Webサイトを無料で公開する：GitHub Pages と Cloudflare の選び方¶

対象 / ポイント

対象: 個人サイト、ブログ、ポートフォリオ、ドキュメント、小規模なランディングページを無料で公開したい人。

ポイント:

手軽さとGitHubとの一体感なら GitHub Pages が扱いやすい
表示速度、帯域、将来の拡張性を重視するなら Cloudflare が向く
CloudflareはPagesとWorkersの統合を進めているため、長期運用ではWorkers前提も見る

静的なブログやポートフォリオなら、無料公開先は GitHub Pages と Cloudflare が有力候補になる。どちらも独自ドメインとHTTPSに対応し、小規模サイトなら料金をかけずに始められる。この記事の問いは、無料ホスティングを手軽さと速度・拡張性のどちらで選ぶかだ。

まず結論：用途で2択になる¶

静的なサイトを出すだけなら、どちらを選んでも無料で公開できる。差が出るのは、公開までの近さ、アクセス増への余裕、後から動的処理を足せるかである。

判断は次の3行で足りる。

とにかく早く出したい、コードがすでにGitHubにある → GitHub Pages
海外アクセスや表示速度を重視する → Cloudflare
フォーム送信、API、認証などを後で足す可能性がある → Cloudflare

迷ったら、まず公開しやすい方で始めればよい。静的サイトはHTML、CSS、画像の束なので、後から移しやすい。ただし、移しやすいからこそ、最初に制限の違いだけは見ておく価値がある。

「公開する」と何が起きるのか¶

公開とは、ローカルで作ったHTMLやCSSのファイル群を、世界中からアクセスできる場所に置くことだ。多くの静的サイトでは、次の流れになる。

ローカルでファイル作成 → Gitでpush → サービス側がビルド → 配信網へ配置 → 訪問者が受信

この「配信網へ配置」の部分がCDNである。 CDNは、訪問者に近い拠点からファイルを返す仕組みだ。 GitHub Pages も Cloudflare も静的ファイルを配れるが、制限と周辺機能の設計が違う。

ここから先は、まずGitHub Pagesの強みを見る。

GitHub Pages：コードと公開がひとつになる¶

GitHub Pagesの強みは、リポジトリと公開先がほぼ一体になることだ。普段のpush操作が、そのまま公開フローになる。

無料・公開リポジトリで使う場合、主な制限は次の通りである¹。

公開サイトの容量は最大1GB
帯域は月100GBのソフト上限
ビルドは1時間あたり10回が目安。GitHub Actionsでビルドすればこの上限は対象外

月100GBは、1ページ1MBなら約10万ページビュー分に相当する。個人ブログや技術ドキュメントには十分だが、動画、配布ファイル、大量画像を置く用途には向かない。 GitHub自身も、商用ECやSaaSを主目的にした無料Webホスティングとしての利用は想定していないと説明している¹。

もう1つの制約は、サーバー側の処理を動かせない点だ。 PHP、常駐API、データベース接続をGitHub Pages上で実行することはできない。静的サイトとして割り切るほど強く、動的処理を足したくなるほど別基盤が必要になる。

その反対側にあるのがCloudflareだ。

Cloudflare：速度と拡張性が持ち味¶

Cloudflareの強みは、静的配信とエッジ実行を同じ基盤で扱えることだ。 Cloudflare Pagesの無料枠では、静的リクエストと帯域が無制限として示されている²。

GitHub Pagesとの差は、次の4点に出る。

世界規模のエッジ網から配信でき、海外アクセスでも低遅延を狙いやすい
静的ファイル配信では帯域上限を気にしにくい
MkDocsやHugoなどのビルドコマンドを指定しやすい
必要になればWorkersでAPIや認証などの動的処理を足せる

ただし、Cloudflareでも制限が消えるわけではない。 Pages無料枠には月500ビルド、1サイト20,000ファイル、1ファイル25MiBといった上限がある³。さらにWorkersで動的処理を動かす場合は、無料枠で1日100,000リクエストなどWorkers側の制限を見る必要がある⁴。

つまり、Cloudflareは「何でも無制限」ではない。静的配信の余裕が大きく、動的処理へ広げる道が用意されている、と捉えるのが正確だ。

2026年の注意点：Pages と Workers は近づいている¶

Cloudflareは、PagesとWorkersを1つの開発体験へ統合していく方針を公式に示している⁵。 2026年時点では、Workers側に静的アセット、API、SSR、より広い機能セットを寄せる流れが見える⁶。

この動きは、今すぐPagesを避ける理由にはならない。純粋な静的サイトなら、Pagesは今も手軽な選択肢だ。一方で、長期運用や動的処理を想定するなら、最初からWorkersの設定ファイルとデプロイ方式を見ておく方が後の移行コストを下げやすい。

ここで比較を一度表に落とす。

比較表¶

観点	GitHub Pages	Cloudflare
向いている用途	小規模な静的サイト、ドキュメント、公開リポジトリ連動	速度重視の静的サイト、非公開リポジトリ連動、将来のAPI追加
帯域	月100GBのソフト上限¹	Pagesは無制限帯域を掲げる²
サイト容量	公開サイト最大1GB¹	Pages無料枠は20,000ファイル、1ファイル25MiB³
ビルド	標準はJekyll寄り。Actionsで自由度を上げられる	任意のビルドコマンドを指定しやすい
プレビューデプロイ	標準の強みではない	プレビューを無制限に保持できる³
サーバーレス処理	不可	Workersで追加可。ただしWorkersの制限は別途確認
非公開リポジトリ	Pro、Team、Enterprise系プランが必要¹	PagesはGitプロジェクトの公開/非公開と独立して管理できる³
今後の方向	安定した静的ホスティング	PagesとWorkersの統合が進行中

表だけを見るとCloudflareが万能に見えるかもしれない。実際には、最小構成で迷わないことも大きな価値である。 GitHub上のREADMEやドキュメントをそのまま公開したいなら、GitHub Pagesの単純さは強い。

どちらを選ぶか¶

GitHub Pagesが向くのは、公開までの摩擦を最小にしたいケースだ。サイトのソースがすでにGitHubにあり、公開リポジトリで問題なく、動的処理を足す予定がなければ十分に実用になる。

具体的には、次のようなサイトだ。

個人ブログやポートフォリオ
OSSプロジェクトのドキュメント
小規模な学習・検証用ページ

Cloudflareが向くのは、表示速度、帯域、将来の拡張を気にするケースだ。非公開リポジトリから公開したい場合や、後からフォーム、API、認証、A/Bテストを足したい場合もCloudflareが設計しやすい。

具体的には、次のようなサイトになる。

海外アクセスを含むブログやメディア
画像やページ数が増えやすい静的サイト
後からWorkersで機能追加したいランディングページ

独自ドメインとHTTPSは、どちらも対応する。ここは決定的な差ではない。差が出るのは、公開後に何を足したくなるかだ。

最小の公開手順¶

MkDocsで作ったサイトをGitHub Pagesへ公開するなら、典型的には次のコマンドで足りる⁷。

mkdocs gh-deploy

Cloudflare PagesでMkDocsを公開する場合は、ダッシュボードでGitHubリポジトリを接続し、ビルド設定に次を入れる⁸。

ビルドコマンド: mkdocs build
出力ディレクトリ: site

どちらも、最初の公開は難しくない。重要なのは、最初の数分ではなく、公開後に何を運用したくなるかである。

まとめ¶

無料の静的ホスティング選びは、永久に変えられない基盤選定ではない。 HTML、CSS、画像、Markdownをきれいに分けておけば、GitHub PagesからCloudflareへも、その逆へも移しやすい。

最初に見るべき基準はシンプルだ。 GitHubに置いたコードをすぐ公開するならGitHub Pages。速度、帯域、非公開リポジトリ、将来の動的処理まで含めるならCloudflare。

長く運用するなら、公開先よりも「サイトを特定サービスに閉じ込めない構成」を先に作る。ビルドコマンド、出力ディレクトリ、独自ドメインを明確にしておけば、無料サービスの制限や方針が変わっても動きやすい。