GitHub Copilot の cloud agent を企業で使いたくても、「外部通信をリポジトリごとにしか縛れない」「チームごとに例外設定が増えて統制しにくい」という理由で見送っていた組織は少なくありません。2026年4月3日の GitHub changelog で、組織の firewall settings が Copilot cloud agent に対応し、組織単位で firewall、recommended allowlist、組織共通の custom allowlist、リポジトリ独自ルールの可否をまとめて管理できるようになりました。結論から言うと、GitHub Copilot Business / Enterprise を前提にした企業導入の現実味は、今回の更新でかなり高まりました。 (The GitHub Blog)
ただし、これで安全性が自動的に完成したわけではありません。GitHub の公式 docs は、agent firewall は Bash ツールから起動したプロセスにしか適用されず、MCP サーバーや configured setup steps には適用されないと明記しています。導入判断では、repository access、runner、secrets、社内プロキシの allowlist、Actions minutes と premium requests まで含めて設計する必要があります。 (GitHub Docs)
2026年4月3日の changelog で何が変わったか
今回の更新の本質は、cloud agent の通信制御が「リポジトリ単位の個別設定」から「組織単位の共通ガードレール」に引き上がったことです。GitHub の changelog では、organization admins が全リポジトリに対して firewall の有効・無効、recommended allowlist の有効・無効、organization-wide custom allowlist、repository admins に custom allowlist を許可するかどうかを管理できると案内しています。既定値は Let repositories decide で、従来の挙動を保ちます。 (The GitHub Blog)
| 項目 | 変更前 | 変更後 |
|---|---|---|
| firewall の有効・無効 | リポジトリ単位で設定 | 組織で一括、またはリポジトリに委譲 |
| recommended allowlist | リポジトリ単位で設定 | 組織で一括、またはリポジトリに委譲 |
| custom allowlist | リポジトリごとに管理 | 組織共通の allowlist を追加可能 |
| リポジトリ独自ルール | リポジトリ管理者任せ | 組織側で許可・禁止を制御可能 |
上の整理は 2026年4月3日の changelog と公式ドキュメントを要約したものです。さらに、組織レベルで追加した custom allowlist は全リポジトリに適用され、リポジトリ側で削除できません。組織ルールとリポジトリルールは結合されます。 (The GitHub Blog)
組織 firewall settings で Copilot cloud agent をどこまで制御できるか
Copilot cloud agent にはもともと built-in firewall があり、既定でインターネットアクセスは制限されています。GitHub に接続するための一部ホストは常時許可され、推奨 allowlist も既定で有効です。通信がブロックされると、pull request 本文やコメントに、拒否されたアドレスと実行コマンドの警告が残ります。 (GitHub Docs)
実務で特に大きいのは、organization custom allowlist を使って、社内 package registry や artifact 配布先を組織共通で許可できるようになった点です。GitHub の changelog でも internal package registry が例として挙げられており、同じ例外設定を各リポジトリに複製しなくてよくなります。これは、cloud agent を一部チームだけでなく組織横断で試したい企業ほど効く変更です。 (The GitHub Blog)
allowlist は「ドメイン」と「URL」で粒度が大きく変わる
custom allowlist にはドメインか URL を入れられます。ドメインを入れると、そのドメインとサブドメインまで許可されます。一方、URL を入れると scheme・host・path とその配下に限定されます。たとえば packages.contoso.corp は prod.packages.contoso.corp まで許可しますが、https://packages.contoso.corp/project-1/ なら project-1 配下の HTTPS だけに絞れます。最小権限で設計したいなら、まずは URL 単位から始め、必要なときだけドメインに広げる考え方が扱いやすいです。 (GitHub Docs)
recommended allowlist で許可される主な通信先
GitHub の recommended allowlist は、Debian / Ubuntu / Red Hat などの OS パッケージ配布先、Docker Hub や Azure Container Registry / AWS Elastic Container Registry などの container registry、主要言語の package registry、証明書検証に必要な certificate authority、Playwright MCP サーバー用ブラウザ取得ホストなどを対象にしています。依存関係の取得や build でよく使う通信が中心なので、pilot 初期はこれを有効のまま使う方が無難です。 (GitHub Docs)
firewall だけで安全になるわけではない
ここは誤解しやすいポイントです。GitHub は agent firewall の限界として、Bash ツールから起動したプロセスにしか適用されないこと、MCP サーバーや configured Copilot setup steps には適用されないこと、GitHub Actions の実行環境の中でしか機能しないこと、巧妙な攻撃では回避される可能性があることを明記しています。つまり、組織 firewall settings は強い第一歩ですが、包括的なセキュリティ対策そのものではありません。 (GitHub Docs)
その一方で、cloud agent 側にも別のガードレールはあります。書き込み権限のあるユーザーからの操作にしか反応せず、agent が起票した pull request で GitHub Actions が走る場合は書き込み権限ユーザーの承認が必要です。agent は作業対象リポジトリだけにアクセスでき、既存 PR ブランチか新しい copilot/ ブランチにしか push できず、通常のデフォルトブランチへ直接 push できません。実行時に使える secret / variable も、組織やリポジトリのものがそのまま渡るのではなく、copilot environment に追加したものだけです。さらに、生成コードには CodeQL、secret scanning、dependency analysis が使われます。 (GitHub Docs)
2026年4月3日には、cloud agent の commit 署名にも対応しました。これにより commit は GitHub 上で Verified として表示され、Require signed commits が有効なリポジトリでも使いやすくなりました。各 commit message には session logs へのリンクも入るため、レビューや監査のしやすさも改善しています。 (The GitHub Blog)
企業導入でまず入れたい安全策
最初の pilot でおすすめしやすいのは、次のような「狭く始めて、必要な通信だけ開ける」構成です。これは GitHub の設定仕様と制限を踏まえた、実務寄りの初期設定です。 (GitHub Docs)
| 設定項目 | pilot 初期の考え方 | 理由 |
|---|---|---|
| Repository access | Selected repositories | 影響範囲を限定しやすい |
| Enable firewall | Enabled | 任意ホストへの接続を避ける |
| Recommended allowlist | Enabled | 一般的な依存取得を通しやすい |
| Organization custom allowlist | 必要最小限の URL から追加 | 内部 registry などだけを開けやすい |
| Allow repository custom rules | 初期は Disabled | 例外通信の乱立を防ぎやすい |
| MCP servers on GitHub.com | 必要になるまで広げない | firewall の対象外領域を不用意に増やさない |
この構成で重要なのは、「ビルドが通らないから firewall 全体を Disabled にする」という近道を避けることです。GitHub は firewall を無効にすると任意ホストへの接続を許し、コードや機密情報の流出リスクが高まると明記しています。依存関係取得や社内配布物が原因なら、まず organization custom allowlist で必要最小限の domain / URL を足す方が筋がよいです。 (GitHub Docs)
また、MCP サーバーは別ポリシーで管理され、Business / Enterprise の組織メンバー向けには cloud agent と third-party MCP の両方が既定で無効です。しかも firewall は MCP サーバーに適用されないため、pilot 初期は MCP を急いで開けず、必要性とデータ共有範囲が明確になってから段階的に有効化した方が安全です。 (GitHub Docs)
Copilot cloud agent 導入の前提条件
ライセンスとポリシーの階層
Copilot cloud agent は Pro、Pro+、Business、Enterprise で利用できますが、Business / Enterprise では既定で無効で、管理者による有効化が必要です。組織が enterprise 配下にある場合、enterprise 側で明示的に選んだポリシーは組織側で上書きできません。設定を進める前に、「どこが最終決定権を持つか」を先に確認すべきです。 (GitHub Docs)
リポジトリ単位の開放範囲
組織では Repository access を使って、cloud agent を全リポジトリで使うか、一部リポジトリだけで使うかを選べます。対象リポジトリで agent を有効にすると、cloud agent へのアクセス権を持ち、そのリポジトリに write 権限のあるユーザーは仕事を委任できます。厳しめに始めるなら、まずは Selected repositories が無難です。 (GitHub Docs)
企業ネットワークの allowlist は別で必要
組織 firewall settings は、cloud agent の実行環境から外部へ出る通信を制御する機能です。これとは別に、会社のプロキシや境界 firewall を使っている環境では、Copilot の公開 URL や API 用ドメインを allowlist に入れる必要があります。つまり「agent 側の firewall を設定したから社内ネットワーク側の調整は不要」ではありません。 (GitHub Docs)
コストと runner も設計に入れる
cloud agent は GitHub Actions minutes と Copilot premium requests を消費し、1 セッションごとに premium request を 1 件使います。無料枠を使い切って課金設定もなければ、タスクを実行できなくなります。さらに、cloud agent は既定で ubuntu-latest の GitHub-hosted runner で動きますが、組織単位で larger runner や self-hosted runner を既定にしたり、リポジトリ側の上書きを禁止したりできます。社内リソースへ安全に到達させたい組織では、firewall だけでなく runner 設計が実質的な前提条件です。 (GitHub Docs)
見落としやすいポイント
- content exclusions が効く前提で考える
Copilot cloud agent は content exclusions を考慮しません。通常の Copilot では除外したいファイルでも、cloud agent では閲覧・更新できる前提で設計した方が安全です。 (GitHub Docs) - branch protection の課題がすべて解消したと思い込む
signed commits 対応でRequire signed commitsとの相性は改善しましたが、特定の commit author しか許さないルールなど、まだ cloud agent を block しうる設定は残ります。 (The GitHub Blog) - enterprise policy だけで全利用者を止められると思う
GitHub の docs では、enterprise の Copilot policy は、その enterprise から Copilot ライセンスを割り当てたユーザーにしか効かないと説明されています。Pro+ ユーザーが enterprise のリポジトリにアクセスできる場合は、その policy だけでは制御しきれません。絶対に使わせたくないリポジトリは、repository access や enterprise 側の全リポジトリ block まで考える必要があります。 (GitHub Docs) - domain allowlist と URL allowlist の違いを軽く見る
domain はサブドメインまで広く許可し、URL は scheme・host・path 配下に限定します。社内 artifact 配布で「一部パスだけ使いたい」ケースでは、domain を入れると想定以上に広がりやすいです。 (GitHub Docs) - pilot の予算設計を後回しにする
1 回のセッションで premium request を 1 件使い、同時に GitHub Actions minutes も消費します。技術検証のつもりでも、バックログの issue をまとめて振ると使用量は意外に増えます。 (GitHub Docs)
結局、企業導入の現実味は増したのか
答えは「増した。ただし、条件付き」です。今回の organization firewall settings 対応で、外部通信の既定値と例外を組織で一括管理できるようになり、同じ 2026年4月3日には runner の組織管理と commit signing も加わりました。通信先、実行基盤、署名という企業ガバナンスの主要論点が同時に前進したのは大きいです。 (The GitHub Blog)
一方で、firewall は包括的な防御ではなく、content exclusions の非適用や corporate proxy 側の allowlist、コスト管理といった論点は残ります。したがって、公開 SaaS や一般的な package registry 中心の開発組織では導入しやすくなりましたが、閉域性や高い規制対応が求められる組織では、まず対象リポジトリを絞った pilot から始める方が現実的です。 (GitHub Docs)
今すぐ始めるならこの順番
Repository accessをSelected repositoriesにし、影響の小さいリポジトリから pilot を始める。cloud agent は組織単位で対象リポジトリを選べます。 (GitHub Docs)- 組織 firewall settings は
Enable firewall = Enabled、Recommended allowlist = Enabled、Allow repository custom rules = Disabledを初期値にする。まずは repo ごとの場当たり的な例外追加を止める方が統制しやすいです。 (GitHub Docs) - 社内 package registry や artifact 配布先が必要なら、organization custom allowlist に domain ではなく URL で最小限追加し、必要時だけ広げる。 (GitHub Docs)
- 内部リソースへ接続が必要なら、runner type を組織で固定する。GitHub は larger runner や self-hosted runner を既定にでき、repo 側の上書きも禁止できます。 (GitHub Docs)
- corporate proxy の allowlist、Actions minutes、premium requests の予算、コードレビュー手順を同時に決める。cloud agent の commit は署名され、session logs への追跡もできますが、最終レビューとテストは人が担う前提が必要です。 (GitHub Docs)
組織 firewall settings の追加は、Copilot cloud agent を「便利そうだが統制しにくい機能」から「条件を満たせば企業展開を設計できる機能」へ一段進めた更新です。まずは小さく開き、通信先・runner・レビュー・予算を組織で揃える。この順番で進めれば、今回の changelog は十分に実利があります。 (The GitHub Blog)
コメント