GitHubが大好きなセキュリティチームのhikaeです。GitHubは先日、GitHub Copilot Free / Pro / Pro+ の入出力などを、オプトアウトしない限りAIモデルの学習に利用する方針変更を発表しました。適用は2026年4月24日を予定しています。Copilot Business / Enterprise の利用者はこの変更の対象外ですが、本当に安心なのでしょうか？
「自社の開発者が必ずBusiness / Enterpriseライセンスの経路で使っている」と言い切れるかという観点から、意図せず学習に使われる経路をどう塞ぐかについて実装方法を整理し、その実装方法を整理し社内で実施した対処法について紹介します。
学習許可のオプトアウトに注意
今回注意すべきはinteractionの範囲です。もしもCopilotユーザーが学習利用をオンにしている場合、プライベートリポジトリ内でCopilotを使用中に生成されたコードスニペットが収集対象となります。また、Web画面上やcommit画面*1など至るところにCopilotはGitHubに組み込まれており、気づいたらCopilotに情報が流れているという状況です。
そして今回採用されているオプトアウト方式では4月24日までに設定を変更しなかった利用者は自動的に学習有効化される挙動になっています。ユーザーが意図しない許可を取ってしまう可能性があり、統制上の大きなリスクがある変更と捉えています。
なぜBusiness / Enterpriseを導入していても安心できないのか
1. どのライセンスで動いているかが見えづらい
Business / Enterprise Copilotの支払いは企業に紐づきますがライセンスは個人ごとに別途付与される方式です。全員にライセンス付与する設定を有効化していない場合は付与していないユーザーはポリシー制御外になります。 利用者は組織に招待されてVS CodeでCopilotが使えるからとそれがBusiness / Enterpriseライセンスとは限りません。 IDE上のサジェスト体験は同じでありプランに移動するまで区別がつきません。実際に自分は検証のためにCopilotを解約してみました。月末までアクティベーション（有効化）されるのですが、月初になってプランが切り替わったことに気づきませんでした。テナントごとにアクセス制限がされる設定は現時点で存在しません。
2. 無料プランが勝手に動く
気づかない理由の1つに無料プランがあります。現在、Copilotサブスクリプションを持っていない場合でもFreeプランに自動サインアップされ、即座に利用を開始できるフローになっています。つまり、組織の管理外の個人アカウントでサインインするだけで、学習対象のFreeプラン経由の通信が開始されるわけです。
3. VSCodeでCopilotがビルトイン
追い打ちをかけるように、VSCode 1.116 のアップデートです。4/15にリリースされたVSCodeからGitHub Copilot Chatがビルトイン拡張として同梱されるようになりました。新規インストールでは、チャット・インラインサジェスト・エージェント機能がセットアップ手順なしで利用可能になります。
つまり「拡張機能の配布をブロックする」というEDRやプロキシレベルの統制はもはや機能しません。デフォルト状態で、すべての開発者マシンにCopilotクライアントが存在するという前提で設計しなおす必要があります。
対応方法
ここから考慮した対応策と実際にどのような意思決定をしたのかを3つ紹介します。
[却下] 1. Copilotライセンスを組織と連動させる
組織で契約しているCopilot Business / Enterpriseのシートが、社員のGitHubアカウント（企業メールドメインで紐付けられたアカウント、またはEMU）に対して確実に割り当てられている状態を作ることが最も確実です。
Business / Enterpriseシートが割り当たっている限り、ビジネス・エンタープライズ顧客との契約でCopilotインタラクションデータのモデル学習利用は禁じられており、GitHubはその約束を守ると明言されており、学習懸念は排除されます。
しかし利用しないユーザーの場合は無駄なコストが発生します。勝手に付属するオプションのせいでGitHub単体の利用ハードルが上がるのは悲しいです。
[部分採用] 2. プライベートアカウント利用者に個人設定を強制する
あくまでもオプトアウトなので、設定さえしておけば学習されるリスク自体は低減可能です*2。GitHub利用者自身に設定をお願いするというのが次に考えられる方法です。しかし、これはあくまで最終手段であり、全てをこれに賭けてしまうのは大量のインシデントを生んでしまいます。
Copilotだけではないですが、チェックすべき個人設定は2点あります。
(a) AI学習オプトアウト
https://github.com/settings/copilot/features にアクセスし、Privacyヘッダー下の "Allow GitHub to use my data for AI model training" を無効化することでオプトアウトできます。
(b) 個人でのPush protection有効化
https://github.com/settings/security_analysis の「User」セクションで、"Push protection for yourself" を有効にする。GitHub上のすべてのユーザーは個人設定からpush protectionを有効化でき、これによりリポジトリ側の設定に依存せず、パブリックリポジトリへのSecretプッシュが保護されます。秘密情報の誤Pushは学習経路に直接関係しないものの、個人アカウントの乗っ取りから発生するサプライチェーンが増えているため併せて徹底したいところです。
アカウント分離のトレードオフ
個人的な感覚として、会社業務用と個人用でGitHubアカウントを分けるという運用方針を設けることが最近のGitHubアカウント運用標準になっています。GitHubの規約変更で、以前は禁止されていたサブアカウント運用が可能になりサインイン中のGitHubアカウントを切り替え可能になったため、「会社のメールドメイン + Business/Enterpriseシート割当済みアカウント」と「個人アカウント」を別物として扱い、業務コードは必ず前者で開く運用を徹底するということが一般的になりました。
freeeではOSS推奨文化なども考慮してこの方法は採用しない意思決定をとっています。その上で、個人と組織はSSOをはじめとした複数のテナント越境を防ぐ検知の仕組みを敷くことを徹底して業務が個人に混ざるリスクを最小化しています。
[採用] 3. 無料プランでの通信をネットワーク層でブロックする
意図しない漏洩を防ぐ上で最も効果的なのが、プラン別エンドポイントのネットワーク制御です。GitHub Copilotの特徴としてトラフィックをプランごとに別ドメインに分けており、ファイアウォールでFree / Pro経路だけを遮断できます。
このsubscription based routingのおかげで、企業ネットワークのファイアウォールでCopilot Business / Enterpriseへのアクセスを明示的に許可し、Copilot Pro / Copilot Freeへのアクセスをブロックできます。
- 許可：
*.business.githubcopilot.com（Business） /*.enterprise.githubcopilot.com（Enterprise） - ブロック：
*.individual.githubcopilot.com（Free / Pro / Pro+）
これは運用コストが低く他サービスへも転用可能な点で有効な制御点です。ライセンス付与漏れや、個人アカウントへの誤サインインが発生しても、通信自体が成立しないため学習経路には乗りません。ファイアウォールが通らない部分で利用されるとこの対策が無効化されるのでそこの考慮はGitHubとは別レイヤでしておくといいでしょう。GitHubでもAuditlogのsource ipを見ることで部分的に発見可能です。
freeeでも複数のAI Agentツールの活用が進んでいる背景もあり、コスト統制も兼ねたライセンスの棚卸しを継続的に実施しています。このルールを適用したことでライセンスが剥奪されたことに気づかずに学習されてしまう懸念を最小限にすることができました。
ただしこの仕組みにも課題があります。社内ネットワークを通らないものは制御されないため社内ネットワーク外ではこの制御をすり抜けます。そのような環境では同等の社内情報にアクセスできないようにする仕組みでカバーします（SSO, IP allow list）。最終的にはGitHub管理側の認証をどこまで強制できているかでここの実行強度に左右します。
まとめ：安全にGitHubを使うために
GitHub CopilotはAI関連プロダクトの中では最もポリシー制御を効かせやすい製品の一つです。AI Control機能が充実しておりMCPサーバー/モデルのホワイトリスト化、Metrics/UsageのダッシュボードとAPI、ここまで揃っているAIプロダクトはかなり少ないです。
近年はLLMプロキシとしての側面が強まっています。逆に言えば、ここを押さえればAI利用のガバナンスの大部分をGitHub側の仕組みに集約できる ということでもあります。AgentHQによってClaude CodeやOpenCodeなどの様々なAI Agentのサーバーとしての統制が実現できる点で今後の期待値は非常に高いです。
一方で、Business / Enterpriseの契約傘下に開発者を確実に収めきれていない場合、GitHubのガバナンスに揺らぎが生じているというガバナンス上のリスクが顕在化してきています。Copilotを導入しているだけでは足りず、
- シートが確実に割り当たっているか
- 漏れているケースでもFree / Pro経路の通信がネットワーク層で遮断されているか
- 個人アカウント利用時の設定が規程化されているか
の3点が揃ってはじめて、「自社のコードはCopilotの学習対象にならない」と言い切れます。方針変更のアナウンスをトリガーに、自組織の設定を見直してみてください。
