GitHub Copilot Business — セキュリティ機能の全体像と企業導入のポイント

1. はじめに

GitHub Copilot Business（以下 GHCB）は、開発者の生産性を飛躍的に高める AI コーディング支援ツールです。一方で、企業が導入を検討する際に最も懸念されるのがセキュリティとデータプライバシーです。

本記事では、GHCB を企業ネットワークに安全に導入するための 4 つの主要セキュリティ機能を解説します。

Firewall 許可リストと Copilot 専用ドメインの分離
Data Residency によるテナント専用 FQDN の割り当て
企業プロキシを使った個人アカウント利用の制限
GitHub Copilot のデータ取り扱いとモデル学習利用の制限

対象プラン: GitHub Copilot Business / GitHub Copilot Enterprise 対象読者: 情報システム部門、セキュリティ担当者、GitHub Enterprise 管理者

2. Firewall 許可リストと Copilot 専用ドメインの分離

2.1 なぜドメインが分離されているのか

GitHub Copilot の AI サービスは、通常の GitHub.com（github.com、api.github.com）とは異なる専用ドメインで動作します。この設計により、企業のネットワーク管理者は以下の運用が可能になります。

Copilot トラフィックだけを個別に監視・制御できます。
Copilot を使わないユーザーには Copilot ドメインへのアクセスを閉じたままにできます。
プラン別のドメインを使い分けることで、Individual プランをブロックできます。

2.2 許可すべきドメイン一覧

Copilot を企業ネットワークで利用するために、Firewall / プロキシで許可すべき URL は以下のとおりです。

2.2.1 Copilot 専用ドメイン（github.com と分離）

ドメイン	用途
`*.githubcopilot.com`	Copilot AI サービス全般
`*.business.githubcopilot.com`	Copilot Business 専用
`*.enterprise.githubcopilot.com`	Copilot Enterprise 専用
`copilot-proxy.githubusercontent.com`	サジェスチョン API
`copilot-telemetry.githubusercontent.com`	テレメトリ送信
`origin-tracker.githubusercontent.com`	コード参照トラッキング
`default.exp-tas.com`	機能フラグ / A/B テスト
`copilot-reports-*.b01.azurefd.net`	利用メトリクスレポート

2.2.2 GitHub 本体（認証・API・管理に必要）

ドメイン	用途
`github.com`	Web UI / 認証
`api.github.com`	REST / GraphQL API
`api.github.com/copilot_internal/*`	Copilot 内部 API
`collector.github.com`	テレメトリ収集

2.2.3 Data Residency 利用時（後述）

ドメイン	用途
`ENTERPRISE.ghe.com`	テナント専用エンドポイント
`*.ENTERPRISE.ghe.com`	サブドメイン

ポイント: *.individual.githubcopilot.com は意図的にブロックすることで、社内ネットワークから Individual プランの Copilot を利用できないようにすることが推奨されます。

2.3 ドメイン分離の利点

text

通常の GitHub 通信:   github.com / api.github.com
                        ↓ 別ドメイン
Copilot AI 通信:      *.githubcopilot.com / copilot-proxy.githubusercontent.com

この分離により、既存の GitHub.com 許可ルールに影響を与えずに Copilot の通信だけをファインチューニングできます。通信は HTTPS（ポート 443）を前提に設計されています。

参考: 最新の許可リストは Copilot allowlist reference を必ず確認してください。ドメインは今後追加・変更される可能性があります。

3. Data Residency — テナント専用 FQDN の割り当て

3.1 Data Residency とは

GitHub Enterprise Cloud with Data Residency は、企業のデータを特定の地理的リージョン内で処理・保管するための機能です。この機能を利用すると、通常の github.com ではなく ghe.com ドメイン配下にテナント専用の FQDN が割り当てられます。

text

通常:          github.com/your-org
Data Residency: your-enterprise.ghe.com

3.2 テナント専用 FQDN の仕組み

Data Residency を有効化すると、企業には以下の形式で固有のエンドポイントが付与されます。

項目	値
Web UI	`https://ENTERPRISE.ghe.com`
API	`https://api.ENTERPRISE.ghe.com`
パッケージ	`https://pkg.ENTERPRISE.ghe.com`
Git 操作	`https://ENTERPRISE.ghe.com/*.git`

ENTERPRISE 部分には企業が選択したサブドメイン名が入ります（例: octocorp.ghe.com）。
サブドメインは作成後に変更できません。慎重に選択する必要があります。
すべてのアクセスは Enterprise Managed Users（EMU）として IdP 経由で認証されます。

3.3 対応リージョン

2026 年 3 月時点で以下のリージョンが利用可能です（Azure インフラストラクチャを基盤）。[^1]

リージョン	備考
EU	2024 年提供開始
US	2025 年追加
日本	2025 年追加
オーストラリア	2025 年追加

3.4 GitHub Copilot と Data Residency の関係

Data Residency 環境では、利用できる機能やセットアップ手順は GitHub.com と一部異なります。ただし、GitHub Copilot の認証 URL は GHE.com の専用ドメイン経由で利用できます。公開ドキュメントから確認できるポイントは以下のとおりです。

専用ドメインでの分離: SUBDOMAIN.ghe.com と *.SUBDOMAIN.ghe.com を使って、GitHub.com とは別のエンドポイントで運用できます。
EMU 前提のアクセス制御: GHE.com では Enterprise Managed Users を前提に認証とアクセス制御を構成します。
機能差分への注意: GitHub Copilot を含め、一部の機能は GHE.com で追加設定が必要だったり、利用可否に差分があります。

注意: Data Residency は GitHub Enterprise Cloud の追加機能であり、別途契約が必要です。利用を検討する場合は GitHub の営業チームに問い合わせてください。

4. 企業プロキシによる個人アカウント利用の制限

4.1 背景と課題

企業が GitHub Copilot Business を導入しても、開発者が社内ネットワークから個人の GitHub アカウントで Copilot Individual にアクセスしてしまう可能性があります。この場合、以下のリスクが発生します。

企業のセキュリティポリシーが適用されません。
監査ログに記録されません。
企業コードが Individual プランのデータポリシーで処理される可能性があります。

4.2 Enterprise Access Restrictions の仕組み

GitHub は Enterprise Access Restrictions 機能を提供しています（2025 年 9 月 GA）。[^2] この機能を使うと、企業プロキシで sec-GitHub-allowed-enterprise HTTP ヘッダーを注入することで、許可されたエンタープライズアカウントでのみ GitHub にアクセスできるように制限できます。

4.3 設定手順

4.3.1 ステップ 1: GitHub 側で機能を有効化

GitHub Enterprise の管理コンソールにログインします。
Settings → Authentication security → Enterprise access restrictions を開きます。
Enable enterprise access restrictions を有効にします。
表示される Enterprise ID をコピーします。

4.3.2 ステップ 2: 企業プロキシにヘッダー注入を設定

プロキシ（または Firewall）で、GitHub 関連ドメインへの HTTPS リクエストに以下のヘッダーを注入する設定を行います。

text

sec-GitHub-allowed-enterprise: YOUR-ENTERPRISE-ID

対象ドメインは以下のとおりです。

github.com
api.github.com
*.githubcopilot.com

4.3.3 ステップ 3: プロキシ設定例（Squid の場合）

squid

# GitHub Enterprise Access Restrictions
acl github_domains dstdomain .github.com .githubcopilot.com .githubusercontent.com
request_header_add sec-GitHub-allowed-enterprise "YOUR-ENTERPRISE-ID" github_domains

4.3.4 ステップ 4: 動作確認

管理対象アカウント（EMU）: 通常どおり GitHub / Copilot にアクセスできます。
個人アカウント: GitHub.com のログインページでアクセスが拒否されます。

4.4 複数エンタープライズ対応

2025 年 10 月のアップデートにより、カンマ区切りで最大 20 の Enterprise ID を 1 つのヘッダーに指定できるようになりました。[^3] グループ企業やホールディングス構成での運用にも対応しています。

text

sec-GitHub-allowed-enterprise: ENTERPRISE-ID-1, ENTERPRISE-ID-2, ENTERPRISE-ID-3

4.5 注意事項

プロキシでの SSL/TLS インスペクション（HTTPS 復号） が必須です。暗号化された通信の中にヘッダーを注入する必要があるためです。
この制御は社内ネットワーク経由のアクセスに対してのみ有効です。社外（自宅 Wi-Fi 等）からのアクセスには適用されません。
Data Residency（ghe.com）を利用している場合は、ドメイン自体がテナント専用のため、この制御が不要なケースもあります。

5. GitHub Copilot のデータ取り扱い

5.1 データフローの概要

GitHub Copilot Trust Center では、GitHub Copilot が扱うデータとして、Prompts、Suggestions、Feedback Data、User Engagement Data が明示されています。したがって、「まったくデータを扱わない」と理解するのではなく、どのデータが処理され、何に使われるのかを分けて確認することが重要です。

5.2 データの種類と保持ポリシー

公開情報から明確に確認できるのは、Business / Enterprise のデータが AI モデルの学習には使われないことです。一方で、プロンプト、サジェスチョン、利用状況データの具体的な保持期間や、すべての機能に共通する一律の保持ルールまでは、今回確認した公開資料だけでは断定できませんでした。

また、Trust Center では User Engagement Data について、pseudonymous identifiers を含む利用データとして説明されています。運用設計では、保持の有無だけでなく、どの種類のメタデータが収集対象なのかも確認しておく必要があります。

5.3 サードパーティモデルプロバイダーとの契約

Copilot は OpenAI、Anthropic、Google、xAI など複数のモデルプロバイダーを利用しています。公開ドキュメントから確認できる内容は、各プロバイダーごとに条件が異なるという点です。[^4][^5]

OpenAI: GitHub は zero data retention agreement を維持しています。
Anthropic: 一般提供されている機能では zero data retention agreement がありますが、beta / public preview の一部機能は対象外です。
Google: GitHub データをモデル学習に利用しないことが明記されています。
xAI: zero data retention API policy で運用されると説明されています。

このため、「すべての第三者モデルが常にゼロログ・ゼロ保持で動作する」と一括りにするのではなく、利用するモデルと機能の提供段階ごとに確認するのが安全です。

5.4 Individual プランとの違い

公開情報として明確に比較しやすいのは、ネットワーク制御、ポリシー管理、監査性 の観点です。

Individual: ユーザー個人の設定と契約条件に依存します。
Business / Enterprise: 組織または Enterprise 管理者がポリシー、ネットワーク制御、監査ログなどを使って統制できます。

なお、監査ログについては、Copilot に関する設定変更やライセンス変更、Web 上の一部エージェント活動は記録できますが、ローカル IDE から送信されたプロンプトそのもののような client session data は標準の監査ログには含まれません。

5.5 追加のセキュリティ対策

Content Exclusions: 特定のファイルパスやパターンを Copilot のコンテキストから除外できます。.env ファイルやシークレット設定ファイルなど、機密性の高いファイルを送信対象から外すことができます。
通信の暗号化: IDE と Copilot サービス間のすべての通信は TLS で暗号化されます。
コンプライアンス認証: SOC 1、SOC 2、ISO 27001、ISO/IEC 42001:2023 等の認証を取得しています。[^4]

参考: 詳細なデータ取り扱いポリシーは GitHub Copilot Trust Center で確認できます。

6. 導入チェックリストとおすすめの活用シーン

GitHub Copilot Business は、企業のセキュリティ要件を満たすために多層的な保護機能を提供しています。以下のチェックリストを参考に導入を進めてください。

6.1 導入前チェックリスト

Firewall / プロキシに Copilot 専用ドメイン（*.business.githubcopilot.com 等）を許可リストに追加しています。
*.individual.githubcopilot.com をブロックリストに追加しています。
Data Residency の必要性を評価し、必要な場合は ghe.com のテナントを契約しています。
企業プロキシに sec-GitHub-allowed-enterprise ヘッダー注入を設定しています。
SSL/TLS インスペクションがプロキシで有効化されています。
Content Exclusions で機密ファイルを除外設定しています。
監査ログの確認体制を整備しています。

6.2 こういうチームにおすすめ

金融・医療・公共: Data Residency + プロキシ制御を組み合わせ、厳格なコンプライアンスを実現したいチーム
大規模エンタープライズ: 複数組織をまたいだ Copilot ライセンス管理と、Individual プランのブロックを徹底したいチーム
セキュリティ意識の高いスタートアップ: 学習利用の制限、ポリシー管理、監査性を整理して顧客やステークホルダーに説明したいチーム

7. まとめ

GitHub Copilot Business の企業導入では、Firewall によるドメイン分離、Data Residency によるテナント専用 FQDN、企業プロキシでの個人アカウント制限、そしてデータ取り扱いポリシーの理解という 4 つの観点を押さえることが重要です。いずれも公式ドキュメントに沿って段階的に設定すれば、セキュリティ要件と開発生産性を両立できます。