v4 Decision ADR v4.1 (Final) — C採用・PII最小化設計

2026-04-17 | Claude Code | v4.1 patch: Codex 10回目指摘3件を in-place 織り込み（契約書/SQL claim/Meta revoke）

1. v3(21)→v4(23) 主要変更点

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

v3 (21) と同一。19 §1 参照。

2.1 ビジネスサマリ（再掲）

• 飲食店向け IG 自動投稿 SaaS、¥20k/¥35k 月額
• 100店舗目標（¥3.5M/月売上）、300店舗水平拡大
• SLO: 99.5% / p95 60s / 月 downtime < 2h / RTO 1h / RPO 5min

3. Invariants（20項目 MUST、INV-18 は best-effort に降格）

3.1 MUST 19項目

INV-1〜17, 19, 20 は v3 (21) と同一で MUST。

3.2 INV-18 Data Residency（best-effort + 契約範囲明記）

3.3 データクラス定義

3.4 契約書明記テンプレート（案）（v4.1: Codex 10回目指摘 #1 で Anthropic 追加 + CF log 詳細分類）

第X条（データ処理とサブプロセッサ）

1. 当社（AI経営共創パートナーズ）は以下のサブプロセッサを利用します:
   - Supabase Inc.（米国法人、データは日本国内保管）:
       用途: データベース・認証・シークレット管理
       データ処理場所: 東京リージョン（AWS ap-northeast-1）
   - Cloudflare Inc.（米国）:
       用途: フロントエンド配信・API Gateway・WAF・画像ストレージ（R2）・ログ
       データ処理場所: 全世界エッジ（リクエストは最寄りエッジで処理）
   - Anthropic PBC（米国）:
       用途: Claude AI によるキャプション生成・画像分析
       データ処理場所: 米国
       送信データ: 店舗がアップロードした料理画像、生成指示プロンプト
       保持: Anthropic の standard retention（最大30日、学習には使用しない契約）
   - Sentry Inc.（米国）:
       用途: エラー監視・パフォーマンス監視
       データ処理場所: 米国（US tier）
   - Better Stack s.r.o.（チェコ）:
       用途: 死活監視・アラート
       データ処理場所: EU

2. 【Class 1 情報】貴店舗に関する以下の情報は日本国内のみに保管します:
   - 店舗情報（店舗名・住所・電話番号）
   - Instagram 連携情報（user_id・access_token・refresh_token、すべて暗号化）
   - 承認者メールアドレス・店舗管理者アカウント情報
   - 投稿履歴のテキスト部分（キャプション・ハッシュタグ・画像管理ID）
   - 操作履歴・監査ログ（IP アドレス・user-agent・actor_id を含む）
   → 保管先: Supabase 東京リージョン（AWS ap-northeast-1）

3. 【Class 2 情報】以下の匿名化・redaction 済みデータは国外サブプロセッサを
   経由する可能性があります:
   - 匿名化されたエラー trace（store_id をハッシュ化、caption_text をマスク）
     → Sentry（米国）
   - サービス死活監視の heartbeat
     → Better Stack（EU）
   - Cloudflare edge logs（IP 末尾オクテット削除、path は集約済）
     → Cloudflare グローバル

4. 【Class 3 情報】画像データは以下のとおり扱います:
   - 料理画像（Class 3、PII ではない）:
     * Cloudflare R2 の APAC placement（東京近傍、best-effort、契約保証なし）
     * Anthropic Claude API（米国、キャプション生成のため送信）
   - 画像には店舗を特定できる情報（看板・メニュー表等）が含まれる場合、
     貴店舗は投稿前に確認する責任を負います。

5. Class 2 データの redaction 実装は以下を最低限守ります:
   - 個人を特定可能な識別子（名前・メール・電話）の除去
   - IP アドレスの末尾オクテット削除または都道府県レベル集約
   - store_id のハッシュ化
   - Claude API 送信時も同様の redaction を適用

4. データクラス × Vendor マトリクス（Codex 9回目指摘 #1 対応）

凡例: 5=Native / 4=Sound / 3=Achievable / 2=要注意 / BE=Best Effort（契約書明記）

4.1 Class 1 データのフロー（JP region 固定）

ユーザー (店舗ブラウザ)
   ↓ HTTPS
Cloudflare Workers (edge: 最寄り、処理のみ・保管なし)
   ↓ HTTPS (JP region 固定)
Supabase Postgres / Auth / Vault (Tokyo ap-northeast-1)
   ← Class 1 データはすべてここに保管

4.2 Class 2 データ（redaction 後に外部送信）

Cloudflare Workers
   ↓ エラー発生時
   ↓ redaction処理（PII除去）
   ↓
Sentry (US or EU)
   - store_id → ハッシュ化
   - caption_text → マスク
   - IP → 末尾オクテット削除

4.3 Class 3 データ（画像、APAC best-effort）

店舗ブラウザ
   ↓ presigned URL (10min 有効)
Cloudflare R2 APAC placement
   - Tokyo 近傍に配置される（best-effort）
   - EU/FedRAMP のような契約保証はなし
   - 画像自体は PII ではない（料理写真のみ）

5. Bill of Materials（v3 から pg-boss を削除）

5.1 新 async 処理設計（pg_cron + SQL claim_jobs 関数）（v4.1: Codex 10回目指摘 #2 対応、advisory_lock の誤用を修正）

Job queue テーブル

CREATE TABLE job_queue (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  kind TEXT NOT NULL,              -- 'publish_post', 'reconcile_ig', 'refresh_token'
  payload JSONB NOT NULL,
  idempotency_key TEXT UNIQUE,     -- IG API 重複実行防止キー
  state TEXT NOT NULL DEFAULT 'pending',  -- 'pending', 'processing', 'done', 'failed'
  scheduled_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  locked_by TEXT,                  -- 実行中 worker の ID
  locked_until TIMESTAMPTZ,        -- lease 期限（タイムアウト後は他worker が claim 可）
  attempts INT NOT NULL DEFAULT 0,
  max_attempts INT NOT NULL DEFAULT 3,
  last_error TEXT,
  next_attempt_at TIMESTAMPTZ,
  created_at TIMESTAMPTZ NOT NULL DEFAULT now(),
  finalized_at TIMESTAMPTZ
);

CREATE INDEX idx_job_queue_ready ON job_queue (scheduled_at, state)
  WHERE state IN ('pending', 'processing');

原子的 claim 関数（SQL 1文で race-free）

CREATE OR REPLACE FUNCTION claim_jobs(
  p_worker_id TEXT,
  p_lease_seconds INT DEFAULT 300,
  p_max_jobs INT DEFAULT 5
) RETURNS SETOF job_queue AS $$
  -- SKIP LOCKED で並行 worker が同じ行を取らない
  -- state='processing' AND locked_until < now() の expired lease も対象
  UPDATE job_queue
  SET
    state = 'processing',
    locked_by = p_worker_id,
    locked_until = now() + (p_lease_seconds || ' seconds')::interval,
    attempts = attempts + 1
  WHERE id IN (
    SELECT id FROM job_queue
    WHERE scheduled_at <= now()
      AND (next_attempt_at IS NULL OR next_attempt_at <= now())
      AND attempts < max_attempts
      AND (
        state = 'pending'
        OR (state = 'processing' AND locked_until < now())
      )
    ORDER BY scheduled_at ASC
    LIMIT p_max_jobs
    FOR UPDATE SKIP LOCKED
  )
  RETURNING *;
$$ LANGUAGE SQL;

finalize関数（CAS で lease 所有者のみ commit 可能）

CREATE OR REPLACE FUNCTION finalize_job(
  p_job_id UUID,
  p_worker_id TEXT,
  p_success BOOLEAN,
  p_error TEXT DEFAULT NULL,
  p_retry_after_seconds INT DEFAULT NULL
) RETURNS BOOLEAN AS $$
DECLARE
  v_changed INT;
BEGIN
  IF p_success THEN
    UPDATE job_queue
    SET state = 'done', finalized_at = now(), last_error = NULL,
        locked_by = NULL, locked_until = NULL
    WHERE id = p_job_id AND locked_by = p_worker_id AND state = 'processing';
  ELSIF p_retry_after_seconds IS NOT NULL THEN
    UPDATE job_queue
    SET state = 'pending', last_error = p_error,
        next_attempt_at = now() + (p_retry_after_seconds || ' seconds')::interval,
        locked_by = NULL, locked_until = NULL
    WHERE id = p_job_id AND locked_by = p_worker_id AND state = 'processing';
  ELSE
    UPDATE job_queue
    SET state = 'failed', last_error = p_error, finalized_at = now(),
        locked_by = NULL, locked_until = NULL
    WHERE id = p_job_id AND locked_by = p_worker_id AND state = 'processing';
  END IF;

  GET DIAGNOSTICS v_changed = ROW_COUNT;
  RETURN v_changed = 1;  -- false なら lease 喪失（他 worker に奪われた）
END;
$$ LANGUAGE plpgsql;

実行モデル

Primary: pg_cron (Supabase内、Tokyo)
  * * * * * →
    SELECT * FROM claim_jobs('pg_cron_worker_' || gen_random_uuid(), 300, 5);
    → 各 job を Supabase Edge Functions に委譲（非同期呼び出し）
    → Edge Functions 内で finalize_job() を呼ぶ
    ※ pg_cron 自体は 10分以内に完了（claim のみ、実処理は Edge Functions）

Secondary (watchdog/reaper): Cloudflare Workers Scheduled Trigger
  */5 * * * * →
    REST API 経由で expired lease の job を SELECT
    → pg_cron 停止時の fallback（stuck job を claim し直す）
    → 通常時は対象ゼロ

設計の key points

• advisory_lock を使わない: session-scoped で timeout 機能を持たないため誤用リスク。 代わりに locked_until カラム + FOR UPDATE SKIP LOCKED で atomic claim
• claim は 1 SQL 文: UPDATE + RETURNING で race-free
• finalize は CAS: WHERE locked_by = ? で lease 所有者のみ commit 可、changes=0 で奪取検知
• idempotency_key: IG API 呼び出し前に付与、重複実行防止
• CF Workers は watchdog: primary は pg_cron、CF は stuck job reaper のみ（dual active 廃止）
• Supabase Cron 10分制限準拠: claim_jobs のみ pg_cron で実行、実処理は Edge Functions に非同期委譲

5.2 Failure matrix の再設計

E2 crash injection:

• Lease 喪失後の job 復帰: worker が finalize 前に死ぬ → locked_until 経過後に別 worker が claim → idempotency_key により IG 二重投稿なし
• Split-brain 防止: finalize の CAS により、元 worker が lease 喪失後に finalize しようとしても changes=0 で検知
• Edge Functions throw: 例外で終了した場合、lease が切れるまで再処理されない（5分）が、worker が定期的に lease を更新する設計で長時間 job もサポート可

6. Decision（v4 最終）

7. TCO (C 採用時の実価格、v3 と同等)

Enterprise plan 購入なし、既存 vendor pricing で運用。v3 (21) §5 と同じ試算。

3年 TCO ¥6.7M / 100店舗売上 ¥3.5M/月 / 粗利率 94.7%（v3 と同じ）

8. Erasure 設計（Vault + PITR 整合）

8.1 問題の正確な認識

• Supabase Vault マスターキーは Supabase 管理なので、PITR で戻すと削除済み secret も復号できる
• → 「row delete した瞬間から 7日間は PITR で復元可能」（GDPR 消去 30日以内を満たすには 8 日目以降 OK）
• Vault は public alpha、pgsodium は pending deprecation → 将来の選択肢確保必要

8.2 採用する erasure flow （v4.1: Codex 10回目指摘 #3 で Meta revoke 具体化 + blocking branch）

Step 1: Meta 側で token revoke（具体化）

Target: Instagram Business Account に紐付く IG access_token

Endpoint（Meta Graph API 公式）:
  DELETE https://graph.facebook.com/v21.0/{ig-user-id}/permissions
    ?access_token={access_token}
  # App に与えた全権限を一括 revoke（instagram_basic, pages_show_list 等）

  または個別 permission:
  DELETE https://graph.facebook.com/v21.0/{ig-user-id}/permissions/{permission-name}

Required credentials:
  - access_token（revoke 対象の token そのもの、または app access_token）

Expected response:
  { "success": true }
  # success != true or HTTP != 200 の場合は revoke 失敗

Post-revoke 検証（必須）:
  GET https://graph.facebook.com/debug_token?input_token={access_token}
      &access_token={app_id}|{app_secret}
  # is_valid=false なら revoke 成功
  # is_valid=true なら revoke 失敗（blocking branch へ）

参照: https://developers.facebook.com/docs/graph-api/reference/user/permissions/

Step 2: DB 側で tombstone

- stores.deleted_at = now() 設定（soft delete）
- vault secret を vault.update_secret(id, '__REVOKED__') で上書き
- 業務クエリは WHERE deleted_at IS NULL で除外
- audit_logs に {action: 'token_revoke', revoke_verified: true/false, meta_response} を記録

Step 3: PITR tail を待つ（7日間）

- Supabase PITR 7日 add-on 契約に依存
- 7日経過で PITR 範囲外（復元不可）
- この間に誤削除 rollback 可能

Step 4: 物理削除（8日目以降の定期バッチ）

DELETE FROM stores WHERE deleted_at < now() - '7 days'::interval;
-- Vault secret も vault.delete_secret(id) で完全削除
-- 削除証明書を audit_logs + email で顧客提示

Blocking branch（Codex 10回目指摘 対応）

以下のいずれかの場合、deletion certificate を発行しない:

• Step 1 の revoke API が非 200 応答
• Step 1 の debug_token 検証で is_valid=true のまま
• stored access_token が既に expired / missing（revoke 対象不在）で顧客が Meta Business settings で手動削除確認をしていない
• token が page token / system-user token で revoke 方法が異なる場合

Blocking 時の対応:

1. deletion certificate の代わりに pending notification を顧客に送付
2. 顧客に Meta Business Manager の Business Settings → Apps から手動で app remove する手順を案内
3. 手動削除確認を受けて初めて deletion certificate を発行
4. audit_logs に blocking 発生と解除を全記録

Token type 別の revoke 方法

8.3 GDPR 「削除要求から 30日以内」との整合

• Step 1 (IG revoke) 即時 → 顧客視点で「機能停止」
• Step 2 (tombstone) 即時 → クエリからは見えない
• Step 3〜4 (物理削除) 8〜30日 → GDPR 30日以内ルール内

8.4 pgsodium deprecation への対応

• Supabase が pgsodium 置き換え product を出したら migration
• vault.* API は abstraction layer 経由で呼び、migration 時の影響局所化
• alpha SLA 対象外のリスクは Q5 に記載して子安氏と合意

8.5 Master Key Rotation

Supabase が Vault master key を管理するため、アプリ側は rotation job を持たない。Supabase 支援が必要な場合は enterprise 契約 or サポートチケット経由（alpha 時点では limited）。

9. 他セクション（v3 から変更なし）

• Evidence failure matrix: v3 §8 から E2 crash injection を pg_cron + Edge Functions + CF Workers モデルに調整
• Operating Model: v3 §9 と同じ 24/7 escalation + 8 runbook
• Delivery Plan: v3 §10 と同じ 12週 MVP

10. 子安氏への依頼事項（Q1-Q7）

10.1 進め方

• 本書（23）+ Codex 10回目レビュー（narrow review）+ 11 過去 Codex レビュー 1式を送付
• 48h 以内に Q1-Q7 回答
• Q1 = Yes かつ重大 blocking なし → prototype phase 即着手

11. 付録：9ラウンドの経緯

11.1 関連ドキュメント

• 13 根本監査
• 14 δ判定
• 17 v1
• 19 v2 (γ採用・却下)
• 21 v3 (β採用)
• 22 Codex 9回目