Claude Codeのセキュリティリスク｜個人利用で塞ぐべき6つの穴

Claude Codeのセキュリティリスクを、この記事では個人利用の視点で6つに整理します。①起動直後の権限モードを把握していない、②.envなどの秘密情報のファイルが作業ディレクトリ内なら確認なしで読める、③他人のリポジトリでは信頼の状況によってリポジトリ側のhooksなどが使われる、④MCPサーバーとプラグインが権限ルールの外でコードを実行する、⑤Webなど外部の内容に紛れた指示（プロンプトインジェクション）、⑥会話やコードの保存先と保持期間です。Claude Codeは確認プロンプト、分類器、サンドボックスといった仕組みを持っていますが、公式ドキュメントは承認前に提案されたコードやコマンドを確認する責任は利用者にあると明記しています。この記事では、6つそれぞれについて既定で守られる範囲と自分で塞ぐ範囲を分けて整理します。

組織での導入判断（管理設定、監査、契約）は対象外です。そちらは企業でClaude Codeのセキュリティを検討する際の論点を参照してください。

Claude Codeのセキュリティリスクは、どこまで自動で守られているのか？

先に全体像を表にまとめます。「既定で守る範囲」はClaude Codeの公式ドキュメント（Security、Permissions、Sandboxingほか）の記述に基づきます。

リスク	Claude Codeが既定で守る範囲	利用者が自分で塞ぐ範囲
①権限モード	auto modeでは分類器が危険と判断した操作を止める	今どのモードかを把握し、確実に止めたい操作はdenyルールにする
②機密ファイル	Manualではファイル変更と、組み込みの読み取り専用コマンドを除くBashは確認される	作業ディレクトリ内の読み取りは確認なしなので、`Read`のdenyを書く
③他人のリポジトリ	対話セッションで未信頼フォルダから起動するとworkspace trustダイアログが出る	`claude -p`ではダイアログが出ない点に備える
④MCP・プラグイン	MCPのツール呼び出しには権限ルールが効く	サーバーやプラグインの提供元を自分で判断する
⑤プロンプトインジェクション	`curl`等は自動承認されない、WebFetchは多くの場合、別モデル経由	承認前の確認、サンドボックスでの通信制限
⑥データの保存	通信はTLS 1.2+で暗号化	学習利用の設定、ローカル記録、`/feedback`の扱いを確認

前提として、権限ルールはモデルではなくClaude Code本体が強制します。公式によると、プロンプトやCLAUDE.mdの指示はClaudeの行動を方向づけるだけで、許可範囲は変えません。CLAUDE.mdに「.envは読まないで」と書いても制限にはならないので、制限は設定ファイルのルールに書きます。

起動したセッションは、確認なしでどこまで動く設定になっているのか？

いまのClaude Codeでは、端末とVS Codeの対話セッションの組み込みの開始モードはauto modeです。端末・VS Codeでautoが既定になるのはv2.1.283以降で、それより前のバージョンではPro、Max、Teamプランで機能フラグを取得するセッションだけがautoになり、それ以外はdefault（Manual）でした。autoが選ばれてもそのセッションで使えない場合はManualで始まります。

各モードで確認なしに動く範囲は次のとおりです（出典: Permission modes）。

モード	確認なしで動く範囲
`default`（Manual）	読み取りのみ
`acceptEdits`	読み取り、ファイル編集、`mkdir`・`touch`・`mv`・`cp`などの一般的なファイル操作
`auto`	すべて（背景で安全チェックあり）
`bypassPermissions`	すべて（公式の想定は隔離されたコンテナやVMのみ）

auto modeでは、別の分類器モデルが利用者の代わりに操作を審査します。curl | bashのようなダウンロードしたコードの実行、機密データの外部送信、force push、git reset --hardやgit clean -fdのように未コミットの変更を捨てるコマンドなどは既定でブロック対象です。分類器が信頼の範囲とするのは作業ディレクトリと、セッション開始時に設定済みだったgitリモートで、それ以外は、信頼するインフラを設定するまでは外部として扱われます。

個人利用で見落としやすいのは、会話で伝えた制約の扱いです。「pushしないで」と伝えると分類器はそれをブロックの合図として読みますが、公式によるとこの境界はルールとして保存されず、コンテキストの圧縮でその発言が消えると失われることがあります。確実に止めたい操作はdenyルールにしてください。denyルールはbypassPermissionsを含むすべてのモードで効きます。

セキュリティリスクを抑えて1回のセッションを確認重視で動かしたいときは、起動時にモードを指定します。

claude --permission-mode default

bypassPermissions（--dangerously-skip-permissionsと同等）は、インターネット接続のないコンテナ、VM、dev containerのような隔離環境に限るよう公式が警告しているモードです。手元のPCで誤って使わないようにしたい場合、permissions.disableBypassPermissionsModeを"disable"にすると自分自身をbypassから締め出せます。この設定はユーザー自身の設定からでも動くと公式に書かれています。

モードの選び方を詳しく知りたい場合は権限モードの種類と選び方にまとめています。

.envやAPIキーのファイルは、Claudeに読まれてしまうのか？

読まれる可能性があります。Manualモードでも、ファイルの読み取りとGrepは作業ディレクトリと追加ディレクトリの範囲なら承認なしで実行されます。プロジェクト直下の.envは、何も設定していなければ確認なしで読める位置にあります。

セキュリティリスク対策として公式のPermissionsが示している止め方は、permissions.denyにReadルールを書く方法です。設定リファレンスの例は次のとおりです。

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

この設定で、一致するファイルはファイル探索と検索結果から外れ、読み取りが拒否され、EditとWriteも同じパスでブロックされます。全プロジェクトに効かせたいなら、プロジェクトではなくユーザー設定の~/.claude/settings.jsonに書きます。./.envのような./で始まるパターンは、公式の表でカレントディレクトリ基準とされています。ルールの評価順はdeny、ask、allowの順で、allowルールでdenyの例外を作ることはできません。ユーザー設定のdenyはプロジェクト設定のallowにも勝ちます。なお、.claudeignoreを置いても効果はないと公式に書かれています。

ただし、このdenyには届かない経路があります。

grep -r pattern .のように、ファイル名を出さずに読むコマンド
PythonやNodeのスクリプトが自分でファイルを開く場合のような、任意のサブプロセス
Bash(curl *)は書かれた文字列に一致するだけなので、/usr/bin/curlやsh -c 'curl …'は止まらない

これらまで止めるにはOSレベルで制限するサンドボックスが必要です。サンドボックスは既定でオフで、セッション内で/sandboxを実行するか、sandbox.enabledをtrueにすると有効になります。動作環境はmacOS、Linux、WSL2で、ネイティブWindowsではコマンドはサンドボックスなしで実行されます。注意したいのは、サンドボックスの既定の読み取り範囲がマシンの大半で、~/.sshや~/.aws/credentialsも含まれる点です。読ませたくない場所はsandbox.filesystem.denyReadに追加します（公式例は"denyRead": ["~/.aws/credentials"]）。また、サンドボックスが囲うのはシェルコマンドだけで、Claudeのファイルツール、MCPサーバー、hooksはその外で動きます。設定手順はサンドボックスで制御できる範囲と確認手順で扱っています。

denyルールが効いていないように見えるときの確認

/permissionsを開き、書いたルールが一覧にあるか、どのsettings.jsonから来ているかを確認します。このダイアログは全ルールとその出所ファイルを表示します。
ファイルシステムのルートから書いたつもりのパスが/1つで始まっていないか確認します。先頭の/1つは設定ファイルの位置が基準になり、ルートから指定するには//で始めます。
Write(...)でパスを指定していないか確認します。Writeのパスルールは受け付けられても参照されず、起動時に警告が出ます。公式はWrite(docs/**)の代わりにEdit(docs/**)を使うよう案内しています。

設定ファイル全体の書き方はセキュリティ設定の手順にまとめています。

他人のリポジトリをcloneして開くと、何が勝手に動くのか？

公式のSecurityによると、対話セッションでまだ信頼していないフォルダを開くと、workspace trustダイアログが出ます。プロジェクトの.claude/settings.jsonにあるpermissions.allowは、このダイアログを承認するまで適用されません（denyとaskは制限側なので影響を受けません）。.mcp.jsonのサーバーにも別の承認プロンプトがあります。

穴になりやすいのは次の2つの状況です。

親フォルダだけを信頼している場合: 公式の表では、そのフォルダ自体を信頼していなくても、リポジトリの設定ファイルにあるhooks、envブロック、apiKeyHelperのような補助コマンドは使われるとされています。
claude -pで実行する場合: 公式は-pセッションではどちらのプロンプトも表示されないとしています。同じ表で、一度も信頼していないフォルダでのclaude -pでは、上記のhooksやenvも使われ、.mcp.jsonのサーバーは承認の有無にかかわらず確認なしで接続されるとされています。

もう1つ、ホームディレクトリで直接起動すると、信頼はそのセッション限りでディスクに保存されず、起動のたびにプロンプトが出ます。公式はプロジェクトのサブディレクトリから起動するよう勧めています。

自分で書いていないリポジトリでclaude -pを使う前の対策として、公式は次を挙げています。

--setting-sources userを渡し、プロジェクトの設定ファイルと.mcp.jsonを読ませない
--settings '{"disableAllHooks": true}'でその実行のhooksを止める（ユーザー設定に書くだけでは、プロジェクト設定がfalseに戻せるため不十分）
disabledMcpjsonServersに名前を入れて、特定の.mcp.jsonサーバーを全セッション種別で拒否する

MCPサーバーやプラグインは、どこまで信用してよいのか？

公式の立場ははっきりしていて、MCPサーバーは自作するか、信頼できる提供元のものを使うよう勧めています。Anthropicはディレクトリに載せるコネクタを掲載基準で審査しますが、どのMCPサーバーについてもセキュリティ監査や管理は行わないと書かれています。

プラグインはさらに範囲が広く、公式のPlugin securityは、インストールしたプラグインは利用者のユーザー権限でマシン上の任意のコードを実行できると説明しています。そして権限ルールとサンドボックスが対象にするのはClaudeのツール呼び出しで、プラグインが自分で走らせるコードは対象外です。hooksやローカルMCPサーバーは、利用者のフルアクセスで動きます。

個人で判断するときに公式の記述から使える観点は次の3つです。

マーケットプレイス名は中身を示さない: 名前が示すのはカタログの発行者で、個々のプラグインが何をするかではありません。どこから入れる場合も中身を確認します。
自動更新でレビュー済みの内容が変わりうる: 自動更新が有効なマーケットプレイスでは、レビューしたファイルがバックグラウンドで更新されます。
.mcp.jsonだけ見ても全体はわからない: 他のスコープのサーバーやclaude.aiのコネクタはリポジトリの外で設定され、プラグインがサーバーを追加する場合もあります。

MCPのツール呼び出し自体には権限ルールが効くので、使わないサーバーのツールはmcp__<server>__*の形でdenyに入れられます。MCPの設定方法はMCPの仕組みと設定手順、プラグインの導入はプラグインのガイドで扱っています。

プロンプトインジェクションには、何が組み込まれていて何が利用者に残るのか？

プロンプトインジェクションは、読み込んだWebページや文書に紛れ込ませた文章で、AIへの指示を上書きしようとする手法です。公式のSecurityが挙げている組み込みの対策は次のとおりです。

curlやwgetのようなWeb取得コマンドは、既定で自動承認されない
WebFetchは多くの場合、ページを別のモデル呼び出しで処理し、Claudeは生のページではなくその回答を受け取る
Manualモードでは、解析しきれないBashコマンドは確認される。Bash(git *)のような部分的なallowがあってもこの確認は省略されない
Manualモードでは、どのルールにも一致しないコマンドは既定で承認が必要

それでも公式は、これらの保護はリスクを大きく下げるものの、すべての攻撃に耐えるシステムはないと書いています。利用者側に残る対策として挙げられているのは、承認前のコマンド確認、信頼できない内容をClaudeに直接パイプしないこと、重要ファイルへの変更の確認、送信先となる外部のWebサービスを扱う作業のVMでの実行、怪しい挙動の/feedbackでの報告です。

権限とサンドボックスの関係について、公式は、プロンプトインジェクションがClaudeの判断を迂回してもサンドボックスの制限は残るため、両方を重ねて使うよう説明しています。外部の文書を多く読ませる使い方なら、サンドボックスを有効にして通信先を許可ドメインで絞る構成が向いています。サンドボックスのネットワークは直接の外向き経路を持たず、許可ドメインのリストは空から始まります。

会話やコードはどこに送られ、どこに残るのか？

公式のData usageによると、プロンプトとモデルの出力はTLS 1.2+で暗号化されて送信されます。そのうえで、個人向けプランで確認したいのは次の4点です。

項目	公式の記述
学習利用	Free、Pro、Maxは設定がオンのとき、Claude Codeでの利用を含めて学習に使われる
サーバー側の保持期間	学習を許可すると5年、許可しないと30日。設定はclaude.aiのデータプライバシー設定でいつでも変更できる
ローカルの記録	セッション記録は`~/.claude/projects/`に平文で既定30日保存。期間は`cleanupPeriodDays`で調整
`/feedback`で送った記録	`/bug`、`/share`も同じ経路で、5年保持。`DISABLE_FEEDBACK_COMMAND=1`で無効化

法律・税務上の助言ではありません。契約や利用の可否は、規約の原文または専門家にご確認ください。

ローカルの保存場所にある記録が平文である点は、PCを共有している場合や、同期ツールでホームディレクトリを外部に送っている場合に関係します。また、セッションの評価のあとに、記録を見てよいかを尋ねる任意の質問が別に出ることがあります。ここで「Yes」を選ぶと、ソースコードやファイルの内容がそのままアップロードされます。この記録共有は「Yes」を選ばない限り行われません。

メトリクスにコード、プロンプト、ファイルパスは含まれず、DISABLE_TELEMETRY=1で止められます。エラーレポートが有効になるのは、Pro・Maxでサインインし、v2.1.198以降を使い、Claude APIに直接接続し、組織がゼロデータ保持やHIPAAの契約を結んでいない、という条件をすべて満たすときで、DISABLE_ERROR_REPORTING=1で止められます。学習利用とテレメトリの止め方の違いはオプトアウト設定の解説で扱っています。情報漏洩のリスクを詳しく知りたい場合は情報漏洩の事象と日常利用のリスクを参照してください。

今日確認するなら、どの順番で見ればよいか？

上の6つを、確認の順番として手を動かしやすい順にこの記事で並べ直すと次のとおりです。

モード: 既定はauto modeと押さえ、確認重視のセッションは--permission-mode defaultで起動する。止めたい操作はdenyルールに書く。
/permissions: 公式も定期的な監査に勧めています。確認プロンプトで「Yes, and don’t ask again」を選んで恒久保存されたルールはリポジトリルートの.claude/settings.local.jsonに入り以後のセッションにも効くので、覚えのないallowを探す。
機密ファイル: ~/.claude/settings.jsonにRead(./.env)などのdenyを追加する。
サンドボックス: macOS、Linux、WSL2なら/sandboxで有効にし、読ませたくない資格情報ファイルをsandbox.filesystem.denyReadに入れる。
MCPとプラグイン: 提供元を説明できないもの、使っていないものを外す。
データ: claude.aiのプライバシー設定で学習利用を確認し、ローカル記録の保存期間をcleanupPeriodDaysで決める。

確認の過程でClaude Code自体の脆弱性に気づいた場合は、公開せずにAnthropicのHackerOneプログラムから報告するよう公式に案内されています。

ここで挙げた既定値のうち、開始モードとエラーレポートの対象は、公式ドキュメント上でもバージョン番号つきで条件が書き分けられている項目です。この記事の記述は、2026年10月19日に取得した公式ドキュメントと照合しています。手元のバージョンが記事の条件と合わない場合は、公式のSecurityとPermission modes、Data usageのページで該当箇所を見直してください。