v4 Decision ADR v3 — β採用・vendor実価格TCO版

2026-04-17 | Claude Code | v2(19)を Codex 8回目指摘6件で全面改訂 + vendor 実価格で Decision 再検証

1. 実現したいこと（要件）

v2(19) と同一。1.1 ビジネス要件 / 1.2 機能要件 / 1.3 運用要件は 19 §1 を参照。

1.1 変更なしの要件サマリ

• 飲食店向け IG 自動投稿 SaaS、¥20k/¥35k 月額
• 100店舗 目標、300店舗 水平拡大上限
• MVP: F-A/B + F-01/02/03/06/07/08、Phase 2: F-03b/F-09/F-04、Phase 3: F-05
• SLO: 予約投稿 99.5% / API p95 < 60s / 月 downtime < 2h
• RTO 1h / RPO 5min / 24/7 escalation

2. Invariants（v2 から変更なし、20項目全て MUST）

INV-1〜20 の内容は 19 §2 と同一。

3. 候補案 Bill of Materials（β 採用版）

3.1 採用案 β — Supabase + Cloudflare Workers hybrid

3.2 Rejected 案 γ — Neon + Clerk + Trigger.dev

3.3 Rejected 案 α — Cloudflare all-in

Codex 7/8回目 と同じく Hard Gate 失敗で Reject:

• INV-8 Recovery: D1 は PITR 非対応、wrangler d1 export 日次では RPO 24h が上限（SLO RPO 5min 不達成）
• INV-12 Backup/Restore: 同上

4. スコアリング再評価（β 採用版）

4.1 Rubric（v2 から変更なし）

5=Native / 4=Sound / 3=Achievable / 2=Difficult / 1=Blocked（Hard Gate） / ?=Unknown

4.2 Hard Gate（INV-3 / 8 / 12 / 13）

• α: INV-8=1, INV-12=1（D1 PITR なし）→ Hard Gate 失敗
• β: INV-3=5 / INV-8=5 / INV-12=5 / INV-13=5 → Pass
• γ: INV-3=5 / INV-8=5 / INV-12=5 / INV-13=4 / INV-18=1（Tokyo 非対応）→ INV-18 を MUST 化で追加 Hard Gate 失敗

4.3 INV-18 を Hard Gate に昇格

Codex 8回目指摘 #3 対応で INV-18 を pre-Q1 blocker に。評価は以下:

4.4 β の Weighted Score（Hard Gate 通過後 16項目）

INV-1〜17, 19, 20（INV-18 は Hard Gate）でスコア合計:

• INV-1=5, INV-2=5, INV-4=4, INV-5=5, INV-6=5, INV-7=5, INV-9=4, INV-10=4, INV-11=5, INV-14=5, INV-15=4, INV-16=3, INV-17=3, INV-19=5, INV-20=4
• 合計: 66/75

5. 3年 TCO（vendor 実価格版）

5.1 Vendor 実価格（2026年4月時点）

実調査ソース: supabase.com/pricing, developers.cloudflare.com/workers/platform/pricing, betterstack.com/pricing, sentry.io/pricing

5.2 月額コスト（100店舗・現実シナリオ）

5.3 3年 TCO（100店舗ベース）

5.4 感度分析

重要: 30店舗停滞時は運用工数 + Better Stack/Sentry 固定費が重い。 30店舗到達まで Better Stack を 1 responder にして $34/月に抑える、 Sentry は Developer plan $26 を Hobby (Free) から始める選択肢を追加。

6. Decision（v3 最終）

6.1 β を γ より選ぶ決定的理由

1. INV-18 Data Residency が Hard Gate: γ は Neon/Clerk/Trigger.dev とも Tokyo 非対応で日本 PII 越境。β は Supabase Tokyo region 公式サポートで完全クリア
2. 単一ベンダ集中による composite availability 向上: Supabase 99.9% + CF 99.99% ≒ 99.89%（月 72分 downtime、γ の 113分より優位）
3. Vendor 管理の簡潔さ: 4ベンダ（Supabase, CF, Sentry, Better Stack） vs γ 6ベンダ
4. 実価格 TCO でも劣位なし: Supabase PITR add-on $100/月で γ と同等、Neon Scale の $160〜700 より安定
5. pgsodium Vault で INV-13 Secrets lifecycle が native 実装: γ で要求した envelope encryption のカスタム実装が不要

6.2 β の弱点と mitigation

7. MEK / Secrets 設計（β 版、pgsodium ベース）

7.1 Supabase Vault (pgsodium) の活用

Supabase は Vault（pgsodium 拡張ベース）を native に提供。secret の暗号化保管と復号ヘルパが SQL から使える。

-- IG token を暗号化保管
SELECT vault.create_secret(
  'ig_access_token_plaintext_here',
  'ig_token_store_001',
  'Instagram access token for store_001'
);

-- 復号
SELECT decrypted_secret FROM vault.decrypted_secrets WHERE name = 'ig_token_store_001';

7.2 Key Rotation (pgsodium)

pgsodium は master key rotation を自動管理。Supabase 側で encryption key の世代管理を 内部で行うため、アプリ側は rotation job を持たなくて良い。 Codex 8回目指摘 critical（MEK rotation と PITR の矛盾）は β 採用で自動解決。

7.3 Revocation / Crypto-shredding

• 店舗解約時: SELECT vault.update_secret(id, null) または row DELETE で secret 消去
• IG token 漏洩疑い: 該当 secret を削除 → F-06 Cron で refresh token から再取得
• 全体漏洩対応: Supabase サポートに master key rotation を依頼（enterprise-grade 対応）

7.4 PITR との整合

Supabase PITR は Vault data を含めて過去時点に restore 可能。 master key は Supabase が管理するので、restore 時にも自動的に対応する master key で復号できる。 v2/v3 の γ 設計で問題になった「MEK 削除で PITR restore 後に復号不能」という矛盾は発生しない。

7.5 Audit

以下を audit_logs に記録:

• secret create（どの actor / どの store / IG token scope）
• secret decrypt（どの actor / 目的）
• secret delete / rotate（actor / 対象）

8. Evidence Failure Matrix（v3 修正版）

8.1 E1 Authz matrix

v2 (19 §10.1) と同じ。Supabase Auth + RLS policies の test。

8.2 E2 Publish idempotency（crash injection mechanics 追加）

8.3 E3 Audit append（100並行）

Test mechanics: k6 or autocannon で 100 並行リクエスト、各 endpoint が audit_logs.append を呼ぶ。 Postgres advisory lock (pg_advisory_xact_lock) + seq INSERT 原子的。 Pass: 全 100行が prev_hash で連結、seq 連番、fork ゼロ。

8.4 E4 Retry storm mechanics

8.5 E5 Migration dry-run mechanics

8.6 E6〜E9（v2 と同じ、INV-18 を β では pass 前提）

E9 Data residency: β 採用により Supabase Tokyo + CF Tokyo + R2 で全ベンダ JP region 対応。PII が region を出ない設計を確認。

9. Operating Model（v2 と同じ、24/7 採用）

v2 (19 §12) と同じ。子安氏への質問 Q6 として on-call 受諾 + compensation 確認を追加（§11 参照）。

9.1 8つの Runbook（P1 優先 6本をドラフト作成対象に）

1. R1 予約投稿一括失敗（P1）
2. R2 Instagram outage 中の顧客コミュニケーション（P1）
3. R3 Supabase Auth 障害時の degraded login（P1）
4. R4 Supabase DB 障害時の read-only mode（P1）
5. R5 pg-boss 不整合時の手動 cron（P2）
6. R6 Audit chain fork 検知時 forensics（P1）
7. R7 Secret 漏洩時の緊急 rotation（P1）
8. R8 店舗単位 v4→v2 rollback（P2）

10. Delivery Plan（v2 から軽微調整）

Phase 1 MVP 12週間は v2 と同じ。ただし Week 3-4 の Auth 実装は Clerk → Supabase Auth に変更のため工数は同等。

11. 子安氏への依頼事項（Q1-Q6）

11.1 進め方

• 本書 + 20 Codex 8回目レビュー + Codex 9回目レビュー（narrow）を送付
• 48h 以内に Q1-Q6 回答
• Q1 = Yes かつ Q5 重大項目なし・Q6 合意可能 → prototype phase 即着手
• それ以外 → 60分 MTG で議論

12. 付録：関連ドキュメント

• 19 v2（γ採用版、Codex 8回目で needs-major-revision）
• 20 Codex 8回目レビュー（本書 v3 の指摘元）
• 17 v1（Codex 7回目で needs-major-revision）
• 13 CC アーキテクチャ根本監査
• 14 Codex 5回目（v3 no-ship 判定）