小さなWebツールの公開先を選ぶ：GitHub Pages・Vercel・Firebase Hostingの使い分け

最初に決める3つの問い

公開先の比較は機能一覧から始めると混乱します。先にツールの側の条件を3つ決めます。

1. 静的ファイルだけで足りるか。 入力を画面内で計算して表示するだけなら足ります。ログイン、他サービスのAPIを秘密のキーつきで呼ぶ、データを保存する、といった場合はサーバー側の処理が要ります。
2. 公開前に確認用のURLが要るか。 家族や同僚に「この変更を見て」と送りたいなら、本番と別のURLがあると便利です。自分だけが使うなら要りません。
3. お金が絡むか。 広告、決済、有料の依頼で作るツールかどうかで、無料プランの規約に触れる場合があります。

3サービスの違い(確認できた範囲)

GitHub Pages:静的サイト専用、規約は「商売に使わない」

GitHub Pagesは、GitHubのリポジトリにあるHTML・CSS・JavaScriptを公開する静的サイトのホスティングです(公式:GitHub Pagesとは)。サイトのURLは、ユーザー用が<owner>.github.io、リポジトリごとのプロジェクト用が<owner>.github.io/<リポジトリ名>の形です。

公式の制限のページには、公開サイトは最大1GB、デプロイは10分以内、帯域は月100GBのソフトリミット、ビルドは1時間あたり10回まで(カスタムのGitHub Actionsワークフローを使う場合は対象外)と書かれています。また、オンラインビジネスを動かす無料ホスティングとしての利用、SaaSの提供、パスワードやクレジットカード番号のような機密情報の送受信は用途として認められていません。小さな個人ツールには十分な余裕がありますが、「売るためのツール」には向きません。

GitHub Pagesはリポジトリから静的ファイルを公開するサービスです。今回確認した公式ページでは、ブランチやプルリクエストごとの確認用URL機能は確認できませんでした。

Vercel:確認用URLが標準、無料のHobbyは非商用のみ

Vercelは、本番(Production)とは別に確認用(Preview)の環境を持ちます。本番ブランチ以外へのpushやプルリクエストで、本番に影響しないプレビューのデプロイが自動で作られ、デプロイごとにURLが発行されます。ブランチ単位のURLと、コミット単位のURLの2種類があります(公式:Environments)。Hobbyを含む各プランで、プレビュー環境を使った確認ができます。

サーバー処理はVercel Functionsで書けます。公式のFair Useのページでは、Hobbyの利用枠として、関数の呼び出しは最初の100万回、Fast Data Transferは最初の100GBとされています。

注意点は規約です。同ページによると、Hobbyは非商用の個人利用に限られ、決済の受け付け、商品やサービスの宣伝、制作や運用で報酬を受け取る場合、アフィリエイトが主目的、Google AdSenseなどの広告掲載が商用に当たります。寄付のお願いは商用扱いにならないとも書かれています。判断に迷う場合はVercelのサポートに確認するよう案内されています。

Firebase Hosting:静的もサーバー処理も扱える、Google側と組みやすい

Firebase Hostingは、静的なページやシングルページアプリをCDNで配信するサービスで、Cloud FunctionsやCloud Runと連携して動的なコンテンツも返せます。プレビューチャンネルを使ったテスト用の公開や、GitHubのプルリクエスト経由のデプロイにも対応しています(公式:Firebase Hosting)。

Firebase Hostingの料金や無料枠、Cloud FunctionsやCloud Runを連携するときに必要なプラン・料金は、ここで参照したHostingの説明ページだけでは確認できません。公開前にFirebaseの料金ページと各バックエンドの料金・プラン条件を確認してください。

条件から公開先を絞る比較表

次の表は、上で確認した内容に基づく編集部の整理です。「○」は公式に機能の記述を確認できたもの、「未確認」は今回の調査では確認できなかったものです。

• 静的ファイルだけを公開、GitHub Pages：○、Vercel：○、Firebase Hosting：○
• サーバー側の処理が要る、GitHub Pages：記述なし(静的専用と考える)、Vercel：○(Functions)、Firebase Hosting：○(Cloud Functions/Cloud Run連携)
• 公開前の確認用URL、GitHub Pages：今回は未確認、Vercel：○(Previewを自動生成)、Firebase Hosting：○(プレビューチャンネル)
• 広告・決済・有料依頼のツール、GitHub Pages：規約上、不向き、Vercel：無料のHobbyは不可、有料プランが前提、Firebase Hosting：料金・規約を要確認
• 向いている人、GitHub Pages：計算機、診断、早見表を無料で置きたい、Vercel：変更を確認しながら育てたい、APIを呼びたい、Firebase Hosting：Googleのサービスとまとめて管理したい

AIに公開先を相談する依頼文(説明用の例)

次の依頼文は説明用の例で、実行した結果を載せたものではありません。ツールの条件だけを渡し、公式情報との照合は自分で行います。

次のWebツールの公開先を、GitHub Pages・Vercel・Firebase Hostingから
選ぶための確認項目を作ってください。

【ツールの条件(説明用の例)】
- 内容:文字数と読了時間を計算する画面
- 使う技術:HTML、CSS、JavaScriptのみ
- 外部APIの利用:なし
- データ保存:なし(入力はブラウザ内で処理)
- 公開前の確認URL:友人に1回見せたい
- 収益:なし。広告も付けない
- 管理するのは自分1人

【お願い】
1. 条件ごとに、各サービスで満たせるか「満たす/要確認/満たさない」で表にする
2. 「要確認」の項目は、公式ドキュメントのどのページを見るべきか書く
3. 料金や上限の数値は、あなたの記憶では答えず「公式で確認」と書く
4. 最終的に第一候補と、その理由を3行以内で出す

人が確認するのは次の3点です。AIが数値を断定していないか、「要確認」の項目を公式ページで実際に読んだか、収益化の予定をAIに正直に伝えたか。最後の点は、規約の判断に直結します。

乗り換えやすさのための注意点

どれを選んでも、後で移れるように作っておくと困りません。以下は編集上の提案です。

• ファイルは静的な状態で保つ。 index.htmlと画像、CSS、JSのフォルダだけで動く形にしておけば、3サービスのどれにも置けます。
• リンクは相対パスにする。 GitHub Pagesのプロジェクトサイトは/<リポジトリ名>/という階層の下に置かれるため、/style.cssのようにルートから始まるパスだと読み込めなくなることがあります。./style.cssの形が安全です。
• サーバー処理を別ファイルに切り出す。 呼び出し先のURLを設定用の1か所にまとめ、画面側のコードとは分けておきます。Vercel FunctionsからCloud Functionsに移すときも、書き換えが少なくて済みます。
• 独自ドメインを使う場合は、早めに決める。 公開先を変えても利用者に配るURLが変わらないので、乗り換えの負担が下がります。ドメインの設定手順は各サービスの公式ページで確認してください。
• 秘密のキーを画面側のコードに書かない。 静的ファイルは誰でも読めます。キーが必要なAPIは、サーバー側の処理を経由させてください。AIにコードを書かせる際は、実際のキーではなくダミーの文字列(例:YOUR_API_KEY)を渡します。
• 上限に達したときの動きを知っておく。 Vercelでは、Hobbyの利用上限を超えると、多くの場合その機能を再び使えるまで30日待つ必要があります(公式:Hobbyプラン)。一部の利用枠は停止期間が短く、例外があります。アクセスが急に増えそうなツールは、事前に移行先を決めておくと安心です。

迷ったときの選び方

• 静的なページ、確認用URLは不要、収益化なし → GitHub Pages
• 変更を確認しながら改良したい、サーバー処理がある、個人利用の範囲 → Vercel(Hobby)
• 収益化の予定がある → Vercelなら有料プランが前提。他の2つも規約と料金を読んでから
• Googleのサービスを軸にバックエンドを組む → Firebase Hosting(料金は要確認)

最初は静的な形で作り、必要になった段階でサーバー処理を足すのが、いちばん失敗の少ない順番です。