• Status: Accepted
  • Mode: Standard
  • Kruchten Type: Executive/Property
  • Scope: platform
  • Implementation Status: Not Started
  • 起案者: [email protected]
  • 起案日時 (JST): 2026-07-04 14:20
  • 承認日時 (JST): 2026-07-04
  • Approver Role: platform
  • Approver Who: [email protected]
  • Driver: [email protected]
  • Consulted: Decision Pipeline AI 審査 (Gate 0-4)

1. Executive Summary

  • 文脈: Decision Pipeline (= ADR 審査を自動で回す仕組み) の本番 prompt 16 件は、変更のたびに golden eval (= 正解データによる出力品質の自動検査) で品質を守る設計で 2026-05 から運用している。
  • 課題: CI で品質の合否判定が実際に効いているのは 16 件中 1 件だけで、既に書かれた正解データ 92 件は配線欠落で一度も実行されず、週次の定期検査も有効化判定の不具合で一度も動いていない。
  • 対策: 正解データ済みの 4 prompt へ検査配線を追加し、残る整備計画・週次検査を有効にする条件・検査コスト方針を 4 段階に分けて裁定し直す。
  • 効果: CI で品質判定が効く prompt を 1/16 から 5/16 へ 2 週間で拡大し、2026-08-31 までに 12/16 へ引き上げ、週次の定期検査を 2026-08-02 に初回実行させる。
  • 代償: prompt 変更 PR ごとに検査費 $4-17 と CI 実行時間の増分 (約 7 分 → 30-50 分) を受け入れ、正解データ執筆 140-160 件 (7-16 人日) の人手作業が残る。

2. 何を解決するか

2.1 直面していること

信頼性:

  • 本番 prompt は 18 件あり、うち品質保証の対象 16 件の中で CI の品質合否判定が実際に効いているのは 1 件のみ。
  • 検査設定 file (promptfoo.yaml = 検査の実行定義) が存在するのは 18 件中 3 件で、うち 2 件は eval_suite: deferred (= 正解データ整備を後回しにする宣言) のため合否判定の対象外になっている (1 件は検査 case 0 件で実質空)。
  • 採点 prompt では品質のずれが 1.5 ヶ月検出されない事故が実際に起きており、バイト一致検証 (= prompt 本文の SSoT と実装内の予備の文面が一致しているかの確認) では内容の劣化を検出できない。

効率性:

  • 正解データ file (golden.jsonl) が既に書かれている 4 prompt 分 92 件は、検査設定 file の欠落により CI で一度も実行されず遊休している。

運用性:

  • 週次 cron (= 毎週日曜に全 prompt の品質検査を回す定期実行) は、有効化判定の「全 prompt が正解データ 20 件以上」という一括判定が常に不合格を返すため、導入以来一度も検査本体を実行していない (直近 5 回 2026-05-31〜06-28 は全て 1.5-2 分で終了 = 検査未実行の傍証)。
  • 有効化判定は eval_suite: deferred の 4 prompt を file パスとして解決して必ず「不存在」と判定するため、正解データを何件書いても週次 cron は永久に有効化されない構造欠陥がある。
  • 唯一実効している prompt も正解データが 19 件で基準の 20 件に 1 件足りず、一括判定の不合格要因になっている。

保守性:

  • prompt メタ設定 13 件が正解データのパスを宣言しているが、うち 9 件は実体 file が存在せず「検査がある」という誤った安心感だけが残っている。
  • ADR-0042 (LLM プロンプトのライフサイクルを管理するポリシー) が 2026-05-15 に設定した整備計画の対象には、後継 3 分割 (ADR-0071 = Gate 1 Socratic Node の盲点検出エンジン再定義) で不要になった旧 prompt が含まれたままで、対象リストが実働構成 (18 件) から古くなっている。

2.2 放置すると起こること

効率性:

  • 整備期日 2026-07-14 (ADR-0042 の D+60 マイルストーン) に予定どおり正解データを 100 件規模で人手執筆しても、配線欠落と有効化判定の構造的な欠陥により CI 防御は 1 件も増えず、執筆コスト 7-16 人日が成果ゼロになる。

信頼性:

  • prompt 変更 PR の品質判定が人間レビュー頼みのまま prompt 数が増え続け (計画時 5 件 → 現在 18 件)、採点 prompt で起きた 1.5 ヶ月型の品質ずれが再発しても検出手段がない。

適合性:

  • 期日 2026-07-14 の未達が記録されないまま経過し、下流タスク MAS-365 (= Gate1↔Gate4 カバレッジ突合) の前提日付が実態と乖離する。

2.3 潜在リスク (実害未発生 · 発生確率不明)

適合性:

  • prompt lifecycle 管理の統制が「宣言 13 件中 9 件実体なし」の宣言倒れ状態のため、監査時に統制の実効性を指摘されるリスク (発生は監査タイミング依存)。

3. 採用したい方針

3.1 対策方針

golden eval の実効化を 4 段階 (Phase 1-4) に分け、即効の配線 (Phase 1) を裁定が必要な計画刷新 (Phase 2-4) から切り離して先行させる。あわせて ADR-0042 の D+60 期日 (2026-07-14) を本 ADR に統合し、成果 (CI 防御の拡大 + 週次検査の実働) とセットの新期日 2026-08-31 へ引き直す。

  • 信頼性: Phase 1 (2026-07-18 まで) — 正解データ済みの 4 prompt (相互検証 30 件 / 審査の入口で行う簡易な判定 26 件 / 起案前ゲート 2 系統の共有 36 件) へ promptfoo (= prompt 検査を実行する OSS ツール) の検査設定を配線し、CI 実効を 1/16 から 5/16 へ拡大する。
  • 保守性: Phase 2 (2026-08-31 まで) — 正解データ未整備 9 prompt の整備対象を実働 prompt 基準に刷新し (撤去裁定済みの旧 prompt は対象外)、20 件基準と eval_suite: deferred の昇格基準を裁定してから執筆する。
  • 運用性: Phase 3 (2026-07-31 まで) — 週次 cron の有効化判定を「全 prompt 一括」から prompt 単位判定へ修正し、準備の整った prompt 分だけ週次検査を先行実行させる (判定 script は main クローン領分のため発注)。
  • 効率性: Phase 4 (2026-08-15 まで) — 検査コスト方針 (高価格モデル 30 呼び出しが prompt 変更 PR ごとに全件走る現設計の頻度制御 or 差分検査化) を Phase 1 の実測 1 ヶ月分を根拠に裁定する。
  • 適合性: 期日の引き直し — ADR-0042 本文は Immutable (= 受理後は本文を書き換えない規約) のため、期日変更は frontmatter への追記で記録し、下流タスクの前提日付更新は doc クローンへ委譲する。

3.2 守るべき設計制約

  • 適合性: scripts/.github/workflows/ は main クローン領分のため、Phase 3 の判定 script 修正は drp が直接編集せず main へ発注する (docs 側の正典 2 file の更新は doc へ委譲する)。
  • 適合性: ADR-0042 本文の書き換えは行わず、期日変更は frontmatter 追記のみで記録する。
  • 信頼性: 検査の役割分担は先行配線済み prompt の方式を踏襲し、promptfoo には形式検証 (schema · 必須 field · 値域) を置き、判定の正確性評価は別レーンに残す。形式検証のみでは gate4-scoring で起きた 1.5 ヶ月型の意味的品質ずれを素通しするため、意味的正確性の別レーンは Phase 2 完了 (2026-08-31) を暫定期間の上限とし、担当クローン・接続方法は Phase 2 の裁定時に別 ADR で確定する。
  • 保守性: prompts/production/ は実装本文との同期契約があるため、配線 PR は編集直前に main 側と調整してから出す。

3.3 仕様

  • 信頼性: Phase 1 の配線対象と検査モデルは cross-validation (30 件 · claude-opus) / gate0-triage (26 件 · gemini-flash) / gate0a-pregate-primary と gate0a-pregate-secondary (共有 36 件 · gemini-flash + claude-sonnet) の 4 prompt とする。
  • 信頼性: assertion (= 検査の合否条件) は gate0b-abc-screen/promptfoo.yaml (= 唯一実効している検査設定) を基準に、JSON schema 検証 + 必須 field + 値域チェックを prompt ごとに設計する。設計 draft は別クローン (doc) の査読を挟み、gate0b-abc-screen の「形式検証と正確性評価の分離」判断ログを参照する。
  • 信頼性: Phase 1 配線時点で claude-opus (cross-validation prompt) の呼び出しは PR ごと全件実行 (30 件/PR) を暫定上限とし、Phase 4 裁定までの 1 ヶ月分の実測でこの上限の妥当性を検証する。
  • 効率性: 正解データ執筆プロセスは、執筆者 1 名 + 別クローン (doc または main) の査読 1 名の 2 段で運用し、ADR-0187 (K=5 サンプリング) 前提の prompt では 5 サンプル中の代表出力を正解として選ぶ手順とする (執筆者単独の主観固定を回避)。
  • 運用性: scripts/prompt-golden-readiness.mjs (= 週次 cron の有効化判定 script) を prompt 単位判定へ修正し、eval_suite: deferred をパス解決の対象から除外する。
  • 保守性: Phase 2 の整備対象は実働 8 prompt (gate1-da / gate1-pm / gate1-judge / gate2-consistency / gate4-scoring / policy-alignment / recall-pre-gate に加え、gate3-parallel-review は別起案「孤立 prompt dir 2 件の SSoT 収束」の標準構成化の完了後に対象へ加える) とし、唯一実効 prompt の 19 件 → 20 件補充もここに含める。別起案の完了確認が 2026-08-15 までに取れない場合は gate3-parallel-review を Phase 2 対象から外し、KPI を 12/16 → 11/16 に修正する。
  • 適合性: ADR-0042 の frontmatter へ「D+60 (2026-07-14) は本 ADR へ統合し新期日 2026-08-31」を追記し、MAS-365 の前提条件日付の連動更新を doc へ委譲する。

4. 判断基準

4.1 評価軸 (5 個選定)

#軸 (Q42)日本語軸名重要度 (係数)案件特有の解釈
1#reliable信頼性Must (×2.0)prompt 内容変更時の品質のずれ (実例: 採点 prompt の 1.5 ヶ月未検出) を CI で検出できるか。K.O.: 品質検出レーンが 1 件も増えない案は不採用
2#efficient効率性Must (×2.0)既存の正解データ 92 件と今後の執筆 140-160 件が確実に CI 防御へ変換されるか · 検査費が月 $150 以内か。K.O.: 人手執筆の成果が CI で 1 回も実行されない案は不採用
3#operable運用性High (×1.0)週次 cron が実際に検査本体を実行する配線になるか · 準備済み prompt 分の段階実行ができるか
4#suitable適合性High (×1.0)ADR-0042 の lifecycle 方針 (整備完了が cron 有効化に接続する) と整合し、scripts/.github = main 領分・docs 正典 = doc 領分の境界を守れるか
5#maintainable保守性Medium (×0.5)整備対象リストが実働 prompt 構成 (18 件) と一致し陳腐化しないか

K.O. criterion: Must 軸の score < 3 は不採用。

4.2 評価軸 × 案スコア表

係数案 1: 統合 ADR (採用)案 2: 単発配線案 3: 保留案 4: 期日単独実施
信頼性×2.05311
効率性×2.04341
運用性×1.05211
適合性×1.05222
保守性×0.55223
加重和 (正規化)0.9240.5150.4240.258
K.O. 通過 (Must ≥3)❌ (信頼性 1)❌ (信頼性 1 · 効率性 1)

加重和は満点 33.0 (= 5 × 6.5) に対する正規化値。

5. 検討した代替案

  • 案 2 (単発 PR で 4 prompt の配線のみ): 起案なしで PR 単発で配線する案。

    • 信頼性: PR 時の検出は 5/16 へ増えるが、週次検査は死んだ配線のまま残り、未整備 9 prompt で 1.5 ヶ月型の品質ずれが再発しても検出できない。
    • 効率性: claude-opus 30 呼び出しが prompt 変更 PR ごとに全件走るコスト構造が、方針未裁定のまま既成事実化する。
    • 運用性: 有効化判定の構造欠陥に触れないため、週次 cron は永久に検査本体を実行しない。
    • 適合性: scripts/.github/ は main 領分で単発 PR では踏み込めず、ADR-0042 の期日未達も無記録のまま経過する。
    • 保守性: assertion 設計は prompt ごとに設計判断を伴い、単発 PR の粒度を超えて判断が散逸する。
  • 案 3 (保留 · バイト一致検証 16/16 を当面の防衛線とする): 現状維持でバイト一致検証のみを頼る案。

    • 信頼性: バイト一致検証は SSoT と実装の同期しか守れず、採点 prompt で実際に起きた 1.5 ヶ月の品質ずれ型の事故は byte が一致していても素通しする (K.O. 該当)。
    • 効率性: 追加費用ゼロだが、既存の正解データ 92 件が遊休のまま残る。
    • 運用性: 週次 cron が一度も実行されない死んだ配線が放置される。
    • 適合性: 期日 2026-07-14 の未達が無記録で経過し、下流タスク MAS-365 の前提が崩れる。
    • 保守性: メタ宣言 13 件中 9 件実体なしの不一致が残り「検査がある」誤解が継続する。
  • 案 4 (対象リストだけ差し替えて 2026-07-14 に正解データ整備を単独実施): 配線せずに人手執筆だけ進める案。

    • 信頼性: 品質検出レーンは 1/16 のまま 1 件も増えない (K.O. 該当)。
    • 効率性: 140-160 件を人手執筆しても配線欠落と有効化判定の欠陥により CI では 1 件も実行されず、7-16 人日が成果ゼロになる (K.O. 該当)。
    • 運用性: eval_suite: deferred 4 件のパス解決失敗が残るため、週次 cron の有効化に到達できない。
    • 適合性: 期日だけは守れるが、ADR-0042 §5.3 が定めた「整備完了 → cron 有効化」の接続を満たさない。
    • 保守性: 対象リストの刷新だけは進む。

6. 影響

6.1 正の影響

  • 信頼性: 品質のずれの検出時点が PR 時 (配線済み prompt) と週次 (定期検査) の 2 レーンになり、未検出期間の上限が実測 1.5 ヶ月から最長 1 週間へ短縮する。
  • 効率性: 既存の正解データ 92 件が即日 CI 防御へ変換され、Phase 2 で執筆する 140-160 件も配線済みの状態で書けるため執筆成果が空振りしない。
  • 運用性: 週次 cron が「一度も実行されない配線」から準備済み prompt 分の実働検査へ変わる (初回実行 2026-08-02 目標)。
  • 保守性: 整備対象リストが実働 18 prompt 基準に刷新され、メタ宣言と実体の不一致 9 件が解消へ向かう。

6.2 負の影響 / リスク

  • 効率性: prompt 変更 PR ごとの検査費が $4-17 増え、CI 実行時間が約 7 分から 30-50 分へ延びる (Phase 4 の頻度制御 or 差分検査の裁定で縮める)。
  • 効率性 (ストレスシナリオ): claude-opus $0.5/呼び出し × 30 件 = PR 1 件 $15 · 月 10 件で $150 突破 · 撤退条件 2 発動時は cross-validation を週次のみへ退避し PR 時検出が最長 1 週間空白になる。
  • 適合性: 2026-07-14 の期日を破る記録が残り、下流タスク MAS-365 の開始も連動して後ろ倒しになる。
  • 信頼性: assertion 設計を誤ると正しい変更を誤って落とす誤検出が発生し、prompt 変更 PR を止める (撤退条件 4 で監視)。
  • 信頼性: Phase 1-2 の暫定期間 (最長 2026-08-31 まで) は形式検証のみが稼働し、意味的品質ずれは週次 cron 側でしか検出されない。

6.3 中立・トレードオフ

  • 効率性: Phase 4 のコスト方針裁定を Phase 1 の実測 1 ヶ月後に置くため、暫定期間は claude-opus 30 呼び出し/PR が既定値で走る (上限件数は §3.3 で明示・実測後に見直し)。

7. コスト試算

7.1 前提条件

項目根拠
prompt 変更 PR の頻度月 4-8 件 (ストレス上限 10 件)検査 workflow の直近 8 run 実測からの推定
検査 1 回の LLM 呼び出し数現行 約 20 → Phase 1 後 約 148正解データ件数の実測 (19+1 → +30+26+36×2) と実装のモデル割当
1 呼び出し単価 (概算)gemini-flash $0.001 未満 / claude-sonnet $0.01-0.05 / claude-opus $0.1-0.5各社公表料金 × 正解データ 1 件の入出力規模 (数千 token) からの概算
現行 CI 実行時間約 7 分 (直列実行 · 約 21 秒/呼び出し)検査 workflow の直近 8 run 実測

7.2 月コスト試算

項目一時 (実装)月次 (運用)
Phase 1: 検査設定 4 件の assertion 設計 + 配線 + ローカル検証 + doc 査読2-4 人日-
Phase 2: 正解データ執筆 140-160 件 (1 件 25-50 分) + 査読7-16 人日-
Phase 3: 有効化判定 script の修正 (main 発注)0.5-1 人日-
Phase 1 後の PR 検査 LLM 費 (通常シナリオ)-$4-17/PR × 月 4-8 件 = 月 $16-136
Phase 1 後の PR 検査 LLM 費 (ストレスシナリオ)-claude-opus $0.5/呼 × 30 件 × 月 10 件 = $150 突破 → 撤退条件 2 発動対象
週次 cron の検査 LLM 費 (実働開始後)-月 $17-73 程度 (PR 検査 1 回分 × 月 4-5 回)
CI 実行時間の増分-約 7 分 → 30-50 分/PR (約 148 呼び出しの直列実行)

8. 撤退条件

各撤退条件は「発動決定者 = 起案者 ([email protected])」「発動から実行までの最大 5 営業日」を共通条件とする。Phase 2 の人手作業開始前 (2026-07-31) にチェックポイントを設け、撤退条件 3 の観測基準を確認する。

  1. Phase 1 配線後、prompt 変更 PR の CI 実行時間が 60 分を超過 → Phase 4 (頻度制御 / 差分検査) の裁定を前倒しし、超過が解消するまで高価格モデル分の検査を週次 cron 側へ退避する。
  2. 検査由来の LLM 費が月 $150 を超過 → claude-opus 30 呼び出し (相互検証 prompt) を PR ごと実行から週 1 回実行へ切り替える。切替期間中は cross-validation の PR 時検出が最長 1 週間空白になることを許容する。
  3. 2026-08-31 時点で正解データ整備が対象の 50% (70-80 件) 未満 → 20 件基準を 10 件へ引き下げて暫定 gate 化するか、対象を Must 級 prompt に絞る再裁定を起案する。
  4. 誤検出 (正しい変更を検査が誤って落とす) が月 3 件を超過 → 当該 prompt の assertion を形式検証のみに縮退し、判定の正確性評価を別レーンへ戻す。
  5. Phase 3 反映後 4 週連続で週次 cron の検査本体が実行されない → 有効化判定の再修正を main へ再発注し、それでも解消しなければ週次 cron の存廃を ADR で再裁定する。

9. Confirmation

  1. 実効 gate 数の観測: prompt 変更 PR の CI ログで合否判定対象の prompt 数を確認 / prompt 変更 PR ごと / 2026-07-18 時点で 5/16 未達なら Phase 1 配線の不具合を調査し修正 PR を出す。assertion 設計の誤検出率は Phase 1 配線前にローカルで正解データ 92 件を流して事前計測し、5% 超なら配線しない。
  2. 週次 cron の初回実行: workflow 実行履歴で実行時間の変化 (1.5-2 分 → 検査込みの 10 分超) を確認 / 週次 / 2026-08-02 までに初回実行がなければ撤退条件 5 の 4 週監視を開始する。Phase 3 の main 発注 PR のマージ日を独立指標として週次で追跡する (発注日から 2 週間超で escalation)。
  3. 検査コストの観測: LLM gateway (= モデル呼び出しの中継層) の利用集計で検査由来の費用を確認 / 月次 / 月 $150 超過で撤退条件 2 を発動する。
  4. 正解データ整備の進捗: リポジトリ内の golden.jsonl 件数を集計 / 隔週 / 2026-08-31 時点で対象の 50% 未満なら撤退条件 3 を発動する。2026-07-31 のチェックポイントで 30% 未満なら Phase 2 の対象を Must 級に絞る再裁定を検討する。

KPI: CI 実効 gate 数 1/16 → 5/16 (2026-07-18) → 12/16 (2026-08-31 · gate3-parallel-review 未完了時は 11/16) / 週次 cron 初回実行 2026-08-02 まで / 検査 LLM 費 月 $150 以内 / prompt 変更 PR の CI 実行時間 60 分以内 / assertion 誤検出 月 3 件以内。

10. 参照

10.1 関連 ADR

  • ADR-0042 (LLM プロンプトのライフサイクル管理ポリシーを採択する) — amends。本 draft は同 ADR §5.3 の D+60 マイルストーン (2026-07-14 · 正解データ整備完了 → 週次 cron 有効化) を統合し、新期日 2026-08-31 へ引き直す (本文 Immutable のため frontmatter 追記で記録)。
  • ADR-0056 (Decision Pipeline の LLM temperature / sampling 戦略を工程別ハイブリッド設計で確立) — 補完。検査実行時のモデル・パラメータの前提。
  • ADR-0071 (Gate 1 Socratic Node を盲点検出エンジンに再定義) — 補完。整備対象から旧 prompt を外し後継 3 prompt (gate1-da / gate1-pm / gate1-judge) へ差し替える根拠。
  • ADR-0171 (drift 検出 CI を実測で数値補強) — 並立。SSoT と実装のずれ検出はバイト一致検証レーンが守り、本 draft は内容品質のずれ検出レーンを担う。
  • ADR-0187 (seed=42 前提撤回 + K=5 サンプリング採択) — 補完。Gate 0 系 prompt の出力ゆらぎの前提は同 ADR の sampling 設計に従い、正解データ執筆時は 5 サンプル中の代表出力を選ぶ。

10.2 関連 PR/Issue

  • PR #4363 — バイト一致検証の全数調査で「golden eval 実効は 16 件中 1 件のみ」を調査結論として明記した PR。
  • PR #4367 — 実装内の予備文面 (FALLBACK) の同期修復 PR。バイト一致検証 16/16 の防衛線を成立させた。
  • commit 667b9938 (2026-05-15) — 正解データ収容ディレクトリの作成と D+60 期日 (2026-07-14) を設定した実装 commit。
  • tasks/prompts/handover_2026-07-04_drp-session-58-close-fallback-audit-10pr-plus-fact-check-lit_next-session.md (= 本 draft の課題整理元の引継ぎ文書) — 整備予定と撤去裁定の順序制約を明記。
  • 別起案「孤立 prompt dir 2 件の SSoT 収束」 — gate3-parallel-review の Phase 2 対象化の前提。完了期日 2026-08-15 · 担当は drp。

10.3 外部資料

11. 実装配線

  • lint 配線: prompts/production/{cross-validation,gate0-triage,gate0a-pregate-primary,gate0a-pregate-secondary}/promptfoo.yaml を新設する (.github/workflows/prompt_eval.yml は promptfoo.yaml の実在で自動的に検査対象へ組み込むため workflow 変更は不要)。assertion draft は doc クローンの査読 (gate0b-abc-screen の設計判断ログ参照) を経て配線する。scripts/prompt-golden-readiness.mjs の prompt 単位判定化と .github/workflows/prompt_regression_cron.yml の実行確認は main へ発注する (発注日 2026-07-05 目標 · 期待完了 2026-07-31 · 承認者 = 起案者 [email protected])。
  • 起案フロー配線: docs/adr/0042-adopt-llm-prompt-lifecycle-management-policy.md の frontmatter へ期日引き直し (D+60 2026-07-14 → 本 ADR 統合 · 新期日 2026-08-31) を追記する (本文は Immutable のため本文改変なし)。Phase 2 の正解データ執筆プロセス (執筆者 + 査読の 2 段 · K=5 代表出力選定) を docs/_internal/06_ops/prompt_lifecycle_guide.md に追記する。
  • docs SSoT 同期: docs/_internal/06_ops/prompt_lifecycle_guide.md 行 276 (週次 cron 有効化条件) / 行 294 (D+60 整備予定表) の対象リストと期日の更新、および docs/_internal/02_project/TODO_future.md 行 289 (MAS-365 の前提条件日付) の連動更新を doc クローンへ handover で委譲する。