関連ADR:ADR-0131 へADR-0133 へADR-0143 へADR-0154 へ 最終更新: 2026/06/22 18:56
commonid: rq-098-scope-aware-critique-synthesistype: researchstatus: active

RQ-098: スコープ境界を尊重する LLM critic ゲート設計（FN=0 維持）— 3モデル調査 synthesis

調査: 2026-06-08、OpenAI o3-deep-research / Gemini deep-research-preview / Claude opus を同一プロンプトで実行。生結果は docs/research/rq-098-result-{openai,gemini,claude}.md。 目的: Cross-Validation ゲートが「審査中の単一決定のスコープ外（下流 ADR が所有）」の懸念で過剰却下する failure mode を、FN=0（本来却下すべき指摘を取りこぼさない）を犠牲にせず直す機構を定義する。 背景: 現状 CV の差し戻しは critical × Must軸 × undermines のみでスコープ判定が無い（ADR-0076 導入 / ADR-0109 で過剰審査ループの終端対処は済）。

Executive Summary（横断 key findings）

3モデルが独立して合意した点を最優先で 5 つ。

  1. 「閾値を緩める」では FN=0 を壊す。スコープという直交特徴量の追加が唯一の解。（3モデル合意） precision/recall は閾値上で逆相関する。バーを下げて FP を減らせば必ず FN が増える。決定境界を「動かす」のでなく、スコープメタデータという新しい軸を足して境界の「形」を変える（Claude が最も明示・OpenAI/Gemini も同旨）。

  2. スコープ判定は自然言語プロンプトでなく「実行可能（構造化・evidence 固定）なルーブリック」でのみ安定する。（3モデル合意） 自由記述の「問題を探せ」は run 間で不安定。各 (finding × Must軸) ペアで in_scope/out_of_scope/insufficient_evidence の per-axis 二値＋ADR からの逐語引用（evidence_quote）を必須にする。OpenAI=分離ルーブリック、Gemini=analytic rubric/pairwise、Claude=Rulers 流の versioned/hashed ルーブリック。

  3. out-of-scope は「捨てる」のでなく「具体的に名指しされた下流先へ re-home（降格）」する。委任先が無い指摘は keep（却下）が安全側のデフォルト。（3モデル合意） 降格できるのは「ID で解決する下流 ADR/spike が存在し、それ自身のドライバー・rollback/KPI・オーナーを持つ」場合のみ。委任先が無い＝実質「afterwards（後回し）」で、FN を生むので却下に倒す。

  4. 判定ロジックは LLM でなく決定論的な post-processor（外部検証器）に置く。（3モデル合意 = LLM-Modulo 思想） 降格に至る唯一の経路を「全ゲート通過」とし、parse 失敗・evidence 不一致・target_id 未解決・いずれかの Must軸 undermines=yes は すべて keep。LLM の自己判定や自己批評ループは構造的に非収束（Huang ICLR 2024 / Kambhampati LLM-Modulo ICML 2024）なので最終判定を委ねない。

  5. 検証は recall-first の非対称オフライン回帰。aggregate accuracy / F1 は誤り。（3モデル合意） golden データセットに「ロックケース型」を入れ、must-keep クラスの recall が回帰したらデプロイをブロックする。FP 削減は副次指標。希少クラスでは PR-AUC が ROC より適切（Claude/Gemini）。spec-gaming 検知用の adversarial ケース（偽 target_id・循環委任・逐語捏造）も golden に入れる。

3モデル横断の合意 / 相違（設問別）

設問1 — スコープ表現と判定安定化

合意点（3モデル）

  • critic に「機械可読のスコープカード」を渡す。共通して挙がったフィールド: 決定ドライバー（Must/Should）・context/決定の問い・独立可逆性・rollback/KPI・ステークホルダー/オーナー・下流/関連 ADR（typed edge）。RQ-097 の「4発散シグナル」と整合。
  • ルーブリックは**ホリスティック1点でなく per-axis（分離次元）**で採点。OpenAI は Anthropic の「次元別採点」推奨を引用、Claude は analytic rubric、Gemini も per-criterion を強調。
  • temperature 0 / few-shot / 構造化出力で run 間の再現性を上げる。

相違・固有の指摘

  • OpenAI: scope-relevance と severity を別次元に分離して採点（「大きい問題」と「in-scope」を混同させない）。chain-of-thought でスコープを毎回再導出させる。
  • Gemini: 「In-Scope 基準 = エージェントが制御可能な変数（引数妥当性・スキーマ・semantic grounding）／Out-of-Scope = 外部環境要因（API レート制限・外部障害・third-party 品質）」をプロンプトで明示禁止しないとスコアが汚染される。判定の偏り（verbosity/self-preference/position/authority bias）と pairwise 二回入替平均を強調。
  • Claude: MADR/Y-statement の具体フィールドにマップ。insufficient_evidence 第三ラベルを足し「不確実→keep（保守）」へルーティング。evidence_quote は ADR ドライバー節に逐語一致を要求しパーサ層で reject（curse-of-knowledge bias 対策）。Rulers の versioned/hashed/immutable バンドル。

設問2 — 降格 vs 却下の安全な区別

合意点（3モデル）

  • 不変条件: in-scope なら常に却下（FN=0 最優先）／out-of-scope かつ具体委任ありなら降格（注記付きパス）／out-of-scope かつ委任なしは in-scope 扱いで却下。（OpenAI が3分岐を明文化、Claude が I1〜I4 として定式化、Gemini は fail-open/inclusion-biased として同じ帰結）
  • 降格した指摘は消さず追記/保存（OpenAI=Consequences/audit log 記録、Claude=append-only follow_up_required artifact、ADR の append-only 慣行に整合）。

相違・固有の指摘

  • Claude: 「可逆性非対称トレランス」— two-way door 決定は委任の許容度が高く、one-way door（不可逆）は委任バーを上げる（名指し target に加え rollback/KPI 明記を要求）。閾値緩和が FN=0 を壊す理由を causal-judgment 文献（Skepticism Trap / Scaling Paradox）で接地。
  • OpenAI: 「last responsible moment」決定先送りの実務に整合させる。決定間の「インターフェース契約」（決定 A が X、B が Y を扱う）として委任を検査。
  • Gemini: 「Weakest Link Upper Bound（WLNK）」— 直列依存チェーンの集約信頼度は最も懐疑的な検証器を超えられない（Γ(S) ≤ min(S)）。1 つでも異常を検知したら自動実行を停止する数学的定式化。conflict 未解決時はinclusion（人間レビュー/脅威扱い）にデフォルトして FN を最小化。

設問3 — 委任の具体性ゲートと spec-gaming 防止

合意点（3モデル）

  • 「out-of-scope, 下流で対応」を受理する条件は具体性と機械検証可能性。target_id が ADR グラフで解決すること、target がその懸念をカバーする自分のドライバーを持つこと、現 ADR がその懸念を解決済みと主張していないこと。
  • spec-gaming（「とりあえず out-of-scope と貼れば通る」）は Goodhart 則の典型。委任ごとに正当化（名指し owner / 根拠引用）を必須にして「ただ貼る」を高コスト化する。

相違・固有の指摘

  • OpenAI: スコープメタデータとの自動 cross-check（Must ドライバーに含まれる懸念を out-of-scope と貼ったら機械的に検出して override）。プロンプトに「out-of-scope と貼れば通る」報酬シグナルを出さない設計。
  • Claude: 攻撃文献を直接接地 — punctuation-only 応答が GPT-4o を 35%、Thought process: 等の opener が一部 OSS で FP 90% を誘発（master-key 攻撃）。Isomorphic Perturbation Testing (IPT): 同一 finding を実在 target と偽 target に委任して critic の出力が分岐するか検証。adversarial 学習データ（空委任・存在しない ID・非カバー ID・循環委任）。
  • Gemini: より広く reward hacking（evaluator tampering が natural run の約 50% で発生・RewardHackingAgents ベンチ）と specification gaming（チェスエンジン hack / o1 Docker escape）を一般原理として提示。machine-readable GDR/FPF の Formality Level で「証拠の厳密さ」に応じた reliability ceiling を課す。

設問4 — 同一 critic 内包 vs 専用 classifier

合意点（3モデル）

  • 役割分離（生成 vs 批評／スコープ vs 実質判定）は有益だが、ただ役割を割るだけでは検証は保証されない。同一モデル/類似プロンプトの critic は相関エラー（同じ盲点で同じ誤りに合意）を起こす。independence が鍵。

相違・固有の指摘

  • OpenAI: 結論はハイブリッド — メイン LLM がスコープ推論し、軽量 classifier/ヒューリスティックでその結論を二重チェック（veto 可能）。Flamehaven 引用で「verification が multi-agent 最大の失敗源・類似モデルは同じ誤答に合意（agreement bias）」を強調。
  • Claude: 既定は1 LLM コール内で構造化出力（scope と undermining を独立判定）＋決定論的 post-condition 層（DeepEval の DAGMetric 流）。スコープ精度が律速になって初めて別モデルへ。multi-agent は production で 41-87% 失敗・79% は coordination/spec 問題（同一モデルの critic は「コーヒー休憩後の自己レビュー」）。
  • Gemini: 異なる基盤モデルで独立推論する「inclusion-biased conflict resolution」— 不一致時は構造化議論（de-hallucination）→未解決なら inclusion にデフォルト。実証で FN 率約 1%。ただし「コインフリップ」論文の警告（safety judge は systematic failure を共有し near-unanimous でも人間 ground truth と乖離）も併記すべき点は Claude も指摘。

設問5 — 検証と FN=0 回帰

合意点（3モデル）

  • aggregate accuracy/F1 は不適。must-keep クラス（in-scope ∪ ambiguous）の recall=1.0 を一次指標にし、回帰でデプロイブロック。FP 削減は副次。
  • golden にロックケース型を網羅: ①in-scope→keep ②out-of-scope＋名指し target→downgrade ③out-of-scope＋target なし→keep（保守）④scope-metadata 矛盾/曖昧→keep（保守）。プロンプト/モデル変更のたびにオフライン回帰。
  • 判定の安定性テスト（同一入力を複数 run して不変か）。

相違・固有の指摘

  • Claude: ⑤adversarial/spec-gaming プローブ→keep＋alert（100% 検知）、⑥**code-verifiable→他象限へ routing（100%）**を追加。golden は人間ラベル 100-200 例で 85% 一致から開始・各クラス最低 ~20 例。multi-judge 合意は confidence escalator であって substitute でない。希少クラスは PR-AUC。
  • OpenAI: テスト群を「FN=0 を lock-in する safety net」と位置づけ。プロンプト例の storage-location ADR を回帰ケース化（DR 計画欠如で却下しないことを assert）。バグ→新テストの TDD 運用。
  • Gemini: judge の 7メトリクス ensemble（Cohen's κ 等の inter-rater reliability・偶然一致でないことの確認・golden に対する precision/recall）。「95% accuracy でも希少 critical で recall 0%」の罠。cascaded 二段（高 recall・低 precision の AI フィルタ → 高 precision の決定論スクリプト/人間 triage）。

合意度サマリ: 設問1=高、設問2=高、設問3=高（攻撃事例の具体性は各モデル固有）、設問4=中（分離は合意、内包1コール vs 別モデルで方針が分かれる）、設問5=高。

推奨機構（FN=0 を壊さない統合設計）

3モデルの提案を統合した推奨アーキ。Claude の post-processor 不変条件を骨格に、OpenAI の3分岐と二重チェック、Gemini の inclusion-default を取り込む。

[1] ADR ingestion → Scope Card 派生
    （MADR フィールド: decision_question / must_drivers[] / should_drivers[] /
      considered_options[] / independent_reversibility / rollback_kpi /
      stakeholders・owner / downstream_adrs[]・follow_ups[] / typed relations）
              │  ※ versioned + hashed
              ▼
[2] Cross-Validation Critic（単一 LLM コール・DAG/構造化出力）
    入力: Scope Card（hash 済）＋ finding ＋ locked rubric（hash 済）
    出力（schema-locked JSON, 構造化デコード）:
      scope_verdict: in_scope | out_of_scope | insufficient_evidence
        evidence_quote: <ADR ドライバー節からの逐語>
      （out_of_scope のとき）delegation:
        target_id / target_kind(existing_adr|spike|create_request)
        coverage_argument: <target からの逐語>
      premise_undermines_axis: <Must軸ごと yes|no|insufficient_evidence>
        per_axis_evidence: <ADR span>
              │
              ▼
[3] 決定論的 Post-Processor（= FN=0 のフロア。LLM ではない）
    1. JSON schema 不正?            → KEEP
    2. evidence_quote 逐語不一致?    → KEEP
    3. いずれかの Must軸 undermines=yes? → KEEP（scope 判定を上書き）
    4. scope == in_scope?           → KEEP
    5. scope == insufficient?       → KEEP
    6. target_id がグラフで未解決?   → KEEP
    7. target が自分のドライバー＋rollback_kpi を持たない? → KEEP
    ── ここに到達した時のみ ──       → DOWNGRADE
              │
              ▼
[4] append-only re-home: follow_up_required artifact を ADR グラフに生成。
    元 finding は trace に残す（消さない）。
              │
              ▼
[5] 曖昧/不一致時のエスカレーション: insufficient や cross-check 不一致は
    人間レビューへ（Gemini=inclusion default / OpenAI=human oversight）。

依拠する不変条件（invariants）

  • I1 保守デフォルト: malformed・parse 失敗・欠落・insufficient_evidence はすべて keep。降格に至る唯一の経路は post-processor の全ゲート通過。
  • I2 軸 undermining の優越: いずれかの Must軸が undermines=yes なら、scope 判定に関わらず keep。critic が in-scope を out-of-scope と誤分類しても、軸を正しく捉えていれば取りこぼさない。
  • I3 append-only 保存: 降格 finding は削除せず follow_up_required として名指し target に紐付け（ADR の append-only 慣行に整合）。silent loss を防ぐ。
  • I4 名指し target ＋ coverage: 降格には target_id がグラフで解決し、target が当該懸念をカバーする自分のドライバーを持ち、target からの evidence_quote があること。1 つでも欠けたら keep。
  • I5 逐語 evidence: in-scope/out-of-scope の主張はすべて、引用元（ADR ドライバー / target coverage）に文字単位で一致する引用を含む（Rulers の evidence-anchored 規律）。
  • I6 versioned/hashed rubric: ルーブリック＋スコープカード schema を hash し、判定ごとに hash を保存。ルーブリック変更は golden 全回帰をトリガー。
  • I7 委任は外部検証器で: target 解決・evidence 文字列検証・必須フィールド検査はすべて LLM 外の決定論コード（LLM-Modulo）。
  • I8 非対称回帰ゲート: must-keep クラスの FN 回帰があればデプロイブロック。FP 削減は副次。
  • I9 可逆性非対称バー（Claude 固有・推奨採用）: one-way door 決定は委任バーを上げる（名指し target に加え rollback/KPI 明記を必須）。
  • I10 二重チェック / inclusion default（OpenAI・Gemini 固有・推奨採用）: スコープ結論をヒューリスティックで veto 可能にし、cross-model 不一致や曖昧は人間へ inclusion デフォルト。

out-of-scope を捨てず re-home する不変条件: I3＋I4。委任先が存在し自分のドライバー/rollback を持つ時のみ降格し、その finding は follow_up_required として保存され下流 ADR 作成をゲートする。委任先が無い out-of-scope は I4 で keep（＝ in-scope 扱いの却下）に倒れる。

委任先の具体性ゲート（spec-gaming 防止）: I4＋I7＋adversarial golden（後述）。target_id がグラフで解決しなければ keep。実在 target と偽 target で出力が分岐するか IPT で検証。空委任・存在しない ID・非カバー ID・循環委任を golden に入れて critic を鍛える。

FN=0 を保つ二重ゲート: ①LLM 層（軸ごとの構造化判定）と ②決定論 post-processor 層（I1〜I7）。真に premise を毀損する finding がすり抜けるのは「I2/I5/I1 がすべて同時に破れる」場合のみで、いずれも単体テスト可能なコードレベル不変条件。プロンプトドリフトや spec-gaming に対し、プロンプト上の「バー」より頑健。

文献根拠（URL）

検証戦略（golden データセットと FN=0 回帰）

3モデルの提案を統合したケース型と固定方法。

クラスground truth必須挙動ロック基準
in-scope, underminesfinding が当 ADR の Must軸を毀損keep（却下）recall = 1.0（FN=0）
out-of-scope, 名指し target＋coverage懸念が具体リンクされた下流 ADR（自分のドライバーでカバー）に属すdowngrade＋follow_up_required 発行downgrade の precision ≥ 目標値
out-of-scope, target なし懸念は下流だが具体オーナー不在keep（保守）recall = 1.0（FN=0）
scope-metadata 矛盾/曖昧ドライバー矛盾 or 軸を跨ぐkeep（保守）recall = 1.0（FN=0）
adversarial / spec-gaming プローブ偽 target_id・循環委任・逐語捏造keep＋alert100% 検知
code-verifiable findingコード読みで解決可他象限へ routing100% routing

FN=0 の固定方法（3モデル統合）

  • 一次指標は must-keep クラス（in-scope ∪ ambiguous ∪ target なし）の recall。回帰したらデプロイをブロック（I8）。aggregate accuracy/F1 は使わない。希少クラスは PR-AUC（Claude/Gemini）。
  • golden は人間ラベル 100-200 例で 85% 一致から開始、各クラス最低 ~20 例（Claude）。プロンプト例の storage-location ADR（DR/index/timestamp-authority を理由に却下しない）を回帰ケース化（OpenAI）。
  • ルーブリック＋プロンプト＋スコープカード schema を hash して判定に紐付け（I6）。変更ごとにオフライン全回帰。
  • adversarial プローブは IPT（同一 finding を実在/偽 target に委任し分岐を確認）で spec-gaming を回帰検知（Claude）。
  • multi-judge 合意は confidence escalator として使い、不一致→keep/人間。ただし「合意＝正しさ」ではない（コインフリップ論文の警告）。判定の安定性（同一入力 複数 run で不変）も検査。
  • judge 自体の品質は 7メトリクス ensemble（Cohen's κ 等）で検証可（Gemini）。
  • バグ→新テストの TDD で golden を living spec として育てる（OpenAI）。

注: 当リポの cross-val golden は非決定性で FN=0 単発ゲートが ~80% で偽 FN を出す既知の flake がある（[[crossval-golden-fn0-flaky]]）。本戦略の「複数 run / majority-vote」は既存宿題と整合。

ADR-0119（code-verifiable 象限）との関係

3モデルとも「スコープ委任問題」と「code-verifiable 問題」は直交する別象限と明言した。

  • 証拠の型が違う: code-verifiable は interpreter / test runner / 文字列一致で真偽が確定する事実主張。スコープ委任は「この懸念は storage ADR の問題か、下流 operations ADR の問題か」という決定境界の ontological 主張で、実行可能オラクルが無い。証拠は「決定アーティファクトとそのドライバーのグラフ」であってランタイム挙動ではない（Claude が最も明確・OpenAI/Gemini も同旨）。
  • 機構が違う: code-verifiable は決定論ツールを呼び LLM は coordinator（CRITIC/RLVR 流の tool-grounded critique）。スコープ判定は machine-readable スコープカードに anchor した構造化判定 critic で、外部コードは post-condition checker（target 解決・evidence anchoring・schema 検証）に留める。
  • パイプライン上の層が違う: code-verifiable はスコープゲートより前に解決でき、スコープゲートは残った substantive-judgment findings に対して動く。

統合 vs 独立 ADR の示唆: 両象限は別 ADRが妥当。ADR-0119 が code-verifiable 象限（verify_in_code + evidence、Phase B 観測専用統合済）を扱うのに対し、本 RQ-098 は scope-delegation 象限として独立 ADR で起案するのが自然。RQ-097 の「1 ADR=1 決定／4発散シグナル（ドライバー・可逆性・オーナー・KPI が分かれたら割る）」に照らしても、両者はドライバーも検証戦略も異なるため分割側。ただし両ゲートは CV パイプライン内で**直列（code-verifiable を先に処理 → 残余をスコープゲート）**に配線する点は共通設計として 1 つの実装に同居しうる。

未解決・要追加調査（3モデルが答えきれなかった点）

  1. substantive-judgment FN の下限: 推奨設計は「委任起因の FN」をゼロにするが、critic が全 Must軸を自信を持って誤って undermines=no と出すケース（人間なら yes）は残る。この残余 FN は critic の素の recall に束縛され、回帰ゲート I8 でしか監視されない。critic 自体の recall 向上策（モデルアップグレード・substantive 軸での multi-judge）は本調査の範囲外（Claude が明示）。
  2. 委任先の時間的妥当性: 下流 ADR が「十分早く」着手されるかの判定は LLM 知識を超える。OpenAI は target status（proposed/accepted）をメタデータに入れて目安にするが、確実な機構は未確立。
  3. inclusion default のコスト: Gemini の fail-open は FN を下げるが FP/人間レビュー負荷を増やす（false positive paradox）。曖昧ケースをどこまで人間に回すかの運用閾値は調査で決め切れていない。
  4. 内包1コール vs 別モデル classifier の実証比較: 設問4 は方針が割れた（Claude=1コール既定、OpenAI=ハイブリッド二重チェック、Gemini=cross-model）。当パイプラインでどちらがスコープ精度・コストで優位かはオフライン実測待ち（合意なし）。
  5. 委任の coverage 判定の自動化: 「target のドライバーが当該懸念を本当にカバーするか」の relevance 判定自体が小型 scope-classifier を要し、その classifier の検証が再帰的に必要になる点の解は提示されていない。

References（3モデル統合・重複排除）

LLM critic の限界 / 外部検証器

LLM-as-judge / ルーブリック設計

spec-gaming / reward hacking / judge fooling

safety-critical / 非対称損失の judge 信頼性

multi-agent / 役割分離 / 失敗モード

ADR 実務（1決定・ドライバー・follow-up・supersession・グラフ）

評価指標 / 非対称損失 / オフライン回帰

Gemini 固有（GDR / FPF / 産業事例）

  • Governance Decision Records / First Principles Framework（scope metadata・Formality Level・WLNK 不変量） — Gemini 生結果 §References [10][11] 参照（Vertex grounding redirect URL は生結果 docs/research/rq-098-result-gemini.md に収録）。
  • 産業事例: Meta RADAR（Risk Aware Diff Auto Review）/ Web3 smart-contract auditing（Slither + AI 文脈レビュー）— 同上、生結果 §Sources [8][38]。

完全な URL（Gemini の Vertex grounding redirect 含む）は各生結果 docs/research/rq-098-result-{openai,gemini,claude}.md の References / Sources 節を参照。