🦆
一度でもPublicにしたGitHubのRepositoryはCopilotに学習されるのか?
なぜ作成したのか
- Gigazineで不穏な記事を見かけたので整理してみる
参考
1. 事象の概要
GitHub Copilotは、GitHub上の大量のパブリックリポジトリのコードを学習データとして活用することで、コード補完機能を提供しています。一方で、以下のようなケースが報告されています。
- 一度でも「Public」に設定したリポジトリ(後からPrivateに変更したものも含む) のコードが、Copilotの学習データに含まれてしまっている可能性がある。
- 「Public」から「Private」に変更したあとであっても、すでに学習済みのデータからは抜き取られないため、過去の公開時点でのコードがCopilotの補完結果に影響を与える。
つまり、「過去に一瞬でも公開設定にしたコード」は、Copilotの学習素材として扱われる可能性がある ということです。
2. 発生する具体的なユースケース
-
誤って一時的にリポジトリをPublicにしてしまった場合
- OSSコミュニティなどで検証用のため、一時的にPublicへ切り替えた。
- 結果的にPrivateへ戻しても、その一時的な公開時点のコードが学習データに含まれる可能性がある。
-
就職活動や共同開発でPrivateリポジトリを共有しようとしてPublicにした場合
- 共有手順の簡略化、または相手側のGitHubプランの制限等により、Publicにしてしまう。
- その後、機密情報や個人情報が含まれることに気づいて急いでPrivateに戻しても、既にCopilotの学習データに含まれているリスクがある。
-
ライセンスや権利関係の整理前にPublicにしてしまった場合
- リポジトリを公開し、あとから「著作権やライセンス的に問題がある」と発覚しPrivateに戻した。
- 公開時点で第三者に閲覧・クローンされているだけでなく、Copilotにも学習データとして取り込まれている可能性がある。
-
機密データやアクセストークン等を含むコードを誤って公開していた場合
- Publicにした当時は気づかず、後日機密情報が含まれることに気づいて削除 & Privateへ変更しても、学習データや履歴には残るリスク。
3. 回避するための方法
-
最初からPrivateリポジトリで運用し、一時的にもPublicにしない
- コードが公開されないように注意することが最も確実な対策。
- 誰かに見せたい場合は、プライベートリポジトリへのコラボレーター招待や、GitHub Enterpriseなどの機能を活用する。
-
OSSとして公開する場合は、意図的に公開して良い部分のみアップする
- 機密情報やパスワード、トークン等が含まれないように事前に確認し、
.gitignore
やGitHubのSecret機能等で管理する。 - そもそも「公開しても問題ないコード」だけをリポジトリに含める設計にする。
- 機密情報やパスワード、トークン等が含まれないように事前に確認し、
-
PrivateからPublicに切り替える場合は、念入りにリポジトリ履歴(コミットログ)もチェックする
- 削除したつもりでもコミット履歴に残っている場合、公開と同時に漏洩リスクが発生。
- 公開前に不要なコミットやファイルを再度クリーンアップしてから公開する。
-
万が一Publicにしてしまった場合は、Gitの履歴も含めて再構成 (リポジトリを作り直す) する
- コミットをsquashする、あるいは
git filter-branch
やgit filter-repo
などで不要情報を取り除いた新リポジトリをPrivateで作成し直す。 - ただし、Copilotなどの大規模言語モデルが既に学習したデータからは削除されないため、完全な回避策にはならないが、誤公開による一般への再流出リスクは減らせる。
- コミットをsquashする、あるいは
4. 残存するリスク
-
学習済みモデルからの削除は実質困難
- 一度学習に使われたデータは、モデルにパラメータとして組み込まれてしまう。
- 後から「その特定のデータだけを抜き取る」ことは現状の技術的・運用的にほぼ不可能。
- そのため、Privateへの変更後も該当コードがCopilotの生成に含まれる可能性はゼロにはならない。
-
特定のコード片が再生成されるリスク
- Copilotは類似した問題や文脈に対して、学習データから近いパターンを生成する。
- もしリポジトリ内のコードが独特の場合、Copilotがほぼ同一のコード断片を提案するリスクがある。
- 公開時点で機密情報が混入していれば、そこから復元・再現される可能性もある。
-
誤って推論結果を公開するとさらなる漏洩が発生
- 仮にCopilotが独自推論で出力したコード断片が元の機密情報を暗示していた場合、開発者側がそのまま公開してしまうと被害が拡大する。
- このリスクは特に、機密性の高いアプリケーション開発・企業向けシステムで問題となる。
5. GitHub・Microsoft・OpenAIの見解
5.1 GitHub (Copilotのサービス提供者)
- GitHubはCopilotのFAQやプライバシーに関するドキュメント[1]の中で、「Copilotはパブリックリポジトリのコードを学習している」 と明確に表明している。
- Privateリポジトリの情報は学習に使用しない方針とされているが、「一度公開されたリポジトリも学習対象になる」 という点に関して、GitHubの公式ドキュメント[2]には「公開されているコードは学習データに含まれる可能性がある」という旨の案内がある。
- 「過去に一瞬でも公開されていたリポジトリを学習から除外する仕組み」は現状提供されていない(ローカルマシンで個人向けにブロックするツールやフィルタはない)。
5.2 Microsoft (GitHubの親会社)
- Microsoft全体としても、GitHub Copilotは「開発者生産性を上げるコアサービス」という位置付け。
- プライバシーの懸念に対しては「GitHubのポリシーに準拠」という立場をとっていると考えられる。
- 大規模言語モデルの技術的な側面から「学習済みのデータを部分的に削除することは難しい」という点は、過去にOpenAIとの協力プロジェクトなどで言及されている。
5.3 OpenAI (モデル技術の提供元の一つ)
- GitHub Copilot自体は、OpenAIのCodexモデルやGPT系モデルをベースにしているとされる(現在はGitHubが独自発展させたモデルを使っている可能性もあるが、根幹技術はOpenAIの研究成果に近い)。
- OpenAIは、大規模言語モデルにおけるプライバシーやデータ利用の問題に関して、「個人情報や機密データに関する厳密なデータセット取り扱いは常に課題である」との認識を示している。
- ただし、Copilotのデータ利用ポリシーに関しては「GitHubやMicrosoftの方針に従う」というのが基本スタンスと見られている。
6. まとめ
-
一度でもPublicに設定したリポジトリは、Copilotの学習対象になり得る
- その後Privateに戻しても、「学習済みデータからの除外」は技術的・運用的に行われていない。
- 機密漏洩やライセンス問題のリスクを避けるには、最初からPublicにしない、もしくは公開前のコードクリーニングが必須。
-
具体的な回避策としては「Privateを貫く」「そもそも誤ってPublicにしない」ことが最善
- 公開が必要な場合は、機密情報・重要データを含まないよう管理を徹底し、コミット履歴も検証する。
- 万一誤ってPublicにしてしまった場合は、リポジトリの再構成やコミット履歴のフィルタリングが現実的な対応となるが、Copilotの学習データからの完全除外は望めない。
-
GitHub・Microsoft・OpenAIは「公開されているデータを利用する」という基本方針
- Copilotの学習対象から特定リポジトリを後付けで削除するスキームは用意されていない。
- 技術的にも、大規模モデルの一部学習データを後から完全に「忘れさせる」ことは困難。
-
残存するリスクを理解した上で、日頃からGitHub運用を慎重に
- コードやドキュメントをPublicにする際は、本当に公開可能な内容かを再確認する習慣が重要。
- 機密情報が万が一外部に出ても被害を最小化できるよう、鍵やトークンの定期的なローテーション、万が一のインシデント対応手順の準備を行うことが推奨される。
所感
- 設定ミスによる学習は、GitHubのプライバシーポリシー上受容するほかない状況
- Public設定時点の内容が対象になるため、新規作成当時であればそこまで大きな問題にはならない
- 業務上、プライベートで進めた開発リソースをPublicに変更するというケースはあまり見当たらないけれど、従業員向けに注意喚起はしておいたほうがよさそうな内容。
Discussion