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

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

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

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

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

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

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

Apexドメインを設定する

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

GitHub Enterprise Cloudで、サイトのリポジトリにアクセスしてください。
リポジトリ名の下にある [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウンメニューを選び、 [設定] をクリックします。
サイドバーの [コードと自動化] セクションで、 [ ページ] をクリックします。
[カスタムドメイン] で、カスタムドメイン名を入力してから、 [保存] をクリックします。ブランチからサイトを公開している場合は、直接ソースブランチのルートに CNAME ファイルを追加するコミットが作成されます。カスタム GitHub Actions ワークフローを使用してサイトを発行する場合、CNAME ファイルは作成されないため、手動で作成する必要があります (カスタムドメインが書かれたテキスト行のみを含む)。公開元について詳しくは、「GitHub Pages サイトの公開元を設定する」をご覧ください。
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のカスタムドメインの検証」を参照してください。
[ターミナル][ターミナル][Git Bash] を開きます。

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 レコードも忘れずに確認してください。

静的サイトジェネレータを使用してローカルでサイトを構築し、生成されたファイルを GitHub Enterprise Cloud にプッシュする場合、ローカルのリポジトリに CNAME ファイルを追加したコミットをプルしてください。詳しくは、「カスタムドメインとGitHub Pages のトラブルシューティング」を参照してください。
必要に応じて、サイトに 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 レコードを設定します。

GitHub Enterprise Cloudで、サイトのリポジトリにアクセスしてください。
リポジトリ名の下にある [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウンメニューを選び、 [設定] をクリックします。
サイドバーの [コードと自動化] セクションで、 [ ページ] をクリックします。
[カスタムドメイン] で、カスタムドメイン名を入力してから、 [保存] をクリックします。ブランチからサイトを公開している場合は、直接ソースブランチのルートに CNAME ファイルを追加するコミットが作成されます。カスタム GitHub Actions ワークフローを使用してサイトを発行する場合、CNAME ファイルは作成されないため、手動で作成する必要があります (カスタムドメインが書かれたテキスト行のみを含む)。公開元について詳しくは、「GitHub Pages サイトの公開元を設定する」をご覧ください。

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

Punycodes について詳しくは、「国際化ドメイン名」をご覧ください。
ご利用の 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のカスタムドメインの検証」を参照してください。
[ターミナル][ターミナル][Git Bash] を開きます。

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

静的サイトジェネレータを使用してローカルでサイトを構築し、生成されたファイルを GitHub Enterprise Cloud にプッシュする場合、ローカルのリポジトリに CNAME ファイルを追加したコミットをプルしてください。詳しくは、「カスタムドメインとGitHub Pages のトラブルシューティング」を参照してください。
必要に応じて、サイトに HTTPS 暗号化を適用するには、 [HTTPS の適用] を選択します。このオプションが利用できるようになるには、最大で24時間かかります。詳しくは、「HTTPS で GitHub Pages サイトを保護する」を参照してください。

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

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

GitHub Pages サイトのドメインを構成するプロセスを十分理解している場合は、以下の表を使用して、特定のシナリオの DNS 値と、DNS プロバイダーがサポートする DNS レコードの種類を確認できます。 GitHub Enterprise Cloud で 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`）	`CNAME`	`SUBDOMAIN.example.com.`	`USERNAME.github.io` または `ORGANIZATION.github.io`

カスタムドメインの削除

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

GitHub Enterprise Cloudで、サイトのリポジトリにアクセスしてください。
リポジトリ名の下にある [設定] をクリックします。 [設定] タブが表示されない場合は、 [] ドロップダウンメニューを選び、 [設定] をクリックします。
サイドバーの [コードと自動化] セクションで、 [ ページ] をクリックします。
[カスタムドメイン] で、 [削除] をクリックします。

カスタムドメインの保護

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

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

参考資料

カスタムドメインとGitHub Pages のトラブルシューティング