Gate 1: 盲点検出 (Blind-spot Detection) プロンプト設計ドキュメント (v2.0)

実装ステータス: ADR-0071 で「Socratic 問診」から「盲点検出エンジン」へ再定義済み 実装ファイル: drp/src/nodes/socratic.ts（ノード名は socratic のまま） モデル: claude-sonnet（ADR-0033 で gemini-flash から upgrade） 方式: Devil's Advocate (DA) + Pre-mortem (PM) の 2 本並列 → Judge/Aggregator による non-interactive DAG。情報提供型（差戻しなし） 基盤 ADR: ADR-0071 / ADR-0019 / ADR-0033 ノード挙動仕様: nodes/02_socratic.md（フロー図・State 入出力の正典） プロンプト本文 SSoT: KV active-pointer（bizlp:prompts:gate1-da / gate1-pm / gate1-judge の :active）。本ドキュメントに掲載する文面は socratic.ts 内の inline fallback（KV 未登録時に使用）であり、設計の参考。

⚠️ 旧仕様からの変更: v1.0（2026-05-12, Phase 2b）の「不足情報を最大 3 問問診して pass=false で差し戻す」方式は ADR-0071 で廃止。現在 Gate 1 は問診を行わず、起案者が見落としているリスク・反論・失敗シナリオを機械的に洗い出して PR body の Blind-spot Report に提示するのみ（pass/fail 判定には使わない）。本ドキュメントは現行実装に合わせて全面改稿（v2.0）。

目的

Triage 通過後、起案者ドラフトの 盲点検出を行う。Devil's Advocate（敵対的反論）と Pre-mortem（事前検死）の 2 本を並列実行し、Judge が統合・重複排除して findings を生成する。

• 解決する課題: RQ Synthesis の 3 モデル合意が同じ訓練データバイアスで盲点を共有するリスク、および Proposer＝Reviewer のソロ運用で confirmation bias が構造的に排除できないリスク（ADR-0071 §1.3）。
• 設計思想: 情報提供型（差戻しなし）。findings は PR body の Blind-spot Report に表示し、人間（代表取締役）が最終判断する。Gate 1 は常に socraticPass=true を返す。
• 後段との連携: ここで生成した blindSpotFindings は、後続の Cross-Validation ノード（ADR-0076）で評価軸（Must 軸等）とのペア判定に使われ、critical × Must 軸 × undermines のときのみ差し戻される。Gate 1 自体は差し戻さない。

アーキテクチャ

                ┌──────────────────────┐
   draft ──┬──▶ │ Devil's Advocate (DA) │ T=0.95 ─┐
            │    └──────────────────────┘          │
            │    ┌──────────────────────┐          ├─▶ Judge/Aggregator ─▶ blindSpotFindings[]
            └──▶ │ Pre-mortem (PM)       │ T=0.8  ─┘    (T=0.2, dedupe, max 10)
                 └──────────────────────┘

• 3 プロンプトを KV から並列ロード（gate1-da / gate1-pm / gate1-judge、ADR-0042 Active Pointer）。各サンプルの timeout は 90 秒。
• Constitution（22 観点）: socratic.ts 内に 22 の批判観点（採用案の最大の弱点 / 撤退条件の現実性 / GAS 6 分制限 / 監査要件整合 など）を保持し、毎回ランダムに 3 観点を選んで DA プロンプトに付加する。固定プロンプトによる盲点の固定化を避けるための仕掛け。
• フェイルセーフ: DA・PM が両方失敗した場合のみ、空の findings で skip-through（socraticPass=true）。Judge 失敗時は DA/PM の生 findings を actionability=monitor で返す。

System Prompt（inline fallback / 設計参考）

① Devil's Advocate（gate1-da, T=0.95）

You are a Devil's Advocate reviewing an Architecture Decision Record (ADR) proposal.
Your role is explicitly adversarial — challenge the proposed decision with
counter-arguments, counter-examples, and overlooked risks.

[Rules]
- Generate 3-5 counter-arguments against the proposed decision
- Each counter-argument must include concrete evidence or reasoning, not vague skepticism
- Focus on what the proposer has NOT considered, not what they wrote poorly
- Do not soften your critique — be direct and specific
- If the decision references prior research (RQ Synthesis), challenge whether the
  research missed relevant domains or contrary evidence

[Language]
- All string values MUST be written in Japanese (日本語). 専門用語の英単語はそのまま使用可。

[Output: JSON only, no markdown fences]
{ "findings": [ { "title", "severity": "critical|high|medium|low", "evidence", "suggested_action" } ] }

実行時、上記に加えて選択された 3 つの Constitution 観点が [Constitution — focus on these perspectives this run] として付加される。

② Pre-mortem（gate1-pm, T=0.8）

You are conducting a Pre-mortem analysis of an ADR proposal.
Imagine it is 6 months from now. This ADR was adopted and the system has
catastrophically failed.

[Rules]
- Generate failure scenarios in EXACTLY 4 categories (one per category minimum):
  1. Technical (code, infra, performance, security)
  2. Operational (deployment, monitoring, maintenance, on-call burden)
  3. Business/Regulatory (cost overrun, compliance violation, stakeholder rejection)
  4. Cognitive (sunk cost, confirmation bias, scope creep, premature optimization)
- For each: severity (critical|high|medium|low) と probability (likely|possible|unlikely)
- Focus on failure modes NOT already mentioned in the proposal's risks section

[Output: JSON only]
{ "findings": [ { "category", "title", "severity", "probability", "evidence", "suggested_action" } ] }

③ Judge/Aggregator（gate1-judge, T=0.2）

You are a Judge aggregating blind-spot findings from two adversarial reviewers
(Devil's Advocate and Pre-mortem).

[Rules]
- Merge findings from both sources; deduplicate same-core-concern findings
- Classify each: severity, actionability
  actionability = block | revise_adr | add_to_risks | monitor
- REMOVE findings already addressed in the proposal's context
- "block" は極めて稀（真に決定を覆す盲点のみ）
- Output max 10 findings, prioritized by severity × actionability

[Output: JSON only]
{ "findings": [ { "source", "title", "severity", "actionability", "evidence",
  "suggested_action", "dedupe_group" } ], "summary": "1-2 sentence overall assessment" }

出力スキーマ（State: blindSpotFindings）

Judge 通過後、各 finding は以下の形に正規化されて State に格納される（nodes/02_socratic.md §出力が正典）:

{
  "source": "devil_advocate | premortem | both",
  "title": "盲点の短いタイトル（日本語）",
  "severity": "critical | high | medium | low",
  "actionability": "block | revise_adr | add_to_risks | monitor",
  "evidence": "なぜこれが実在するリスクか（具体）",
  "suggestedAction": "起案者が調査・追記すべきこと",
  "dedupeGroup": "重複排除のグループキー"
}

socraticPass は常に true、socraticQuestions は常に空配列（旧問診方式の名残のフィールド）。

通過挙動

いかなる場合も Gate 1 は差し戻さない（情報提供型）。差し戻し判断は後段の Cross-Validation（ADR-0076）が担う。

テストケース（要移行 / 既知ドリフト）

⚠️ テストハーネス未移行: drp/test-tc-socratic.mjs の TC-S01〜S03 は 旧問診方式（pass/questions を gpt-4o で検証）のままで、現行の盲点検出（DA/PM/Judge）に未移行。pass=false 差し戻しを期待する旧ケースは現実装では再現不能（常に socraticPass=true）。

このテスト移行はコード側（main ワークスペース）の作業。盲点検出向けの新テスト観点は「DA/PM が findings を生成するか」「Judge が重複排除し max 10 に収めるか」「全ノード失敗時に空 findings で skip-through するか」。本ドキュメントでは旧 TC-S01〜S03 を撤去し、移行は main 申し送りとする。

UI / PR body での表示

盲点検出は差し戻さないため、findings は起案フォームではなく 生成される ADR PR body の「Blind-spot Report」セクションに表示される。severity・actionability 付きで列挙し、actionability=block の finding がある場合は代表取締役の確認を促す。

変更履歴