Gate 2: 過去 ADR 整合性チェック プロンプト設計ドキュメント (v1.1)

実装ステータス: Phase 2c 完了 (2026-05-12) / ADR-0033 でモデル刷新 実装ファイル: drp/src/nodes/consistency.ts モデル: claude-opus（claude-opus-4-7、LiteLLM Gateway 経由） パラメータ: loadLlmParams(env, 'gate2-consistency', { temperature: 0.4, seed: 42 })（KV bizlp:prompts:gate2-consistency:params で上書き可） ノード挙動仕様: nodes/06_consistency.md プロンプト本文 SSoT: KV active-pointer（bizlp:prompts:gate2-consistency:active）。以下の System Prompt は consistency.ts 内 FALLBACK_PROMPT（KV 未登録時に使用）と一致。

⚠️ v1.0 からの変更: モデルは claude-sonnet → claude-opus に刷新済み（ADR-0033）。ADR 取得方式も Contents API 並列 fetch → GraphQL 一括取得 + KV キャッシュに変更済み（下記実装メモ参照）。

目的

新規 ADR ドラフトが既存 ADR（リポジトリ内 docs/adr/ の全ファイル）と Conflict / Supersede / Info の関係にあるかを自動判定し、矛盾を早期に差し戻す。

System Prompt (v1.0)

あなたは ADR (Architecture Decision Record) の整合性審査員である。
提出された新規 ADR ドラフトと、リポジトリ内の既存 ADR 一覧を照合し、以下の判定を行え。

[判定区分]
- CONFLICT  : 新規 ADR が既存 ADR の決定と矛盾・逆行する。両立不可能。
- SUPERSEDE : 新規 ADR が既存 ADR を意図的に上書きする。ADR 本文に "Supersedes: ADR-NNNN" の明記が必要。
- INFO      : 直接の矛盾・上書きはないが、参照・考慮すべき関係がある。
- PASS      : 整合性に問題なし。

[判定ルール]
1. CONFLICT は「決定の方向性が逆向き」「前提となる制約を破壊する」「既存の採択済み制限を無視している」場合のみ。軽微な方針の違いは INFO 扱い。
2. SUPERSEDE は「既存 ADR の核心的な決定を置き換える」場合。新規 ADR のドラフト本文に明示的な Supersedes 宣言があれば SUPERSEDE を許容とする。なければ CONFLICT 相当として扱う。
3. verdict は最も重大な区分を選ぶ（CONFLICT > SUPERSEDE > INFO > PASS）。
4. conflicts は CONFLICT / SUPERSEDE / INFO に該当する ADR のみ列挙する。PASS の場合は空配列。
5. severity = "CONFLICT" または "SUPERSEDE" の場合、rejection_hint に「何を修正すれば通過できるか」を具体的に 150 字以内で記述する。

[出力ルール]
- JSON のみを出力。前置き・解説・コードブロックの ``` も禁止。
- adr_number は "017" 形式（3桁ゼロパディング）。

[出力フォーマット]
{
  "verdict": "PASS" | "CONFLICT" | "SUPERSEDE" | "INFO",
  "conflicts": [
    {
      "adr_number": "NNN",
      "adr_title": "string",
      "severity": "CONFLICT" | "SUPERSEDE" | "INFO",
      "reason": "string"
    }
  ],
  "rejection_hint": "string | null",
  "summary_md": "string"
}

User メッセージ構造

## 新規 ADR ドラフト
{state.adrBody}

## 既存 ADR 一覧（先頭 40 行抜粋）
=== 001_ssot_invoice.md ===
（先頭 40 行）

=== 002_engine_separation.md ===
（先頭 40 行）

... (全 ADR)

差し戻し判定ロジック

テストケース

TC-C01: CONFLICT 検出（明示的矛盾）

入力: 「列参照を列番号ハードコードで統一する ADR」

期待: verdict = "CONFLICT", conflicts[].adr_number = "011" (DTO ヘッダーベース列アクセス ADR)

TC-C02: SUPERSEDE 宣言あり → 通過

入力: Gemini から Claude への領収書 OCR 移行 ADR で Supersedes: ADR-0007 を明記

期待: verdict = "SUPERSEDE", 続行 (差し戻さない)

TC-C03: SUPERSEDE 宣言なし → 差し戻し

入力: Gemini から Claude への領収書 OCR 移行 ADR で Supersedes 宣言なし

期待: verdict = "SUPERSEDE", rejected = true (宣言追記を要求)

TC-C04: INFO のみ → 通過

入力: 新規テーブル追加 ADR (既存 ADR-0005 Sheets-as-datastore と関連)

期待: verdict = "INFO", 続行, PR 本文に整合性セクション追加

TC-C05: PASS → 通過

入力: 完全に独立した新規機能 ADR

期待: verdict = "PASS", 整合性セクションなし

実装メモ

• ADR 取得: GitHub Contents API で docs/adr/ を一覧取得（1 subrequest）→ GitHub GraphQL で全ファイル本文を 1 リクエストに一括取得（エイリアス f0..fN / object(expression:)、Unicode パス事故回避のため変数経由）。download_url の個別並列 fetch は使わない。
• KV キャッシュ: 取得結果は DRAFTS_KV の _cache:adr-summaries に TTL 1h（3600s）でキャッシュ。cache hit 時は GitHub を叩かない。
• 対象ファイル: docs/adr/ 内で /^(\d{4}-|\d{3}_).*\.md$/ にマッチする全 ADR（README.md / _template.md 除外）× 先頭 40 行抜粋。固定ファイル数ではない（ADR は 100 件超に増加済み）。
• Supersedes 検出: /supersedes?.*ADR-\d{3,4}/i で 3 桁（旧）・4 桁（新, ADR-0023 で統一）両対応。
• CONFLICT / 宣言なし SUPERSEDE 時は state.rejected = true + state.rejectionMsg を設定（scoring node と同じパターン）。
• consistency ノードは scoring 合格後のみ実行（コスト最適化）。

変更履歴