Decision Review Pipeline (DRP) を PoC 顧客に提案する営業資料の SSoTADR-0121 §Phase 0-3 の要求 = 「事後監査でなく起案前に質を作り込む事前審査」の差別化軸言語化を軸に、Phase 0-1 の実測ダッシュボード (Phase 0-1 実測) と Phase 0-2 のデモシナリオ (poc-demo-scenarios.md) を束ねる。

§0 このプロダクトが解く問題

組織の意思決定を、特定の人物に依存しない・検証可能な持続可能なガバナンスに変える。

創業 proposal (tasks/proposals/decision-pipeline-productization.md, 2026-06-04 マージ) の位置づけに沿い、次の 4 対象の困りごとを解く。

対象Before (現状)After (このプロダクト導入後)
経営者・創業者自分が見ないと判断の質が担保できない (ボトルネック)関与を最終承認の一点に圧縮 · 見ていなくても質と安全が担保される
現場・若手詳しい人を捕まえないと提案が進まない提案するとその場で盲点指摘・過去決定との矛盾チェック・採点が返る
取締役会・投資家意思決定がキーパーソン依存 (カリスマリスク)決定が記録・採点・監査証跡つきで残り、独断専行が構造的に起きにくい
監査・内部統制「なぜそう決めたか」の証跡が散在ADR + 審査ログが自動で蓄積される · 改ざん検知・追跡可能

§1 差別化軸: 事後監査ではなく事前審査

1.1 主張

  • 既存の GRC / ワークフロー製品: 決まった後の記録・承認履歴を残す (事後監査)
  • 本プロダクト: 決まる前に起案の質を作り込む (事前審査)

事前審査は「AI が判定する」機能ではなく、「起案本文が判断に足る内容かを機械的に検査し、不足を指摘して起案者に戻す」仕組み。最後に決めるのは人間で、AI は判断の材料が揃っているかを見張る。

1.2 事前審査が効くしくみ

検査ゲート見張る対象効き方
起案前ゲート (pre-gate)コスト試算 · 撤退条件 · Confirmation KPI の 3 節が定量条件を満たしているか数値未記載を機械的に検出し、起案者に「数字を入れて再投入」を促す
Cross-Validation起案本文の盲点 · 過去決定との矛盾独立した観点で反証を試み、消えない反証を盲点として返す
bounded roundsCross-Validation の過剰審査 loop3 round で停止 · HITL に戻す (「これ以上 AI で判定を積み上げても質は上がらない」判定)
Gate 4 採点全体の質を 0-49 で採点40 点以上で通過 · 未満は差戻し
triage 分岐案件の重み (Light / Standard / Critical)Critical は経営会議付議推奨 · Light は簡易 pipeline で素早く通す

1.3 「AI が判定する」ではなく「判断の場を用意する」

  • Critical 起案は自動通過ではなく 経営会議への付議推奨 を返す (poc-demo-scenarios.md §4)
  • bounded rounds が発動したら HITL エスカレーション で人間の合議に戻す (同 §6)
  • pipeline は判断そのものを下さない · 判断に足る材料が揃っているかを見張る

§2 ドッグフーディング実績 (自社運用ダッシュボード)

自社で本番稼働中の実測値。ガバナンス商材で最も効く証拠。

2.1 実測サマリー (2026-05-27 〜 2026-07-01 · 35 日間)

指標実測値意味
総 run 数36035 日で 360 件の意思決定を pipeline に流した
差戻し率43.33%起案本文の不足を機械的に検出して戻した割合
盲点検出数 (per run 平均)8.241 起案あたり平均 8 件の盲点を Cross-Validation が指摘
bounded rounds 発動率2.5%過剰審査 loop の停止機構が働いた割合 (適正水準)
triage Standard 比率76.7%主要な起案は Standard で処理
triage Critical 比率18.1%不可逆コミット判定は Critical
pass rate (score 記録あり分)85.8%差戻し → 再投入で通過に至る率が高い

本ページの数値は自社の実運用ダッシュボード (D1 telemetry 集計) から取得しており、架空デモとは別物です。

2.2 実測から読み取れること

  • 差戻し 43.33% は「AI が却下する」のではない: rejection の主要因は placeholder-remaining / pregate-dangling-premise / cost-missing = 起案本文の記入漏れの機械検出であり、起案者が追記して再投入すれば通過する仕組み
  • 盲点 8.24 件/run: 独立した観点で反証を試み、起案者が本文追記で解消する運用が定着している
  • bounded rounds 2.5%: 過剰審査 loop の停止機構が「稀な安全弁」として想定範囲で機能している

2.3 ダッシュボードの再現性

自社ダッシュボードは集計 script (drp/scripts/dashboard-metrics.mjs) から再現可能。手集計の一点ものではなく、SSoT の script + D1 telemetry から任意の期間で再現できる (ADR-0121 §Confirmation 1)。

§3 デモ体験 (架空企業の起案 5 件)

本セクションのデモシナリオは架空企業を想定した例示であり、自社および PoC 顧客の実審査データとは別物です。

デモ環境 (drp-demo.bizlp.dev · 仮) で 5 件の架空起案を投入し、pipeline の主要な挙動を体感してもらう。各シナリオの詳細は poc-demo-scenarios.md を参照。

#業界意思決定論点見せる挙動
1製造業 (精密加工)5 軸 CNC 更新 5,000 万円通過 · 盲点検出 (税制優遇の期限見落とし)
2IT 企業 (SaaS ベンダー)CRM 乗り換え (Salesforce → HubSpot)通過 · 費用構造の盲点 (Tableau 再結線コスト)
3サービス業 (美容チェーン)新業態フィットネス出店 3,000 万円Critical triage · 経営会議付議推奨
4建設業 (元請け)下請け 3 社比較 → 2 社単価契約差戻し (cost-missing) · 再投入で通過
5医療法人 (200 床)電子カルテ更改HITL エスカレーション (bounded rounds 発動)

3.1 デモの狙い

  • 通過 3 件: pipeline が判断を助ける挙動 (盲点指摘 · 費用構造の再確認)
  • 差戻し 1 件: pre-gate による差戻しが「AI が却下する」のではなく「起案の欠落を機械的に検出する」ものだと示す
  • HITL 1 件: 高リスク領域で pipeline が「決めきる」のではなく「決める場を用意する」構造を示す

§4 PoC の枠組み (Phase 1)

本セクションのデモシナリオは架空企業を想定した例示であり、自社および PoC 顧客の実審査データとは別物です。

4.1 PoC 期間と出口条件

項目内容
期間PoC 開始から 8 週間 (延長条件あり)
出口条件顧客の実起案 10 件が pipeline を通過し、顧客が「続けたい」と言う
費用無償または実費 (LLM 従量分) · 月 200 USD 上限
データの扱いPoC 顧客専用の単一テナント環境 (別 Worker + 別 KV/D1 namespace) で預かる
終了時削除検証手順書 (poc-cleanup-procedure.md) に沿ってデータ全削除

4.2 契約条項の要点

顧客契約書 (DPA · GDPR Article 28) に組み込む条項の要約。詳細は poc-cleanup-procedure.md §2 を参照。

  • 削除可能レイヤ: KV / D1 / DO / Queues / Vectorize の 5 種類は PoC 終了時に手順書に沿って削除
  • 削除不可レイヤ: Cloudflare が保持する Workers 実行ログ (最大 90 日)・DO 内部 metadata (経験則 90 日以内)・Queues DLQ metadata (4 日)・Vectorize index metadata (通常 30 日以内) は契約書で除外範囲を明示
  • 法務レビュー: PoC 候補確定前に法務レビューを経て DPA 条項の要否を判断

4.3 データ分離の限界と対応

  • Phase 1 (PoC): マルチテナント分離は実装しない。PoC 顧客ごとに別 Worker + 別 namespace で分離する 単一テナント環境 を用意する
  • Phase 2 (将来): マルチテナント設計を Phase 1 出口後の別 ADR で決定する
  • Entra ID OIDC: 顧客認証はマルチテナント Entra ID OIDC を固定制約とする (ADR-0110 OQ-3)

§5 導入プロセス

  1. 商談 · デモ (0-2 週): デモ環境で 5 件のシナリオを体験してもらう · 差別化軸を確認する
  2. 法務レビュー (2-3 週): 契約書 (DPA) の条項を法務が確認する
  3. 契約締結 (3-4 週): PoC 期間・出口条件・削除条項を明記して締結
  4. PoC 環境セットアップ (4-5 週): 顧客専用の Worker + KV/D1 namespace を立ち上げる · 削除手順書を顧客に共有
  5. PoC 伴走 (5-13 週 = 8 週): 顧客の実起案 10 件を pipeline に流す · 差戻し率 · HITL エスカレーション率を記録
  6. 出口判定 (13-14 週): 10 件通過 + 顧客の継続意思を文書 (メール可) で取得 · Phase 2 移行判断の材料にする
  7. PoC 終了時の処理: 契約に沿って削除手順を実行 · 完了報告を顧客に送付

投下工数の上限: 弊社側は週 1 人日キャップ (ADR-0121 §制約) · 超過が 2 週連続したら着手ペースを再調整する。

§6 想定される質問と答え

6.1 「AI が意思決定を代行するのですか」

いいえ。最後の判断は経営者・意思決定者が下します。pipeline は「判断に足る材料が起案本文に揃っているか」を機械的に検査し、不足を指摘するものです。Critical 起案は経営会議への付議を推奨し、bounded rounds が発動した場合は HITL エスカレーションで人間の合議に戻します。

6.2 「LLM への入力で情報が漏れないか心配です」

  • LLM は Anthropic API を利用します。Anthropic のポリシーでは API 経由の入力を学習データに使わないと明示されています
  • PoC 環境は顧客専用の Worker + KV/D1 namespace で分離し、他顧客のデータと混ざりません
  • 削除不可レイヤ (Cloudflare Workers 実行ログ · DO 内部 metadata 等) は契約書で除外範囲を明示し、含まれる情報は識別子の hash 化などで PII を落とします

6.3 「自社の意思決定文化に合うかわかりません」

  • 現行の評価軸・閾値・テンプレートは自社の ADR 文化を前提にしています
  • PoC 期間中に「自社流に変えたい」項目を記録します · Phase 2 でカスタマイズ性の設計に反映します
  • 汎用性スコアリングを Phase 1 出口評価に含め、業界・規模・ガバナンス文化のどの軸に由来するかを分類します

6.4 「差戻し率 43.33% は高くないですか」

自社実測値です。差戻しの主要因は起案本文の記入漏れ (placeholder-remaining / pregate-dangling-premise / cost-missing) の機械検出で、起案者が追記して再投入すれば通過します。pass rate (score 記録あり分) は 85.8% で、大半の起案は最終的に通過に至ります。

6.5 「PoC 後の価格はいくらですか」

Phase 3 で決定します。PoC 中の顧客分 LLM コストの実測値と、自社実績 (月 200 USD 弱) を参考に、従量設計を含めて Phase 3 で正式に定めます。

§7 免責

  • 本資料のデモシナリオは架空企業を想定した例示であり、自社および PoC 顧客の実審査データとは別物です。
  • 本資料の実測数値は自社の実運用ダッシュボード (D1 telemetry 集計 · 35 日間 · 360 run) から取得したもので、期間・条件を変えれば数値は変動します
  • 本資料は PoC 検討段階の資料であり、Phase 2 以降の機能・価格・マルチテナント設計は未確定です

§8 関連

8.1 SSoT / 参照

  • ADR-0121 = DRP 製品化 Phase 0+1 (本資料の要求元)
  • poc-demo-scenarios.md = デモシナリオ 5 件の詳細
  • poc-demo-disclaimer.md = 免責表記 SSoT
  • poc-demo-environment.md = デモ環境要件
  • poc-cleanup-procedure.md = PoC 撤退時の削除検証手順書
  • drp/scripts/adr-0121-phase0-dashboard-result-2026-07-01.md = 実測ダッシュボード (Phase 0-1)
  • tasks/proposals/decision-pipeline-productization.md = 創業 proposal (位置づけ原典)

8.2 関連 ADR

  • ADR-0121 — DRP 製品化 Phase 0+1
  • ADR-0102 — Tiered review depth (triage 設計)
  • ADR-0109 — Cross-Validation bounded rounds + HITL エスカレーション
  • ADR-0091 — 起案前ゲート (require-quant)
  • ADR-0110 — 顧客認証 = マルチテナント Entra ID OIDC 固定制約
  • ADR-0182 — HITL エスカレーション設計

8.3 資料の月次更新運用

  • 本資料の dashboard 数値 (§2.1) は drp/scripts/dashboard-metrics.mjs の再実行結果を月次で反映する
  • 反映運用: 月初に drp session でダッシュボードを再生成し、本 file の §2.1 を更新する PR を切る
  • 本 file の path 安定化: docs/proposals/poc-sales-material.md の path は顧客営業の引用元として固定する。移動する場合は redirect ページを残す

8.4 外部資料