最終更新: 2026/06/22 18:56
commonid: synthesis-writing-guidetype: how-tostatus: active
pageaudience: agent

Synthesis 執筆ガイド (How-to)

読者: 新規参加者 (将来の経営層) + AI Agent 前提知識: ADR-0050 (規約) を一読 所要時間: 初回読了 30-60 分、最初の Synthesis 執筆 + 半日

本ドキュメントは 手順書 (How-to)。設計根拠は synthesis_rationale.md、 誤り回避は synthesis_anti_patterns.md を参照。

1. パイプライン全体フロー

bizlp の Synthesis は ADR-0019 (Decision Pipeline) の 4 段階で進行する。

段階 1: 起案
  → メタプロンプト + 実プロンプト + Decision Drivers pre-register + PR

段階 2: 並列調査 (横断プロセス)
  → Claude / Gemini / GPT Deep Research 3 モデル並列実行
  → 結果ファイル 3 つを PR にバンドル

段階 3: Synthesis 執筆 (本ガイドの中核)
  → 3 モデル結果を Considered Options として収録
  → K.O. Criterion 判定 (定性、Standard/Critical) + Evaluation Matrix (加重和、タイブレーク用)
  → Decision Outcome 確定

段階 4: ADR 起案 / 実装
  → Synthesis の決定を ADR に transcribe または直接実装

2. 段階 1: Driver の Pre-registration

2.1 目的

評価軸を 3 モデル並列調査の結果を見る前に 確定する。 これにより post-hoc rationalization (事後合理化) を構造的に防止。

2.2 作業手順

  1. 案件の Triage を判定 (ADR-0020 準拠: Light / Standard / Critical)
  2. 案件の Scope を判定 (ADR-0049 準拠: corporate / platform / product / ops)
  3. arc42 Q42 9 タグから関連軸を識別 (5-7 個に絞る)
    • 9 タグ: #reliable / #flexible / #maintainable / #efficient / #usable / #operable / #suitable / #secure / #safe
    • 軸定義の詳細解釈: synthesis_rationale.md#q42-bizlp-interpretation 参照
  4. トレードオフが発生する軸を残す (3-5 個に絞る、5 個推奨)
  5. 重要度ラベルを付与 ([Must] / High / Medium)
    • [Must] は複数許容、ただし軸数の半分以下を目安
    • 5 軸採用なら [Must] 2-3 個、4 軸なら 2 個、3 軸なら 1-2 個
  6. 5 個未満を選んだ場合は理由を明記 (関係軸が 5 個未満の場合のみ許容)
  7. 省略軸の理由カテゴリを明示 (7 種から選択、synthesis_rationale.md 参照)
  8. 段階 1 PR を起案 (メタプロンプト + 実プロンプト + 上記 Driver pre-register)

2.3 Triage 判定の目安

Triage該当ケース
Light軽微な変更、可逆、本番影響なし。typo 修正、文言調整等。Synthesis 自体が不要なケースも多い
Standard中程度の影響、3 モデル並列調査の価値がある。新規機能追加、ADR テンプレート拡張、Lint ルール追加 等
Critical重大な影響、不可逆性高い、Bezos Type 1。ADR-0050 自身、ADR-0020 Triage 基準改訂、本番データに直接影響 等

判定で迷ったら 1 段上 (より厳格) を選ぶ。後で軽量化はできるが、Light で 後から重大事項と判明する方がリスク大。

2.4 Scope 判定の目安

ADR-0049 の階層定義を参照:

Scope該当ケース
corporate法人運営・組織・人事・税務・契約 (将来の経営層拡大時の判断等)
platform全プロダクトに影響する基盤 (ADR テンプレ、Decision Pipeline、CI/CD、AI Agent 運用ルール)
product管理会計プロダクト固有 (SSOT INV、仕訳エンジン、データマート、FP&A)
ops日々の業務オペ・統制 (ITGC、月次決算、playbook、障害対応)

2.5 軸選定の典型パターン (Scope 別)

Scope典型 [Must] になりやすい軸
corporate#reliable (事業継続性) / #suitable (法令適合) / #secure (機密情報)
platform#maintainable (AI Agent 解釈性) / #suitable (既存 ADR 整合) / #flexible (将来拡張)
product#reliable (確実な実行) / #suitable (会計基準) / #efficient (GAS 6 分制限)
ops#operable (運用容易性) / #safe (本番データ保護) / #secure (機密値管理)

これは 目安であり、案件特性で異なる。固定ルール化しないこと。

3. 段階 2: 3 モデル並列調査 (横断プロセス)

3.1 目的

すべての Synthesis で 3 モデル並列調査を実施する。これは Q42 軸選定とは 独立した 横断的プロセス品質保証。

3.2 作業手順

  1. 段階 1 で起案した実プロンプトを Claude / Gemini / GPT に同時投入
  2. 各モデルから Deep Research 結果を取得
  3. それぞれを RQ-NNN_<topic>_result_<model>.md として保存
  4. nav 登録 (docs/_config.json)
  5. research_questions.md のステータス更新

3.3 注意

  • 3 モデルの結果を 読んでから 軸を追加・変更してはならない (pre-registration 違反)
  • 結果ファイル間で内容の重複は許容 (各モデルの独立性を保つため)
  • 結果に間違いがあっても訂正せず原文ママ保存 (Considered Options で批判的に扱う)

4. 段階 3: Synthesis 執筆

4.1 テンプレートのコピペ

docs/_meta/templates/synthesis.md をコピーして docs/_internal/01_discovery/research_prompts/RQ-NNN_<topic>_synthesis.md として作成。

4.2 各セクションの埋め方

§0 自己言及性

通常案件では削除。フレームワーク自身を確立する self-bootstrapping Synthesis (ADR-0050 のような) のみ記述。

§1 Context & Problem Statement

  • 1-2 段落で簡潔に
  • 詳細背景は References へリンク
  • §1.1 顕在化した問題、§1.2 解決すべき問題の 2 サブセクション

§2 Decision Drivers (Pre-registered)

  • 段階 1 PR で確定した内容を そのまま再掲
  • ここで内容変更しないこと (pre-registration の精神)
  • §2.1 採用軸の表、§2.4 省略軸 justification は Triage 別に粒度調整

§3 Considered Options (3 モデル並列調査結果)

  • 各モデル: 推奨 / 主な特徴 / 強み / 弱み の 4 ブロック
  • 強み = この案の Advantage (CBA 形式)
  • 弱みは「他案の長所の裏返し」になっていないか確認 (二重カウント防止)

§4 K.O. Criterion 判定 (v2 順序: 定性を先に判定)

  • Light は本セクション削除 (K.O. 判定なし、§5 加重和のみ)
  • Standard: 代表取締役氏が Critic agent 役で 1 ラウンド判定 (実装後は自動)
  • Critical: Critic agent 3 ラウンド (Self-Consistency)、1 票でも fail なら fail
  • 各 [Must] 軸ごとに案件ごとの pass/△/fail を判定
  • 「決定的 Advantage」または「不通過理由」を必ず記述
  • v2 改訂注: 旧 v1 では §5 K.O. → §4 Evaluation Matrix だったが、執筆者を post-hoc rationalization に誘導する構造的弱点が Gate 4 retroactive validation で識別され反転 (ADR-0050 §4.1 v2 改訂注 / ADR-0050_gate4_validation_report.md §6.4)

§5 Evaluation Matrix (タイブレーク用)

  • 1-5 段階で採点
  • 採点根拠を必ず備考列に記載 (将来の振り返り・再現性のため)
  • 加重和は機械計算 (Excel/スプレッドシートで OK)
  • 正規化スコア = 素点 ÷ (5 × 係数合計)
  • 例: 5 軸採用、係数合計 = 6.5 (Must×2 + Must×2 + High×1 + High×1 + Medium×0.5)、満点 = 5 × 6.5 = 32.5
  • Critical/Standard では §4 K.O. 通過案のタイブレーク用、Light では本節が唯一の採択根拠

§6 Decision Outcome

  • 採択案を明確に宣言
  • ハイブリッド統合の場合は §6.2 で各要素の出所を明示 (informed extension)
  • §6.3 Justification: 最優先 Driver に対する決定的 Advantage を明記
  • §6.4 数値検証: §4 K.O. 通過案の中で §5 加重和首位案が一致するか確認
    • 一致 → 結論の確信度最大
    • 不一致 → Triage 連動運用で裁定 (Critical: K.O. 絶対 / Light: K.O. なしのため §5 加重和首位がそのまま採択 / Standard: 別途記述)
  • §6.5 長期方針: 該当する場合のみ (案 B 移行視野等)

§7 Consequences

  • Positive / Negative / Neutral を必ず記述
  • Negative を書けない場合は採点が confirmation bias の可能性 → 自己点検

§8 Confirmation

  • Standard/Critical 必須、Light 任意
  • §8.1 実装確認方法 (Step 表)
  • §8.2 レビュー期日
  • §8.3 振り返り (Critical 必須、3 ヶ月 / 6 ヶ月 / 1 年)
  • §8.4 蓄積する組織知 (振り返り結果を anti_patterns に集約)

§9 Caveats / 限界条件

  • §9.1 Pre-registration の状態
  • §9.2 暫定値の明示 (v1 暫定で将来見直し可能なもの)
  • §9.3 Confirmation bias 緩和策 (採点逆方向でも結論が変わらないか自己点検)
  • §9.4 その他の限界

§10 References

  • 業界フレームワーク (一次資料 URL/DOI)
  • bizlp 既存 ADR
  • 関連 RQ / PR
  • 段階 2 結果ファイル

4.3 Triage 別の作業ボリューム

Triage1 件あたり所要時間Critic ラウンド省略軸 justification
Light15-30 分スキップ1 行 / 軸
Standard30-60 分1 ラウンド1-2 行 / 軸
Critical1-2 時間3 ラウンド1 段落 / 軸

5. LLM Critic Agent との接し方 (段階 7 実装後)

5.1 Critic agent の役割

  • K.O. Criterion 判定を機械化
  • AutoGen / Multi-Agent Debate パターン
  • system prompt は synthesis_rationale.md#critic-agent-system-prompt 参照

5.2 代表取締役氏の作業

  1. 段階 3 で各案を 1-5 採点
  2. Critic agent が K.O. 判定を出力 (JSON)
  3. Critic 結果を批判的に確認 (盲信しない)
  4. 異議があれば手動上書き + 理由ログ
  5. ループ 3 回で結論出ない場合は Critical 格上げ

5.3 Critic 結果の見方

{
  "evaluations": [
    {"option": "Claude", "ko_judgment": "PASS",
     "cited_advantage": "...", "reason": "..."},
    ...
  ]
}
  • cited_advantage を確認: 引用が誤っていないか
  • reason を確認: Must driver と直接関係しているか
  • 同じ案件を 2 回実行して結果が同じか (Self-Consistency)

5.4 Critic agent の既知失敗モード

  1. yes-man (Proposer に同調) → 別モデル使用で緩和
  2. 過剰批判 (全 fail) → 「Must driver に直接関わる点のみ」と指示
  3. multi-round 収束しない → ラウンド上限 2-3
  4. 自身の confirmation bias → JSON 構造化 + reasoning 必須
  5. 非決定性で再実行で結果違う → Self-Consistency で多数決

6. K.O. 通過ゼロ時の handling

すべての案が Must を満たさない場合:

6.1 Light: 発生しない (K.O. 判定なし)

6.2 Standard

1. Synthesis に通過ゼロを明記、段階 4 に進まない
2. 段階 1 へ戻る (別 PR で起案):
   - Driver の再設定 (Must を 1 個減らす、軸を入れ替える)
   - 代表取締役氏がレビュー、再 pre-register
3. 段階 2 を再実施 (新 Driver で 3 モデル調査)
4. 段階 3 を再実施
5. ループ上限: 3 回まで、3 回で Critical 自動格上げ

6.3 Critical

1. 通過ゼロを Synthesis 結果に明記
2. 段階 1 戻し (Standard と同様)
3. ループ上限: なし
4. 「判断不能」を正直に認める
   - ADR 起案を延期
   - 追加調査 (補助 RQ 起案、別領域の知見収集) を実施
5. 緊急採択 (Must を緩めて採択) は禁止
   → post-hoc rationalization の典型に堕ちる

7. セルフレビューチェックリスト (Synthesis 完了前)

提出前に以下を確認:

7.1 Pre-registration 整合性

  • 段階 1 PR で確定した Driver と §2 が完全一致
  • 段階 2 結果を読んでから軸を追加していない
  • 軸数が 5 個 (または 3-4 個で理由明記)
  • [Must] 個数が軸数の半分以下

7.2 K.O. 判定 (Standard/Critical) — v2 順序で先に確認

  • 各 [Must] 軸ごとに pass/△/fail を判定
  • 決定的 Advantage または不通過理由を記述
  • 通過ゼロなら REQUIRES_REPROPOSAL を §6 で宣言

7.3 Evaluation Matrix

  • すべての軸に採点根拠を備考列で記載
  • 加重和の計算が正しい (係数 × 素点)
  • 正規化スコア = 素点 ÷ 満点 で計算

7.4 Decision Outcome

  • 採択案を明確に宣言
  • §6.3 Justification で最優先 Driver の Advantage を明記
  • §6.4 数値検証で加重和と K.O. の整合性を確認

7.5 Consequences

  • Positive / Negative / Neutral 全部記述
  • Negative が書けるか (confirmation bias 自己点検)

7.6 Caveats

  • §9.3 で「採点逆方向でも結論が変わらない」確認
  • v1 暫定値があれば §9.2 で明示

7.7 References

  • 業界 FW の一次資料 URL/DOI を記載
  • 関連 ADR / RQ を明示
  • 段階 2 結果ファイル 3 つすべて参照

7.8 アンチパターン回避

  • synthesis_anti_patterns.md の典型誤り 5-10 件と照合
  • post-hoc rationalization の自覚チェック (採点後に軸を変えていない)

8. 振り返りの運用 (Critical 必須)

8.1 振り返りタイミング

  • 3 ヶ月後: テンプレートの使いやすさ、所要時間の妥当性
  • 6 ヶ月後: 重要度ラベル係数 (v1 暫定) の妥当性
  • 1 年後: 案 B 移行可能性、累計 20-30 件での総括

8.2 振り返りで記録する内容

  • K.O. 判定で迷ったケース
  • Critic agent が誤判定したケース (実装後)
  • 軸選定の誤り事例
  • post-hoc rationalization の兆候を発見したケース
  • 数値スコアが結論を変えた回数 (案 B 移行トリガーの判定材料)

8.3 振り返り結果の蓄積先

  • synthesis_anti_patterns.md に集約
  • 6 ヶ月ごとに整理し、新規参加者向け教材化
  • ADR-0050 v2 改訂の根拠資料

9. よくある質問

Q1. Q42 9 タグでカバーできない関心事がある時は?

A. subsume ルールで最も近いタグに帰属させる。詳細パターンは synthesis_rationale.md#subsume-patterns。例:

  • 財務コスト → #reliable (事業継続性)
  • LLM トークン費 → #reliable (同上)
  • Time-to-market → #reliable
  • 監査要件 → #suitable + #operable

ad-hoc に新規軸を作るのは禁止 (Q42 完全固定の規約)。

Q2. 3 モデル全部が同じ結論を出した場合の Synthesis は?

A. 短くて OK。Considered Options で「3 モデル全員一致」と明記し、 Evaluation Matrix は省略可。ただし K.O. 判定 (Standard/Critical) は実施。

Q3. 代表取締役氏 1 人で全部判断しているのに deciders: [代表取締役] だけ?

A. はい。将来の経営層拡大時に複数 deciders 記載に拡張。

Q4. Critic agent が実装されていない現状で K.O. 判定はどうする?

A. 代表取締役氏が手動で実施。手順:

  1. 各 [Must] 軸について各案の Advantage を読む
  2. pass / △ / fail を判定
  3. 判定理由を必ず記述
  4. §9.3 Caveats で「手動判定」と明記

Q5. Synthesis の振り返りはいつ書く?

A. 3 ヶ月後・6 ヶ月後・1 年後の 3 回。元の Synthesis ファイルに 「§11 振り返り」セクションを追記する形。

10. 参照

  • ADR-0050 (Synthesis 標準テンプレート) — 本ガイドの規約
  • docs/_meta/templates/synthesis.md — Synthesis ひな形
  • synthesis_anti_patterns.md — よくある誤り
  • synthesis_rationale.md — Q42 解釈表 / subsume パターン / 理由カテゴリ運用
  • ADR-0019 (Decision Pipeline LangGraph) — Critic agent 実装基盤
  • ADR-0020 (Triage 基準) — Light/Standard/Critical 区分
  • ADR-0049 (ADR Scope 4 層) — Corporate/Platform/Product/Ops 区分