• Status: Accepted
  • Mode: Standard
  • Kruchten Type: Existence/Property
  • Scope: platform
  • Implementation Status: Done (PR #1057)
  • 起案者: [email protected]
  • 起案日時 (JST): 2026-05-27 15:21
  • 承認日時 (JST): -
  • Deciders: [email protected] (単独)

コンテキスト

1.1 背景 (Background)

ADR 評価 Pipeline には Gate 1 (Blind-spot Detection) と Gate 4 (Scoring) が含まれるが、両者は独立して動作している。Gate 1 が critical な盲点を検出していても、その盲点が Must 評価軸の根拠を毀損しているか否かは Gate 4 の採点には反映されない。

1.2 現状 (Current State / As-Is)

Gate 4 は ADR 文面の品質 (記述の充実度) を 50 点満点 × N=5 Self-Consistency で評価し、Gate 1 は盲点を「情報提供型」(ADR-0071) として findings 列挙するに留まる。両ゲートの突き合わせは人間レビュアーに委ねられている。

1.3 課題 (Problem)

ADR-0076 で具体的に発生した事象:

  • bge-m3 の日本語専門用語ドメイン品質が未検証 (critical, revise_adr) であるにもかかわらず、#suitable (Must, ×2.0) にスコア 5 が付与され 42/50 で通過。
  • Blind spot #1 は「セマンティック検索による発見性」という #suitable の中核要件の前提が実証されていないことを指摘しており、#suitable = 5 は希望値であって実測値ではない。
  • Blind spot #6 (overlap 閾値・30-50% 削減根拠の欠如) も #suitable の「既調査スコープ削減」要件の根拠を毀損。
  • #efficient (Must) も blind spot #4 (reindex 動的コスト未計上)・#5 (Vectorize 次元数上限) で Free tier 前提が検証されていない。

つまり「Must 軸に高スコアが付くが、その前提自体が critical 盲点で実証されていない」状態が Gate 4 を素通りする。

1.4 制約・要件 (Constraints & Requirements)

  • Gate 4 (50 点満点 × N=5 Self-Consistency) のプロンプト・採点ロジックは変更しない (既に安定稼働)。
  • Gate 1 の「情報提供型」設計思想 (ADR-0071) を維持する (Gate 1 自身は差戻し権限を持たない)。
  • Pipeline 全体のレイテンシ増加は async 実行内に収め、UX 影響を最小化する。
  • LLM 呼出追加のコスト増は月数百円規模に抑える。

1.5 目標 (Goals / To-Be)

Gate 4 通過後・Gate 2 (Consistency) 前に「Blind-spot × Must Cross-Validation Gate」を挿入し、critical 盲点が Must 軸の前提を毀損している ADR を自動差戻しする。Non-Goals: Should/Medium 軸への critical 適用、毀損の程度スコアリング、Gate 1 の recall 改善。

決定

Gate 4 (Scoring) 通過後・Gate 2 (Consistency) 前に「Blind-spot × Must Cross-Validation Gate」を新設する。本ゲートは以下を行う:

  1. Gate 1 の blindSpotFindings から severity=critical かつ actionability=block または revise_adr の findings を抽出。
  2. ADR 本文の評価軸テーブルから Must 軸 (重要度に [Must] を含む) とそのスコアを抽出。
  3. 各 critical finding が Must 軸の前提を毀損しているかを LLM (claude-opus, T=0.2) で判定。
  4. 毀損していると判定された場合、「どの盲点がどの Must 軸のどの前提を毀損しているか」を具体的に指摘して差戻し。

差戻しメッセージ例:

盲点 #1 (bge-m3 ドメイン品質未検証) が #suitable (Must, スコア 5) の前提を毀損しています。bge-m3 の MRR@5 オフライン評価を実施し、結果を ADR に追記した上で再投入してください。

通過条件:

  • critical + block/revise_adr の findings が存在しない → 通過
  • critical findings があるが Must 軸の前提を毀損していない → 通過
  • critical findings が Must 軸を毀損している → 差戻し

差戻しメッセージには「Gate 4 のスコアリングは ADR 文面の品質を評価するものであり、記述内容の検証済み度合いは評価しない。本ゲートは盲点検出結果と評価軸の整合性を検証する」旨を併記する。

判断基準 (Decision Drivers)

3.1 評価軸 (Q42 9 タグから選定)

#重要度 (係数)案件特有の解釈
1#reliable[Must] (×2.0)未検証仮定での Must 軸高スコア通過を防止し、ADR 判断の信頼性を担保できるか
2#suitable[Must] (×2.0)Gate 1 findings と評価軸を交差検証するという本ゲートの目的に適合しているか
3#maintainable[High] (×1.0)Gate 1 スキーマ変更・プロンプト改訂に対する保守容易性
4#efficient[High] (×1.0)LLM 呼出追加によるコスト/レイテンシが許容範囲か
5#operable[Medium] (×0.5)false positive 認定・撤退判定の運用容易性

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

3.2 評価軸 × 案スコア表

係数採択案 (新ゲート)案 A (Gate 1 即差戻し)案 B (Gate 4 に findings 注入)
#reliable×2.0422
#suitable×2.0523
#maintainable×1.0342
#efficient×1.0354
#operable×0.5333
加重和 (正規化)0.7550.5780.533
K.O. 通過 (Must ≥3)❌ (#reliable=2)

検討した代替案 (Alternatives Considered)

  • 案 A: Gate 1 で critical + revise_adr/block → 即差戻し — 不採用理由: 評価軸との関連を考慮しない粗い判定。Medium 軸への critical でも差戻されるため false positive が高い。Gate 1 の「情報提供型」設計思想 (ADR-0071) を崩す。
  • 案 B: Gate 4 の scoring prompt に Gate 1 findings を注入 — 不採用理由: Gate 4 の採点基準 (ADR 文面の品質 = 「書かれているか」) と Gate 1 の盲点検出 (外部リスク = 「検証されているか」) は評価視点が異なる。1 つの prompt に混ぜると各々の精度が低下。既に 50 点満点 × N=5 Self-Consistency で安定している Gate 4 のプロンプトを変更するリスクが大きい。

影響 (Consequences)

5.1 正の影響 (Good)

  • 未検証の仮定で Must 軸を高スコアに盛った ADR が通過しなくなる。
  • 差戻し時に「どの盲点がどの Must 軸を毀損しているか」を具体的に指摘するため、起案者の修正箇所が明確。
  • Gate 1 の盲点検出が「情報提供」から「根拠検証」に昇格し、Pipeline 全体の判断品質が向上。

5.2 負の影響 (Bad)

  • LLM 呼出 1 回追加 (claude-opus T=0.2、~$0.04/ADR、月 15 ADR で $0.60/月)。
  • Pipeline レイテンシ +10-20 秒 (async 実行内なので UX 影響小)。
  • Gate 4 で合格した ADR が cross-validation で差戻される体験は起案者にとって予想外。
  • 盲点 #1 由来 (critical): 本ゲートの核心判定は T=0.2 の単一 LLM 呼出であり、Gate 4 の N=5 Self-Consistency と比較して精度・再現性が劣る可能性がある (要追記: N=3 以上の Self-Consistency 適用、過去 ADR 10 件以上でのオフライン precision/recall 測定、(ADR_id, findings_hash) キャッシュ、false negative 率の追跡)。
  • 盲点 #2 由来 (critical): 「前提毀損」の判定基準が未定義であり、(a)直接引用否定のみか (b)間接的仮定揺動も含むかでプロンプト設計次第の恣意的判定リスクがある (要追記: 毀損判定基準をルールベース 3 段階で定義 / 差戻しメッセージに citation 付与 / 監査トレイル出力)。
  • 盲点 #3 由来 (critical): Gate 1 出力のスキーマドリフト (critical→CRITICAL、actionability 列挙値拡張等) で抽出ロジックが 0 件を返し、サイレントに全 ADR を通過させる無音バグが発生しうる (要追記: JSON Schema/Zod による厳格バリデーション、想定外値で error 停止、Gate 1 と本ゲート間の Contract Test)。
  • 盲点 #4 由来 (high): 本ゲートは Gate 1 の recall に上限を持ち、Gate 1 が見逃した盲点はそのまま通過する。「ゲート通過=安全」という誤信を醸成するパラドックスのリスク (要追記: メッセージに「LLM 自動判定はドメイン専門家レビューの代替ではない」明記 / 事後インシデントレビューで Gate 1 検出可否を遡及追跡)。
  • 盲点 #6 由来 (high): 起案者が「この軸は Must ではなく Should」とラベリングすることで本ゲートの審査を意図的に回避できる構造的抜け穴がある (要追記: Must/Should 分類が起案者設定に依存することの限界を明記 / 将来検討として Should 軸毀損が総スコア 15% 超を占める場合の警告補助判定)。
  • 盲点 #7 由来 (high): Gate 4 合格後の二重障壁が起案者の心理的コストを上昇させ、「口頭決定→後付け ADR」迂回文化の逆選択を招くリスク (要追記: 3 ヶ月間 ADR 提出数・差戻し率・口頭決定インシデント数のトラッキング / 統計的有意な減少時のフォールバックポリシー)。
  • 盲点 #8 由来 (medium): 差戻しメッセージが「何を書けば通過するか」を示し、小規模・非代表的データセットでの形式的追記による形骸化を誘発しうる (要追記: 再投入時に Gate 1 が当該 finding の解消を再評価する差戻しループ収束条件 / 検証の最低品質基準を定義不能ならばリスクとして明記)。

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

  • 盲点 #5 由来 (high): false positive 撤退条件「3 件連続」の運用定義 (認定主体・「連続」の定義・SLA) が曖昧で、政治的対立または文化的抑圧のいずれかを招くリスク (要追記: 起案者 issue 起票 → 72 時間以内にゲート管理者が独立レビュー → Slack 公開、月次 false positive 率ダッシュボード、撤退条件評価とは別の月次モニタリング)。
  • 盲点 #9 由来 (medium): 運用開始後に「high もカバー」「Should 軸も」「毀損度 0-100 スコア」等の機能追加要求が累積し、ゲート肥大化・精度低下・レイテンシ増加を招くスコープクリープリスク (要追記: 判定スコープを critical × Must のみに明示固定、スコープ変更は別 ADR 必須、追加要求はバックログ化し 3 ヶ月評価で一括判断)。
  • 過去 ADR との関係:
    • ADR-0071 (Gate 1 盲点検出エンジン): Extends — Gate 1 の findings を差戻し判定に活用。
    • ADR-0056 (temperature/sampling 戦略): Confirms — 新ゲートの temperature は 0.2 (判定安定性重視)。
    • ADR-0019 (Decision Pipeline): Confirms — ゲート追加による Pipeline 強化。

撤退条件 (Rollback Plan)

  • 判定指標: false positive (正当な ADR が不当に差戻される) が 3 件連続で発生した場合、ゲートを skip-through に設定。
  • 判定タイミング: 3 ヶ月後 (2026-08)。
  • 代替案: skip-through 設定後、案 B (Gate 4 への findings 注入) を再検討するか、Gate 1 の判定基準を厳格化する方向で再設計。
  • 補足 (要追記): false positive 認定フロー (起案者 issue 起票 → ゲート管理者の独立レビュー → Slack 公開、SLA 72 時間) を別途明文化する必要がある。「連続」の定義 (calendar 日 or ADR 提出順) も要確定。false negative 指標も撤退条件の評価対象に追加することを推奨 (盲点 #1)。

Confirmation (準拠確認 / Fitness Function)

  • 検証手段:
    1. 自動: Pipeline 実装時に、本ゲートのユニットテストで「critical+Must 毀損 findings を含む ADR fixture が差戻される」「critical あるが Must 毀損なしの fixture が通過する」「critical なしの fixture が通過する」の 3 ケースを必須化。
    2. 自動: Gate 1 出力 JSON に対する Zod スキーマバリデーションを CI に組み込み、スキーマドリフト発生時に Contract Test が fail する (盲点 #3 対応)。
    3. 自動: 過去 ADR 10 件以上を用いたオフライン precision/recall 評価をリリース前に実施し、結果を ADR 追記 (盲点 #1 対応)。
    4. 手動: 月次で false positive 率・false negative 率・ADR 提出数・差戻し率・口頭決定インシデント数をダッシュボード化し、ゲート管理者がレビュー (盲点 #5, #7 対応)。
  • 実行頻度:
    • ユニットテスト・Contract Test: 全 PR / 全 Pipeline 実行時。
    • オフライン評価: 本ゲート初回リリース時 + プロンプト変更時。
    • 月次モニタリング: 毎月第 1 営業日。
    • 撤退条件評価: 2026-08。
  • 違反時の対応:
    • ユニットテスト fail: PR マージブロック。
    • Contract Test fail: Pipeline をエラー停止 (サイレント通過防止)。
    • false positive 3 件連続: skip-through 化 (撤退条件)。
    • ADR 提出数の統計的有意な減少: 適用範囲限定フォールバック (Must 軸スコア ≥4 かつ critical findings ≥2 の場合のみ発動等) を発動。

参照 (References)

  • 関連 ADR:
    • ADR-0071 (Gate 1 盲点検出エンジン) — Extends
    • ADR-0056 (temperature/sampling 戦略) — Confirms
    • ADR-0019 (Decision Pipeline) — Confirms
    • ADR-0076 (本 ADR の直接的動機となった事例)
  • 関連 PR/Issue: (要追記)
  • 外部資料: (要追記)