GitHub Pages サイトのカスタムドメインを管理する

特定の DNS レコードとリポジトリ設定を設定または更新し、GitHub Pages サイトのデフォルトドメインをカスタムドメインに指定することができます。

この機能を使用できるユーザーについて

GitHub Pagesは、パブリック・リポジトリのGitHub Freeと組織用のGitHub Free、パブリック・リポジトリとプライベート・リポジトリのGitHub Pro、GitHub Team、GitHub Enterprise Cloud、GitHub Enterprise Serverで利用できます。 詳しくは、「GitHub のプラン」をご覧ください。

GitHub Pages で、Jekyll ビルドの実行に GitHub Actions が使用されるようになりました。 ビルドのソースとしてブランチを使用する際、組み込みの Jekyll ワークフローを使用する場合は、リポジトリで GitHub Actions を有効にする必要があります。 GitHub Actions が使用できない場合、または無効になっている場合は、ソース ブランチのルートに .nojekyll ファイルを追加すると、Jekyll ビルド プロセスがバイパスされ、コンテンツが直接デプロイされます。 GitHub Actions の有効化の詳細については、「リポジトリの GitHub Actions の設定を管理する」を参照してください。

Platform navigation

この記事の内容

リポジトリの管理者権限があるユーザは、GitHub Pages サイトのカスタムドメインを設定できます。

カスタムドメインの設定について

ヒント: カスタム ドメインをリポジトリに追加する前に検証し、セキュリティを向上させ、乗っ取り攻撃を回避することをお勧めします。 詳しくは、「GitHub Pagesのカスタムドメインの検証」を参照してください。

DNS プロバイダでカスタムドメインを設定する前に、必ず GitHub Pages サイトをカスタムドメインに追加してください。 カスタムドメインを GitHub に追加せずに DNS プロバイダに設定すると、別のユーザがあなたのサブドメインにサイトをホストできることになります。

DNS レコードの構成が正しいかどうかを確認するために利用できる dig コマンドは、Windows には含まれていません。 DNS レコードが正しく構成されていることを確認するには、Resolve-DnsName PowerShell コマンドを使用するか、BIND をインストールします。

注: DNS の変更内容が反映されるまで最大で 24 時間かかることがあります。

Apexドメインを設定する

example.com などの apex ドメインを設定するには、リポジトリ設定でカスタムドメインを構成し、ご利用の DNS プロバイダーで少なくとも 1 つの ALIAS、ANAME、または A レコードを構成する必要があります。

  1. GitHubで、サイトのリポジトリにアクセスしてください。

  2. リポジトリ名の下にある [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    タブを示すリポジトリ ヘッダーのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で強調表示されています。

  3. サイド バーの [コードと自動化] セクションで、 [ ページ] をクリックします。

  4. [カスタム ドメイン] で、カスタム ドメイン名を入力してから、 [保存] をクリックします。 ブランチからサイトを公開している場合は、直接ソース ブランチのルートに CNAME ファイルを追加するコミットが作成されます。 カスタム GitHub Actions ワークフローを使用してサイトを発行する場合、CNAME ファイルは作成されないため、手動で作成する必要があります (カスタム ドメインが書かれたテキスト行のみを含む)。 公開元について詳しくは、「GitHub Pages サイトの公開元を設定する」をご覧ください。

  5. DNS プロバイダーに移動し、ALIAS、ANAME、または A レコードを作成します。 IPv6 サポートのために AAAA レコードを作成することもできます。 IPv6 サポートを実装する場合、IPv6 の世界的な導入が遅れているため、AAAA レコードに加えて A レコードを使うことを強くお勧めします。 正しいレコードの作成方法に関する詳しい情報については、DNSプロバイダのドキュメンテーションを参照してください。

    • ALIAS または ANAME レコードを作成するには、apex ドメインがサイトの既定のドメインを指すようにします。 サイトの既定のドメインの詳細については、「GitHub Pages について」を参照してください。

    • A レコードを作成するには、apex ドメインが GitHub Pages の IP アドレスを指すようにします。

      185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153

    • AAAA レコードを作成するには、apex ドメインが GitHub Pages の IP アドレスを指すようにします。

      2606:50c0:8000::153
2606:50c0:8001::153
2606:50c0:8002::153
2606:50c0:8003::153

    警告: ワイルドカード DNS レコード (*.example.com など) を使用しないことを強くお勧めします。 このようなレコードを使うと、ドメイン乗っ取りのリスクが直ちに発生します (ドメインの検証を行ったとしても)。 たとえば、example.com を検証すれば a.example.com を使うことはできなくなりますが、依然として (ワイルドカード DNS レコードの対象範囲である) b.a.example.com を乗っ取ることができます。 詳しくは、「GitHub Pagesのカスタムドメインの検証」を参照してください。

  6. [ターミナル][ターミナル][Git Bash] を開きます。

  7. DNS レコードが正しく構成されていることを確認するには、dig コマンドを使用します。EXAMPLE.COM はご利用の apex ドメインに置き換えてください。 結果が、上記の GitHub Pages の IP アドレスに一致することを確認します。

    • A レコードの場合:

      $ dig EXAMPLE.COM +noall +answer -t A
> EXAMPLE.COM    3600    IN A     185.199.108.153
> EXAMPLE.COM    3600    IN A     185.199.109.153
> EXAMPLE.COM    3600    IN A     185.199.110.153
> EXAMPLE.COM    3600    IN A     185.199.111.153

    • AAAA レコードの場合:

      $ dig EXAMPLE.COM +noall +answer -t AAAA
> EXAMPLE.COM     3600    IN AAAA     2606:50c0:8000::153
> EXAMPLE.COM     3600    IN AAAA     2606:50c0:8001::153
> EXAMPLE.COM     3600    IN AAAA     2606:50c0:8002::153
> EXAMPLE.COM     3600    IN AAAA     2606:50c0:8003::153

      A レコードも忘れずに確認してください。

  8. 静的サイト ジェネレータを使用してローカルでサイトを構築し、生成されたファイルを GitHub にプッシュする場合、ローカルのリポジトリに CNAME ファイルを追加したコミットをプルしてください。 詳しくは、「カスタムドメインとGitHub Pages のトラブルシューティング」を参照してください。

  9. 必要に応じて、サイトに HTTPS 暗号化を適用するには、 [HTTPS の適用] を選択します。 このオプションが利用できるようになるには、最大で24時間かかります。 詳しくは、「HTTPS で GitHub Pages サイトを保護する」を参照してください。

apex ドメインと www サブドメイン バリアントの構成

注: HTTPS としてセキュリティで保護された Web サイトでは www サブドメインを apex ドメインとともに設定することをお勧めします。

カスタム ドメインとして Apex ドメインを使用している場合は、www サブドメインも設定することをお勧めします。 DNSプロバイダを通じて各ドメインの種類のための正しいレコードを設定しているなら、GitHub Pagesは自動的にドメイン間のリダイレクトを生成します。 たとえば、www.example.com をご自分のサイトのカスタム ドメインとして構成し、GitHub Pages DNS レコードを Apex と www のドメインに設定している場合、example.com は www.example.com にリダイレクトされます。 自動リダイレクトは www サブドメインにのみ適用されることに注意してください。 自動リダイレクトは、blog などのその他のサブドメインには適用されません。 詳細については、「サブドメインの構成」を参照してください。

ご利用の DNS プロバイダーに移動し、www サブドメインが GitHub Pages の既定のドメインをポイントする CNAME レコードを作成します。 たとえば、サイトが <user>.github.io に存在する場合は、www.example.com を <user>.github.io にポイントする CNAME レコードを作成する必要があります。同様に、<organization>.github.io に存在する組織サイトの場合は、www.example.com を <organization>.github.io にポイントする CNAME レコードを作成する必要があります。 CNAME レコードがリポジトリ名を含めなくても直接 <user>.github.io または <organization>.github.io をポイントしていることを確認します。

正しいレコードの作成方法に関する詳しい情報については、DNSプロバイダのドキュメンテーションを参照してください。 サイトの既定のドメインの詳細については、「GitHub Pages について」を参照してください。

サブドメインを設定する

www またはカスタム サブドメイン (www.example.com や blog.example.com など) を設定するには、リポジトリ設定にドメインを追加する必要があります。 その後、DNS プロバイダで CNAME レコードを設定します。

  1. GitHubで、サイトのリポジトリにアクセスしてください。

  2. リポジトリ名の下にある [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    タブを示すリポジトリ ヘッダーのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で強調表示されています。

  3. サイド バーの [コードと自動化] セクションで、 [ ページ] をクリックします。

  4. [カスタム ドメイン] で、カスタム ドメイン名を入力してから、 [保存] をクリックします。 ブランチからサイトを公開している場合は、直接ソース ブランチのルートに CNAME ファイルを追加するコミットが作成されます。 カスタム GitHub Actions ワークフローを使用してサイトを発行する場合、CNAME ファイルは作成されないため、手動で作成する必要があります (カスタム ドメインが書かれたテキスト行のみを含む)。 公開元について詳しくは、「GitHub Pages サイトの公開元を設定する」をご覧ください。

    メモ: カスタム ドメインが国際化ドメイン名の場合、Punycode でエンコードされたバージョンを入力する必要があります。

    Punycodes について詳しくは、「国際化ドメイン名」をご覧ください。

  5. ご利用の DNS プロバイダーに移動し、サブドメインがサイトの既定のドメインを指す CNAMECNAME レコードを作成します。 たとえば、ユーザー サイトのサブドメイン www.example.com を使用する場合は、www.example.com が <user>.github.io を指す CNAME レコードを作成します。 組織サイトのサブドメイン another.example.com を使用する場合は、another.example.com が <organization>.github.io を指す CNAME レコードを作成します。 CNAME レコードは常に、<user>.github.io または <organization>.github.io (リポジトリ名を除く) を指す必要があります。 正しいレコードの作成方法に関する詳しい情報については、DNSプロバイダのドキュメンテーションを参照してください。 サイトの既定のドメインの詳細については、「GitHub Pages について」を参照してください。

    警告: ワイルドカード DNS レコード (*.example.com など) を使用しないことを強くお勧めします。 このようなレコードを使うと、ドメイン乗っ取りのリスクが直ちに発生します (ドメインの検証を行ったとしても)。 たとえば、example.com を検証すれば a.example.com を使うことはできなくなりますが、依然として (ワイルドカード DNS レコードの対象範囲である) b.a.example.com を乗っ取ることができます。 詳しくは、「GitHub Pagesのカスタムドメインの検証」を参照してください。

  6. [ターミナル][ターミナル][Git Bash] を開きます。

  7. DNS レコードが正しく構成されたことを確認するには、dig コマンドを使用します。WWW.EXAMPLE.COM はご利用のサブドメインに置き換えてください。

    $ dig WWW.EXAMPLE.COM +nostats +nocomments +nocmd
> ;WWW.EXAMPLE.COM.                    IN      A
> WWW.EXAMPLE.COM.             3592    IN      CNAME   YOUR-USERNAME.github.io.
> YOUR-USERNAME.github.io.      43192   IN      CNAME   GITHUB-PAGES-SERVER .
> GITHUB-PAGES-SERVER .         22      IN      A       192.0.2.1

  8. 静的サイト ジェネレータを使用してローカルでサイトを構築し、生成されたファイルを GitHub にプッシュする場合、ローカルのリポジトリに CNAME ファイルを追加したコミットをプルしてください。 詳しくは、「カスタムドメインとGitHub Pages のトラブルシューティング」を参照してください。

  9. 必要に応じて、サイトに HTTPS 暗号化を適用するには、 [HTTPS の適用] を選択します。 このオプションが利用できるようになるには、最大で24時間かかります。 詳しくは、「HTTPS で GitHub Pages サイトを保護する」を参照してください。

    注: カスタム サブドメインを apex ドメインにポイントすると、Web サイトへの HTTPS の適用に関する問題が発生し、サブドメインが GitHub Pages サイトにまったく到達しないという問題が発生する可能性があります。

カスタム ドメインの DNS レコード

GitHub Pages サイトのドメインを構成するプロセスを十分理解している場合は、以下の表を使用して、特定のシナリオの DNS 値と、DNS プロバイダーがサポートする DNS レコードの種類を確認できます。 GitHub で GitHub Pages サイトを構成する方法や、dig コマンドを使用して構成を確認する方法などの詳細については、上記のセクションを参照してください。

Apex ドメインを構成するには次の表から 1 つの DNS レコードの種類のみを選択する必要があります。 Apex ドメインと www サブドメインを構成するには (たとえば example.com www.example.com など)、Apex ドメイン、その後にサブドメインを構成します。 詳細については、「Apex ドメインと www サブドメイン バリアントの構成」を参照してください。

警告: ワイルドカード DNS レコード (*.example.com など) を使用しないことを強くお勧めします。 このようなレコードを使うと、ドメイン乗っ取りのリスクが直ちに発生します (ドメインの検証を行ったとしても)。 たとえば、example.com を検証すれば a.example.com を使うことはできなくなりますが、依然として (ワイルドカード DNS レコードの対象範囲である) b.a.example.com を乗っ取ることができます。 詳しくは、「GitHub Pagesのカスタムドメインの検証」を参照してください。

シナリオDNS レコードの種類DNS レコード名DNS レコード値
Apex ドメイン
（example.com）		A@185.199.108.153
185.199.109.153
185.199.110.153
185.199.111.153
Apex ドメイン
（example.com）		AAAA@2606:50c0:8000::153
2606:50c0:8001::153
2606:50c0:8002::153
2606:50c0:8003::153
Apex ドメイン
（example.com）		ALIAS または ANAME@USERNAME.github.io または
ORGANIZATION.github.io
Subdomain
（www.example.com、
blog.example.com）		CNAMESUBDOMAIN.example.com.USERNAME.github.io または
ORGANIZATION.github.io

カスタムドメインの削除

取得中のカスタム ドメインに関するエラーが発生した場合は、別のリポジトリからカスタム ドメインを削除する必要がある場合があります。

  1. GitHubで、サイトのリポジトリにアクセスしてください。

  2. リポジトリ名の下にある [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウン メニューを選び、 [設定] をクリックします。

    タブを示すリポジトリ ヘッダーのスクリーンショット。 [設定] タブが濃いオレンジ色の枠線で強調表示されています。

  3. サイド バーの [コードと自動化] セクションで、 [ ページ] をクリックします。

  4. [カスタム ドメイン] で、 [削除] をクリックします。

    GitHub Pages のカスタム ドメインを保存または削除する設定ボックスのスクリーンショット。 "example.com" というテキスト ボックスの右に、赤い文字で [削除] というラベルの付いたボタンがあります。

カスタムドメインの保護

GitHub Pages サイトが無効になっているが、カスタム ドメインが設定されている場合、ドメインの乗っ取りのリスクがあります。 サイトが無効な間に、DNS プロバイダでカスタムドメインを設定していると、サブドメインのいずれかで誰かにサイトをホストされてしまう恐れがあります。

カスタム ドメインを確認すると、他の GitHub ユーザーが自分のリポジトリでそのドメインを使用できなくなります。 ドメインが確認されておらず、GitHub Pages サイトが無効になっている場合は、DNS プロバイダーで DNS レコードを直ちに更新または削除する必要があります。詳しくは、「GitHub Pagesのカスタムドメインの検証」をご覧ください。

参考資料