Cloudflare 無料版の制限一覧：CDN、DNS、WAF、Workers はどこまで使える？

Cloudflare の無料版は多くの人から「サイバー菩薩」と呼ばれています。グローバル CDN、DDoS 保護、SSL 証明書、DNS 解決、すべて無料です。しかし「無料」には常に境界があります。

Workers は毎日 10 万リクエスト、Pages は月間 500 回ビルド、DNS は最大 1000 レコード。これらの数字は何を意味するのでしょうか？あなたのプロジェクトが突然制限されることはあるでしょうか？この記事では、Cloudflare のすべての製品の具体的な制限を一度にまとめ、制限超過を判断するお手伝いをします。

正直に言いましょう：無料版で個人ブログや小規模プロジェクトをホストする予定なら、この記事で 5 分以内に決断できます。

一、CDN と DNS：「無制限」の背後にある真実

Cloudflare の最も魅力的な特徴：無制限帯域幅。この 4 文字は多くの開発者を惹きつけます。しかし、喜ぶのはまだ早いです。

CDN の「無制限」とは具体的にどういう意味？

公式ドキュメントでは帯域幅の上限が明記されていません。Free、Pro、Business すべて記載がありません。これは何を意味するのでしょうか？

2024年10月、Reddit でユーザーが実測データを共有しました：月間 20TB のトラフィックを数ヶ月間継続しても、アカウントは正常に動作していました。Cloudflare コミュニティでも同様のフィードバックがあります——無料版で月間 15TB を実行しても問題なかったという報告です。

しかし、ここに落とし穴があります。利用規約に明記されています：ストリーミング動画、大規模な非 HTML ファイルのホスティングは許可されていません。「大規模」とは何か？具体的な数字はありません。公式の表現は「不釣り合いな負荷」です。この表現は曖昧ですが、意味は明確です：動画 CDN として使用すれば、遅かれ早かれアカウント停止されます。

もう一つの明確な制限：単一ファイルのキャッシュ上限 512 MB。この数字は Workers Limits ドキュメントに明記されており、無料版と有料版で共通です。大きな動画をキャッシュしたい？できません。

つまり、CDN の「無制限」には 2 つの意味があります：

1. 通常のウェブサイトトラフィック（HTML、CSS、JS、画像）——基本的に上限なし
2. 動画や大容量ファイル——明確に禁止

ブログサイト、静的サイト、小規模 API プロキシ？安心して使用できます。画像サイト？1枚あたり 512MB を超えなければ OK です。動画プラットフォームを作りたい？諦めましょう。

DNS レコード制限：予想外の落とし穴

DNS は Cloudflare のコアサービスですが、無料版の制限はどこにあるのでしょうか？

2024年9月が分岐点です。この日より前に作成された無料ゾーン（zone）は、3000 レコードを設定できました。以降に作成されたものは、1000 レコードのみです。

なぜこのような変更があったのか？公式からの説明はありませんが、コミュニティの議論では一つの理由が指摘されています：悪用の防止。無料版でドメインを大量に作成し、ゴミレコードを詰め込むユーザーがいたのです。

1000 件で十分でしょうか？単一ドメインで、数十のサブドメインを設定し、MX、TXT レコードを追加しても——通常は数百件で十分です。実際の問題は：ドメイン数がいくつあるか？

良いニュースは：ドメイン数に上限はありません。無料アカウントで無制限にドメインを追加できます。各ドメインが 1000 レコードを超えなければ、いくらでも追加可能です。

ただし、注意すべき点があります：DNS クエリ自体に制限はありません。トラフィックが増えても DNS 解決が止まる心配はありません。

実際に十分なシナリオ

あなたのプロジェクトが以下の場合：

• 個人ブログ（WordPress、Hexo、Hugo）——完全に十分
• 静的サイト（Astro、Next.js SSG）——完全に十分
• 小規模 API プロキシ（数個のバックエンドサービスへの転送）——基本的に十分
• 画像ホスティングサイト（1枚あたり < 512MB）——十分ですが、総量に注意

これらの範囲を超える場合、事前に利用規約（ToS）を確認することをお勧めします。アカウント停止されてから問題に気づくのでは遅すぎます。

二、Workers と KV：計算レイヤーの境界線

Workers は Cloudflare のエッジコンピューティングプラットフォームです。JavaScript または TypeScript を書いて、世界 200 以上のノードにデプロイします。素晴らしいですね。しかし、無料版の制限は CDN よりも厳しいです。

Workers リクエスト制限：毎日 10 万回

公式ドキュメントに明記されています：無料版は毎日 100,000 リクエスト。UTC 00:00 にリセットされます。

この数字は何を意味するのでしょうか？あなたの API が平均して各ユーザーに毎日 10 回呼び出されると仮定します：

• 100 ユーザー → 毎日 1000 リクエスト → 月間 30,000 → 安全
• 1000 ユーザー → 毎日 10,000 リクエスト → 月間 300,000 → 制限超過

実際、多くの小規模プロジェクトで Workers が使用されます：

• API Gateway（バックエンドへのリクエスト転送）
• SSR レンダリング（Next.js、Remix）
• フォーム処理（POST リクエストの受信）
• JWT 検証（未認証リクエストのブロック）

これらのシナリオでは、各リクエストがクォータを 1 回消費します。あなたのサイトに毎日 1000 ビジターがあり、各人が 5 回 Workers を呼び出すと、1日で 5000 リクエストです。問題なさそうですね。しかし、アクセス数が 10 倍になったら？1ヶ月で制限超過です。

より重要な制限：CPU 時間 30ms/リクエスト。この数字は公式 Limits ドキュメントからです。30ms で何ができる？単純な JSON 解析、ルーティング判断、JWT 検証——OK。複雑な計算？無理。例えば、Workers で画像圧縮、PDF 生成、ディープラーニング推論——タイムアウトする可能性が高いです。

もう一つの詳細：スクリプトサイズ上限 1 MB（圧縮後）。環境変数は最大 64 個、各最大 5KB。小規模プロジェクトでは通常十分ですが、大規模アプリケーションでは注意が必要です。

KV：キャッシュレイヤーのクォータ

Workers KV はエッジキーバリューストレージです。2026年2月、公式ブログで無料版の枠引き上げが発表されました：

• 読み取り：100,000 回/日
• 書き込み：1,000 回/日
• ストレージ容量：1 GB

書き込みは 1000 回/日のみ——この制限は厳しいです。

どのようなシナリオで大量書き込みが発生する？ユーザーセッションキャッシュ、アクセスログ、カウンター。あなたの API が各リクエストで 1 レコードを書き込む場合、1日で 1000 リクエストで満杯です。

しかし、読み取りは比較的緩やかです。10 万回/日で、小規模な読み取りキャッシュシナリオをサポートできます：

• 設定キャッシュ（KV から API キー、feature flags を読み取り）
• 静的データキャッシュ（製品リスト、記事ディレクトリ）
• ユーザープロファイルキャッシュ（読み取り多、書き込み少）

KV を RAG アプリケーションのベクトルストレージとして使用する予定？待ってください、それは適していません。KV にはベクトル検索機能がなく、書き込み制限も厳しいです。ベクトルデータベースには Cloudflare Vectorize（有料）または外部の Pinecone、Milvus を使用してください。

D1：エッジ SQLite データベース

D1 は Cloudflare の SQLite エッジデータベースです。2026年5月、技術ブログ buildmvpfast が公式データをまとめました：

• 行読み取り：5,000,000 行/日
• 行書き込み：100,000 行/日
• ストレージ：5 GB

読み取り枠は非常に緩やか——500 万行。書き込みも KV より高い——10 万行。つまり、D1 は純粋なキャッシュよりもデータ永続化に適しています。

実際のシナリオ：

• ブログコメントシステム（読み取り多、書き込み少）
• ユーザープロファイルストレージ（たまに更新）
• 小規模 CMS（記事、タグ、カテゴリ）

EC 注文システムを作りたい？書き込み量が制限を超える可能性があります。各注文で 1 レコード、1日で数千件の注文があれば、1ヶ月で制限超過です。

十分かどうか？トラフィックモデルで判断

重要な数字を整理します：

製品	毎日の無料枠	適用シナリオ
Workers	100,000 リクエスト	小規模 API、SSR レンダリング
Workers CPU	30ms/リクエスト	単純なロジック
KV 読み取り	100,000 回	読み取りキャッシュ
KV 書き込み	1,000 回	セッションキャッシュ（制限あり）
D1 読み取り	5,000,000 行	データクエリ
D1 書き込み	100,000 行	データ書き込み

あなたのプロジェクトの日次アクセス数が 1000 以下なら、これらの枠は基本的に十分です。アクセス数が 5000 を超える場合、Workers クォータを事前に監視することをお勧めします。毎日ダッシュボードを確認し、突然 403 エラーになってから制限超過に気づくのを避けましょう。

三、Pages：デプロイ制限は想像以上に厳しい

Cloudflare Pages は静的サイトホスティングプラットフォームです。Git 統合、自動ビルド、グローバルデプロイをサポートします。無料版の制限は Workers よりも具体的です。

ファイル数とビルド回数：明確な上限

公式 Pages Limits ドキュメントの数字：

• ファイル数：20,000 個/サイト
• ビルド回数：500 回/月
• 並列ビルド：1 個
• 単一ファイル上限：25 MB

20,000 ファイルは多いように思えますが、Next.js や Astro で中規模ブログサイトを作る場合——数百記事、各記事に画像、CSS、JS——すぐにこの数字に近づく可能性があります。

2026年1月、公式チェンジログで有料版のファイル上限が 100,000 に引き上げられました。無料版は依然として 20,000。これは何を意味する？サイトがスケールし始めると（コンテンツが 500 記事を超える、または大量のメディアファイルがある）、遅かれ早かれ壁にぶつかります。

ビルド回数 500/月はさらに重要です。各 git push でビルドがトリガーされます（手動でキャンセルしない限り）。あなたの開発ペースを仮定します：

• 毎日 2 回コードを変更 → 月間 60 回ビルド → 安全
• 毎日 10 回コードを変更 → 月間 300 回ビルド → すぐに満杯
• CI/CD 自動ビルド（各コミット） → 1週間で制限超過の可能性

並列ビルドは 1 つのみ。これは、2 回 push すると、2 回目のビルドが待機することを意味します。個人開発では問題ありませんが、チーム协作では相互にブロックする可能性があります。

実際のシナリオ分析

静的ブログ（Hexo、Hugo、Astro）：

• ファイル数：記事 + 画像 + テーマファイル、通常 5000 以下 → OK
• ビルド回数：週に数回変更 → OK
• 結論：完全に十分

中規模コンテンツサイト（500+ 記事、画像あり）：

• ファイル数：20,000 に接近する可能性 → 注意が必要
• ビルド回数：頻繁な更新 → 制限超過の可能性
• 結論：監視をお勧め、有料アップグレードを準備

小規模 SPA（React、Vue シングルページアプリケーション）：

• ファイル数：ビルド後は通常 < 1000 → OK
• ビルド回数：開発段階で頻繁に push → 制限超過の可能性
• 結論：開発段階でビルド頻度を制御

チーム协作プロジェクト：

• 並列ビルド：複数人が push すると待機 → 効率の問題
• ビルド回数：全員が変更 → すぐに制限超過
• 結論：有料版へのアップグレードをお勧め、並列ビルドを解放

制限超過の予兆

いつ有料版を検討すべきか？

1. ファイル数が 15,000 を超える —— 上限に近い
2. 月間ビルド回数が 300 を超える —— 開発ペースが速い
3. チームが 3 人を超える —— 並列ビルドがブロックし始める
4. サイトコンテンツが急速に成長 —— 月間 50+ 記事を追加

Pro プランは $20/月で、100,000 ファイルと並列ビルドが解放されます。プロジェクトがスケールし始めたら、この投資は制限超過後の緊急対応よりも賢明です。

四、R2 と WAF：ストレージとセキュリティの無料境界線

R2 は Cloudflare のオブジェクトストレージです。WAF は Web Application Firewall です。これら 2 つの製品の無料版の制限が、あなたのプロジェクトがどこまで進めるかを決定します。

R2：ゼロエグレス料金の代償

R2 の最も魅力的な点：ゼロエグレス料金。AWS S3 はエグレストラフィック料金を請求し、1GB あたり $0.09。Cloudflare R2 は請求しません。

しかし、無料版には制限があります。公式 Pricing ドキュメントに明記されています：

• ストレージ容量：10 GB
• Class A オペレーション（書き込み/リスト）：1,000,000 回/月
• Class B オペレーション（読み取り）：10,000,000 回/月

10 GB ストレージには何が保存できる？

• 画像（各 500KB）→ 約 20,000 枚
• PDF ファイル（各 5MB）→ 約 2,000 個
• 動画（各 100MB）→ 約 100 個

問題なさそうですね。しかし、画像ホスティングサイトを作り、ユーザーアップロードが制御できない場合——2ヶ月で満杯になる可能性があります。

オペレーション枠は比較的緩やかです。Class A（書き込み）100 万回/月、Class B（読み取り）1000 万回/月。つまり、読み取り圧力が高いシナリオ（画像 CDN）——基本的に制限超過しません。書き込み圧力が高いシナリオ（ユーザーが頻繁にアップロード）——監視に注意が必要です。

WAF：保護範囲は限定されているが十分

WAF 無料版は何を提供する？

2026年5月の公式ドキュメント更新後、明確になりました：

• Cloudflare Free Managed Ruleset（管理ルールセットのサブセット）
• ドメインレベル WAF のみアクセス可能、アカウントレベルにはアクセス不可
• WordPress 専用保護は含まれない
• カスタムルールは使用可能（Custom Firewall Rules）

「管理ルールセットのサブセット」とはどういう意味？公式から具体的な数字はありませんが、コミュニティの議論と 2022 年の公式ブログ「WAF for everyone」記事によると——無料版がカバーするのは高危険度脆弱性保護であり、全ルールではありません。

具体的には以下を含みます：

• OWASP Top 10 主要脆弱性（SQL Injection、XSS など）
• Cloudflare 固有の脅威ルール（一部）
• 高危険度 CVE 脆弱性（緊急修正）

含まれないもの：

• WordPress 専用保護（Pro 以上が必要）
• 高度な管理ルール（詳細設定）
• アカウントレベルの統一管理（複数ドメインの統一ルール）

カスタムルールは使用可能です。以下を設定できます：

• IP によるブロック（悪意ある IP を禁止）
• 国によるブロック（Geo-blocking）
• User-Agent によるブロック（ボットをブロック）
• URL パスによるブロック（機密パスを保護）

これらの機能は小規模サイトで十分です。ブログサイト、個人プロジェクト——無料 WAF で大部分の自動化攻撃を防げます。しかし、EC、金融系ビジネスを運営している場合——有料版へのアップグレードをお勧めします、完全なルールセットを解放できます。

適用シナリオ分析

シナリオ	R2 は十分？	WAF は十分？
個人ブログ（画像 < 100 枚）	✓ 完全に十分	✓ 十分
画像ホスティングサイト（ユーザーアップロード制御可能）	✓ 総量に注意	✓ 十分
画像ホスティングサイト（ユーザーアップロード制御不可）	✗ 制限超過の可能性	✓ 十分
ファイル共有サイト（PDF/ドキュメント）	✓ ファイル数による	✓ 十分
小規模 EC（機密データなし）	✓ 十分	△ アップグレード推奨
中規模 EC（決済フローあり）	✓ 十分	✗ アップグレード推奨

R2 の 10 GB が最も重要なボトルネックです。プロジェクトのユーザーアップロードが制御できない場合——事前にストレージ拡張を計画するか、AWS S3 / Backblaze B2 を外部接続して階層型ストレージを行うことをお勧めします。

五、シナリオ意思決定表：無料版は本当に十分か？

前の章ですべての数字を列挙しました。しかし、最も重要な質問は：あなたのプロジェクトは制限を超えるか？

ここにクイック判断表を用意しました。プロジェクトタイプとスケールで分類、一目でわかります。

プロジェクトタイプで判断

プロジェクトタイプ	月間リクエスト	月間トラフィック	ストレージ要件	無料版の結論
個人ブログ（静的）	< 10K	< 1 GB	< 1 GB	✓ 完全に十分
技術ブログ（動的 SSR）	< 100K	< 10 GB	< 1 GB	△ Workers が制限超過の可能性
API サービス（小規模）	< 3M	—	< 5 GB	✗ Workers は有料が必要
画像ホスティングサイト（小規模）	—	< 20 GB	< 10 GB	△ R2 が制限超過の可能性
画像ホスティングサイト（中規模）	—	> 50 GB	> 10 GB	✗ R2 は有料が必要
静的コンテンツサイト（500+ 記事）	—	< 20 GB	—	△ Pages ファイルが制限超過の可能性
チーム協作プロジェクト	複数人開発	—	—	✗ Pages 並列は有料が必要

トラフィックスケールで判断

日次アクセス数	Workers リスク	Pages リスク	CDN リスク
< 100	なし	なし	なし
100-500	なし	なし	なし
500-1000	低（月間約 15K リクエスト）	なし	なし
1000-5000	中（月間約 150K リクエスト）	低	なし
5000-10000	高（Workers が制限超過の可能性）	中（ビルド頻度）	なし
> 10000	制限超過	高	なし（動画を除く）

クイック自己チェックリスト

これらの質問に答えれば、制限超過かどうか判断できます：

1. あなたのサイトは毎日何人のビジターがいますか？

   • < 100 → すべての製品で十分
   • 100-1000 → Workers に注意、他は OK

   • 1000 → Workers が制限超過の可能性

2. あなたのサイトには何個のファイル/記事がありますか？

   • < 100 → Pages は完全に十分
   • 100-500 → Pages は OK、成長に注意

   • 500 → Pages ファイルが上限に接近

3. あなたのチームは何人ですか？

   • 1 人 → Pages 単一並列で十分
   • 2-3 人 → Pages がブロックする可能性

   • 3 人 → 有料版へのアップグレード推奨

4. ユーザーファイルをどれくらい保存する必要がありますか？

   • < 5 GB → R2 で十分
   • 5-10 GB → R2 がすぐに満杯

   • 10 GB → R2 は有料が必要

5. コードを毎日何回ビルドしますか？

   • < 10 回/週 → Pages 500 ビルドで十分
   • 10-30 回/週 → Pages が上限に接近

   • 30 回/週 → Pages が制限超過の可能性

いつアップグレードすべきか？

あなたのプロジェクトに以下の兆候が現れた場合、Pro プラン（$20/月）の検討をお勧めします：

• Workers リクエストが 80K/日に接近 —— 上限に近い
• Pages ビルドが 400 回/月を超える —— 開発ペースが速い
• R2 ストレージが 8 GB を超える —— まもなく満杯
• チーム協作でビルド待機が発生 —— 並列のボトルネック
• サイトトラフィックが急速に成長 —— 予防的アップグレード

Pro プランで解放されるもの：

• Workers リクエスト：無制限（従量課金、$0.02/百万リクエスト）
• Pages ファイル：100,000
• Pages ビルド：並列 5 個
• R2 ストレージ：有料版は従量課金、ゼロエグレス料金
• WAF ルール：完全な管理ルールセット

あなたのプロジェクトがすでにスケールし始めている場合、$20/月 は AWS/Vercel の従量課金よりもお得かもしれません——少なくとも Workers と CDN の費用は予測可能で、請求書を見て驚くことはありません。

結論

Cloudflare 無料版のコア制限は 3 つの製品に集中しています：Workers（10 万リクエスト/日）、Pages（500 ビルド/月）、R2（10 GB ストレージ）。CDN と DNS の「無制限」は本当です——動画や大容量ファイルをホストしない限り。

あなたのプロジェクトがまだ無料版の範囲内なら、今すぐ Cloudflare を導入する時です。グローバル CDN、DDoS 保護、SSL 証明書——これらの機能は他のプラットフォームでは有料です。

しかし、プロジェクトがすでに制限に接近している場合、Pro プランの $20/月 は AWS/Vercel の従量課金よりもお得かもしれません。少なくとも毎月の費用が明確で、請求書を見て驚くことはありません。

最後のアドバイス：事前に監視する。毎日ダッシュボードを確認し、週に 1 回クォータ使用率をチェックしましょう。突然 403 エラーになってから制限超過に気づくのを避けてください。