ADR-0205: golden eval を実効化する
- 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.0 | 5 | 3 | 1 | 1 |
| 効率性 | ×2.0 | 4 | 3 | 4 | 1 |
| 運用性 | ×1.0 | 5 | 2 | 1 | 1 |
| 適合性 | ×1.0 | 5 | 2 | 2 | 2 |
| 保守性 | ×0.5 | 5 | 2 | 2 | 3 |
| 加重和 (正規化) | 0.924 | 0.515 | 0.424 | 0.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: deferred4 件のパス解決失敗が残るため、週次 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 の観測基準を確認する。
- Phase 1 配線後、prompt 変更 PR の CI 実行時間が 60 分を超過 → Phase 4 (頻度制御 / 差分検査) の裁定を前倒しし、超過が解消するまで高価格モデル分の検査を週次 cron 側へ退避する。
- 検査由来の LLM 費が月 $150 を超過 → claude-opus 30 呼び出し (相互検証 prompt) を PR ごと実行から週 1 回実行へ切り替える。切替期間中は cross-validation の PR 時検出が最長 1 週間空白になることを許容する。
- 2026-08-31 時点で正解データ整備が対象の 50% (70-80 件) 未満 → 20 件基準を 10 件へ引き下げて暫定 gate 化するか、対象を Must 級 prompt に絞る再裁定を起案する。
- 誤検出 (正しい変更を検査が誤って落とす) が月 3 件を超過 → 当該 prompt の assertion を形式検証のみに縮退し、判定の正確性評価を別レーンへ戻す。
- Phase 3 反映後 4 週連続で週次 cron の検査本体が実行されない → 有効化判定の再修正を main へ再発注し、それでも解消しなければ週次 cron の存廃を ADR で再裁定する。
9. Confirmation
- 実効 gate 数の観測: prompt 変更 PR の CI ログで合否判定対象の prompt 数を確認 / prompt 変更 PR ごと / 2026-07-18 時点で 5/16 未達なら Phase 1 配線の不具合を調査し修正 PR を出す。assertion 設計の誤検出率は Phase 1 配線前にローカルで正解データ 92 件を流して事前計測し、5% 超なら配線しない。
- 週次 cron の初回実行: workflow 実行履歴で実行時間の変化 (1.5-2 分 → 検査込みの 10 分超) を確認 / 週次 / 2026-08-02 までに初回実行がなければ撤退条件 5 の 4 週監視を開始する。Phase 3 の main 発注 PR のマージ日を独立指標として週次で追跡する (発注日から 2 週間超で escalation)。
- 検査コストの観測: LLM gateway (= モデル呼び出しの中継層) の利用集計で検査由来の費用を確認 / 月次 / 月 $150 超過で撤退条件 2 を発動する。
- 正解データ整備の進捗: リポジトリ内の 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 外部資料
- promptfoo ドキュメント: https://www.promptfoo.dev/docs/intro/
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 で委譲する。