2026年8月11日、Hacker Newsで、AIアシスタントを作業IDEで使用しているすべての人が読むべき分析が広まりました。研究者は、VS CodeをGitHub Copilotのためのインターセプトプロキシに接続し、何がサーバーに送信されるかを観察しました。結果、送信されるのは、あなたが追加する行だけではなく、オープンな.envの内容も含まれていることが明らかになりました。
良いニュースは、これを誰でも確認できることで、Copilotだけでなく、他の方法でも可能です。以下は、アシスタントのトラフィックを20〜30分で監査するための作業手順、インターセプトされたリクエストで何を探すべきか、そしてファイル除外の標準メカニズムの制限についてのガイドです。
自分でやる理由
ベンダーのドキュメントはポリシーを説明していますが、クライアントの実際の動作については触れていません。「私たちはあなたのコードを学習に使用しません」と「クライアントはあなたのコードをサーバーに送信しません」の間には大きな隔たりがあります。ヒントを生成するためには、モデルがコンテキストを取得する必要があり、問題はクライアントがそのコンテキストをどれだけ広く収集するかということです。
監査が必要な場合は、以下のような状況です：
- NDAに基づいて作業しているか、顧客の個人データを扱っており、何が境界を越えているかを知る必要がある。
- リポジトリに秘密情報、スタンドの設定、内部アドレス、トークンを保持している。
- チームのコンプライアンスを担当しており、設定のスクリーンショットではなく、実際のリクエストのログが必要である。
- アシスタントが突然、開いていないファイルについて「知っている」理由を理解したい。
Copilotのトラフィックで見つかったこと
この分析は、クラシックなmitmproxyに基づいています。VS Codeはローカルプロキシにポート8080で接続され、厳格な証明書チェックは無効にされました。主な発見は以下の通りです：
- コンテキストは1つのファイルを超えています。 インライン補完時、クライアントは最大20ファイルを収集し、最近の修正の要約を8つ、各変更の周囲の3行のコンテキスト、さらに現在のファイルの完全なテキストと最近編集されたファイルの差分を含みます。
- 秘密はマスクされていません。 リクエストの本文の
promptフィールドには、TEST_ENV_VAR_SECRET="mysecretenvvar"のような文字列が含まれており、オープンファイルからの環境変数が通常のテキストとして送信されていました。 - ローカルデータベースもオープンです。
session-store.dbファイルは、user_messageとassistant_responseを暗号化や編集なしで保存しており、そこにはトークン、クラウドプロバイダーのキー、以前チャットに挿入した接続文字列のパスワードが含まれています。 - サービスコール。 補完の他に、クライアントは
/models、/agents/swe/models、/models/session/intent、およびGitHubのOAuthエンドポイントを呼び出し、アシスタントが応答を生成する前にリクエストを分類する様子がよくわかります。
特に覚えておくべきことは、クライアントが現在のリポジトリのURLをサーバーに送信して、適用可能な除外ポリシーを取得することです。この事実自体は無害ですが、作業ツリーの構成も信号となることを意味します。
ステップバイステップ：インターセプトを設定する
- mitmproxyをインストールし、起動します。 ウェブインターフェースで十分です：
mitmweb。デフォルトでプロキシはポート8080をリッスンし、コンソールはブラウザで開かれます。CIや長時間のセッションにはmitmdumpが便利です。 - ルート証明書をインストールします。 mitmproxyを初めて起動すると、
~/.mitmproxyディレクトリにCAが作成されます（ファイルmitmproxy-ca-cert.cer）。これを信頼済みに追加する必要があります。さもなければ、クライアントはTLS接続を切断します。監査中はユーザーレベルの信頼で十分ですが、その後は証明書を削除し、「万が一」のために他のCAをシステムに残さないでください。 - インターセプトモードを選択します。 モードは3つあり、正しい選択は1時間の手間を省きます：
- regular — 通常のプロキシで、クライアントは明示的に設定します。最も予測可能なオプションです。
- local — 同じマシン上でアプリケーションの透明なインターセプトで、プログラムの設定を変更せずに：
mitmproxy --mode local:CodeはVS Codeプロセスのみをキャッチし、--mode local:42は指定されたPIDのプロセスを、--mode local:!curlはcurl以外のすべてをキャッチします。これは、プロキシ設定がないアシスタントを監視する最良の方法です。 - upstream — mitmproxyの背後に独自のプロキシがあるチェーン：
mitmdump --mode upstream:http://host:8081、ログインとパスワードはオプション--set upstream_auth=user:passで設定されます。
- IDEをプロキシに向けます（regularモードの場合）。 VS Codeの
settings.jsonで："http.proxy": "http://127.0.0.1:8080""http.proxySupport": "override""http.proxyStrictSSL": false— 監査中のみ。このフラグは証明書の検証を完全に無効にし、作業設定に残すことはできません。
- 証明書の問題を適切に解決します。 Copilotの拡張機能はNode上で動作するため、正しい方法は検証を無効にするのではなく、ルートCAとmitmproxyの証明書を含むPEMを作成し、環境変数
NODE_EXTRA_CA_CERTSを介して指定することです。IDEを再起動する必要があります：この変数はプロセスの開始時に読み込まれます。 - ストリームをファイルに書き込みます。 リアルタイムで目で見るのは無駄です — リクエストは毎分数十件あります。
--set save_stream_file=flows.dumpを有効にし、すべてを収集しないように--set save_stream_filter=...でサンプリングを制限します。その後、ファイルはオフラインで簡単に解析できます。 - リクエストの本文で検索し、URLでは検索しません。 実用的なテクニック：ユニークな文字列を含むカナリアファイルをテストリポジトリに置き（例：
CANARY_9f3c_DO_NOT_SEND）、エディタで開き、隣のファイルで作業し、インターセプトされた本文でカナリアを探します。これにより、あなたのクライアントのバージョンにおけるコンテキスト収集の実際の範囲がわかります。
落とし穴
ライセンスがインターセプトをブロックする可能性があります。 Copilotの法人プランでは、「現在のCopilotライセンスは自己署名証明書を使用したプロキシ接続をサポートしていません」というエラーが表示されます。これはプロキシのバグではなく、クライアントが意図的に自己署名CAを介して動作を拒否しているためです。これは、システムレベルで信頼された証明書を使用するか、Node用のPEMを構築することで解決できます。組織のポリシーがこれを禁止している場合、監査は管理者と調整する必要があります。
ピンニングとQUIC。 一部のクライアントは、通常のプロキシでは見えないQUIC上のHTTP/3を使用しています。インターセプトを有効にした後、アプリケーションが「動作するがログが空」である場合、ほぼ常にその理由はこれです：テストプロセスのUDP/443をブロックすると、クライアントはHTTP/2に戻ります。
テレメトリとペイロードは異なる経路を通ります。 1つのエンドポイントだけで「何も送信されていない」と結論付けないでください：プロセスがアクセスするホストの全リストを確認し、ドキュメントに記載されているものだけを見ないでください。
法的枠組み。 自分のマシンとアカウントでトラフィックをインターセプトすることは可能です。他人の作業ノートパソコンを所有者の知らないうちに監視することは別の話であり、「セキュリティ」がそれを正当化することはありません。
結果をどうするか
監査の結果、リクエストに余分なファイルが含まれていることが示された場合、標準の手段は次のように見え、それぞれに明確な制限があります。
- コンテンツ除外。 GitHubの公式メカニズムで、指定されたパスをCopilotが使用することを禁止します。ビジネスおよびエンタープライズプランでのみ利用可能で、Copilotの設定で管理者によって設定され、VS Code、Visual Studio、JetBrainsでサポートされています。Xcode、Eclipse、Vim/Neovimではインラインヒントのみに対応しています。
- 最大の穴はエージェントモードです。 ドキュメントは、Copilot ChatのEditおよびAgentモード、ならびにCopilot CLIでは除外がサポートされていないことを明言しています。つまり、アシスタントが自らファイルを操作し、設定を読み取り、コマンドを実行する場所では、プラットフォームのフィルタリングが適用されません。コンテンツ除外を唯一の障壁として頼る場合、エージェントモードでは障壁がありません。
- .gitignoreは保護しません。 一般的な誤解：Gitのインデックスからの除外は、アシスタントのコンテキストからの除外を意味しません。
- 組織の最小限。 秘密は秘密管理ツールに、コードの近くにある
.envには置かない；アシスタントのチャットは接続文字列を挿入する場所ではない；ローカルの履歴データベースは、シェルの履歴をクリアするのと同じようにクリアする必要があります。
ここでのプロキシとその必要性
インターセプトには実用的な続きがあります。まず、upstreamモードでは、アシスタントのすべてのトラフィックを制御された出口ノードを通過させることができます：リクエストを同時に見ることができ、どのアドレスから送信されるかを管理できます。これは、アシスタントのAPIがあなたの地域で利用できない場合や、企業のポリシーが固定された発信IPを要求する場合に必要です。このようなシナリオには、安定したデータセンタープロキシが適しています。
次に、同じスタンドは自動化のデバッグにも役立ちます：AIエージェントが自らウェブサイトを訪問する際、インターセプトは実際に送信されるヘッダーと、どのように保護がそれをキャッチするかを示します。この組み合わせについては、PlaywrightとMCPのAIエージェント用プロキシに関する資料で説明しました — そこでエージェントシナリオに必要なアドレスのタイプの選択について触れています。
mitmproxyを以前に設定したことがない場合は、HTTPSインターセプトの基本設定から始めてください — それは私たちのmitmproxyを使用したトラフィックインターセプトガイドで詳しく説明されています。その上にlocalおよびupstreamモードを追加してください。
結論
AIアシスタントのトラフィック監査は、偏執病ではなく、正常なエンジニアリングの衛生状態であり、1晩で1回行うことができます。Copilotの分析は明確な状況を示しました：クライアントは広範囲にコンテキストを収集し、秘密はコードと同様にそのコンテキストに含まれ、ローカルの履歴は平文で保存され、標準の除外は最も危険なモード — エージェントモードでは機能しません。
ドキュメントではなく、トラフィックを確認してください。mitmproxyをlocalモードで立ち上げ、リポジトリにカナリアを置き、ストリームをファイルに収集し、あなたのマシンから何が送信されているかを自分の目で確認してください。その後の解決策は簡単です：この送信量を意識的に受け入れるか、他のサーバーに見られる前に秘密を作業ツリーの外に移動させるかのいずれかです。