← ADR 一覧へ残タスク一覧へ 最終更新: 2026/06/22 19:15
commonid: adr-0121type: adrstatus: accepted
pagemode: Standardkruchten: Executive/Existencescope: corporateimplementation_status: Not Startedproposed_at: 2026-06-05 01:52approved_at: 2026-06-05 (PRdeciders: [email protected] (単独)business: drp
型付き辺: 出 3 / 入 0
関連: ADR-0109 ADR-0110 ADR-0125全体は INDEX →

ADR-0121: 意思決定審査パイプラインの製品化に Phase 0+1 限定で着手する (go/no-go)

  • Status: Accepted
  • Mode: Standard
  • Kruchten Type: Executive/Existence
  • Scope: corporate
  • Implementation Status: Not Started
  • 起案者: [email protected]
  • 起案日時 (JST): 2026-06-05 01:52
  • 承認日時 (JST): 2026-06-05 (PR #1474 merge = 受理・JST 03:41)
  • Deciders: [email protected] (単独)

コンテキスト

§1.1 背景

審査パイプライン (Decision Review Pipeline) を他社展開する製品化構想は、proposal (tasks/proposals/decision-pipeline-productization.md, PR #1378 マージ 2026-06-04) で位置づけ合意が成立した — 事業領域マトリクス「組織と × まかせあう」、製品コンセプト「組織の意思決定を、特定の人物に依存しない・検証可能な持続可能なガバナンスに変える」。proposal §8 次アクション 2 のとおり、製品化着手の go/no-go を本 ADR で決定する（自己適用）。

§1.2 現状 (As-Is)

  • 自社で本番稼働中。MVP 卒業 EC-1〜6 充足 (2026-06-03)、ADR 100 件超を実審査済み — ドッグフーディング実績がガバナンス商材の営業証拠になる
  • LLM コストは自社 1 社分で月約 $200 (Anthropic API、prompt caching 未適用)

§1.3 課題

  • 一人体制であり、現注力事業（人材開発）とバイヤー・営業導線が別物 (proposal §4)。リソース配分が最大の制約

§1.4 制約・要件

  • 2026-06-04 確定の固定制約: 製品化後は顧客 (Microsoft 365 基盤) が直接触るため、顧客向け認証は マルチテナント Entra ID OIDC を JTBD-012 (証憑管理)・管理会計プロダクトと共通基盤にする。CF Access (ADR-0110) は社内フェーズ限定の解 (同 ADR OQ-3、PR #1413)
  • コンピュート基盤は CF Workers + DO/KV/D1/Queues を維持
  • 本件投下工数は週 1 人日キャップ

§1.5 目標 (To-Be)

製品化に go の判断を確定し、最小の不可逆コミットメント (Phase 0+1) で論点 1〜4 の実データを取得できる状態にする。Non-Goals: Phase 2/3 のコミット、価格決定、基盤移行、現事業の優先度変更。

決定

製品化に go、ただし Phase 0 (自社運用 KPI の整備・営業資料化) + Phase 1 (1 社 PoC) に限定して着手 する。Phase 2 (マルチテナント化) / Phase 3 (価格設計・正式製品化) は Phase 1 の出口条件達成を前提とする別 ADR とし、本 ADR ではコミットしない。

Phase 0 の成果物 (proposal §6 の出口条件を具体化):

  1. 審査実績ダッシュボード 1 枚: 採点分布・差戻し率・盲点検出数・過剰審査停止機構 (ADR-0109 bounded rounds) の発動率を実データから集計
  2. デモ用サンプル起案セット: 自社 ADR は機密で見せられない (proposal 論点 6) ため、架空企業の起案 5 件 (通過 3 / 差戻し 1 / HITL エスカレーション 1) を作成し、デモ環境で実際に審査が走る状態にする。営業資料・デモ環境の両方に「このデモは架空企業の起案を使用しており、自社の実審査データとは別物です」の免責表記を必須要素とし、実データセクション (ダッシュボード) と架空デモを視覚的に明確分離する
  3. 営業資料 1 部: 「事後監査でなく起案前に質を作り込む事前審査」の差別化 (論点 5) を軸に、ダッシュボード+デモを束ねる

Phase 1 (1 社 PoC) の枠組み:

  • 出口条件 (proposal §6 のまま): 顧客の実起案 10 件が pipeline を通過し、顧客が「続けたい」と言う
  • PoC 中のデータの扱い (論点 1 の先送りと引き換えの限定): マルチテナント分離は実装しない。PoC 顧客のデータは専用に分離した単一テナント環境 (別 Worker + 別 KV/D1 namespace) で預かり、PoC 終了時の全削除を契約条項に含める。Phase 1 セットアップ工数に「削除対象ストレージの全列挙 (Workers 実行ログ・DO ジャーナル・Queues デッドレターを含む全レイヤー) と削除検証手順書の作成」を必須タスクとして含め、削除不可レイヤーは Cloudflare ドキュメントで事前確認し除外範囲を契約条項に明示する。PoC 候補確定前に法務レビューを経て DPA (改正個人情報保護法委託先監督・GDPR Article 28) 条項の要否を判断する。本格的なマルチテナント設計は Phase 2 ADR で、Entra マルチテナント認証と併せて決定する
  • カスタマイズ要件の観測 (論点 2): 評価軸・閾値・テンプレートのうち PoC 顧客が「自社流に変えたい」と言った項目を記録し、Phase 2 ADR のカスタマイズ性スコープの入力にする。各項目を業界・規模・ガバナンス文化のどの軸に由来するかを分類する汎用性スコアリングを Phase 1 出口評価に含め、Phase 2 ADR のゲート条件とする
  • 受容性の計測 (論点 4): PoC 顧客の差戻し率・再投入率・HITL エスカレーション率を自社運用値と比較し、「AI が審査する」ことへの抵抗が数値に表れるかを観測する
  • PoC 顧客セグメント記録: 規模・業種・IT 成熟度を Phase 1 出口時点で記録し、Phase 2 ADR でターゲットセグメント仮説として明示 (Crossing the Chasm 配慮)
  • 顧客問い合わせ SLA: PoC 開始前に顧客との合意文書に「HITL エスカレーション発生時の応答目標は翌営業日以内、それ以外の技術問い合わせは 3 営業日以内」と明記。応答できない期間が発生した場合の暫定対処 (エスカレーション凍結・審査一時停止) のフローを合わせて定義
  • 現事業との両立 (論点 7): 本件への投下工数を週 1 人日以内にキャップする。超過が 2 週連続したら着手ペースを再調整する

判断基準 (Decision Drivers)

3.1 評価軸

#軸重要度 (係数)案件特有の解釈
1#suitable[Must] (×2.0)proposal で位置づけ合意済み構想と整合し、最小コミットメントで論点 1〜4 の実データを得られるか
2#maintainable[Must] (×2.0)一人体制で週 1 人日キャップ下に運用可能か (現事業の圧迫回避)
3#flexible[High] (×1.0)Phase 2/3 への進路と撤退の両方を残せるか (不可逆コミット最小化)
4#secure[High] (×1.0)PoC 顧客データの預かりリスクをデータ分離・契約条項・DPA で抑えられるか
5#efficient[Medium] (×0.5)LLM コスト・工数・PoC 期間が想定枠に収まるか

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

3.2 評価軸 × 案スコア表

軸係数案 B (採択: Phase 0+1)案 A (Full go)案 C (No-go)案 D (Phase 0 のみ)
#suitable (Must ×2.0)2.04312
#maintainable (Must ×2.0)2.04154
#flexible (High ×1.0)1.05233
#secure (High ×1.0)1.03254
#efficient (Medium ×0.5)0.54254
加重和 (正規化)0.8000.3940.6330.589
K.O. 通過 (Must ≥3)✓❌ (#maintainable=1)❌ (#suitable=1)❌ (#suitable=2)

検討した代替案 (Alternatives Considered)

  • 案 A: full go (Phase 0〜3 一括コミット) — マルチテナント設計・価格設計まで一気に進める。一人体制で現事業と並行するには過剰コミットであり、PoC で得るべき実データ (カスタマイズ要件・受容性・顧客分 LLM コスト) なしに Phase 2/3 を設計すると手戻りが大きい。#maintainable で K.O.。不採用
  • 案 B (採択): Phase 0+1 限定 go、Phase 2 以降はゲート付き別 ADR — ドッグフーディング実績が新鮮なうちに営業資料化し、最小の不可逆コミットメント (PoC 1 社) で論点 1〜4 の実データを取る
  • 案 C: no-go (構想凍結、現事業集中) — 機会損失が大きい。MVP 卒業直後の運用データと「自社で使い込んだ実績」は時間経過で陳腐化しないが、検証の先送りは Phase 2 以降の判断材料をいつまでも得られない。proposal で位置づけ合意済みの構想を理由なく凍結すると意思決定の一貫性を欠く。#suitable で K.O.。不採用
  • 案 D: Phase 0 のみ go (PoC は別 ADR) — 営業資料を作っても見せる相手 (PoC 候補) を探さなければ棚上げと同じ。Phase 0 と Phase 1 は「資料を作る→見せる→反応を得る」の一連であり、分割すると Phase 0 成果物の鮮度が落ちる。#suitable で K.O.。ただし PoC 候補が見つからない場合は実質この案に縮退する (撤退条件 #2)

影響 (Consequences)

§5.1 正の影響 (Good)

  • proposal で合意済みの構想を最小コミットで前進させ、Phase 2 ADR の判断材料 (カスタマイズ要件・受容性・顧客分 LLM コスト・セグメント属性) を実データで取得できる
  • ドッグフーディング実績が新鮮なうちに営業資料化することで、「事後監査でなく起案前に質を作り込む事前審査」の差別化軸を市場検証可能にする
  • 認証基盤を Entra マルチテナント OIDC に固定する制約を明文化することで、JTBD-012 (証憑管理)・管理会計プロダクトと将来ガバナンス・スイートを束ねる構想に整合する
  • 撤退条件 6 件を ADR 時点で明示することで、go の慣性に流されず途中撤退の権利を保持できる

§5.2 負の影響 (Bad)

  • PoC 顧客の起案テキストが Cloudflare 管理領域 (Workers 実行ログ・DO ジャーナル・Queues デッドレター) に残存し、契約上「全削除」を完全証明できない。改正個人情報保護法委託先監督義務・GDPR Article 28 (DPA) と衝突する可能性がある。対処 = Phase 1 セットアップ工数に削除対象全列挙と検証手順書作成を必須化、削除不可レイヤーは契約条項で除外明示、PoC 候補確定前に法務レビュー
  • CF Workers の subrequest 上限 (50件/リクエスト) と wall time 30 秒制限: Cross-Validation + HITL エスカレーション + 外部 LLM 呼び出しを 1 リクエストで連鎖させる現設計では、PoC 顧客の起案フォーマット次第で上限超過のリスクがある。「別 Worker 分離」だけでは上限数は変わらない。対処 = PoC 環境セットアップ着手前に現行自社環境で 1 起案あたり subrequest 数と wall time を実測しヘッドルームを記録、超過リスクがある場合は Queues 非同期分割設計の Phase 1 含入を明示判断
  • PoC 顧客 1 社の代表性バイアス: 「続けたい」の定性評価で go 結論が認知的に固まり、外部調査が追認作業化するリスク。Microsoft 365 基盤の大企業 1 社に偏ると SMB・非 M365 セグメントへの適合性がゼロデータのまま Phase 2 ADR が書かれる (Crossing the Chasm, Moore 1991)。対処 = 汎用性スコアリングを Phase 2 ADR のゲート条件化、セグメント属性記録
  • 週 1 人日キャップ下での 2026-09-30 期限到達リスク: Phase 0 (3.5 人日) + Phase 1 セットアップ (1.0 人日) = 4.5 週、営業活動 2〜4 週を加えると PoC 開始は ADR 承認から最短 7〜9 週後 (2026-08 上中旬)。撤退条件 #2 期限まで PoC 伴走 6 週しか残らず、撤退条件 #3 「8 週で 5 件未達なら延長」と矛盾し得る。対処 = 週次マイルストーン表を別途維持し、不整合発生時はキャップ例外 (Phase 0 期間中は週 2 人日まで) または撤退条件 #2 期限延長で対応
  • 顧客問い合わせ応答遅延リスク: 一人体制 + 週 0.5 人日伴走では、月曜発生のブロッカーが金曜まで未対応になり 10 件通過の出口条件達成を阻害し得る。対処 = SLA 文書化 (翌営業日 / 3 営業日) と暫定対処フロー定義
  • コンピュート基盤の顧客側制約リスク: PoC 候補が Azure データガバナンス基盤を持つ金融・医療・官公庁の場合、CF Workers 経由のデータ処理を IT セキュリティ部門が許可しない可能性。データレジデンシー設定の現状は ADR 未記述、代替基盤も検討外。対処 = Phase 0 営業活動開始前に PoC 想定顧客のセキュリティ要件を確認、許容されない場合の代替基盤オプションは将来の分岐点として保留
  • 現事業 (人材開発) への注意配分減少 — 週 1 人日キャップで管理するが完全分離はできない

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

  • Phase 2 (マルチテナント化) / Phase 3 (価格設計) は本 ADR でコミットしない。実データなしの設計を避ける代わりに、Phase 1 の結果次第で Phase 2 着手が遅延する
  • 顧客向け認証 = Entra マルチテナント OIDC は固定制約として記録 (ADR-0110 OQ-3 と整合)
  • PoC は無償または実費 (LLM 従量分)。価格設計は Phase 3 に送るが、PoC 中の顧客分 LLM コストは Phase 3 従量設計の実データになる
  • コンピュート基盤 (CF Workers + DO/KV/D1/Queues) は維持。M365 基盤は ID 面とデータ取込面のみ制約

撤退条件 (Rollback Plan)

#判定指標期限/検知アクション
1Phase 0 実工数が 5 人日を超過Phase 0 作業中成果物をダッシュボード 1 枚のみに縮退し、デモ素材・営業資料は PoC 候補確定後に延期
2PoC 候補 1 社が 2026-09 末 までに確保できない2026-09-30Phase 1 を保留し案 D 相当に縮退。2026-12 末まで候補ゼロなら no-go 再判定の ADR を起案
3PoC 開始後 8 週で出口条件 (実起案 10 件通過) の半分 (5 件) に未達PoC 8 週時点PoC を 4 週延長 or 終了を顧客と協議。12 週で未達なら Phase 2 へ進まず学習事項を記録して終了
4本件投下工数が週 1 人日を 2 週連続超過週次着手ペース再調整。さらに 2 週続いたら Phase 1 を一時停止し現事業優先
5PoC 顧客分 LLM コストが月 $200 を超過月次審査件数制限。2 ヶ月連続超過なら Phase 3 の従量設計を前倒しで検討
6PoC 中にデータ預かり起因のインシデント (漏洩・誤共有) が 1 件でも発生発生時PoC 即時中断 + 全削除 + Phase 2 のデータ分離設計を必須前提に昇格
7PoC 候補顧客の IT セキュリティポリシーが CF ネットワーク経由を許可しないPhase 0 営業活動中該当顧客を PoC 対象外とし、代替候補を探索。3 候補連続で同事由ならコンピュート基盤の代替検討 ADR を起案
8法務レビューで「削除不可レイヤー (CF 管理領域) の残存」が DPA 上受容不可と判断される (テナント層審査の条件)PoC 候補確定前の法務レビュー時Phase 1 開始をブロック。削除可能性をアーキテクチャ要件化した Phase 2 (マルチテナント分離設計) の前倒し検討 or no-go 再判定 ADR の起案

コスト試算

作業工数 (人日)
Phase 0-1: 審査実績ダッシュボード 1 枚 (採点分布・差戻し率・盲点検出数・bounded rounds 発動率)1.0
Phase 0-2: デモ用サンプル起案セット 5 件 + デモ環境整備1.5
Phase 0-3: 営業資料 1 部 (差別化軸の言語化 + ダッシュボード/デモの束ね)1.0
Phase 1: PoC 環境セットアップ (専用 Worker + KV/D1 namespace 分離 + 削除手順 + 削除対象全列挙 + DPA 検討)1.0
Phase 1: PoC 伴走 (週 0.5 人日 × 8 週を上限目安)4.0
合計 (Phase 0+1)8.5 人日 (週 1 人日キャップ内で約 2〜3 ヶ月)

金銭支出: PoC 顧客分 LLM 実費 月 $200 上限 (超過時は審査件数制限)。Phase 0 は追加金銭支出 0 円 (自社運用データの集計のみ)。

Confirmation

  • 検証手段:
    1. Phase 0 出口: ダッシュボード 1 枚が実データから再現可能な集計スクリプトで生成されること (手集計の一点ものにしない)
    2. デモ環境でサンプル起案 5 件が実際に審査を通り、通過 3 / 差戻し 1 / HITL エスカレーション 1 の結果が再現されること。営業資料・デモ環境の免責表記が実装されていること
    3. Phase 1 セットアップ出口: 削除対象ストレージ全列挙 (Workers ログ・DO ジャーナル・Queues 含む) と削除検証手順書が文書化されていること。subrequest 数・wall time 実測値が ADR 追補に記録されていること
    4. Phase 1 出口: 顧客の実起案 10 件の pipeline 通過を audit ログ (D1 telemetry) で確認 + 顧客の継続意思を文書 (メール可) で取得 + 汎用性スコアリングとセグメント属性記録の完了
    5. 週次で投下工数を記録 (週 1 人日キャップの遵守判定に使用)
    6. PoC 顧客分 LLM コストを月次集計 (Phase 3 従量設計の実データ)
    7. PoC 終了時のデータ全削除を KV/D1 の実エントリ確認 + 除外範囲明示で検証し、完了報告を顧客へ送付
  • 実行頻度: 週次 (工数) / 月次 (LLM コスト) / Phase 出口時 (出口条件判定)
  • 違反時対応: 撤退条件 #1〜#8 のいずれかに該当する場合は当該行のアクションを実施。Confirmation 項目の未達 (例: 削除検証手順書未完成のまま Phase 1 開始) は Phase 進行を停止し、未達項目の解消まで ADR 追補で進捗管理
  • KPI:
    1. Phase 0 完了 = 成果物 3 点が 5 人日以内 に揃う
    2. Phase 1 出口条件 = 顧客実起案 10 件 通過 + 継続意思 1 件 (文書)
    3. 現事業への影響 = 週 1 人日キャップ遵守率 ≥ 80% (週次記録ベース)
    4. PoC 顧客の差戻し率・HITL エスカレーション率を自社運用値と並べた比較表 1 枚 (Phase 2 ADR の入力)
    5. Jr 引き継ぎ可能性の文書化 (テナント層審査の条件・2026-10 入社予定者と PoC 伴走期間が重なる): Phase 1 の SLA 応答・削除手順書・顧客伴走のうち Jr に割り当て可能な作業の仕分けを Phase 1 出口時点で 1 ページ文書化する。未文書化のまま Phase 2 ADR を起案しない

長期的影響 (Long-term)

  • Review After: 2026-12 月初。再評価指標: ①Phase 0/1 の進捗 vs 週次マイルストーン (撤退条件 #2 の 2026-12 末 no-go 再判定に先行) ②週 1 人日キャップ遵守率実測 (KPI 3) ③PoC 顧客分 LLM コスト実績 vs 月 $200 上限 ④撤退条件 #8 (法務レビュー) の結論と Phase 2 前倒し要否
  • Phase 1 中断・終了時の技術負債残骸処理 (審査講評の指摘): 専用 Worker・KV/D1 namespace・デモ環境は PoC 終了/中断のいずれでも削除対象とし、Phase 1 セットアップで作成する削除検証手順書のスコープに含める (顧客データ削除と同一手順で自社側残骸も処分)。営業資料・ダッシュボード集計スクリプトは再利用資産として tasks/proposals/ 系列に保持する
  • 自社側ロックイン回収条件 (テナント層審査の条件): CF Workers 基盤・Entra ID 認証基盤からの撤退コスト見積もりを Phase 2 ADR の必須入力として明示する。顧客側ロックイン (Entra 固定制約) と自社側の基盤回収手段は別問題であり、Phase 2 のマルチテナント設計時に両方を評価する

参照 (References)

  • proposal: tasks/proposals/decision-pipeline-productization.md (PR #1378 マージ 2026-06-04、位置づけ・論点 7 件・展開ステップの原典)
  • MVP 卒業記録: docs/_internal/03_decisions/decision_pipeline/mvp_exit_criteria.md (EC-1〜6 充足 2026-06-03)
  • ADR-0109 (Cross-Validation bounded rounds + HITL エスカレーション = 受容性説明の実装済み根拠)
  • ADR-0110 OQ-3 (PR #1413, 2026-06-04): 顧客向け認証 = マルチテナント Entra ID OIDC 共通基盤の固定制約、CF Access は社内フェーズ限定
  • 隣接構想: JTBD-012 (帳票・証憑管理 SaaS) — 将来ガバナンス・スイートとして同一 Entra 認証基盤に束ねる構想
  • LLM コスト実績: 自社 1 社分 月約 $200 (prompt caching 未適用)
  • 外部資料: Crossing the Chasm (Moore 1991) — セグメント代表性バイアスの参照
  • 法務参照: 改正個人情報保護法 (2022 年施行) 委託先監督義務 / GDPR Article 28 (DPA)
  • 本起案は sub から。PoC 環境構築 (Worker/KV/D1 分離) は main ワークスペース領分