Decision Pipeline Socratic Node の盲点検出型への再定義 — 業界ベストプラクティス調査

調査日: 2026-05-26 調査者: [email protected] 目的: Decision Pipeline (ADR-0019) の Gate 1 Socratic Node を「情報不足の追加質問」から「RQ 調査範囲外の盲点検出」に再定義するための根拠収集。ADR 起案前の 3 vendor 並列調査 調査モデル: Gemini 2.5 Pro (Deep Research) / Claude Opus 4.7 / GPT-4o (Deep Research)

0. 背景と課題

現状の問題

bizlp の ADR 起案プロセスは「RQ (Research Question) で 3 モデル並列調査 → Synthesis → 草案起草 → Pipeline 投入」の流れ。草案投入時点で十分な情報が付与されているため、Gate 1 Socratic の「追加質問」はほぼ毎回 0 件で素通りしており、Gate の存在価値が希薄化している。

再定義の方向性

Gate 1 を「起案者が調べた範囲の外にある盲点を検出する」ノードに再定義したい。具体的には:

• Devil's Advocate: RQ Synthesis で 3 モデル合意した結論に対し、あえて反論・反例を探す
• Pre-mortem: 「この決定が失敗するとしたら何が原因か？」を構造的に洗い出す
• 隣接領域の先行事例: RQ で調べなかった分野の類似事例・失敗事例を指摘する

制約

• インタラクティブ構造（起案者に質問→回答を待つ）は維持しなくてよい
• Pipeline 全体の実行時間に大きな影響を与えないこと（async 実行は可、ADR-0066）
• 1 人法人運用（起案者＝審査者）でも機能する設計であること
• ADR-0056 の temperature/sampling 戦略と整合すること

1. 調査設問

1. Devil's Advocate / Red Team 手法: ソフトウェアアーキテクチャ意思決定（ADR / RFC / Design Doc）に対して LLM が Devil's Advocate を務める先行事例・研究はあるか？ 人間の Devil's Advocate との効果比較は？ プロンプトエンジニアリングのベストプラクティスは？

2. Pre-mortem 手法の自動化: Gary Klein の Pre-mortem を LLM で自動化する研究・実装事例はあるか？ アーキテクチャ決定に適用した事例は？ 「失敗シナリオの網羅性」をどう担保するか？

3. Cognitive Bias Detection: 確証バイアス・アンカリング・サンクコスト等の認知バイアスを ADR / 意思決定文書から LLM が検出する手法はあるか？ 特に「起案者＝審査者」（ソロ開発）でのバイアス検出精度は？

4. Adjacent Domain Discovery: RQ の調査範囲外にある「関連するが見落とされた領域」を LLM が自動的に発見する手法はあるか？ RAG + knowledge graph / web search augmentation / multi-hop reasoning 等のアプローチ比較

5. Non-interactive Review 設計: インタラクティブ（質問→回答）ではなく、入力（ADR 草案 + RQ Synthesis）のみで盲点レポートを生成する「ワンショット審査」の設計パターンは？ 出力構造のベストプラクティス（severity 分類、actionable 度、false positive 制御）

6. 効果測定: 盲点検出型レビューの有効性をどう測定するか？ 検出した盲点が実際に意思決定を改善した割合（precision / recall / impact）の計測手法。1 人法人で月次 < 0.5h の運用コストで回せる仕組み

2. 調査結果

2.1 Gemini 2.5 Pro (Deep Research)

RQ1 Devil's Advocate: Anticipatory Reflection (Wang 2024) が中核。従来の事後的反省 (Post-hoc reflection) ではなく、行動実行前に Devil's Advocate として弱点を探索する 3 層の内省的介入。ゼロショット比でタスク成功率 +3.5pp (20→23.5%)、計画修正・試行回数 45% 削減。ALMC (Adaptive LLM-MAS Collaboration) で異なるドメイン専門のエージェントを並列稼働し、意見対立 (Disagreements) を明示抽出。

RQ2 Pre-mortem: Prospective Hindsight (予期的後知恵) が鍵。LLM に過去形で「解剖録 (Obituary) を書け」と指示すると社会的同意シグナルを放棄し事実ベースの死因究明モードに移行。InvThink フレームワーク (arXiv:2510.01569) は「失敗シナリオ列挙 → 影響分析 → 回避のためのアーキ的制約導出」の三段論法を強制。Continuous Claude v3 Pre-mortem (Parcadei) は Tiger / Paper Tiger / Elephant の 3 カテゴリ強制分類。

RQ3 認知バイアス: Chattopadhyay ら (2020) のフィールド研究で開発者の Reversal Actions の 70% が認知バイアスに関連。CB3: Fixation (固着) が 428 件で最多。LLM 自身の確証バイアスも深刻 — Mitropoulos ら (2026) によると PR メッセージで「脆弱性がある」フレーミングで Claude 3.5 Haiku の FPR が 82.0% に悪化。Malberg (2025) の BiasBuster フレームワークで 3 カテゴリ (prompt-induced / sequential / inherent) 定量化。

RQ4 隣接領域: ベクトル検索は「木を見て森を見ず」。GraphRAG でナレッジグラフのトポロジーを活用し Structural Gap Detection (構造的ギャップ検出) でクラスタ間の欠落ノードを特定。LangGraph + グラフクエリ + Web 検索 + SQL の複合推論チェーンが有効。

RQ5 ワンショット設計: ハイブリッド推論 (Claude 3.7 Sonnet 等) + Few-Shot Prompting でノイズ抑制。出力は executive_summary / blind_spots / severity_category (Tiger/Paper Tiger/Elephant) / actionable_mitigation の構造化 JSON。Signal-to-Noise Framework — レビュー価値は「Actionable コメント率 (S/N比)」で決まる。

RQ6 効果測定: Precision (Actionable Rate) / Recall (Catch Rate) / Impact の 3 指標。False Positive Feedback ループ (ZeroPath 方式): Accept/FP フラグ → 次回の Few-Shot 除外例として自動フィードバック。

2.2 Claude Opus 4.7

結論 (先出し): 3 モデル並列 RQ で Gate 1 が死活化したのは設計の失敗ではなく成功の副作用。Socratic Node を廃止するのではなく「Proposer が既に集めた情報の外側を構造的に攻撃するノード」へ再定義するのが正しい。

RQ1 Devil's Advocate: Silverio/Smit (TMLR 2026) の実証研究が最も直接的 — 20 ビジネスシナリオ × 4 エージェント × 480 チーム決定で、T4 (Explicit Dissent Instructions: 99.2%) のみが統計的にベースライン (48.3%) と区別可能。「ソフトに頼んでも効かない」ため敵対的役割を剥き出しに指定する必要あり。Constitutional AI (Anthropic, Bai et al. 2022) の攻撃観点 constitution を YAML で事前定義し毎回ランダムサンプリングする設計を提案。

RQ2 Pre-mortem: Veinott, Klein & Wiggins (2010) の 178 名 5 条件実験で Pre-mortem は Pros/Cons の約 2 倍の効果サイズで過信を低減。LLM 実装は mode collapse (似た失敗ばかり出す) が課題 — 4 カテゴリ強制 (技術的失敗 / 運用的失敗 / ビジネス・規制的失敗 / 認知的失敗) + 高温度 + 複数サンプル dedup で網羅性担保。FMEA の severity × occurrence × detectability スコアリングを乗せると actionability 向上。

RQ3 認知バイアス: Mohanani et al. (TSE 2018) が SW エンジニアリングの 47 バイアスをカタログ化、ADM では anchoring / confirmation / optimism / sunk cost / availability の 5 つが頻出。Sovrano et al. (2025) は confirmation bias が高複雑度タスクで最大 49.1% — バイアス検出器に使うモデルと検出対象の生成モデルは別系統にすべき。7 項目チェックリスト型プロンプト (Anchoring / Confirmation / Sunk Cost / Availability / Optimism / Bandwagon / Premature Closure) + self-report で検出器自身の bias トレース。

RQ4 隣接領域: (c) Web search augmented + (a) LLM analogical reasoning の二段構え。STEP 1: ADR 要旨から core decision を抽象化 → 3 つの異ドメイン (fintech 以外 / 会計以外 / SaaS 以外) で類似決定の失敗 or 成功事例を web search。STEP 2: 発見事例を ADR に mapping し RQ blind spot として severity 付き報告。コスト: 1 ADR あたり 30〜60 秒、$0.10〜0.30。

RQ5 ワンショット設計: LangGraph 3 本並列 (Devil's Advocate T=0.95 / Pre-mortem T=0.8 / Adjacent Domain T=0.85) → Judge/Aggregator (T=0.2) の non-interactive DAG。JSON 出力: { findings: [{ source, title, severity, actionability, evidence, suggested_action, dedupe_group }], total_count_by_severity, self_assessment }. 設計原則: false positive 抑制 (ADR の Risks/Alternatives で既出のものは除外指示)、severity 4 段階 + actionability 4 段階固定、block (Decision を覆す) は極めて稀にする設計バイアスを Judge に埋込。

RQ6 効果測定: 3 層構成 — Tier 1 (毎 ADR 30 秒): socratic_report.json を自動コミット、accepted フィールドを後で人手記入。Tier 2 (月次 5-10 分): GAS で集計ダッシュボード (finding 数/月、accepted 率、ADR revision rate)。Tier 3 (四半期 30-60 分): retrospective で recall proxy (実際に発生した問題を事前に flag していたか)。Sunset 基準: 3 ヶ月運用で accepted rate < 20% OR revision rate < 10% OR 月所要時間 > 0.5h なら再設計 or 廃止。

2.3 GPT-4o (Deep Research)

RQ1 Devil's Advocate: LLM に「Devil's Advocate の役割」と「方針を明示」することが有効 (Sarah Packowski 2023)。LinqAlpha は投資メモに対し複数の前提を抽出後、各反論を証拠付きで生成するシステムを構築。IUI'24 の実験ではインタラクティブモードで意思決定精度が大幅向上、ワンショットでは効果限定的 — ただしレポート形式なら効果あり。

RQ2 Pre-mortem: Karl Wirth (SparkToro) の「Imagine [プロジェクト] failed, list 10 reasons + mitigations」プロンプト。LLM 出力は「近似値」であり人間の検証が必要 (Xebia)。複数回プロンプト (技術的要因→人的要因→外部要因) + 既知失敗事例 DB を RAG で参照する設計が効果的。

RQ3 認知バイアス: ジョージタウン大の研究で確証バイアスほぼ 100%、循環的思考・隠れた前提も約 98% の精度で検出可能。ただし ADR 文書への特化評価例はまだ乏しく、「その指摘の根拠は？」と証拠付けを要求するプロンプト設計で精度向上の余地。

RQ4 隣接領域: RAG (ベクトル検索) + Knowledge Graph (GraphRAG) + マルチホップ推論の組合せが重要。LaunchDarkly の「初期検索で結果が乏しい場合、関連ドメインのフレーズに言い換えて再検索」手法。Neo4j の解説による GraphRAG で複雑な質問にも答えやすくなる。

RQ5 ワンショット設計: 出力フォーマットを厳格に定義 (JSON/テーブル)。項目ごとに責任者・対応時期を記載。深刻度 (1〜10 スコア) と重要度ランク付与。多段階審査 (各問題に「エビデンスは十分か？」最終確認) で偽陽性を約 80% 削減可能。

RQ6 効果測定: Precision (実際に重要だった割合) / Recall (本来見逃しやすかった問題の検出率) / Impact (修正の規模と経済的価値)。1 人法人では ADR 完了時に「AI 指摘を参考にしたか」「結果どう変わったか」を簡単メモする運用で代替。後工程での問題発生率低下やレビュアーの満足度が実利的な効果指標。

3. サマリー（3-vendor 統合結論）

3 者一致率: 6/6 設問で方向性一致 (100%)、実装詳細で差異あり

3.1 完全一致点

3.2 差異・補完点

3.3 bizlp 向け推奨設計 (Informed Synthesis)

Claude の 3 本並列 + Judge 設計を骨格とし、Gemini の Tiger/Paper Tiger/Elephant 分類と FP Feedback ループ、GPT の多段階検証を組み込む:

LangGraph 構造 (async parallel branches):

        ADR Draft + RQ Synthesis
                |
        ┌───────┼───────┐
        |       |       |
   Devil's   Pre-mortem  Adjacent
   Advocate   Node      Domain
   (T=0.95)  (T=0.8)   (T=0.85)
        |       |       |
        └───────┼───────┘
                |
        Judge / Aggregator (T=0.2)
                |
        Structured Blind-spot Report (JSON)

出力スキーマ:

{
  "findings": [{
    "source": "devil_advocate | premortem | adjacent_domain",
    "title": "str",
    "severity": "critical | high | medium | low",
    "actionability": "block | revise_adr | add_to_risks | monitor",
    "evidence": "str",
    "suggested_action": "str",
    "dedupe_group": "str"
  }],
  "total_count_by_severity": {},
  "self_assessment": { "confidence": "0-1", "known_limitations": [] }
}

段階的導入:

• Now: Devil's Advocate + Pre-mortem の 2 ノード + Judge 実装、既存 ADR 5 本で calibration
• Next (3 ヶ月以内): Adjacent Domain ノード (web search 込み) 追加、Tier 2 月次ダッシュボード
• Later (retrospective 次第): accepted rate > 30% なら温度・constitution を尖鋭化、< 20% なら再設計 or 廃止

Sunset 基準: 3 ヶ月運用で accepted: true/partially < 20% OR ADR revision rate < 10% OR 月所要時間 > 0.5h