著者 コーディングエージェントのテレメトリで何が送信されるか
コーディングエージェントから出る通信は4種類あります。避けられない推論通信と、分析・クラッシュレポート・連携先への接続を実機で監査し、不要な送信を制御する方法を解説します。
コーディングエージェントのテレメトリで実際に送られるデータ
コーディングエージェントのテレメトリには、1 つの言葉で呼ばれる 4 つの異なるデータ共有フローがあります。それぞれに個別の制御方法があります。モデル推論では、プロンプトとコードがモデルを提供する事業者へ送信されます。これを無効にする設定はありません。製品分析データとクラッシュレポートはベンダーへ送信され、多くの場合、ベンダーが契約しているログ管理会社にも送られます。トレーニングへの利用に関する保持期間は、ネットワーク設定ではなく契約上の問題です。見落とされやすい 4 つ目のフローは、追加した各インテグレーションが、自分で選んでいないホストへの接続を開く可能性があることです。
現在のベンダーのデフォルト設定を一覧にすることは、このテーマの中で最も早く古くなる部分です。リリースによってデフォルトが変更されることがあり、新機能によって、既存のどのスイッチでも制御できない送信先が追加されることもあります。そのため、長期的に役立つのは、どのエージェントにも繰り返し適用できる監査手順です。ベンダーのドキュメントを読み、このマシンで実際に適用された設定を確認し、マシン自体からプロセスを監視してから、許容できるコストに応じて制御方法を選びます。以下の各コマンドは、自分のマシン上で自分のネットワークトラフィックを対象に実行します。
4 つのカテゴリと、それぞれに異なる制御が必要な理由
モデル推論のトラフィックは避けられません。 エージェントは、プロンプト、読み取ったファイル、実行したコマンドの出力、生成したテキストをモデルエンドポイントへ送信します。これは製品の動作そのものです。実際に選べるのは、誰が運用するエンドポイントに送信するかだけです。第三者が運用する API に送るか、自分で運用するモデルに送るかの違いです。企業向けクラウドアカウント（Bedrock、Vertex、Foundry）を使用しても、送信先が変わるだけで、この通信フローがなくなるわけではありません。この記事の残りの内容では推論トラフィックは減らせないため、他の 3 つとは分けて考えてください。
製品分析とクラッシュレポートは、別のホストへの異なる通信です。 利用回数、レイテンシ、機能フラグの照会、スタックトレースは、通常、モデル API とは関係のないホスト名へ送信されます。多くの場合、第三者のエラートラッカーが送信先になります。ベンダーは通常、これらを「メトリクス」や「エラーレポート」として文書化し、カテゴリごとに 1 つの環境変数を用意しています。通信量はごく少ないため、バイト数を調べても見つかりません。探す対象は帯域幅ではなく、ホスト名です。
保持とトレーニングは、パケットではなくポリシーの問題です。 ベンダーがプロンプトを保持するか、保持期間、また将来のモデルのトレーニングに使用するかは、契約プランに付随する規約に記載されています。通常、個人向けプランと商用プランでは内容が異なり、ゼロ保持の取り決めは別契約になるのが一般的です。パケットはどちらの場合も同じに見えるため、tcpdump でこれらを検証することはできません。規約を確認し、勤務先にとって重要な事項であれば、書面で取り交わしてください。
統合機能は、気付かないうちに中継先を追加します。 MCP（model context protocol）サーバー、プラグインマーケットプレース、自動更新チェック、Web 検索ツール、取得前に URL を解決する安全性チェックは、いずれもモデルエンドポイントではないホストへのリクエストです。ここで想定外の動作が起きます。ハーネスが、ローカルで処理されると思っていた作業を独自のサービス経由で転送することがあり、設定を 1 行も変更せずにリリースでその動作が始まる場合もあります。追加するすべてのツールについて、ネットワーク上での通信を確認するまでは、新しい送信先として扱ってください。
ステップ 1: ベンダーは何を文書化しているか
エージェントの設定リファレンスとデータ使用に関するページを開き、単語リストを手元に置いて読みます。metrics、analytics、error reporting、crash、feedback、survey、update check、safety check、marketplace を確認してください。これらの各項目は通常、個別のスイッチになっています。ステップ 2 で検索するため、変数名を正確に書き留めてください。
1 つの単語が誤解を招きます。複数のエージェントでは、ドキュメントにある「telemetry」は、ユーザーが運用する collector にメトリクスを送信するよう設定する OpenTelemetry の export を意味します。これは、データをベンダーへ送信する場合とは逆です。Claude Code もその 1 つです。CLAUDE_CODE_ENABLE_TELEMETRY=1 を設定すると、OTEL_EXPORTER_OTLP_ENDPOINT で指定したエンドポイントへの export が開始されます。これはベンダー独自の analytics とは無関係で、analytics には別のオプトアウト設定があります。設定する前に、データがどちらへ流れるのかを確認してください。
マスタースイッチがあることを想定してください。ただし、対象外もあります。2026 年 8 月時点では、Claude Code の CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC により、metrics、error reports、feedback コマンド、session surveys をまとめて無効にできます。一方、同じドキュメントには、これが WebFetch の domain safety check には適用されないと記載されています。この check は、取得しようとしているホスト名をベンダーの API に送信し、独自の設定を持ちます。これは特定の製品だけの問題ではありません。どこでも同じ構造です。マスタースイッチは、その設定が作成された時点で存在していたカテゴリを対象にします。
オプトアウトには代償もあると考えてください。同じドキュメントには、telemetry を無効にすると、一部の機能が依存する feature-flag evaluation も無効になると記載されています。そのため、プライバシー保護のためにスイッチを切ると、使用していた機能まで無効になる場合があります。しかも、両者の関係を示すエラーメッセージは表示されません。フラグ名だけでなく、その直後の説明文も読んでください。
手順 2: 実際に適用された設定はどれか
自分で記述した設定が、実際に適用されるとは限りません。エージェントは複数のファイルから設定をマージします。その中には、他者からクローンしたばかりのリポジトリ内にあるファイルも含まれます。まず、自分のシェルの環境を確認します。
env | grep -Ei 'telemetry|otel|analytics|error_report|do_not_track|proxy'次に、ツールが読み込むすべての設定ファイルを、ドキュメントに記載された順序で表示します。2026 年 8 月時点の Claude Code では、ユーザーファイル、2 つのプロジェクトファイル、Linux 上の管理ポリシーディレクトリの順です。
for f in ~/.claude/settings.json .claude/settings.json .claude/settings.local.json; do
echo "== $f"; [ -f "$f" ] && cat "$f"
done
ls -l /etc/claude-code/ 2>/dev/nullgit clone とともに配置されたプロジェクトファイルは、他者が記述した設定です。その設定によって、ユーザーファイルで無効にした機能が再び有効になることがあります。エージェントに読み込んだ設定ソースを一覧表示する status コマンドがある場合、それが最も速く確認できる事実です。Claude Code では、読み込んだ設定ソースが /status に表示されます。
最も確実な確認方法は、ファイルではなく実行中のプロセスを調べることです。まず、エージェント専用の Linux ユーザーアカウントを用意します。これにより、この後のすべてのコマンドを短くできます。次に、そのプロセスの起動時環境を読み取ります。
pgrep -u agent -a node
sudo tr '\0' '\n' < /proc/$(pgrep -u agent -n node)/environ | grep -Ei 'telemetry|proxy|otel'/proc/<pid>/environ には、プロセスが exec 時点で保持していた変数が表示されます。そのため、.bashrc の export が systemd で起動したサービスに届かなかった場合も検出できます。設定した変数がここにない場合、dotfiles の内容にかかわらず、その変数は一度も適用されていません。
ステップ 3: どのホストに接続するか
まず、agent を実行しているアカウントで絞り込んだオープンソケットを確認します。
sudo ss -tnpe state established-e を指定すると各行に uid: フィールドが追加されるため、プロセス名を確認しなくても agent の接続とブラウザーの接続を分けられます。リモートアドレスを記録し、その背後にある名前を調べます。名前を取得する最も確実な方法は TLS (transport layer security) handshake を確認することです。新しい接続はすべて、クライアントが要求したホスト名を示す SNI (server name indication) フィールドを含む ClientHello から始まるためです。
sudo apt install -y tshark
sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' \
-T fields -e ip.dst -e tls.handshake.extensions_server_name新しい接続ごとに 1 行が出力されます。これは、必要な接続先一覧そのものです。model API、update server、analytics host、error tracker、さらに integration が追加した接続先も含まれます。名前の列が空の場合、そのクライアントは ECH (encrypted client hello) を使用しています。そのため、ホスト名はネットワーク上で確認できません。この場合は、宛先 IP アドレス、逆引き、またはステップ 4 の proxy を使用します。
DNS (domain name system) の情報も有用な照合手段です。接続が完了しなかった場合でも、agent が名前を検索したことを確認できるためです。
sudo tcpdump -ni any -l 'udp port 53'各 query の行は、A? host.example.net. (39) の形式で record type と名前で終わります。外部インターフェイスではなく any で capture してください。systemd-resolved を使用している場合、アプリケーションは 127.0.0.53 の local stub listener と通信し、外部と通信するのは stub だけだからです。agent が明らかに動作しているのに DNS traffic がまったく見えない場合、その runtime は自ら DNS over HTTPS を実行しています。この場合、名前を取得できるのはステップ 4 だけです。
agent が実際に処理を行っている間に capture します。session を開始し、ファイルを読み込ませ、command を実行させ、処理を意図的に失敗させてください。startup 時に 1 回だけ発生する traffic や、exception 発生時だけ発生する traffic は、idle 状態の capture には現れません。idle 状態での capture は、audit が根拠のない都合のよい結論に至る最も一般的な原因です。
手順 4: リクエストの内容を確認する
ホスト名からは接続先が分かります。内容を確認するには、自分で管理するプロキシをエージェントの前段に置き、そのランタイムだけでプロキシの認証局 (CA) を信頼させます。通常は mitmproxy を使用します。プロジェクトでは mitmproxy.org のスタンドアロンバイナリを推奨しており、Python パッケージを使う方法として uv tool install mitmproxy も説明しています。
mitmdump -w /tmp/agent-flows.mitm初回実行時に CA が ~/.mitmproxy/ に書き込まれます。mitmproxy-ca-cert.pem はその証明書単体です。エージェントを起動するシェルで、クライアントのプロキシと証明書を指定します。
export HTTP_PROXY=http://127.0.0.1:8080
export HTTPS_PROXY=http://127.0.0.1:8080
export NODE_EXTRA_CA_CERTS="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export REQUESTS_CA_BUNDLE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"
export SSL_CERT_FILE="$HOME/.mitmproxy/mitmproxy-ca-cert.pem"多くのエージェント CLI は Node プログラムです。Node はプロセスの起動時に NODE_EXTRA_CA_CERTS を読み込むため、エージェントを起動する前に export してください。起動後に別のターミナルで設定しても反映されません。Python クライアントは REQUESTS_CA_BUNDLE または SSL_CERT_FILE を読み込みます。標準ライブラリを使用する Linux 向けの Go バイナリは SSL_CERT_FILE を読み込みます。エージェントを疑う前に、curl でこの経路が機能することを確認します。
curl -sS -o /dev/null -w '%{http_code}\n' https://example.comプロキシが機能すると、200 が表示され、リクエストが mitmdump の出力に現れます。信頼されていない CA の場合は curl: (60) SSL certificate problem: self-signed certificate in certificate chain になり、Node エージェントでは同等のエラーにコード SELF_SIGNED_CERT_IN_CHAIN が含まれます。その後、コンソールビューアーで保存済みのフローを読み込みます。個々のリクエストを開いて、ヘッダーと本文を確認できます。
mitmproxy -r /tmp/agent-flows.mitm結果は 4 通りに分けられます。リクエストが表示される場合は、内容を確認して判断します。証明書エラーでエージェントが起動しない場合は、そのランタイムにおける信頼設定の問題です。ベンダーに関する発見事項ではありません。モデル API だけが表示される場合は、他のカテゴリが無効になっているか、発生させていないイベントで実行されています。エージェントが明らかに動作しているのに何も表示されない場合は、クライアントがプロキシ環境変数を無視しているか、証明書をピン留めしています。この場合、アプリケーション設定だけでは実際の通信を判断できません。最後の結果が最も重要です。接続をパケットキャプチャから隠すことはできないため、手順 3 に戻ります。
制御手段（弱いものから強いものへ）
オプトアウト設定。 最も安価ですが、最も弱い手段です。ベンダーが設定を尊重し、すでに存在するカテゴリだけを対象にすることで機能するためです。再起動後や新しいターミナルでも有効になる場所、つまりユーザー設定ファイルまたはシェルのプロファイルに設定します。その際に DO_NOT_TRACK=1 も追加してください。これは一部のエージェントを含む、多くのコマンドラインツールが尊重する慣例で、費用もかかりません。次回の更新後には step 3 を再実行してください。その時点で対象範囲が変わるためです。
送信トラフィックの制限。 ここでは要求するのではなく、強制します。エージェントを専用ユーザーで実行し、そのユーザーには loopback と DNS だけを許可して、残りを拒否します。専用のテーブルを追加するため、既存のファイアウォールルールには影響しません。
table inet agentegress {
chain output {
type filter hook output priority filter; policy accept;
meta skuid "agent" ip daddr 127.0.0.0/8 accept
meta skuid "agent" udp dport 53 accept
meta skuid "agent" counter log prefix "agent-egress-drop " drop
}
}sudo nft -f /etc/nftables.d/agent.nft で適用し、sudo nft list table inet agentegress でカウンターを監視し、sudo journalctl -k -g agent-egress-drop で拒否された通信を確認します。予期しないホスト名に対する拒否カウンターが増えることが、この設定の目的です。注意点が2つあります。meta skuid はソケットを所有するユーザーに一致するため、そのアカウントが別のユーザーになれない場合にだけ有効です。エージェントにパスワードなしの sudo を許可すると、このルールは単なる提案になってしまいます。また、任意の DNS サーバーへの UDP 53 を許可すると、クエリ名にデータを埋め込んで外部へ送信できる経路が残ります。脅威モデル上必要であれば、エージェントの resolver を自分で管理するホストに向けて、この経路も閉じてください。ホスト名の許可リストは nftables ではなくプロキシに置くべきです。API エンドポイントはコンテンツ配信ネットワークの背後にあり、その IP アドレスが変わるためです。この制御には、動作停止と保守の負担が伴います。パッケージのインストール、SSH 経由の git、エージェント自身の更新確認は、許可するまで失敗します。その許可リストも自分で保守する必要があります。ノートパソコンではなくサーバーで構成する場合も、同じアカウント構成とファイアウォール構成が、VPS 上で Claude Code を安全に実行するための基本になります。
使い捨てのマシン。 重要な認証情報を保持していない仮想マシン（VM）をエージェントに割り当て、タスクの終了時に破棄します。これによりエージェントが送信する内容は減りません。エージェントが送信できる対象を減らせます。通常、こちらが実際に重視すべきリスクです。ただし、上記の送信トラフィック制限と組み合わせてください。インターネットへのアクセスが無制限の新しい VM でも、キャプチャ対象のすべてのホストに到達できるためです。方法と、毎回再構築する必要がある状態については、使い捨て VM でコーディングエージェントを実行するで説明しています。サイズ設計については、VPS 上でコーディングエージェントを実行するを参照してください。
モデルのセルフホスティング。 推論の通信経路をなくせる唯一の制御です。プロンプトがハードウェアの外部に出ないためです。コストは無視できません。クローズドモデルはセルフホストできないため、オープンウェイトを選び、難しいタスクでは性能差を受け入れる必要があります。さらに、モデルを提供するためのハードウェアも必要です。このトレードオフについては、Claude をセルフホストできるかで説明しています。主要なエージェント間の性能差については、Claude Code、Cursor、Codex、Copilot の違いを参照してください。
これら4つの制御手段のいずれも、エージェントがディスク上で読み取れる内容は変えません。推論の通信には、エージェントが読み取った内容が含まれます。作業ディレクトリに .env ファイルがある場合、エージェントが変数名を grep した時点で、その内容がモデルに送信されます。そのデータをエージェントから遠ざけることは別の対策です。AI エージェントのコンテキストから Secret を排除するで説明しています。
更新後に毎回確認すること
- ベンダーの設定ページとデータ利用ページを、前回記録した内容と比較します。新しいスイッチや、新たに追加されたサービス名を探します。
/proc/<pid>/environからプロセス環境を再度読み取り、オプトアウト設定が実行中のプロセスに引き続き適用されていることを確認します。- プロジェクトの設定ファイルを再度出力します。
git pullにより、同僚が変更した設定ファイルが読み込まれる可能性があるためです。 - 実際の作業を 1 セッション分すべて行いながら SNI キャプチャを実行し、ホスト名の一覧を前回の一覧と比較します。
- ファイアウォールの drop カウンターを確認します。新しい宛先は、通常、ほかの場所で気付くより先にそこに現れるためです。
この確認には約 10 分かかります。プロセスの中で、時間が経っても陳腐化しないのはこの部分だけです。2026 年 8 月に確認したデフォルト設定は、2026 年 8 月時点の事実です。キャプチャ結果は、今日時点の事実です。
FAQ
コーディングエージェントによるコードのモデルへの送信を止められますか？
いいえ。そのように説明されている設定があっても、実際には別の処理を指しています。プロンプト、エージェントが読み取ったファイル、実行したコマンドの出力をモデルエンドポイントへ送ることが推論の仕組みです。違うのは、誰がそれを受け取るかだけです。エージェントの接続先を会社のクラウドアカウントや、自分でホストするモデルに変更できます。また、読み取りを許可する範囲を制限すれば、送信される内容を減らせます。分析情報とエラーレポートを無効にしても、この処理にはまったく影響しません。
コーディングエージェントが接続するホストを確認するにはどうすればよいですか？
エージェントを専用の Linux ユーザーで実行し、使用中に新しい接続ごとの TLS ClientHello を取得します: sudo tshark -i any -f 'tcp port 443' -Y 'tls.handshake.type == 1' -T fields -e ip.dst -e tls.handshake.extensions_server_name。接続ごとに 1 行が表示され、宛先アドレスと要求されたホスト名を確認できます。sudo tcpdump -ni any 'udp port 53' で名前を照合します。any でキャプチャしてください。127.0.0.53 上のローカルリゾルバースタブが先にクエリを処理するためです。起動時の ping やクラッシュレポートはアイドル状態のキャプチャには現れないため、エージェントが実際に処理を実行している間に取得してください。
エージェントの動作中にプロキシにネットワークトラフィックが表示されません。何が問題ですか？
クライアントが HTTP_PROXY と HTTPS_PROXY を無視しているか、証明書をピン留めしていて CA を拒否しています。まず curl で経路をテストしてください。curl がプロキシ経由でインターネットに接続でき、エージェントがフロー一覧に現れない場合、エージェントはプロキシ環境変数を使用していません。一部のランタイムでは CA を特定の方法で指定する必要があります。特に Node は NODE_EXTRA_CA_CERTS をプロセス起動時にしか読み取らないため、エージェントの起動後に export しても効果はありません。プロキシからトラフィックを確認できない場合は、パケットキャプチャに切り替えてください。アプリケーションの設定でこれを回避することはできません。
テレメトリを無効にすると、コードがトレーニングに使用されなくなりますか？
いいえ。分析情報とクラッシュレポートは推論とは別の処理です。これらを無効にすると使用回数のカウンターやスタックトレースは送信されなくなりますが、モデルに送られる各プロンプトはこれまでどおりです。プロンプトが保持されるか、将来のモデルのトレーニングに使用されるかは、契約プランの規約で決まります。通常、個人向けプランと商用プランでは条件が異なります。これはパケットをキャプチャして確認するものではなく、契約内容として確認すべき事項です。使用するプランのデータ利用に関するページを確認し、重要な場合は、最初のセッションを開始する前に商用契約またはゼロリテンション契約を手配してください。