開発効率を飛躍的に高めるGitHub Copilot。コード補完やチャット、レビュー支援まで受けられる便利さから、個人開発者だけでなく企業での導入も広がっています。しかし、業務で使う際に必ず立ちはだかるのが「社内コードや仕様書をどこまでCopilotに読み取らせてよいのか」という不安です。実際に「リポジトリ全体を渡しても大丈夫だろうか」「機密情報が含まれるファイルをうっかり開いたままCopilotを使うと情報漏えいにならないか」といった声が、開発チームの間で聞かれます。
本記事では、GitHub Copilotにコードや情報を渡す範囲を迷っている方に向けて、公式情報や公開されている調査データをもとに、安全に使い分けるための判断材料を整理します。プラン別のデータ取り扱いの違い、エディターでの除外設定、組織で導入する際のガバナンスまで、実務目線で順を追って解説します。
まず理解したいCopilotの「見ている範囲」
GitHub Copilotは、エディターで開いているファイルの内容や、カーソル周辺のコード、コメントなどをリアルタイムに読み取り、提案を生成します。リポジトリ全体を事前に読み込んでいるわけではなく、あくまで今編集している文脈をもとに補完する仕組みです。ただし、ここで注意すべきは、Copilotが提案のためにコードスニペットをGitHubのサーバーに送信しているという点です。
公式ドキュメントによると、必要なコンテキストはGitHub側で処理され、応答が返されます。保存済みのリポジトリ全体をそのまま送るわけではないものの、編集中のファイルに機密情報が含まれていれば、それが外部に送信される可能性があります。特に、APIキーやデータベース接続文字列、認証トークンなどをハードコードした設定ファイルを開いたままCopilotを使うと、意図せずそれらが送信対象になり得ます。
プランによるデータ取り扱いの違いを押さえる
GitHub Copilotには、個人向けのFree、Pro、Pro+プランと、企業向けのBusiness、Enterpriseプランがあります。データの保存や学習利用の扱いはプランによって明確に異なります。
個人向けプラン（Free/Pro/Pro+）
個人向けプランでは、コードスニペットがGitHubに一時収集され、製品改善のために利用される可能性があります。デフォルトでは「Allow GitHub to use my data for product improvements」が有効になっており、この設定をオフにしない限り、入力したコードや提案データが学習に回る可能性を否定できません。
設定を変更するには、GitHubのアカウント設定から「Settings」→「Copilot」→「Features」へ進み、該当のチェックボックスを外します。この操作により、個人向けプランでもコードスニペットがGitHubに保存されなくなるとされています。
企業向けプラン（Business/Enterprise）
BusinessおよびEnterpriseプランでは、作業中のコード（プライベートリポジトリを含む）がモデルの再学習に使用されることはありません。データは保持されず、改善にも使われないと明示されています。組織全体の設定でコントロールできるため、管理者がポリシーを適用しやすいのが特徴です。
したがって、社内コードや機密性の高い仕様書を扱う場合は、企業向けプランの利用が大前提となります。個人向けプランで業務コードを扱うことは、情報漏えいリスクを高めるため避けるべきです。
機密情報が漏れるリスクは実際にあるのか
セキュリティ企業GitGuardianの調査によると、GitHub Copilotの8,127件の提案のうち2,702件に「機密情報らしき記述」が含まれ、提案1回あたり平均0.33件の「本物の機密情報」が出力された可能性があると報告されています。また、提案コードの約35%にセキュリティ上の脆弱性が見つかり、ハードコードされた認証情報（CWE-798）の例も確認されています。
これは、GitHub Copilotが学習した公開コードの中に、過去に誤ってコミットされたAPIキーやパスワードなどが含まれているために起こります。モデルがその「記憶」をもとに、意図せず機密情報を提案してしまうのです。したがって、Copilotが生成したコードをそのまま本番環境に適用すると、思わぬ形で秘密情報が混入するリスクがあります。
また、入力段階でのリスクも無視できません。開発者がAPIキーや内部ドキュメントを開いた状態でCopilotを使うと、それらが一時的にGitHubのサーバーへ送信されます。GitHub公式は送信データを学習に再利用しないとしていますが、リスクがゼロになるわけではありません。
エディターでできる具体的な除外設定
VSCodeを例に、Copilotに読み取らせたくないファイルやディレクトリを除外する方法を見ていきましょう。
特定ファイルをCopilotの提案対象から外す
1. VSCodeの設定を開きます（Windows: `Ctrl + ,`、Mac: `Cmd + ,`）。
2. 設定画面右上の「設定 (JSON) を開く」をクリックし、`settings.json`を開きます。
3. 以下のような設定を追加します。
“`json
"github.copilot.advanced": {
"excludeFiles": [
"**/*.env",
"**/config.json",
"/example/",
"**/database.yml"
]
}
“`
`**/*.env`はすべての階層の`.env`ファイルを、`/example/`は`example`ディレクトリ以下の全ファイルを対象から外します。この設定により、環境変数ファイルやデータベース設定ファイルなどをCopilotの提案対象から確実に除外できます。
公開コードフィルターの活用
GitHub Copilotには、公開コードと一致する提案をブロックするフィルター機能があります。これは、学習元の公開コードをそのまま提案してしまうことを防ぐためのもので、設定から有効にできます。GitHubのアカウント設定で「Copilot」→「Policies」→「Suggestions matching public code」を「Block」に設定することで、著作権侵害やライセンス違反のリスクを低減できます。
組織で安全に使うための運用ルール
技術的な設定だけでなく、開発チームとしての運用ルールも欠かせません。以下のような対策を組み合わせることで、リスクを大幅に抑えられます。
機密情報を含まないプロンプト設計
Copilot Chatを使う際、プロンプト（質問文）に直接APIキーや顧客データを貼り付けないよう、チーム内でルール化します。仕様を質問する場合も、具体的な値はマスキングするか、抽象化した例で問い合わせる習慣をつけます。
コードレビューと静的解析の徹底
Copilotが生成したコードは、必ず人間の目でレビューします。特に、認証情報やセキュリティに関わる部分は、静的解析ツール（SonarQubeやESLintのセキュリティルールなど）と組み合わせてチェックします。GitHubのSecret ScanningやDependabotを有効にしておけば、コミット前に機密情報の混入を検出できる可能性が高まります。
ガバナンスと教育
組織として「AIと人の責任分界」を明文化し、Copilotの利用ガイドラインを策定します。例えば、「機密性の高いリポジトリではCopilotを無効にする」「生成コードの本番投入前には必ずセキュリティレビューを実施する」といったルールを定め、定期的に研修を行います。
向いている使い方・向いていない使い方
ここまでの情報を踏まえ、GitHub Copilotを安全に活用できるシーンと、使用を控えるべきシーンを整理します。
向いている使い方
- 公開情報のみを扱うオープンソースプロジェクト
- 機密情報を含まない新規開発のコード補完
- テストコードやドキュメント生成
- 一般的なアルゴリズムやデザインパターンの提案
- 企業向けプランで、除外設定とレビュー体制が整った環境での利用
向いていない使い方、注意が必要な使い方
- 個人向けプランで業務コードを扱う
- APIキーや顧客データが含まれるファイルを開いたままCopilotを使う
- 生成されたコードをレビューなしで本番環境にデプロイする
- 機密性の高い仕様書や設計書をCopilot Chatにそのまま入力する
- ライセンスが厳格なプロジェクトで、公開コードフィルターを無効にしたまま利用する
買う前・導入前に確認すべきチェックリスト
GitHub Copilotの導入を検討する際、以下の項目を事前に確認しておくと、情報漏えいの不安を軽減できます。
| 確認項目 | 内容 |
| — | — |
| 利用プラン | BusinessまたはEnterpriseプランか。個人向けプランで業務利用しないか。 |
| データの学習利用設定 | 個人向けプランの場合、製品改善へのデータ提供をオプトアウトしているか。 |
| 除外設定 | .envや設定ファイルなど、機密情報を含むファイルをCopilotの対象から除外しているか。 |
| 公開コードフィルター | 公開コード一致ブロックが有効か。 |
| レビュー体制 | 生成コードを必ずレビューし、静的解析を組み合わせるプロセスがあるか。 |
| ガイドライン | 組織としてCopilotの利用ルールが明文化され、周知されているか。 |
| シークレットスキャン | GitHubのSecret ScanningやDependabotが有効か。 |
よくある質問と回答
Q. Copilotがリポジトリ全体を読み取ることはありますか？
A. いいえ、Copilotは編集中のファイルとその周辺文脈をリアルタイムに参照するだけで、リポジトリ全体を事前に読み込むことはありません。ただし、開いているファイルに機密情報があれば送信対象になります。
Q. 個人向けプランでも設定すれば安全ですか？
A. データの製品改善利用をオプトアウトすれば、コードスニペットが保存されなくなります。しかし、業務で扱う機密情報の保護を考えると、企業向けプランの利用が推奨されます。
Q. 生成コードにAPIキーが含まれていた場合、責任は誰にありますか？
A. 生成コードの利用責任は開発者側にあります。Copilotが生成したコードであっても、本番適用前のレビューとテストは必須です。
Q. 除外設定はチーム全体に適用できますか？
A. Business/Enterpriseプランでは、組織のポリシーとして除外設定を配布できます。VSCodeのsettings.jsonを共有するか、リポジトリに`.vscode/settings.json`を含めることでチーム全体に適用可能です。
Q. Copilot Chatに仕様書を貼り付けても大丈夫ですか？
A. 機密情報が含まれる場合は避けるべきです。どうしても必要な場合は、具体的な値をマスキングするか、抽象化した質問に留めましょう。
まとめ：線引きのポイントは「プラン」と「設定」と「運用」
GitHub Copilotに社内コードや仕様をどこまで渡すかは、利用プラン、エディターの除外設定、組織の運用ルールの3つで決まります。企業向けプランで適切な設定を施し、レビューと静的解析を組み合わせれば、多くの開発シーンで安全に活用できます。一方、個人向けプランで機密情報を扱うことや、設定を怠ったままの利用は、情報漏えいのリスクを高めるため避けるべきです。
まずは自社の利用プランを確認し、本記事で紹介した除外設定と運用ルールを参考に、安全なCopilot活用を始めてみてください。
コメント