2026年にGitHub Pages・Cloudflare Pagesと問い合わせフォームで静的サイトを無料でホストする方法

2026年現在、静的サイトホスティングの無料プランは大幅に充実しており、GitHub PagesやCloudflare Pagesのようなプラットフォームはゼロコストで本番環境に耐えうるインフラを提供しています。適切なプラットフォームを選ぶだけで、年間数万円のコストを削減しながら、高速で安全、かつ管理しやすいサイトを運営できます。ただし、多くのチュートリアルが触れていない重要な課題があります。サーバーのない静的サイトで、コンタクトフォームをどう動かすか、という問題です。このガイドでは、プラットフォームの選定からコンタクトフォームの実装まで、具体的な手順と実際の制限事項を丁寧に解説します。

無料静的ホスティングが注目される理由

静的ウェブサイトは、あらかじめビルドされたHTML、CSS、JavaScriptファイルをブラウザに直接配信します。PHPもNode.jsのランタイムも不要で、ページ読み込みのたびにデータベースクエリが走ることもありません。この仕組みのシンプルさこそが、無料の静的ページホスティングが高い信頼性を誇る理由です。クラッシュする要素も、パッチを当てる対象も、スケールを考える必要もありません。

中小企業のサイト、ポートフォリオ、SaaSのランディングページ、ドキュメントサイトなど、静的ホスティングはあらゆる要件を満たします:

• 表示速度: CDNエッジノードからファイルが配信されるため、世界中で100ms以下の応答も珍しくありません。
• セキュリティ: サーバーサイドのランタイムがないため、攻撃対象領域が大幅に小さくなります。
• コスト: GitHub PagesもCloudflare Pagesも、パブリックおよび多くのプライベートプロジェクトで無料です。
• 手軽さ: リポジトリにコードをプッシュするだけで自動的にデプロイされます。

唯一の制約は動的な機能です。ユーザー認証、ショッピングカート、フォーム処理など、サーバーサイドのロジックが必要な機能は外部サービスに頼る必要があります。セットアップ手順を進める前に、この点を頭に入れておきましょう。

プラットフォーム比較: GitHub Pages vs Cloudflare Pages

結論: グローバルなユーザーを対象に最速の表示速度を求めるならCloudflare Pagesが優位です。チームがすでにGitHubを日常的に使っており、最もシンプルな構成を望むならGitHub Pagesで十分です。

GitHub Pagesでデプロイする手順

ここでは、シンプルなHTML/CSSサイトを公開する手順を説明します。HugoやJekyllなどの静的サイトジェネレーターを使っている場合も、手順はほぼ同じです。

1. GitHubリポジトリを作成します。 github.com/new にアクセスし、パブリックリポジトリを作成します。ルートドメインで公開したい場合はリポジトリ名を your-username.github.io にします。サブディレクトリパスで公開する場合は任意の名前でかまいません。
2. サイトのファイルをプッシュします。 ローカルのプロジェクトフォルダで以下を実行します:
   コピー

   git init
   git remote add origin https://github.com/your-username/your-repo.git
   git add .
   git commit -m "Initial deploy"
   git push -u origin main

3. GitHub Pagesを有効にします。 リポジトリの 設定 > Pages を開きます。「ソース」で main ブランチと /root フォルダ (ビルド出力が /docs の場合はそちら) を選択し、保存します。
4. デプロイ完了を待ちます。 GitHubは1〜3分以内にビルドしてデプロイします。Pages設定パネルに公開URL (例: https://your-username.github.io) が表示されます。
5. カスタムドメインを設定します (任意)。 リポジトリのルートにドメイン名 (例: www.yoursite.com) を記載した CNAME ファイルを追加します。次に、DNSプロバイダーでCNAMEレコードを your-username.github.io に向けるよう設定します。GitHubが数分以内に自動でSSL証明書を発行します。

Cloudflare Pagesでデプロイする手順

1. Cloudflareにサインアップまたはログインします。 pages.cloudflare.com にアクセスし、GitHubまたはGitLabアカウントと連携します。
2. 新しいプロジェクトを作成します。 「プロジェクトを作成」をクリックし、「Gitに接続」を選択します。一覧からリポジトリを選びます。
3. ビルド設定を構成します。 プレーンなHTMLサイトの場合、ビルドコマンドは空白のままにし、出力ディレクトリを / または index.html が存在する場所に設定します。Hugoの場合はビルドコマンドを hugo、出力を public に設定します。Jekyllの場合は jekyll build を使い、出力は _site です。
4. デプロイします。 「保存してデプロイ」をクリックします。Cloudflareがリポジトリをクローンし、ビルドを実行してグローバルエッジネットワークに公開します。すぐに *.pages.dev のサブドメインが割り当てられます。
5. カスタムドメインを追加します。 プロジェクトのダッシュボードで「カスタムドメイン」を開き、ドメインを入力します。ドメインがすでにCloudflare DNSで管理されている場合はワンクリックで設定完了です。そうでない場合は、ドメインレジストラでCNAMEレコードを *.pages.dev のアドレスに向ける設定が必要です。

以降は、メインブランチへの git push のたびに自動的に再デプロイされます。また、Cloudflare Pagesはプルリクエストに対してプレビューデプロイを自動生成するため、本番公開前に変更内容を確認するのに便利です。

静的サイトにコンタクトフォームを追加する

多くのガイドが触れずに終わる、そして多くの人がつまずくポイントがここです。静的ウェブサイトのコンタクトフォームは、自分自身にデータを送信することができません。リクエストを受け取るサーバーが存在しないためです。現実的な選択肢は3つあります:

• フォームバックエンドサービス (推奨): フォームの action 属性をサードパーティのエンドポイントに向けます。そのサービスが送信を受け取り、バリデーションを行い、メールで通知します。
• サーバーレス関数: Cloudflare WorkersやAWS Lambdaなどを使って小さな関数を記述し、フォームを処理します。動作しますが、コードの記述と継続的なメンテナンスが必要です。
• JavaScript の fetch(): ブラウザのfetch APIを使ってフォームデータをバックエンドのエンドポイントにPOSTします。技術的な詳細はJavaScriptのfetch()でHTMLフォームデータを送信する方法のガイドをご覧ください。

最も手軽にフォームを動かす方法は、専用のフォームサービスを使うことです。Sendformを使った具体的な例を紹介します:

具体例: 5分で動くコンタクトフォームを作る

GitHub Pagesにデプロイしたポートフォリオサイトがあり、訪問者からメッセージを受け取って自分の受信トレイに届けたいとします。以下が完全なHTMLコードです:

<form action="https://sendform.io/f/YOUR_FORM_ID" method="POST">
  <label for="name">お名前</label>
  <input type="text" id="name" name="name" required>

  <label for="email">メールアドレス</label>
  <input type="email" id="email" name="email" required>

  <label for="message">メッセージ</label>
  <textarea id="message" name="message" rows="5" required></textarea>

  <button type="submit">送信する</button>
</form>

連携に必要なのはこれだけです。YOUR_FORM_ID をSendformのダッシュボードで確認したIDに置き換えれば、送信のたびに登録したメールアドレスに通知が届きます。バックエンドのコードもサーバーも月額インフラ費用も不要です。送信後のリダイレクトページや確認メールなど、より高度なUXパターンについては静的サイトフォームのベストプラクティスをご覧ください。

ウェブサイトビルダーと静的サイトを組み合わせて使っている場合は、SendformをウェブサイトビルダーにIntegrateする方法の記事でも詳しく解説しています。

よくある失敗と対策

多くのユーザーの無料静的ウェブホスティング設定をサポートしてきた経験から、特に多いトラブルを紹介します:

1. 404ページを用意していない

GitHub PagesもCloudflare Pagesも、存在しないルートにアクセスされると汎用のエラーページを表示します。ルートディレクトリにカスタムの 404.html ファイルを作成しましょう。ユーザーをサイト内に留め、ブランド体験を守ることができます。

2. シークレット情報をパブリックリポジトリにコミットしてしまう

APIキー、フォームエンドポイントのシークレット、メールアドレスをパブリックなGitHubリポジトリに含めてはいけません。Cloudflare Pagesの環境変数を使うか、.gitignore に登録したプライベートな設定ファイルを参照するようにしましょう。

3. バックエンドの方針を決めずにフォームを作る

最も多い失敗パターンです。美しいコンタクトフォームを作り上げてGitHub Pagesにプッシュしたものの、公開当日にフォームが何も反応しないことに気づく、というケースが後を絶ちません。最初の <input> タグを書く前に、フォームバックエンドの方針を決めておきましょう。Sendformのようなツールを使えば、コードなしでメールに直接届くコンタクトフォームを設定できるため、バックエンドの問題を根本から解消できます。

4. ビルドキャッシュの問題を見落とす

プッシュ後にサイトが更新されない場合、CDNキャッシュが古いファイルを配信している可能性があります。Cloudflare Pagesはデプロイ時にキャッシュを自動でパージします。GitHub Pagesは変更の反映が遅いことがあります。最大10分ほど待つか、テスト中はアセットURLにクエリ文字列を付加してキャッシュを回避しましょう。

5. 相対パスの設定を誤る

GitHub Pagesのサイトが username.github.io/project-name/ (サブディレクトリ) に配置されている場合、すべてのアセットパスにそのプレフィックスを考慮する必要があります。/styles.css へのリンクは機能しません。相対パス (./styles.css) を使うか、静的サイトジェネレーターの baseURL 設定をサブディレクトリに合わせて構成しましょう。

6. フォームワークフローの自動化を後回しにする

フォームで送信データを収集できるようになったら、メールを受け取るだけにとどまる必要はありません。SendformはWebhookとIntegrationをサポートしており、送信データをSlack、CRM、スプレッドシートに自動でルーティングできます。WebhookとAPIを使ったフォームワークフローの自動化のガイドで、バックエンドコードなしに設定する方法を詳しく解説しています。

まとめ

無料の静的ウェブサイトホスティングは、これまでになく高機能になっています。GitHubエコシステムにどっぷり浸かっているチームにはGitHub Pagesが適しており、グローバルなパフォーマンスと充実した無料プランを求めるならCloudflare Pagesが優位です。本当の課題はホスティング自体ではなく、特にコンタクトフォームをはじめとする動的機能の実装にあります。どちらのプラットフォームでも、専用のフォームサービスと組み合わせることで、インフラコストゼロの本格的なウェブサイトを構築できます。上記のプラットフォームガイドを参考にサイトを公開し、Sendformでコンタクトフォームを設定して、初日から確実に送信を受け取れる環境を整えましょう。

静的サイトにコンタクトフォームを数分で追加

Sendformを使えば、GitHub PagesやCloudflare Pagesでホストされた静的サイトからフォーム送信を簡単に収集できます。バックエンドのコードもサーバー設定も不要です。フォームの action 属性をエンドポイントに向けるだけで完了します。

Sendform.netで無料ではじめる →

よくある質問