Claude Code 情報漏洩を防ぐには？送信データの範囲と設定手順

Claude Code の情報漏洩を防ぐ要点は、情報が外に出る経路を4つに分けて、それぞれに合う設定を入れることです。公式ドキュメントによると、Claude Code はローカルで動きますが、モデルとやり取りするために、送信データとしてプロンプトとモデルの出力をすべてネットワーク越しに送ります。設定で扱いを変えられるのは、学習への利用、テレメトリと報告の送信、手元に平文で残る会話の保存記録です。Claude が .env などの秘密を読む経路も制限できますが、deny ルールとサンドボックスは対象が異なり、それぞれに限界があります。なお、特定の流出事件をめぐる報道について、この記事では事実関係を扱いません。報道を見たときの確認先は最後の見出しにまとめました。Claude Code そのものの説明が先に必要な場合は Claude Codeとは何かを読んでください。

Claude Code から情報が出ていく経路は何があるのか？

公式ドキュメントの記述をもとに整理すると、情報漏洩の経路は次の4つです。

経路	何が出るか	主な対策
1. モデルとの通信	プロンプトとモデル出力のすべて	プランごとの学習設定、読ませないファイルを決める
2. テレメトリと報告	利用メトリクス、エラーレポート、`/feedback` などで送る会話履歴	環境変数で個別または一括停止
3. 手元の記録	`~/.claude/projects/` に平文で残るセッション記録	保存日数の短縮、`claude purge`
4. コマンドと外部連携	Claude が実行する `curl` などのコマンド、MCP サーバー	`permissions.deny`、サンドボックス、信頼ダイアログ

経路1の通信は TLS 1.2 以上で暗号化されます。この経路での対策は、何を読ませるかと、送った後の扱いの2点です。

自分のコードは Anthropic の学習に使われるのか？

契約の種類で答えが変わります。

個人向けプラン（Free / Pro / Max）: 学習への利用を許可する設定がオンのとき、Claude Code から送ったデータも学習に使われます。設定は claude.ai/settings/data-privacy-controls からいつでも変えられます。
商用（Team / Enterprise / API / 他社クラウド経由 / Claude Gov）: 商用規約のもとで送られたコードやプロンプトは、顧客が自分から提供を選ばない限り、生成モデルの学習に使われません。

保存期間も契約で異なります。

契約	保存期間（公式記載）
個人向けで学習を許可	5年
個人向けで学習を不許可	30日
商用の標準	30日
Zero Data Retention（ZDR）	Claude for Enterprise の Claude Code で、適格なアカウントが利用可能。標準の Enterprise には含まれず、アカウント担当が組織ごとに有効化する

業務のコードを個人の Pro / Max アカウントで扱うなら、まず学習設定を確認してください。

テレメトリや /feedback では何が送られるのか？

モデルとの通信とは別に、Claude Code は運用のためのデータを2種類送ります。

利用メトリクス: 遅延、信頼性、利用パターン。公式には、コード、プロンプト、ファイルパスは含まれないと書かれています。DISABLE_TELEMETRY=1 で止まります。
エラーレポート: Claude Code 内部のエラーメッセージとスタックトレース。送信前に、秘密情報、ファイルパス、メールアドレスなどの既知のパターンを伏せます。DISABLE_ERROR_REPORTING=1 で止まります。有効になるのは、Pro / Max でサインインしていて、v2.1.198 以降で、Claude API に直接つないでいて、組織に ZDR や HIPAA の契約がない場合だけです。

注意が必要なのは、自分で送る報告です。/feedback を実行すると、コードを含む会話履歴のコピーが Anthropic へ送られます。/bug と /share も同じ経路で、送った記録は5年間保持されます。セッション品質アンケートの評価のあとに、セッション記録を見てよいかを尋ねる追加質問が出ることがあります。ここで Yes を選んだ場合も、会話記録とログがアップロードされます。既知のAPIキーやトークンのパターンは伏せられますが、ソースコードやファイルの中身はそのまま送られます。Yes を選ばなければ何も送られません。

情報漏洩につながる送信は環境変数で止められます。公式には、環境変数は settings.json の env に書いてよいとあります。

{
  "env": {
    "DISABLE_TELEMETRY": "1",
    "DISABLE_ERROR_REPORTING": "1",
    "DISABLE_FEEDBACK_COMMAND": "1",
    "CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY": "1"
  }
}

個別に指定する代わりに、CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC で必須でない通信をまとめて止めることもできます。ただし DISABLE_TELEMETRY か CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC を設定すると、機能フラグの評価も止まります。その結果、Remote Control が使えなくなることがあります。Remote Control を使っている場合は、DISABLE_ERROR_REPORTING などの個別指定にとどめてください。

Amazon Bedrock、Google Cloud の Agent Platform、Microsoft Foundry、Claude Platform on AWS 経由では、エラーレポート、テレメトリ、バグ報告が最初からオフです。各項目の停止手順はオプトアウト設定のガイドにもまとめています。

.env や秘密鍵を Claude に読ませないにはどう設定するか？

経路1の対策の中心は、読み取り制限設定で秘密を含むファイルを読ませないことです。公式は、APIキー、秘密情報、環境変数の値を含むファイルには permissions.deny を使うよう案内しています。一致したファイルは検索結果から外され、読み取りが拒否され、Edit と Write でも書き換えられなくなります。

公式の例は次のとおりです。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./config/credentials.json)",
      "Bash(curl *)"
    ]
  }
}

情報漏洩を防ぐ設定で間違えやすい点が3つあります。

.claudeignore は効きません。 公式に「効果がない」と書かれており、中身を Read の deny ルールに移すよう案内されています。
書く場所でパスの起点が変わります。 Read(.env) は、今いるディレクトリ以下にあるすべての .env に効きますが、親ディレクトリや別プロジェクトには効きません。ユーザー設定（~/.claude/settings.json）に Read(/secrets/**) と書くと、プロジェクトの secrets ではなく ~/.claude/secrets/** を指します。全プロジェクトに効かせたい場合は、ルートからの // で始まるパスか ~/ で始まるパスで書きます。
CLAUDE.md に「読むな」と書いても強制にはなりません。 権限ルールを強制するのはモデルではなく Claude Code で、CLAUDE.md の指示では許可の範囲は変わりません。

ルールは deny、ask、allow の順に評価されます。最初に一致したものが結果になるため、allow で細かい例外を作っても deny は上書きできません。権限モードの違いは権限モードの解説で扱っています。

deny ルールで止まらない経路はどう塞ぐか？

permissions.deny には公式に書かれた限界があります。Read と Edit の deny が効くのは、Claude の組み込みファイルツールと、cat、head、tail、sed、tee のように Claude Code が認識できる Bash コマンドです。grep -r pattern . のようにファイル名を指定せずに読むコマンドや、Python や Node のスクリプトが自分でファイルを開く場合には効きません。Bash(curl *) も、Claude が書いたコマンドの文字列に一致させる仕組みです。そのため /usr/bin/curl や sh -c 'curl …' は止まりません。

通信を制限するサンドボックスでこの隙間を OS のレベルで塞ぎます。既定ではオフで、セッション中に次のコマンドを実行して有効にします。

/sandbox

settings.json で sandbox.enabled を true にしても有効になります。macOS、Linux、WSL2 で動作し、ネイティブの Windows ではサンドボックスなしで実行されます。

有効にしても、既定のままでは秘密を守りきれません。公式の表によると、サンドボックス内のコマンドは ~/.ssh や ~/.aws/credentials を含むマシンの大部分を読めます。環境変数も、中に含まれる秘密ごと引き継がれます。ネットワークは直接外に出られず、手元のプロキシが接続先を許可ドメインのリストと照合します。このリストは最初は空で、リスト外のホストをどう扱うかは権限モードで決まります。認証ファイルと環境変数は sandbox.credentials で拒否します。公式の例は次のとおりです。

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    }
  }
}

サンドボックスが包むのはシェルコマンドだけです。Read などのファイルツール、MCP サーバー、フックはサンドボックスの外で動きます。ファイルツールには permissions.deny、シェルコマンドにはサンドボックスと、両方を組み合わせて隙間を埋めます。許可ドメインの書き方などの詳細はサンドボックス設定のガイドを参照してください。

手元の ~/.claude に残る記録はどう減らすか？

公式によると、Claude Code はセッションを再開できるよう、会話記録を ~/.claude/projects/ に平文で保存します。既定の保存期間は30日です。ツールを通ったもの、つまりファイルの中身、コマンドの出力、貼り付けた文字列はすべて書き込まれます。保存時の暗号化はなく、保護は OS のファイル権限だけです。Claude が .env を読んだり、コマンドが認証情報を出力したりすると、その値が projects/<project>/<session>.jsonl に残ります。

公式が挙げている手元の記録を減らす保存設定は次のとおりです。

cleanupPeriodDays を小さくして保存日数を短くする（既定30、最小1。0 は検証エラーになる）
環境変数 CLAUDE_CODE_SKIP_PROMPT_HISTORY を設定し、会話記録とプロンプト履歴を書き込まないようにする
非対話の -p 実行では --no-session-persistence を付ける
認証ファイルの読み取りを権限ルールで拒否する（前の見出しの設定）

すでに秘密が記録されたかもしれないプロジェクトでは、ターミナルで次のコマンドを実行します。

claude purge

このコマンドは、そのプロジェクトについて Claude Code が持っている状態を削除します。対象は projects/ 配下の会話記録と auto memory、history.jsonl の該当するプロンプト行、~/.claude.json のそのプロジェクトの項目などです。実行すると削除予定の一覧が表示され、確認を求められてから消えます。貼り付けた画像とセッションのスクラッチパッドは別の場所にあるため、このコマンドでは消えません。

他人のリポジトリや MCP を使うときは何に注意するか？

未信頼のリポジトリでは、起動時の信頼確認と MCP サーバーへの接続の扱いを確認してください。

対話セッションでは、まだ信頼していないフォルダで起動すると、ワークスペースの信頼ダイアログが表示されます。.mcp.json に書かれたサーバーにも、別途承認のプロンプトがあります。ただし claude -p で起動したセッションでは、どちらのプロンプトも出ません。公式の表によると、一度も信頼していないフォルダで claude -p や SDK を使うと、.mcp.json のサーバーには承認の有無にかかわらず確認なしで接続されます。入手元のわからないリポジトリを、-p で自動処理に流すのは避けてください。

MCP について、公式は2点を明記しています。1つは、.mcp.json を見ただけではセッションが読み込むサーバーの全体はわからないこと。もう1つは、Anthropic はコネクタを掲載基準で審査するものの、MCP サーバーのセキュリティ監査はしないことです。公式の推奨は、自作か信頼できる提供元のサーバーだけを使うことです。

設定が効いているかはどう確かめるか？

情報漏洩対策の設定は書いただけでは効いているかわかりません。筆者が勧める確認順は次のとおりです。

セッション中に /permissions を開きます。すべての権限ルールと、そのルールがどの settings.json から来ているかが一覧で表示されます。deny ルールが一覧にない場合は、ファイルの場所か JSON の書き方を見直してください。
起動時の警告を読みます。存在しないツール名を書いた deny や ask のルールは、タイプミス検出のために起動時に警告が出ます。読み込めずに飛ばされたルールは、起動時の無効設定ダイアログに表示されます。
ターミナルで次のコマンドを実行し、設定に関する警告が出ていないかを見ます。

claude doctor

Linux と WSL2 でサンドボックスを使う場合は、/sandbox のパネルで必要なパッケージが不足していないかを確認します。

公式は、権限設定を /permissions で定期的に監査するよう勧めています。この記事は2026年10月18日に取得した公式ドキュメントに基づいています。Claude Code を更新したあとは、Security と Data usage のページを読み直すことを勧めます。設定全体の点検はセキュリティ設定ガイド、個人や小規模チームのリスクの洗い出しはセキュリティリスクのガイドで扱っています。

流出事件の報道を見たら、何を確認すればよいか？

報道の真偽を追う前に、この記事の4つの経路のうち自分の環境で開いているものがないかを確かめます。学習設定、テレメトリの設定、deny ルール、~/.claude に残る記録の4点です。

自分で Claude Code の脆弱性を見つけた場合、公式は公表せずに HackerOne のプログラムから報告するよう求めています。報告には詳しい再現手順を付け、公表する前に、問題へ対処する時間を設けるよう求めています。過去のコミットに秘密が混ざっていないかを調べる手順は Claude Codeとgitの使い方ガイドに譲ります。

Claude Code の設定を自分で読み解けるようになりたい場合は、月額1,980円から参加できる学習コミュニティ「AI駆動ラボ」で、生成AIツールの運用を続けて学べる場を用意しています。