ADR-0102: Decision Pipeline の審査深度を mode で階層化する (低ステークス ADR の過剰審査是正)

• Status: Accepted
• Mode: Standard
• Kruchten Type: Executive/Property
• Scope: platform
• Implementation Status: In Progress (フェーズ①②③ 実装完了 2026-06-02。本番 telemetry 8 週観測中・〜2026-07-28。観測指標=コスト削減率 ≥40% / Light 比率 ≥30% / 月間誤分類 ≤8 件)
  • 詳細: 必須前置ゲート完了 (2026-06-02): ①却下事後分析 PASS (実却下 53 件中 過剰審査 36=68%/avg45.1、提案品質 15=28%/avg38 → 過剰審査が主因と確証、Light 化続行可。queries/adr-0102-rejection-analysis.sql)。②Gate3 モデル独立性 = 高 (Gemini/Claude/o3 の 3 ベンダー × 3 視点 → フェーズ② Gate3 省略の前提充足)。フェーズ① 完了 (2026-06-02): gate0-triage プロンプトに排他的除外リスト追加 (高ステークス→Light 誤分類を防止) + テンプレ/メタデータ追加を Light に整合 + 会計 Critical を請求/決済/税検証まで拡張。golden eval ランナー新設 (tools/triage-eval/) で安全優先ゲート (FN=0 かつ Critical 降格=0) を測定: accuracy 23/26=88.5%・FN=0・Critical 降格=0 で PASS。フェーズ② 完了 (2026-06-02): Light モードで Gate3 (parallel_review の 3 モデル並列レビュー) を省略 (parallel_review.ts で early-skip、グラフトポロジは不変＝graph-check/.mmd 無傷)。LIGHT_SKIP_GATE3 flag (既定 ON、"false" でロールバック=Light→Standard フォールバック)。コスト削減効果 (Light run の duration_ms/LLM 呼出数 ≥40% 減) は本番 telemetry で観測。フェーズ③ 完了 (2026-06-02) → ADR-0102 実装完了: Light の Gate1 盲点を dedupeGroup 単位で critical/high 最大 5 件に cap (socratic.ts capLightBlindSpots_、cap 後 severity 分布 + critical/high ゼロ run フラグを telemetry 記録)、Light の Gate4 sampling を 1 に固定 (scoring.ts)。LIGHT_GATE1_CAP / LIGHT_SAMPLING_ONE flag (既定 ON、"false" でロールバック)。
• 起案者: [email protected]
• 起案日時 (JST): 2026-06-01
• 承認日時 (JST): 2026-06-02
• Deciders: [email protected] (単独)

Pipeline 迂回の経緯（監査用注記）: 本 ADR は Decision Pipeline で Standard 46-47/50 と合格点に達したが、Cross-Validation が 2 連続差し戻しした。round 1 は #reliable × critical「Light 誤分類の定量上限が未提示」で、起案テキストに排他的除外リスト + 月間誤分類期待値（月 5.3 件・許容上限 8 件）を追加して対処した。round 2 は その追加した排他的除外リストそのものを「静的定義では実トラフィックを捌けず構造的に誤分類が続く」と新 critical で攻撃し、さらに「3 モデル並列レビューの訓練データ独立性が未検証だから Gate3 省略の安全根拠が崩れる」で #efficient(5)・#reliable(4) の 2 Must を同時毀損、critical 数が 1→3 に発散した。ゴールポストが前回の修正箇所へ移動し収束しない、graph-check (ADR-0100)・stop-button (ADR-0101) と同型の構造的過剰審査である。要求された「3 モデル独立性の検証」は実装時にしか実証できず、9 盲点すべては実装スコープ・撤退条件・Confirmation に captured 済。本 ADR は審査深度の階層化そのものを定義する meta-ADR であり、過剰審査ループで止まり続けるのは自己矛盾であるため、ADR-0100/0101 の前例に倣い Pipeline を迂回し通常 PR で起案する（代表取締役判断 2026-06-01）。#efficient/#reliable の self-score は「実証済みの担保」でなく「pin/CI/段階ゲートで managed なリスク」に正直化した（5→4 / 4→3、K.O. は Must≥3 で通過）。Pipeline retroactive validation（ADR-0052）は任意。

コンテキスト

§1.1 背景

Decision Pipeline は全 ADR を高ステークス前提の対立的審査(Gate1 盲点検出 DA+PM+Judge / Gate3 3モデル並列レビュー / Gate4 採点)に均一にかけており、低ステークスな ADR が過剰審査されている。ADR 起案ペースが上がる(直近 2.5 週で 68 件 docs/adr 到達)ほど、この固定費と再投入 churn が線形に膨らむ。

§1.2 現状 (As-Is)

定量根拠 (D1 telemetry_records, 32 record / 31 run / 269 blind-spot findings, 2026-05-29 抽出):

さらに実装上の事実 (src/nodes/scoring.ts:137): mode が分岐させるのは採点閾値だけ (Light 35 / Standard 40 / Critical 45)。Gate1 盲点検出 (socratic.ts)・Gate3 並列レビュー (parallel_review.ts)・sampling_n はいずれも mode 非依存。つまり Light に分類されても審査コストは一切下がらず、パスバーが 5 点下がるだけ。

triage 基準の事実 (prompts/production/gate0-triage/prompt.md): ルール5「判断に迷ったら Standard を既定値とする」+ Standard の例示が本プロジェクトの実トラフィックそのもの(「新規メタデータフィールド導入」「Pipeline ノードのプロンプト改修」「モデル swap」「新規セクション追加」)。単カラム追加 (ADR-0086/0087) や CI 設定変更まで構造的に Standard へ流れる。

実例: テレメトリに 1 カラム足す ADR-0086 が 4 run、CI の pnpm→corepack 移行が critical 盲点付き Standard、Gate4 閾値外出しが 3 run。規模に対し審査が重すぎることがデータで明白。

さらに基準自体の矛盾 (prompts-eval/datasets/gate0-triage/golden.jsonl): triage の golden 評価データ (20件、合格閾値 0.85) は「ADR テンプレに Confirmation セクション追加」「ADR テンプレに Kruchten 3分類ラベル追加」を Light と正解ラベル付けしているのに、triage プロンプトは「新規セクション追加」を Standard 例示に挙げている。golden(Light)とプロンプト基準(Standard)が真っ向から矛盾しており、プロンプトに忠実なモデルほど Light の golden ケースを Standard と誤答する。低ステークス案件が Light に発火しない構造的原因はモデルでなく基準の矛盾にある(モデル swap だけでは直らない)。低分散の要因は ①プロンプト基準(最有力)②temperature 0.2 + seed 42(意図的低分散)③モデル の 3 つ。

§1.3 課題

限界の正体は「低ステークス ADR の審査コストを下げる仕組みが存在しない」こと、かつ「triage の Light 基準が golden と矛盾し発火していない」こと。起案ペース 27 件/週・churn 2.3 倍・固定 8.7 盲点/run が線形に積み上がる。

§1.4 制約・要件

• 個人開発体制 (代表取締役 + Claude Code 補助)、実装合計は数人日規模に収まること。
• 高ステークス ADR の審査品質 (Gate1 critical/high 盲点・Gate3 並列レビュー) は維持すること。
• 既存 telemetry (telemetry_records) と golden eval (prompts-eval/datasets/gate0-triage) を検証手段として活用できること。
• Light 経路導入によって不可逆・横断・データ/契約に触れる ADR が浅い審査を通らないこと (安全側に倒す)。
• ADR-0084 (mode別閾値の KV 外部化)・ADR-0071 (Gate1 を情報提供型に再定義)・ADR-0056 (sampling 戦略) と整合すること。

§1.5 目標 (To-Be)

mode を「採点閾値の違い」から「審査深度(コスト)の階層」へ意味付けし直し、Light を実効的に軽く・triage を低ステークスに発火させる。Non-Goals: ADR 正規構造へのコスト/実装スコープ節の追加、section-alignment ADR との統合、Critical の審査内容の見直し、triage モデルの確定的な差し替え。

決定

Light を実効的に軽くする (Gate3 並列レビュー省略 / Gate1 盲点を critical/high のみかつ最大 5 件に cap / sampling_n=1 固定) のと、triage 基準の矛盾を解消する (golden↔プロンプト整合 + 排他的除外リスト [データスキーマ変更・外部システム連携・認証認可・課金ロジックは自動 Standard 以上] + 可逆性・影響範囲判定の追加) を両輪で実装する。Standard は現状維持、Critical はフル審査 + 高 sampling。Light は「真に可逆・影響限定」な案件のみに限定し、迷ったら Standard に倒す。

ただし Light での Gate3 省略は「3 モデル並列レビューの独立性評価」をフェーズ②着手前の必須ゲートとし、独立性が低い場合は Gate3 省略を見送る (下記実装スコープ・撤退条件)。

判断基準 (Decision Drivers)

Pipeline コスト / ガバナンス系。重み: Must ×2.0 / High ×1.0 / Medium ×0.5。

3.1 評価軸

K.O. criterion: Must 軸 (#efficient / #reliable) いずれかで score < 3 の案は不採用。

3.2 評価軸 × 案スコア表

加重和 = Σ(score × 係数) / (5 × Σ係数)、Σ係数 = 5.5。採択案のみ K.O. 通過。採択案の #efficient は当初 self-score 5 だったが、コスト削減効果が Gate3 独立性評価の結果に条件づく managed な見込みであることを反映し 4 に、#reliable も除外リストの完全性が実トラフィックで継続検証する managed risk であることを反映し 3 に正直化した (いずれも K.O. 通過)。

検討した代替案 (Alternatives Considered)

• 採択案 (両輪): Light の実効軽量化(Gate3 省略 / Gate1 cap / sampling_n=1) と triage 基準の矛盾解消(golden↔プロンプト整合 + 排他的除外リスト + 可逆性・影響範囲判定)を同時に実装。片方だけでは効果が出ない。
• 案A (triage 基準のみ修正、ゲートは軽くしない): golden↔プロンプト矛盾を解消し Light を発火させるが、ゲートは現状のまま。却下: Light に分類されても「閾値が 5 点下がるだけ」で審査コストは不変(scoring.ts:137 の構造問題が残る) → #efficient=2 で K.O.。ただし「triage 改修のみで効果の大半が得られる可能性」を受け、フェーズ①完了後にデータで graph 改修の ROI を再確認する条件付き段階化を実装スコープに織り込む。
• 案B (Light 分岐ゲートのみ実装、triage 基準は放置): graph に Light 軽量分岐を作るが triage 基準は据え置き。却下: golden↔プロンプト矛盾で Light が発火しない(実績 31/31 Standard) → 軽量化分岐が死蔵し効果ゼロ、#efficient=1 で K.O.。
• 案C (現状維持): 個別 PR で churn を吸収し続ける。却下: churn 52%・固定 8.7 盲点/run が起案ペース増(2.5 週で 68 件)で線形悪化 → #efficient=1 で K.O.。
• 案D (mode 階層化せず全 mode 一律で盲点 cap): 全 ADR の盲点を一律 cap して軽量化。却下: 高ステークス ADR の critical 盲点まで捨て見逃しリスク → #reliable=2 で K.O.。

実装スコープ

• やること: graph の Light 分岐(Gate3 スキップ / Gate1 cap / sampling_n=1)、triage プロンプトの基準改修(golden との矛盾解消＝メタ可逆変更を Light に確定 + 排他的除外リスト + 可逆性・影響範囲判定の追加)、golden への同種 Light ケース追補、telemetry に mode別審査コストを観測できる集計。さらに以下を実装スコープに含める:
  • triage 判定理由の記録: 「なぜ Light と判定したか(可逆性の根拠・影響範囲の評価・排他的除外リストの適用結果)」を telemetry または ADR メタデータに記録し、判定の透明性を確保(black box 化と引き継ぎ者の混乱を防ぐ。監査追跡可能性への対応も兼ねる)。
  • review_mode メタデータの付与: Light 経路で承認された ADR ドキュメントに review_mode: Light 等の審査 mode を明示し、審査深度が通常より浅いことを将来の読者が識別できるようにする。ADR テンプレートに mode 記載欄を追加。さらに信頼性格差の制度化・scope shrinking への対応として、(a) Light ADR を前提とする Standard/Critical ADR は前提部分を再検証する義務を持つ運用ルール、(b) 同一日・同一起案者の複数 Light ADR の関連性チェック (scope shrinking 検知) を監視 KPI に追加。
  • Light 分岐条件式の mode 別ユニットテスト CI 必須化: Standard/Critical が Light 経路へ迷い込まないこと(デフォルト値・null/undefined 伝播・enum タイポによる意図せぬ Light 降格)を CI で必須チェック。段階導入の各フェーズで telemetry の triage_mode 分布を前フェーズと比較し、Standard 比率の異常減少をアラートとして検知。
  • socratic.ts 出力 schema の severity 必須化: critical/high が出力されない異常を検知するバリデーション + cap 後の severity 分布を telemetry に記録 + Light run で critical/high ゼロ run が連続した場合のアラート(cap 後に低品質盲点だけが残る逆転現象の検知)。
  • Gate3 並列レビューのモデル独立性評価: Light で Gate3 を省略する前提として、Gate3 の 3 モデルが異なる訓練元か、または diverse なプロンプト戦略を使っているかを確認しモデル合意の独立性を評価する。独立性が低い場合 Light での Gate3 省略は「審査コスト削減」でなく「唯一の多様性担保を除去」になるため、フェーズ②着手前の必須ゲートとする。フェーズ①の却下 16 件事後分析に「却下 ADR のうち Gate3 のみが検出した盲点が決定打になったケース数」を分析項目として追加。
  • 却下 16 件事後分析を Light 化着手の必須ゲートに: フェーズ①完了時点で却下 16 件を「審査過剰起因／提案品質起因／別の設計課題起因」に分類し、Light 化で防げる比率を定量化する。分析結果は telemetry ダッシュボードに記録し Confirmation KPI に追加。提案品質起因が主因と判明した場合は Light 化でなく起案者向けプレチェックリスト整備への方針転換を撤退条件として明示。Light 経路の承認率 (Light run のうち Pass した割合) を Standard 比で継続監視し、著しく高い場合は「審査が機能していない」シグナルとして扱う。
  • 排他的除外リストのドメイン特化と継続更新: 汎用カテゴリ(データスキーマ変更・外部連携・認証認可・課金ロジック)に加え、本プロジェクト固有のドメイン(Pipeline ノード・triage 基準・golden データ・telemetry スキーマ・採点閾値・審査ロジック)を明示。「他の ADR の採否基準・審査品質・データ蓄積に影響する変更」「メタ ADR (Pipeline 自体を変更する ADR)」を Light 対象外として除外リストに組み込む。除外リストにバージョン番号と最終更新日を付与し、4週レビュー時に「リスト外で Standard に修正された案件」を収集して継続更新するフィードバックループを運用に組み込む。各カテゴリに具体的な判定クエリ(例: 下流クエリから参照されるカラム名が変わるか)を付与し LLM 依存部分を最小化。
• やらないこと (Non-Goals): ADR 正規構造へのコスト/実装スコープ節の追加(別軸・別 ADR。やるとしても対立審査でなく adr-lint の存在チェックとして)。section-alignment ADR (align) との統合。Critical の審査内容の見直し。triage モデルの確定的な差し替え(必要なら別途 golden 正解率で評価する実験タスクとして切り出し)。
• 段階化: ①triage 基準改修＋golden 整合(プロンプト/データのみ・低リスク・golden 正解率で検証、完了期限 1 週、却下 16 件事後分析と Gate3 モデル独立性評価を同梱) → ②Light の Gate3 スキップ(完了期限 3 週、フェーズ① の事後分析と独立性評価で go 判定後に着手) → ③Gate1 cap・sampling 固定(完了期限 5 週)、と段階導入し各段で telemetry を確認。各フェーズに完了定義と期限を明記し telemetry ダッシュボードで進捗を可視化、期限超過時は理由を記録し次回 4 週レビューで有効性評価に含める。フェーズ②③遅延時の暫定措置として、明らかな軽微 ADR を手動 Light フラグで投入する運用をあらかじめ定義する。フェーズ① 完了から 3 週以内にフェーズ②未着手の場合、Light 分類を自動的に Standard にフォールバックする機能フラグを実装し、triage 改修だけが先行して審査品質が低下するリスクを防ぐ。

コスト試算

(粗い概算 / 個人開発: 代表取締役 + Claude Code 補助)

• 追加 LLM コスト: なし。むしろ削減方向 — Light ADR ごとに Gate3 の 3モデル呼び出しと盲点フル生成を節約。仮に起案の 3〜4 割が Light になれば、その分の Gate3+Gate1 コストが消える(Gate3 独立性評価で省略が安全と確認された前提)。
• GAS 実行時間: 増分なし(Pipeline は GAS 外)。
• 起案者負担: なし(triage が自動判定)。
• 最悪ケース試算: triage 改修が不発・Light 比率 10% 未満が 8 週継続 → 撤退の場合、実装 2〜3 人日 + 撤退対応 0.5 人日 ≈ 最大 3.5 人日が純損失、検証期間 8 週。一方の現状維持コストは、起案ペース 68 件/2.5 週 ≈ 27 件/週が維持される前提で 8 週に約 216 件 × 平均 6.7 分 × churn 2.3 倍 ≈ 約 55 時間の Pipeline 稼働が確定発生。最悪ケースでも撤退後は現状維持コストに戻るのみで、ROI 下限は「埋没 ≤ 3.5 人日 vs 効果不発」。この下限が許容できる範囲であることを撤退条件の早期判定(フェーズ① 1 週で Light 発火確認)で担保する。

影響 (Consequences)

§5.1 正の影響 (Good)

• 低ステークス ADR の審査コスト(時間・LLM)が実際に下がり、起案ペース増に耐えられる。
• churn 52% の一因(過剰な盲点・厳しい一律審査)が Light 経路で緩和。
• mode が「閾値の飾り」から「実際の意味を持つ階層」になり、運用の納得感が上がる。

§5.2 負の影響 (Bad)

• Light 経路の実装分岐が graph に増え、保守対象が増える。
• triage の誤分類(本来 Standard を Light に落とす)リスクが新たに発生。
• Light 経路で承認された ADR が将来「Pipeline が承認した」として引用される際、審査深度の差が読者に伝わらないリスク(→ review_mode メタデータ付与 + 引用時の前提再検証ルールで緩和、実装スコープ参照)。
• review_mode メタデータの存在自体が将来の外部監査で「不十分な変更管理」と指摘されるリスク → triage 判定理由の必須記録 + 年次サンプル事後監査で緩和。

§5.3 中立・トレードオフ (Neutral / Trade-offs)

• Light 誤分類による見逃し(定量管理): 可逆と誤判定した案件が浅い審査で通る → Light は「真に可逆・影響限定」に限定し、排他的除外リスト(データスキーマ変更・外部連携・認証認可・課金ロジック + プロジェクト固有ドメイン + メタ ADR → 自動 Standard 以上)でルールベースに先に絞り、残余のみ LLM 判定。月間誤分類期待値を定量化して管理する: 起案ペース 68 件/2.5 週 ≈ 117 件/月、Light 比率目標 30%、golden 正解率 0.85(誤分類率 15%)とすると、誤分類期待値 ≈ 117 × 0.30 × 0.15 ≈ 月 5.3 件。**許容上限を月 8 件(期待値の約 1.5 倍)**とし、これを 2 ヶ月連続で超えたら triage 基準を再設計する。除外リスト漏れによる追加誤分類は継続更新フィードバックループで吸収する。Light 分類 ADR の事後不具合率も併せて監視。
• Gate1 cap で重要盲点を捨てる: critical/high 優先 + dedupeGroup で重要度順に残す設計とし、cap は Light のみ適用(Standard/Critical はフル)。socratic.ts の severity 必須化 + cap 後 severity 分布の telemetry 記録 + critical/high ゼロ run 連続のアラートで、重要盲点が dedupe/cap で消える逆転現象を検知。
• Gate3 モデル合意の独立性: Light で Gate3 を省略する前提として 3 モデルの訓練元独立性を評価。独立性が低ければ Light での Gate3 省略は多様性除去に等しいため、フェーズ②着手前の必須ゲートとする。
• 却下率 52% の真因の不確実性: 「過剰審査」が主因という断定は要検証。フェーズ①完了時点で却下 16 件を「審査過剰で落ちた／提案の質の問題／別の設計課題」に分類する事後分析を実施し、Light 化で防げる比率を確認してからフェーズ②③に進む。提案品質起因が主因と判明した場合は Light 化でなく起案者プレチェックリスト整備へ方針転換。Gate1 盲点 8.7 件/run のうち起案者が「有用」と評価した件数も計測し cap 値(例 5 件)の根拠とする。
• 排他的除外リストの過少設計: 汎用 4 カテゴリのみではプロジェクト固有依存(下流ダッシュボード参照、webhook 連携、メタ ADR の審査性質変更)を捌けない → ドメイン特化カテゴリの追加 + 4週レビューでの継続更新フィードバックループ + 判定クエリ付与で緩和。
• フェーズ②③の永続先送りリスク: triage 改修だけが先行し graph 改修が動かないと triage 改修コストが埋没 → フェーズ① 完了から 3 週内にフェーズ②未着手なら Light 自動 Standard フォールバックの機能フラグで防御。
• golden 過適合リスク: golden 20 件への過適合で実トラフィック誤分類が改善しない可能性(golden で 0.85 達成しても実 run の Light 比率が 5〜10% 止まり)。実トラフィックの Light 分類 ADR を週次で人手スポットチェックする定性 KPI を併用し、golden を実トラフィックから継続補充して代表性を維持する。
• ADR-0071(盲点検出を情報提供型に再定義)の意図との整合: Light の cap が「情報提供」を過度に削がないか確認。

撤退条件 (Rollback Plan)

• Light 分類 ADR の事後不具合率(マージ後の修正 PR 発生率など)が Standard 比で有意に上昇 → Light をフル審査に戻す。
• 月間誤分類件数が許容上限(月 8 件)を 2 ヶ月連続で超過 → 排他的除外リストと triage 基準を再設計。
• 導入後 8 週時点で Light 比率がほぼ 0 のまま(triage が結局 Light を出さない) → triage 基準を再設計、または本施策を撤回。フェーズ① 1 週で Light が発火し始めるかを早期確認し、不発なら基準を即見直す。
• フェーズ①の却下 16 件事後分析で「提案品質起因」が却下の主因と判明 → Light 化でなく起案者向けプレチェックリスト整備へ方針転換。
• フェーズ②着手前の Gate3 モデル独立性評価で 3 モデルの訓練元独立性が低いと判明 → Light での Gate3 省略を見送り、別軸 (Gate1 cap・sampling のみ) で軽量化を限定。
• Light 経路の承認率 (Light run のうち Pass した割合) が Standard 比で著しく高い → 「審査が機能していない」シグナルとして閾値超過で撤退判定。
• triage 改修直後の 2 週間は telemetry の Light 分類 ADR を毎日サンプリングして人手スポットチェック(改修直後に誤分類が集中するリスクへの早期検知)。Light 比率が 1 週間で 30% を超えた場合を「急上昇アラート」として自動通知し、内容確認を義務付ける。
• 判定: 4 週ごとのレビュー(担当: 代表取締役)。telemetry の mode別 duration_ms・盲点件数・却下率・Light 比率・Light run の severity 分布・Standard 比率の異常減少・Light 承認率で観測。

Confirmation

観測可能 KPI で判定する(複数指標併用)。

• Light 比率 ≥ 30%(導入 8 週後、telemetry triage_mode 分布。現状 0%)。triage 基準矛盾解消が効いた指標。
• Light run の審査コスト削減 ≥ 40%(Light run の duration_ms / LLM 呼出数を Standard 比較。Gate3 省略 + Gate1 cap の実効指標)。フェーズ②完了の必須ゲートとして扱う。
• gate0-triage golden 正解率 ≥ 0.85(Light / Critical ケース含む。現状は golden↔プロンプト矛盾で Light を誤答)。
• 実トラフィックの Light 分類 ADR の人手スポットチェック妥当性 ≥ 90%(週次定性チェック、golden 過適合対策)。
• 月間誤分類件数 ≤ 8 件(許容上限、期待値 5.3 件の約 1.5 倍。超過 2 ヶ月連続で基準再設計)。
• Light 経路で critical/high 盲点ゼロ run の連続発生なし(cap 設計の健全性)。
• mode 別経路の正しさ: Light 分岐の mode 別ユニットテストが CI で pass し、Standard/Critical が Light 経路へ迷い込まないこと。
• Light 誤分類の事後不具合: Light 分類 ADR のマージ後修正 PR 発生率が Standard 比で有意に上昇しない(8 週後の事後レビュー)。
• 却下 16 件事後分析の telemetry ダッシュボード記録: フェーズ①完了時に分類結果を記録し Light 化着手の必須ゲートとする。
• Light 承認率の Standard 比: 著しく高い場合は審査機能不全シグナルとして閾値超過で撤退判定。
• 検証手段: telemetry の mode別集計 + golden eval(prompts-eval/datasets/gate0-triage) + 週次の人手スポットチェック + 月次の事後不具合レビュー + Light 分岐 mode別ユニットテスト(CI 必須) + 4 週レビューでの排他的除外リスト継続更新。実行頻度: telemetry 集計と人手スポットチェックは週次、golden eval は改修時、4 週ごとの mode別レビュー、8 週時点の総合判定。違反時対応: 撤退条件を発動(Light をフル審査に戻す or triage 基準再設計 or プレチェックリスト整備へ方針転換)。フェーズ②③の期限超過は理由記録の上、次回 4 週レビューで有効性評価に反映し、フェーズ① 完了 3 週以内にフェーズ②未着手なら Light 自動 Standard フォールバック機能フラグを発動。

参照 (References)

• 関連 ADR:
  • ADR-0084(Gate4 スコアリング閾値の KV 外部化 / mode別閾値): 本 ADR は mode の意味を「閾値」から「審査深度」へ拡張する。閾値の mode別管理は維持し、effort も mode別にする上位互換。
  • ADR-0056(LLM temperature/sampling 戦略): Light で sampling_n=1 固定とする点が関係。整合を確認。
  • ADR-0071(Gate1 socratic を盲点検出エンジン=情報提供型に再定義): Light の盲点 cap がこの「情報提供」意図を損なわないこと(critical/high を優先保持)を前提に設計。
  • ADR-0086 / ADR-0087(telemetry v3): 本 ADR の定量根拠(blind_spot_findings / triage_mode / duration_ms)の出所。導入後の効果検証も同テレメトリで行う。
  • ADR-0100 / ADR-0101(Pipeline 迂回の前例): 本 ADR も Cross-Validation の構造的過剰審査(2 連続差し戻し)を理由に同じ迂回判断を取る。
  • section-alignment ADR(draft id align) / cost-scope 案: いずれも本 ADR とは別軸(構造の話)。本 ADR は審査深度の話で、スコープを分離する。
• 関連 PR/Issue: -
• 外部資料:
  • src/nodes/scoring.ts:137 (mode別閾値の現実装)
  • prompts/production/gate0-triage/prompt.md (triage 基準)
  • prompts-eval/datasets/gate0-triage/golden.jsonl (golden 評価データ)
  • src/nodes/socratic.ts / src/nodes/parallel_review.ts (mode 非依存ゲート)