ADR-0160: UC スライス開発の DRP Discovery / Decision ライフサイクル (Stage 1-4) を独立 ADR として確立する

• Status: Accepted
• Mode: Standard
• Kruchten Type: Existence/Executive
• Scope: platform
• Implementation Status: Not Started
• 起案者: [email protected]
• 起案日時 (JST): 2026-06-20 14:56
• 承認日時 (JST): 2026-06-21
• Approver Role: platform
• Approver Who: [email protected]
• Driver: [email protected]
• Consulted: Decision Pipeline AI 審査 (Gate 0-4)
• Review After: 2026-09-19 (= 撤退判定タイミングと同期)

コンテキスト

1.1 背景

ADR-0028 は UC スライス開発を「探索 (Stage 1-2) / 検証 (Stage 3-6)」の 6 段ワークフローとして 1 本に定義したが、運用してみると性質の異なる 2 ライフサイクルが混在することが 2026-06 監査で表面化した。一方は DRP (何を作るか発見し ADR・仕様に落とすまで: 研究 → ADR → spec) で、drp-ops / spec-gen-pipeline / ADR-0117 以降として独立に高度進化し現在フル稼働している。もう一方は MAS (GAS で実装し実機で Stage 6 検証・Pivot 判定する) でまだ一度も Stage 6 まで到達していない。ADR-0152 (Accepted 2026-06-15) はこの混在を「umbrella + 2 子 ADR への refine 分割」として承認した。本 ADR は ADR-0152 の決定に基づき、DRP Discovery/Decision ライフサイクル (概念上の Stage 1-4) を独立した子 ADR として確立する。同時起案の ADR-Y (MAS GAS-MVP Build/Verify Stage 5-6) と対をなす。

1.2 現状 (As-Is)

ADR-0028 が DRP / MAS の双方を 1 本で記述し、drp-ops / spec-gen-pipeline / ADR-0117 以降の DRP 系 ADR は親として ADR-0028 を参照している。MAS は Stage 6 到達 0 件のまま、DRP 側は ADR-0117 以降が高度進化してフル稼働している。

1.3 課題

責務単一化が起きていない現状の実害は以下:

1. ADR-0028 の implementation_status が別ライフサイクルの PR (#661-668 = 8 件) を誤って指していた。corrigendum PR が 4 本に膨らみ、累積工数は約 (要記入: 達希補完) 人時に達した。
2. 撤退条件 #4「Stage 6 判定記録 0 件」が DRP 稼働量を無視して MAS の停滞を測れない構造になっている。
3. drp-ops / spec-gen-pipeline / ADR-0117 以降の DRP 系 ADR が「親 = ADR-0028」を参照しても、ADR-0028 本文は MAS 段 (Stage 5-6) の記述を多く含むため誤参照を誘発する。
4. Stage 2 Backlog / Stage 3 Decision の帰属が ADR 上で曖昧で、tasks/proposals/ と drp-ops の二重トリガー懸念が残る。

1.4 制約・要件

• ADR-0152 §決定の「umbrella + 2 子 ADR」構造を覆さないこと (ADR-0028 を umbrella として残す)。
• ADR-Y (MAS Build/Verify Stage 5-6) と並立し、Stage 4 / Stage 5 の継ぎ目を仕様 → コードの形で定義すること。
• ADR-0117 以降の DRP 系 ADR からの refine 参照を破壊しないこと (張り替えで対応)。
• ADR-0029 / ADR-0034 の辺張替を承認後 2 週間以内に完了させること (ADR-0152 KPI 3)。
• Stage 6 判定記録条件 (旧 ADR-0028 #4) を本 ADR 本文に持ち込まないこと (ADR-Y へ帰属)。

1.5 目標 (To-Be)

DRP の「発見 → 意思決定 → 仕様化」を独立した 1 ライフサイクルとして定義し、Stage 2 Backlog / Stage 3 Decision を ADR-X 単独に帰属させ、drp-ops / spec-gen-pipeline / ADR-0117 以降の張り替え先を明確化する。Non-Goals: MAS の Build/Verify (Stage 5-6) の規定、ADR-0028 の完全 supersede。

決定

DRP の「発見 → 意思決定 → 仕様化」を独立した 1 ライフサイクル (概念上の Stage 1-4) として定義する設計で、ADR-0028 の Stage 1-4 部分を明示的に refine し責務を単一化することにより、正典ツール (drp-ops / spec-gen-pipeline) を本 ADR の被 refine 先として明示しないままにせず、Stage 2 Backlog / Stage 3 Decision の帰属を本 ADR に確定させる。これにより MAS の Stage 6 未達が DRP 稼働量で隠蔽される誤較正を構造的に解消し、ADR-0117 以降の DRP 系 ADR が ADR-0028 ではなく本 ADR を refines する張り替えを進めることで、umbrella 化の形骸化 (ADR-0152 §影響 盲点 #8) を防ぐ。

本 ADR が定義するライフサイクル (Stage 1-4):

• Stage 1 (研究 / Discovery): Deep Research 3 モデル実行 (scripts/run_deep_research.mjs) + RQ 一覧 (docs/research/INDEX.md) で管理。問いを立て・調査結果を docs/research/ に格納するまで。
• Stage 2 (Backlog): tasks/proposals/ + TODO_future.md (DOC-OPS-NN / DPJ-NN / MAS-NN id 体系) で起案候補を蓄積。本 ADR で ADR-X 帰属として確定 (継ぎ目)。
• Stage 3 (Decision): Decision Pipeline (Cloudflare Workers) で ADR を起案・審査・受理 (triage → socratic → consistency → parallel-review → scoring → numbering)。本 ADR で ADR-X 帰属として確定 (継ぎ目)。
• Stage 4 (Spec): spec-gen-pipeline (B2→B3→B4→B5→B6) で開発仕様書を生成 (Claude 直書き禁止)。Walking Skeleton 4 要素 (UI/Auth/Persistence/Test) の注入はここで完了し、ADR-Y (Build) との継ぎ目を成す。Stage 4 完了の判定基準は「spec-gen-pipeline B6 出力物のファイルパスと Walking Skeleton 4 要素チェックリストへの合格をもって完了」とし、ADR-Y の Stage 5 開始条件と相互参照する条項を ADR-Y 起案時点で同期する (盲点 #1 対応)。

正典ツールは drp-ops Skill / spec-gen-pipeline Skill / Decision Pipeline (drp/)。これらを本 ADR が refines 対象として宣言することで、ADR-0117 以降の DRP 系 ADR の張り替え先が明確になる。

判断基準 (Decision Drivers)

3.1 評価軸

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

3.2 評価軸 × 案スコア表

加重和は K.O. 通過候補のタイブレーク用 (Suhr 1999 CBA 準拠)。

検討した代替案 (Alternatives Considered)

• 案 A: 本 ADR を起案しない (ADR-0152 で十分とみなす) — ADR-0152 は「umbrella + 2 子 ADR への分割」の構造宣言に留まり、Stage 1-4 側の責務単一化と Backlog/Decision 帰属の機械確定が伴わない。ADR-0152 KPI 1 (Stage 6 判定記録条件が ADR-Y のみに存在) の検証も、ADR-X 本文がなければ grep 対象として ADR-X 側で 0 件であることを示せず確認できない。さらに ADR-0152 への追記節で代替する選択肢を検討したが、(a) ADR-0152 のスコープ宣言は「構造改訂の決定」であって「Stage 1-4 のライフサイクル定義」を含まないため本文へ Stage 1-4 詳細を追記すると ADR-0152 自身のスコープを逸脱し、(b) Stage 2/3 帰属確定は子 ADR の存在を前提とする Decision Pipeline 承認フローで処理すべき新規決定であり ADR-0152 の corrigendum では承認権限が異なる、という 2 点で達成できない (盲点 #9 対応)。#operable の K.O. を通過しない。不採用。
• 案 B: ADR-X / ADR-Y を 1 本に統合 (Stage 1-6 を refine 子) — 結局 ADR-0028 と同じ責務混在に戻り、#maintainable の K.O. を通過しない。ADR-0152 §代替案 C「完全 supersede」と同等の認知負荷で、ADR-0028 を umbrella として残す ADR-0152 §決定の前提を覆す。不採用。
• 案 C (採用): ADR-X (本 ADR・Stage 1-4) と ADR-Y (Stage 5-6) を別個に起案 — ADR-0152 §決定で確定済の構造。Stage 2 Backlog / Stage 3 Decision を ADR-X、Stage 6 判定記録条件を ADR-Y に帰属させる。

影響 (Consequences)

5.1 正の影響 (Good)

• drp-ops / spec-gen-pipeline / ADR-0117 以降の正典ツール参照が本 ADR を refines として明示できるようになり、ADR-0028 への直接参照が消える (umbrella 化との整合)。
• Stage 2 Backlog / Stage 3 Decision の帰属が ADR レベルで確定し、tasks/proposals/ と drp-ops の二重トリガー懸念がドキュメント上は解消される。
• Stage 1-4 の指標 (起案数 / 受理率) が DRP 単独で読めるようになり、MAS Stage 6 未達と分離されて誤較正が解消される。

5.2 負の影響 (Bad)

• ADR-0117 以降の DRP 系 ADR 群が ADR-0028 を参照している場合、本 ADR の受理後に ADR-X への張り替えが追加コストとして発生する (ADR-0152 §影響 5.2 盲点 #8 への対応)。
• 依存集約点の単純移動リスク (盲点 #2): ADR-0117 以降の 30 本超を一括張り替えすると、ADR-X が「別名の ADR-0028」になり同じ単一依存集約の密結合問題が再発する恐れがある。対策として、張り替え対象を drp-ops 系 / spec-gen 系 / Decision-Pipeline 系の機能クラスタに分類し、それぞれが中間レイヤ ADR を介して ADR-X を参照する階層構造を採用方針とする。単純一括張り替えは行わない。
• 二重トリガーのランタイム残存リスク (盲点 #3): ADR 上の帰属宣言は drp-ops Skill と Cloudflare Workers Decision Pipeline のランタイム排他制御を提供しない。tasks/proposals/ に存在する ID は drp-ops が無視するフィルタを排他ルールとして定義し、実装責任を KPI 4 に含める (Confirmation §6 で明示)。
• 過渡期 CI 誤検知リスク (盲点 #4): 30 本超の張り替え PR が分散・並走すると CI 辺グラフチェックが旧辺 (ADR-0028) と新辺 (ADR-X) の共存を重複辺エラーと誤検知する恐れがある。対策として「辺移行ブランチ」での一括マージ戦略を採用し、CI の過渡期許容モード (旧辺・新辺共存を一定期間許可するフラグ) の必要性を承認前調査で判定する。
• 共有インフラ障害の双方停止リスク (盲点 #5): spec-gen-pipeline は ADR-X (DRP) と ADR-Y (MAS Build) の双方に機能依存する共有インフラであり、その障害は両ライフサイクルを同時停止させる (Sam Newman, Building Microservices 2nd ed. §4 参照)。spec-gen-pipeline を独立インフラ ADR (ADR-Z 相当) として分離する代替案は「現時点で spec-gen-pipeline は単一の責務 (仕様生成) に閉じており、独立 ADR 化の便益より管理コストが上回る」として採用しない。フォールバック手順として、spec-gen-pipeline 停止時は Stage 4 出力を手動 Markdown で代替し ADR-Y Stage 5 を遅延起動する手順を運用 playbook に追記する。
• 逆方向の隠蔽リスク (盲点 #6): ADR-X 側の起案数・受理率が高い数字を示すことで ADR-Y の進捗停滞への注意が向かなくなる確証バイアスのリスクがある。Confirmation で「ADR-X の月次レポートに ADR-Y (Stage 6 判定記録数) の併記を義務化」し、DRP 指標単独レポートを onboarding_checklist で禁止する。

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

• Stage 4 (Spec) は spec-gen-pipeline で「開発仕様書」を生成する段階で、Walking Skeleton 4 要素 (UI/Auth/Persistence/Test) の注入もここで完了する。spec 出力後の実装は ADR-Y (Build/Verify) の役割で、Stage 4 と Stage 5 の継ぎ目は「仕様 → コード」となる。本 ADR では Stage 4 を含めて 1 ライフサイクルと定義する。

撤退条件 (Rollback Plan)

• 3 ヶ月時点 (≤ 2026-09-19) で ADR-X が DRP 系後続 ADR から refine 参照を 0 件しか受けない場合、本 ADR を status: deprecated へ遷移させ、ADR-0152 の umbrella ADR-0028 のみで運用に戻す (案 A 縮退)。
• Stage 2 Backlog / Stage 3 Decision の帰属が運用上機能せず、tasks/proposals/ や drp-ops が ADR-0028 を直接参照し続ける状態が 3 ヶ月続く場合、本 ADR の存在意義が立たないため deprecated 化を検討。
• onboarding 所要時間が ADR-0152 §1.3 の現状 5〜6 時間から短縮しない場合、ADR-X / ADR-Y の 2 ADR 構造そのものを再評価 (ADR-0152 §撤退条件と整合)。

コスト試算

• 本 ADR 起案: DRP run 1 本 約 0.5 ドル + 人間レビュー 0.5〜1 時間。
• 受理後の参照張替 (ADR-0117 以降の DRP 系 ADR を grep で完全列挙し ADR-X へ張り替え): 約 1 時間 (ADR-0152 §コスト試算で先取り済み)。
• onboarding_checklist の正典参照更新 (探索 = DRP の入口を ADR-X へ): 約 0.3 時間 (ADR-0152 §コスト試算で先取り済み)。
• 合計: 約 2〜3 人時 + LLM 約 0.5 ドル (ADR-Y 起案は別途、ADR-0152 §コスト試算で合算試算済み)。

備考: 過去の ADR-0028 監査で corrigendum PR が 4 本に膨らんだ実績があり、ADR-0117 以降の DRP 系 ADR 群が 30 本超ある場合、張り替え工数は試算の 1.5〜2 倍に振れる可能性。受理後の張り替え PR で完全リスト化を先行する。

Confirmation

• KPI 1: 本 ADR を経由した新規 DRP 提案の受理が 3 ヶ月時点 (= 2026-09-19) で ≥ 3 件 に達する (盲点 #7 対応・張り替え参照ではなく実運用を示す指標)。
  • 検証手段: Decision Pipeline 受理ログから refines: ADR-X を持つ新規 ADR を集計 (node scripts/adr-index.mjs 出力)。PR マージフックで件数をカウントしアラート通知 (盲点 #8 対応・月次 adr-lint だけに依存しない)。
  • 実行頻度: PR マージごと + 月次 adr-lint。
  • 違反時対応: 撤退条件に従い deprecated へ遷移。
• KPI 2: ADR-0028 を refines していた既存 ADR (ADR-0029 / ADR-0034) のうち ADR-X 寄りに再配置する分が、本 ADR 承認後 2 週間以内に張り替え完了する (ADR-0152 KPI 3 と整合)。
  • 検証手段: INDEX 整合性チェック (CI) と PR レビュー。
  • 実行頻度: 承認後 2 週間継続。
  • 違反時対応: 起案者が張り替え PR を提出。
• KPI 3: drp-ops / spec-gen-pipeline Skill description が本 ADR を refines する関係を持つ。
  • 検証手段: skill description の grep。
  • 実行頻度: 承認時 1 回 + 月次 adr-lint。
  • 違反時対応: Skill description 修正 PR を起案者が提出。
• KPI 4: tasks/proposals/ 配下の起案候補が本 ADR の Stage 2 Backlog に帰属する旨を明示し、proposals/ に存在する ID は drp-ops が無視する排他フィルタを実装する (盲点 #3 対応)。
  • 検証手段: proposals README の grep + drp-ops Skill の排他ロジック単体テスト。
  • 実行頻度: 承認後 4 週間以内に実装完了。
  • 違反時対応: drp-ops Skill 改修 PR を起案者が提出。
• KPI 5: Stage 6 判定記録条件 (旧 ADR-0028 #4 / ADR-0152 KPI 1) が ADR-X 本文に 存在しない (grep で 0 件確認)。
  • 検証手段: adr-lint カスタムルールで本文の "Stage 6" 文字列出現箇所を白リスト管理。
  • 実行頻度: 月次 adr-lint。
  • 違反時対応: 起案者が該当箇所を ADR-Y へ移管する PR を提出。
• KPI 6: ADR-X の月次レポートで ADR-Y (Stage 6 判定記録数) を併記する (盲点 #6 対応)。
  • 検証手段: 月次レポートテンプレートに ADR-Y 数値欄を必須化、onboarding_checklist に DRP 指標単独レポート禁止を明記。
  • 実行頻度: 月次。
  • 違反時対応: レポート差し戻し。

参照 (References)

• 関連 ADR:
  • ADR-0028: refines (親 umbrella・ADR-0152 で umbrella 化される)。逆辺 refined_by: [ADR-X] は ADR-0028 へ両端宣言。
  • ADR-0152: refines (構造改訂者・本 ADR が ADR-0152 の決定を実装)。逆辺 refined_by は ADR-0152 へ追記。
  • ADR-Y (同時起案中): 並立 (MAS Build/Verify Stage 5-6 を担当)。relates_to で関連付け。
  • ADR-0029 / ADR-0034: 辺張替対象 (ADR-X 寄りは ADR-0034 の見込み・ADR-0152 §1.4)。本 ADR 承認後 2 週内に張り替え (KPI 2)。
  • ADR-0117 以降: DRP 系 ADR 群、ADR-0028 参照を本 ADR に張り替え対象 (受理後の追加 PR でリスト化 + 張り替え)。
• 関連 PR/Issue: PR #661-668 (ADR-0028 監査で表面化した別ライフサイクル誤指示)。
• 外部資料: Sam Newman, Building Microservices 2nd ed. §4 (共有インフラと境界の議論)。