Cloudflare Workersで個人サイトを運用するリアルなコスト

個人サイトをCloudflare Workersで運用している。「Cloudflareは無料で使える」というイメージが先行しているけど、実際に運用してみると無料のままでは厳しい場面があった。リアルな数字を記録する。

なぜCloudflare Workersを選んだか

Vercelでも良かったけど、Cloudflare Workersを選んだ理由は3つ。

エッジでの実行速度。日本からのアクセスが大半だけど、Workersはグローバルに300以上のデータセンターで実行される。東京にもデータセンターがあるので、日本からのアクセスはかなり低レイテンシ。TTFBが50ms以下になることも珍しくない。

無料枠の太さ。1日10万リクエストが無料。個人ブログのアクセス数を考えれば十分だと思った。実際、1日のリクエスト数は多い日でも500程度。10万には遠く及ばない。

Cloudflareのエコシステム。DNS、CDN、Workers、R2、D1、Zero Trust。全部がCloudflareのダッシュボード一つで管理できる。AWSみたいに複数のサービスコンソールを行ったり来たりしなくていいのが地味に快適。ドメインのDNSもCloudflareに移管したので、ネームサーバーの設定からCDN、Workers、ストレージまで全部一箇所で見える。

無料枠の実態

Workers Free Planの主な制限はこんな感じ。

項目	制限
リクエスト数	1日10万リクエスト
CPU時間	1リクエストあたり10ms
メモリ	128MB
スクリプトサイズ	1MB
Cronトリガー	5個まで

個人ブログなら1日10万リクエストは余裕で足りる。問題はリクエスト数じゃない。CPU時間の10msが意外と厳しい。

Next.jsのSSRだと、ページによっては10msを超えることがある。特にReact Server Componentsのレンダリングが走るページ。静的生成（SSG）したページをCDNキャッシュから返す分には問題ないけど、キャッシュミスして Workerで処理が走ると、10msの壁が見えてくる。

自分の場合、ブログ記事ページは静的生成しているから大丈夫だったけど、トップページのレンダリングで散発的にCPU時間超過のエラーが出た。Cloudflareのダッシュボードの Analytics で確認すると、1日に数件のエラー。アクセス数が少ないから実害はほぼないけど、気持ち悪い。

有料プランに切り替えた理由

結局、Workers Paid（月$5）に切り替えた。決め手はCPU時間の制限。

静的ページは問題ない。CDNキャッシュが効いている限り、Workerの処理は走らない。けれど、キャッシュが切れたタイミングや、初めてアクセスされるページでは Workerが動く。そこでCPU時間超過のエラーが出ると、ユーザーには500エラーが返る。

月に数回とはいえ、500エラーが出るサイトは嫌だった。

Workers Paidプラン（月$5）に切り替えると、CPU時間が30msに拡大される。リクエスト数も月1,000万まで。スクリプトサイズの上限も10MBに増える。個人サイトには十分すぎるスペック。

切り替え後はCPU時間超過のエラーがゼロになった。月$5で精神的な安心が買えるなら安い。

月額コストの内訳

現在の月額コストを整理する。

項目	月額	備考
Workers Paid	$5.00	基本料金
ドメイン(.dev)	約$1.00	年$12.00を月割り
R2ストレージ	$0.00	無料枠内（10GB）
D1データベース	$0.00	未使用
メール転送	$0.00	Cloudflare Email Routing
合計	約$6.00/月

年間約$72。日本円で約1万1,000円。月に缶コーヒー4本分くらい。

R2は画像ファイルの配信に使っているけど、無料枠の10GBに全然届かない。個人ブログの画像なんて、SVGで作っている分もあって全部合わせても数十MB。D1（SQLiteベースのサーバーレスDB）は今のところ使っていないけど、コメント機能やアクセスカウンターを追加するなら候補になる。

メール転送はCloudflare Email Routingで無料。独自ドメインのメールアドレスをGmailに転送している。これ単体でもCloudflareを使う価値がある。

Vercelとのコスト比較

Vercelの無料枠（Hobby Plan）と比較してみる。

	Cloudflare Workers	Vercel Hobby
月額	$5（Paid Plan）	$0
帯域	無制限	100GB/月
ビルド	ローカル or CI	6,000分/月
エッジ実行	○	○（Edge Functions）
独自ドメイン	○	○

コストだけで見ればVercelの無料枠が勝つ。$0と$5/月の差は、個人開発の規模なら気にならないレベルだけど、「無料」と「有料」の心理的な壁は大きい。

Vercel Hobby Planの帯域制限100GB/月は、個人サイトならまず超えない。仮に1ページ500KBとして、月20万PVでようやく100GB。個人ブログでそこまでのトラフィックが来ることはまずない。ビルド時間の制限6,000分/月も、1回のビルドが1分として6,000回分。毎日200回ビルドしても足りる計算。

じゃあなぜCloudflare Workersを使っているのかというと、コスト以外の部分に価値を感じているから。エッジ実行の学び、Cloudflareエコシステムとの統合、そしてインフラを自分でコントロールしている感覚。Vercelは楽だけど、裏側で何が起きているのかがブラックボックス。Cloudflare Workersは wrangler.jsonc で設定を全部管理できるから、インフラエンジニアとしてはこっちの方が性に合っている。

想定外のコスト：時間

金銭的なコストは安い。月$6。でも想定外だったのは、セットアップと運用にかかる時間的コスト。

Vercelなら「GitHubリポジトリを接続 → フレームワーク選択 → デプロイ」で5分。Cloudflare Workersは、wrangler.jsonc の設定、@opennextjs/cloudflare の導入、Workers互換のためのコード修正、バンドルサイズの最適化。初期セットアップに丸一日かかった。

具体的に時間がかかったポイントはこんな感じ。

• @opennextjs/cloudflare の設定と動作確認: 3時間
• next/og が動かない問題の調査と代替実装: 2時間
• バンドルサイズ超過への対応: 1時間
• wrangler.jsonc の設定試行錯誤: 1時間
• キャッシュ戦略の検討と設定: 1時間

合計8時間くらい。自分の時給を仮に3,000円とすると、24,000円分の作業。月$6のサービスの初期セットアップに24,000円。コスパだけで見たら完全にVercelの方が合理的。

ただ、この8時間で得た知識（Workersのランタイム制限、エッジコンピューティングの特性、バンドルサイズの最適化）は仕事でも活きている。投資と考えれば悪くない。

運用中に気づいたこと

Cloudflare Analyticsが便利

Workers Paid Planに含まれるAnalyticsが意外と使える。リクエスト数、CPU時間、エラー率がリアルタイムで見える。Google Analyticsを入れなくても、サーバーサイドのアクセスログ的な情報はこれで十分。

ただし、クローラーやボットのアクセスもカウントされるので、実際の人間のアクセス数とは乖離がある。自分のサイトだと、Analyticsのリクエスト数の3〜4割はボットっぽい。

R2の無料枠がかなり太い

R2（S3互換のオブジェクトストレージ）の無料枠は、ストレージ10GB、Class Aオペレーション100万回/月、Class Bオペレーション1,000万回/月。個人サイトの画像配信なら余裕で収まる。

S3とAPI互換なので、既存のS3用のツールやライブラリがそのまま使える。aws-cli の --endpoint-url を変えるだけでR2にアクセスできる。

個人サイトにおすすめか

「Cloudflare Workersで個人サイトを運用するのはおすすめか」と聞かれたら、条件付きでおすすめ。

向いている人: Cloudflareのエコシステムに興味がある、エッジコンピューティングを実践的に学びたい、設定やトラブルシューティングを楽しめるエンジニア。インフラ寄りの人には特に良い教材になる。

向いていない人: とにかく早くサイトを公開したい、設定に時間をかけたくない、ブログの執筆に集中したい人。そういう人はVercelかNetlify、あるいはAstro + Cloudflare Pagesの方が幸せになれる。Cloudflare Pagesなら設定の手間がかなり少ない。

自分はインフラエンジニアなので前者に該当する。月$6で学びのある環境が手に入るなら安いもの。

関連記事

• Claude Codeで自分のサイトを作った話。AIとの共同開発のリアル
• Cloudflare Workersにデプロイして詰まったポイントまとめ
• 個人開発でNext.jsを選んだ理由と後悔