# Codex Adversarial Review (9回目) — Decision ADR v3 検証

- 対象: `21_v4_Decision_ADR_v3.html`
- 実行日: 2026-04-17
- Verdict: **needs-major-revision**（critical 2件、high 1件）

---

## Codex 9回目の指摘

### 🔴 [critical] INV-18 が non-Japan services で依然偽の pass
**場所**: §8.6 E9 Data residency、§4.3 INV-18 Hard Gate

**Codex の公式ドキュメント実調査結果**:
- **Cloudflare R2 Data Location**: 公式 docs は EU と FedRAMP 管轄のみ保証。APAC placement は「best-effort location hint」で Tokyo residency 保証ではない
- **Cloudflare Workers**: デフォルトで global に実行。Regional Services / Data Localization Suite は **Enterprise プランのみ** で、subrequests / Queues / Cron に caveat あり
- **Sentry SaaS**: データリージョンは **US (Iowa) or EU (Frankfurt)** の2択、Tokyo なし
- **Better Stack**: デフォルトストレージは **EU**、custom data location は enterprise のみ

→ β でも observability / media / edge execution / alert payload に PII が含まれた場合、日本を出る経路が残る。

**参照**:
- https://developers.cloudflare.com/r2/reference/data-location/
- https://developers.cloudflare.com/data-localization/how-to/workers/
- https://sentry.zendesk.com/hc/en-us/articles/23701210235035
- https://betterstack.com/pricing

**Recommendation**:
- INV-18 を unresolved に降格、per-data-class residency matrix を作る
- 以下のいずれかで解決:
  1. R2/Sentry/Better Stack/Workers log/heartbeat に PII が入らないことを証明（redaction + サンプリングテスト）
  2. Cloudflare Enterprise residency controls を購入（月額数千〜万ドル追加）
  3. non-JP-capable vendor を置換（例: Sentry → 国産の BugSnag 日本拠点、Better Stack → 日本 SRE サービス）

---

### 🔴 [critical] Vault / PITR が「crypto-shredding」や rotation 保証を満たさない
**場所**: §7.3〜7.4 Supabase Vault / crypto-shredding claim

**Codex の Supabase 公式 docs 調査結果**:
- Supabase Vault は **public alpha**、alpha 製品は **uptime SLA 対象外**
- pgsodium は **pending deprecation** と明記されている
- Vault のマスターキーは Supabase 管理で DB 外だが、PITR で 7日前に戻すと **削除した secret が resurrect 可能**（復号もできる）

→ CC の「row delete = crypto-shredding」主張は誤り。GDPR 消去要件の観点で重大。

**Recommendation**:
- row deletion を crypto-shredding と呼ぶのを止める
- 明示的な erasure design を追加:
  - Meta 側で token revoke
  - deletion tombstone を restored dataset の外に保管 or PITR 後に replay
  - backup-retention vs legal-erasure の法的制約を文書化
  - Supabase support guarantees for Vault restore を事前取得
- INV-13 を native/pass から Achievable or Unknown に降格

---

### 🟠 [high] Failure matrix が pg-boss kill を前提、runtime が未定義
**場所**: §8.2 E2 / §8.4 E4

**Codex 指摘**:
- BoM で業務ロジックは Supabase Edge Functions or CF Workers
- pg-boss は **Node/Postgres 背景処理ライブラリ**（常時起動の Node worker host が必要）
- ADR は Tokyo 在住の always-on Node worker host を定義していない
- CF Workers / Supabase Edge Functions は **request/serverless runtime**、signal-kill 不可能

→ E2/E4 の crash injection テストは実際のアーキテクチャでは実行不可能。

**参照**: https://www.npmjs.com/package/pg-boss

**Recommendation**:
- pg-boss を使うなら **実際の job-runner runtime** を specify + コスト化（region/residency 保証付き）
- または pg-boss を削除し、pg_cron + CF Workers scheduled trigger に置換
- E2/E4 を **CF Worker / Supabase / pg_cron の実行モデル**に合わせた deterministic failpoint に書き換える

---

## Next Steps (Codex 推奨)

1. §4/§8 を **per-data-class × per-vendor residency matrix** に patch
2. §7 を Vault 暗号化保管 と crypto-shredding の区別、PITR restore + deletion tombstone テスト追加
3. §8 を実際の async worker runtime を定義 or pg-boss signal-kill 機構を削除
4. 上記完了後、10回目 narrow review

> "without them, this should only be sent as acknowledged hard-gate risk, not as final approval"

---

## CC の評価と次の判断

### Codex 9回目の指摘の性質

今回の指摘は **3回目〜8回目と質的に異なる**:
- 3〜8回目: CC のドキュメントの内部矛盾 / 計算ミス / 設計抜け
- **9回目: ドキュメントの内部ロジックは通っているが、SaaS 業界の構造的限界を指摘**

### つまり、10ラウンド目をやっても同じパターン

- Codex の 2 critical 指摘は「vendor の公式仕様として Tokyo residency / crypto-shredding が提供されない」という**物理的事実**
- どれだけ ADR を磨いても、**SaaS プラットフォームの仕様そのものを変えることはできない**
- 解決策は 3つのいずれか:
  1. **Enterprise plan 購入**（Cloudflare Enterprise / Supabase Team → 月額コスト桁違い）
  2. **セルフホスト**（コンテナベース、運用工数激増）
  3. **リスク受容**（「INV-18 は best-effort、完全担保は phase 2 以降」と明示）

### ここで判断が必要

CC が 10回目 review を目指して ADR を patch し続けるか、<strong>ユーザー判断で決着させる</strong>か。

### 経営判断としての問いかけ

- 100店舗商用 SaaS で「日本国内 PII 完全担保」を SLA 明記するのか、「best-effort」で許容するのか
- 予算を $500-1000/月追加して Enterprise tier を買うか、リスク受容するか
- 10ラウンド以上 Codex を回し続けるか、ここで人間判断するか