# Codex Adversarial Review (6回目) — v4 ADR叩き台検証

- 対象: `15_v4_ADR叩き台.html`
- 実行日: 2026-04-17
- モデル: Codex (openai-codex plugin 1.0.3) via `/codex:adversarial-review`
- 目的: CC 作成の ADR 叩き台を、子安氏送付前に Codex が批判
- 前提: ユーザー（高木）要望「Codex にも確認するように」

---

**Verdict: reject-and-rewrite**

ADR は discussion seed としては有用だが、**子安氏レビュー用としては ship-ready ではない**。最高リスク決定が未解決のまま残っている:
- 識別情報 / 認可（identity / authorization）
- 回復 / ロールバック（recovery / rollback）
- 具体的なアーキテクチャ選択（A vs B の可動域が大きすぎる）
- 現実的な負荷ゲート
- デリバリー範囲

## Findings（重要度順）

### 🔴 [critical] Auth/AuthZ がまだアーキテクチャ決定になっていない
INV-1 は authenticated actor を要求するが、案A は「Cloudflare Access or 独自 session」、案B は「Supabase Auth or Clerk or Auth.js」と**auth を交換可能な provider に還元**している。actor taxonomy（actor 種別）、tenant membership、approver delegation、admin/service actor、CSRF/session model、IG token 保管/rotation、audit actor 識別 が未定義。
→ **主要信頼境界が未定**。ここを決めないと v4 は「文言を満たしつつも v3 と同じ authority バグを別 auth library で再現」する可能性。

**推奨**: スタック選定の前に identity/AuthZ 専用 ADR を作成:
- auth provider 選定
- role と tenant membership ルール
- approval / delegation フロー
- service / admin actor ルール
- token vault / rotation
- CSRF / session ポリシー
- 必須 authorization テスト

---

### 🔴 [critical] 移行ロールバックが「主張」だけで「設計」されていない
INV-10 / G10 / 移行セクションは store 単位のロールバックと 10分カットオーバーを約束しているが、ADR には feature flag と履歴比較しか書かれていない。以下が未対応:
- scheduled-post freeze/drain
- IG token 移管
- ID マッピング
- media rehydration
- v4 writes created before rollback
- 重複 publish 防止
- partial cutover 後の reconciliation

→ **移行失敗で履歴破損・予約投稿消失・Instagram 重複公開のリスク**。

**推奨**: 移行専用 ADR を別立て:
- データインベントリ
- dry-run ツール
- checksum / diff ルール
- idempotent import/export
- queue drain / freeze ポリシー
- token / media ハンドリング
- dual-read / dual-write 判断
- rollback state ownership
- store 単位リハーサル
- 10分根拠の明示

---

### 🟠 [high] Invariant セットが incomplete かつ mis-prioritized
10 invariants は v3 の既知失敗をカバーしているが、以下が未記述:
- schema evolution / compatibility
- backup / restore drill
- retention / deletion / GDPR
- secrets lifecycle
- cost / resource quota
- disaster recovery
- deployment safety
- data migration compatibility

さらに、**INV-8（recovery）/ INV-9（abuse）/ INV-10（migration）を SHOULD にしているが、どれか1つでも100店舗商用ローンチをブロックする MUST 級**。ADR が「v4 は 10 invariants を満たせば良い」と書いているため、**欠けた invariant はスキップ許可証になってしまう**。

**推奨**:
- INV-8, 9, 10 を MUST 昇格
- 追加の launch-blocking invariant を作成:
  - authz
  - schema/versioning
  - backup/restore
  - retention/deletion
  - secrets/token lifecycle
  - disaster recovery
  - cost/quota governance
  - deployment/rollback safety
- 各 invariant に測定可能な acceptance test

---

### 🟠 [high] 負荷ゲートが「実際に壊れる failure burst」をモデル化していない
G1〜G10 は平均と単純 request rate のみ。以下をモデル化していない:
- 相関した飲食店投稿時間（ランチ・ディナー集中）
- メンテナンス後 / IG 障害後のキャッチアップ
- token refresh 失敗
- webhook/event delivery rate
- 同時 settings 変更
- media size distribution
- tenant-specific hot spot
- noisy-neighbor isolation

さらに、G3 は「100 req/5分」だが 1 post は複数 Graph API call + polling を要する。G6「1時間 outage 後の 5分内全復旧」は rate-budget math なしの主張。G10 は「未設計」のまま gate に置かれている。

**推奨**: テーブルを load/failure matrix に置換:
- p50/p95/p99 normal load
- per-tenant burst limits
- outage catch-up
- webhook/token-refresh storm
- media dimensions
- IG rate-budget math
- noisy-neighbor quotas
- 各ゲートの prototype pass/fail test

---

### 🟠 [high] 案A と案B は「option family」であって「比較可能なアーキテクチャ」ではない
**案A** は DO / Queues / R2 / D1 の一貫性契約を未定義。per-tenant AuditAppenderDO は singleton を避けるが、tenant audit write をシリアライズするだけで、backpressure / replay / cold-start / queue redelivery / recovery semantics が未定義。

**案B** は Fly/Railway/Supabase、pg-boss/BullMQ、Upstash/Fly Redis、複数 storage 選択肢をバンドルしており、各々が異なる HA と failure mode を持つ。

→ ADR は**ラベルを比較しているだけで具体的にデプロイ可能なシステムを比較していない**。Option B 推奨は under-determined。

**推奨**:
- 案A / 案B を**1つの具体的な bill of materials** に narrow
- state ownership と consistency contract を追加
- queue / redelivery / backpressure / DR 挙動を記述
- declare 前に少なくとも 1つの hybrid or monolith alternative を追加

---

### 🟠 [high] Option B 推奨は evidence-light かつ familiar tool バイアス
比較表は B に「natural」「industry standard」「prior art」「debugging」で勝ちを与えているが、**子安氏の経験未知、prototype 必須** と自認している。これは**preference であって ADR decision ではない**。

さらに**「間違った案を選んだ場合のコスト」を省略**: auth, job queue, storage, migration script, operational runbook の再構築コストが抜けている。

**推奨**:
- B を「仮説」として再フレーム
- 1週間の prototype scorecard を作成（hard pass/fail 基準）:
  - authz
  - publish idempotency
  - audit append
  - retry storm
  - migration dry-run
  - observability
  - operator debugging
- 明示的な switching cost 見積

---

### 🟠 [high] タイムラインとスコープが主張リスクに対して credible でない
140〜232h を auth / publish / approval / upload / audit / observability / migration / load test / hardening に割り当てているが、Week 17-18 に production load/security review を push、Week 19-20 に migration を push。

risk table 自身が「3ヶ月超過は high probability」と書いているのに、scope cut は 2機能（LINE 通知 / F-04）だけ。
- **MVP vs full-feature split がない**
- **integration / rework budget がない**
- **1 engineer + CC support の delivery plan がない**

**推奨**:
- Phase 1 MVP vs Phase 2 を明示
- security / migration / load validation を prototype フェーズに前倒し
- contingency と review/rework 時間を加算
- staffing assumption を明記
- 3ヶ月が mandatory なら architecture 承認前に scope 削減

---

### 🟠 [high] ADR がハード決定を子安氏に丸投げしている
本書は draft と自称しつつ、以下を子安氏に validate 依頼:
- invariants
- load envelope
- option 選定
- prototype スコープ

→ **承認依頼には unresolved decision が多すぎる**。以下がない:
- final Decision section
- rejected alternatives
- assumptions
- consequences
- open-risk register
- evidence required

子安氏は**本書の半分を自分で再導出しない限り approve/reject/modify できない**。

**推奨**: 本物の ADR に rewrite:
- proposed decision
- accepted/rejected alternatives
- assumptions
- consequences
- unresolved risks
- evidence required
- owner/deadline
- **子安氏 input が必要な「正確な質問」だけ切り出す**

---

### 🟠 [high] Operational ownership が欠落（INV-7 が MUST なのに）
INV-7 は real-time detection と 90日 postmortem ログを要求するが、operational plan はツール名と「24/7 可能か？」のオープン疑問だけ。以下が未定義:
- SLO/SLA
- アラート閾値マトリクス
- pager ownership
- incident runbook
- backup restore drill
- access review
- release gate
- schema migration process
- support escalation

→ **v4 は stack 選定が正しくても 100店舗で unserviceable になり得る**。

**推奨**: operating-model section を追加:
- SLO
- alert threshold
- on-call owner
- incident / rollback runbook
- backup/restore cadence
- access review
- release / change-management gate
- 最初の paid migration 前に必要な minimum observability dashboard

---

### 🟡 [medium] コスト比較がビジネス判断に guide できるほど広くない
cost table は月額 infra line items のみで「コストは判断基準にならない」と結論しているが、以下が omit:
- staging/dev 環境
- HA tier
- backup/PITR
- restore testing
- log ingestion / retention at volume
- alerting seat
- paid support
- security review
- incident response
- data egress
- migration labor
- on-call / human ops

¥3.5M/月の製品では、**infra $120 vs $200/月ではなく TCO と operational risk が重要**。

**推奨**: 月額 infra 推定を **3年 TCO モデル** に置換:
- production / staging / dev
- HA / backup / observability tier
- incident / on-call labor
- security / compliance work
- migration cost
- 30/100/300 store での cost-per-store 感度分析

---

## Next Steps（Codex 最終推奨）

1. **本 ADR を現状のまま 子安氏に送らない**。明示的な proposed choice と unresolved question を分離した decision document に rewrite
2. **auth/AuthZ / migration rollback / load-failure gate を最初の revision target** に（rework コストが最も高いブロッカー）
3. **auth model と具体的な A/B bill of materials が確定してから prototype を走らせる**（そうしないと曖昧なアーキテクチャを比較することになる）

---

## ユーザーへの直接メッセージ

> 「Codex にも確認するように」との依頼を履行した結果、**CC の ADR 叩き台は Codex に reject-and-rewrite 判定された**。v3 の whack-a-mole パターンを v4 ADR でも同じく「表面を整えただけ」に陥らせないため、Codex は厳しく批判している。

> これは CC が下手なのではなく、**「叩き台→子安氏」の一段飛ばしが構造的に無理**という指摘。子安氏に渡すなら、CC がもう 1〜2 段、auth ADR / migration ADR / 具体的な bill of materials / TCO モデルを固める必要がある。

> ユーザーはここで方針選択が必要:
>
> 1. **CC が追加で ADR を深堀り**（auth ADR + migration ADR + BoM + TCO = 追加 12〜20h）してから子安氏に渡す
> 2. **現状の叩き台 + Codex レビュー（本書）を両方子安氏に送る**。子安氏に「叩き台 + 批判」で議論してもらう
> 3. **子安氏との初回 MTG（1時間）に叩き台を使い、Codex 批判を議論材料に**。MTG で ADR の骨格を合意してから CC が深堀る