GitHub Pages で自作ツールを無料公開する手順｜サーバー不要で URL 共有

はじめに

前回の記事『自作ツールを GitHub で公開する手順』では、自作の Web ツールを GitHub のリポジトリで公開し、ZIP でダウンロードして使ってもらう形を整えました。ただ、この配布方法には「相手にダウンロードと展開の一手間をかけさせる」という小さなハードルが残ります。ちょっと試してほしいだけの相手に「ZIP を落として、展開して、HTML を開いてください」と説明するのは、意外と面倒なものです。

この続編では、GitHub Pages を使って、リポジトリ内の HTML ツールをそのまま Web ページとして公開し、URL を渡すだけで使ってもらえる形にする手順を扱います。追加費用は不要で、サーバーの構築も要りません。前回と同じく、筆者が実際に自作ツールを公開した作業を例に、スクリーンショットを交えて整理します。すでに GitHub のリポジトリにファイルを置いてある状態を前提とするため、アカウント作成やアップロードの手順は前回の記事を参照してください。

結論を先に述べると、すでにリポジトリがあれば、GitHub Pages の有効化は Settings で数クリック、数分で完了します。技術的なハードルはほぼありません。その分、判断として重要なのは公開範囲の理解です。GitHub Pages のサイトは全世界に公開され、アクセス制限はかけられません。「URL を知っている人だけが見られる」わけではないことを理解した上で、公開してよい内容かを確認することが、この手順で唯一かつ最大の注意点です。

GitHub Pages とは（仕組みと無料枠）

手順の前に、GitHub Pages がどういうサービスで、無料でどこまで使えるのかを整理します。

リポジトリのファイルをそのまま Web 公開する仕組み

GitHub Pages は、GitHub が提供する静的サイトのホスティング機能です。リポジトリに置いた HTML・CSS・JavaScript のファイルを、そのまま Web サイトとして配信します。リポジトリが「ファイル置き場」だとすれば、GitHub Pages はその置き場に「Web サーバーの看板」を掛ける機能と言えます。

重要なのは、公開の元になるのがリポジトリそのものだという点です。別の場所にファイルをコピーしたり、デプロイ作業を行ったりする必要はなく、リポジトリのファイルを更新（コミット）すれば、公開ページにも自動的に反映されます。配布物と公開ページが常に一致するため、「配っているファイルと Web 版でバージョンが違う」という管理の悩みが発生しません。

料金と利用条件（無料プランでの利用可否）

GitHub Pages は、無料プラン（GitHub Free）の個人アカウントでも利用できます。ただし条件があり、無料プランで GitHub Pages を使えるのは Public リポジトリのみです。Private リポジトリのまま Pages を使うには有料プラン（GitHub Pro 等）が必要になります。

参考: GitHub Docs（GitHub Pages limits）
“GitHub Pages is available in public repositories with GitHub Free”
（GitHub Pages は、GitHub Free ではパブリックリポジトリで利用できる）
https://docs.github.com/en/pages/getting-started-with-github-pages/github-pages-limits

前回の記事の流れで OSS としてツールを公開している場合、リポジトリはすでに Public のはずなので、追加費用なしでそのまま Pages を有効化できます。

利用にはいくつかの制限（クォータ）もあります。公開サイトのサイズは 1 GB まで、転送量は月 100 GB まで、ビルド（公開処理）は 1 時間に 10 回までがソフトリミットとして定められています。数字だけ見ると小さく感じるかもしれませんが、単一 HTML のツールはファイルサイズが数十 KB 程度であり、個人ツールの公開でこれらの上限に触れることは、現実的にはまず考えられません。

なお、利用規約上の制限として、EC サイトや SaaS のような商用サービスの運営を主目的とした利用は認められていません。また、パスワードやクレジットカード番号を扱うような機微な処理にも使うべきではないとされています。自作ツールの無償公開はこれらに該当しませんが、用途を広げる際には頭に入れておきたい条件です。

向いているもの・向かないもの

GitHub Pages は静的コンテンツ専用です。この特性から、向き・不向きがはっきり分かれます。

向いているのは、ブラウザ内で処理が完結するものです。HTML・CSS・JavaScript だけで動く計算ツール、チートシートやドキュメント、ポートフォリオページなどが典型です。計算ロジックがすべてクライアントサイドの JavaScript で書かれているツールであれば、そのまま公開できます。

向かないのは、サーバー側の処理が必要なものです。PHP や Python などのサーバーサイドコードは実行されず、データベースへの接続もできません。たとえば WordPress のショートコードとして PHP で実装したツールをそのまま置いても動作しないため、公開するのは PHP を含まないスタンドアロン版（HTML 単体で動く形）である必要があります。ユーザーの入力を保存する、ログインさせるといった機能が必要なツールも対象外です。

この「静的限定」は制約であると同時に、運用の軽さでもあります。サーバーがないということは、脆弱性対応・アップデート・監視といったサーバー運用の負担が一切ないということです。個人の自作ツールを長く公開し続ける形としては、むしろ理にかなった選択と言えます。

公開前に確認すべきこと

有効化の操作自体は数クリックですが、その前に確認しておきたいことが 3 つあります。いずれも「後から気づくと面倒」な性質のものなので、先に整理します。

全世界公開が前提であること（アクセス制限は不可）

最も重要な確認です。GitHub Pages で公開したサイトは、インターネット上の誰でもアクセスできます。個人アカウントの GitHub Pages には、パスワード保護や IP 制限のようなアクセス制御の機能はありません。「URL を教えた人だけが見られる」わけではなく、URL は推測・検索も可能な公開情報になると考えるべきです。

参考: GitHub Docs（Creating a GitHub Pages site with Jekyll）
“GitHub Pages sites are publicly available on the internet”
（GitHub Pages のサイトはインターネット上で一般公開される）
https://docs.github.com/en/pages/setting-up-a-github-pages-site-with-jekyll/creating-a-github-pages-site-with-jekyll

限定した相手だけに使わせたい事情がある場合、GitHub Pages は適さない選択です。逆に、前回の記事の流れで「OSS として誰でも使える形」を目指しているのであれば、この特性はそのまま望んだ動作になります。

公開してよいファイル構成かの再確認

Pages を有効化すると、公開対象のブランチに含まれるファイルが Web からアクセス可能になります。リポジトリとしては公開済みでも、「Web ページとして誰でも開ける」状態になると、閲覧のハードルが一段下がります。前回の記事で整理した「外すべきもの」（広告コード・API キー・個人情報・環境依存の情報）が残っていないか、有効化の前にもう一度だけ確認しておくと安心です。

特に見落としやすいのが、ツール本体以外のファイルです。メモ書きの memo.txt や検証用の中間ファイルをリポジトリに置いたままにしていると、それらも URL/memo.txt の形でアクセスできてしまいます。公開ブランチには「配布物として見られてよいファイルだけ」を置く状態にしておきます。

URL の形式を知っておく

公開後の URL は次の形式になります。

https://ユーザー名.github.io/リポジトリ名/

たとえばユーザー名が example-user、リポジトリ名が mtu-mss-calculator なら、https://example-user.github.io/mtu-mss-calculator/ が公開 URL です。この URL でアクセスすると、リポジトリ直下の index.html が表示されます。ファイル名が index.html 以外の場合は、https://ユーザー名.github.io/リポジトリ名/ファイル名.html のようにファイル名まで指定する必要があります。URL を短くシンプルにしたい場合は、ツール本体のファイル名を index.html に変更（リネーム）しておくのがおすすめです。この点は、後述のつまずきポイント（404）にも関わります。

なお、ユーザー名がそのまま URL に含まれるため、匿名運用でユーザー名を設計した意味がここでも活きてきます。

GitHub Pages の有効化手順

準備の確認が済んだら、有効化の操作に入ります。所要時間は反映待ちを含めても 10 分程度です。ここでは筆者の自作ツール（MTU/MSS 計算ツール）のスタンドアロン版を例に進めます。なお、画面のデザインや文言は変更される場合があります（本記事のキャプチャは 2026 年 7 月時点のものです）

Settings → Pages での設定

対象リポジトリのページ上部にある「Settings」タブを開き、左サイドバーの「Code and automation」セクションから「Pages」を選びます。

「Build and deployment」の「Source」で「Deploy from a branch」を選択します。これは「指定したブランチの内容をそのまま公開する」という最もシンプルな公開方式で、ビルド処理を挟まない単一 HTML のツール公開にはこの方式で十分です。

ブランチの選択と保存

「Branch」のプルダウンで公開するブランチを選びます。ブラウザ操作だけでファイルをアップロードしてきた場合、ブランチは main の 1 つだけのはずなので、main を選択します。フォルダは既定の「/ (root)」のままで問題ありません。「Save」を押すと、公開処理が始まります。

操作としてはこれで完了です。サーバーの契約も、DNS の設定も、デプロイスクリプトも必要ありません。

公開 URL の確認と反映待ち時間

Save の後、同じ Pages 設定画面の上部に「Your site is live at https://ユーザー名.github.io/リポジトリ名/」という表示と「Visit site」ボタンが現れます。これが公開完了のサインです。

反映には少し時間がかかります。公式ドキュメントでは、変更が公開されるまで最大 10 分程度かかる場合があるとされています。Save 直後に URL を開いて 404 が表示されても、まずは数分待ってから再読み込みしてみてください。表示された URL にアクセスし、ツールが動作すれば公開作業は完了です。

公開後は、この URL を README にも記載しておくことをおすすめします。リポジトリを訪れた人が「ダウンロードせずにブラウザで試す」という選択肢を持てるようになり、ツールを触ってもらうハードルがさらに下がります。README には、ツールの計算根拠を解説した記事へのリンクなど、関連情報への導線もあわせて置いておくと、訪問者が背景まで理解しやすくなります。

公開後の確認と運用

公開できたら、表示の確認と、日々の更新・停止の流れを押さえておきます。GitHub Pages の運用は「リポジトリを更新すれば付いてくる」のが基本で、覚えることはごくわずかです。

表示確認（別端末・シークレットウィンドウ）

公開直後に、自分の環境以外からの見え方を確認します。ブラウザのシークレットウィンドウ、またはスマートフォンなど別端末で公開 URL を開き、次の点をチェックします。

• ページが表示され、ツールが正常に動作するか（計算・ボタン操作・コピー機能など一通り）
• スマートフォンでの表示が崩れていないか（URL を渡した相手がスマートフォンで開くケースは意外と多い）
• ブラウザのアドレスバーに鍵マーク（HTTPS）が表示されているか

GitHub Pages は既定で HTTPS に対応しており、https:// の URL がそのまま使えます。特別な設定や証明書の用意は不要です。

ファイル更新と再公開の流れ

公開後の更新に、特別な「再公開」の操作はありません。リポジトリのファイルを更新（ブラウザ上で編集してコミット、またはファイルを再アップロード）すれば、公開ページにも自動的に反映されます。反映までは有効化のときと同じく最大 10 分程度かかる場合があります。

すぐに反映を確認したいときは、ブラウザのキャッシュに注意してください。ページが古いまま見える場合は、スーパーリロード（Windows は Ctrl+F5、macOS は Cmd+Shift+R）で再読み込みすると、キャッシュを飛ばして最新の状態を確認できます。

なお、リポジトリの更新がそのまま公開ページに直結するということは、作業途中の中途半端な状態も公開されてしまうということでもあります。大きな改修を段階的にコミットしたい場合は、動作が壊れた状態のコミットを避けるか、改修が一通り終わってからまとめて反映する運用が無難です。

公開の停止方法

公開をやめたくなった場合は、リポジトリのメインページまたは Settings → Pages にある「Your site is live at …」表示の横のメニュー（横三点アイコン）から「Unpublish site」を選びます。現在のデプロイが削除され、サイトは表示されなくなります。リポジトリ本体の設定や中身には影響しません。

停止は削除とは異なり、再びコミットやワークフローの実行があれば新しいデプロイが作られて再公開できます。「完全にやめる」のではなく「いったん引っ込める」に近い操作と理解しておくと、気軽に試せます。

つまずきやすいポイント

有効化はシンプルな操作ですが、初回はいくつか引っかかりやすい点があります。

404 が表示される（直後）

有効化・更新の反映には最大 10 分程度かかります。まずは数分待って再読み込みしてください。

404 が表示される（待っても直らない）

URL とファイル名の対応を確認します。https://ユーザー名.github.io/リポジトリ名/ で開けるのはリポジトリ直下の index.html です。ツールのファイル名が tool.html などの場合は、URL にファイル名まで含めるか、index.html にリネームします。また、URL のパスは大文字・小文字を区別するため、Tool.html と tool.html は別物として扱われます。

トップ URL でツールではなく README が表示され

リポジトリ直下に index.html がない場合、GitHub Pages は代わりに README.md を HTML に変換してトップページとして表示します。「404 ではないが、出てくるのはツールではなく説明文のページ」という状態がこれです。筆者も、ツール本体を mtu-mss-tool.html のまま公開した際にこの状態になりました。対処は、ツール本体のファイル名を index.html にリネームすることです。GitHub 上でファイルを開き、編集画面のファイル名欄を index.html に書き換えてコミットすれば、トップ URL でツールが表示されるようになります。

設定画面で Pages の項目に「Upgrade or make this repository public」と表示される

リポジトリが Private のままです。無料プランで Pages を使うには、リポジトリを Public に変更する必要があります（Settings → General の Danger Zone から変更できます）

更新したのに古い表示のまま

反映待ちか、ブラウザキャッシュのどちらかです。10 分待っても変わらなければスーパーリロードを試し、それでも変わらなければリポジトリの「Actions」タブで「pages build and deployment」の処理が成功しているかを確認します。

ツールは開くが一部が動かない

ローカル（file://）では動いていたのに公開版で動かない場合、外部リソース（CDN のライブラリ等）の読み込みを http:// で指定していないかを確認します。GitHub Pages は HTTPS で配信されるため、HTTP の外部リソースはブラウザにブロックされます（混在コンテンツ）。読み込みはすべて https:// に統一します。

まとめ

GitHub Pages を使えば、リポジトリに置いた自作ツールを、サーバーの構築も追加費用もなしで「URL を渡すだけで使える形」にできます。操作は Settings → Pages で数クリック、更新はリポジトリへのコミットだけという手軽さで、静的なツールの公開先としては十分すぎる仕組みです。押さえるべきは操作よりも、全世界公開という前提の理解でした。

• GitHub Pages はリポジトリのファイルをそのまま Web 公開する静的ホスティング
• 無料プランで使えるのは Public リポジトリのみ
• 公開サイトは誰でもアクセス可能で、アクセス制限は不可
• 有効化は Settings → Pages で Deploy from a branch を選び Save するだけ
• URL は ユーザー名.github.io/リポジトリ名/ 形式で index.html が表示される
• 更新はコミットで自動反映、反映まで最大 10 分程度
• 公開の停止は Unpublish site から可能で、再公開もできる

以上、最後までお読みいただきありがとうございました。