最終更新: 2026/07/02 02:17
commonid: poc-cleanup-proceduretype: how-tostatus: active
pageaudience: subbusiness: drp

PoC 撤退時の削除検証手順書 (ADR-0121 Phase 1 セットアップ出口)

Decision Review Pipeline (DRP) を PoC 顧客に展開する Phase 1 の出口条件 (ADR-0121 §Confirmation 3) を満たす削除手順書。PoC 終了時 (完走 or 中断) に、顧客データを Cloudflare 上から確実に取り除くための 削除可能レイヤの操作手順 と 削除不可レイヤの契約条項テンプレ の 2 部構成でまとめる。

§0 使い方

  • PoC 契約締結前: §2 の契約条項テンプレを顧客契約書 (DPA · GDPR Article 28 委託先監督条項) に組み込む。文言はそのまま使うか法務レビュー後に調整する。
  • PoC 終了時: §1 の順で削除を実行し、§3 のチェックリストで完了判定する。
  • 顧客からの削除要求時 (右忘れ処理相当): §1 の該当 binding だけを実行する (顧客単位分離は Phase 1 では未実装のため、実質は全 PoC データが対象)。

削除対象の全列挙・実測は drp/scripts/adr-0121-phase1-list-result-2026-07-01.md を SSoT とする。binding 定義は drp/wrangler.toml が原本。

§1 削除可能レイヤ (5 種類) の削除手順

§1.1 KV namespaces (3 binding)

対象: DRAFTS_KV (ADR draft staging · ADR-0019) / PROMPTS_KV (LLM prompt lifecycle · ADR-0042) / SIGMA_LOG (Gate 4 σ 月次モニタ · ADR-0074)

列挙 (削除前に件数を記録):

pnpm --filter drp exec wrangler kv key list --binding <BINDING> --remote

削除 (list → loop で個別 delete):

pnpm --filter drp exec wrangler kv key list --binding <BINDING> --remote \
  | jq -r '.[].name' \
  | while read -r key; do
      pnpm --filter drp exec wrangler kv key delete --binding <BINDING> --remote "$key"
    done

注意:

  • PROMPTS_KV は本番プロンプト SSoT を含むため、PoC 顧客固有の key しか削除しない ように prefix (bizlp:poc:<tenant>:) で絞る運用が Phase 2 マルチテナント設計の条件。Phase 1 は単一テナント環境で運用するため、PoC 終了時に 全 key 削除 で問題ない (自社の prompt は別 workspace / 別 KV に隔離)。
  • TTL 設定は key 単位で書き出し時に指定 (削除時は無関係)。

§1.2 D1 databases (1 binding)

対象: TELEMETRY_DB (審査 telemetry · ADR-0077)

テーブル一覧:

pnpm --filter drp exec wrangler d1 execute decision-pipeline-telemetry \
  --remote --command "SELECT name FROM sqlite_master WHERE type='table' ORDER BY name" \
  --json

全 row 削除 (schema 保持 · Phase 1 の PoC 環境を再利用する場合):

pnpm --filter drp exec wrangler d1 execute decision-pipeline-telemetry \
  --remote --command "DELETE FROM telemetry_records"

schema ごと削除 (再構築する場合):

pnpm --filter drp exec wrangler d1 execute decision-pipeline-telemetry \
  --remote --command "DROP TABLE telemetry_records"

database 全削除 (PoC 環境ごと撤収する場合):

pnpm --filter drp exec wrangler d1 delete decision-pipeline-telemetry

注意: _cf_KV は Cloudflare 内部の system table なので削除対象外。

§1.3 Durable Objects (2 binding)

対象: SOCRATIC_SESSIONS (Socratic 対話 · ADR-0119) / PIPELINE_SESSIONS (Pipeline state · ADR-0019 · ADR-0120)

制約: CF CLI からの静的 list は不可 (execution / API 経由でのみ列挙可能)。削除は DO 内部で storage.deleteAll() を呼ぶ実装を経由する。

削除実装 (drp/src/do/*.ts で PoC 撤退用 endpoint を用意):

// drp/src/do/socratic_session.ts / pipeline_session.ts
async destroy(): Promise<Response> {
  await this.state.storage.deleteAll();
  const alarm = await this.state.storage.getAlarm();
  if (alarm !== null) await this.state.storage.deleteAlarm();
  return new Response("cleared", { status: 200 });
}

実行: PoC 撤退時に script (drp/scripts/purge-do-instances.mjs · 未実装 · Phase 1 セットアップで追加) から instance を列挙して destroy を呼ぶ。列挙は Workers Logs / Analytics 経由で近似 (Cloudflare の DO 全 instance API がないため)。

注意: DO instance の list が近似のため、残存 instance が発生する可能性がある。§2.2 で契約条項化する。

§1.4 Queues (1 binding)

対象: PIPELINE_QUEUE (async pipeline · ADR-0066) + DLQ pipeline-queue-dlq

削除: Cloudflare Queues の message は消費時に ack (deleteMessage) 経由で削除される。手動一括削除 API は無い。

PoC 撤退時の運用:

  1. PoC 環境の consumer を停止 (drp/wrangler.toml から consumer 定義を外す or worker 自体を無効化)
  2. producer 側からの message 投入を停止
  3. 残存 message は consumer 復帰時に ack で処理 (or DLQ 送りにする pre-validation を組み込む)
  4. DLQ retention (通常 4 日) で自動失効を待つ

注意: DLQ retention の 4 日は Cloudflare 側の default で、ユーザー側から縮められない。§2.3 で契約条項化する。

§1.5 Vectorize indexes (1 binding)

対象: RECALL_INDEX (ADR recall · RQ-107 R9 Recaller Phase b-1 · index name = drp-adr-recall)

index info (削除前に vectorCount を記録):

pnpm --filter drp exec wrangler vectorize info drp-adr-recall

index 全削除 (PoC 撤退時の推奨):

pnpm --filter drp exec wrangler vectorize delete drp-adr-recall --force

個別 vector 削除 (顧客データだけ抜きたい場合 · Phase 2 マルチテナント設計の前提):

// Workers Runtime 内で実行
await env.RECALL_INDEX.deleteByIds(["<vector-id-1>", "<vector-id-2>"]);

注意: --force オプションが無いと wrangler が確認 prompt で止まる (CI 実行不可)。CI 化する場合は --force を必ず付ける。

§2 削除不可レイヤ (4 種類) の契約条項テンプレ

Cloudflare 側で保持されるログ・metadata は、ユーザー側から即時削除 API がない (or 遅延削除しかない)。§1 の削除実行後も一定期間残るため、PoC 顧客契約書 (DPA · GDPR Article 28) で明示的に除外範囲・retention 期間を記載する。

§2.1 Workers 実行ログ (Log Push / Analytics Engine)

  • 理由: Cloudflare が管理する tail log / analytics データ · ユーザー側からの即時削除 API 無し

  • retention: Cloudflare Analytics Engine の保持期間依存 (通常 90 日以内で自動失効)

  • mitigation:

    1. Workers Logs opt-out (wrangler.toml の [observability] で無効化 · ADR-0110 相当)
    2. structured logging で PII (顧客識別情報 · 起案本文) を残さない設計
    3. 残さざるを得ない field は hash 化 (SHA-256 · salt 併用)

  • 契約条項テンプレ (DPA §X.Y 委託先処理範囲):

    委託先 (Cloudflare, Inc.) が Workers Logs / Analytics Engine として保持する実行ログには、リクエストメタデータ (時刻 · request ID · status code 等) が最大 90 日間 保持される可能性がある。当該ログには顧客識別情報および起案本文の平文は含まれず、必要な識別子は SHA-256 で hash 化して保存する。90 日経過後は Cloudflare 側の自動失効により復元不可となる。

§2.2 DO 内部 metadata (alarm / operational trace)

  • 理由: DO storage 内の user data は storage.deleteAll() で削除可能。Cloudflare 側が保持する alarm 状態 / debug trace / operational metrics は削除 API 無し

  • retention: Cloudflare 側 retention policy 依存 (詳細非公開 · 経験則で 90 日以内失効)

  • mitigation:

    1. DO instance destroy 前に alarm を明示解除 (storage.deleteAlarm())
    2. storage.deleteAll() 実行を DO 全 instance に組み込み (§1.3 参照)
    3. DO instance の名前空間に顧客識別子を含めない設計 (Phase 2 マルチテナント対応で見直し)

  • 契約条項テンプレ:

    Durable Objects の内部 metadata (alarm 状態 · operational trace · debug metrics) は Cloudflare が保持する。§1.3 の手順で storage 内容と alarm を削除した後も、当該 metadata は Cloudflare 側 retention (詳細非公開 · 経験則 90 日以内 失効) の間は残存する可能性がある。当該 metadata には顧客の起案内容そのものは含まれない。

§2.3 Queues DLQ retention metadata

  • 理由: DLQ (pipeline-queue-dlq) に格納された message metadata は retention 経過で自動削除される · 手動即時削除 API 無し

  • retention: Queues DLQ の default retention 4 日

  • mitigation:

    1. PoC 撤退時に DLQ consumer を明示 ack で全 message を吸い出す (実装追加要)
    2. pre-validation で DLQ 到達を回避する設計 (schema check · size limit)
    3. retention 経過 (4 日) を明示的に待つ

  • 契約条項テンプレ:

    Cloudflare Queues の DLQ (Dead Letter Queue) に到達した message metadata は Cloudflare 側 retention (default 4 日) の間保持される。§1.4 の手順で consumer 停止後、最大 4 日間は DLQ 内部に message が残存する可能性がある。当該期間経過後は Cloudflare 側の自動失効により復元不可となる。顧客データが DLQ に到達しない設計 (pre-validation) を最善策とする。

§2.4 Vectorize index metadata (embeddings vector 除去後の residual)

  • 理由: index 全削除は可能だが、Cloudflare 側 storage 上での immediate purge は保証されない

  • retention: Cloudflare 側 GC 依存 (詳細非公開 · 一般的な GC 期間は 30 日以内)

  • mitigation:

    1. wrangler vectorize delete --force で index 全体を消す (§1.5 参照)
    2. 個別 vector を deleteByIds() で消してから index 全削除する (2 段階削除で residual を最小化)
    3. Phase 2 マルチテナント設計で顧客ごとに別 index を割当てる (Phase 1 では単一 index を全 PoC で共有)

  • 契約条項テンプレ:

    Vectorize index の全削除 (§1.5) 後も、Cloudflare 側 storage 上での物理 purge は Cloudflare の一般的な GC 期間 (通常 30 日以内) を要する場合がある。当該期間の embeddings vector は復元不可能な形式で保持される。

§3 検証チェックリスト (PoC 撤退完了判定)

削除実行後、下記を全て満たすことで PoC 撤退の完了とする。

  • DRAFTS_KV / PROMPTS_KV / SIGMA_LOG: wrangler kv key list --binding <name> --remote の結果が 0 entry
  • TELEMETRY_DB: SELECT COUNT(*) FROM telemetry_records の結果が 0 row (or database ごと削除で 404 応答)
  • DO: PoC 期間中に発火した instance を purge-do-instances.mjs (§1.3 · 未実装) で destroy 済み。Workers Logs で残存 instance 反応が 無い
  • Queues: consumer 停止済み · DLQ が 4 日経過後 の状態 (retention 自動失効を待つ)
  • Vectorize: wrangler vectorize info drp-adr-recall が 404 or vectorCount = 0
  • §2 契約条項テンプレを顧客契約書 (DPA) に組み込み済み · 顧客署名済み

すべてチェックが揃った時点で、PoC 顧客への完了通知 + ADR-0121 §Confirmation 3 の充足として ADR 追補に記録する。

§4 PoC 顧客契約書テンプレへの紐付け

営業チームが用意する顧客契約書 (別途整備) に、本手順書の §2 契約条項テンプレを引用する形で組み込む。契約書側の記載例:

本サービスに関する Cloudflare 側の残存データ範囲は、docs/decision_pipeline/poc-cleanup-procedure.md §2.1 - §2.4 に定めるとおりとする。当該条項に反する残存が確認された場合、乙 (当社) は甲 (顧客) の要請に基づき Cloudflare サポートに調査を依頼する。

  • § 見出しレベル安定化: 本手順書 §2.1 / §2.2 / §2.3 / §2.4 の見出し番号は将来にわたって固定する。追加削除不可レイヤが判明した場合は §2.5 以降に追加し、既存番号は変更しない。
  • file path の安定化: docs/decision_pipeline/poc-cleanup-procedure.md の path は顧客契約書からの引用元として固定する。移動する場合は redirect ページを残す。

§5 実行順序 (安全策)

削除を安全に進めるための推奨順序:

  1. 記録 — §1.1 - §1.5 の削除前に各 binding の件数 / vectorCount を記録 (wrangler kv key list --binding ... 等)
  2. 停止 — Producer / consumer / cron を全て停止 (drp/wrangler.toml から consumer 定義を外す · schedule を無効化)
  3. 削除 — §1.1 KV → §1.2 D1 → §1.3 DO → §1.4 Queues → §1.5 Vectorize の順で実行
  4. 確認 — §3 チェックリストの全項目を確認
  5. 契約条項の履行 — §2 契約条項テンプレに沿って retention 期間 (最大 90 日) 経過後の再確認を予定
  6. 記録 — 撤退完了記録を docs/_internal/06_ops/lessons_learned.md に追加 (削除件数 · 実行時刻 · 発生した issue)

§6 関連

6.1 SSoT

  • binding 定義: drp/wrangler.toml
  • 削除対象実測: drp/scripts/adr-0121-phase1-list-result-2026-07-01.md (drp PR #3585 · 2026-07-01 実測)
  • 削除対象列挙 script: drp/scripts/list-storage-keys.mjs (再実行で最新化可能)

6.2 関連 ADR

  • ADR-0121 — DRP 製品化 Phase 0+1 (本手順書は §Confirmation 3 = Phase 1 セットアップ出口 の実装)
  • ADR-0019 — Decision Review Pipeline (Pipeline 全体設計)
  • ADR-0042 — LLM prompt lifecycle (PROMPTS_KV)
  • ADR-0066 — Async pipeline queue (PIPELINE_QUEUE)
  • ADR-0074 — Gate 4 scoring σ 監視 (SIGMA_LOG)
  • ADR-0077 — Telemetry (TELEMETRY_DB)
  • ADR-0110 — Workers Logs / observability (Phase 1 opt-out 判断)
  • ADR-0119 — Socratic Session (SOCRATIC_SESSIONS)
  • ADR-0120 — Pipeline Session workflow (PIPELINE_SESSIONS)

6.3 関連 PR

  • PR #3585 (drp session 29) — 削除対象全列挙 script + 実測 artifact
  • PR #3516 (drp session 28) — 審査実績ダッシュボード (Phase 0-1)

6.4 外部資料