🟠 Cloudflareで商業提供する — SvelteKit × D1 × R2、無料で始めて有料へ上がる順番

1/6　🟠 Cloudflareで商業提供する — SvelteKit ×

# 🟠 Cloudflareで商業提供する — SvelteKit × D1 × R2、無料で始めて有料へ上がる順番
wranglerでデプロイできる人が、顧客に売る段で踏む壁を12個に数え上げた。Cloudflareの自己サービス規約には「無料プランは商用不可」という条項が無い（Vercelは利用規約4条で禁止している）。ただしWAFはゾーン単位の機能で、pages.dev や workers.dev のままでは守る手段が1つも無い。Workers Logsの保持は無料3日・有料7日、標準LogpushはEnterprise限定。一方でAudit Logsは全プラン18ヶ月ある。無料枠を超えたときの挙動は製品ごとに違い、WorkersもD1も課金されずエラーで止まるのに、R2だけは自動で課金される。すべてCloudflare公式ドキュメントで確認した数値と、Codexの独立設計を並べた。

## 🧱 商業提供で踏む壁 12個と、必要なプラン
このセクションの3点
① 12個の壁のうち、金で解決できないのは1つだけ
② それは独自ドメイン。共有ドメインでは守る手段がゼロ
③ 最低ラインは Workers Paid 5ドル + ゾーン Pro 20ドル

さとまた
Cloudflareでやるとします。Vercelと同じで企業提供・商業利用です。アーキテクチャ等、SvelteKit・D1・R2でやるとします。
私は wrangler を使ったデプロイまでの開発をすでに行っているのです。

この表がこの記事の答えです。wranglerでデプロイできる人が、顧客に売る段で踏む壁を12個に数え上げました。入門は書きません。

数値はすべて 2026年8月17日時点のCloudflare公式ドキュメントで確認したものです。同じ問いを Vercel に当てた記事が2本あり（Vercelの運用をAIに任せる／月20ドルでセキュリティはどこまでできるか）、そこで確定させた事実と同じ基準で比べています。

設計はCodexにも独立に組ませました。私と判断が割れたところは、揃えずに両方載せています。

12
商業提供で踏む壁の数

1
金では解決できない壁（独自ドメイン）

25ドル
商業提供の最低ライン（月・5ドル + 20ドル）

26.50ドル
顧客1万人でのCodexの試算（月）

# | 壁 | 何が起きるか | 要るもの

1 | 無料プランで商用してよいのか | Cloudflareの自己サービス規約には「無料プランは商用不可」という条項が無い。Vercelは利用規約4条で禁じているので、ここは決定的に違う。ただし workers.dev は公式ドキュメントが「business-criticalでない個人・趣味の用途」と明記 | 規約上は無料でも可（第3章）
2 | 共有ドメインのままだと守る手段がゼロ | WAFはゾーン単位の機能。pages.dev / workers.dev にはWAFもレート制限も一切効かない。サーバー側で弾いてもリクエストは到達して課金対象になる | 独自ドメイン。金では買えない（第4章）
3 | 実行ログが数日で消える | Workers Logs の保持は無料3日 / 有料7日。1年保持を契約で求められると足りない | アプリ側で自分で書く（第5章）
4 | ログを外へ出せない | 標準Logpushは Enterprise 限定。ただし Workers Trace Events Logpush は Paid 5ドルでも使える | Paid 5ドル、または Enterprise
5 | 監査ログは足りるのか | Audit Logs は全プランで18ヶ月。Vercelは Enterprise 限定なので、ここはCloudflareの明確な優位。ただし残るのは設定変更で、アプリ内の操作は残らない | 無料で足りる（第6章）
6 | D1が10GBで止まる | 1データベース 10GB上限・引き上げ不可。ただしDB数は Paid で 50,000 | テナントごとにDBを分ける設計（第7章）
7 | D1の書き込みが直列 | DBごとに1件ずつ処理する。1クエリ100msなら実効10QPS程度。書き込みが集中すると、顧客数より先に詰まる | 分割 + Queues へ逃がす（第7章）
8 | R2だけ自動課金される | 他の製品は無料枠を超えると止まるのに、R2だけは課金される。しかも無料枠だけの利用でも決済手段の登録が必須 | バケット作成日に上限アラート（第8章・第11章）
9 | Workersの上限 | CPU 無料10ms / 有料 最大5分、サブリクエスト 50 / 10,000、バンドル 3MB / 10MB | Paid 5ドル（第9章）
10 | ループの停止条件をどこに持つか | Cron は最短1分・無料5本 / 有料250本。Workflows はGA。課金は2026年8月10日以降に開始とされている（開始済みかは本記事では未確認）。Durable Objects は無料プランでも使える | 用途で選ぶ（第10章）
11 | SLAを約束できるか | Cloudflare側の100% SLAは Business 200ドル 以上。それ未満で「止まりません」と契約書に書く根拠は無い | Business 200ドル（第13章）
12 | データ所在地・第三者証跡 | ISO 27001 / SOC 2 の報告書はプラン不問（NDA前提）、DPAは自動適用。しかしデータ所在地の指定は Enterprise 限定の有償アドオン | 紙は無料、地域指定は Enterprise（第13章）

### 何が、どのプランから使えるか
機能 | 無料 | Workers Paid 5ドル | ゾーン Pro 20ドル | Business 200ドル | Enterprise

Workers・D1・R2・KV・DO・Queues の実行 | 使える（超過で停止） | 枠が上がる | — | — | —
Workers Logs の保持 | 3日 | 7日 | — | — | —
Workers Trace Events Logpush | 不可 | 可 | — | — | —
標準Logpush（ゾーン全体） | 不可 | 不可 | 不可 | 不可 | 可
Audit Logs（18ヶ月） | 可 | 可 | 可 | 可 | 可
マネージドルールセット（OWASP含む） | 縮小版のみ | — | 可 | 可 | 可
カスタムWAFルール | 5本 | — | 20本 | 100本 | 1,000本
レート制限ルール | 1本 | — | 2本 | 5本 | 100本
Bot Management | 不可 | — | 不可 | 不可 | 有償アドオン
100% SLA | 無し | — | 無し | 有り | 有り
データ所在地の指定 | 不可 | — | 不可 | 不可 | 有償アドオン

この表から読める、いちばん大事なこと
12個のうち11個は金で解決できます。月25ドル（Workers Paid 5ドル + ゾーン Pro 20ドル）で、商業提供の最低ラインは超えます。

解決できないのは2番だけです。WAFはゾーン単位の機能なので、独自ドメインが無いと、いくら払っても守れません。これは料金の問題ではなく構造の問題で、依頼者は実際にこれでCloudflareの無料枠を2回焼いています（3秒ポーリング × 2チャンネル = 1日57,600リクエスト、無料枠は1日10万リクエスト）。

だから順番はこうなります。ドメインを先に取る。金は後でよい。アプリ側の有料化（5ドル）はコード変更なしでいつでも上げられますが、ドメインだけは、必要になった日には間に合いません。

→ 次のSection 2では、この先に出てくる言葉を先に片付ける。

## 📖 この記事に出てくる言葉
このセクションの3点
① 「ゾーン」が分かれば第4章が読める。WAF・レート制限は全てゾーン単位の機能で、workers.dev / pages.dev はゾーンではない
② D1のSessions API、R2のClass A・B、LogpushのEnterprise限定は、あとの章の数値を読むときに毎回出てくる
③ wranglerでのデプロイ手順そのものは書かない。ここは「壁」の章を読むための最短の用語だけに絞った

この先の章は、公式ドキュメントの語をそのまま使う。デプロイ自体の説明は省き、あとの章の数値を正しく読むために必要な12語だけをここで固定する。

用語 | 意味

ゾーン | 独自ドメインに対してCloudflareが管理する単位。WAF・カスタムルール・レート制限・マネージドルールセットは全てゾーン単位の機能。workers.dev / pages.dev はCloudflareが所有する共有ドメインでありゾーンではないため、これらの機能が一切適用されない（第4章）
バインディング | Workerのコードから D1 / R2 / KV 等のリソースへ接続する設定。wrangler.tomlで定義する。Workers Freeでも1Workerあたり最大100個までバインド可能
Class A・Class Bオペレーション | R2の操作を課金上2種類に分ける区分。Class A（PUT・LIST等の書き込み系）は無料枠が月100万回、Class B（GET・HEAD等の読み取り系）は月1,000万回で、B の方が単価も枠も緩い
Logpush | ログを外部ストレージ（S3・R2・Splunk等）へ継続的に転送する仕組み。ゾーン全体のHTTP/WAFログを流す標準LogpushはEnterprise限定。Workersの実行ログだけを流すWorkers Trace Events LogpushはWorkers Paid（$5）でも使える（第5章）
マネージドルールセット | Cloudflareが用意する既知の攻撃パターン検知ルール。OWASP Core Rulesetを含む。Freeは縮小版のみで、フル機能はPro以上でないと有効化できない（第4章）
Sessions API | D1のRead Replicationを使うとき、直前に自分が書いた行を確実に読み返すための整合性API。これを使わないと、レプリカが有効でも全クエリがプライマリDBへ集中する（第7章）
Static Assets | Workers上でHTML・JS・CSS等の静的ファイルを配信する仕組み。旧来のWorkers Sitesの後継で、SvelteKitのビルド成果物をそのまま載せられる
Time Travel | D1をある時点の状態へ巻き戻せる機能。保持期間はPaidでも30日、Freeは7日。長期保存の代替にはならない（第7章）
egress | Cloudflareのネットワークからデータを外部へ転送すること。他クラウドでは転送量課金の対象になりやすいが、R2は egress を常に無料としている（第8章）
SLA | 稼働率の保証。Cloudflare側の100%稼働率SLAはBusiness（$200/月〜）以上でしか契約に含まれない（第11章）
DPA | データ処理契約。個別の署名を要さず、利用規約（SSSA）に同意した時点で自動的に効力を持つ。データ所在地の指定は別枠でEnterprise限定（第13章）
NDA | 秘密保持契約。SOC2報告書などコンプライアンス文書の詳細版を入手するときの前提条件で、プランには連動しない（第13章）

🗺️

#### ゾーン
WAFもレート制限もこの単位でしか効かない。第4章の核

📤

#### Logpush
標準はEnterprise限定、Workersだけなら$5で外へ出せる（第5章）

🔁

#### Sessions API
使わないと全クエリがD1のプライマリへ集中する（第7章）

→ 次の第3章では、「無料プランで商用してよいのか」を、Vercelとの規約の差から確定する。

## 📜 規約 — 無料で商用してよいのか
このセクションの3点
① Cloudflareの自己サービス規約には「無料プランは商用不可」という条項が無い。Vercelは利用規約4条でHobbyの商用利用を明文で禁止している
② ただし workers.dev サブドメインは、公式ドキュメントが「business-criticalでないhobby・personal向け」と明記している。規約ではなく製品ドキュメント側の制約
③ 旧2.8条項（HTML以外の配信制限）は2023年に改定済み。今は動画・大容量配信をCDN経由で行う場合、Free/Pro/BusinessいずれでもStream・Images・R2等の有償サービス経由が条件になる

「最初は無料で、あとから有料で」という依頼者の前提が、規約上そもそも成立するのかをまず確定する。答えはVercelとは違う。

無料プランでの商用利用 — Vercel ⇄ Cloudflare
Vercel — 明文で禁止
利用規約4条

- ・Hobbyプランは商用利用を明文で禁止

- ・違反時はアカウント停止の対象になり得る

- ・商用に切り替えるにはProプラン以上の契約が前提

Cloudflare — 禁止条項なし
自己サービス規約（SSSA）

- ・「無料プランでの商用利用を禁止する」条項は本体に無い

- ・第2.2.1条(h)はクレジットカード情報の処理のみを無料サービス上で禁止

- ・第2.6条は無料サービスの終了条件と免責を定めるのみで商用利用自体は禁じない

✅ 事実（出典つき） Cloudflareの自己サービス規約（Cloudflare公式（terms）、Self-Serve Subscription Agreement）第2.6条「Free & Trial Services」は、無料サービスをいつでも終了・制限できる裁量と免責（no liability）を定めているが、商用利用そのものを禁じる文言は無い。原文: “We will have no liability for any harm or damage arising out of or in connection with any Free Services.” 商用禁止の条項が無いことと、無料サービスに責任保証が無いことは別の話であり、両方とも同じ条文から読み取れる。

### workers.dev は「規約」ではなく「ドキュメント」で釘を刺している
規約本体に商用禁止条項が無いからといって、既定ドメインのまま本番に出してよいわけではない。Cloudflare公式ドキュメント の技術ドキュメント側に、規約とは別の制約が明記されている。

✅ 事実（出典つき） Cloudflare公式ドキュメント の Workers ルーティング設定ページ（workers-dev）に次の記載がある。原文: “Your workers.dev subdomain is treated as a Free website and is intended for personal or hobby projects that aren’t business-critical.” 同様の文言は pages.dev のドキュメント側では見当たらなかった（確認範囲内）。つまりこれは Self-Serve Subscription Agreement という契約書ではなく、製品ドキュメントが定める運用上の推奨という位置づけである。

この差は小さくない。契約違反ではないので、workers.dev のまま商用システムを動かしても直ちにアカウント停止にはならない。しかし公式が「business-criticalでない」と名指しした場所へ、顧客に売るシステムを置く判断は、規約云々の前に設計判断として避けるべきものである。

### 旧2.8条項 — 動画・大容量配信の制限は今も生きている
もう1点、依頼者が動画等を配信する構成を検討する場合に関わる条項がある。旧SSSAにあった「Section 2.8」（HTMLと非HTMLコンテンツを区別する配信制限）は2023年5月の規約改定で撤廃され、現在はサービス個別規約の「Content Delivery Network」節に移設・条件変更されている。

✅ 事実（出典つき） Service-Specific Terms（Cloudflare公式（service specific terms application services））の「Content Delivery Network」節、原文: “Unless you are an Enterprise customer, Cloudflare offers specific Paid Services (e.g., the Developer Platform, Images, and Stream) that you must use in order to serve video and other large files via the CDN.” Enterprise以外は、動画・大容量ファイルをCDN経由で配信する場合、R2・Images・Stream等の有償サービスを経由することが条件になる。Free/Pro/Businessいずれのプランでも、この条件を満たせばCDN自体は使ってよい。

📎 Claudeの判定
「無料プランで商用しても規約違反ではない」。Vercelのように商用利用そのものを禁じる条項はCloudflareのSSSAには無い。ただし共有ドメイン（workers.dev / pages.dev）のままなら別の理由で本番に使えない。理由は規約ではなくセキュリティ機能の構造にある（第4章で確定する）。動画・大容量ファイル配信をするなら、プランに関わらずR2・Images・Stream経由にする条件が別途ついてくる。

🤖 Codexの指摘
workers.devの用途説明を利用規約上の商用禁止へ格上げしやすい、という点に注意が要る。SSSAにはFreeの商用禁止がない。workers.devは公式ドキュメント上personal・hobby、非business-critical向けという位置づけであり、Vercel Hobbyの規約違反と法的に同じとは書けない。またpages.devにもworkers.devと同一のhobby文言があると断定しやすいが、資料の確認範囲ではPages側に同様の文言は見当たっていない。共通して言える強い問題は、共有ドメインではゾーンのWAFを適用できないこと自体である。

→ 次の第4章では、そのWAFがなぜ workers.dev / pages.dev に一切効かないのかを、依頼者が実際に無料枠を焼いた実例とともに確定する。

2/6　🚫 pages.dev のままでは、守る手段が1つも無い

## 🚫 pages.dev のままでは、守る手段が1つも無い
このセクションの3点
① WAF・カスタムルール・レート制限・マネージドルールセットは全てゾーン単位の機能。pages.dev / workers.dev はCloudflare所有の共有ドメインでゾーンではないため、これらが一切適用されない
② 依頼者はこの構造で実際に無料枠を2回焼いている。ラズパイのbotが3秒間隔で2チャンネルをポーリングし、1日57,600リクエスト。Workers/Pagesの無料枠は10万リクエスト/日（全Pagesプロジェクト合算）
③ サーバー側では止められない。401でも404でも429でも、リクエストは一度Functionに到達した時点でカウントされる。止められるのはクライアント側だけ

第3章で「規約違反ではない」と確定した。しかしそれとは別の理由で、pages.dev / workers.dev のまま顧客向けシステムを本番運用してはいけない。理由はゾーンという単位そのものにある。

✅ 事実（出典つき） Cloudflare公式ドキュメント の WAF カスタムルールのドキュメント（waf/custom-rules）は「At the zone level, all customers can create and deploy custom rulesets」と、ゾーン単位が前提であることを明記している。WAFのマネージドルールセット・カスタムルール・レート制限ルールは、いずれもこの「ゾーン」という単位に紐づく機能であり、顧客が保有する独自ドメイン（ゾーン）に対してのみ設定できる。

workers.dev と pages.dev は、依頼者が保有するゾーンではなくCloudflareが所有する共有ドメインである。第3章で確認した「business-criticalでないhobby用途」という位置づけは、この構造と一致している。共有ドメインである以上、そこにWAFルールを書いても適用対象が無いため、そもそも設定画面にすら出てこない。

実例 — 3秒ポーリング×2チャンネルで無料枠を2回焼いた
・ラズパイ上のbotが pages.dev のAPIエンドポイントを3秒間隔でポーリング
・対象は2チャンネル分。1チャンネルあたり1日28,800リクエスト、2チャンネル合計で57,600リクエスト/日
・Workers/Pagesの無料枠は10万リクエスト/日（全Pagesプロジェクト合算・日本時間09時リセット）。このポーリングだけで枠の半分以上を消費
・通常アクセスが少しでも重なれば枠超過。超過するとWorkers自体がエラーで停止する（第9章）
・pages.devのままではWAF・レート制限が一切効かないため、サーバー側でこのリクエストを止める手段が無かった
・401・404・429のいずれを返してもリクエストは一度Functionに到達しており、その時点でカウントされる。応答コードを変えても消費は減らない
・結果、止められるのはbot側（クライアント側）のポーリング間隔と実装だけだった

この実例が示すのは「運が悪かった」ではなく、構造上そうなるようにできているということである。独自ドメインに載せていれば、レート制限ルールを1本設定するだけで同じ事故は起きなかった。

リクエストがカウントされるまで — pages.dev と独自ドメインの分岐
bot
3秒間隔でポーリング
2チャンネル分、1日57,600リクエスト

▶
pages.dev（共有ドメイン）
ゾーンではないためWAF・レート制限が素通り

▶
Functionに到達
401 / 404 / 429 を返しても到達した時点でカウント確定

▶
無料枠 10万リクエスト/日
正常アクセスを巻き込んでWorkers自体が停止

防御手段 | Free | Pro（$20/月） | Business（$200/月） | Enterprise

マネージドルールセット（OWASP含む） | 縮小版のみ | フル利用可 | フル利用可 | フル利用可
カスタムWAFルール（本数上限） | 5 | 20 | 100 | 1,000
レート制限ルール（本数上限） | 1 | 2 | 5 | 100
Bot Management | Bot Fight Mode（単純bot検知のみ） | Super Bot Fight Mode | Super Bot Fight Mode | Bot Management（有償アドオン・スコアベース）

ただしこの表は独自ドメイン（ゾーン）に載せて初めて意味を持つ。Freeのカスタムルール5本・レート制限1本であっても、workers.dev / pages.devの共有ドメインに置いたままでは0本と同じである。順番が違う。まずゾーンに載せる。プランを上げるかどうかはそのあとの話になる。

📎 Claudeの判定
独自ドメインを取るまで、守る手段はゼロ。これは料金の問題ではなく構造の問題である。Freeプランのまま独自ドメインへ載せるだけで、カスタムルール5本・レート制限1本が使えるようになる。逆にProやBusinessへ上げても、pages.dev / workers.devのまま公開している限りその効果は一切適用されない。プランを検討する前に、まず独自ドメインへ移す作業を最優先にする。

🤖 Codexの指摘
独自ドメインは最初の顧客公開より前に取るべきで、あとからでよいものではない。開発用URLとしてpages.dev / workers.devを使うのはよいが、本番URLとして顧客へ配ってはいけない。独自ドメインを後付けする技術作業自体は重くなく、コード変更・再ビルド・再デプロイ不要でDNS設定が中心だが、顧客へ旧URLが配られた後ではURL・Cookie・OAuthのコールバック・CORS・メール内リンクなどの運用面が残る。何より後付けまでの期間はWAFを迂回できる入口を公開することになるため、「簡単に後付けできる」ことは「後付けでよい」理由にならない。ポーリングも間隔を長くするだけでなく、SSE・Webhook・ロングポーリング等のプッシュ型へ変え、最低30〜60秒を既定にすべきである。

→ 次の第5章では、pages.dev を離れて独自ドメインで運用しても残る問題——実行ログが3〜7日で消えることを確定する。

## 🧾 ログが証跡にならない問題
このセクションの3点
① Workers Logsの保持は無料3日・有料7日が上限で、契約で保持期間を約束する材料にはならない
② ゾーン全体のログを外部へ出す標準LogpushはEnterprise限定。Workersの実行ログだけならPaid 5ドルでも外部転送できる
③ 保持期間を自分で決めたいなら、アプリ側の監査ログをD1とR2へ自分で書くしかない

Workers Logsは何もしなくても自動で記録される。だがこれは障害直後の調査用のログであって、契約書に書ける保存期間の証跡ではない。無料は3日、有料でも7日で上限に張り付く。ここを勘違いしたまま「ログはあります」と顧客に説明すると、あとで期間の話になったときに詰む。

項目 | 無料 | 有料・上位プラン | 扱う範囲

Workers Logs 保持 | 3日 | Paid 7日（上限） | アプリの実行ログのみ
標準Logpush | 不可 | Enterprise限定 | ゾーン全体のHTTPログ・WAFイベント等
Workers Trace Events Logpush | 不可 | Workers Paid 5ドルで可 | Workersの実行ログのみ

ログを外へ出す2つの経路は別物
標準Logpush
ゾーン全体

- ・ゾーン全体のHTTPリクエスト・WAFイベントを継続転送できる

- ・Enterprise限定

- ・商業本番でゾーンログの恒久保存が必要ならここが必須になる

Workers Trace Events Logpush
アプリ実行ログだけ

- ・Workersの実行ログだけを外部へ継続転送できる

- ・Workers Paid（月5ドル）で利用できる

- ・ゾーン全体のログは含まれない。範囲がそもそも違う

✅ 事実（出典つき） Cloudflare公式ドキュメント の Workers Observability ドキュメントに、Maximum log retention periodは7日、Workers Freeは3日・Workers Paidは7日と明記されている。同じくCloudflare公式ドキュメントのLogpushドキュメントの可用性表では、標準LogpushはFree・Pro・Businessが不可でEnterpriseのみ可、ただし「Enterpriseでなくとも、Workers Paidプランを契約すればWorkers Trace Events Logpushは使える」という注記がある。

📎 Claudeの判定
プラットフォームのログは短期の調査用と割り切る。Workers Logsの3〜7日は「デプロイ直後に何が起きたか」を見るには足りるが、契約で1年・3年といった保存期間を約束する根拠にはならない。契約で保持期間を約束するなら、自分で書いて自分で保存する。直近分をD1に書き、古いものはR2へ流す設計にすれば、保存期間はCloudflareのプランではなく自分のポリシーで決まる。R2は取り出し（egress）が常に無料なので、長期アーカイブを外へ出すコストも掛からない。

🤖 Codexの指摘
Workers LogsのFree 3日・Paid 7日は、障害直後の調査には使えても、ISO27001の証跡保管基盤としては短すぎる。Vercelの1時間よりは明確に改善しているが、「1時間より長い」ことと「組織が定めた保持期間を満たす」ことは別問題である。ISO27001の管理策A.8.16は、特定の日数を要求しているのではなく、組織が自分で定めた監視記録の保持期間を実際に維持できるかを問うものなので、7日だけで足りると断定してはいけない。Workers Paid 5ドルでもWorkers Trace Events Logpushが使える点は強みだが、これは標準Logpushと同じではない。ゾーン全体のHTTPリクエストやWAFイベントを含む標準LogpushはEnterprise限定であり、「5ドルで全部取れる」と誤解してはいけない。アプリ側の監査ログをD1・R2へ自分で書く案には賛成するが、それだけでは半分しか解決しない。障害時に監査ログの書き込みも一緒に失敗する、D1の監査ログが業務データの書き込みと同じ直列キューを奪う、削除権限を持つ主体が証跡も消せる——こうした設計不備を潰して初めて証跡になる。

✅ 事実（出典つき） ISO27001附属書Aの管理策A.8.16は「組織が定めた保持期間にわたって監視記録を維持する」ことを求める。同じ依頼者向けに調べたVercelの記事では、Runtime Logsの保持が1時間しかなくこの管理策と衝突する点を指摘した。Cloudflareの3〜7日はそれより明確に長いが、「プラットフォーム標準の保持期間だけでは組織が定めた期間を満たせない」という構造上の課題は同じである。

自分で書く監査ログの置き場所
直近
D1に書く
検索しやすい。直近の調査・顧客対応にはここを見る

▶
長期
R2へ流す
取り出しが常に無料。ライフサイクル設定で保持期間を自分で決める

▶
注意
D1の10GBに近づけない
監査ログを業務データと同じDBに積み続けると上限に近づく

証跡として機能させるために埋まっているか
✓ Workers Logs（実行ログ、無料3日・有料7日）
全プランで自動。ただし保持は短い

△ Workers Trace Events Logpush（実行ログの外部転送）
Workers Paid 5ドルで可。標準Logpushではない

− 標準Logpush（ゾーン全体のHTTP・WAFログ）
Enterprise限定

− アプリ監査ログ（D1・R2へ自分で書く）
書き込み失敗の検知・権限分離・復元試験まで含めて設計する

→ 次のSection 6では、設定変更を追える「Audit Logs」が、業務の監査ログとどう違うのかを見る。

## 🔍 監査ログは誰が、いつまで見られるか
このセクションの3点
① Cloudflare Audit Logsは全プランで利用でき、保持は18ヶ月。Vercelの監査ログはEnterprise限定
② ここに残るのは「誰がCloudflareの設定を変えたか」であって、顧客の注文や閲覧を記録する業務監査ログではない
③ 設定変更の証跡は無料で18ヶ月取れる。アプリ内の操作の証跡は自分で作る

前章の実行ログは短命だったが、Audit Logsは事情が違う。プラン不問で18ヶ月残る。これはVercelとの比較でCloudflareが明確に有利な数少ない項目の1つである。ただし「監査ログがある」という言葉だけを見て安心してはいけない。ここに残るのはアカウント設定の変更履歴であって、顧客が何をしたかの記録ではない。

監査ログのプランと保持期間
Cloudflare Audit Logs
全プラン共通

- ・Free・Pro・Business・Enterpriseの全プランで利用できる

- ・保持期間は18ヶ月。削除前にこの期間は保証される

- ・Enterprise顧客はLogpushでさらに長期保存できる

Vercel Audit Logs
前記事で確認済み

- ・Enterprise限定

- ・Free・Pro相当のプランでは監査ログそのものが無い

- ・設定変更の証跡を無料で残せない

✅ 事実（出典つき） Cloudflare公式ドキュメントのアカウントセキュリティのドキュメントに、Audit Logs are available on all plan types、Audit Logs are retained for 18 months before being deletedと明記されている。Enterprise顧客はLogpushを使ってさらに長期間の保存が可能とも書かれているが、具体的な日数はドキュメント上に記載がない。

### 何が残り、何が残らないか
記録されるか | 内容 | 例

残る | アカウント・ゾーンの設定変更 | DNSレコードの変更、WAFルールの追加、権限の付与
残る | APIトークンやメンバーの操作 | トークン発行、メンバー招待・削除
残らない | 顧客データへのアプリ内操作 | 注文の変更、管理者によるデータ閲覧、認可拒否
残らない | アプリのAPIが失敗した記録 | ビジネスロジック側のエラー、決済失敗の理由

📎 Claudeの判定
「設定変更の証跡は無料で18ヶ月取れる。アプリ内の操作の証跡は自分で作る。」この2つを混ぜて説明しない。顧客監査で聞かれるのは大抵後者、つまり「誰が私のデータを見たか」「注文はいつ誰が変更したか」であり、これはCloudflareのAudit Logsには一切現れない。前章のD1・R2への自前ログ設計は、実行ログの保存期間だけでなく、この業務監査ログの空白を埋めるためでもある。Audit Logsは「Cloudflareの管理画面を誰が触ったか」の証跡として、無料でそのまま使えばよい。

🤖 Codexの指摘
Audit Logsが全プランで18ヶ月保持される点は、VercelのAudit LogsがEnterprise限定であることに対する大きな優位である。小規模事業者でも、誰がCloudflareの設定を変更したかを18ヶ月追える。ただしAudit LogsはCloudflareアカウント・設定操作の証跡であって、顧客が注文を変更した、管理者が顧客データを閲覧した、APIが失敗した、といった業務監査ログではない。18ヶ月という数字だけを見て「監査ログ問題は解決」と書くのは誤りである。

監査で聞かれたときに出せるか
✓ Cloudflareの設定を誰がいつ変えたか（Audit Logs）
全プラン無料・18ヶ月

✓ APIトークンの発行・削除履歴
Audit Logsに含まれる

− 顧客の注文・データ閲覧の履歴
アプリ側で自分の監査ログを書く必要がある

− 業務ログの保持期間ポリシー
D1・R2の設計とセットで決める

→ 次のSection 7では、その自前ログの置き場所にもなるD1が、10GBと直列書き込みでどこから詰まるかを見る。

3/6　🗄️ D1で詰まる上限（10GBと、直列書き込み）

## 🗄️ D1で詰まる上限（10GBと、直列書き込み）
このセクションの3点
① 1DBの上限は10GB（Paid）で、増量リクエストを出しても引き上げられない。増えるのはDB数（Paidで50,000）とアカウント全体のストレージ（1TB）
② 書き込みはDBごとに直列処理される。平均クエリが100msなら実効10QPS程度が目安になるが、これは製品固定の上限ではなくクエリ時間に反比例する設計上の警告
③ Time Travelは最長30日（Paid）で常時ON・追加費用なしだが、長期保存の代替にはならない。古い履歴はR2へアーカイブする設計が要る

項目 | 数値 | 備考

1DBの最大サイズ（Free） | 500MB | 引き上げ不可
1DBの最大サイズ（Paid） | 10GB | 引き上げ不可
アカウントのDB数（Free / Paid） | 10 / 50,000 | Paid＋Enterpriseは申請でさらに増枠可
アカウント全体ストレージ（Free / Paid） | 5GB / 1TB | アカウント全体の上限は申請で増枠可
クエリ実行時間の上限 | 30秒 |
SQL文の最大長 | 100,000バイト | 大きな一括処理は分割が要る
バインド変数の上限 | 100個 / クエリ | 一括INSERTは行数を分けて発行する必要がある
Time Travel復元期間（Free / Paid） | 7日 / 30日 | 常時ON・追加コストなし。復元は破壊的操作

📎 Claudeの判定
D1の壁は「大きくできない」ことそのものが本質である。10GBという数字自体は小さくないが、Paidで課金しても増えないという一点が、他のCloudflare製品（Workersのサブリクエストやバンドルサイズのように設定変更で緩められるもの）と決定的に違う。
だから設計の起点を「1DBをどう大きくするか」に置いてはいけない。最初から顧客単位・テナント単位でDBを横に並べることを前提に、アプリのルーティング層（どの顧客のリクエストをどのDBバインディングへ渡すか）を用意しておく必要がある。あとから水平分割に切り替える設計変更は、共有DBに書き込みが集中してからでは遅い。
Read Replicationが全プラン無料という点は見落とされやすい優位だが、Sessions APIを実装しなければ効果が出ない「使わないと存在しないのと同じ機能」であることは、この章のもう一つの判定として明記しておく。

🤖 Codexの指摘
D1 Paidは1DB 10GBで、この上限は増量できない。一方、DB数はPaidで50,000、アカウント全体は1TBなので、D1は「1個を大きくする」のではなく「小さいDBを横に並べる」製品として扱うべきである。
全顧客を1DBへ入れる設計には反対する。D1はDBごとに単一スレッドでクエリを1件ずつ処理する。平均100msなら約10QPSという数字は、必ず10QPSしか出ないというベンチマーク結果ではないが、クエリ時間に反比例して直列化の影響が出るという設計上の警告として十分である。注文確定、在庫引当、監査ログ追記などが同じ共有DBへ集中すれば、顧客数より先に書き込み待ちが壁になる。
それでも、1顧客だけで10GBを超える、全顧客をまたぐ強いトランザクションが必要、または単一DBへの書き込みが集中するならD1に固執しない。既存Postgres・MySQLをHyperdrive経由で使う、または顧客単位の強整合な状態機械ならDurable Objectsを候補にする。DOも万能な共有SQL DBではなく、Duration課金を伴う別設計である点は忘れてはいけない。

✅ 事実（出典つき） 1DBの最大サイズ・DB数・アカウント全体ストレージ・クエリ実行時間・バインド変数上限は Cloudflare公式ドキュメント（platform / limits） に記載（確認日2026-08-17）。Read Replicationは全プラン無料で追加料金なし、書き込みは常にプライマリへ転送され、Sessions APIを使わない場合は全クエリがプライマリのみに行く仕様は Cloudflare公式ドキュメント（best practices / read replication） に記載。Time Travelの復元期間・常時ON・破壊的操作である点は Cloudflare公式ドキュメント（reference / time travel） に記載。課金は返却件数ではなく処理した行数（rows_read / rows_written）で決まる点は Cloudflare公式ドキュメント（platform / pricing） に明記されており、egress（データ転送）課金は無い。

Codexが示した対策の順番
まず切る
テナントごとにDBを分ける
顧客IDによる論理分割だけで済ませず、原則としてテナント単位・一定の単位ごとにD1データベース自体を分ける。

▶
検索・一覧
インデックスを設計する
課金は処理した行数で決まるため、インデックス無しのフルスキャンは速度と料金を同時に悪化させる。

▶
整合性が要る経路
Sessions APIを使う
Read Replicationは全プラン無料だが、Sessions APIを使わないと恩恵を受けられず全クエリがプライマリへ行く。

▶
応答を待たない処理
Queues・Workflowsへ逃がす
メール送信・集計・変換・バックアップなど、HTTP応答内で完了しなくてよい処理は別基盤へ回す。

▶
古いデータ
R2へアーカイブする
Time Travelは最長30日（Paid）。古い履歴・監査ログはR2へ移し、working setを10GB未満に保つ。

D1でよい条件 ⇄ D1に固執しない条件
D1でよい条件

- ・読み取り比率が高いワークロードである

- ・1顧客のworking dataを10GB未満に抑えられる

- ・書き込みを顧客ごとのDBへ分散できる（テナント分割ができる）

D1に固執しない条件と代替

- ・1顧客だけで10GBを超える → Hyperdrive経由で既存のPostgres・MySQLを使う

- ・全顧客をまたぐ強いトランザクションが要る → 同じくHyperdrive経由の外部DB

- ・単一DBへの書き込みが集中し分割できない → 顧客単位の強整合ならDurable Objectsを検討する

→ 次のSection 8では、R2で詰まる上限と、egressが常に無料であることの意味を確定する。

## 🪣 R2で詰まる上限（egress無料の意味）
このセクションの3点
① egress（下り転送）は常に無料。ログ・成果物・画像・動画を顧客へ配る用途でここが最も効く
② 無料枠はストレージ10GB-月・Class A操作100万回/月・Class B操作1,000万回/月で、超えると停止ではなく自動課金される
③ r2.devはレート制限があり本番非サポートと公式に明記されている。顧客提供では独自ドメインが必須

項目 | 数値 | 備考

egress（下り転送） | 常に無料 | Standard / Infrequent Access どちらも対象
無料枠ストレージ | 10GB-月 | Standard storageのみ。Infrequent Accessには適用されない
無料枠Class A操作 | 100万回/月 | PutObject・ListObjects・Complete Multipart Upload等
無料枠Class B操作 | 1,000万回/月 | GetObject・HeadObject等の読み取り系
1オブジェクトの最大サイズ | 5TiB | 正確には5TiB − 5GiB
単発PUTの上限 | 5GiB | 超える場合はマルチパートアップロード
マルチパートの各パート | 5MiB〜5GiB | 最大10,000パート。最終パート以外は最低5MiB必須
ライフサイクルルール | 1,000 / バケット | ストレージクラス遷移と自動削除の両方に対応

🚫 r2.devを本番の公開先にしない
・r2.devはレート制限があり、超えると429で応答が止まる（数百リクエスト/秒単位で変動）
・r2.devへのCNAME設定は公式ドキュメントで「サポート外のアクセス経路」と明記されている
・WAF・キャッシュ・Bot Management・アクセス制御はカスタムドメイン経由でしか使えない
・顧客へ渡す公開URLは独自ドメイン（カスタムドメイン、1バケットあたり最大100個まで設定可）にする

📎 Claudeの判定
R2は「置き場」としては強い。egress無料は動画・PDF・バックアップのような大容量配布と相性がよく、Vercelのようにストレージから外へ出す転送量そのものに課金される構成に比べて、顧客提供のファイル配信では明確な優位になる。
ただしR2は課金の挙動が他のCloudflare製品と逆である。Workers・D1・KV・DO・Queues・Workflowsは無料枠を超えるとエラーで止まるのに対し、R2だけは自動的に課金される。この記事の前半で確定した「無料か止まる」という安心設計の前提が、R2に限っては最初から成立していない。
だからR2バケットを作る段階を、この記事全体の中で最初に決済手段の登録と予算監視を要求する発火点として扱う。無料枠だけを使うつもりでも、決済手段の登録自体は避けられない。上限アラートを機能実装より先に作るべきだ。

🤖 Codexの指摘
R2の自動課金も無条件に安全ではない。誤実装や攻撃が可用性停止ではなく請求へ変換されるからである。商業本番での正解は「停止か請求かを選ぶ」ことではなく、Paid化して正常需要では止まらない容量を確保し、独自ドメインのWAF・レート制限、アプリ側の認可とクォータ、利用量と請求の監視で異常需要を抑えることである。
R2もWorkers Paidに含まれて安全に止まる、と誤りやすい点にも注意したい。R2は独立して決済手段が必要で、無料枠超過は自動課金である。Workers Paid化でR2バケットの課金挙動が変わるわけではない。Free超過時の挙動を全製品へ一括適用しやすいが、Workers・D1・KV・DO・Queues・Workflowsは失敗する一方、R2だけは自動課金する。この非対称性こそ運用設計の中心である。
さらに、支払いを30日以内に更新しなければ従量課金サービスのデータが削除されうる。カード期限や請求メールを経理任せにせず、運用手順へ組み込むべきだ。

✅ 事実（出典つき） 料金・無料枠・egress常時無料の記載は Cloudflare公式ドキュメント（r2 / pricing） 。1オブジェクトの最大サイズ・単発PUTとマルチパートの上限・同一オブジェクトキーへの同時書き込み1回/秒は Cloudflare公式ドキュメント（platform / limits） 。r2.devのレート制限と「サポート外のアクセス経路」という表記、カスタムドメイン経由でのみWAF・キャッシュ・Bot Managementが使える点は Cloudflare公式ドキュメント（buckets / public buckets） 。ライフサイクルルールの上限とマルチパートアップロードが既定7日で自動失効する仕様は Cloudflare公式ドキュメント（buckets / object lifecycles） 。認可エラー（401）となったリクエストは課金されない旨も料金ページに明記。いずれも確認日は2026-08-17。

R2バケットを作る前に確認すること
− 決済手段を登録したか
無料枠だけの利用でも登録は必須

− 請求の予算アラートを設定したか
自動課金は上限で止まらない

− ライフサイクルルールで無制限な増加を止めているか
一時ファイルの自動削除・古いデータのInfrequent Access移行

− カスタムドメインを用意したか
r2.devのまま顧客へ配布していないか

→ 次のSection 9では、Workersの実行時間・サブリクエスト・バンドルサイズの上限を見る。

## ⚙️ Workersの上限（CPU・サブリクエスト・バンドル）
このセクションの3点
① CPU時間はFree 10ms・Paid 最大5分（cpu_msで設定）。数えるのは壁時計時間ではなく実際にCPUが動いた時間だけ
② サブリクエストはFree 50・Paid 10,000（設定変更で最大1,000万）。バンドルサイズはFree 3MB・Paid 10MB（gzip後）
③ 依頼者は過去に17.5MBのWorkerバンドルで全アセットが500になる事故を起こし、adapter-staticへ移行して解決した

項目 | Free | Paid

CPU時間（HTTPリクエストごと） | 10ms | デフォルト30秒・最大5分（cpu_msで設定）
サブリクエスト数 | 50 / リクエスト | 10,000 / リクエスト（設定変更で最大1,000万）
バンドルサイズ（gzip後） | 3MB | 10MB
Cron Trigger数 | 5本 | 250本
Cron Triggerの最短間隔 | 1分 | 1分

🚫 実際に起きた事故: 17.5MBのWorkerバンドル
・Worker bundleが17.5MBまで膨らみ、Cloudflare Pagesの全アセットが500エラーになった
・原因はサーバー側でしか使わない大きなライブラリが単一の実行ファイルにまとめてバンドルされたこと
・最終的に静的アセット配信の構成へ移行し、バインディングを使わない構成に切り替えて解決した
・D1・R2のバインディングを使うSSR構成では同じ移行はできないため、この記事の構成では別の対策が要る

📎 Claudeの判定
Workersの上限で最初に押さえるべきは、CPU時間が壁時計時間ではないという点である。D1やR2への問い合わせで待っている時間は数えられず、実際にCPUが動いている時間だけがカウントされる。平均的なWorkerは1リクエストあたり約2.2ms消費という水準なら、デフォルトの30秒はほとんどのAPIエンドポイントで問題にならない。詰まるのは集計バッチのような重い処理を1リクエストに詰め込んだときだけで、その場合は cpu_ms を引き上げるより先に、処理をQueuesかWorkflowsへ分割するほうが筋がよい。
一方でバンドルサイズ（3MB・10MB）は、この記事の依頼者にとって数字上の上限以上の意味を持つ。過去に17.5MBのWorkerバンドルで全アセットが500になる事故を実際に起こしており、原因はサーバー側専用の重いライブラリが単一の実行ファイルへ巻き込まれたことだった。今回のD1・R2を使う構成では、あのときの解決策（静的アセット配信への移行）はそのまま使えない。依存関係を追加するたびに wrangler deploy の圧縮後サイズを確認する運用が要る。

🤖 Codexの指摘
PagesからWorkersへの推奨を一次情報以上に強く断定しやすい点には注意が必要である。公式が明示的に非推奨としているのは旧アダプター（Workers Sites向け）であって、Workers Static Assetsそのものではない。この名称の混同は避けるべきだ。PagesよりWorkers Static Assetsが常に優れるという直接の公式宣言は資料では取得できておらず、Workersを選ぶのはこの記事の設計判断であって公式の明文ではない。
私なら実行基盤は SvelteKit ＋ 公式のCloudflareアダプター ＋ Workers Static Assets という構成にする。このアダプターはSvelteKitの全機能を扱え、Workers Static AssetsとPagesの双方に出力できるため、Pagesを選んでも直ちに誤りではない。ただしCloudflareがWorkers SitesからWorkers Static Assetsへの移行を推奨している現在、実行と静的配信をWorkers側へ統一するほうが新規構成として自然だと考えている。

✅ 事実（出典つき） CPU時間・サブリクエスト数・バンドルサイズ・Worker起動時間の上限は Cloudflare公式ドキュメント（platform / limits） に記載（確認日2026-08-17）。CPU時間がネットワーク待ちを含まず実際にCPUが動いた時間のみ計測される点、平均的なWorkerが1リクエストあたり約2.2ms消費する水準も同ページに記載。Cron Triggerの最短間隔・本数上限は Cloudflare公式ドキュメント（configuration / cron triggers） 。SvelteKit公式のCloudflareアダプターが platform.env からD1・R2等のバインディングへアクセスする仕組み、および非推奨なのは旧アダプター（Workers Sites向け）でありWorkers Static Assetsではないという区別は svelte.dev のアダプタのドキュメントドキュメントに記載。

wrangler devでD1・R2に当てるまでの3段階
開発中
wrangler devでローカルエミュレート
D1・R2などのバインディングは、既定ではローカルのランタイムでエミュレートされる。

▶
本番相当の確認
--remoteで実際のD1・R2に当てる
Cloudflareのネットワーク上にある本物のD1・R2に対して開発・確認ができる。

▶
デプロイ前の最終確認
ビルド後の実行ファイルで動作確認する
ビルドしたあとの挙動を、本番へ出す前にローカルまたはリモートで確認する。

アダプター選びで混同しないための2点
✓ 非推奨なのは旧アダプター（Workers Sites向け）であって、Workers Static Assetsではない

− バンドルサイズは依存関係を追加するたびに圧縮後の数値で確認する
過去の17.5MB事故と同じ経路を通らないため

→ 次のSection 10では、Cron・Queues・Workflows・Durable Objectsのどれでループの停止条件を持てるかを見る。

4/6　🔁 ループを回す部品

## 🔁 ループを回す部品
このセクションの3点
① 定期起動はCron Triggers（最短1分間隔・無料5本・有料250本）だが、リトライも再開もない。落ちたら次のtickまで放置される
② 配送保証が要るならQueues（無料1万オペレーション/日・最大128KB・リトライ上限100回）。ただし配達は最低1回のみ保証で、同じメッセージが2回届くこともある
③ CPU・壁時計の制限をまたいで続きから再開したいならWorkflows（GA・課金は2026年8月10日以降に開始とされる）。顧客ごとの状態を持ち続けたいならDurable Objects（無料プランでもSQLiteバックエンドなら使える）

この記事とは別に、ループそのものの設計を扱った記事で確認した原則がある。ループには停止条件が要る。停止条件の無いものはループではなく暴走である。3秒間隔のポーリングを2チャンネルで動かすbotが、1日57,600リクエストという無料枠を軽く超える量を勝手に生み続けた実例は、この記事の第4章で扱った。
ここでは「停止条件をどこに持たせるか」を、Cloudflareが用意している4つの部品——Cron Triggers・Queues・Workflows・Durable Objects——に当てはめて選ぶ。停止条件とは、①一定時間で必ず打ち切られるか（タイムアウト）、②失敗したときに自動でやり直すか（リトライ）、③同じ処理を二重に実行しても壊れないか（冪等性）、④CPU上限や再デプロイをまたいで続きから動けるか（途中再開）の4点である。

部品 | 向いている用途 | 起動・上限 | 課金の起点

Cron Triggers | 一定間隔でWorkerを起動するだけ | 最短1分間隔・アカウントあたり無料5本／有料250本 | Worker実行と同じ課金
Queues | メッセージ単位で配送保証したい非同期処理 | 無料1万オペレーション/日・メッセージ最大128KB・リトライ上限100回 | 64KBごとに1オペレーション課金
Workflows | CPU・壁時計の制限をまたいで続きから再開したい処理 | GA・ステップ単位で状態を永続化 | 課金は2026年8月10日以降に開始とされる（CPU時間・リクエスト・ストレージ・ステップ数の4軸）
Durable Objects | 顧客ごと・エンティティごとに状態を持ち続ける常駐処理 | 無料プランはSQLiteバックエンドのみ利用可 | リクエストと稼働時間（Duration）の2軸課金

### Cron Triggers — 一定間隔で起動するだけ
Cron Triggersは標準的なcron式で設定する。公式サンプルにある* * * * *のとおり、最短1分間隔まで設定できる。時刻はUTC基準で動く。1アカウントあたりの登録本数は無料プランで5本、有料プランで250本。CPU時間は1回の実行につき無料プランで10ミリ秒、有料プランでは実行間隔が1時間未満なら30秒・1時間以上なら15分まで使える。
この部品が持っているのは「一定時間で必ず打ち切られる」というタイムアウトだけである。リトライは無い。ある回の実行が失敗しても、Cloudflare側が自動でやり直してはくれない。次のtickが来るまで何も起きない。したがって、Cron Triggersだけで組んだ定期処理は、実行のたびに「前回どこまで終わっていたか」を自分のコードで判定し、途中から再開するか最初からやり直すかを自分で決める設計が要る。ここを省くと、失敗が静かに積み重なる。

### Queues — 配送保証と自動リトライ
Queuesは非同期処理をメッセージ単位で扱う。料金は64KBごとに1オペレーションとして課金され、無料プランは1日1万オペレーションまで、有料プランは月100万オペレーション込みで、超えた分は100万オペレーションあたり0.40ドル。メッセージの保持期間は無料プランが24時間固定、有料プランは既定4日・最大14日まで延長できる。1メッセージの最大サイズは128KB（メタデータ約100バイトを含む）で、リトライ上限は100回。1つのキューが受け付けるスループットは秒間5,000メッセージまで、滞留できるバックログは25GBまでという上限もある。
Cron Triggersと違い、Queuesには「失敗したら自動でやり直す」という仕組みが最初から入っている。これはリトライと途中再開の一部を肩代わりしてくれるという意味で、停止条件を組み込みやすい部品である。ただし配達の保証は「最低1回」であって「ちょうど1回」ではない。同じメッセージが2回届く可能性がある前提で、受け取る側の処理を冪等（同じ入力を2回処理しても結果が変わらない設計）にしておく必要がある。ここを怠ると、リトライが安全弁ではなく二重課金・二重送信という別の事故に変わる。

### Workflows — 落ちても続きから
WorkflowsはGAの機能で、無料・有料の両プランで使える。処理をステップに分けて実行し、各ステップの完了状態を永続化する。途中でWorkerが落ちても、次の実行では最後に完了したステップから続きを動かせる——これが「durable execution（永続的な実行）」と呼ばれる性質で、Cron TriggersにもQueuesにも無い「途中再開」をこの部品だけが持つ。
課金は2026年8月10日以降に開始とされている（開始済みかは本記事では未確認）。CPU時間・リクエスト数・ストレージ・ステップ数の4軸で計算され、Workers本体のPaidプランと同じCPU時間の込み枠を使う。D1のTime Travel（有料プランでも30日）を超える長期のバックアップ処理や、承認待ちのように何日もまたがる非同期処理は、公式もWorkflowsのユースケースとして想定している。停止条件のうち「途中再開」を確実に持たせたいなら、この記事ではWorkflowsを選ぶ。

### Durable Objects — 顧客ごとの状態を持ち続ける
Durable Objectsは無料プランでも使える（ただしSQLiteバックエンドのみ。KVバックエンドは有料プラン限定）。1つのDurable Objectが1つの顧客・1つのエンティティに対応するような設計にすると、状態は再デプロイやリクエストをまたいで消えずに残り続ける。定期的な処理はAlarm機能で持たせられ、そのAlarmの起動もリクエスト課金の対象として数えられる。
Cron Triggers・Queues・Workflowsが「処理そのもの」の停止条件を持つ部品なのに対し、Durable Objectsは「状態」を持つ部品である。顧客ごとに独立したループ（例えば顧客ごとの利用量カウンタや、顧客ごとの定期集計）を作るなら、この状態を土台にしてAlarmで駆動する設計が向く。ただしリトライやタイムアウトはQueues・Workflowsのように部品側が自動で持ってくれるわけではなく、自分のコードで組む部分が残る。

停止条件を持てるのはどれか
△ Cron Triggers — タイムアウトはあるが、リトライ・途中再開は無い
次のtickまで待つだけ。冪等性の設計は全面的に自分の責任

✓ Queues — リトライは自動（上限100回）。ただし配達は最低1回で、二重配達を前提に冪等に作る必要がある
再開の単位はメッセージ1件。処理の途中経過は保存されない

✓ Workflows — ステップ単位で状態を永続化し、途中から再開できる
停止条件の4点のうち「途中再開」を唯一持つ部品

△ Durable Objects — 状態は持ち続けるが、リトライ・タイムアウトの設計は自前
Alarmで定期駆動はできる。停止条件そのものは部品任せにできない

📎 Claudeの判定
4つを同じ土俵で選ぶ問題ではない。定期起動はCron。長時間の処理でCPU・壁時計の制限をまたいで落ちても再開したいならWorkflows。顧客ごとの状態を持つならDurable Objects。Queuesはこの3つと排他ではなく、Workflows内の各ステップから外部処理をキューに投げる、という組み合わせ方もできる。ループの設計で最初に決めるべきは部品の選び方ではなく、「このループはどの停止条件を必要としているか」を先に言語化することである。それが決まらないまま部品を選ぶと、Cron Triggersに全部を背負わせて再びポーリング事故を起こす。

🤖 Codexの指摘
Workflowsの課金開始日について、公式のchangelogの文言は「no earlier than August 10th, 2026（2026年8月10日より早くは開始しない）」であり、「その日から確実に始まった」と断定できる書き方ではない。確認日である2026年8月17日時点で既に開始済みの可能性は高いが、これは資料の側にも留保がある数値であり、断定調で書き切ってはいけない、という指摘を受けている。

✅ 事実（出典つき） Cron Triggersの最短間隔・登録本数、Queuesの料金体系・無料枠・メッセージ最大サイズ・リトライ上限、Workflowsの提供状況と課金開始日、Durable Objectsの無料プラン対応（SQLiteバックエンド限定）は、いずれもCloudflare公式ドキュメントのWorkers・Queues・Workflows・Durable Objectsそれぞれの上限ページと料金ページで確認した（確認日2026年8月17日）。

→ 次のSection 11では、無料プランで始めて、いつ有料プランへ切り替えるかを、発火条件つきで決める。

## 🪜 無料で始めて、いつ有料にするか
このセクションの3点
① 超過時の挙動が製品ごとに逆。ほとんどは止まり、R2だけ課金される
② アプリの有料化とドメインの有料化は別の軸。後者は独自ドメインが要る
③ 有料へ上げる発火条件は8つ。最初の有償顧客の前が分かれ目

さとまた
最初は無料で、あとから有料で。
私は wrangler を使ったデプロイまでの開発をすでに行っているのです。

この章が依頼の中心です。結論から書くと、「無料で始めて、あとから有料」は Cloudflare では成立します。規約上も無料プランでの商用を禁じる条項はありません（第3章）。

ただし2つだけ、順番を間違えると取り返しがつかないものがあります。①独自ドメインと②R2の課金挙動です。この2つは「あとから」では遅い場面があります。

### まず知っておくこと — 超過したときの挙動が、製品によって逆
無料枠を超えたとき、何が起きるか
止まる（課金されない）
Workers / D1 / KV / Durable Objects / Queues / Workflows

- ・無料枠を超えるとエラーを返して停止する。請求は来ない

- ・Workers はエラー 1027 / 1102、D1 は daily limits exceeded

- ・請求事故は起きないが、顧客のシステムが止まる

- ・商業提供ではこれが致命傷。止まってから気づく運用は許されない

課金される（止まらない）
R2 だけ

- ・無料枠を超えると自動的に課金される。切り上げ請求になる

- ・無料枠の範囲で使うだけでも、決済手段の登録が必須（他の製品は不要）

- ・止まらないのでサービスは生きるが、請求が伸びる

- ・対策はバケットを作った日に上限アラートを作ること。あとからでは遅い

この非対称は、設計に直接効きます。「無料枠で様子を見る」という運用は、Workers と D1 では「止まるまで待つ」という意味になり、R2 では「請求が来るまで待つ」という意味になります。同じ「無料で始める」でも、失敗の形が逆です。
さらに、支払いを30日放置すると従量課金サービスのデータが削除されうることが公式の請求ポリシーに書かれています。無料枠で始めること自体は問題ありませんが、カードを登録したあとに放置するのがいちばん危ない状態です。

### 「アプリの有料化」と「ドメインの有料化」は、別の軸である
軸 | 何を買うか | 単位 | あとからでも間に合うか

アプリ側 | Workers Paid $5/月 | アカウント単位 | 間に合う。コード変更なしで即日切り替えられる。D1・R2・Queues などの枠もここで上がる
ドメイン側 | ゾーンの Pro $20/月・Business $200/月 | ゾーン（ドメイン）単位 | 独自ドメインを取るまで、原理的に買えない。WAF もレート制限もゾーンの機能なので、pages.dev のままでは金を払っても守れない

ここがこの記事でいちばん実務的な発見
「有料にする」を1本の階段だと思っていると間違えます。階段は2本あって、上がれる時期が違います。

アプリ側（$5）はいつでも上がれるので、後回しでかまいません。実際、コードは1行も変わりません。

しかしドメイン側（$20）は、独自ドメインを取得してCloudflareのゾーンにしないと、そもそも買えません。そして守る手段（WAF・レート制限・マネージドルールセット）は全部こちら側にあります。つまり「あとから有料にすれば守れる」は、独自ドメインがある場合にだけ正しい。

だから私の判定はこうです。ドメインだけは、無料で始める段階で先に取っておく。年間1,000〜2,000円程度の話で、これを後回しにすると「守りたくなった日に守れない」状態になります。

### 発火条件つき、8ステップ

- 1 STEP 1

#### 開発・社内検証は完全無料でよい
Workers Free、D1 Free、Pages で作る。顧客を載せないうちは、止まっても誰も困らない。ここで金を払う理由はない

- 2 STEP 2

#### 独自ドメインを取り、Cloudflareのゾーンにする
まだ無料プランでよい。買うのはドメインだけ。これを先にやっておくと、あとで守りたくなった日に即Proへ上げられる。逆に後回しにすると、移行作業が本番運用中に降ってくる

- 3 STEP 3

#### R2バケットを作った日に、決済手段の登録と上限アラート
R2は無料枠だけでも決済手段が必要で、超過しても止まらず課金される。バケット作成と同じ日に上限監視を作る。ここだけは「あとから」が効かない

- 4 STEP 4

#### 最初の有償顧客を載せる前に Workers Paid $5
これが最大の分かれ目。無料枠超過は課金ではなくエラー停止なので、商業提供で「止まったら上げる」は成立しない。顧客を載せる前に上げる

- 5 STEP 5

#### 公開した時点で ゾーン Pro $20
マネージドルールセット（OWASP含む）はPro以上。Freeは縮小版のみで、カスタムWAFルールも5本、レート制限は1本しか置けない。不特定多数に開けるなら、ここは必要経費

- 6 STEP 6

#### ログを外へ出す必要が出たら Workers Trace Events Logpush
Workers Paid $5 の範囲で使える。ゾーン全体の標準Logpushと混同しないこと（そちらはEnterprise限定）。あわせてアプリ側の監査ログを D1 か R2 に自分で書く（第5章）

- 7 STEP 7

#### 稼働率を契約で約束したら Business $200
Cloudflare側の100% SLAはBusiness以上。「止まりません」と契約書に書くなら、その根拠がこの層にある。カスタムWAFルールも100本、レート制限5本へ

- 8 STEP 8

#### データ所在地の指定を求められたら Enterprise
Data Localization Suite は Enterprise 限定の有償アドオン。ゾーン全体のHTTPログの継続転送（標準Logpush）も同じ。ここは金額の話ではなく、商談の話になる

📎 Claudeの判定
「最初は無料、あとから有料」は成立します。ただし正確には「無料で始めてよいのはアプリ側だけ」です。

ドメインは無料のうちに取っておく。R2は作った日に決済とアラートを用意する。この2つを守れば、あとは顧客が増えた順に $5 → $20 → $200 と上げるだけで、作り直しは発生しません。コードは変わりません。

逆に、この2つを後回しにしたときだけ、「本番運用中にドメイン移行する」「請求が来てから気づく」という、いちばん高くつく形になります。

🤖 Codexの指摘
Codex はもっと厳しいことを言っています。

「『無料で始める』は、開発、社内検証、顧客を載せない実証までに限定する。最初の有償顧客を載せる前を Workers Paid $5 への発火条件にする。上限エラーが一度でも出てから切り替える運用は、無料検証には許されても商業提供には許されない。」

そして本番を Free と共有ドメインのまま始める案には明確に反対しています。「独自ドメイン、Workers Paid $5、Pro $20、Workers Trace Events Logpush、アプリ監査ログを本番開始条件にする」。

私（Claude）の「あとから上げればよい」より、Codexの「本番開始の条件として最初から揃える」のほうが、商業提供という前提には合っています。私はこの点でCodexに寄せます。ただしSTEP 1〜3（顧客を載せない段階）まで無料でよい、という点は両者一致しています。

✅ 事実（出典つき）

・超過時の挙動: Workers / D1 / KV / Durable Objects / Queues / Workflows は課金されずエラー停止（Workers 1027・1102、D1 は daily limits exceeded）。R2のみ自動課金・切り上げ請求。R2は無料枠利用でも決済手段の登録が必須 — Cloudflare公式の各製品の Limits / Pricing ページ
・支払いを30日放置すると従量課金サービスのデータが削除されうる — Cloudflare公式の請求ポリシー
・プラン別のWAF: マネージドルールセット（OWASP含む）はPro以上。カスタムWAFルール Free 5 / Pro 20 / Business 100 / Enterprise 1,000。レート制限ルール Free 1 / Pro 2 / Business 5 / Enterprise 100 — Cloudflare公式のWAFドキュメント
・100% SLA は Business 以上、Data Localization Suite と 標準Logpush は Enterprise — Cloudflare公式のプラン比較

いずれも 2026年8月17日 時点で公式ドキュメントを確認したもの。プランの内容も価格も変わる領域なので、契約前に必ず自分で当たること。

→ 次のSection 12では、顧客1万人のときに実際いくらになるかを試算する。

5/6　💰 顧客1万人のとき、月いくらか

## 💰 顧客1万人のとき、月いくらか
このセクションの3点
① 顧客1万人・1人1日50リクエストという負荷モデルで試算すると、月の合計は26.50ドル
② 内訳はWorkersの基本5ドルと超過1.50ドル、D1は読み書きとも込み枠の範囲内で0ドル、R2も無料枠内で0ドル、ゾーンPro20ドル
③ これは料金予言ではなく比較用モデル。料金表の枠内であることは性能保証ではない、という警告つきで読む

この試算はCodexが独立に作った負荷モデルである。Cloudflareの公式価格ページに書かれている単価だけを使い、Cloudflareが実測した数値ではない。「Workers Paid 5ドル＋ゾーンPro 20ドルで足りるか」という問いに、具体的な負荷を1つ置いて答えを出すことがこの章の目的である。

$26.50/月
試算の合計

10,000人
想定した顧客数

15億行
D1の月間読み取り行数

Enterprise
ゾーン全体のログ転送が要るなら必要なプラン

### 試算の前提
前提項目 | 値

顧客数 | 10,000人
Workerリクエスト | 1人1日50リクエスト
D1読み取り | 1リクエストにつきD1を100行読む
D1書き込み | 1人1日10行
期間 | 30日
R2 | 1人あたり1MB保存・月1回Class A操作・月10回Class B操作
ゾーン | 1ドメインをPro（20ドル/月）で運用

この前提はCloudflareの実測値ではなく、依頼された1万人試算を成立させるための仮の負荷モデルである。実サービスでは、この数字をアクセスログとD1のクエリ実測に置き換える必要がある。

### 計算
項目 | 月間使用量 | 込み枠・単価 | 試算

Workers | 10,000 × 50 × 30 ＝ 15,000,000リクエスト | 10,000,000リクエスト込み・超過0.30ドル/100万 | 5ドル基本料＋1.50ドル超過
D1読み取り | 10,000 × 50 × 100 × 30 ＝ 1,500,000,000行 | 25,000,000,000行込み | 0ドル追加
D1書き込み | 10,000 × 10 × 30 ＝ 3,000,000行 | 50,000,000行込み | 0ドル追加
R2ストレージ | 10,000 × 1MB ＝ 約10GB-月 | Standardの無料枠10GB-月 | 0ドル追加
R2 Class A | 10,000回/月 | 1,000,000回/月まで無料 | 0ドル追加
R2 Class B | 100,000回/月 | 10,000,000回/月まで無料 | 0ドル追加
ゾーンPro | 1ドメイン | 20ドル/月 | 20ドル

合計は月26.50ドルとなる。固定料金の内訳だけを見ると「Workers Paid 5ドル＋Pro 20ドル＝25ドル」では足りず、Workers超過分の1.50ドルが上乗せされる。ただし実質的にはほぼその構成のままで収まる、という結果である。
より重要なのは金額そのものよりD1の形である。月15億行の読み取りは込み枠の25,000,000,000行に対して余裕があるが、それは全リクエストが単一のD1に集中しても料金上は問題にならないという意味でしかない。第7章で見たとおり、D1は1データベースにつき単一スレッドでクエリを1件ずつ処理する。料金が枠内に収まっていても、直列書き込みとレイテンシは別の制約として残る。

🤖 Codexの指摘
これは料金予言ではなく、資料にある単価だけを使った比較用モデルである。実際の請求はアクセス分布、CPU時間、処理行数、R2操作数で変わる。料金表の枠内であることは性能保証ではない。顧客単位のDB分割、クエリ時間の実測、ピーク時の書き込みQPS測定をしなければ、この26.50ドルを「1万人運用可能価格」として広告してはいけない。

この試算に含まれていないもの
・WorkersのCPU超過分の課金
・R2の容量が10GBを超えた場合の追加料金
・Queues・Workflowsを使う場合の課金
・外部ログ保存先（Workers Trace Events Logpush等の転送先）の費用
・監視・アラートツールの費用
・メール送信サービスの費用
・ゾーン全体のHTTP・WAFログを継続転送するLogpushが必要な場合はEnterprise契約になり、この試算では要件を満たさない

📎 Claudeの判定
26.50ドルという数字は、この記事のどの主張よりも軽く扱われるべきである。この試算が答えているのは「Workers Paid＋ゾーンProの固定費レンジで足りるか」という料金の問いだけであり、「1万人を安全に運用できるか」という問いには答えていない。第7章のD1直列書き込みと、第9章のWorkers上限を合わせて読んだうえで、この金額はスループットの実測が済むまでは仮の数字として扱うのが正しい使い方である。

✅ 事実（出典つき） Workers・D1・R2それぞれの込み枠と単価、ゾーンPro20ドルの料金は、Cloudflare公式のWorkers・D1・R2それぞれの料金ページで確認した数値である（確認日2026年8月17日）。計算そのものはCodexが独立に作成した試算であり、Cloudflareが公表した実測値ではない。

→ 次のSection 13では、ISO27001・SOC2・DPAといった証跡をどう出すかを解説する。

## 📑 証跡をどう出すか
このセクションの3点
① ISO27001・SOC2の報告書はプラン不問で入手できる。ただしSOC2はNDA署名が前提
② DPAは署名不要。SSSAに同意した時点で自動的に効力を持ち、無料プランの顧客にも適用される
③ データ所在地の指定と稼働率SLAはプランで決まる。前者はEnterprise限定、後者はBusiness以上

顧客監査では、必ず同じ順番で聞かれる。証跡はあるか、どう取るか、どのプランが要るか。認証・契約書のたぐいはプラン不問で揃うが、地域指定と稼働率の約束だけは金で解決するしかない項目である。この順に並べる。

顧客監査で聞かれる順
✓ ISO27001認証は保有しているか
Cloudflareが保有。証明書レベルの確認はプラン不問

△ SOC2 Type II報告書を出せるか
プラン不問だがNDA署名が前提。Super Administrator権限のダッシュボードから申請

✓ DPA（データ処理契約）は結べるか
署名不要。SSSAへの同意で自動適用

− データを日本国内など特定地域に限定できるか
Data Localization SuiteはEnterprise限定の有償アドオン

− 稼働率SLAを契約に書けるか
100% SLAはBusiness（月200ドル）以上

✅ 事実（出典つき） Cloudflare公式ドキュメントのコンプライアンス文書ページに、コンプライアンス文書へのアクセスはアカウントのSuper Administratorに限られると明記されている。Cloudflareのトラストハブでは、SOC2報告書の提供前に全ての現在・将来の顧客がNDAへの署名を求められると書かれている。プラン（Free・Pro・Business・Enterprise）による証跡アクセスの制限は確認できなかった。

✅ 事実（出典つき） DPA本文には、SSSA・Enterprise Subscription Agreement・その他の書面または電子的な合意に基づきCloudflareのサービスを利用する顧客に適用され、顧客が署名した日または当事者がこのDPAに合意した日から効力を持つ、と書かれている。データ所在地の指定（Data Localization Suite）はwww.cloudflare.comのドキュメントでEnterprise限定の有償アドオンと明記されている。

### SLAと地域指定は、紙とは別の軸
紙で済むもの ⇄ 金で解決するもの
紙（認証・契約）
プラン不問

- ・ISO27001・SOC2の報告書はプラン不問で入手できる

- ・DPAは自動適用。無料プランの顧客にも及ぶ

- ・実務のハードルはNDA締結のフローだけ

金（プラン・アドオン）
ここだけプランに縛られる

- ・データ所在地の指定はEnterprise限定の有償アドオン

- ・100%稼働率SLAはBusiness（月200ドル）以上

- ・ゾーン全体のログ長期転送（標準Logpush）もEnterprise限定

📎 Claudeの判定
紙（認証・DPA）はプラン不問で揃う。足りないのは地域指定とSLAで、ここは金で解決するしかない。ISO27001・SOC2の報告書もDPAも、無料プランの顧客に対して門前払いにはならない。ただし、報告書を提示すること自体はコンプライアンスの「入口」に過ぎない。前記事で立てた結論——AIは第三者になれない。作れるのは客観性であって第三者性ではない——はここでも変わらない。ISO27001・SOC2の認証はCloudflareが自分の運用について第三者機関から得たものであり、利用者であるこちら側のログ設計・アクセス制御・保持ポリシーが自動的にその認証に含まれるわけではない。顧客に見せるべき証跡は、Cloudflareの認証書と、自分たちが第6章・第5章で作った監査ログ・保持ポリシーの2枚を並べたものになる。

🤖 Codexの指摘
ISO27001認証と自分のシステムの適合を混同しやすい。CloudflareがISO27001等を保有していても、利用者のログ設計、アクセス制御、保持、レビューが自動的に適合するわけではない。SOC2文書はNDAが前提である。同じ要件ならCloudflareを選ぶという判断は、無料サービスの商用利用自体を禁止する明文がなく、Audit Logsが全プランで18ヶ月あり、Workers Paid 5ドルでWorkers Trace Events Logpushを使え、D1・R2へ自前の監査ログと長期アーカイブを構築できることに基づく。ただしCloudflareなら安価にISO27001対応が完成する、とは言わない。ゾーン全体の標準LogpushはEnterprise限定で、データ所在地指定もEnterprise、契約上のSLAはBusiness以上である。必要な証跡がWorkersの実行ログ、Cloudflareの設定変更、アプリの監査ログで満たせる案件ならCloudflareが明確に有利だが、WAF・HTTPアクセスログの長期転送や地域限定まで要求されればEnterprise商談になる。

→ 次のSection 14では、この12個の壁をふまえてVercelとCloudflareのどちらを選ぶか、5列の比較表で並べる。

## ⚖️ Vercelとどちらを選ぶか
このセクションの3点
① 同じ要件を同じ基準で当てた。5項目のうち4項目でCloudflareが上
② Codexは同じ要件ならCloudflareを選ぶと断定した。私も同じ
③ ただし要件がログの長期転送と地域指定まで含むなら、差は消える

この比較には前提があります。同じ依頼者の同じ要件（顧客に提供する商業システム・ISO27001の証跡が要る）に対して、Vercelを2本の記事で調べ、Cloudflareを今回調べた。だから同じ問いを同じ基準で当てています。

「どちらが優れているか」ではありません。この要件では、どちらが安く証跡を積めるかです。

論点 | Vercel | Cloudflare | どちらが有利か

無料プランでの商用 | 利用規約4条で禁止（Hobbyは商用不可） | 規約に禁止条項が無い。ただし workers.dev は公式ドキュメントが「business-criticalでない用途」と明記 | Cloudflare。小さく始めて商用へ移る道が塞がれていない
実行ログの保持 | Runtime Logs 1時間 | Workers Logs 無料3日 / 有料7日 | Cloudflare。ただしどちらも1年保持の契約には足りない
監査ログ | Enterprise 限定 | 全プランで18ヶ月 | Cloudflare。ここが最大の差
WAFマネージドルール | Proで使える | Pro（20ドル）以上で使える | 互角。ただしCloudflareは独自ドメインが前提
ログの外部転送 | — | Workers Trace Events Logpush は Paid 5ドルで可。ゾーン全体の標準Logpushは Enterprise | Cloudflare（限定的にだが安価に出せる）
データ所在地の指定 | — | Enterprise 限定の有償アドオン | 互角に厳しい
最低ラインの月額 | Pro 20ドル | Workers Paid 5ドル + ゾーン Pro 20ドル = 25ドル | Vercelがやや安い（ただし証跡の取れ高が違う）

🤖 Codexの指摘
Codexは断定しました。

「同じ要件ならCloudflareを選ぶ。理由は、無料サービスの商用利用自体を禁止する明文がなく、Audit Logsが全プランで18ヶ月あり、Workers Paid 5ドルで Workers Trace Events Logpush を使え、D1・R2へ自前の監査ログと長期アーカイブを構築できるからである。VercelはHobbyで商用利用できず、Runtime Logsが1時間、Audit LogsがEnterprise限定なので、小規模から証跡を積み上げる道がCloudflareより狭い。」

同時に、過剰な期待を否定しています。

「ただしCloudflareなら安価にISO 27001対応が完成する、とは言わない。ゾーン全体の標準LogpushはEnterprise限定で、データ所在地指定もEnterprise、契約上のSLAはBusiness以上である。必要証跡がWorkersの実行ログ、Cloudflare設定変更、アプリ監査ログで満たせる案件ならCloudflareが明確に有利だが、WAF/HTTPアクセスログの長期転送や地域限定まで要求されればEnterprise商談になる。」

📎 Claudeの判定
私もCloudflareを選びます。Codexと同じ結論ですが、決め手の順番が少し違います。

私にとって最大の差は「小さく始められるか」です。Vercelは商用にした瞬間にProが必須で、しかもその20ドルを払っても監査ログは手に入りません（Enterprise限定）。Cloudflareは無料の段階から Audit Logs が18ヶ月分たまり続けます。顧客監査は「いま何ができるか」ではなく「過去の記録が残っているか」を聞いてくるので、証跡は早く始めたほうが勝ちます。

逆にVercelを選ぶ場面もはっきりしています。独自ドメインを持たない、持ちたくない案件です。CloudflareはWAFがゾーン単位なので、共有ドメインのままでは守れません。Vercelは自社のドメイン配下でも防御が効きます。「ドメインを持たない商用」はCloudflareでは成立しない——これが唯一、はっきりVercelが勝つ条件です。

要件で分かれる
Cloudflareを選ぶ
証跡を安く積み上げたい

- ・独自ドメインを持っている（または取る気がある）

- ・必要な証跡が設定変更・実行ログ・アプリ監査ログで足りる

- ・無料の段階から記録を残し始めたい（Audit Logs 18ヶ月）

- ・egress無料が効く（ログ・成果物・画像を大量に配る）

- ・書き込みが多くない、または顧客ごとにDBを分けられる

Vercelを選ぶ、または他を検討する
要件が重い、またはドメインを持たない

- ・独自ドメインを持たない商用（Cloudflareでは守れない）

- ・ゾーン全体のHTTPログを長期転送する必要がある（CloudflareはEnterprise）

- ・データ所在地の指定が要件（どちらも上位プラン）

- ・単一DBへの書き込みが集中する（D1が向かない。Hyperdrive経由で既存DBを使う）

- ・1顧客で10GBを超えるデータを持つ

→ 次のSection 15では、Codexと割れたところと、この記事の限界を書く。

6/6　🤖 Codexと割れたところ、この記事の限界

## 🤖 Codexと割れたところ、この記事の限界
このセクションの3点
① Codexは私の読み方に20個の危険を挙げた。全部載せる
② 判断が割れたのは1点。いつ有料へ上げるかの発火条件
③ 確認できなかった一次情報が5件ある。確度を落とさず書いた

この記事は、私（Claude）が公式ドキュメントを調べ、同じ資料を OpenAI の Codex に独立に読ませて設計を組ませ、そのうえで突き合わせたものです。

Codex は「資料には有用な一次情報が揃っているが、そのまま要約すると次を誤る危険がある」として、20個の誤読パターンを挙げてきました。実際に私は、そのうち1つを本文で踏んでいました。

20
Codexが挙げた誤読の危険

1
実際に私が踏んでいたもの

1
判断が割れた論点

5
一次情報を確認できなかった項目

### 私が実際に踏んでいた誤り
Codex の指摘20番。「Workflows の課金開始を『2026年8月10日から開始済み』と断定しやすい」。
公式の文言は Starting no earlier than August 10th, 2026（2026年8月10日より前ではない時期に開始）であって、開始済みとは書かれていません。私は第1章の表に「2026年8月10日から課金開始」と断定で書いていました。調査資料の中でも、片方は開始済みと書き、もう片方は現況確認が必要と留保していて、私は断定しているほうだけを採っていました。
「以降に開始とされている（開始済みかは本記事では未確認）」に直しました。2つの資料が食い違っているとき、強いほうを採るのは私の癖です。これは前の記事でも同じ形で指摘されています。

### 判断が割れた1点 — いつ有料へ上げるか
同じ事実を見て、結論が違った
📎 Claude
あとから上げればよい

- ・アプリ側の有料化はコード変更なしで即日できる

- ・だから顧客が増えた順に 5ドル → 20ドル → 200ドルと上げればよい

- ・先に取るべきなのはドメインだけ

- ・無料で始めること自体に問題はない

🤖 Codex
本番開始の条件として最初から揃える

- ・「上限エラーが一度でも出てから切り替える運用は、無料検証には許されても商業提供には許されない」

- ・最初の有償顧客を載せる前を発火条件にする

- ・本番を無料と共有ドメインのまま始める案には明確に反対

- ・独自ドメイン・Workers Paid・Pro・Logpush・アプリ監査ログを本番開始の条件にする

私はCodexに寄せました。「あとから上げられる」は技術的には正しいのですが、商業提供という前提では、止まってから気づく運用が許されないという指摘のほうが強い。第11章の判定はCodex側で書いています。
ただし顧客を載せない段階（開発・社内検証・実証）まで無料でよいという点は、両者一致しました。依頼者の「最初は無料で、あとから有料で」は、その範囲では完全に成立します。

### Codexが挙げた、間違えやすい20個のうち主要なもの
間違えやすい点 | 正しくはどうか

D1の読み取り込み枠の桁 | 公式は First 25 billion＝250億行。25億ではない。資料内で表記が揺れていた
行数とクエリ数の混同 | D1の課金枠はAPIリクエスト数ではなく処理した行数。10件返しても、インデックスが無ければ10行課金とは限らない
「100msなら10QPS」を製品の固定上限として書く | これは単一スレッドと平均クエリ時間からの例であって固定上限ではない。1msなら約1,000QPSという例も同じ資料にある
1DB 10GB と アカウント1TB の混同 | Paidでも1DBは10GBで増量できない。アカウントに空きがあっても単一DBは伸ばせない
D1 Free の上限 | 1DB 500MB・アカウント合計5GB・DB数10 という別々の上限がある
Read Replication を有効にすれば読み取りが分散される | Sessions APIを使わないと全クエリがプライマリへ行く。さらにレプリカは書き込みを分散しない
Workers Paid 5ドル と ゾーン Pro 20ドル を同じ階層と思う | 別契約軸。Proだけ買ってもWorkersの日次停止は消えず、Workers Paidだけ買ってもマネージドルールセットは得られない
R2もWorkers Paidに含まれて安全に止まる、と思う | R2は独立して決済手段が必要で、超過は自動課金。この非対称が運用設計の中心
workers.dev の記述を規約上の商用禁止に格上げする | 自己サービス規約に無料の商用禁止は無い。公式ドキュメント上の位置づけであって、Vercel Hobbyの規約違反と法的に同じとは書けない
pages.dev にも同じ趣旨の記述があると断定する | Pagesでは同様の文言を発見できていない。共通して言えるのは「共有ドメインにゾーンWAFを適用できない」ことだけ
FreeにはWAFが無い、と書く | Freeにも縮小版のマネージドルールセットがある。「Freeはゼロ」も「FreeでProと同じ」も両方まちがい
PagesよりWorkersが公式に推奨されていると書く | 公式が非推奨としているのは旧アダプタと旧方式。Workersを選ぶのはこの記事の設計判断であって公式の明文ではない
Audit Logs をアプリの監査ログと呼ぶ | Cloudflareの設定操作の監査であって、業務操作・データ閲覧・認可拒否の証跡ではない
CloudflareがISO 27001を持っている＝自分のシステムが適合する | 別。利用者側のログ設計・アクセス制御・保持・レビューが自動的に適合するわけではない

この記事の限界（読む前提として）
・数値はすべて 2026年8月17日 時点。プランも価格も上限も変わる領域なので、契約前に必ず自分で公式を当たること
・一次情報を直接確認できなかったものが5件ある。R2を無料枠だけで使う場合の決済手段の要否、共有ドメインへのWAF不適用を明文で述べた公式ページ、アップロード最大サイズの一部、Zero Trustの価格ページ本文、Workflowsの課金開始の現況。いずれも本文で確度を落とさずに書いた
・Workflowsの課金開始は 2026年8月10日より前ではない という公式文言までしか確認していない。開始済みかは確認していない
・実際にこの構成で商業システムを運用した実績にもとづく記事ではない。公式ドキュメントの数値と、2つのAIの設計判断である
・D1の 100msで10QPS はベンチマーク結果ではなく、単一スレッドという性質からの例である。実測はしていない
・顧客1万人の試算は、依頼された試算を成立させるための負荷モデルであって実測値ではない。料金表の枠内であることは性能保証ではない

Codexが挙げた、この構成が破綻する3条件
① 単一のD1へ全顧客の書き込みを集めたとき。課金枠が残っていても、ピークの書き込みで詰まる。テナント分割できない業務なら、外部のPostgreSQLやMySQLをHyperdrive経由で使うほうへ替える。

② 1顧客のデータが10GBを超える、または長期履歴と監査ログを無期限にD1へ積むとき。1DB 10GBは増量できず、Time TravelもPaidで30日まで。R2へのアーカイブでworking setを抑えられないなら、D1を選ばない。

③ 必要な証跡・地域制限・SLAを月25ドルの構成だけで満たせると思ったとき。Workers Logsは最大7日、標準LogpushとData LocalizationはEnterprise、SLAはBusiness以上。顧客契約がこれらを要求した瞬間に、25ドルという価格前提は破綻する。

→ 最後のSection 16に、全文コピーを置く。