Cloudflare Workers と Pages、
何が違う?

あれ、Pagesで作ろうとしたのにWorkersを選ばされる

Cloudflareのダッシュボードを開いて、「サイトを公開したいだけなのに」と思いながらプロジェクトを作ろうとすると、なぜか「Workers」を勧められることがあります。

「前はPagesでできたのに、なんで?」って思いますよね。

これ、ちゃんと理由があります。

ざっくり言うと、こういう違いです。

一言でまとめると、Pagesは「サイトを置く場所」、Workersは「プログラムを動かす場所」です。

ただし、実はこの2つの裏側は同じCloudflareのエッジネットワークで動いています。違うのは「入り口」と「管理方法」だけ。性能や速度に差はありません。

じゃあなぜWorkersを選ばされるのか

Next.jsやNuxt.jsのような「フルスタックフレームワーク」（画面表示だけでなく、裏側のデータ処理まで1つのプロジェクトで作れる仕組み）を使ってアプリを作ると、サーバーサイドの処理が発生します。

サーバーサイド処理とは、ページを表示する前にデータベースからデータを取ってきたり、AIを呼び出したり、ログイン状態をチェックしたりする処理のことです。これは閲覧者のブラウザではなく、Cloudflare側のサーバーで実行されます。

この「サーバーサイド処理」は、Pagesだけでは動かせません。Workersが必要になります。

Cloudflare自身も2025年頃からNext.jsのデプロイ先としてWorkersを公式に推奨するようになりました。OpenNextというNext.jsのアダプタも、Workers専用で作られています。

つまり、「Webアプリを作る = Workers一択」という流れになってきています。

ここからは実体験です。

社長の業務システムを開発していて、AI診断、事業計画書の自動生成、案件管理、顧客管理、監査ログと機能を追加していったら、ある日こんなエラーが出ました。

Workers無料プランのサイズ上限は3MB（gzip圧縮後）。アプリは3.1MBで、たった200KBオーバー。

「じゃあPagesに切り替えれば25MBまでいけるのでは?」と思いました。

結論から言うと、それは無理でした。

Pagesに切り替えても解決しない理由

Pagesの「25MB」は静的ファイル（HTML、CSS、画像など）のサイズ上限です。サーバーサイドの処理（APIや、アクセスのたびにページを動的に生成する仕組み）は、Pages上でも結局Workersとして動きます。つまり、サーバー処理部分には同じ3MBの制限がかかります。

しかも、OpenNext（Next.jsをCloudflareで動かすアダプタ）はWorkers専用で、Pages向けのデプロイパスを用意していません。

八方塞がりでした。

結局、一番シンプルで確実な方法はこれでした。

Cloudflareのダッシュボードから「Workers Paid」プランに切り替える。月額$5。これだけでサイズ上限が3MB → 10MBに上がります。

「$5/月で追加料金がかからないか?」と心配になると思うので、計算してみました。

月間1,000万リクエストは、1日あたり約33万回に相当します。仮にスタッフ100人が毎日100回操作しても1日1万回、月30万回。無料枠の3%しか使いません。

ちなみに、コードを最適化して不要なライブラリを削ってサイズを100KB程度は削減しましたが、それでも3MBは超えていました。フルスタックのアプリでは、フレームワーク本体だけで1MB近くあるので、機能を削るにも限界があります。

迷ったら、このフローチャートで判断してください。

具体的に言うと:

前回「Pages簡単だよ」とお伝えしましたが、アプリを本格的に作り込んでいくと、こういう壁にぶつかることもあります。でも$5/月で解決できるので、そんなに怖がる必要はないです。