Cloudflare PagesでのNext.jsデプロイを極める：Edge Runtimeと静的生成の課題を克服する

August 12, 2025 開発ノート Next.js Cloudflare Pages デプロイ Edge Runtime SSG

Next.jsアプリケーションをCloudflare Pagesのようなプラットフォームにデプロイすることは、そのグローバルなEdgeネットワークのおかげで信じられないほどのパフォーマンス上の利点をもたらします。しかし、この強力な環境には、特にEdge RuntimeとNode.js固有のAPIとの相互作用に関して、特定の制約が伴います。この投稿では、一般的な課題とその解決策を探ります。

Edge Runtimeのパラドックス：fsとpathモジュール

Cloudflare Pagesは、動的なルートがEdge Runtimeで実行されることを義務付けることがよくあります。Edge Runtimeは非常に高性能ですが、fs（ファイルシステム）やpathのようなNode.jsの組み込みモジュールをサポートしない軽量な環境です。

問題: あなたのNext.jsアプリケーションは、実行時にファイル（例：Markdownブログ記事）を読み込むためにfsやpathを使用していますが、デプロイプラットフォームはEdge Runtimeを要求します。

初期の誤解: fsを使用するページにexport const runtime = 'edge';を追加しようとすると、ビルドの失敗（Module not found: Can't resolve 'fs'）につながります。逆に、runtime = 'edge'を削除すると、プラットフォームが動的なルートがEdge用に設定されていないと不平を言う可能性があります。

解決策：静的サイト生成（SSG）を採用する このパラドックスを解決する鍵は、Node.js固有のAPIを必要とするすべての操作（ファイルシステムからの読み込みなど）が、実行時ではなく、ビルドプロセス中のみに行われるようにすることです。Next.jsの静的サイト生成（SSG）は、このために設計されています。

• getStaticProps (Pages Router) / サーバーコンポーネントでのデータフェッチ (App Router): これらのメカニズムを使用して、ビルド時にデータをフェッチします（例：Markdownファイルを読み込む）。
• generateStaticParams (App Router): 動的なルート（例：blog/[lang]、blog/[lang]/[slug]）の場合、generateStaticParamsはNext.jsにビルド時にどのパスをプリレンダリングするかを指示します。これにより、ページは完全に静的になり、実行時にfsを必要とせず、Cloudflare Pagesによって提供される出力は、事前に生成されたHTML/JSONとなり、実行時にfsを必要とせずにEdgeネットワークと完全に互換性があります。

冗長な動的APIルートの削除

場合によっては、サーバーサイドのデータフェッチ用に設計された動的APIルート（例：/api/posts/[lang]/[slug]）があるかもしれません。フロントエンドのページが静的に生成され、ビルド時にデータをフェッチするようになった場合、これらの動的APIルートは冗長になる可能性があります。

問題: 不要な動的APIルートが静的またはEdge互換にできない。

解決策: APIルートが不要になった場合（例：その機能がSSGに置き換えられた場合）、削除することを検討してください。これにより、アプリケーションが簡素化され、プラットフォームの制約との潜在的なビルドの競合が解消されます。

By strategically leveraging Next.js's SSG capabilities and understanding the nuances of Edge Runtime, you can successfully deploy robust applications on Cloudflare Pages, delivering content efficiently to users worldwide.