ADR-0113: 意思決定の確定・記録を支える Decision Pipeline UI/IA を定義する（Decide/Corpus 2 画面新設 + 4 画面 IA + 監査ガード）

• Status: Accepted
• Mode: Standard
• Kruchten Type: Existence/Property
• Scope: platform
• Implementation Status: Not Started
• 起案者: [email protected]
• 起案日時 (JST): 2026-06-04 18:03
• 承認日時 (JST): 2026-06-04 (PR #1403 merge = 受理)
• Deciders: [email protected] (単独)

1. コンテキスト

1.1 背景

JTBD DPJ-001（意思決定を make し、record する）のゴール「ADR が Accepted として確定し、後から想起できる形で記録された」を支える UI が、現行 Decision Pipeline の /chat（起案 → 審査 → PR 作成までで完結）に欠落している。本 ADR は RQ-086（意思決定 JTBD landscape）→ RQ-087（確定・記録 UI/IA の 3 モデル調査・約 $5.39）を入力とし、その Synthesis の裁定（C1〜C6）を IA として確定する。

1.2 現状 (As-Is)

現状の Decision Pipeline には以下 2 機能が UI 上に存在しない:

1. 確定 (Decide): status Proposed → Accepted の遷移と「誰が・いつ・何を根拠に」の権威的記録。現状は GitHub PR を手動 merge し Status: フィールドを手編集するのみで、確定の who/when/basis が PR メタに散逸し監査追跡が困難。
2. 記録・想起 (Corpus): 既存 ADR の一覧・検索・状態俯瞰。現状 docs/adr/ を直接 grep するしかなく、未決 (Proposed) の ADR を一望する手段が無い。

1.3 課題

bizlp は既に ADR 約 104 件を保有し（2026-06-02 時点・docs/adr/ 実数）、想起コスト・滞留見落としが顕在化する閾値に到達している。本セッションで導入した Cross-Val 過剰審査 systemic fix（Part2 goalpost escalate）で Proposed に滞留する ADR を可視化する UI 着地点も現状ゼロ。

なお、「閾値到達」の主観性に関する盲点（盲点 #4）への対応として、MVP リリース前 2〜4 週間でデータ収集フェーズ（現時点の Proposed 件数・平均滞留日数・grep 所要時間の計測値）を先行させることを Open Questions に追加する（計測ツールの実装担当は Q7 として実装フェーズで確定する）。Corpus 画面（3.0 人日）と Decide 画面（2.0 人日）は独立して優先度評価可能であり、必要時に分割 ADR として再裁定する選択肢を残す。

1.4 制約・要件

• 適用範囲: 本 ADR は drp サブシステム（Cloudflare Workers + D1 + KV + Queues、Scope: platform）の UI/IA を対象とし、bizlp 本体の GAS 会計基盤には適用しない。ADR-0010（GAS モジュラーモノリスの数値プレフィックス採番）の命名規約・GAS 実行時制約は本 ADR の対象外であり抵触しない
• 既存 MADR / ADR-0023/0024 / chat.html / KV / D1 / Workers 資産と整合し、新フォーマット規約や二重管理を増やさない
• Accept 後の本文改竄をブロック + override に rationale 必須（MADR immutability 非保証への明示ガード）
• 監査要件の適用範囲は当面「社内ガバナンス用途」とし、外部監査対応（投資家・監査法人・規制当局）が将来的に想定される場合の RFC 3161 タイムスタンプ認証導入可否は Open Questions（盲点 #11）
• n=1 (solo 起案・代表取締役単独 Accept) を前提とするが、将来の multi-approver 拡張を破壊的変更なしに追加できるスキーマ設計とする（盲点 #2/#7）
• 追加金銭支出ほぼ 0 円（新規 LLM 呼出を増やさない）

1.5 目標 (To-Be)

現 /chat を 4 画面 IA に拡張し、DPJ-001 の確定+記録を UI 上で完結させる: Compose（起案）→ Review（審査可視化）→ Decide ★新（確定）→ Corpus ★新（記録・想起）。Non-Goals: multi-approver / 承認パスポリシー / RAG-CASCADE 矛盾検出 / stacked PR / 3-panel cohort review。

2. 決定

現 /chat を 4 画面 IA に拡張し、欠落していた Decide / Corpus の 2 画面を新設する。確定 = Decide 画面の Accept modal でワンクリック status 遷移 + who/when/basis 自動 capture + AI 審査 override 時 rationale 必須。記録の真実の源 = MADR YAML + Confirmation セクション（既存 ADR-0023/0024 と整合）。Accept 後は body 編集を tool 側でブロックし、確定物は docs/adr/ に publish して git 上の immutable な公式記録とする（ハイブリッド = in-app 権威記録 + git publish、Synthesis C1）。記録・想起 = Corpus 画面に単一 corpus テーブル + status group-by board + 保存ビュー 4 本（Proposed / Accepted / Stuck / All）+ time-in-status 滞留検知を実装。AI 審査は advisory 扱いで severity tier（red/yellow/gray）提示、非収束（goalpost / Part2 escalate）は gray tier で Decide 迂回 Accept へ誘導する。

3. 判断基準 (Decision Drivers)

3.1 評価軸

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

3.2 評価軸 × 案スコア表

採択案は K.O. 通過かつ加重和最高。案 X2 は K.O. 通過するが n=1 に過大で加重和も劣る。

4. 検討した代替案 (Alternatives Considered)

• 採用案: Decide/Corpus 2 画面新設 + 4 画面 IA + 監査ガード（ハイブリッド記録）。Good: DPJ-001 を最小画面数で完遂。既存 KV/Pipeline/chat.html を再利用し新規規約ゼロ。Cross-Val 過剰審査の UI 着地（迂回 Accept + 滞留検知）を同時に得る。Bad: Decide/Corpus の新規実装コスト。body 編集ブロックの実装と「正当な訂正」運用の線引きが必要。
• 案 X1: git/PR のみで確定（in-app Decide 画面なし・status を手編集）。Good: 実装コストほぼゼロ。Bad: who/when/basis が PR メタに散逸し監査追跡困難、未決一望不可、想起のたびに grep、goalpost 滞留が不可視。#suitable / #usable Must の K.O. に抵触。
• 案 X2: フル機能（multi-approver + 承認パスポリシー + RAG/CASCADE 矛盾検出 pipeline + stacked PR / 3-panel cohort review）。Good: 大規模組織の網羅的ガバナンス。Bad: n=1 に過大。3 モデル合意で multi-approver は out-of-scope と裁定済（Synthesis C6）。実装・運用コストが MVP を圧迫。
• 案 X3: 既製 ADR ツール採用（Log4brains / Backstage ADR plugin 等）。Good: catalog・検索・静的サイト公開が既製。Bad: 専用 Accept 画面が無く status 編集止まり（3 モデル一致の調査結論）。既存の KV/Pipeline + chat.html と二重管理になり #maintainable 劣化。監査ガード（Accept 後 body lock）を結局別途実装。

5. 影響 (Consequences)

5.1 正の影響 (Good)

• DPJ-001 の確定 + 記録が UI 上で完結し、Accept の監査証跡（who/when/basis + AI score snapshot）が機械可読で残る
• 未決 ADR の一望（保存ビュー 4 本）+ time-in-status 滞留検知で「探す・迷うコスト」を排除
• Cross-Val 過剰審査（Part2 escalate）が Review 表示 → Decide 迂回 Accept として運用フローに着地

5.2 負の影響 (Bad)

• Decide/Corpus 2 画面の新規実装コスト（MVP で 約 8.5 人日想定）
• Accept 後 body 編集ブロックが「typo 等の正当な訂正」を阻害しうる → 訂正は新リビジョン + 監査ログ方式の運用ルールが必要。盲点 #3 指摘の通り「撤退条件への先送り」では不十分なため、MVP スコープに「Errata モード」（軽量訂正フロー: errata フラグ付き diff 記録 + 監査ログ追記）と「新リビジョンフロー」（Supersedes リンク必須・実質的変更用）の 2 系統を明示設計する
• Corpus が増えるまで tag/category filter は無し（≥100 件で再検討）= 一部 facet 検索が当面手動。盲点 #12（スコープクリープ）への対応として MVP リリース時に「現在 104 件では tag/category filter を意図的に省略」する UI バナーを表示し、Should 項目追加は新規 ADR フローを経由するルールとする
• 既存 104 件の status 遷移タイムスタンプ欠落により、time-in-status が新規 Accept 分にしか機能しない期間が発生（盲点 #8）。バックフィルスクリプト（git log から Status: 最終変更 commit 日時を D1 投入、不明分は imported_at マーク）を MVP スコープに含める
• n=1 前提の override rationale が形式的入力に陥り Cross-Val telemetry 改善ループを毀損するリスク（盲点 #13）。rationale 入力に最低 20 文字閾値 + カテゴリタグ必須化で形骸化を抑止

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

• 真実の源 = git (immutable) vs in-app (status/監査の権威記録): ハイブリッド（C1）で両取りするが、Decide↔docs/adr/ の同期実装コストが発生（Open Questions Q1）。盲点 #1/#6 指摘の通り、Workers + D1 + KV + webhook の非同期チェーンにおける部分トランザクション失敗を防ぐため、Accept 操作を単一 saga として設計し、各ステップに補償トランザクションを定義する。具体的には (a) D1 status 書き込み (b) MADR body hash snapshot (c) GitHub webhook PR Status 更新 の各失敗時に Pending-Publish 中間 status を UI 警告として表示し、webhook 失敗時は D1 status を Proposed に巻き戻す。hash 計算対象は Status フィールドを除いた body 本文に限定、Queues 冪等キーは ADR ID + Accept タイムスタンプで構成。ステージング環境で E2E テスト必須化
• 監査強度（body lock 必須）vs 編集の柔軟性: 監査要件を優先し lock を採用、柔軟性は Errata モード + 新リビジョン運用で確保
• 矛盾検出の深さ（手動 supersede vs semantic RAG）: 当面は手動 + 全文検索、semantic は near-term Should（C2、corpus 約 120 件到達 or 明示要求時）
• n=1 前提 vs 将来の multi-approver 拡張: 盲点 #2/#7 への対応として、D1 の acceptors カラムを当初から JSON 配列型（単一要素でも配列）で定義し、status 列挙型に Awaiting-Second-Review 等の将来値を予約。UI は n=1 用シンプル表示を維持しデータ層のみ拡張可能化。multi-approver 対応時の migration 手順は Open Questions に明記
• Cross-Val Part2 escalate フラグとの双方向依存（盲点 #5）: escalate フラグのデータスキーマ（フィールド名・型・発火条件）を本 ADR Appendix で「インターフェイス契約」として固定。Part2 撤退時は gray tier 表示を非表示化 or 汎用 override に吸収する設計を予め定義
• Jr 引き継ぎ境界（2026-10 入社想定）: Jr が保守で触れる範囲は Corpus 画面の表示層（テーブル・保存ビュー定義・バッジ表示）に限定する。Accept saga・補償トランザクション・webhook・Queues 冪等キーはコア層として起案者管理とし、変更には ADR 起案を要する設計境界とする

5.4 ADR-0018（Markdown + git = 管理記録の真実の源）との整合

ADR-0018（TODO 3 軸管理・GitHub Issues 移行保留）が示した「管理記録は Markdown + git を真実の源とする」方針と本 ADR のハイブリッド記録は両立する:

• 意思決定の内容（ADR 本文）の真実の源は引き続き docs/adr/ の Markdown + git。D1 が権威を持つのは「status 遷移イベントと監査メタ（who/when/basis/override rationale）」のみで、これは Markdown が構造的に保持・検証できない種類の記録である（git commit author は改竄可能・MADR は immutability 非保証）
• 両者が乖離した場合（改竄検知アラート時を含む）は git 本文を正とし、D1 は乖離の発生自体を監査ログとして記録する
• Decide 画面の Accept は「git への publish（webhook）を伴って初めて完結する」saga として設計するため、in-app 状態が git に先行して権威化することはない（Pending-Publish 中間 status の間は確定扱いにしない）
• ADR-0018 が回避した「外部システムへの管理記録の移転」（GitHub Issues）と異なり、本 ADR の D1 は Markdown 記録を置換せず補完する

6. 撤退条件 (Rollback Plan)

• MVP リリース 4 週後: Accept modal 経由の確定が全 Accept の 95%（盲点 #10 指摘により 80% から引き上げ）未満なら IA を見直す。初期 4 週間は日次モニタリング。併せて git 側で Accept modal を経由せず Status: Accepted に変更された commit を検出する CI lint を実装し、旧フロー迂回を技術的に困難化
• MVP リリース 4 週後: 「未決 ADR を探す操作」が保存ビューで 1 操作（≤2 クリック）で完了しない事例が月 3 件以上発生したら Corpus IA を再設計
• body 編集ブロックが正当な訂正を阻害し回避運用が月 2 件以上発生したら Errata モードの拡張可否を再評価（先送りではなく初期実装するため発火閾値は下がる想定）
• Corpus の Proposed 中央値滞留が 14 日を超え続ける場合、滞留検知 UI の表示設計を再評価
• 撤退手順: (1) D1 audit_record テーブルを read-only 化 (2) docs/adr/ への publish webhook を停止 (3) Compose/Review 画面のみ残し Decide/Corpus を feature flag で非表示 (4) 監査ログを CSV export して保全

コスト試算

• 人件費換算: 自工数のみ（起案者 = 実装者）。外部支出 0 円
• 運用コスト増分: Workers / D1 / KV / Queues は現行 Decision Pipeline の無料枠内で稼働中であり、本 ADR の増分（D1 行 = ADR 件数オーダー 約 110 行 + 月数十件の status 遷移イベント、webhook 呼び出し = Accept 時のみ）は枠内で月 $0 見込み。月次 Cloudflare 請求確認（既存 ops チェックリスト）で超過を監視する
• 新規 LLM 呼び出しは増やさない（§1.4 制約。rationale の LLM 妥当性チェック等を将来追加する場合は別途見積もる）
• Q8（Corpus 先行分割）を採る場合の Phase 1 は Corpus 3.0 + バックフィル 0.5 + ドキュメント 0.5 = 約 4.0 人日に縮退する

Confirmation

• 検証手段 1（機械・CI/lint）: Accept された ADR の status 遷移レコードに who / when / basis（override 時は rationale 20 文字以上 + カテゴリタグ）が全件揃っているか。KPI: 記録率 100%。実行頻度: PR ごと + 日次。違反時: merge block。前提: 盲点 #1 対応として Accept saga の全ステップ完了（D1 + snapshot + webhook publish）後に検証実行されること、Pending-Publish 中間 status は検証対象外
• 検証手段 2（機械・改竄検知）: Accept 後の docs/adr/*.md 本文 hash が Accept 時 snapshot と一致するか。hash 計算対象は Status フィールドを除いた body 本文に限定（盲点 #6 対応）。実行頻度: CI 毎 + 日次。違反時: アラート + 直近 Accept への差し戻し。差し戻し手順は「Accept 済み ADR の訂正手順書（Runbook）」（盲点 #9 対応で MVP リリースと同時に docs/ 配下に作成）に明文化
• 検証手段 3（手動・月次レビュー）: Corpus の time-in-status をレビューし Proposed 滞留（>14 日 or goalpost escalate フラグ）件数を確認。KPI: Proposed 中央値滞留 ≤ 7 日（既存 104 件はバックフィル完了後から計測対象、未バックフィル分はバッジで除外明示）。違反時: Decide 迂回 Accept を促す / 撤退条件 #4 発動
• 検証手段 4（手動・四半期）: override rationale の定性分析を行い「incorrect-assumption」「hallucinated」タグ比率が 80% を超える場合は AI 審査モデル再キャリブレーション（盲点 #13）。gray tier 表示判定ロジックは Cross-Val 側 ADR で四半期見直し

参照 (References)

• 関連 ADR: ADR-0019（Decision Pipeline LangGraph 移行 / 本 ADR の UI 層拡張元）、ADR-0023 / ADR-0024（MADR 採用 / テンプレート・Confirmation 監査スロット利用元）、ADR-0066（async DO / Queues / Review 画面 polling 基盤流用元）、ADR-0050（Synthesis 標準テンプレート Q42 MCDA / 判断基準軸選定の準拠先）
• 関連 systemic fix: Cross-Val 過剰審査 systemic fix Part1（ライフサイクル整合バー）/ Part2（goalpost loop-breaker, 2026-06-02）/ Part2 escalate フラグの UI 着地点が本 ADR の「Review gray tier 表示 → Decide 迂回 Accept」+「Corpus time-in-status 滞留検知」
• 関連 RQ: RQ-086（意思決定 JTBD landscape）、RQ-087（確定・記録 UI/IA の 3 モデル調査・約 $5.39）
• Open Questions（本 ADR で裁定）:
  • Q1: Decide(in-app) ↔ docs/adr/ publish 同期 = Accept 時 webhook で PR Status: 更新 + body snapshot 監査記録（saga + 補償トランザクション付き）
  • Q2: semantic-similarity 提案 = Should（corpus 約 120 件到達 or 明示要求時、MVP 外）
  • Q3: score×churn×Implementation Status カラム = Should（MVP は status badge + time-in-status のみ）
  • Q4: goalpost の Review 表示 ↔ Decide 迂回 Accept 連携 = Must
  • Q5（実装フェーズで確定）: multi-approver 対応時の D1 migration 手順（acceptors は当初から JSON 配列型のため破壊的変更なしの追加列方針を基本とする）
  • Q6（実装フェーズで確定）: 外部監査対応想定時の RFC 3161 タイムスタンプ認証導入可否
  • Q7（実装フェーズで確定）: MVP リリース前データ収集フェーズ（Proposed 件数・滞留日数・grep 所要時間）の計測ツール実装担当
  • Q8（実装着手時に判断）: MVP を Corpus 先行（3.0 人日）/ Decide Phase 2 に分割するか — Policy Alignment 審査が 1 人法人の運用コスト観点で分割を強く推奨。Q7 のデータ収集結果（Proposed 滞留実測）と合わせて実装着手時に裁定する
• 外部資料: MADR 4.0 仕様、arc42 Q42 quality tag（ADR-0050 経由）