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 ファイルは作成されません。既存の CNAME ファイルは無視されますし、必要ありません。 公開元の詳細については、「GitHub Pages サイトの公開元を設定する」を参照してください。

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

    • ALIAS または ANAME レコードを作成するには、apex ドメインがサイトの既定のドメインを指すようにします。 サイトの既定のドメインについて詳しくは、「What is 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 プロバイダーによって自動設定されている場合は、それを削除してから次に進みます。

警告

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

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

  2. 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

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

  4. 必要に応じて、サイトに 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プロバイダのドキュメンテーションを参照してください。 サイトの既定のドメインについて詳しくは、「What is GitHub Pages?」をご覧ください。

サブドメインを設定する

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

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

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

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

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

  4. [カスタム ドメイン] で、カスタム ドメイン名を入力してから、 [保存] をクリックします。 ブランチからサイトを公開している場合は、直接ソース ブランチのルートに CNAME ファイルを追加するコミットが作成されます。 カスタム GitHub Actions ワークフローから公開する場合、CNAME ファイルは作成されません。既存の 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プロバイダのドキュメンテーションを参照してください。 サイトの既定のドメインについて詳しくは、「What is 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 の適用に関する issue が発生し、サブドメインが GitHub Pages サイトにまったく到達しないという issue が発生する可能性があります。

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

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

apex ドメインを構成するには、以下の表にあるすべての A および AAAA レコードを追加するか、または表の ALIAS/ANAME レコードのみを追加します。 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. [カスタム ドメイン] で、 [削除] をクリックします。

    カスタム ドメインのスクリーンショット。 "example.com" というテキスト ボックスと [Save] ボタンの横に、赤い文字で [Remove] というラベルのボタンがあります。

カスタムドメインの保護

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

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

参考資料