# Codex Adversarial Review (7回目) — Decision ADR 検証 - 対象: `17_v4_Decision_ADR.html`（CC が要件ベースで作成した Decision 文書） - 実行日: 2026-04-17 - 目的: 子安氏送付前の最終検証 --- **Verdict: needs-major-revision**（reject-and-restart ではなく、**1 focused revision** で ship 可能） ADR は 6回目（reject-and-rewrite）から大幅改善されたが、**子安氏送付前に 5つの穴を埋める必要**がある。γ 方向性自体は妥当。 ## Findings（5件） ### 🔴 [critical] INV-13 Secrets lifecycle が「scored 5」だが γ には vault 設計がない INV-13 は JWT/暗号鍵/IG token の rotation/revocation/audit を vault 経由で要求するが、γ BoM は Cloudflare Secrets + Clerk 内蔵 key のみ。per-store IG token の暗号化 / version 管理 / revocation / audit / Neon 上での restore 挙動 が未定義。 **さらに矛盾**: 9.3 Migration Consequences で「pgsodium の v1 key に統一」と書いたが、**γ は Neon であって Supabase ではない**。pgsodium は Supabase 固有の拡張。 **推奨**: γ 専用の secrets 設計を追加: - KMS/vault provider - envelope encryption schema - key version table - token rotation/revocation flow - audit events - restore behavior - v2 token の migration → pgsodium 参照は削除 or β 採用時に再掲 --- ### 🟠 [high] TCO モデルが内部矛盾で γ 最安を支えない TCO table で Clerk $25/月 × 36 = $900 と計算しているが、Rejected Alternatives 7.2 で「子安氏が $25/月 × 100店舗 = $2,500/月 を高いと判断する場合」と書いた。**両方の前提を同じ決定に使えない**。 さらに incident cost（α ¥1.5M, γ ¥0.3M）が根拠なし。30/100/300 店舗の scenario や staff sub-account の scale 試算が抜けている。 **推奨**: 30/100/300 店舗 × 2-5 staff/store の scenario テーブルに置換。Clerk の billing 前提を1つに統一。Trigger.dev と paid support tier を含める。hard cost と risk-adjusted incident 推定を分離。 --- ### 🟠 [high] Operating Model が SLO/RTO と矛盾 ADR は 99.5% publish 成功 / p95 publish API <60秒 / 月間 downtime <2時間 / RTO 1時間 / RPO 5分 を定義。しかし on-call plan は **平日 9-19時対応、時間外は翌営業日** になっている。 金曜 20時の予約投稿失敗 / retry 枯渇 / ベンダ障害で operator 介入が必要な場合、**documented process は RTO も commercial promise も満たせない**。「Automatic retry is not an operating owner when retry is the thing that failed」。 **推奨**: 二者択一: 1. **SLA/RTO を business-hours 言語に downgrade**（「営業時間内で」と明記） 2. **publish-impacting incident は 24/7 escalation path** を定義（owner, PagerDuty, runbook, ベンダ status 確認, 顧客通知ルール） --- ### 🟠 [high] スコアリングが依然 preference-driven 1-5 スコアリングに **rubric（3/4/5 の分離基準）がない**、**hard-gate vs weighted-score の区別がない**、disputed 行の evidence が欠落。 具体例: - Cloudflare Access + custom approver session が 2、Clerk が 5 → 根拠薄い - Durable Objects の idempotent publish が 3 → **DO はまさに single-writer 用に設計されている**のに低スコア - D1 daily export が「RPO/RTO を満たせない」と証明なしに却下 → **Postgres/Clerk familiarity を invariant fit として偽装している可能性**。 **推奨**: - 各 invariant にスコアリング rubric を追加 - 未知は 5 でなく "unknown" と marking - launch-blocking gate と preference score を分離 - 争いのある α vs γ 行には evidence/citation/prototype check を追加してから合計を使う --- ### 🟠 [high] Evidence gate が core failure mode を見逃したまま pass 可能 - **E2**（Worker crash retry）: crash のタイミングを列挙していない（IG media creation 前後 / Graph API 成功後 DB commit 前 / DB commit 後 Trigger.dev ack 前 / reconciliation 中） - **E4**（outage 復旧）: backlog size / tenant 数 / IG rate-limit 挙動 / outage が mock か real dependency failure か未定義 - **E5**（migration dry-run）: v2 10店舗のみ、dataset size / dual-write rollback 基準なし → Week 1-2 で E1〜E7 が pass しても **duplicate publish / retry storm / migration / rollback リスクが未解決で残る**。 **推奨**: E2〜E5 を **failure matrix** に: - 全外部 side-effect boundary で crash injection - Trigger.dev/Neon/Clerk outage ケース - 30/100/300 店舗の backlog size - IG rate-limit/backoff 挙動 - 現実的な history/media volume での migration - explicit rollback/reconciliation pass 基準 --- ### 🟡 [medium] Invariant に multi-vendor SLA と compliance が抜けている γ は Clerk / Neon / Trigger.dev / Cloudflare / Better Stack / Instagram の 6ベンダに依存するが、15 MUST invariants は以下を含んでいない: - composite vendor availability（複合稼働率） - support/SLA tier requirement - data residency（日本居住データ） - customer data export/portability（GDPR） - AI prompt/response audit retention - public API versioning（顧客が API 連携する場合） γ が 73/75 スコアを取りながら、**これらの reliability/compliance リスクは選択されたアーキテクチャが複数ベンダに依存しているからこそ存在**する。 **推奨**: MUST または SHOULD に追加: - composite availability（各ベンダSLA の積） - vendor outage/fallback behavior - data residency / export - AI audit logging / redaction / retention - API compatibility / versioning 追加後、α/β/γ を再スコアリング。 --- ## Next Steps（Codex 最終推奨） 1. **ship-to-子安氏 ではない**。needs-major-revision（reject-and-restart ではない） 2. **1 focused revision** で以下 5点を修正: - Secrets 設計（γ 専用） - TCO scenario-based リモデル - スコアリング rubric 追加 - Operating model 修正（SLO downgrade or 24/7 path 追加） - Evidence failure matrix 化 - Invariant に compliance/multi-vendor 追加 3. 修正後、Q1-Q4 に「blocking concerns 自由記述」欄を追加 4. **Q1=Yes でも即 prototype 着手させない**。γ-specific risks（Trigger.dev / Neon latency / Clerk billing / IG token secrets）に concrete pass/fail gate が必要 --- ## 結論とアクション Codex は **γ 方向性を否定していない**。構成自体は要件に対して妥当（案α は D1 PITR不在で構造的に不足、案β との比較も妥当）。ただし **現状の ADR には子安氏が Q1 に Yes と答えるには詰めが足りない箇所が 5つ**ある。 ### 必要な追加作業（CC） - Secrets 設計の詳細化: 2h - TCO scenario テーブル化: 2h - スコアリング rubric 追加: 1h - Operating model 二択明記: 1h - Evidence failure matrix 化: 2h - Invariant 追加 + 再スコア: 2h - **合計 10h** これを実施してから子安氏に送る方針が合理的。