静的サイトホスティングのプラットフォームを正しく選ぶだけで、年間数万円のコストを節約しながら、高速・安全・メンテナンスが楽なサイトを運用できます。無料枠の品質は年々向上しており、GitHub Pages や Cloudflare Pages はゼロコストで本番環境に耐えうるインフラを提供しています。ただし、多くのチュートリアルが触れない課題が一つあります。サーバーのない静的サイトで、どうやってお問い合わせフォームを動かすか、という問題です。このガイドでは、プラットフォームの選定からお問い合わせフォームの実装まで、具体的な手順と知っておくべき制約を丁寧に解説します。
目次
この記事のポイント:
- GitHub Pages と Cloudflare Pages はどちらもカスタムドメイン対応の無料静的ホスティングを提供しています。
- Cloudflare Pages は CDN エッジネットワークにより世界的に高速です。GitHub Pages は GitHub をすでに使っている開発者にとってシンプルな選択肢です。
- 静的サイトはフォームをネイティブに処理できません。送信内容を受け取ってメールで届けるには、サードパーティのフォームサービスが必要です。
- Sendform のような専用フォームバックエンドを使えば、サーバーサイドのコードを書かずに機能するお問い合わせフォームを追加できます。
無料の静的サイトホスティングが注目される理由
静的ウェブサイトは、あらかじめ生成された HTML・CSS・JavaScript ファイルをブラウザに直接配信します。PHP も Node.js のランタイムも、ページ読み込みのたびに走るデータベースクエリもありません。その単純さこそが、無料の静的ページホスティングが安定している理由です。クラッシュするものも、パッチを当てるものも、スケールさせるものも存在しないのです。
中小企業のサイト、ポートフォリオ、SaaS のランディングページ、ドキュメントサイトなど、さまざまな用途で静的ホスティングは要件を満たします:
- 高速性: ファイルは CDN のエッジノードから配信され、世界中で 100ms 以内の応答が期待できます。
- セキュリティ: サーバーサイドのランタイムがないため、攻撃対象領域が大幅に縮小されます。
- コスト: GitHub Pages も Cloudflare Pages も、公開・多くのプライベートプロジェクトで無料です。
- シンプルさ: リポジトリにコードをプッシュするだけで、サイトが自動的にデプロイされます。
唯一の制約は動的な機能です。ユーザー認証、ショッピングカート、フォーム処理など、サーバーサイドのロジックが必要な処理はすべて外部サービスに委ねる必要があります。セットアップ手順を進める前に、この点を頭に入れておいてください。
プラットフォーム比較: GitHub Pages vs Cloudflare Pages
| 項目 | GitHub Pages | Cloudflare Pages |
|---|---|---|
| 無料枠 | あり (公開リポジトリは常に無料) | あり (サイト数無制限) |
| カスタムドメイン | 対応 | 対応 |
| HTTPS | Let's Encrypt で自動発行 | Cloudflare SSL で自動発行 |
| ビルドパイプライン | GitHub Actions (手動設定) | CI/CD 組み込み済み |
| グローバル CDN | 限定的 (米国中心) | 300 拠点以上のエッジ |
| 帯域制限 | 月約 100GB のソフトリミット | 無制限 |
| プライベートリポジトリ | GitHub Pro が必要 | 無料で対応 |
結論: グローバルなユーザーを対象に最速のロード時間を求めるなら Cloudflare Pages が優位です。チームがすでに GitHub を活用していてシンプルなセットアップを望むなら、GitHub Pages で十分です。
GitHub Pages へのデプロイ手順
ここでは、公開可能なシンプルな HTML/CSS サイトが手元にある前提で説明します。Hugo や Jekyll などの静的サイトジェネレーターを使っている場合も、手順はほぼ同じです。
-
GitHub リポジトリを作成する。 github.com/new にアクセスして公開リポジトリを作成します。ルートドメインで公開したい場合はリポジトリ名を
your-username.github.ioにしてください。サブディレクトリパスで公開する場合は任意の名前で構いません。 -
サイトのファイルをプッシュする。 ローカルのプロジェクトフォルダで以下を実行します:
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 -
GitHub Pages を有効にする。 リポジトリの 設定 > Pages を開きます。「ソース」で
mainブランチと/rootフォルダを選択します (ビルド出力先が別の場合は/docsを選択)。保存をクリックします。 -
デプロイを待つ。 GitHub が 1 - 3 分以内にビルドとデプロイを完了します。Pages 設定パネルに公開 URL (例:
https://your-username.github.io) が表示されます。 -
カスタムドメインを設定する (任意)。 リポジトリのルートにドメイン名 (例:
www.yoursite.com) を記述したCNAMEファイルを追加します。次に DNS プロバイダーで CNAME レコードをyour-username.github.ioに向けるよう設定します。数分以内に GitHub が SSL 証明書を自動発行します。
Cloudflare Pages へのデプロイ手順
- Cloudflare にサインアップまたはログインする。 pages.cloudflare.com にアクセスし、GitHub または GitLab アカウントを連携します。
- 新しいプロジェクトを作成する。 「プロジェクトを作成」をクリックし、「Git に接続」を選択してリポジトリを一覧から選びます。
-
ビルド設定を構成する。 プレーンな HTML サイトの場合はビルドコマンドを空欄にし、出力ディレクトリを
/などindex.htmlが存在する場所に設定します。Hugo の場合はビルドコマンドをhugo、出力をpublicに設定します。Jekyll の場合はjekyll buildを使用し、出力を_siteに設定します。 -
デプロイする。 「保存してデプロイ」をクリックします。Cloudflare がリポジトリをクローンし、ビルドを実行してグローバルエッジネットワークに公開します。すぐに
*.pages.devサブドメインが割り当てられます。 -
カスタムドメインを追加する。 プロジェクトのダッシュボードで「カスタムドメイン」を開き、ドメインを入力します。ドメインがすでに Cloudflare DNS で管理されている場合はワンクリックで完了します。そうでない場合は、ドメインレジストラで
*.pages.devアドレスへの CNAME レコードを追加する必要があります。
メインブランチへの git push のたびに自動再デプロイが実行されます。また、Cloudflare はプルリクエストに対してプレビューデプロイを作成するため、本番公開前に変更内容を確認するのに便利です。
静的サイトにお問い合わせフォームを追加する
多くのガイドが説明を止めるのがここです。静的ウェブサイトのお問い合わせフォームは、サイト自身にデータを送信できません。リクエストを受け付けるサーバーが存在しないためです。現実的な選択肢は三つあります:
- フォームバックエンドサービス (推奨): フォームの
action属性をサードパーティのエンドポイントに向けます。そのエンドポイントが送信を受け取り、バリデーションを行い、メールで転送してくれます。 - サーバーレス関数: Cloudflare Workers や AWS Lambda などでフォームを処理する小さな関数を書く方法です。動作しますが、コードの記述と継続的なメンテナンスが必要です。
- JavaScript の fetch(): ブラウザの fetch API を使ってフォームデータをバックエンドエンドポイントに POST する方法です。技術的な詳細は JavaScript の fetch() で HTML フォームデータを送信する方法 のガイドをご覧ください。
最短で動くフォームを実現するには、専用のフォームサービスを使うのが一番です。以下は Sendform を使った具体的な例です:
具体例: 5 分で動くお問い合わせフォームを作る
サイトにコードを追加する前に、Sendform のアカウントを作成してフォームエンドポイントを用意する必要があります。作業時間は約 2 分です:
- Sendform.net に登録する。 クレジットカード不要で無料アカウントを作成します。登録後すぐにデフォルトのプロジェクトが用意されます。
- フォームを作成する。 ダッシュボードで「新しいフォーム」をクリックし、名前を入力してプロジェクトを選択し、送信内容を受け取りたいメールアドレスを入力します。Sendform はエンドポイントを有効化する前にこのアドレスを確認します。
- エンドポイント URL をコピーする。 フォームが作成されると、
https://sendform.net/!your-form-id形式のユニークなエンドポイント URL が表示されます。これをコピーして HTML に貼り付けます。
エンドポイントが用意できたら、静的サイトに以下の HTML を追加します:
<form action="https://sendform.net/!your-form-id" method="POST">
<label for="name">Your Name</label>
<input type="text" id="name" name="name" required>
<label for="email">Your Email</label>
<input type="email" id="email" name="email" required>
<label for="message">Message</label>
<textarea id="message" name="message" rows="5" required></textarea>
<button type="submit">Send Message</button>
</form>your-form-id の部分を Sendform のダッシュボードに表示される ID に置き換えてください。以降の送信はすべて、セットアップ時に確認したメールアドレスに届きます。バックエンドのコードも、サーバーも、月額のインフラ費用も不要です。送信後のリダイレクトページや確認メールなど、より高度な UX パターンについては 静的サイトのフォームベストプラクティス のガイドをご覧ください。
ウェブサイトビルダーと組み合わせて使う場合は、ウェブサイトビルダーへの Sendform 統合方法 の記事で詳しく解説しています。
スパム対策について: 公開されているフォームにはボットからの送信が集まります。Sendform にはハニーポットフィールドとレート制限が組み込まれています。受信トレイをクリーンに保つ方法については、フォームのスパム対策ベストプラクティス の記事をご覧ください。
よくある失敗と回避策
無料の静的ウェブホスティングのセットアップを支援してきた経験から、最も多くの人がつまずくポイントをまとめました:
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 とインテグレーションをサポートしており、送信内容を Slack、CRM、スプレッドシートへ自動的にルーティングできます。バックエンドコードを書かずに設定する方法は、webhook と API を使ったフォームワークフローの自動化 のガイドで詳しく解説しています。
まとめ
無料の静的ウェブサイトホスティングは、かつてないほど高機能になっています。GitHub Pages は GitHub エコシステムに根ざしたチームに最適で、Cloudflare Pages はより優れたグローバルパフォーマンスと充実した無料枠を提供します。本当の課題はホスティング自体ではなく、特にお問い合わせフォームのような動的な機能への対応です。どちらのプラットフォームも専用のフォームサービスと組み合わせることで、インフラコストゼロで本格的なウェブサイトを構築できます。上記のプラットフォームガイドからサイトを公開し、Sendform でお問い合わせフォームを接続して、初日から確実に送信を受け取れる体制を整えましょう。

静的サイトに数分でお問い合わせフォームを追加する
Sendform を使えば、GitHub Pages や Cloudflare Pages でホストされた静的サイトからフォームの送信を簡単に受け取れます。バックエンドのコードもサーバーの設定も不要です。フォームの action 属性にエンドポイントを指定するだけで完了します。
Sendform.net で無料ではじめる →
よくある質問
ほとんどのビジネス用途では問題ありません。GitHub Pages と Cloudflare Pages はどちらもエンタープライズ級のインフラに支えられた 99.9% 以上の稼働率を誇ります。主な制約はサーバーサイド処理の欠如であり、信頼性ではありません。高トラフィックサイトや EC サイトでは将来的に無料枠を超える可能性がありますが、ランディングページやポートフォリオであれば無料ホスティングは本番環境として十分な品質です。
はい。GitHub Pages と Cloudflare Pages はどちらも無料プランでカスタムドメインに対応しており、SSL 証明書による自動 HTTPS も含まれています。ドメインを所有していれば、DNS レコードをホスティングプラットフォームに向けるだけで設定できます。作業は 15 分以内に完了し、SSL は数時間以内に自動発行されます。
静的サイトはサーバーが動作していないため、フォームの送信をネイティブに処理できません。一般的な解決策は、フォームの action 属性をサードパーティのフォームバックエンドサービスのエンドポイントに向けることです。そのサービスが POST リクエストを受け取り、データをバリデーションして、指定したメールアドレスに転送します。Sendform はそのようなサービスの一つです。登録してフォームを作成するとユニークなエンドポイント URL が発行されるので、HTML フォームの action 属性にその URL を貼り付けるだけで完了します。
GitHub Pages はシンプルで GitHub リポジトリと直接統合されているため、すでに GitHub を使っている開発者に最適です。Cloudflare Pages は 300 拠点以上のエッジを持つ高速なグローバル CDN、無料枠での無制限帯域、プルリクエストのプレビューデプロイ付きの CI/CD を提供します。パフォーマンスを重視するサイトには Cloudflare Pages が有利です。
基本的な HTML の知識があると助かりますが、開発者でなくても大丈夫です。Hugo、Jekyll、またはプレーンな HTML ファイルはどちらのプラットフォームでも問題なく動作します。お問い合わせフォームについては、Sendform が 2 分の登録後にコピー&ペーストするだけの HTML スニペットを提供しているため、どの段階でもサーバーサイドのプログラミング知識は不要です。