ADR-0194: ADR-0056 の Gate 0 seed 固定前提を撤回

• Status: Superseded (2026-07-03 · superseded_by: ADR-0187 · 内容重複起案として ADR-0187 に集約)
• Mode: Standard
• Kruchten Type: Executive/Property
• Scope: platform
• Implementation Status: Not Started
• 起案者: [email protected]
• 起案日時 (JST): 2026-07-03 03:10
• 承認日時 (JST): 2026-07-03
• Approver Role: platform
• Approver Who: [email protected]
• Driver: [email protected]
• Consulted: Decision Pipeline AI 審査 (Gate 0-4)

1. Executive Summary

• 文脈: ADR-0056 §6.5 「T=0 工程は seed:42 + temperature:0.2 固定で再現性確保」前提が、ADR-0157 (Gate 0 Triage provider を gemini-flash に統一) 以降、Gemini API が seed パラメータ未対応のため事実上崩壊している。
• 課題: Gate 0 判定 drift の再現性検証手段が失われた状態で、モデル世代更新時に silent drift が検知されないリスクがあり、ADR-0056 §6.5 と ADR-0157 §決定 の SSoT 整合性が破綻している。
• 対策: ADR-0056 §6.5 を撤回し、temperature:0.0 + top_k:1 で deterministic 化 (案 i) と K=5 回サンプリング + 多数決で mode 判定 (案 ii) の併用戦略に置換する。判定基準は K/K = OK / K-1/K = WARN / K-2/K 以下 = FAIL。
• 効果: seed 不要で ADR-0157 と整合し、Gate 0 drift 検知目的を維持することで ADR-0073 実装先行可能となり、統計的アサーションで silent drift 感度が向上する。
• 代償: 総工数 1.1 人日と月 +$1-2 の LLM cost 増が発生し、K=5 threshold は運用実測後の調整余地が残る。

2. 何を解決するか

2.1 適合性

• ADR-0056 §6.5 の「T=0 工程は seed=42 + temperature=0.2 固定」(PR #1009 で shipped) が、ADR-0157 の「Gate 0 Triage provider を gemini-flash に統一」と Gemini API の seed 未対応 (2026-07-01 時点) により Gate 0 について成立していない。
• ADR-0073 (Gate 0 Triage Seed 固定再現性 回帰テスト · Proposed) の §1.4 制約が「ADR-0056 の seed:42 + temperature:0.2 設定を前提」であるため、前提崩壊で実装着手不可の状態にある。

2.2 信頼性

• モデル世代更新時に Gate 0 判定が silent drift しても検知されない状態で、drp session 26 で本問題を検出するまで露見しなかった。
• 起案者・保守担当が「seed=42 で再現性 OK」と誤認し、drift 検知が working していると思い込むリスクが残る。

2.3 保守性

• ADR-0056 §6.5 と ADR-0157 §決定 の 2 つの SSoT が矛盾したまま docs.bizlp.dev で公開されている。

3. 採用したい方針

3.1 対策方針

ADR-0056 §6.5 を structure-only amend で下記に置換する (本文の判断根拠 §決定 は不変・§6.5 の実装ルールのみ更新)。旧記述「T=0 工程は seed: 42 + temperature: 0.2 固定で再現性を確保する」を撤回し、新記述として T=0 工程 (Gate 0 Triage 等) の drift 検知を deterministic 設定 + K=5 サンプリング + 判定基準の 3 点で担保する形に置換する。ADR-0157 (Gate 0 provider = gemini-flash 統一) と整合を保つため、provider 切替 (Claude/OpenAI) は行わない。

• 適合性: deterministic 設定 (temperature: 0.0 + top_k: 1) で Gemini deterministic decoding を強制 (案 i)。
• 信頼性: K=5 サンプリング (candidateCount: 5) で多数決により mode を判定 (案 ii)。
• 信頼性: 判定基準 K/K 一致 = OK / K-1/K 一致 = WARN / K-2/K 以下 = FAIL で drift を段階検知。
• 保守性: provider 切替なしで ADR-0157 との整合を維持。

3.2 守るべき設計制約

• 保守性: ADR-0157 (Gate 0 provider = gemini-flash 統一) との整合性を維持し、provider 切替を行わない。
• 適合性: ADR-0073 の目的である Gate 0 判定 drift 検知を維持する。
• 効率性: コスト増を月 $2 以下に抑える。
• 柔軟性: K=5 は将来 K=3 に低減可能な設計とし、実測後の cost/信頼性 trade-off で調整できる余地を残す。
• 柔軟性: 判定基準 (K/K / K-1/K / K-2/K) の threshold も初期設定と位置付け、運用実測後の調整余地を残す。

3.3 仕様

• 適合性: Gate 0 Triage 呼出設定 (drp/src/nodes/triage.ts の Gemini API 呼出パラメータ) を temperature: 0.0 / top_k: 1 / candidateCount: 5 とする。
• 信頼性: 判定 script を drp 領分で新設 (drp/src/nodes/gate0_regression.ts)。K=5 回呼出 → mode 集計 → 判定基準適用 → 結果を D1 telemetry (telemetry_records.gate0_regression_result) に記録する。
• 信頼性: 採択前スモークテストとして temperature:0.0 + top_k:1 で同一プロンプトを 10 回逐次呼出し、出力トークン列の完全一致率を実測する。完全一致率が 90% 未満の場合は案 (i) を除外して案 (ii) 単独運用に降格する (§8 撤退条件 3 に分岐明示)。
• 信頼性: Phase 1 で candidateCount:5 の候補間 Jaccard 類似度またはトークン一致率を測定し、類似度が 0.95 超の場合は候補間相関が高すぎるため K 回独立呼出方式に切り替える (§8 撤退条件 6)。
• 信頼性: 意図的に FAIL するダミーケースを golden に 1 件混入し、スクリプトの検知動作を月次 cron 実行時に sanity check する。
• 運用性: 実行タイミングは月次 (cron) + model version 更新時の手動実行。cron 実行結果を Slack (#drp-alerts) に通知し、D1 書込み失敗時は cron を non-zero exit で終了させて CI/CD 側で検知する。
• 運用性: golden データセットは半年ごとにレビューし、新規 edge case を追加する (陳腐化による確証バイアス回避)。
• 信頼性: Gemini API の candidateCount は 1 回のリクエストで K 個の候補を返す挙動が K 回別呼出とほぼ等価となるが、統計的独立性は API 保証依存のため、Phase 1 で candidateCount 方式と K 回別呼出方式の mode 一致率が同等 (差 ≤ 5pt) であることを確認する。
• 保守性: 本 amend 受理後 14 日以内に doc 領分で ADR-0073 amend (frontmatter status: Proposed → Amended · 本文 §1.4 制約を「本 amend §3.3 判定基準の運用実装 (drp/src/nodes/gate0_regression.ts + 月次 cron)」に読み替え) を起票する。未起票の場合は §8 撤退条件 5 として発火し、ADR-0073 amend 起票を blocking issue として起案者・保守担当に escalation 通知し ADR pipeline を停止する (Superseded flip による SSoT 再乖離を回避)。
• 保守性: 上記 ADR-0073 amend 起票 (doc 領分) が完了した後に、drp 領分で drp/src/nodes/gate0_regression.ts 実装 + 月次 cron 設定 + D1 telemetry 追加を行う (§8 撤退条件 4 で 90 日 SLA)。

4. 判断基準

4.1 評価軸

K.O. criterion: Must 軸 (適合性 / 安全性) score < 3 は不採用。

4.2 評価軸 × 案スコア表

加重和分母 = 満点 5 × Σ係数 8.5 = 42.5。案 (ii)+(i) 併用 = 36.5/42.5 = 0.859。案 (iv) は Must 2 軸で K.O. failure。

5. 検討した代替案

• 案 (i) deterministic sampling 単独 (併用に格上げ)

  • 適合性: temperature: 0.0 + top_k: 1 (Gemini) で greedy decoding を強制するが、Gemini 内部 tie-break が deterministic か未検証。
  • 信頼性: 単独採用は却下し、本 amend では (ii) と併用する形で採用。

• 案 (ii) mode 一致率 (K 回サンプリング) 単独 (併用に格上げ)

  • 信頼性: seed 未使用 + temperature: 0.2 のまま K=5 回サンプリング + mode 多数決で判定する。
  • 信頼性: (i) を併用することで deterministic 化を試みつつ、Gemini 内部 tie-break が非 deterministic の場合の fallback として (ii) が動く二重担保となるため、採択案として格上げ。

• 案 (iii) Claude/OpenAI (seed 対応) provider 切替 (不採用)

  • 保守性: ADR-0157 (gemini-flash 統一) と正面衝突し、ADR-0157 amend 起案が別途必要となり LLM Gateway 拡張で複雑化する。
  • 効率性: LLM cost が gemini-flash 比 1 桁高い (Opus/Sonnet)。
  • 使いやすさ: Gate 0 のみ例外化する ADR 新規起案が必要になり、責務分割で保守コスト増。

• 案 (iv) ADR-0073 廃止 + 別軸で drift 検出 (不採用)

  • 適合性: promptfoo eval で cosine similarity 検証等の別軸に置換すると、Gate 0 判定 drift の「回帰テスト」ではなく「similarity 監視」で目的が変質する。
  • 安全性: Gate 0 判定 mode drift が未検知のままモデル更新が進むリスクが残る。
  • 適合性: ADR-0073 目的 (再現性検証) を諦めることになる。

6. 影響

6.1 正の影響

• 保守性: ADR-0056 §6.5 と ADR-0157 の SSoT 整合性が回復し、破綻が解消される。
• 適合性: ADR-0073 が実装先行可能状態に flip する (Proposed → Amended → 実装 In Progress)。
• 安全性: Gate 0 判定 drift 検知の実運用が開始され、モデル世代更新時のリスクが低減する。
• 信頼性: 統計的アサーション (K=5 mode 一致率) は seed 単一回帰より drift 検知感度が高い。
• 使いやすさ: 判定 script は drp/src/nodes/ に閉じ込め可能で、起案者側 (main/doc) は透過。

6.2 負の影響 / リスク

• 効率性: 月 +$1-2 の LLM cost 増 (K=5 倍呼出) が発生する。
• 信頼性: temperature:0.0 + top_k:1 が Gemini 内部で真に deterministic に動く保証がなく、採択前スモークテスト (§3.3) で完全一致率 90% 未満なら案 (i) を除外する必要がある。
• 信頼性: candidateCount:5 は共有 KV cache により候補間相関が高くなる可能性があり、K=5 多数決が実質 K=1 相当の情報量に縮退するリスクがある (§3.3 で Jaccard 類似度測定・§8 撤退条件 6 で独立呼出降格を規定)。
• 信頼性: golden 件数 20 件では検出力が限定的で、10% 程度の低頻度 drift を統計的に有意検知できず、20〜25% 以上の drift 率でないと反応しない (§7.1 に検知限界を明記)。
• 柔軟性: K=5 の判定 threshold は初期設定で、運用実測後の調整余地が残る (§8 で明示)。
• 保守性: 判定 script (drp/src/nodes/gate0_regression.ts) の維持コストが drp 領分に新たな責務として乗る。
• 保守性: Gemini API が将来 seed パラメータを正式サポートした場合、gate0_regression.ts (K=5 多数決) を seed:42 元設計に再置換すべきかの判断が残り、技術的負債の可能性がある (§8 撤退条件 7 で対応)。

7. コスト試算

7.1 前提条件

Golden 20 件の検知限界: 二項分布による検出力計算では、drift 率 10% (2 件/20 件) を 95% 信頼区間で検知するには golden ≥ 100 件が必要 (Fleiss 標本設計標準)。20 件では実質 drift 率 ≥ 20-25% でないと統計的に有意検知できない。golden 拡張案 (50 件) の場合、月次 cost は $2.5-5、100 件で $5-10 と試算される。当面は 20 件のまま運用し、§9 KPI 2 (drift 検知件数) が 12 ヶ月ゼロなら golden 拡張を別 amend で検討する。

7.2 月コスト試算

一回性 (実装コスト): ADR-0056 amend 起案 + Pipeline 通過 = main 側 0.3 人日 / ADR-0073 amend (Proposed → Amended flip · doc 領分) = doc 側 0.1 人日 / Gate 0 script 実装 (drp/src/nodes/gate0_regression.ts) = drp 側 0.5 人日 / 月次 cron 設定 + D1 telemetry 追加 = drp 側 0.2 人日 / 総工数 約 1.1 人日。

定常 (月次 LLM cost 増): K=5 倍呼出 × 月次実行 = +$1-2/月 (許容範囲)。Cost 上振れリスクは K を将来 K=3 に低減で半減可能。

総額 (12 ヶ月): 一回性 1.1 人日 + 定常 12 ヶ月 × $1-2 = $12-24 (誤差レベル)。

8. 撤退条件

1. 判定基準の false positive/negative が 20% 超過 → threshold 再調整を別 amend で起案 (本 amend §3.3 の判定基準を更新)。
2. 月次 LLM cost > $5 → K=5 → K=3 に低減 or cron を月次に降格。
3. 採択前スモークテスト (§3.3) で temperature:0.0 + top_k:1 10 回呼出の出力トークン列完全一致率 < 90% → 案 (i) deterministic 設定を除外し、案 (ii) K=5 サンプリング + mode 多数決の単独運用に降格する。または K=5 中 3 以下しか mode 一致しない状態が Gate 0 全 golden 20 件で 3 ヶ月連続 → 同じく案 (ii) 単独に降格。
4. 本 amend 受理から 90 日経過しても ADR-0073 実装完遂 (drp/src/nodes/gate0_regression.ts + 月次 cron) が Done にならない → ADR-0073 (Amended) を Superseded に flip し、Gate 0 drift 検知は別 ADR で扱う。
5. 本 amend 受理から 14 日以内に ADR-0073 amend (doc 領分 · frontmatter status: Proposed → Amended + 本文 §1.4 制約書換) が起票されない → Superseded flip による SSoT 再乖離 (temperature:0.0/top_k:1/candidateCount:5 のコード残存 vs ADR 撤回の乖離) を避けるため、ADR-0073 amend 起票を blocking issue として起案者・保守担当に escalation 通知し、ADR pipeline を停止する。14 日タイマーは GitHub Issue の due date + adr-lint の scheduled check で自動追跡する (§11 実装配線)。
6. Phase 1 検証で candidateCount:5 候補間 Jaccard 類似度 > 0.95 → 候補間相関が高すぎるため K=5 多数決が実質 K=1 相当になる。K 回独立呼出方式 (candidateCount:1 × 5 回呼出) に切り替え、レイテンシ・cost 上振れ (推定 +$1-2/月) を許容する。
7. Gemini API が seed パラメータを正式サポート → 本 amend を Superseded とし、ADR-0056 §6.5 を再 amend して seed:42 元設計に戻すか gate0_regression.ts の K=5 方式を継続するかを別 amend で判断する。Gemini API 変更ログ監視を月次 cron の観測項目に追加する。

9. Confirmation

1. Gate 0 mode 一致率 K/K ≥ 90% (検証手段: telemetry_records.gate0_regression_result の月次集計 · 実行頻度: 月次 · 違反時対応: §8 撤退条件 3 発火 = 案 (i) 除外検討)。
2. silent drift 検知件数 = 0 → 1+ 検知/年 (検証手段: telemetry 年次集計 · 実行頻度: 12 ヶ月後判定 · 違反時対応: golden 20 件の検知限界 = drift 率 ≥ 20-25% を勘案し、ゼロ継続時は golden 拡張を別 amend で検討)。
3. 月次 cost 増 ≤ $2 (検証手段: Cloud Billing · 実行頻度: 月次 · 違反時対応: §8 撤退条件 2 発火 = K=3 降格)。
4. ADR-0056 本文に seed:\s*42 正規表現がヒットしない (検証手段: adr-lint の grep 検証 · 実行頻度: 本 amend 受理後の diff + PR CI · 違反時対応: PR reject)。
5. ADR-0073 amend が本 amend 受理後 14 日以内に doc 領分で起票 → Amended → In Progress → Done (90 日以内) (検証手段: adr-lint scheduled check + GitHub Issue due date · 実行頻度: 14 日 / 90 日タイマー · 違反時対応: §8 撤退条件 5・4 発火)。
6. candidateCount 方式と K 回別呼出方式の mode 一致率差 ≤ 5pt + 候補間 Jaccard 類似度 ≤ 0.95 (検証手段: Phase 1 実測 · 実行頻度: 実装完遂直後 1 回 + 半年ごと再測 · 違反時対応: §8 撤退条件 6 発火 = 独立呼出方式へ切替)。
7. 採択前スモークテスト: 同一プロンプト 10 回逐次呼出の出力トークン列完全一致率 ≥ 90% (検証手段: drp/src/nodes/gate0_regression.ts 実装前の smoke script · 実行頻度: 実装着手前 1 回 · 違反時対応: §8 撤退条件 3 発火 = 案 (i) 除外し案 (ii) 単独運用)。
8. 月次 cron 実行の可視性: Slack 通知成功率 100% + D1 書込み失敗時の non-zero exit (検証手段: Slack #drp-alerts 受信ログ + CI/CD alert · 実行頻度: 月次 · 違反時対応: cron 失敗 1 回で保守担当が原因調査)。

10. 参照

10.1 関連 ADR

• Amends: ADR-0056 (LLM temperature/sampling 戦略) — 本 amend 対象 · §6.5 を撤回・置換
• ADR-0073 (Gate 0 Triage Seed 固定再現性 回帰テスト) — 本 amend で Amended flip · 実装先行可能状態
• ADR-0157 (LLM Gateway 統一・gemini-flash 標準化) — 本 amend の整合性回復先 · Gate 0 provider の SSoT
• ADR-0053 (判断基準 MCDA 構造) — §4 判断基準の準拠先
• ADR-0088 (コスト試算必須化) — §7 コスト試算の準拠先
• ADR-0176 (§実装配線 lint 強制) — §11 実装配線の準拠先

10.2 関連 PR/Issue

• PR #1009 (ADR-0056 §6.5 seed=42 実装) — 本 amend の対象コード
• 起点 handover: handover_2026-07-01_adr-0073-seed-premise-review-adr-0056-amend_to_main.md (drp session 26 起票 · main archive 済)

10.3 外部資料

• Google Gemini API リファレンス (ai.google.dev/api/generate-content): seed パラメータ非対応 (2026-07-01 時点確認)
• Anthropic Claude API: seed パラメータ対応 (2025-06〜 · 案 (iii) の技術根拠 · 本 amend では採用しない)
• OpenAI API: seed パラメータ対応 (2024〜 · 同上)
• Holtzman et al. 2020 / Wiher et al. 2022 — LLM サンプリング候補間相関の研究 (§3.3 Jaccard 類似度検証の根拠)
• Fleiss et al. — 統計的標本設計標準 (§7.1 golden 検知限界の根拠)

11. 実装配線

• lint 配線: adr-lint --check-edges で本 amend (ADR-0056) と ADR-0073 status flip の相互参照 (typed edge = amends: [ADR-0056] / amended-by: [本 amend]) を検証 / adr-draft-lint (WIRING_LINT_ENABLED=true) で本 draft の §11 実装配線が形骸化していないか検出 / 受理後 grep -E "seed:\s*42" docs/adr/0056-*.md で hit ゼロを確認 (KPI 4) / adr-lint scheduled check で ADR-0073 amend 起票 14 日タイマー・実装完遂 90 日タイマーを自動追跡 (KPI 5)。
• 起案フロー配線: 本 draft を KV push (draft_push.sh) → Pipeline に投げて Gate 0-4 通過 → ADR-0056 amend として受理 → adr-index 再生成 → docs.bizlp.dev/adr/0056 で公開。受理後 14 日以内に doc 領分で ADR-0073 status を Proposed → Amended に flip (frontmatter + 本文 §1.4 制約書換) し、GitHub Issue に due date を設定 (blocking escalation の自動化)。その後 drp 領分で smoke script 実行 (KPI 7) → drp/src/nodes/gate0_regression.ts 実装 + 月次 cron 設定 + D1 telemetry 追加 + Slack #drp-alerts 通知経路整備 + golden への FAIL ダミーケース 1 件混入 + 半年ごとの golden レビュー手順を drp/CLAUDE.md に明記。
• docs SSoT 同期: ADR-0056 amend 受理後に docs/adr/0056-*.md の Corrigendum 履歴に amend 記録を追記 / docs/architecture/prd.md の LLM sampling 戦略節を書き換え (doc 領分) / drp/CLAUDE.md に「Gate 0 判定 script 手順 + golden 半年レビュー + Gemini seed 対応監視」を追記 (drp 側実装完遂後) / 起点 handover (_to_main.md) は本 draft PR 起票時に archive 退避。