はじめに
GitHub Copilotはコード補完やチャット機能で開発効率を大きく引き上げる一方、社内コードや仕様をどこまでAIに渡してよいのか、判断に迷う場面は少なくありません。特に機密情報や顧客データを含むリポジトリを扱う場合、情報漏えいや学習利用の不安が先行し、導入を見送るケースも耳にします。
この記事では、公式ヘルプや公開ドキュメント、セキュリティ専門家のレポートをもとに、Copilotにコードを渡す際のリスクと対策を整理します。プラン別のデータ取り扱いの違い、除外設定の具体手順、安全に使うための運用例までをまとめ、読者が自分の使い方に合うか判断できる材料を提供します。
GitHub Copilotに渡す前に分けたい情報の種類
Copilotにコードを読ませる前に、まずはリポジトリ内の情報をいくつかのカテゴリに分けて考えることが有効です。公開しても問題ないコードと、機密性が高いコードを同じように扱うと、意図しない漏えいにつながる可能性があります。
公開コードと社内コードの線引き
オープンソースとして公開されているコードや、個人の学習用プロジェクトは比較的リスクが低いといえます。一方、社内システムの認証情報、顧客データを扱うロジック、未公開のアルゴリズムを含むコードは、Copilotに渡す範囲を慎重に決める必要があります。
公式情報によると、Copilotは編集中のファイルとその周辺文脈を参照して提案を生成します。リポジトリ全体をそのまま学習するわけではありませんが、開いているファイルに機密情報が含まれていると、それが提案生成のコンテキストに含まれる可能性があります。したがって、機密性の高いコードを編集する際は、Copilotを一時的に無効にするか、後述の除外設定を活用することが推奨されます。
除外したいファイルや秘密情報の具体例
以下のようなファイルや情報は、Copilotに読ませる範囲から外すことを検討します。
- 環境変数ファイル（.env）
- APIキーやトークンを直書きした設定ファイル（config.json、database.ymlなど）
- 認証情報を含むシークレット管理ファイル
- 顧客情報や個人情報を含むデータファイル
- 未公開の特許関連コードやアルゴリズム
これらのファイルをCopilotの提案対象から外すには、VSCodeの設定で除外パターンを指定します。具体的な手順は後述しますが、まずは「何を渡したくないか」をリストアップすることが第一歩です。
プラン別に見るデータの取り扱いと学習利用の違い
Copilotのデータ取り扱いは、利用するプランによって大きく異なります。個人向けと企業向けでは、コードの保存やモデル再学習への利用に関するポリシーが異なるため、自分の契約プランを確認することが重要です。
個人向けプラン（Free、Pro、Pro+）の注意点
個人向けプランでは、カーソル前後のコードスニペットがGitHubに一時的に収集され、モデル改善に使われる可能性があります。ただし、設定からオプトアウトすることが可能です。
GitHubの設定画面で「Allow GitHub to use my data for product improvements」のチェックを外すと、コードスニペットが保存されなくなります。この設定は個人のアカウント単位で有効ですが、組織として統制する機能は個人プランにはありません。そのため、複数人で使う場合は各自が設定を確認する必要があります。
企業向けプラン（Business、Enterprise）の保護機能
Businessプラン（月額19ドル／ユーザー、2026年4月時点の公称価格）以上では、作業中のコードがモデルの再学習に使用されないことが契約で明記されています。データは保持されず、改善にも使われません。
さらに、EnterpriseプランではIP補償（知的財産権の侵害に対する保護）が条件付きで提供され、組織全体でのポリシー設定や監査ログの取得が可能です。自社コードを学習に使わせたくない場合は、Business以上が第一候補となります。
プラン別の比較表
| 項目 | 個人向け（Free/Pro/Pro+） | 企業向け（Business/Enterprise） |
|——|—————————|——————————–|
| コードの学習利用 | オプトイン（既定で利用される可能性あり、オプトアウト可） | 学習利用なし（契約で明記） |
| データの保持 | 設定次第で一時保存 | 保持されない |
| IP補償 | なし | Enterpriseで条件付き提供 |
| 組織ポリシー設定 | 不可 | 可（Enterpriseで詳細設定） |
| 監査ログ | なし | Enterpriseで利用可 |
表の内容は2026年4月時点の公開情報に基づきます。最新の条件は公式ドキュメントで必ず確認してください。
機密情報が漏れる仕組みと実際のリスク
Copilotが機密情報を提案してしまうメカニズムを理解すると、なぜ除外設定やプラン選択が重要なのかが明確になります。
学習データに由来する「記憶」の問題
CopilotはGitHub上の膨大な公開コードを学習しています。その中には、過去に誤ってコミットされたAPIキーやパスワードが含まれている場合があります。モデルはこれらの「記憶」を利用して、意図せず機密情報を提案してしまうことがあります。
GitGuardianの調査（2025年7月時点）によると、Copilotの8,127件の提案のうち2,702件に「機密情報らしき記述」が含まれ、提案1回あたり平均0.33件の「本物の機密情報」が出力された可能性が報告されています。また、提案コードの35%にセキュリティ上の脆弱性が見つかり、CWE-798（ハードコードされた認証情報）の例も確認されています。
ハードコードされた認証情報の危険性
ソースコードに直接書かれたパスワードやAPIキーは、Copilotの提案を通じて新たなコードに埋め込まれる可能性があります。これが本番環境にそのまま取り込まれると、重大なセキュリティインシデントにつながりかねません。
提案コードをそのまま受け入れるのではなく、必ずレビューし、認証情報が含まれていないかを確認する習慣が求められます。また、後述するPublic Code Filterを有効にすると、公開コードと一致する提案を抑制できます。
VSCodeでの具体的な除外設定手順
Copilotに特定のファイルを読ませないようにするには、VSCodeの設定ファイルで除外パターンを指定します。以下は、Qiitaの記事（2025年10月更新）で紹介されている手順を参考にしたものです。
設定ファイル（settings.json）の編集方法
1. VSCodeで設定画面を開く（Ctrl + , または Cmd + ,）
2. 画面右上の「設定（JSON）を開く」アイコンをクリック
3. 開いたsettings.jsonの最下部に、以下のコードを追記する
“`json
"github.copilot.advanced": {
"excludeFiles": [
"**/*.env",
"**/config.json",
"/example/",
"/example2/",
"**/database.yml"
]
}
“`
この設定により、指定したパターンに一致するファイルはCopilotの提案対象から除外されます。`/example/`のようにディレクトリ単位での除外も可能です。
除外パターンの設計ポイント
- 環境変数ファイルは`**/*.env`で全階層を対象にする
- 設定ファイルは拡張子やファイル名で個別に指定する
- サンプルコードやテスト用のディレクトリは、チーム内で合意した上で除外する
- 除外パターンは定期的に見直し、新しい機密ファイルが追加されたら更新する
チームで安全に使うための組織設定と運用
企業やチームでCopilotを導入する場合、個人の設定任せにせず、組織全体でポリシーを定めることが重要です。
Enterpriseプランで可能なポリシー制御
Enterpriseプランでは、管理者が組織全体に対して以下のようなポリシーを設定できます。
- 学習データへの利用を無効化
- Public Code Filterの強制有効化
- 特定のリポジトリやファイルタイプの除外
- 監査ログの取得と分析
これらの設定により、開発者個人の判断に依存せず、組織として一貫したセキュリティレベルを維持できます。
レビューと静的解析の組み合わせ
Copilotの提案コードをそのままマージするのではなく、以下のプロセスを組み合わせることでリスクを低減できます。
- コードレビューで認証情報や脆弱性の有無を確認する
- 静的解析ツール（SonarQube、ESLintなど）で自動チェックする
- GitHubのSecret Scanning機能を有効にし、コミット前にシークレットを検出する
特に、Secret Scanningはプッシュされたコードから機密情報を検出し、アラートを出すため、Copilotの提案に限らず全般的な対策として有効です。
MCP連携時の注意点
CopilotのMCP（Model Context Protocol）連携機能は、外部ツールやサービスと連携できる強力な機能ですが、データの第三者流出口になりやすい面があります。連携する際は、最小権限の原則を守り、人間の最終承認を必須とする運用が推奨されます。組織ポリシーで外部MCPを制御し、不用意なデータ送信を防ぎます。
安全に使うための運用例と確認事項
ここまでの内容を踏まえ、実際の開発現場でどのようにCopilotを使い分けるか、具体的な運用例を紹介します。
プロジェクトの機密レベルに応じた使い分け
- 公開予定のOSSプロジェクト：比較的リスクが低いため、Copilotを積極的に活用できる
- 社内ツール開発：認証情報を含まないロジック部分のみCopilotを有効にし、設定ファイルは除外する
- 顧客データを扱う本番システム：機密性の高いファイルはCopilotを無効にし、コードレビューを厳格化する
- 研究開発段階のアルゴリズム：未公開の知的財産を含むため、Copilotの利用を控えるか、完全にオフラインの環境で作業する
導入前に確認すべきチェックリスト
1. 利用プランは個人向けか企業向けか
2. コードの学習利用オプトアウト設定は有効か
3. 機密ファイルの除外設定は適用されているか
4. Public Code Filterは有効か
5. コードレビューと静的解析のプロセスは整備されているか
6. Secret Scanningは有効か
7. チームメンバー全員がポリシーを理解しているか
これらの項目を一つずつ確認することで、Copilotを安全に導入できる状態かどうかを判断できます。
向いている人・向いていない人
向いている人
- 公開コードや学習用プロジェクトで開発効率を上げたい個人開発者
- 企業向けプランで組織ポリシーを設定できるチームリーダー
- コードレビューや静的解析のプロセスがすでに整っている開発チーム
向いていない人
- 機密情報を多く扱い、コードの外部送信が一切許容されない環境
- 個人プランで組織的な管理ができないまま、チーム全員が使う場合
- 提案コードをそのまま本番環境に反映するような運用をしている現場
よくある質問
Copilotにリポジトリ全体を渡しても大丈夫ですか？
Copilotはリポジトリ全体を直接学習するわけではなく、編集中のファイルと周辺文脈を参照します。ただし、開いているファイルに機密情報が含まれていると、提案生成に利用される可能性があります。リポジトリ全体を「渡す」というより、編集中のコードが送信されるイメージです。機密ファイルは事前に除外設定を行いましょう。
個人プランでも企業のコードを安全に使えますか？
個人プランでは、コードスニペットがGitHubに一時収集され、モデル改善に使われる可能性があります。オプトアウト設定は可能ですが、組織全体での統制はできません。企業のコードを扱う場合は、Businessプラン以上への移行を検討することをお勧めします。
除外設定をしても完全に安全ですか？
除外設定はCopilotが提案を生成する際の参照対象から外すもので、コード自体が外部に送信されないことを保証するものではありません。Copilotは提案生成のために必要なコンテキストをGitHub側に送信するため、ファイルを開いているだけで送信される可能性があります。機密性の高いコードは、Copilotを一時的に無効にするか、別のエディタで編集するなどの対策を併用してください。
Public Code Filterとは何ですか？
Public Code Filterは、GitHub上の公開コードと一致する提案を検出し、ブロックする機能です。これにより、OSSのコードがそのまま提案されることを防ぎ、ライセンス侵害のリスクを低減できます。設定で有効にすることが推奨されます。
生成されたコードの著作権はどうなりますか？
Copilotが生成したコードの著作権については、GitHubの利用規約に基づきます。EnterpriseプランではIP補償が提供されますが、未改変の提案にのみ適用されるなどの条件があります。詳細は公式ドキュメントを確認し、必要に応じて法務専門家に相談してください。
まとめ
GitHub Copilotにリポジトリや仕様を渡す範囲で迷うときは、まず情報の機密レベルを整理し、プランに応じたデータ取り扱いを確認することが大切です。個人向けプランではオプトアウト設定を忘れずに行い、企業向けプランでは組織ポリシーを活用することで、多くのリスクを低減できます。
除外設定やレビュープロセスを組み合わせ、Copilotの利便性を活かしながら安全に運用する道は十分にあります。一方で、絶対に外部に送信できないコードはCopilotの対象から外す判断も必要です。この記事で紹介したチェックリストをもとに、自社の状況に合った使い方を見つけてください。
コメント