GitHub Pages・Cloudflare Pages・Netlify・Vercelの選び方

4つのサービスは何が違うのか

記事情報: 2026年4月19日初出。本文の機能・制約は2026年7月25日に公式資料で再確認しています。

GitHub Pages、Cloudflare Pages、Netlify、Vercelはいずれも、Gitリポジトリやビルド済みファイルからWebサイトを公開できます。

選び方の短い答えは、静的ファイルだけか、プレビューが必要か、サーバー側の処理を使うか、利用するフレームワークとの統合を優先するかを先に決め、その条件に合うサービスを選ぶことです。

ただし、得意な用途は同じではありません。GitHub Pagesは静的ファイルの公開が中心です。残りの3つは、静的ファイルに加えてサーバー側の処理やフレームワーク連携を提供します。

料金、無料枠、ビルド上限は頻繁に変更されます。この記事では性能順位を置かず、2026年7月25日に確認した公式ドキュメントを基に、選定軸を整理します。契約前には必ず各サービスのPricingとLimitsを確認してください。

最初に確認する比較表

「対応」と書かれていても、利用できるruntime API、実行時間、リージョン、料金は同じではありません。

GitHub Pages

GitHub Pagesは、GitHubリポジトリから静的サイトを公開する機能です。HTML・CSS・JavaScriptで作ったサイト、静的サイトジェネレーターの出力、プロジェクトドキュメントに向いています。

GitHub Pagesが向いている用途

• 学習用ポートフォリオ
• OSSのドキュメント
• 静的なブログや説明ページ
• GitHub Actionsでビルドできるサイト

GitHub Pagesの注意点

GitHub Pages自体はサーバーサイドのJavaScriptやデータベース処理を実行しません。ログイン、決済、秘密情報を使うAPIが必要なら、別のバックエンドを用意します。

GitHub公式は、Pagesをオンラインビジネス、EC、SaaSを動かす無料ホスティングとして利用することや、パスワード・カード番号を扱う機密性の高い取引に使うことを制限しています。商用サイトでは機能だけでなく利用規約を確認してください。

公開方法やprivate repositoryの利用可否はGitHubプランで異なります。

Cloudflare Pages

Cloudflare Pagesは、静的アセットの配信に加え、Pages Functionsを通してCloudflare Workersの実行環境を利用できます。KV、D1、R2などCloudflareのサービスと組み合わせる構成を検討できます。

Cloudflare Pagesが向いている用途

• Astro、Hugoなどで生成した静的サイト
• Cloudflare Workersを使うAPI
• D1やKVと連携するサイト
• branchごとのpreviewを確認したいチーム

Cloudflare Pagesの注意点

Pages FunctionsのリクエストはWorkersの利用枠や制約に関係します。静的ファイルの上限、build時間、build回数、FunctionsのCPU時間を別々に確認してください。

Cloudflare Pagesでは、Git integrationとDirect Uploadで運用方法が異なります。既存プロジェクトの接続方法を後から変更する場合の制約も、Known issuesで確認します。

Netlify

Netlifyは、Git連携によるbuild・deploy、Deploy Preview、Functions、Edge Functions、redirect・header設定などをまとめて提供します。

Netlifyが向いている用途

• Pull Requestごとにpreviewを共有する
• 静的サイトと小さなFunctionsを同じプロジェクトで管理する
• redirect、header、フォームなど配信周辺の機能を使う
• 複数の静的サイトジェネレーターを運用する

Netlifyの注意点

プランや課金体系は変更されることがあります。サイト数だけでなく、build、帯域、Functions、画像処理、チームメンバーなど、実際に使う単位をPricingで確認します。

Netlify固有の機能へ強く依存すると、別サービスへ移行するときに設定を書き換える必要があります。redirectやFunctionsの仕様をリポジトリ内に記録しておくと移行しやすくなります。

Vercel

Vercelは、フロントエンドフレームワーク向けのdeploy基盤です。特にNext.jsとの統合が深く、Preview Deployment、Functions、画像最適化、キャッシュなどを組み合わせられます。

Vercelが向いている用途

• Next.jsの機能を公式に近い構成で利用する
• Pull Requestごとにpreviewを共有する
• 静的ページとサーバーレンダリングを混在させる
• frameworkのbuild設定を小さく始めたい

Vercelの注意点

Next.jsのすべての機能がVercelでしか動かないわけではありませんが、別環境ではadapterやruntime制約を確認する必要があります。

Functionsの実行、転送量、画像最適化、buildなどは別々の利用量として扱われる場合があります。月額だけで判断せず、自分のアクセスパターンに対応する項目を確認してください。

選定手順

1. 静的ファイルだけか

HTML・CSS・画像だけを配信し、サーバー処理が不要なら4サービスすべてが候補です。構成を最も単純にしたい場合、GitHub Pagesも有力です。

2. サーバー側処理が必要か

問い合わせフォーム、認証、DB、秘密鍵を使うAPIが必要なら、Functionsか別バックエンドが必要です。実行環境がNode.js互換か、Web Standards中心かも確認します。

3. フレームワーク固有機能を使うか

Next.jsのServer Components、ISR、画像最適化などを使う場合、対象サービスのサポート範囲を確認します。Astro、Nuxt、SvelteKitもadapterによって利用できる機能が変わります。

4. Previewが必要か

個人の小さなサイトでは本番deployだけでも運用できます。チームでレビューするなら、Pull RequestごとのURL、アクセス制限、preview用環境変数が重要です。

5. 上限と規約を確認する

次の項目を公式ページで確認します。

• 商用利用と禁止用途
• 転送量・リクエスト数
• build回数・同時build数・timeout
• ファイル数と1ファイルの最大サイズ
• FunctionsのCPU時間・メモリ・実行地域
• チームメンバーと権限
• ログ保持期間
• 独自ドメインと証明書

小さく比較する

候補を2つまで絞ったら、同じサイトをdeployして確認します。

1. production buildが成功する
2. preview URLを作成できる
3. custom domainとHTTPSを設定できる
4. 404、redirect、response headerが正しい
5. 環境変数がpreviewとproductionで分離される
6. ログからエラーを調査できる
7. 想定アクセス量で料金項目を説明できる

TTFBなど1つの測定値だけで順位を決めないでください。利用者の地域、キャッシュ状態、ページサイズ、外部APIによって結果が変わります。

よくある選び方

• GitHub上の作品・ドキュメントを静的公開する：GitHub Pages
• Cloudflare Workers、D1、KVと組み合わせる：Cloudflare Pages
• Deploy Previewと配信周辺機能をまとめて使う：Netlify
• Next.js中心のWebアプリを運用する：Vercel

これは出発点であり、絶対的な正解ではありません。必要な機能が少ないほど、特定サービスへの依存も小さくできます。

まとめ

静的・動的の違いが曖昧なら静的サイトと動的サイトの違いを先に確認してください。VercelでNext.jsを公開する具体的な操作はVercelデプロイ入門、公開と利用者への提供開始の違いはリリースとデプロイの違いで整理できます。

• 4サービスとも静的サイトを公開できる
• GitHub Pagesは静的配信が中心
• Cloudflare Pages、Netlify、Vercelはサーバー側処理も扱える
• 価格・上限・対応機能は変更されるため公式情報を確認する
• 性能順位ではなく、必要なruntime、preview、運用機能から選ぶ

参考リソース

• GitHub Pages Documentation
• GitHub Pages limits
• Cloudflare Pages Documentation
• Cloudflare Pages limits
• Netlify Documentation
• Netlify Pricing
• Vercel Documentation
• Vercel Pricing

×

PR

×

PR