← ADR 一覧へ残タスク一覧へ 最終更新: 2026/06/22 18:56
commonid: adr-0134type: adrstatus: accepted
pagemode: Standardkruchten: Executive/Propertyscope: platformimplementation_status: Done (PRproposed_at: 2026-06-11 01:22approved_at: 2026-06-11 01:59deciders: [email protected] (単独)business: meta
型付き辺: 出 5 / 入 1
細分化する: ADR-0132 関連: ADR-0147 ADR-0130 ADR-0042 ADR-0149 前提とされる: ADR-0145全体は INDEX →

ADR-0134: tasks/prompts の役目を終えた運用プロンプトを archive へ退避する機構

  • Status: Accepted (PR #1713 merge = 受理の規約により 2026-06-11 受理)
  • Mode: Standard
  • Kruchten Type: Executive/Property
  • Scope: platform
  • Implementation Status: Done (PR #1737 滞留 lint / PR #1741 初期掃除 66 本 / enforce 昇格 PR — いずれも 2026-06-11)
  • 起案者: [email protected]
  • 起案日時 (JST): 2026-06-11 01:22
  • 承認日時 (JST): 2026-06-11 01:59
  • Deciders: [email protected] (単独)

コンテキスト

§1.1 背景

ADR-0132 で「役目を終えた運用プロンプトは tasks/prompts/archive/ 系へ退避する」方針は確立済みだが、具体機構が未決のため退避を始められない。ADR-0132 の撤退条件により、その受理 (2026-06-11) から 30 日以内に本機構 ADR が Accepted されなければ分類決定ごと見直しになる。

§1.2 現状 (As-Is)

tasks/prompts/ に運用プロンプト 221 本 (2026-06-10 時点・handover_* 103 / task_* 69 / main_* 32 / impl_* 10 ほか) が現役・完了の区別なく直下に混在し、週約 55 本ペースで増えている。

§1.3 課題

放置すれば 30 日後に 440 本超 (週 55 本ペースの外挿) となり、古い handover を現役の指示と誤認して完了済みタスクを重複実行するリスクが線形に増える。ADR-0132 の HITL 残余リスク節 (Cross-Validation 指摘) で、機構が解くべき構造問題が 4 点特定されている:

  1. 起票者はセッション終了で離脱するため「起票者が完了マーカーを付与する」設計は最多カテゴリ (約 46%) で構造的に不成立
  2. 対応 ADR/PR を持たない task_*/impl_* (約 79 本) には完了イベントがなく退避トリガーが存在しない
  3. ADR 番号未記載の handover (約 40%) は人手照合だと退避可否が記憶依存になる
  4. impl_* に本番コード生成直結プロンプトが含まれる場合、「管理対象外」のまま archive すると追跡不能な本番指示になる (AI ガバナンス監査リスク)

§1.4 制約・要件

  • ADR-0132 受理 (2026-06-11) から 30 日以内に Accepted される必要がある
  • 起票者離脱・完了イベント不在・ADR 番号未記載という構造制約のもとで退避が回り続けること
  • impl_* 中の本番直結プロンプトを ADR-0042 Type 1 管理体系から漏らさない (AI ガバナンス監査要件)
  • 直接金銭支出 0 円・実装コストは ADR-0130 規模 (約 1 人日) 内に収める

§1.5 目標 (To-Be)

  • 受理 4 週後に tasks/prompts/ 直下の現役本数を 100 本未満にする
  • 退避判定を機械化し記憶依存を排する
  • Non-Goals: GitHub Issues 等の外部トラッカー移行、ADR-0042 本体の改訂、ADR-0106 カタログ走査範囲の変更

決定

Y-Statement: 週約 55 本ペースで運用プロンプトが蓄積する tasks/prompts/ の文脈で、現役と完了の混在による誤参照・探索コスト増の課題に直面し、起票者マーカー方式や経過日数のみの全自動退避でなく、消費者退避 + 経過日数フォールバック + CI 強制のハイブリッド退避機構を選ぶ。人手判定の記憶依存を排して退避を確実に回し続けるため、無関係 PR が滞留超過 FAIL で止まりうる運用負荷を受け入れる。

機構の内容 (1 つの退避機構を構成する 4 要素):

  1. 消費者退避 (一次トリガー): 運用プロンプトを処理し終えたセッション (= 消費者) が、処理完了と同じ PR で当該ファイルを git mv で tasks/prompts/archive/ へ退避する。起票者でなく消費者が完了を判定する (残余リスク 1 への対応)。Step 1〜5 など複数段の handover は最終 Step を処理したセッションが退避する。並列処理時の責任者決定ルール (先着セッションが handover 冒頭に <!-- CONSUMER: session-id --> を記録して責任宣言する等の具体手順) を実装時に規定する (盲点 3 への対応)。
  2. 経過日数フォールバック (補助トリガー): 最終 git 更新から 30 日を超えて tasks/prompts/ 直下に滞留するファイルは退避対象とする (残余リスク 2・3 への対応)。「無参照」は直接観測できないため最終更新日を代理指標とする。最終更新日は git log --follow -1 --format=%aI -- <file> で取得し、ファイルシステムタイムスタンプ (os.path.getmtime() 等) は使わない (CI クリーンチェックアウトで全ファイルが「今日更新」と誤判定される盲点 1 への対応)。さらに自動 format bot 等による意味なし touch でカウンターがリセットされる抜け穴を塞ぐため、git log --diff-filter=M -- <file> 相当で「ファイル内容を意味的に変更した最後の commit 日」を採用する (盲点 5 への対応)。30 日超のダミーファイルを含む fixture で検出ロジックを CI 自動検証する。現役で残す必要があるものは <!-- KEEP-UNTIL: YYYY-MM-DD 理由 --> マーカーで延長する (1 回 90 日まで・理由必須・期限到来で再判定)。
  3. CI 強制: 滞留 lint (実装は main 領分・scripts/) が PR ごとに滞留超過 (基準 30 日・KEEP-UNTIL は例外) を検査し、超過 1 件以上で FAIL する。対応は git mv 1 コマンドなので負荷は小さい。ADR-0130 の drift check と同型の「無関係 PR でも止める」規律パターンを踏襲する。CI 強制 FAIL の有効化は初期掃除 PR マージ完了後とし、それまでの移行期間は warning モードで稼働させる (受理直後に約 110 本以上が存在し全 PR FAIL でフローが停止する盲点 2 への対応)。
  4. archive の検索除外 (恒久化): ADR-0132 が暫定措置とした RAG・コンテキスト構築スクリプトからの除外について、tasks/prompts/archive/ を恒久除外対象として正式化する (誤参照リスクの根治)。

例外規定 (Type 1 昇格フロー・残余リスク 4 / 盲点 4 への対応): 「本番 LLM パイプラインへ直接入力されるプロンプト」の判定基準として、起票時点でフロントマターに production_pipeline: true フィールドの宣言を必須化する。滞留 lint が 30 日フォールバック対象ファイルをスキャンする際に同フラグを検出した場合、通常の FAIL ではなく「Type 1 昇格 PR を起票せよ」という専用エラーメッセージを出力し、main へ起票して prompts/production/ (ADR-0042 Type 1) へ移管し、SemVer・eval CI の管理体系に編入する。

初期掃除: 既存 221 本へ受理後に経過日数基準を一括適用して退避する (main 実施)。

判断基準 (Decision Drivers)

3.1 評価軸

#軸重要度 (係数)案件特有の解釈
1#operableMust (×2.0)人手の記憶・善意に依存せず退避が回り続けるか。K.O.: 起票者の離脱で止まる設計は不可
2#reliableMust (×2.0)現役プロンプトを誤退避しない・完了プロンプトを取りこぼさないか
3#maintainableHigh (×1.0)機構自体の保守が軽いか (lint 1 本 + マーカー規約 1 つのみ)
4#efficientMedium (×0.5)退避 1 件あたりの運用コストが小さいか (git mv 1 コマンド)

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

3.2 評価軸 × 案スコア表

軸係数採択案 (ハイブリッド)案 A (起票者マーカー)案 B (経過日数のみ全自動)案 C (現状維持)
#operable×2.05141
#reliable×2.04221
#maintainable×1.04345
#efficient×0.54455
加重和 (正規化)0.8800.3800.6600.380
K.O. 通過 (Must ≥3)✓❌❌❌

採択案のみ Must 軸が共に 3 以上で K.O. を通過する。

検討した代替案 (Alternatives Considered)

  • 案 A: 起票者が完了マーカーを付与 — 不採用。ADR-0132 の CV 残余リスクで構造的不成立と特定済み (起票者はセッション終了で離脱し、最多カテゴリ約 46% で機能しない)。#operable K.O. に該当。
  • 案 B: 経過日数のみの全自動退避 (cron が機械移動) — 不採用。消費状態を見ないため進行中の長期タスクを誤退避する (#reliable K.O.)。防衛的な KEEP マーカー運用が常態化して結局人手判定に回帰し、自動化の利点が消える。消費者退避と組み合わせるフォールバックとしてのみ採用する。
  • 案 C: 現状維持 (機構なし) — 不採用。ADR-0132 撤退条件 (受理後 30 日以内に機構 ADR Accepted) のトリガーを引き、分類決定ごと見直しになる。30 日後に 440 本超の外挿。
  • 案 D: GitHub Issues 等の外部トラッカーへ移行 — 不採用。案件管理は TODO_future.md 継続・Issues 移行はチーム拡大時まで保留が既決の運用判断。ツール乗換はファイル退避機構と別の決定であり、将来移行する場合も「現役と完了を分離する」規律自体は無駄にならない。

影響 (Consequences)

§5.1 正の影響 (Good)

  • 探索対象が現役分のみに絞られ、古い指示の誤参照・完了済みタスクの重複実行リスクが消える
  • 退避判定が機械化され記憶依存が消える
  • ADR-0132 の撤退条件トリガーを回避し分類決定が確定する
  • impl_* 中の本番直結プロンプトが production_pipeline: true フラグで ADR-0042 Type 1 管理体系に確実に編入される

§5.2 負の影響 (Bad)

  • 無関係な PR が滞留超過 FAIL で止まることがある (対応は git mv 1 コマンド)
  • KEEP-UNTIL マーカー・production_pipeline フロントマター・並列処理時の CONSUMER 宣言という新しい規約を覚える必要がある
  • 初期掃除 PR マージまでの移行期間は warning モードで運用するため CI 強制が一時的に効かない

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

  • 30 日基準が実態より短いと延長マーカーが乱発され形骸化する (撤退条件 2 で監視)
  • 消費者が退避を忘れても 30 日フォールバックが回収するため致命的にならない
  • 消費者退避 vs フォールバック退避の比率を Confirmation で計測することで、機構設計思想 (消費者退避が一次) の骨抜きを検知する

撤退条件 (Rollback Plan)

  1. 受理後 4 週時点で tasks/prompts/ 直下の本数が受理時点から減少していなければ (退避が回っていない)、機構を見直す。
  2. KEEP-UNTIL 延長が直下本数の 30% を超えたら、30 日基準が実態と乖離しているため基準日数を再設計する。
  3. 滞留 FAIL 起因の admin merge bypass が月 3 件以上発生したら、CI 強制 (FAIL) を警告に降格して運用を再設計する。閾値の妥当性は §コスト試算の感度分析で検証する。
  4. 実装 (滞留 lint 稼働) が受理後 2 週以内に着手されなければ、ADR-0132 残余リスク 4 点目 (起票だけで放置) の再来として Confirmation 違反扱いとし、実装計画を main と再調整する。
  5. archive への移動コミットのうち消費者退避 (処理完了 PR と同一 PR での移動) が占める割合が月次レビューで 50% を下回ったら、消費者退避が形骸化しているとみなし機構を見直す (盲点 6 への対応)。

コスト試算

  • 起案: 0.25〜0.5 人日 (ADR-0132 のコスト試算が同値を見積もり済み・流用)。
  • 実装 (滞留 lint + adr-lint.yml 組込 + RAG 除外恒久化・main 領分): 約 1 人日 (類似実績: ADR-0130 の規律 3 点セット PR #1687 が lint + CI + 棚卸しで同規模)。
  • 初期一括退避 (221 本の機械振り分け): 約 0.25 人日 (main)。
  • 継続運用: 消費者退避は 1 件 1 分未満 (git mv のみ)。滞留 FAIL 対応は月数件想定 (フォールバック発動は消費者退避の漏れ分のみ)。
  • 直接金銭支出 0 円。

感度分析 (消費者退避失念率 → 月次 FAIL 件数)

週 55 本 × 月 4 週 = 月 220 本新規起票を前提に、失念率別の月次 FAIL 想定件数:

失念率月次 FAIL 件数撤退条件 3 (月 3 件) との関係
1.4%約 3 件発動境界
2.3%約 5 件補助 KPI 目標境界
5.0%約 11 件撤退条件 3 発動
10.0%約 22 件撤退条件 3 発動

補助 KPI 目標 (≤ 5 件/月) は失念率 2.3% 以下を仮定している。過去類似プロセスの違反率実績データは現時点で計測機構がなく取得できないため、この仮定は暫定値である。受理後 4 週レビュー時点で滞留 lint の実測 4 値 (直下本数・滞留超過件数・KEEP-UNTIL 件数・消費者退避比率) が出るため、その実測値で閾値を再校正する。

Confirmation

  • 検証手段: 滞留 lint が tasks/prompts/ 直下の本数・滞留超過件数・KEEP-UNTIL 件数・消費者退避比率 (archive への移動コミットのうち処理完了 PR と同一 PR での移動が占める割合) の 4 値を CI ログに出力する。検出ロジック自体は 30 日超のダミーファイルを含む fixture を用いた CI テストで自動検証する。
  • 実行頻度: CI は PR 毎。4 値の集計レビューは月次。
  • 違反時対応: 撤退条件 1〜5 の該当判定を行い、該当すれば見直しに入る。
  • KPI: tasks/prompts/ 直下の現役本数 — 受理 4 週後に 100 本未満 (根拠 = 現状 221 本のうち対応 ADR/PR 完了分と 30 日超滞留分の初期掃除で半減する推定)。以後の定常状態は「直近 4 週の起票分 + KEEP-UNTIL 分」のみ。
  • 補助 KPI: 滞留 FAIL 発生件数/月 (目標 ≤ 5。フォールバックは消費者退避の漏れ回収なので 0 が理想)。消費者退避比率 ≥ 50% (機構設計思想の維持)。

参照 (References)

  • 関連 ADR:
    • ADR-0132: 親決定。本 ADR は ADR-0132 が委譲した退避の具体機構 (行き先) を所有し、その撤退条件 (受理後 30 日以内に本 ADR が Accepted) と Confirmation (b)(c) を充足する。
    • ADR-0130: 「CI が止める規律 + 例外は理由付き登録」のパターンを踏襲する (滞留 FAIL / KEEP-UNTIL は同 ADR の check-new-pages / EXCEPTIONS と同型)。
    • ADR-0042: Type 1 昇格フローの受け皿。昇格時は同 ADR の Type 1 管理 (SemVer・eval CI) に編入する。ADR-0042 本体は Immutable のため改訂しない。
    • ADR-0106: tasks/prompts/ (archive 含む) がカタログ走査対象外であることは ADR-0132 で正典化済み。本 ADR はこれを変更しない。
  • 関連 PR/Issue: -
  • 外部資料: -