最終更新: 2026/07/02 03:07
commonid: poc-demo-environmenttype: how-tostatus: active
pageaudience: subbusiness: drp

PoC デモ環境要件 (ADR-0121 Phase 0-2)

Decision Review Pipeline (DRP) の営業デモを走らせる環境の要件書。ADR-0121 §Phase 0-2 の Confirmation 2 「デモ環境で 5 件が実審査を通る」を担保するために、実データ (自社運用ダッシュボード) と架空デモを分離する方針・存続期間・drp 側の実装引き継ぎ点を定める。

§0 使い方

  • docs 側 (本 file): 分離方針・存続期間・免責注入の要件を確定する
  • drp 側 (別 handover 委譲): §3 で確定した方針をもとに wrangler.toml 分離 · fixture schema · 投入 script を実装する
  • 営業デモの前: §1 の環境が立ち上がっていることを確認し、poc-demo-scenarios.md の 5 件を fixture 投入する
  • PoC 撤退時: poc-cleanup-procedure.md の削除手順にデモ環境も含めて実行する

§1 環境の分離方針 (実データと架空デモ)

1.1 分離の対象

営業デモの体験は次の 2 種類を組み合わせる。

  • 実データセクション: 自社運用のダッシュボード (D1 telemetry 集計 · 360 run · 差戻し率 43.33% 等) を提示する。数値は自社の実運用値であり、架空ではない
  • 架空デモセクション: poc-demo-scenarios.md の 5 件を投入した審査結果を提示する。数値・企業名は架空である

商談で両者を並べて見せると、顧客は「これは自社のデータですか」「これはデモですか」の判別が付きづらい。誤解が生じると (α) 自社実績を誇張して見せた印象を与えるリスク · (β) 顧客の実起案を投入した結果と誤認されるリスクの両方が生じる。よって環境レベルで両者を分離する。

1.2 分離の 3 案 (docs 側で確定 · drp が実装)

案分離方式分離度実装コスト運用コスト
α別 Worker (drp-demo) + 別 KV/D1 namespace高中 (packages/drp-demo/ 新設 · コード共有は subset)低 (wrangler.toml が完全分離)
β単一 Worker + env.DEMO_MODE flag で切替中低 (drp/src に flag 分岐追加)中 (実行時分岐でミスる余地)
γ別 CF account + 別 domain (drp-demo.bizlp.dev)最強高 (CF account 増設 · billing 分離)中 (アカウント越境の管理)

採択: 案 α (別 Worker + 別 namespace) を推奨する。

採択の根拠:

  • 分離度: β の実行時分岐は「本番 Worker に架空 draft を投入した瞬間に本番 pipeline に流れる」誤操作の余地がある。「架空 draft は本番 D1 telemetry に記録される」など後戻り不可の事故を生む。α は Worker 単位で分離するため、fixture 投入は物理的に別 KV に向く
  • 実装コスト: γ の CF account 増設は billing 上の分離コストが割に合わない。α は packages/drp-demo/ を新設して subset のコード (審査 pipeline core) を共有するだけで済む
  • 運用コスト: α は wrangler.toml が完全に別 file なので、デモ環境の設定変更が本番に波及しない。β は 1 file 内の flag 制御となり、review でうっかり見落とす余地がある
  • 削除性: α はデモ環境の削除が「別 Worker + 別 namespace の削除」で完結する。β は本番 Worker の flag off + 本番 D1 からのデモデータ削除の 2 段階が必要 · 削除漏れリスクが上がる

drp 実装引き継ぎ点 (§3.1 参照):

  • packages/drp-demo/wrangler.toml を新設 (別 Worker · 別 KV binding · 別 D1 database)
  • 審査 pipeline core (drp/src/) は demo 側から subset import する構成 · 依存関係の重複を避ける

1.3 URL / domain の分離

  • 本番 (自社運用): 現行 drp.bizlp.dev (仮 · 実 domain は drp/wrangler.toml で確定) を維持
  • デモ: drp-demo.bizlp.dev (案 · 実装時に確定)
  • UI 上の視覚的分離: デモ画面には poc-demo-disclaimer.md §1.1 banner を常時表示する。実データ画面 (dashboard) には §1.3 分離注記を上部に表示する

1.4 デモ環境で必ず表示するもの

  • 免責 banner (poc-demo-disclaimer.md §1.1 の byte 一致文言)
  • 架空企業を明示するシナリオ選択画面: 「シナリオ 1: 製造業 A 社 (架空)」等と全ての遷移先で「架空」の表示を維持
  • 入力できる範囲の制限: 顧客が自社の起案を直接入力できないようにする (fixture 選択のみ · 自由入力欄は非表示 or read-only)

§2 環境の存続期間

2.1 デモ環境の存続範囲

  • Phase 0 (2026-08 中旬まで): デモ環境を営業活動用に稼働。PoC 候補との商談で使う
  • Phase 1 (PoC 開始 〜 出口条件達成): PoC 顧客専用環境が別途立ち上がるため、デモ環境は「Phase 0 で作った営業導線を新規商談で使い続ける」用途に転じる
  • Phase 1 出口 (PoC 完走 or 中断): デモ環境は撤収候補。営業活動が Phase 2 に進む場合は撤収を判断保留、no-go 再判定 (ADR-0121 撤退条件 #2) の場合は削除

2.2 撤収時の削除範囲

デモ環境も PoC 環境と同じく poc-cleanup-procedure.md §1 の削除手順を適用する。対象:

  • KV (デモ用の DRAFTS_KV / PROMPTS_KV / SIGMA_LOG · demo 名前空間分)
  • D1 (デモ用の TELEMETRY_DB · demo 名前空間分)
  • DO (デモ用の SOCRATIC_SESSIONS / PIPELINE_SESSIONS · demo 名前空間分)
  • Queues (デモ用の PIPELINE_QUEUE · demo 名前空間分)
  • Vectorize (デモ用の RECALL_INDEX · demo 名前空間分)
  • Worker (drp-demo) 自体の削除
  • domain (drp-demo.bizlp.dev) の DNS 削除

2.3 削除不可レイヤの契約条項

デモ環境で発生した Workers 実行ログ・DO 内部 metadata・Queues DLQ metadata・Vectorize index metadata は poc-cleanup-procedure.md §2 と同じ retention 条項が適用される。ただし架空データのため PoC 顧客契約書に条項を書く必要はない。

§3 drp 実装引き継ぎ点

docs 側で §1 · §2 を確定した後、drp 側で次の実装を進める。実装は drp session 30 以降で先取り可能な項目を含む。

3.1 wrangler.toml 分離 (案 α)

  • 新設 path: packages/drp-demo/wrangler.toml
  • worker name: drp-demo
  • binding:
    • KV: DRAFTS_KV_DEMO · PROMPTS_KV_DEMO · SIGMA_LOG_DEMO
    • D1: TELEMETRY_DB_DEMO (name = decision-pipeline-telemetry-demo)
    • DO: SOCRATIC_SESSIONS_DEMO · PIPELINE_SESSIONS_DEMO
    • Queues: PIPELINE_QUEUE_DEMO (+ DLQ)
    • Vectorize: RECALL_INDEX_DEMO (name = drp-adr-recall-demo)
  • audit: wrangler.toml の binding 名は本番と全て別名にする。名前で「demo vs prod」を目視判別できる

3.2 fixture schema と投入 script

  • fixture の格納: drp/scripts/demo-fixtures/scenario-01.json 〜 scenario-05.json (5 file)
  • schema: poc-demo-scenarios.md §2〜§6 の起案 payload 想定を JSON 化。schema は本番 drp の draft record 型に byte 一致で合わせる
  • 投入 script: drp/scripts/inject-demo-fixtures.mjs (未実装 · drp session 30+ 想定)
    • --dry-run: 投入対象と KV / D1 の変更予告のみ表示
    • --execute: 実投入
    • --wrangler=demo/prod: 投入先環境の切替 (default = demo)
    • 安全策: --wrangler=prod を指定しても demo fixture の投入は明示的な --i-know-this-writes-to-prod フラグが無ければ block する

3.3 免責 banner の inline 実装

  • 参照元: poc-demo-disclaimer.md §1.1 の code block 内文言
  • 実装: packages/drp-demo/public/index.html (仮) の header 直下に固定 banner。ADR-0182 の build-time inline gate と同機構で SSoT から byte 一致で埋め込む
  • CI ゲート: build script が SSoT と inline 展開の差分を検出したら fail

3.4 入力制限

  • fixture 選択画面: デモ環境の起案入力は §3.2 の 5 件から選択のみ · 自由入力欄は非表示または read-only
  • 理由: 商談中に顧客が自社の実起案を入力すると「顧客の意思決定情報がデモ環境の KV に書き込まれる = 削除対象の追加」が発生する。fixture 選択に限定して情報混入を機械的に防ぐ

§4 分離方針の追補 ADR 起票判定

案 α の採択と packages/drp-demo/ の新設は、ADR-0121 本文には無い意思決定なので、次のいずれかの形で追補する:

  • 追補 A (推奨): 本 file の §1.2 で採択根拠を明示し、ADR-0121 の実装配線として扱う (別 ADR 起票なし)
  • 追補 B: 「PoC デモ環境の Worker 分離方針」を単独 ADR (仮 ADR-NNNN) で起票する

推奨 A の根拠: ADR-0121 §Phase 0-2 に「デモ環境で 5 件が実審査を通る」の Confirmation があり、分離方針は本 file の要件書レベルで確定できる。単独 ADR 起票は影響範囲が広いときに用いる。本件は drp の Worker 構成に閉じるため、本 file + drp 実装引き継ぎで足りる。追補 B は drp 側で実装着手時に判定要と判断された場合に起票する。

§5 関連

5.1 SSoT / 参照

5.2 drp 側の追加検討事項 (drp が判定)

  • immutability guarantee: 免責 banner の byte 一致 SSoT は ADR-0182 の build-time inline pattern で実装可能
  • fixture 投入 script の骨組み先取り実装: drp session 30+ で drp/scripts/inject-demo-fixtures.mjs の骨組み (schema + dry-run) を先取り可能。fixture 内容は placeholder で、本 file 確定後に §3.2 の実 fixture に差し替え
  • domain の実確定: drp-demo.bizlp.dev は仮案 · Cloudflare Pages / Workers Routes の設定は drp 側で確定

5.3 関連 ADR

  • ADR-0121 — DRP 製品化 Phase 0+1
  • ADR-0182 — build-time inline pattern (免責 banner の byte 一致機構)
  • ADR-0110 — Workers Logs opt-out (デモ環境の Log 除外設計)
  • ADR-0019 — Decision Review Pipeline (Pipeline 全体設計)
  • ADR-0066 — Async pipeline queue (デモ環境の Queues 分離)
  • ADR-0077 — Telemetry (デモ環境の D1 分離)

5.4 外部資料