2026年8月1日

2026年8月1日

GitHub PagesでWebサイトを公開する方法(ブランチ公開・GitHub Actions・独自ドメイン)

GitHub Pages は、GitHub のリポジトリに置いた HTML などの静的ファイルを、そのまま Web サイトとして公開できる機能です。リポジトリを作ってファイルを push し、設定画面で公開元を選べば、ユーザー名.github.io の URL でサイトが表示されます。この記事では、公開元の2つの方式(ブランチから公開と GitHub Actions で公開)の違いと手順、独自ドメインと HTTPS の設定、公開前に知っておきたい制約までを説明します。

GitHub Pagesでできること・できないこと

GitHub Pages が配信するのは静的なファイルです。PHP やデータベースは動かないため、WordPress をそのまま載せることはできません。手書きの HTML サイト、ドキュメント、ポートフォリオ、静的サイトジェネレーター(Jekyll、Hugo、Astro など)で生成したサイトに向いています。

公開前に、次の点を押さえておいてください。

  • 公開されたサイトは、原則としてインターネット上の誰でも見られます。リポジトリを非公開にしていても、Pages のサイト自体は公開されます(組織向けの一部プランには閲覧を制限する機能があります)。
  • 無料プランでは、公開リポジトリから Pages を使えます。非公開リポジトリから公開するには有料プランが必要です。
  • サイトの容量、帯域、ビルドの回数には利用上の目安が定められています。また、ネットショップの運営など商用サービスの基盤として使うことは想定されていません。

プランごとの対応範囲や利用上の制限は変わることがあるため、GitHub の公式ドキュメントで最新の内容を確認してください(2026年10月現在)。

ユーザーサイトとプロジェクトサイト

GitHub Pages には、URL の形が違う2種類のサイトがあります。

  • ユーザー(組織)サイト: リポジトリ名を ユーザー名.github.io にすると、https://ユーザー名.github.io/ で公開されます。1アカウントにつき1つです。
  • プロジェクトサイト: それ以外の名前のリポジトリでは、https://ユーザー名.github.io/リポジトリ名/ で公開されます。リポジトリごとに作れます。

プロジェクトサイトでつまずきやすいのが、CSS や画像のパスです。HTML に /css/style.css のようにルートからのパスを書くと、https://ユーザー名.github.io/css/style.css を探しに行き、リポジトリ名の部分が抜けて404になります。css/style.css のような相対パスで書くか、静的サイトジェネレーターのベースパス(base URL)の設定にリポジトリ名を入れてください。独自ドメインを設定した場合はルートが変わるので、そのときにもパスの書き方を見直します。

方法1: ブランチから公開する

ビルドが要らない手書きの HTML サイトなら、この方法が最も手軽です。

  1. リポジトリを作成し、index.html を含むファイルを push します。
  2. リポジトリの Settings を開き、Pages の設定で公開元(Source)に「ブランチから公開」を選びます。
  3. 公開するブランチ(例: main)とフォルダ(ルート / か /docs)を選んで保存します。

数分後、設定画面に公開 URL が表示されます。画面の項目名は変わることがあるので、見当たらない場合は Pages の設定項目の中から公開元の選択を探してください。

この方式では、GitHub が既定で Jekyll によるビルドを行います。Jekyll を使わない手書きのサイトで、アンダースコアで始まるフォルダ(_assets など)が表示されない場合は、公開するフォルダの直下に .nojekyll という空のファイルを置くと、Jekyll の処理が行われなくなります。

touch .nojekyll
git add .nojekyll
git commit -m "Disable Jekyll processing"
git push

方法2: GitHub Actionsで公開する

Hugo や Astro などでビルドが必要なサイトは、GitHub Actions でビルドして公開する方式が向いています。ビルド結果を別のブランチにコミットする必要がなく、ビルドの手順もワークフローとして残せます。

Pages の設定で公開元に GitHub Actions を選び、.github/workflows/pages.yml を作成します。次の例は、npm run build で dist フォルダに出力するサイトを公開するものです。

name: Deploy to GitHub Pages

on:
  push:
    branches: [main]
  workflow_dispatch:

permissions:
  contents: read
  pages: write
  id-token: write

concurrency:
  group: pages
  cancel-in-progress: false

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm
      - run: npm ci
      - run: npm run build
      - uses: actions/configure-pages@v5
      - uses: actions/upload-pages-artifact@v3
        with:
          path: ./dist

  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    steps:
      - id: deployment
        uses: actions/deploy-pages@v4

ポイントは3つあります。

1つ目は permissions です。Pages への公開には pages: write と id-token: write が必要で、これがないと公開の段階で権限エラーになります。逆に、それ以外の権限は付けずに最小限にしておきます。

2つ目は concurrency です。push が続いたときに公開処理が同時に走らないようにします。

3つ目はアクションのバージョンです。上の @v4 などのメジャーバージョンは更新されていくため、GitHub が提供しているスターターワークフローや各アクションのリポジトリで、使用時点の推奨バージョンを確認してください。

ワークフローの実行状況はリポジトリの Actions タブで確認できます。失敗した場合は、どのステップで止まったかを開いてログを読みます。ビルドのステップで失敗していれば手元でも npm run build が通るか、公開のステップで失敗していれば権限と Pages の公開元の設定を確認します。

独自ドメインとHTTPSを設定する

Pages の設定で独自ドメインを入力し、DNS にレコードを登録します。

  • **サブドメイン(例: www.example.com)**: ユーザー名.github.io を向く CNAME レコードを登録します。
  • **ルートドメイン(例: example.com)**: GitHub の公式ドキュメントに記載された A レコード(IPv6 を使う場合は AAAA レコード)を登録するか、DNS サービスの ALIAS・ANAME 機能を使います。

A レコードの値は、執筆時点では 185.199.108.153 から 185.199.111.153 までの4つが案内されていますが、設定する前に公式ドキュメントで最新の値を確認してください。

ブランチから公開する方式では、独自ドメインを設定するとリポジトリに CNAME というファイルが作られます。GitHub Actions で公開する方式では、このファイルは使われず、設定画面の値が使われます。

DNS が反映されると証明書が自動で発行されるので、Pages の設定にある「HTTPS を強制する」オプションを有効にします。反映直後はこのオプションが選べないことがありますが、しばらく待つと選べるようになります。

あわせて、アカウントまたは組織の設定でドメインの所有確認(verified domains)を行っておくことをおすすめします。所有確認をしておかないと、DNS が GitHub を向いたまま Pages の設定を外したときなどに、第三者にそのドメインでサイトを公開されるおそれがあります。サイトをやめるときは、DNS のレコードも削除してください。

公開前の確認ポイント

公開リポジトリでは、サイトに表示しないファイルも含めてリポジトリ全体が誰でも見られます。次の点を確認してから公開してください。

  • API キーやパスワード、.env ファイルをコミットしていないか。一度でもコミットした秘密情報は、履歴から消すだけでなく無効化して再発行します
  • 個人情報や社外秘の資料が含まれていないか
  • .gitignore で、ビルドの中間ファイルやローカルの設定ファイルを除外しているか

WordPress のサイトを静的化して GitHub Pages で配信する方法もありますが、コメントやフォーム、検索など PHP で動く機能は使えなくなります。静的化する場合も、元の WordPress を非公開の環境に残し、バックアップを取ったうえで進めてください。

まとめ

  • GitHub Pages はリポジトリの静的ファイルを公開する機能で、PHP やデータベースは動かない
  • ユーザー名.github.io のリポジトリはユーザーサイト、それ以外はプロジェクトサイトになり、プロジェクトサイトではパスの書き方に注意する
  • 手書きの HTML はブランチから公開、ビルドが必要なサイトは GitHub Actions で公開する
  • Actions では pages: write と id-token: write の権限を付け、アクションのバージョンは公式で確認する
  • 独自ドメインは CNAME または公式の A レコードで設定し、HTTPS を強制し、ドメインの所有確認を行う
  • 公開リポジトリには秘密情報や個人情報を含めない

お気軽にご相談ください

お見積りへ お問い合わせへ
▲