ADR-0161: UC スライス開発の MAS GAS-MVP Build / Verify ライフサイクル (Stage 5-6) を独立 ADR として確立する

• Status: Accepted
• Mode: Standard
• Kruchten Type: Existence/Executive
• Scope: platform
• Implementation Status: Not Started
• 起案者: [email protected]
• 起案日時 (JST): 2026-06-20 19:29
• 承認日時 (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-15 (KPI 4 = UC-4-S01 Stage 6 判定記録締切) / 2026-09-19 (KPI 2 = refine 参照 ≥ 2 件チェック + 撤退条件評価)

コンテキスト

1.1 背景

ADR-0028 は UC スライス開発を「探索 (Stage 1-2) / 検証 (Stage 3-6)」の 6 段ワークフローとして 1 本に定義したが、運用してみると性質の異なる 2 ライフサイクルが混在することが 2026-06 監査で表面化した。一方は DRP (何を作るか発見し ADR・仕様に落とすまで) で 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 の決定に基づき、MAS GAS-MVP Build/Verify ライフサイクル (概念上の Stage 5-6) を独立した子 ADR として確立する。同時起案の ADR-X (DRP Discovery/Decision Stage 1-4) と対をなし、Stage 4 (Spec 生成) の出力を入力として受け取る継ぎ目を持つ。

1.2 現状 (As-Is)

ADR-0028 の implementation_status は「In Progress (残=完了条件 #4: UC-4-S01 の Stage 6 判定記録が changelog に未記録・期限 ≤2026-06-30 で撤退トリガー)」となっており、MAS の Stage 6 未達と DRP の活発な稼働が同じ 1 本の ADR で並存している。Walking Skeleton 4 要素 (認証 / DDL / 監査ログ / Feature Flag) の Stage 4-5 横断適用範囲は ADR-0028 と ADR-0021 の両方に分散し、GAS=MVP プラットフォームの位置づけ (検証用・本番移行は別ライフサイクル) も ADR-0028 §1.4 制約に埋もれている。

1.3 課題

責務単一化が起きていない現状の実害: (1) 上記 implementation_status の誤較正、(2) Stage 6 判定記録条件が ADR-0028 完了条件 #4 として混在 ADR の責務に紐づくため、DRP 稼働量で隠蔽されて MAS の停滞が可視化されない、(3) Walking Skeleton 4 要素の参照経路が不明瞭、(4) GAS=MVP プラットフォームの位置づけが ADR レベルで子 ADR として独立宣言されていない。

加えて、MAS Stage 6 未達の根本原因が「ADR の責務混在」のみか「GAS 実装作業そのものの未着手」「技術的ブロッカー」も含むかの因果経路は未確定であり、本 ADR の構造整備は Walking Skeleton / GAS=MVP / Pivot 判定の参照経路を 1 か所に集約することで「実装着手のためのエントリポイントを単一化」する効果に貢献するが、実装リソースの確保自体は別途 ADR-Y 受理後の製品ロードマップ判断に委ねる。

1.4 制約・要件

• ADR-0152 §決定 (umbrella + 2 子 ADR 構造) を実装すること
• ADR-0021 / ADR-0029 / ADR-0030 の参照経路を破壊しないこと
• ADR-0028 完了条件 #4 の撤退トリガー期限を製品ロードマップで再設定可能にすること
• 正典ツールは GAS 実装系 (mas/ / clasp / 監査ログ機構 / Walking Skeleton 4 要素実装テンプレート) に限定
• 本番移行 (GCP / ローカル LLM) は ADR-Y の外側として ADR-0028 §1.5 Non-Goals を継承

1.5 目標 (To-Be)

MAS の「実装 → 実機検証 → Pivot 判定」を独立した 1 ライフサイクルとして定義し、Stage 6 判定記録条件・撤退トリガー期限・Walking Skeleton 4 要素・GAS=MVP プラットフォーム位置づけ・Pivot 判定 (Pass/Pivot/Fail) を ADR-Y 本文 1 か所に集約する。Non-Goals: 本番移行ライフサイクル、GAS 実装リソースの調達判断そのもの。

決定

〔X〕 MAS の「実装 → 実機検証 → Pivot 判定」を独立した 1 ライフサイクルとして定義する設計で 〔Y〕 ADR-0028 の Stage 5-6 部分を明示的に refine し責務を単一化することにより 〔A〕 ADR-0028 完了条件 #4 (Stage 6 判定記録) を子 umbrella の責務として曖昧に残すのではなく 〔Z〕 Stage 6 判定記録条件と撤退トリガー期限を ADR-Y に再帰属させ、製品ロードマップで再設定可能にする。〔B〕 これにより DRP 稼働量と MAS Stage 6 未達が指標として分離されて MAS 停滞の可視化を構造的に担保し 〔C〕 Walking Skeleton 4 要素・GAS=MVP プラットフォーム位置づけ・Stage 6 ピボット判定 (Pass/Pivot/Fail) を ADR-Y 本文で 1 か所に集約することで参照経路を明確化する。

ADR-Y が定義するライフサイクル (Stage 5-6):

• Stage 5 (Build / Implement): spec-gen-pipeline (Stage 4 の出力) が提供する開発仕様書を入力に、GAS で UC スライスを実装する段階。Walking Skeleton 4 要素 (認証 / DDL / 監査ログ / Feature Flag) はこの段階で横断的先行実装制約として組み込まれる。スライスの初回実装から横串で貫通させ、後追い追加を禁じる (移行コストが指数的に増大するため)。正典ツール: npm run push:dev / clasp / 監査ログ機構。入力契約として、ADR-0029 が出力する開発仕様書の必須フィールド (および ADR-0029 §出力スキーマへの固定アンカー参照) を Stage 5 受け入れ条件とし、ADR-0029 側の出力形式変更時は ADR-Y の入力契約節を同期更新する義務を ADR-0029 KPI に明記する (盲点 #1 対応)。法定保存義務のある記録については GAS 上の監査ログを MVP 検証目的に限定し、別途 GCS または社内ストレージへ二重書き込みすること (電子帳簿保存法・内部統制報告制度の最長 10 年保持要件への適合確認を Stage 5 完了条件に追加・盲点 #5 対応)。
• Stage 6 (Verify + Pivot Gate): npm run push:dev/prod + GAS 上動作確認 → 98_audit_log 記録 → Pass / Pivot / Fail(技術) 判定を docs/_internal/02_project/usecase_dev_mapping.md の stage6_verdict 列に記録。判定は代表取締役の月次観察に依存する。Pass = 動いていて使われる / Pivot = 動くが使われない・解くべき問題がずれていた / Fail(技術) = 実装できない or 監査要件を満たせない。判定権者単一依存への対処として、バックアップ承認者 (CTO 代行) を指名し、月次観察スキップ時は最大 2 週間の自動延長ルールを適用、stage6_verdict 記録の書き込み担当者 (Driver) を明示し、Stage 6 観察の 2 週前にカレンダーアラートを設定する (盲点 #3 対応)。

正典ツールは GAS 実装系 (mas/ / clasp / 監査ログ機構 / Walking Skeleton 4 要素実装テンプレート)。本番移行 (GCP / ローカル LLM) は ADR-Y の外側の別ライフサイクルとして将来 ADR に委ねる (ADR-0028 §1.5 Non-Goals を本 ADR でも継承)。

判断基準 (Decision Drivers)

3.1 評価軸

K.O. criterion: Must 軸 (#maintainable / #operable / #reliable) の score < 3 は不採用。#reliable を Must に昇格させたのは、本 ADR の存在意義が「DRP 稼働で MAS 停滞が隠蔽されない指標分離」そのものであるため。

3.2 評価軸 × 案スコア表

検討した代替案 (Alternatives Considered)

• 案 A: 本 ADR を起案しない (ADR-0152 で十分とみなす) — ADR-0152 は構造宣言に留まり、Stage 5-6 側の責務単一化と Stage 6 判定記録条件の帰属確定が伴わない。ADR-X だけを起案して ADR-Y を欠くと、ADR-0152 KPI 1 (Stage 6 判定記録条件が ADR-Y のみに存在) の grep 検証時に ADR-Y が存在しないため「ADR-Y 上に 1 件」を満たせず KPI 1 が達成不能。#operable K.O. 不通過。不採用。
• 案 B: ADR-X / ADR-Y を 1 本に統合 (Stage 1-6 を refine 子) — 結局 ADR-0028 と同じ責務混在に戻り、#maintainable と #reliable の K.O. を通過しない。ADR-0152 §代替案 C「完全 supersede」と同等の認知負荷で、umbrella 維持の前提を覆す。不採用。
• 案 C: ADR-Y を起案するが Stage 6 判定記録条件は ADR-0028 (umbrella) 側に残す — 期限再設定のたびに umbrella を書き換えざるを得ず ADR-0152 KPI 4 (umbrella-readonly) と矛盾。#operable K.O. 不通過。不採用。
• 案 D (採用): ADR-Y を独立起案し Stage 6 判定記録条件・撤退トリガー期限を再帰属 — ADR-0152 §決定の確定済構造。期限を製品ロードマップで再設定する余地が確保され、ADR-Y 本文を編集する形で運用継続できる。

影響 (Consequences)

5.1 正の影響 (Good)

• Stage 6 判定記録条件が ADR-Y 単独に帰属することで、DRP 稼働量と MAS Stage 6 未達が指標として完全分離される。
• Walking Skeleton 4 要素 / GAS=MVP / Pivot 判定の 3 概念が ADR-Y 本文 1 か所に集約され、ADR-0021 + ADR-0028 に分散していた参照経路が明確化。
• 撤退トリガー期限を製品ロードマップ判断で書き換えるとき ADR-Y 本文だけを編集すればよい (umbrella ADR-0028 を触らない)。
• Stage 5 入力契約 (ADR-0029 出力スキーマへの固定アンカー) を明示することで spec-gen-pipeline の破壊的変更が検証ゲートを発火させる構造になる (盲点 #1)。

5.2 負の影響 (Bad)

• ADR-0028 の implementation_status 本文記述「残=完了条件 #4: UC-4-S01 の Stage 6 判定記録が changelog に未記録・期限 ≤2026-06-30 で撤退トリガー」を本 ADR 受理後に ADR-Y へ移管する追加作業が発生。umbrella 化 (ADR-0152 KPI 4) と同タイミングで実施する必要があり、ADR-X / ADR-Y の両方受理が前提となる順序制約が生じる。
• ADR 構造整備のみでは MAS Stage 6 未達の根本原因 (実装リソース不足の可能性) を解消しないため、ADR-Y 受理後も KPI 4 が達成されない場合「ADR-0152 のみで十分だった」と評価されるリスクが残る (盲点 #6)。本 ADR は実装エントリポイントの単一化に寄与するが、リソース確保は別議題。
• ADR-0029 出力スキーマ変更時に ADR-Y 入力契約節の同期更新義務が ADR-0029 側 KPI に追加されることで、ADR-0029 の改訂コストが微増。

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

• ADR-X (Stage 1-4) と ADR-Y (Stage 5-6) の継ぎ目は「Stage 4 Spec → Stage 5 Build」となる。spec-gen-pipeline の出力 (開発仕様書) を ADR-Y の入力契約として明示するため、両 ADR の参照節で相互参照が必要。
• 法定保存義務のある記録の GCS / 社内ストレージへの二重書き込みは MVP 期間の運用コストを増やすが、電子帳簿保存法・内部統制報告制度への適合を MVP 段階から確保する。
• Stage 6 判定のバックアップ承認者・自動延長ルール導入により、月次観察スキップ時の判定遅延リスクは緩和されるが、判定権の分散に伴う合意形成コストが発生。

撤退条件 (Rollback Plan)

• 3 ヶ月時点 (≤ 2026-09-19) で ADR-Y が MAS 実装フェーズの後続 ADR から refine 参照を 0 件しか受けない場合、本 ADR を status: deprecated へ遷移させ、ADR-0152 §撤退条件「umbrella 再統合」へ縮退 (案 A 縮退)。
• 2026-09-15 までに Stage 6 判定記録が 1 件も生成されない場合 (ADR-0152 §撤退条件と整合)、製品ロードマップ上の MAS 投資継続/撤退をステークホルダーに上申。本 ADR を維持するか deprecated 化するかは上申結果に従う。
• Walking Skeleton 4 要素の Stage 5-6 横断適用が運用上機能せず、要素が後追い追加される実例が連続 3 件発生したら、ADR-Y の「横断的先行実装制約」前提を再評価する (案 B 縮退または前提改訂)。
• ADR-Y を deprecated 化する場合、deprecated 化と同時に旧 ADR-0028 完了条件 #4 の帰属先を ADR-0028 umbrella に差し戻すか新たな ADR-Z へ移管する手順を必ず実行し、帰属が空白になる時間窓をゼロにする (盲点 #2 対応)。撤退トリガー期限の保持・更新責任者は移管先 ADR の Driver が継承する。

コスト試算

• 本 ADR 起案: DRP run 1 本 約 0.5 ドル + 人間レビュー 0.5〜1 時間。
• 受理後の参照張替 (ADR-0021 / ADR-0029 / ADR-0030 の Stage 5-6 言及を ADR-Y へ参照変更、ADR-0028 完了条件 #4 を ADR-Y へ移管): 約 1 時間。
• Walking Skeleton 4 要素のテンプレ言及更新 (ADR-Y を refines として明示): 約 0.3 時間。
• 撤退トリガー期限の再設定 (ADR-0028 完了条件 #4 期限 ≤ 2026-06-30 を製品ロードマップで判断 → ADR-Y 本文を更新): 約 0.5 時間 (期限到来時の判断コストは別途)。
• 合計: 約 2〜3 人時 + LLM 約 0.5 ドル (ADR-0152 §コスト試算で先取りされた範囲内)。

備考: 過去の ADR-0028 監査で corrigendum PR が 4 本に膨らんだ実績があり、ADR-0021 / ADR-0029 / ADR-0030 の言及が想定より広範な場合、張り替え工数は試算の 1.5〜2 倍に振れる可能性。受理後の張り替え PR で完全リスト化を先行する。

Confirmation

• KPI 1 (ADR-0152 KPI 1 と相補): Stage 6 判定記録条件 (旧 ADR-0028 #4 相当) が ADR-Y にのみ存在し ADR-X には存在しない。
  • 検証手段: grep でリポジトリを機械確認 (ADR-Y に 1 件 / ADR-X に 0 件)
  • 実行頻度: ADR-X / ADR-Y 承認時および月次 adr-lint
  • 違反時対応: 該当 ADR を修正し再レビュー
• KPI 2: 本 ADR が MAS 実装フェーズの後続 ADR から ≥ 2 件 refine 参照を受ける (3 ヶ月時点 = 2026-09-19、ADR-0152 KPI 2 と整合)。
  • 検証手段: 型付き辺グラフ自動集計 (node scripts/adr-index.mjs 出力)
  • 実行頻度: 月次 adr-lint
  • 違反時対応: 撤退条件に従い deprecated へ
• KPI 3: Walking Skeleton 4 要素 (認証 / DDL / 監査ログ / Feature Flag) が ADR-Y 本文で Stage 5-6 横断適用制約として明示され、ADR-0021 / ADR-0028 への二重参照が解消する。
  • 検証手段: ADR-0021 / ADR-0028 / ADR-Y の Walking Skeleton 言及箇所を grep し ADR-Y 単独で完結することを確認
  • 実行頻度: ADR-Y 承認時および月次 adr-lint
  • 違反時対応: 該当箇所を ADR-Y へ集約する修正 PR を発行
• KPI 4: UC-4-S01 (ランウェイ対応スライス) の Stage 6 判定記録が ≤ 2026-09-15 までに docs/_internal/02_project/usecase_dev_mapping.md に Pass/Pivot/Fail のいずれかで 1 件以上記録される (旧 ADR-0028 完了条件 #4 を ADR-Y で再宣言)。
  • 検証手段: grep -c "stage6_verdict" docs/_internal/02_project/usecase_dev_mapping.md → ≥ 1 かつ verdict 列の値が Pass / Pivot / Fail のいずれかであること、および判断根拠フィールド (reason または evidence) が最低 50 文字以上記述されていることを adr-lint スクリプトに実装して機械検証する (盲点 #4 対応)
  • 実行頻度: 月次 adr-lint および 2026-09-15 締め切り時
  • 違反時対応: 製品ロードマップ判断で期限を ADR-Y 本文に再設定するか deprecated へ
• KPI 5: ADR-0028 完了条件 #4 の本文記述が ADR-Y 承認後 2 週間以内に ADR-Y へ移管完了する (ADR-0152 KPI 4 = umbrella-readonly と整合)。
  • 検証手段: ADR-0028 本文に「完了条件 #4」の生記述が残らないことを grep 確認
  • 実行頻度: ADR-Y 承認後 2 週間時点および月次 adr-lint
  • 違反時対応: 移管 PR を発行し再検証

参照 (References)

• 関連 ADR:
  • ADR-0028: refines (親 umbrella・ADR-0152 で umbrella 化される)。逆辺 refined_by: [ADR-Y] は ADR-0028 へ両端宣言。
  • ADR-0152: refines (構造改訂者・本 ADR が ADR-0152 の決定を実装)。逆辺 refined_by は ADR-0152 へ追記。
  • ADR-X (同時起案・本日 DRP 投入済 id=adr-drp-discovery-decision-lifecycle): 並立 (DRP Discovery/Decision Stage 1-4 を担当)。relates_to で関連付け。継ぎ目 = Stage 4 Spec → Stage 5 Build。
  • ADR-0021: refines (UC スライス × Walking Skeleton × Now/Next/Later の三本柱。Walking Skeleton 4 要素の Stage 5-6 横断適用制約を本 ADR が継承)。
  • ADR-0029 / ADR-0030 / ADR-0034: 辺張替対象 (ADR-Y 寄り見込みは ADR-0029 = Spec/Impl Pipeline、ADR-0152 §1.4)。本 ADR 承認後 2 週内に張り替え (ADR-0152 KPI 3)。
• 関連 PR/Issue:
  • UC-4-S01: Stage 6 実機到達対象スライス (KPI 4 検証対象)。
• 外部資料: -