ADR-0135: Decision Pipeline の審査深度を mode で階層化する

• Status: Accepted
• Mode: Standard
• Kruchten Type: Executive/Property
• Scope: platform
• Implementation Status: In Progress (残スコープ = 下記訂正注記の差分 3 点のみ。主要施策は ADR-0102 で実装済み)
• 起案者: [email protected]
• 起案日時 (JST): 2026-06-11 14:08
• 承認日時 (JST): 2026-06-21
• Deciders: [email protected] (単独)

訂正とスコープ縮小 (2026-06-11・amends ADR-0102)

本 ADR の起案後に、同一テーマの先行決定 ADR-0102「Decision Pipeline の審査深度を mode で階層化する (低ステークス ADR の過剰審査是正)」が 2026-06-02 にフェーズ①〜③まで実装完了済みであることが判明した (起案時の整合性チェック Gate 2 は重複を検出できなかった)。

1. 事実訂正: §1.2「mode が分岐させるのは採点閾値だけ」は 2026-05-29 抽出の telemetry と当時のコード認識に基づく分析であり、現在は成立しない。Light の Gate3 スキップ (LIGHT_SKIP_GATE3)・Gate1 盲点 cap critical/high 5 件 (LIGHT_GATE1_CAP)・採点 sampling_n=1 (LIGHT_SAMPLING_ONE) は ADR-0102 により実装済み・既定 ON で本番稼働中。triage の golden↔プロンプト矛盾 (テンプレ/メタデータ追加の Light 化) も 0102 フェーズ①で解消済み (prompt v1.2.0)。
2. 残スコープ (差分 3 点): (a) 週次事後不具合率集計 + 閾値超過時の issue 自動起票 (撤退条件の自動検知) (b) triage 出力のスキーマ検証 (盲点 #2・許可値外で pipeline 停止) (c) 事前検証ゲート (i)(ii) は ② 実装済みのため「事後検証」として実施を別途判断。
3. 保留 (達希判断事項): §決定の「単カラム追加・閾値/設定の外出し・プロンプト微修正を Light に確定」は、ADR-0102 フェーズ①の排他的除外リスト (高ステークス領域は外見が小さくても Light 禁止・達希判断・golden 22〜24 で固定) と正面衝突するため、明示判断があるまで実施しない。

コンテキスト

§1.1 背景

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

§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。

§1.3 課題

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

§1.4 制約・要件

• mode 階層は採点閾値以外 (Gate1/Gate3/sampling) にも分岐を持たせる必要がある (実装事実より)。
• triage プロンプトと golden.jsonl の整合性を取る (CI 合格閾値 0.85 を維持)。
• Standard/Critical の審査内容は現状維持 (安全側)。
• 段階導入と事前検証ゲートで誤分類率を実装前に定量化する (5% 閾値)。
• ADR-0071 (情報提供型盲点検出)・ADR-0056 (sampling 戦略)・ADR-0084 (mode別閾値) と整合。

§1.5 目標 (To-Be)

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

決定

mode を「採点閾値の違い」から「審査深度 (コスト) の階層」へ意味付け直し、両輪で実装する。(1) Light を実効的に軽くする: Gate3 並列レビュー (3モデル) を省略、Gate1 盲点検出を critical/high のみ・最大 5 件に cap (dedupeGroup 活用)、採点 sampling_n=1 固定。Standard = 現状維持、Critical = フル審査 + 高 sampling。(2) triage を低ステークスに発火させる: golden↔プロンプトの矛盾を解消し、メタ ADR のうち可逆かつパターン準拠の変更 (テンプレ/セクション追加・メタデータ追記・単カラム追加・閾値/設定の外出し・プロンプト微修正) を Light と確定。可逆性・影響範囲 (blast radius) の判定を triage 基準に追加し、ルール5 を「可逆かつ影響限定なら Light 優先」に補正。設計原則: Light は真に可逆・影響限定な案件のみ、迷ったら Standard。

判断基準 (Decision Drivers)

3.1 評価軸

K.O. criterion: Must 軸 (#efficient, #suitable) の score < 3 は不採用。

3.2 評価軸 × 案スコア表

採択案を最終選定 (Must 軸満点、加重和最高)。案 E は K.O. 通過するが採択案より効果が劣り、撤退条件から接続する次案として保留。

検討した代替案 (Alternatives Considered)

• 案 A (現状維持: 均一審査を継続): 審査コストと churn が ADR 量に比例して増え続ける。#efficient/#suitable の Must を満たさず不採用。
• 案 B (triage 基準だけ直して Light を発火させる): mode は採点閾値しか変えないため、Light を選んでも審査コストは 0 円も下がらない (実装事実)。効果ゼロの罠。単独では不採用。
• 案 C (採点閾値の調整のみ): 却下 churn の一部は減るが、重いゲートは全 mode で走り続け審査コストは不変。部分対策で不十分。
• 案 E (ルールベースの静的 triage フィルタ): ファイルパス・diff 規模・変更種別による決定的分類。確率的誤分類が無い利点はあるが、ADR は自然言語の起案で対象パスが確定していない段階のものが多く、静的特徴だけでは可逆性・影響範囲を判定できないケースが残る。採択案の後の境界ケース誤分類が続く場合の次案として撤退条件から接続。

影響 (Consequences)

§5.1 正の影響 (Good)

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

§5.2 負の影響 (Bad)

• Light 経路の実装分岐が graph に増え、保守対象が増える。
• triage の誤分類 (本来 Standard を Light に落とす) リスクが新たに発生。
• Light 経路で Gate3 をスキップすると 3 モデル並列によるバイアス相互補正が消え、誤分類した Standard 相当 ADR が単一モデル・単一サンプルのみで審査される (盲点 [high] #3)。31 run 規模では誤分類率 5% 以下でも 1〜2 件が誤分類圏に入る。既存 31 run の parallel_review 結果から「Gate3 が Gate1 で検出されなかった critical/high 指摘を初出した件数と割合」を集計し、独自寄与率が 0 でない場合は Light でも Gate3 を単一モデルに縮退する代替を実装スコープで再検討する。

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

• Light 誤分類による見逃し: 可逆と誤判定した案件が浅い審査で通る → Light は「真に可逆・影響限定」に限定し、迷ったら Standard。Light 分類 ADR の事後不具合率を監視。
• Gate1 cap で重要盲点を捨てる: critical/high 優先 + dedupeGroup で重要度順に残し、cap は Light のみ適用 (Standard/Critical はフル)。
• ADR-0071 (情報提供型盲点検出) の意図との整合: Light の cap が「情報提供」を過度に削がないか確認。
• Light 比率 KPI による基準なし崩し緩和リスク (盲点 [high] #4): Confirmation の Light 比率 20% を「達成すべき KPI」から「参考指標」に格下げし、Light 分類 ADR の可逆性判定を月次で第三者 (別モデルまたは別担当者) がサンプル監査する手順を Confirmation に追加。
• ゲート (ii) の認知的アンカー (盲点 [high] #7): 一回限りの静的検証である旨を明示し、導入後 4 週・8 週の telemetry レビュー時に Light run の Gate1 盲点内容を人間がサンプル確認する手順を撤退条件の判定フローに組み込む。
• 案 E のパス情報実測未取得 (盲点 [medium] #8): telemetry の 31 run について「ADR テキストにファイルパス・diff 規模・変更種別が明示されていた割合」を実測し、ルールベース pre-filter で Light 確定できる割合を定量化する追加調査を案 E 転換時の前提とする。
• telemetry バックエンドの並列書き込み (盲点 [medium] #9): Sheets を使っている場合、Light 経路初稼働前に mode 別集計クエリの duration_ms 精度を検証する手順を実装スコープに追加 (バックエンド実装の明記含む)。

撤退条件 (Rollback Plan)

• Light 分類 ADR の事後不具合率 (マージ後 4 週以内の修正 PR 発生率) が Standard 比 1.5 倍超、かつ累積 5 件に達したら即時 Light 停止 (graph 設定で全件フル審査へ戻す・~5 分)。検知は週次自動集計が行い、閾値超過で GitHub issue を自動起票する (人手の紐付け・目視に依存しない)。
• 導入後 8 週時点で Light 比率がほぼ 0 のまま (triage が結局 Light を出さない) → triage 基準を再設計、または本施策を撤回。
• 事前検証ゲート (i) の誤分類率が 5% 超 → ② 以降を凍結し、triage 基準を再改修してから再測定 (LLM 改修後も誤分類が続く場合は案 E のルールベース静的フィルタへ転換)。
• 判定: 4 週ごとのレビュー (担当: 達希)。telemetry の mode別 duration_ms・盲点件数・却下率・Light 比率で観測。
• 事後不具合率の自動集計の仕組み: 週次 CI スクリプトが merged PR のタイトル・本文から ADR 番号 (ADR-\d{4}) を抽出し、telemetry の triage_mode (Light/Standard) と突合して「ADR ごとのマージ後 4 週以内の修正 PR 件数」を mode 別に集計。telemetry スキーマへの追加は不要 (既存の triage_mode と PR メタデータの突合のみ・実装 ~0.25 人日を本コストに計上)。
• PR↔ADR 番号抽出の事前精度検証 (盲点 [high] #5): スクリプトのリリース前に過去 merged PR 全件に対して抽出率を実測し、抽出できなかった PR 件数を telemetry に「未突合件数」として記録する列を追加 (実装スコープに追記)。

実装スコープ

• やること: graph の Light 分岐 (Gate3 スキップ / Gate1 cap / sampling_n=1)、triage プロンプトの基準改修 (golden との矛盾解消＝メタ可逆変更を Light に確定 + 可逆性・影響範囲判定の追加)、golden への同種 Light ケース追補、telemetry に mode別審査コストを観測できる集計。
• やらないこと (Non-Goals): ADR 正規構造へのコスト/実装スコープ節の追加 (別軸・別 ADR。やるとしても対立審査でなく adr-lint の存在チェックとして)。section-alignment ADR (align) との統合。Critical の審査内容の見直し。triage モデルの確定的な差し替え (必要なら別途 golden 正解率で評価する実験タスクとして切り出し)。
• 段階化: ①triage 基準改修＋golden 整合 (プロンプト/データのみ・低リスク・golden 正解率で検証) → 事前検証ゲート 2 つ (①の後・②の前。どちらかが落ちたら ② に進まない) → ②Light の Gate3 スキップ → ③Gate1 cap・sampling 固定、と段階導入し各段で telemetry を確認。
• 事前検証ゲート (i) — Light 誤分類率の実装前実測: 新 triage 基準で過去の実トラフィック (telemetry 全 31 run + 直近の Standard 判定 ADR 20 本) をドライラン再分類し、Light 判定になったものを人間がラベル付け (可逆/不可逆・影響限定/横断) して誤分類率 (Standard 相当 → Light) を実測。誤分類率 5% 以下でなければ ② に進まない。
• 事前検証ゲート (ii) — Gate3 の過去価値確認 (盲点 [critical] #1 反映): ドライランで Light 判定になった過去 run について、Gate3 指摘が最終的な ADR 修正 PR の diff に反映されているかを突合し、反映件数と未反映件数を記録する方式に変更 (単純な「0 件確認」ではなく、Gate3 の独自寄与の偽陰性検出を含む)。空集合だけで Gate3 スキップの安全性を結論しない。
• triage 出力のスキーマ検証 (盲点 [critical] #2 反映): triage ノードの出力を Zod 等でスキーマ検証し、許可値 (Light / Standard / Critical) 以外は即時エラーとして pipeline を停止する防御コードを graph 入口に追加。大文字小文字ゆれ・null 伝播で Standard が Gate3 を逃げる事故を防ぐ。
• Light 分岐の統合テスト: mode='Light' 固定注入で「Gate3 スキップ・Gate1 cap・sampling_n=1」の 3 条件同時成立を CI 検証。逆向き (mode='Standard' 固定で Gate3 が必ず実行される) も同テストで検証。
• Gate3 独自寄与率の集計 (盲点 [high] #3 反映): 既存 31 run の parallel_review 結果から「Gate3 が Gate1 で検出されなかった critical/high 指摘を初出した件数と割合」を集計し、ADR の定量根拠に追加。0 でない場合は Light で Gate3 を単一モデルに縮退する代替を採用。
• 実行環境の明記 (盲点 [high] #6 反映): 事前検証ゲート (i)(ii) および golden eval CI の実行環境 (GAS / GitHub Actions / ローカル等) を明記。GAS 上で動かす部分があれば 6 分以内に収まることを実測値で示す。Pipeline は GAS 外。
• telemetry バックエンド検証 (盲点 [medium] #9 反映): telemetry バックエンドの実装 (スプレッドシート/DB) と並列書き込みの有無を明記。Sheets の場合は Light 経路初稼働前に mode 別集計クエリの duration_ms 精度を検証。

コスト試算

(粗い概算 / 個人開発: 達希 + Claude Code 補助)

• 追加 LLM コスト: なし。むしろ削減方向 — Light ADR ごとに Gate3 の 3モデル呼び出しと盲点フル生成を節約。仮に起案の 3〜4 割が Light になれば、その分の Gate3+Gate1 コストが消える。
• GAS 実行時間: 増分なし (Pipeline は GAS 外)。
• 起案者負担: なし (triage が自動判定)。

Confirmation

• 検証手段:
  1. triage golden 評価 (20 件・合格閾値 0.85) が基準改修後も pass し、Light 正解ラベルのケース (テンプレ/セクション追加・メタデータ追記) の正解率が 100% になること (golden↔プロンプト矛盾の解消確認)。
  2. telemetry に mode 別の審査コストが記録されること: Light run で Gate3 スキップ・盲点件数 ≤ 5・sampling_n=1 が観測できる (Standard/Critical はフル審査のまま)。
  3. 導入後 8 週で新規 run に占める Light 比率 ≥ 20% (現状 0%・31 run 全て Standard)。ただし本項目は「達成すべき KPI」ではなく「参考指標」とし (盲点 [high] #4 反映)、未達でも triage 基準の緩和方向の改修は行わない。かつ Light 1 run の所要時間が Standard 比 50% 以下 (現状平均 ~6.7 分)。
  4. Light 分類 ADR の事後不具合率 (マージ後 4 週以内の修正 PR 発生率) が Standard 比 1.5 倍以下であること。週次自動集計 (PR↔ADR 番号突合) が稼働し、閾値超過時の issue 自動起票が機能していること。PR↔ADR 番号抽出率を事前実測し、未突合件数を telemetry 列に記録すること。
  5. 事前検証ゲートの実施記録が残っていること: (i) ドライラン再分類の誤分類率実測値 (≤ 5% で ② 解禁) と (ii) Light 相当過去 run での Gate3 指摘が ADR 修正 PR diff に反映されているかの突合結果 (反映件数と未反映件数)。
  6. Light 分類 ADR の可逆性判定を月次で第三者 (別モデルまたは別担当者) がサンプル監査し、基準を満たさないものが 0 件であること (盲点 [high] #4 反映)。
  7. triage ノード出力の Zod スキーマ検証が CI で稼働し、許可値外で pipeline 停止することの統合テストが pass すること (盲点 [critical] #2 反映)。
  8. 導入後 4 週・8 週の telemetry レビュー時に Light run の Gate1 盲点内容を人間がサンプル確認する手順が記録に残ること (盲点 [high] #7 反映)。
• 実行頻度: golden eval はプロンプト変更 PR ごと (CI・FN=0 ゲート)。事後不具合率の集計は週次 (自動)。telemetry レビューは 4 週ごと (撤退条件の判定と同時)。第三者サンプル監査は月次。
• 違反時対応: 撤退条件の該当判定を行う (8 週で Light 比率ほぼ 0 → triage 基準再設��または撤回 / 事後不具合率 Standard 比 1.5 倍超かつ累積 5 件 → 即時 Light 停止 / ゲート (i) 誤分類率 5% 超 → ② 凍結し再改修、改修後も続けば案 E へ転換)。

参照 (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) の出所。導入後の効果検証も同テレメトリで行う。
  • section-alignment ADR (draft id align) / cost-scope 案: いずれも本 ADR とは別軸 (構造の話)。本 ADR は審査深度の話で、スコープを分離する。
• 関連 PR/Issue: -
• 外部資料: -