番外編 Cloudflare Workersの無料運用を調べる―障害、上限、料金とAstroサイトの移行余地

Astroで公開しているゆまラボをCloudflare WorkersのFreeで運用し続けられるか、10万リクエスト、静的アセット数、ビルド上限、過去の障害、料金、別サーバーへの移行まで確認します。

執筆：ゆまラボ運営者

公開：更新：
番外編 Cloudflare Workersの無料運用を調べる―障害、上限、料金とAstroサイトの移行余地

第1回でWordPress以外の構成を考え、最終的にAstroとCloudflare Workersを選んだ。

記事をMarkdownで持てること、GitHubで変更履歴を管理できること、あとからAIを使った記事作成や自動化へ広げやすいこと。そのあたりは実際にサイトを作っていく中でも変わっていない。

もう一つ大きいのが、レンタルサーバーを別に契約しなくても公開できる点。

ただ、無料で動いていると逆に気になる。どこまで無料なのか。アクセスが増えたら止まるのか。記事が何千件になってもビルドできるのか。Cloudflare自体が止まったらどうするのか。

第13回までサイト側の修正を続けてきたので、ここで一度Cloudflare Workersを公開基盤として使い続ける前提を調べ直した。

Gitからビルドしたdistをエッジへ配信し、別ホストへの退避経路も持つ構成図

※ 記事内の図は内容を整理するために作成した概念図です。Cloudflareなど各社の公式資料や実際の製品画面ではありません。

Cloudflare Workersで静的サイトを配る構成#

今のゆまラボは、Astroで生成したHTML、CSS、画像をdistへ出力し、それをWorkers Static Assetsとして公開する形になっている。

この構成は、2026年9月時点のCloudflareの方針とも合っている。CloudflareのWorkers Best Practicesでは、新しい静的サイト、SPA、フルスタックアプリにはWorkers Static Assetsを使うことを推奨している。Pagesも継続して使えるが、新機能や最適化はWorkersへ重点を置くとしている。

第1回でPagesではなくWorkersを選んだ時点では、将来APIや自動処理を追加しやすいことを重視していた。現在はCloudflare側もWorkersを新規プロジェクトの推奨先としているので、この選択を今から変える理由は特に見つからなかった。

レンタルサーバー代が発生しないのは、CloudflareのFreeプランとWorkers Static Assetsの無料枠を使っているからだ。独自ドメインの費用は別だが、静的ファイルを置くためだけの月額サーバー契約は今の構成では必要ない。

Cloudflare自身は、Freeを単なるお試し版ではなく事業戦略の一部と説明している。大量の無料ユーザーがいることでISPとの直接接続を増やしやすくなり、ネットワークコストを下げられること、幅広い利用から製品改善につながること、有料プランへ移る利用者もいることが理由として挙げられている。無料だから利用者データを販売して成立させている、という説明ではない。

FreeとPro、Workers Paidは別の話#

ここは少し分かりにくかった。

Cloudflareの料金表にあるFreeとProは、CDN、DNS、WAFなどを含むNetwork & CDN側のプラン。Proは年払いなら月20ドル相当、月払いなら25ドルで、より細かなセキュリティやパフォーマンス設定が増える。

Workersには別にWorkers FreeとWorkers Paidがある。Workers Paidはアカウントあたり最低月5ドル。10 million requests/月と30 million CPU ms/月などが含まれ、超過分は従量課金になる。

横にスクロールできます
見るものFree上位プラン
Network & CDN$0/月Pro $20/月相当（年払い）または$25/月
Workers$0Workers Paid 最低$5/月
静的アセットへのリクエスト無料・無制限無料・無制限
Workerコードへのリクエスト100,000/日リクエスト数の上限なし。月10 millionまで基本料金に含む

つまり、アクセスが増えたからCloudflare Proへ上げればWorkersの上限も増える、という関係ではない。Worker側の計算資源やリクエスト枠を増やしたいなら見るべきなのはWorkers Paidになる。

今のゆまラボでProが必要かと言われると、まだ必要性は感じない。CDN、DNS、DDoS対策、Universal SSLはFreeにも含まれている。サイト運用上ほしい機能が明確になってから考えればよさそうだ。

1日10万リクエストの上限がかかる場所#

最初に数字だけ見たときは、Freeだと1日10万PVを超えたらサイトが止まるのかと思った。

これは今の静的構成では違う。

Workers Static Assetsの公式ドキュメントでは、静的アセットへのリクエストは無料かつ無制限と明記されている。10万/日という上限はWorkerスクリプトを実行するリクエスト側の話になる。

静的ファイルへのアクセスとWorkerコードを実行するアクセスで上限の扱いが異なることを示す図

今のように、ビルド済みのHTMLやCSS、画像をそのまま返すだけなら、ページを表示するたびにWorkerの処理時間を消費する構成ではない。

将来ここへ、検索API、認証、AI API連携、SSR、リクエストごとの処理などを追加すると話が変わる。Workerコードを通るリクエストはFreeの100,000/日とCPU 10ms/呼び出しの枠を見る必要がある。run_worker_firstでWorkerを必ず先に通す設定では、Freeの上限を超えた対象リクエストが429になることも公式ドキュメントに書かれている。

ゆまラボで考えるなら、記事本文は静的配信のままにして、必要な機能だけWorkerへ逃がす方が分かりやすい。

記事が増えたときに見る数字#

アクセス数より先に気になっていたのは、記事を大量に作った場合のビルド。

Workers Freeでは、1つのWorkerバージョンに含められるStatic Assetは20,000ファイル。Workers Paidでは100,000ファイルまで増える。1ファイルの上限はどちらも25MiBだ。

ここでいう20,000は「記事20,000本」ではない。Astroが生成するHTML、画像、CSS、JavaScriptなどを含めた実ファイル数なので、記事数だけから上限到達時期を決めることはできない。

ビルド側にも別の制限がある。Workers BuildsのFreeは月3,000分のビルド時間、同時ビルド1、1回のビルドは20分まで。Paidでは月6,000分、同時6、CPUが2 vCPUから4 vCPUへ増える。ただし1回20分のタイムアウト自体はPaidでも同じだ。

そのため、記事が増えてビルドに20分以上かかるようになった場合は、単純に課金するだけでは解決しない。ビルド内容を軽くする、外部CIでビルドして成果物をデプロイする、といった調整が必要になる。

逆に、Static Asset数が20,000へ近づいた段階ならWorkers Paidで100,000まで広げられる。今すぐ将来のページ数を心配して構成を変えるより、distのファイル数とCloudflareのビルド時間を見ながら判断する方が現実的だと思う。

Cloudflareの速度と2025年の大規模障害#

Cloudflareを使う理由として表示速度は分かりやすい。現在のネットワーク紹介では世界348都市に拠点があり、静的ファイルを利用者に近いエッジから返せる。

ただ、国内の高速なレンタルサーバーとCloudflare Workersを一律に比べて「何倍速い」とは書けない。WordPressならテーマ、PHP、DB、キャッシュ構成で大きく変わるし、静的サイトでも画像や外部JavaScript次第で遅くなる。

Workersが大規模用途でも使われている例としてはCanvaやShopifyがある。Canvaはリダイレクトやセキュリティヘッダーなどの処理をWorkersへ移し、ShopifyもWorkersをショッピングカートや決済を含むアプリケーションで利用している。もちろん、これはゆまラボと同じ静的ブログ構成という意味ではない。Workers自体が個人サイト専用の仕組みではないことは分かる。

一方で、Cloudflareなら止まらないとも言えない。

2025年6月12日にはWorkers KVの基盤障害で2時間28分の大規模障害が起きた。Workers Assetsの平均エラー率増加は約0.06%だった一方、Pagesはエラー率が一時ほぼ100%まで上がり、新しいビルドもできなくなった。

11月18日にはCloudflareのコアネットワークで約2時間10分にわたる大きな障害。12月5日にも約25分、Cloudflareが処理するHTTPトラフィックの約28%へ影響する障害が発生している。

Cloudflareはその後Code Orange: Fail Smallという耐障害性改善を進め、2026年5月に一連の作業完了を公表した。2025年11月と12月の障害を防げたはずの対策を実装したとしている。

改善されたことと、今後絶対に止まらないことは別だ。無料か有料かに関係なく、公開先を1社に寄せる以上、このリスクは残る。

distとGitがあれば公開先を変えられる#

ここはAstroを選んでおいてよかった部分。

Astroの標準的な静的ビルドはnpm run buildでdist/へ成果物を出す。Astro公式のデプロイドキュメントでも、ホスティング先へ公開するディレクトリはdistが基本になっている。Hostingerの例では、静的サイトならdist/の中身をファイルマネージャーやFTPでアップロードする手順まで案内されている。

つまり、今のゆまラボが静的サイトのままなら、Cloudflareで何かあった場合にdistを一般的なレンタルサーバーへ置いて公開することはできる。

Cloudflare側で問題が起きた場合にGitとdistから別ホストへ公開できる退避構成図

ただし、バックアップとして本当に大事なのはdistだけではなくGit側のソースだと思う。distはその時点で公開できる完成品なので緊急退避には便利だが、Markdown、設定、コンポーネント、依存関係まで含めて作り直せるのはリポジトリ側になる。

今後WorkersのAPI、KV、D1、SSRなどCloudflare固有の動的機能を増やした場合は、distをコピーするだけでは同じサイトにならない。その時は移行先で同等のバックエンドを用意する必要がある。

当面は静的ページを中心にしておけば、Freeの恩恵をかなり受けられる。記事が増えたらStatic Asset数とビルド時間を確認する。動的処理が増えたらWorkersの10万リクエスト/日を見る。必要になったところだけPaidへ切り替える。

そしてGitとdistから別の公開先へ逃げられる状態は残しておく。

無料で使えることより、この逃げ道を持ったまま運用できる方が自分には大きい。

参考#

連載：Astro＋Cloudflareでサイトを作る