GitHub Pagesのカスタムドメイン設定を、GitHub Copilotだけで自動化できるのか。結論からいえば、Copilot CLIとDNS事業者のAPIを組み合わせれば、DNS管理画面を手作業で編集せずに設定できます。
ただし、今回示されたのはGitHub Pagesに新しい「DNS自動設定機能」が追加されたという発表ではありません。GitHub Copilot CLIが、コミュニティ製のAgent Skillを介してDNS APIを操作する実践例です。既存のGitHub Pages利用者に移行や設定変更が求められるものではなく、現在の手動DNS設定もそのまま利用できます。(The GitHub Blog)
GitHub公式ブログの掲載日は2026年7月8日です。本稿では、日本時間で7月9日に確認された更新として、実際に何が自動化されるのか、既存環境との互換性、導入条件、安全な検証手順を整理します。
GitHub PagesとGitHub CopilotのDNS自動化で何が変わるのか
今回の要点は、GitHub PagesのDNS仕様が変わったことではなく、従来は人が行っていた設定作業をCopilot CLIが代理実行できるようになったことです。
| 項目 | 従来の設定 | Copilotを使った公式デモ | 既存環境への影響 |
|---|---|---|---|
| GitHub Pagesの有効化 | リポジトリ設定画面から操作 | Copilot CLIが設定 | 仕様変更なし |
| HTMLの作成と公開 | ファイル作成、コミット、公開設定 | Copilot CLIが一連の作業を実行 | 既存サイトは変更不要 |
| DNSレコード | DNS管理画面でA・CNAMEを手入力 | DNS事業者のAPI経由で追加・変更 | DNSレコードの内容は従来と同じ |
| カスタムドメイン設定 | Pages設定とCNAMEファイルを管理 | Copilotが設定やコミットを実行 | 公開方式によって扱いが異なる |
| HTTPS | GitHub Pagesが証明書を発行 | 従来のHTTPS発行処理を利用 | Copilotが証明書を発行するわけではない |
| 動作確認 | digやブラウザで確認 | Copilotが名前解決とHTTP応答を確認 | 最終確認は人が行うべき |
| 対応の必要性 | 現行運用を継続可能 | 任意で自動化を導入 | 必須対応なし |
公式デモでも使用されたのは、GitHub Pagesで以前から案内されている4つのAレコードと、www用のCNAMEレコードです。HTTPSも既存のGitHub Pagesによる自動証明書発行を利用しています。(The GitHub Blog)
つまり、「zero DNS configuration」はDNS設定が不要になるという意味ではありません。正確には、人がDNS管理画面を開いて手入力する作業をゼロにする仕組みです。
公式デモでは何が自動化されたのか
GitHubの公式デモでは、空のリポジトリからカスタムドメインのHTTPSサイトを公開するまで、次の作業をGitHub Copilot CLIが支援しました。
- 公開リポジトリを作成する
- ランディングページを生成する
- GitHub Pagesを有効化する
- Namecheapで取得したドメインを確認する
- 現在のDNSレコードを取得する
- 既存のパーキング用レコードを置き換える
- GitHub Pages用のAレコードを登録する
www用のCNAMEレコードを登録する- リポジトリに
CNAMEファイルを追加する - DNSの名前解決とHTTP 200応答を確認する
- HTTPSで公開できることを確認する
デモでは、ドメイン取得からHTTPS公開まで約14分で完了しました。ただし、これは特定の環境での実測例であり、完了時間を保証するものではありません。GitHubのドキュメントでは、DNS反映やHTTPS利用可能化に最大24時間かかる場合があると案内されています。(The GitHub Blog)
実際に設定されるDNSレコード
デモで使用された基本構成は次のとおりです。
| ホスト名 | 種類 | 設定値 |
|---|---|---|
@ | A | 185.199.108.153 |
@ | A | 185.199.109.153 |
@ | A | 185.199.110.153 |
@ | A | 185.199.111.153 |
www | CNAME | <GitHubユーザー名または組織名>.github.io |
wwwのCNAMEには、リポジトリ名を含めません。たとえばユーザー名がexample-user、リポジトリ名がmy-siteでも、CNAMEの接続先はexample-user.github.ioです。
これらは2026年7月時点のGitHub公式ドキュメントに記載された値です。自動化スクリプトへ固定値として長期間埋め込むのではなく、実行時に最新の公式ドキュメントと照合する運用が安全です。(GitHub Docs)
GitHub Pagesの新機能ではなくCopilot CLIの活用例
今回の情報を読み解くうえで最も重要なのは、次の3点です。
GitHub PagesにDNS事業者との直接連携が追加されたわけではない
GitHub Pagesの設定画面に、Namecheapや他のDNSサービスへ自動接続するボタンが追加されたわけではありません。
Copilot CLIが次の2つの設定先を横断して操作しています。
- GitHub側では、リポジトリ、Pages設定、
CNAMEファイルを操作 - DNS側では、Agent Skillに含まれるスクリプトからNamecheap APIを操作
したがって、Copilot CLIを使わず、これまでどおりGitHub Pagesの設定画面とDNS管理画面から設定する方法も引き続き有効です。(The GitHub Blog)
Namecheap専用の標準機能ではなくコミュニティ製スキルを利用する
公式デモでは、Awesome GitHub Copilotで公開されているコミュニティ製のNamecheap Agent Skillを使用しています。
Agent Skillは、特定業務の手順、スクリプト、注意事項などをCopilotへ追加する仕組みです。GitHub Copilot CLI自体に、すべてのDNS事業者のAPI操作が標準搭載されているわけではありません。(The GitHub Blog)
Namecheap以外でも、APIを提供しているDNS事業者であれば、Copilot CLIにAPIドキュメントを参照させて同様の処理を構築できます。ただし、専用スキルがない事業者では、API仕様の解釈、認証、レコード更新方法、エラー処理を個別に検証する必要があります。(The GitHub Blog)
ブログ掲載時の手順をそのままコピーしない
公式ブログに掲載されたインストール例は次の形式です。
gh skill install github/awesome-copilot namecheap --scope user一方、現行のNamecheapスキルページでは次の形式が表示されています。
gh skills install github/awesome-copilot namecheap公式ブログと現在のスキルページでコマンド表記が一致していないため、実行時はGitHub CLIのヘルプと最新のスキルページを確認してください。プレビュー段階のツールや周辺コマンドは、短期間で構文や導入方法が変わる可能性があります。(The GitHub Blog)
導入に必要な条件
CopilotによるGitHub PagesのDNS自動化には、GitHubアカウントだけでなく、DNS APIを実行できる環境が必要です。
| 条件 | 確認内容 |
|---|---|
| GitHub Pagesを利用できるプラン | GitHub Freeでは公開リポジトリで利用可能。プライベートリポジトリでの利用には対応プランが必要 |
| リポジトリ権限 | カスタムドメインを設定できる管理者権限 |
| GitHub Copilot | 有効なCopilotプラン |
| Copilot CLI | インストールとGitHub認証が完了していること |
| 組織ポリシー | BusinessやEnterprise環境では管理者がCopilot CLIを許可していること |
| DNS API | DNSレコードを管理する事業者がAPIを提供していること |
| API認証情報 | APIユーザー、APIキー、IP許可設定など |
| DNS管理権限 | 対象ゾーンを変更できる権限 |
| ロールバック情報 | 変更前の全DNSレコードを復元できること |
GitHub Copilot CLIはすべてのCopilotプランで利用できますが、組織からライセンスを付与されている場合は、組織またはEnterpriseのポリシーで無効化されていないことが条件です。WindowsではPowerShell 6以降が必要です。(GitHub Docs)
GitHub PagesはGitHub Freeでも公開リポジトリから利用できます。なお、プライベートリポジトリから公開した場合でも、通常のGitHub Pagesサイトはインターネット上に公開されます。リポジトリ内に秘密情報や社内限定情報を含めないよう注意が必要です。(GitHub Docs)
Namecheapを使う場合の追加条件
公式デモでは、Namecheap APIを有効にしたうえで、APIを実行する端末のグローバルIPアドレスを許可リストへ登録しています。
そのため、次の環境では事前確認が必要です。
- インターネット接続のたびにグローバルIPアドレスが変わる
- VPN経由で外部通信している
- CI/CDランナーの送信元IPが固定されていない
- 社内プロキシを経由している
- Namecheapでドメインを取得しているが、DNSは別事業者で管理している
特に、ドメインの購入先と権威DNSの管理先は同じとは限りません。Namecheapで取得したドメインでも、ネームサーバーをCloudflareなどへ変更している場合、Namecheap側のDNSレコードを書き換えても公開中のDNSには反映されません。操作対象は、実際に権威DNSを運用しているサービスのAPIでなければなりません。(The GitHub Blog)
既存のGitHub Pages実装との互換性
既存サイトへ導入する場合は、公開方式とDNS構成によって注意点が変わります。
| 既存構成 | 互換性 | 確認すべき点 |
|---|---|---|
| 手動で正しく設定済みのサイト | そのまま利用可能 | 自動化のためだけにDNSを書き換える必要はない |
| ブランチから公開 | 利用可能 | 公開元ブランチ直下のCNAMEファイルを維持する |
| カスタムGitHub Actionsから公開 | 利用可能 | CNAMEファイルは無視されるため、Pages設定を確認する |
Apexドメインとwwwを併用 | 利用可能 | AレコードとCNAMEの両方を設定し、リダイレクト方向を確認する |
| ユーザー・組織サイト | 要確認 | 配下のプロジェクトサイトにもカスタムドメインが適用される場合がある |
| メールを同一ドメインで使用 | 要注意 | MX、TXT、SPF、DKIM、DMARCなどを絶対に消さない |
| 外部CDNや別DNS事業者を利用 | 条件付き | 実際の権威DNSを管理するAPIを使用する |
| ワイルドカードDNSを利用 | 非推奨 | ドメイン乗っ取りリスクがある |
ブランチ公開ではCNAMEファイルを維持する
ブランチからGitHub Pagesを公開している場合、カスタムドメインは公開元ブランチ直下のCNAMEファイルにも保存されます。
静的サイトジェネレーターが生成物を強制プッシュする構成では、Copilotが追加したCNAMEファイルが次回デプロイ時に消えることがあります。自動化が一度成功しても、次回の公開後にカスタムドメインが解除されていないか確認してください。(GitHub Docs)
GitHub Actions公開ではCNAMEファイルを成功条件にしない
カスタムGitHub Actionsワークフローから公開している場合、CNAMEファイルは不要で、存在していてもGitHub Pagesから無視されます。
そのため、「CopilotがCNAMEファイルをコミットしたから設定完了」と判断するのは不適切です。リポジトリの「Settings」から「Pages」を開き、Custom domain欄へ正しいドメインが保存されていることを確認します。(GitHub Docs)
ユーザーサイトや組織サイトでは配下URLも確認する
ユーザーサイトまたは組織サイトへカスタムドメインを設定すると、同じアカウントが所有するプロジェクトサイトにも、そのカスタムドメインが既定で使われる場合があります。
たとえば、ユーザーサイトにwww.example.comを設定すると、個別のカスタムドメインを持たないプロジェクトサイトがwww.example.com/project-nameで公開されます。サイト全体のURL構成が変わる可能性があるため、既存リンク、検索エンジンの登録、OAuthのリダイレクトURLなども確認してください。(GitHub Docs)
対応が必要かを判断する基準
今回の情報を受けて、すべてのGitHub PagesサイトにCopilot CLIを導入する必要はありません。
| 利用状況 | 対応判断 |
|---|---|
| 既存サイトが安定稼働している | 対応不要。現在のDNS設定を維持する |
| 新しい個人サイトを頻繁に作る | 検証する価値が高い |
| Namecheapで検証用ドメインを管理している | 公式デモに近く、試しやすい |
| 複数サイトを同じ手順で開設する | 標準手順化やスキル化を検討する |
| 企業の本番ドメインを扱う | 直接実行せず、変更申請・レビュー・ロールバックを組み込む |
| 同じドメインでメールを運用している | 全レコード保全を確認できるまで自動変更しない |
| DNS事業者がAPIを提供していない | 従来どおり手動設定を継続する |
| APIキーを個人端末へ保存できない | 組織の秘密情報管理方式を整備してから導入する |
最初の導入対象として適しているのは、失敗しても業務に影響しない検証用ドメインやサブドメインです。企業のコーポレートドメインやメール利用中のドメインを、最初の検証対象にするべきではありません。
安全に試すための導入手順
検証用ドメインまたはサブドメインを用意する
本番のApexドメインではなく、次のような検証専用ドメインを用意します。
pages-test.example.net検証用であっても、同じDNSゾーンに本番のメールや業務システムが存在する場合は注意が必要です。DNS APIによっては、単一レコードの追加ではなくゾーン内の全レコードを置き換える処理が使われます。
変更前のDNSレコードをすべて保存する
最低限、次の情報を保存します。
- ホスト名
- レコードタイプ
- 値
- TTL
- MXの優先度
- 現在のネームサーバー
- メール転送設定
- GitHubドメイン検証用TXTレコード
- SPF、DKIM、DMARCなどのTXTレコード
NamecheapのsetHosts APIは、既存レコードへ差分追加するのではなく、渡された内容で全レコードを置き換える方式です。現在のスキル説明でも、全レコードを取得してから実行するか、既存レコードを保持する単一レコード操作を使うよう警告されています。(Awesome GitHub Copilot)
DNS変更前にGitHubでドメインを検証する
GitHubは、DNS事業者側で接続先を変更する前に、次の順序で設定することを推奨しています。
- GitHubアカウントまたは組織でドメイン所有権を検証する
- GitHub PagesのCustom domainへドメインを登録する
- DNS事業者側のAレコードやCNAMEを変更する
ドメイン検証ではTXTレコードを追加します。検証後もTXTレコードを残すことで、他のGitHubユーザーによるカスタムドメインの乗っ取りを防ぎやすくなります。ワイルドカードDNSは、検証済みドメインでも乗っ取りリスクを残すため推奨されません。(GitHub Docs)
最初は変更せず計画だけを出させる
いきなり「設定して」と指示するのではなく、最初は変更案だけを作成させます。
このGitHub Pagesサイトへexample.comを設定するための作業計画を作成してください。
まだGitHub設定、ファイル、DNSレコードは変更しないでください。
次の内容を先に表示してください。
・現在のGitHub Pages設定
・現在のネームサーバー
・現在の全DNSレコード
・追加、変更、削除するレコード
・GitHub公式ドキュメントの現在値との照合結果
・影響を受ける可能性があるMX、TXT、CAAレコード
・変更後の確認手順
・元に戻すためのロールバック手順
MX、TXT、SPF、DKIM、DMARC、ドメイン検証用TXTは変更しないでください。計画内容を確認し、削除されるレコードが想定どおりであることを確認してから実行へ進みます。
APIキーをチャットへ貼り付けない
公式ブログの画面ではCopilotがAPIキーを質問する流れが紹介されていますが、現行のNamecheapスキル説明では、APIキーをチャットへ入力させないよう明記されています。
現在のスキルでは、利用者自身がローカルターミナルでセットアップスクリプトを実行し、APIキーを非表示入力する方式が案内されています。認証情報はアクセス権を所有者だけに制限したファイル、または環境変数で管理します。公開記事の画面や過去の手順より、実行時点の最新セキュリティ手順を優先してください。(The GitHub Blog)
変更は1回ごとに承認する
DNS検証では、Copilot CLIの--allow-all-toolsを使用せず、操作内容を1回ごとに確認するのが安全です。
Copilot CLIには、特定ツールをセッション中ずっと許可する選択肢があります。しかし、たとえば特定ファイルを削除するrm操作をセッション単位で許可すると、そのセッション中は別のrm操作も追加確認なしで実行できる場合があります。DNS変更やGit操作を含む検証では、広い権限を一括承認しないようにします。(GitHub Docs)
意図しないプッシュを防ぎたい場合は、Copilot CLIの制御オプションも利用できます。
copilot --deny-tool='shell(git push)'まずローカルで差分を確認し、人が承認したコミットだけをプッシュする運用にすると、DNSとリポジトリの変更を分離できます。
テスト時に確認すべき項目
DNS APIから成功応答が返っても、サイトが利用可能になったとは限りません。次の層を分けて確認します。
| 確認対象 | 確認内容 | 失敗時に疑う点 |
|---|---|---|
| API応答 | DNS更新APIが正常終了したか | 認証、IP許可、APIパラメーター |
| DNS事業者のレコード一覧 | 登録内容が意図した値になったか | 全置換、ホスト名の解釈、値の誤り |
| 権威DNS | 権威ネームサーバーが新しい値を返すか | 反映待ち、別DNS事業者を操作している |
| パブリックDNS | 一般のDNSリゾルバーから解決できるか | TTL、キャッシュ、伝播待ち |
| GitHub Pages設定 | Custom domainが保存されているか | 権限、Pages設定、重複ドメイン |
| HTTP応答 | 正しいサイトが返り、200応答になるか | DNS誤設定、Pages未公開、404 |
| HTTPS | 証明書が有効でHTTPS強制が使えるか | DNS競合、証明書発行待ち |
| コンテンツ | CSS、画像、JavaScriptが読み込めるか | Mixed Content、絶対URLの誤り |
| 次回デプロイ | 再公開後もドメイン設定が残るか | CNAMEファイルの上書き |
| 既存サービス | メールや他のサブドメインが動くか | MX・TXT・CNAMEの消失 |
Windowsでの確認例
Resolve-DnsName example.com -Type A
Resolve-DnsName www.example.com -Type CNAME
curl.exe -I http://example.com
curl.exe -I https://example.commacOS・Linuxでの確認例
dig example.com A +short
dig www.example.com CNAME +short
curl -I http://example.com
curl -I https://example.comGitHubが公開した実セッションでも、Namecheap API側では更新成功と表示された直後に、権威DNSへ問い合わせると古いパーキング用レコードが返る場面がありました。これは、APIの成功とDNSの反映完了が別段階であることを示しています。API応答だけで作業完了とせず、権威DNS、パブリックDNS、HTTP、HTTPSまで確認する必要があります。(Gist)
失敗しやすいポイント
全レコード置換でメール設定を消してしまう
最も大きな事故につながりやすいのが、Aレコードだけを変更したつもりで、MXやTXTを含む全レコードを置き換えてしまうケースです。
特に、次のレコードを含むドメインでは全置換を避けます。
- Google WorkspaceやMicrosoft 365のMXレコード
- SPFレコード
- DKIMレコード
- DMARCレコード
- ドメイン所有権確認用TXTレコード
- 外部サービス用CNAMEレコード
- GitHub Pagesのドメイン検証用TXTレコード
「追加するレコード」だけでなく、変更後に残る全レコードの一覧を確認することが重要です。
ドメイン購入先とDNS管理先を取り違える
レジストラのAPIが正常に動作しても、そのレジストラが権威DNSを管理していなければ公開DNSは変わりません。
変更前に、次の情報を確認します。
dig example.com NS +shortWindowsでは次のように確認できます。
Resolve-DnsName example.com -Type NS返されたネームサーバーを運用しているサービスが、実際に操作すべきDNS事業者です。
CNAMEの接続先へリポジトリ名を付ける
www.example.comのCNAMEを設定する場合、接続先は通常、次の形式です。
username.github.io次のようにリポジトリ名を追加する設定は避けます。
username.github.io/repository-nameDNSのCNAMEはURLパスを扱えないためです。
サブドメインをApexドメインへCNAME接続する
GitHubは、カスタムサブドメインのCNAMEをApexドメインへ向ける構成ではなく、<ユーザー名>.github.ioまたは<組織名>.github.ioへ直接向ける構成を案内しています。
Apexドメインとwwwを両方正しく設定すると、GitHub Pagesが設定したCustom domainに応じてリダイレクトを処理します。(GitHub Docs)
HTTP 200だけで成功と判断する
HTTP 200が返っても、次の問題が残っている場合があります。
- 別サイトのコンテンツが表示されている
- Apexドメインと
wwwのリダイレクト方向が逆 - HTTPS証明書が未発行
- CSSや画像がHTTPで読み込まれている
- GitHub PagesではなくDNS事業者のパーキングページが返っている
レスポンスコードだけでなく、ページタイトルや固有の文字列を確認し、目的のサイトが表示されていることまでテストします。
14分で完了しないことを失敗と判断する
公式デモの約14分は成功例です。DNSキャッシュ、TTL、証明書発行待ち、API側の反映タイミングによって所要時間は変わります。
GitHubの設定画面で「Certificate not yet created」と表示される場合は、DNSレコードの競合や反映待ちを確認します。HTTPS化後は、画像、CSS、JavaScriptにhttp://の参照が残るMixed Contentも確認してください。(GitHub Docs)
企業やチームで利用する場合の管理策
個人の検証サイトでは便利な自動化でも、企業の本番ドメインでは変更管理が必要です。
最低限、次の情報を記録します。
- 実行者
- 対象ドメイン
- 変更前の全DNSレコード
- Copilotが提示した変更案
- 人が承認した変更内容
- 実際にAPIへ送信した内容
- 実行結果
- DNSとHTTPSの確認結果
- ロールバック方法
- 使用したスキルの配布元とバージョン
また、Agent Skillにはスクリプトや実行手順が含まれます。コミュニティ製スキルをユーザー全体へ導入する前に、SKILL.mdと付属スクリプトをレビューし、外部送信先、認証情報の保存場所、DNS更新方式を確認してください。GitHub CopilotのAgent Skillは、リポジトリ単位のプロジェクトスキルとして配置することもできます。初回検証では利用範囲を限定する方法が適しています。(GitHub Docs)
GitHub Pages利用者が次に行うべきこと
既存のGitHub Pagesサイトが正常に動作している場合、今回の情報を理由にDNSやリポジトリを変更する必要はありません。これは必須移行ではなく、Copilot CLIを使った新しい自動化パターンです。
新規サイトの公開作業を効率化したい場合は、次の順序で検証します。
- 業務に影響しない検証用ドメインを用意する
- 変更前のDNSレコードをすべて保存する
- GitHubでドメイン所有権を検証する
- Agent Skillと付属スクリプトを確認する
- Copilotには最初に変更計画だけを出させる
- DNS変更を1操作ずつ承認する
- 権威DNS、パブリックDNS、HTTP、HTTPSを別々に確認する
- 次回デプロイ後もカスタムドメインが維持されるか確認する
- ロールバックを実際に実行できる状態にしておく
GitHub Copilotによる「手動DNS設定ゼロ」は、作業時間を短縮できる一方、DNS変更の責任までAIへ移すものではありません。Copilotに変更案と反復作業を任せ、人が差分、権限、影響範囲、最終結果を確認することが、安全に活用するための基本方針です。
コメント