Claude Codeのセキュリティ対策と設定｜個人・企業で今すぐやるべきチェックリスト【2026】

Claude Codeのセキュリティ対策で、まず今日やることは3つです。①.envなどの秘密情報を、Readのdenyルールで読ませない。②知らないフォルダを安易に信頼せず、確認画面の「Yes」を押し続けない。③サンドボックスを有効にし、/sandboxで実際に動いているかまで確かめる。denyだけでは、Pythonなどのスクリプト経由の読み取りは止まりません（この端末で確認）。設定の書き方はチェックリストにまとめています。企業で使う場合は、権限ルールの設計と定期的な見直しを導入前に決めておくことが前提です。

Claude Codeは、Anthropicの生成AI「Claude（クロード）」が、手元のパソコンでファイルを読み書きし、コマンドを実行するツールです。できることが多いぶん、何を許すかは利用者が決める必要があります。この記事の「セキュリティ」は、2つの意味に分けて読めます。1つはClaude Codeに何を許すかの設定（権限・サンドボックス・送ったデータの扱い・企業での管理）、もう1つは書かれたコードの脆弱性を見つける公式機能「Claude Security」です。前者を中心に、Anthropic公式ドキュメントにもとづいて解説します（確認日は参考文献に記載）。

先に、この記事で使う言葉の言い換えです。

Claude Codeのセキュリティの全体像：起きうること7つと、止める仕組み

先に、Claude Codeを使うときに起きうる問題と、それを止める公式の仕組みを一覧にします。どれも設定で大きく減らせますが、1つの仕組みですべてを防げるわけではありません。

実際に公開された脆弱性と、依存パッケージの乗っ取りの例は、後半の節にまとめています。

確認画面で「Yes」を押し続けると何が起きるか

Manualモードでは、Claude Codeはファイルの編集やコマンドの実行の前に確認を出します。ここで「Yes, and don’t ask again」を選ぶと、Bashコマンドとウェブ取得（WebFetch）のドメインについては、許可のルールがリポジトリの直下の .claude/settings.local.json に保存され、以後そのリポジトリのすべてのセッションで確認なしに通ります。ファイル編集の許可はファイルに保存されず、セッションの終わりまでです（公式 Configure permissions）。

つまり、確認を読まずに押し続けると、広い許可が気づかないうちに積み上がっていきます。後で紹介する /permissions で定期的に見直すのはこのためです。

もう1つ知っておきたいのが、起動時のモードです。v2.1.283以降、ターミナルとVS Codeでは「autoモード」が組み込みの開始モードで、別の分類器モデルが操作を確認し、危険と判断したものだけを止めます。すべて自分で確認したい場合はManualモードで起動します（公式 Permission modes、違いは後述の表）。

守りは3つの層で考える

• 権限（パーミッション）：Claude Code本体が、ツールの呼び出しごとに「許可・確認・拒否」を判定します。この判定はClaude Codeが行うもので、モデルが行うのではありません。プロンプトやCLAUDE.mdに書いた指示はClaudeが試みる動きを変えますが、Claude Codeが許可する範囲は変えません。
• サンドボックス：Bashなどのシェルコマンドと、そこから起動したプログラムが触れるファイルと通信先を、OSの仕組みで制限します。
• 環境の分離：dev container（開発用コンテナ）や仮想マシンの中でClaude Code全体を動かし、手元のパソコンから切り離します。

公式は、権限とサンドボックスを「互いを補う2つの層」と説明しています。プロンプトインジェクションでClaudeの判断がだまされても、サンドボックスの制限は残るためです。

権限の許可・確認・拒否を実際にどう決めるかは、Claude Code 権限設定で解説しています。

関連記事Claude Codeで学習させない設定は？

まずやるべきClaude Codeのセキュリティ設定チェックリスト（個人・チーム共通）

Claude Codeのセキュリティは、ほとんどが手元の設定で決まります。企業導入の検討に入る前に、個人でも今日から実施できる対策を、公式ドキュメント（Security・Permissions・Permission modes・Sandboxing）に沿って一覧にしました。

1・2・5番は、次の1つの設定ファイルにまとめて書けます（~/.claude/settings.json に書くと自分のすべてのプロジェクトに、プロジェクトの .claude/settings.json に書くとそのプロジェクトに効きます）。保存後、Claude Code内で /status を実行すると、設定ファイルが読み込まれたかを確認できます。

{
  "permissions": {
    "defaultMode": "default",
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Bash(curl *)",
      "Bash(wget *)"
    ],
    "ask": [
      "Bash(git push *)"
    ]
  }
}

この例では、秘密情報のファイルを読ませず、curl・wget を禁止し、git push の前には必ず確認を出します。対象は自分の環境に合わせて変えてください。

実際の画面：初めてのフォルダで出る確認

表の4番目（知らないリポジトリを安易に信頼しない）に当たる画面です。信頼ダイアログは、まだ信頼していないフォルダでClaude Codeを対話モードで起動したときに出ます。

このダイアログには、そのフォルダの設定ファイルが許可しようとしているルールや追加のフォルダが並びます。プロジェクトの .claude/settings.json にある permissions.allow のルールは、ここで信頼するまで使われません（denyとaskのルールは制限するだけなので、信頼の前から効きます）。

公式によると、ホームフォルダの直下でClaude Codeを起動した場合、この信頼は今回のセッションだけのものになり、ディスクに保存されないため、起動のたびに確認が出ます。設定でこれを保存することはできません。プロジェクトのサブフォルダで起動すれば、フォルダ（Gitのリポジトリならリポジトリの直下）ごとに信頼が保存されます。

Claude Security（脆弱性スキャン）とは：書かれたコードの脆弱性を見つける公式機能

「Claude Codeのセキュリティ」には、AIの操作の範囲を絞る設定（この後の節）とは別に、書かれたコードに潜む脆弱性を見つけるための公式機能もあります。2026年2月20日に「Claude Code Security」が、TeamプランとEnterpriseプランの利用者向けの限られた研究プレビューとして発表されました。既知のパターンに照らすのではなく、部品どうしの関係やデータの流れを読み取って脆弱性を探し、人が確認するための修正案（パッチ）を出します（出典：Anthropic公式発表）。

現在の公式製品ページ（Claude Security）では、名称が「Claude Security」になり、コードベースをスキャンして指摘を検証し直したうえで修正案を出し、修正は人が確認・承認してから適用する、と説明されています。提供形態は2つです。Claude.aiのアプリはClaude Enterprise向けのパブリックベータで、スキャンには Claude Mythos 5.1 が使われます（このモデルでのスキャンはアプリでのみ）。Claude Code用のプラグインは、すべてのClaude Codeの利用者向けにベータで提供されています。

Claude Codeで使えるセキュリティ確認の道具は5段階

公式ドキュメントは、脆弱性の確認を1つの道具に任せず、段階ごとに重ねる形を勧めています。どの段階で何を使うかを、公式の表に沿ってまとめます。

security-guidance プラグインは、ターミナルのClaude Codeで次のように入れます。入れた後は自動で動き、呼び出すコマンドはありません。Python 3.7以降が必要で、ターンの終わりやコミットのときの確認はGitのリポジトリの中でだけ動きます。

/plugin install security-guidance@claude-plugins-official

公式は、どの段階も「保証ではなく、後の確認の代わりにはならない」と注意しています。/security-review の使い方はClaude Codeのレビュー用コマンドの解説で詳しく説明しています。

権限（パーミッション）の仕組み：6つのモードと確認の出方

権限モードは6種類

権限モードは、Claudeが確認なしで何を実行できるかの基準を決めます（公式 Permission modes）。

denyルールは、bypassPermissions を含むすべてのモードで効きます。また、設定ファイルなどの「保護されたパス」への書き込みは、bypassPermissions など一部の場合を除いて自動承認されません。組織では、bypassPermissions を使えないように管理設定で止めることもできます（後述）。

ツールの種類ごとの確認と、「今後確認しない」の範囲

Manualモードでの確認の出方は、ツールの種類で決まります。

実際の画面：ファイルを作るときの確認

上の表の「ファイルの編集・書き込み」の行に当たる画面です。Claude Codeがファイルを作る前に、内容を見せて許可を求めます。

Manualモードには、解析しきれないBashコマンド、どのルールにも当てはまらないコマンド、起動したフォルダの外へのファイル操作の前にも確認が出る守りがあります（公式 Security）。ただし最後の確認は画面上の境界なので、承認したBashコマンドは、自分のユーザーの権限が及ぶ場所ならどこにでも書けます。OSのレベルで止めたい場合はサンドボックスを使います。

権限ルールの書き方：allow・ask・denyと設定ファイルの置き場所

チェックリストの「.envを読ませない」「広すぎる許可を絞る」を実際に設定するには、権限ルールの書き方を知っておく必要があります。公式ドキュメント（Configure permissions）の要点をまとめます。

ルールは3種類。判定は deny → ask → allow の順

ルールは deny、ask、allow の順に評価され、最初に当てはまったものが結果になります。ルールの細かさは順番に影響しません。そのため、広いdenyルール（例：Bash(aws *)）があると、より細かいallowルール（例：Bash(aws s3 ls)）を書いても実行できません。allowでdenyの例外は作れないという点が、はまりやすいところです。

ルールの書式

読ませたくないファイルは Read の deny で指定する（.claudeignore は効かない）

公式ドキュメントは、ファイルやフォルダを読ませないようにするには Read のdenyルールを追加する、としています。プロジェクトに .claudeignore というファイルを置いても効果はなく、その内容は Read のdenyルールへ移すよう案内されています。

• Read のdenyルールは、同じパスへの編集・書き込み（新規作成を含む）も止めます。ノートブックの編集（NotebookEdit）は対象外なので、どのツールにも変えさせたくないパスには Edit のdenyも足します。
• Read・Edit のdenyルールが効くのは、Claudeの組み込みのファイル操作と、cat・head・tail・sed・tee などClaude Codeが認識できるBashのファイル操作、> file のようなリダイレクトまでです。
• PythonやNodeのスクリプトが自分でファイルを開く場合のように、別のプログラムを経由した読み書きには効きません。そこまで止めたい場合は、OSのレベルで制限するサンドボックスを併用します。

実際の画面：denyルールで.envが読めなかったとき

危険なコマンドをdenyへ入れる：ただし書き方を変えられると止まらない

確認画面で「Yes」を押し続ける使い方になりやすい人ほど、通信や削除のコマンドは最初からdenyに入れておくと安全です。次は、通信のコマンドと削除のコマンドを止める例です（対象は環境に合わせて変えてください）。

{
  "permissions": {
    "deny": [
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(rm *)"
    ]
  }
}

公式の権限ドキュメント（Configure permissions の「What a Bash rule doesn’t match」）は、Bashのルールを「Claudeが書いたコマンドの文字列に一致させる仕組み」と説明し、denyやaskは、そのプログラムの周りの安全の境界ではないとしています。公式の表では、次の書き方は止まりません。

ルールの照合前に公式が自動で外す「ラッパー」は、timeout・time・nice・nohup・stdbuf・command・builtin・noglob と、フラグなしの xargs に限られます。direnv exec・devbox run・mise exec・npx・docker exec は外されないため、Bash(devbox run *) のような許可は、run の後ろに何が来ても一致します。

対策は3つを重ねます。いずれも公式が挙げている手段です。

• 書き方の違いを足して塞ぐ：sh -c や絶対パスの形まで止めたいときは、Bash(bash -c *)・Bash(sh -c *) のように、その形をdenyへ追加します（公式のワイルドカードの書式に沿った例で、この記事では実機検証していません。書き方を変えられるとまた漏れるため、これだけでは境界になりません）。
• コマンドの文字列に頼らない境界を使う：ファイルと通信の制限はサンドボックスで行います（次の節）。公式も「文字列に依存しない強制にはサンドボックスを使う」としています。
• 実行前に自分のロジックで検査する：PreToolUseフックで、コマンドの全文を実行前に確かめます。

PreToolUseフックは、終了コード2で呼び出しを止めます。次は、rm -rf を含むBashコマンドを止めるフックの登録例です（書式は公式のhooksガイドの例に沿っています）。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/block-rm-rf.sh"
          }
        ]
      }
    ]
  }
}

止めるスクリプトは、公式の protect-files.sh（Edit・Write用）の書き方に沿って、Bash用に作れます。入力のJSONからコマンドを取り出し、条件に合えば標準エラー出力に理由を書いて終了コード2で終わります。理由はClaudeに渡るので、別のやり方を探してもらえます。次はその一例です（.claude/hooks/block-rm-rf.sh に保存し、chmod +x します）。

#!/bin/bash
INPUT=$(cat)
COMMAND=$(echo "$INPUT" | jq -r '.tool_input.command // empty')

if echo "$COMMAND" | grep -q 'rm -rf'; then
  echo "Blocked: rm -rf is not allowed" >&2
  exit 2
fi

exit 0

権限設定の全体はClaude Codeの権限設定の解説で詳しく説明しています。

.envの秘密情報を、そもそもファイルに置かない：実行時にだけ渡す

Readのdenyは「読ませない」守りで、キーがファイルに平文で残る問題は解決しません。キーをファイルに置かず、コマンドを実行するときだけ環境変数として渡す方法があります。次は、各ツールの公式ドキュメントで確認できる使い方です（2026年10月20日確認）。

どの方法でも、渡した環境変数は実行するコマンドから読めます。そのため、本番の強い権限のキーではなく、権限を絞った開発用のキーを渡すのが基本です。あわせて、.env などのファイルはReadのdenyに入れたままにしておきます。1Password CLI・Doppler・direnvの導入は、それぞれの公式ドキュメントに従ってください。

秘密情報がコミットに紛れ込むのを防ぐ道具もあります。gitleaks は、パスワード・APIキー・トークンなどの秘密情報をGitのリポジトリから検出するツールです。公式のREADMEは、リポジトリの直下の .pre-commit-config.yaml に次のように書き、pre-commit install を実行する方法を示しています（rev はREADMEの例で、pre-commit autoupdate で更新します）。コミットの前に検査が走るため、.env を読ませない設定とは別の、もう1つの網になります。

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.24.2
    hooks:
      - id: gitleaks

設定ファイルの置き場所と優先順位

どこか1か所でdenyされたツールは、ほかの場所の設定や起動時の引数で許可することはできません。たとえばユーザー設定で許可していても、プロジェクト設定でdenyしていればブロックされます（逆も同じです）。

設定した後は、/permissions で、どのルールがどの設定ファイルから読み込まれているかを一覧で確認できます（画面は下の「企業・チームで導入するときの設定方針」の節にあります）。

サンドボックスで、コマンドが触れる範囲をOSのレベルで絞る

サンドボックスは、Claudeが実行するシェルコマンドと、そこから起動したプログラムを、決められた範囲の中だけで動かす仕組みです。既定ではオフで、Claude Code内で /sandbox を実行するか、設定ファイルで sandbox.enabled を true にすると有効になります（公式 Sandboxing）。

有効にしたときに、コマンドが既定で届く範囲は次のとおりです。読み取りはパソコンのほぼ全体に届く点に注意が必要です。

公式は「組み込みの認証情報の拒否リストは無く、指定したファイルと変数だけが制限される」と明記しています。SSHの鍵やクラウドの認証情報は、自分で credentials に書く必要があります。次は、認証情報を読ませず、決めたドメインにだけ通信させる設定の例です。

{
  "sandbox": {
    "enabled": true,
    "allowUnsandboxedCommands": false,
    "credentials": {
      "files": [
        { "path": "~/.ssh", "mode": "deny" },
        { "path": "~/.aws/credentials", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" }
      ]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

allowUnsandboxedCommands を false にすると、サンドボックスの中で失敗したコマンドを、Claudeが外で実行し直す逃げ道（確認つきの再実行）を止められます。

サンドボックスの外で動くもの

サンドボックスが包むのはシェルコマンドだけです。次のものは外で動くため、それぞれ別の手当てが必要です。

• Read・Edit・Write・WebFetch・WebSearch などの組み込みのツール：権限ルールに従います。denyRead ではReadツールは止まらず、allowedDomains ではWebFetchは制限されません。
• フック（hooks）、手元で動くMCPサーバー、ステータスラインのコマンド、apiKeyHelper など：利用者と同じ権限で動きます。
• 自分で ! から打ったコマンド、excludedCommands に入れたコマンド、サンドボックスの外での再実行を認めたコマンド。

動く環境は、macOS・Linux・WSL2です（LinuxとWSL2では bubblewrap と socat が必要）。Windowsのネイティブ環境ではサンドボックスが使えず、コマンドはサンドボックスなしで動くため、使うならWSL2の中でClaude Codeを動かします。必要なものが無くて起動できないときも、既定ではサンドボックスなしで動くので、止めたい場合は sandbox.failIfUnavailable を true にします。詳しい設定はClaude Codeのサンドボックスの解説で説明しています。

実際に試して分かったこと：.envのdenyとサンドボックスはどこまで効くか

ここまでの説明が実際の動きと合っているかを、この端末で確かめました。条件は次のとおりです。

• 日時と環境：2026年10月16日、Linux（Ubuntu）、Claude Code v2.1.301
• 検証用の空のフォルダを作り、.env には「TEST_TOKEN=test」という無害な1行だけを書きました（本物の秘密情報は使っていません）
• プロジェクトの .claude/settings.json に、チェックリストの例と同じ Read(./.env)・Read(./.env.*) のdenyを書きました
• 同じフォルダに、.env を開いて表示するだけのPythonスクリプト read_env.py（中身は print(open('.env').read()) の1行）を置きました

denyを入れても、Pythonスクリプト経由では読めた

Readのdenyルールは、Claudeの組み込みのファイル操作と、cat のようにClaude Codeが読み取りと認識できるコマンドには効きました。一方、.env を開くPythonスクリプトの実行は、denyでは止まりませんでした。止めていたのは、Manualモードの実行確認だけです。

これは公式ドキュメントの「別のプログラムを経由した読み書きには効かない」という説明どおりの動きです。確認画面の内容が python3 read_env.py だけなので、スクリプトの中身を知らなければ、.env を読むことに気づけません。確認画面で「今後確認しない」を選んで python3 * を許可していた場合は、確認なしで中身が会話に入ります（非対話の -p で実際にそうなりました）。

なお、同じ会話で先に cat .env が拒否されていたときは、Claudeが迂回を控えました。ただしこれはモデルのその場の判断で、設定による制限ではありません。新しい会話では、そのまま実行の確認が出ました。

サンドボックスは、必要なものが無いと動かないまま使えてしまう

サンドボックスを有効にする設定を入れても、Linuxで socat が入っていない状態では、サンドボックスは動きませんでした。非対話の実行では「Sandbox disabled: sandbox is enabled but dependencies are missing: socat not installed」「Commands will run WITHOUT sandboxing.」という警告が出ましたが、対話の画面ではそのまま普段どおりに使え、Pythonスクリプトは .env を読めました。

socatを用意してサンドボックスが動く状態にすると、同じスクリプトは読み取りを拒否されました。公式の説明どおり、Readのdenyルールがサンドボックスの読み取り制限にも加わり、Pythonのような別のプログラムにもOSのレベルで効いたことになります。

サンドボックスを使うなら、有効にした後に /sandbox のDependenciesタブで不足が無いかを確かめます。また、作業フォルダの外のファイルは credentials に書くまで読めたので、守りたい認証情報は1つずつ書き出します。

autoモードでも、askルールは確認画面を出した

autoモードでも、Bash(npm install *) のaskルールを入れておくと、npm install は自動では通らず、確認画面が出ました。上の「依存パッケージの乗っ取り」で紹介した設定は、autoモードで使う場合にも効きます。

実際の脅威への備え：公開された脆弱性・依存パッケージ・プロンプトインジェクション・MCP

プロンプトインジェクションは、コードのコメントや外部のファイル、Webページなどに悪意のある文を紛れ込ませ、AIの指示を上書きしようとする手口です。Claude Codeでは、知らないリポジトリそのものにも、設定ファイルやMCPサーバーの指定が入っている場合があります。

実際に公開された脆弱性：知らないリポジトリから始まるものが多い

Anthropicは、Claude Codeの脆弱性をGitHubのセキュリティアドバイザリで公開しています（anthropics/claude-code のSecurity Advisories、2026年10月21日時点で35件。Claude Desktopの分を含みます）。そのうち、この記事の対策と関係が深いものを抜き出しました。

公式の説明から読み取れる点は3つです。1つ目は、多くが「悪意のあるリポジトリを開く」「信頼できない内容をClaudeに読ませる」ことを条件にしている点です。知らないリポジトリを安易に信頼しない、という基本が効きます。2つ目は、denyルールやサンドボックスにも抜け道が見つかってきた点です。1つの仕組みに頼らず重ねるのはこのためです。3つ目は、どれも修正済みで、公式は「自動更新の利用者には修正が届いている。手動で更新している場合は最新版にするように」と案内している点です。更新を長く止めること自体がリスクになります。手元の版は claude --version で確認できます。

依存パッケージの乗っ取り：2026年3月のaxiosの例

Claude自身の不具合とは別に、Claudeが実行する npm install などで、乗っ取られたパッケージを入れてしまう危険もあります。2026年3月31日、GitHubのアドバイザリデータベースは、JavaScriptで広く使われる通信ライブラリ axios の 1.14.1 と 0.30.4 にマルウェアが含まれていたとして警告（GHSA-fw8c-xr5c-95f9「Malware in axios」）を公開しました。警告は、入れたコンピューターを「完全に乗っ取られたもの」とみなし、そこに保存していた秘密情報と鍵を別のコンピューターから直ちに変更するよう求めています。

被害を小さくする設定は2つです（どちらも公式の設定です）。

• Bash(npm install *) などをaskルールに入れ、パッケージの追加は毎回自分で確認する（autoモードでも効きます。実際の画面。npm i のような別の書き方を使う場合はそれも足します）
• サンドボックスを有効にし、credentials で認証情報を拒否し、通信先を allowedDomains に絞る（制限は、インストール時のスクリプトにも及びます）

{
  "permissions": {
    "ask": [
      "Bash(npm install *)",
      "Bash(pnpm add *)",
      "Bash(pip install *)"
    ]
  }
}

許可した通信先（パッケージの配布元など）の中で起きる乗っ取りまでは、サンドボックスでは見分けられません。依存パッケージの確認は、CIの既存のスキャナーでも行います。

パッケージ側の対策として、公開から日が浅い版を入れない設定もあります。npm公式の設定 min-release-age は、指定した日数より前に公開された版だけをインストールの対象にします（既定は未設定です。たとえば .npmrc に min-release-age=7 と書くと、公開から7日以内の版は入りません）。ただし、条件に合う版が無いとインストールはエラーになり、npm audit fix は修正版が公開から日が浅いと入れられず、脆弱な版のまま警告を出して終わります（npm Docs: config）。

プロンプトインジェクションへの公式の備えと、MCPサーバー

• curl・wget など、Webから内容を取ってくるコマンドは既定で自動承認されません。
• WebFetchでは、多くの場合、ページをそのままClaudeに渡さず、別のモデルの呼び出しで要約した答えを渡します。
• 内容を解析しきれないコマンドは確認が出て、どのルールにも当てはまらないコマンドも既定で確認が必要です（Manualモード）。

あわせて公式は、信頼できない内容を扱うときの注意として、「承認する前に提案されたコマンドを確認する」「信頼できない内容をClaudeに直接パイプしない」「重要なファイルへの変更を確かめる」「外部のWebサービスとやり取りするときは仮想マシンで動かす」「怪しい動きは /feedback で報告する」の5つを挙げています。そのうえで、これらの保護はリスクを大きく下げるが、すべての攻撃を防げるわけではない、と明記しています。

MCPサーバーの監査の責任は、利用する側にあります。

プロジェクトで使うMCPサーバーは .mcp.json に書き、ソース管理に入れられます。ただし、ほかの範囲の設定やclaude.aiのコネクタ、プラグインが追加するサーバーもあるため、.mcp.json を見るだけでは、セッションが読み込むサーバーのすべては分かりません。Anthropicはディレクトリに載せるコネクタを掲載基準に照らして確認しますが、個々のMCPサーバーのセキュリティ監査や管理は行いません。自作か信頼できる提供元のものだけを使い、組織では管理設定で使えるサーバーを制限します。MCPの基本はClaude CodeのMCPの解説で説明しています。

プラグイン・スキル経由で入る危険：入れる前に中身を読む

プラグインは、フック・MCPサーバー・スキルなどをまとめて配る仕組みです。公式の Plugin security and trust（2026年10月20日確認）は、「インストールしたプラグインは、利用者の権限で任意のコードを実行できる」と明記しています。Claude Codeの権限ルールとサンドボックスが守るのは「Claudeが行うツール呼び出し」で、プラグインが自分で動かすコードは対象外です。

入れる前の確認は、公式が次の順を示しています。

1. claude plugin marketplace list で、マーケットプレイスの取得元（GitHubのリポジトリなど）を確かめます。
2. セッションで /plugin を開き、詳細の「Will install」で、追加されるコマンド・エージェント・スキル・フック・MCPやLSPサーバーを確かめます。
3. ただし「Will install」は、フックが「ある」ことは示しても「何を実行するか」は示しません。取得元のリポジトリで、hooks/hooks.json・.mcp.json・bin/ を読みます。
4. 信頼できなくなったら、シェルで claude plugin uninstall <plugin> を実行します。取得元ごと外すなら、マーケットプレイスも削除します。

公式のマーケットプレイスの名前は予約されていて、github.com/anthropics/ 以外の取得元はその名前を名乗れません。ただし公式は、名前は「誰が公開しているか」を示すだけで、中のプラグインが何をするかは示さない、と注意しています。どのマーケットプレイスのものでも、入れる前に読みます。スキル単体（SKILL.md）も、命令文を含むファイルなので、知らない人が書いたものは中身を読んでから置きます。

非対話（-p）で知らないリポジトリを動かすときの注意

claude -p での実行や Agent SDK では、信頼ダイアログが出ません。公式の表によると、そのフォルダを信頼していなくても、次のものは使われます。

• プロジェクトの設定ファイルにあるフック、env の設定、apiKeyHelper などの補助コマンド
• .mcp.json にあるMCPサーバー（承認の有無にかかわらず、確認なしで接続されます）

一方、プロジェクトの permissions.allow のルールは使われません。自分が書いていないリポジトリで -p を使う前には、公式が挙げる次の方法で、読み込むものを絞ります。

• --setting-sources user を付けて、プロジェクトの設定ファイルと .mcp.json を読まないようにする
• --bare で起動し、プロジェクトのフック・スキル・サブエージェント・プラグイン・MCPサーバーを読まないようにする（env の設定などは残ります）
• --settings '{"disableAllHooks": true}' で、その実行だけフックを止める（ユーザー設定に書くだけでは、プロジェクト設定で戻されることがあります）

Windowsでの注意：WebDAV

Windowsで使う場合、公式はWebDAVを有効にすることや、\\* のようなWebDAVのサブフォルダを含みうるパスへのアクセスを許すことを勧めていません。WebDAVはMicrosoftが非推奨にしており、有効にするとClaude Codeが外部のホストへ通信し、権限の仕組みを迂回する経路になりうるためです。

コードやプロンプトの送信先・保存期間・学習への利用（公式の記載）

Claude Codeは手元で動きますが、モデルとやり取りするために、入力したプロンプトとモデルの出力をネットワーク経由で送ります（通信はTLS 1.2以上で暗号化）。保存期間と学習への利用は、アカウントの種類で決まります。公式のデータ利用の文書（Data usage）の記載を、種類ごとに表にまとめました。

送る情報を減らしたい場合の設定も、公式に載っています。使用状況の計測は DISABLE_TELEMETRY=1、エラー報告は DISABLE_ERROR_REPORTING=1、/feedback は DISABLE_FEEDBACK_COMMAND=1、アンケートは CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY=1 で止められます。CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC を設定すると、必須でない通信をまとめて止められます。計測にはコード・プロンプト・ファイルパスは含まれないと公式は説明しています。Amazon Bedrock・Google Cloud の Agent Platform・Microsoft Foundry・Claude Platform on AWS を使う場合、計測・エラー報告・/feedback の送信は既定でオフです。

注意したい点が3つあります。

1. WebFetchツールは、URLを取得する前に、ホスト名（URL全体ではありません）を安全確認の一覧と照合するため api.anthropic.com へ送ります。この確認は、どのモデル提供元を使っていても動きます。社内のネットワークで api.anthropic.com を遮断していると、WebFetchは失敗します。
2. 手元の会話の記録は平文で残ります。機密を扱う端末では、保存期間を短くするか、共有の端末で使わない運用を決めておくと安心です。
3. APIキーやトークンは、macOSではキーチェーン（使える場合）に、Linuxでは所有者だけが読み書きできるファイル（権限0600）に保存されます。

企業・チームで導入するときの設定方針

個人の設定は、利用者が自分で変えられます。組織として守りを揃えるには、設定の配り方・監視・更新の管理までを決めておきます。公式が「チームのセキュリティ」として挙げるのは、管理設定で組織の基準を強制する、承認済みの権限設定をバージョン管理で共有する、メンバーを教育する、OpenTelemetryの計測で利用状況を見る、ConfigChange フックでセッション中の設定変更を監査・ブロックする、の5つです。

managed settingsで、利用者が外せない守りを作る

管理者が配る管理設定（managed settings）の権限ルールは、ユーザー設定・プロジェクト設定・起動時の引数のどれでも上書きできません（公式 Deploy managed settings）。配り方は、端末の管理方法に合わせて選びます。

公式の例は次のとおりです。秘密情報を読ませず、確認をすべて省く bypassPermissions モードを使えなくし、権限ルールの取得元を管理設定だけに限っています。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)"
    ],
    "disableBypassPermissionsMode": "disable"
  },
  "allowManagedPermissionRulesOnly": true
}

管理設定で sandbox.allowUnsandboxedCommands を false にすると、サンドボックスは「管理者が必須にした」状態になり、リポジトリの設定ファイルでサンドボックスを緩める指定は無視されます。どの設定がどこから効いているかは、各端末の /status で確認できます。

組織でプラグインの取得元まで固定するなら、同じ管理設定に次のキーを足します（公式 Manage Claude Code plugins for your organization、2026年10月20日確認）。次は、公式が示す「公式のマーケットプレイスと自社のものだけを許可する」例から、許可と持ち込みの制限だけを抜いたものです。

{
  "strictKnownMarketplaces": [
    { "source": "github", "repo": "anthropics/claude-plugins-official" },
    { "source": "github", "repo": "your-org/*" },
    { "source": "skills-dir" }
  ],
  "disableSideloadFlags": true
}

実際の画面：/permissions で、配ったルールが効いているかを確かめる

チームで設定を配った後は、各自の環境でルールが効いているかを /permissions で確認してもらいます。どのルールがどの設定ファイルから読み込まれているかが一覧で出ます。

dev containerで、さらに分離する

特に機密度の高いリポジトリでは、公式はClaude Code全体をサンドボックスの実行環境やdev container（開発用コンテナ）の中で動かすことを勧めています。dev containerでは、Claudeが実行するコマンドは手元のパソコンではなくコンテナの中で動き、プロジェクトのファイルの変更は手元のリポジトリに反映されます。公式の参考用コンテナには、外への通信を許可した宛先だけに絞るファイアウォールのスクリプト（init-firewall.sh）が入っています。

ただし公式は、コンテナの中で確認を省く --dangerously-skip-permissions を使うと、悪意のあるプロジェクトがコンテナ内のもの（~/.claude にあるClaude Codeの認証情報を含む）を持ち出すのは防げない、と注意しています。信頼できるリポジトリだけで使い、~/.ssh やクラウドの認証情報をコンテナに入れない（リポジトリ単位や短い期限のトークンを使う）ことが勧められています。

Claude Code自体の更新と、サプライチェーンへの備え

Claude Codeは更新の頻度が高いツールです。更新のしかたは入れ方によって違います（公式 Advanced setup）。手元の版は claude --version、更新の状態は claude doctor で確認できます。

古い版に戻らないよう下限を決めたいときは、設定に minimumVersion を書きます。管理設定に書くと組織の下限になり、さらに requiredMinimumVersion と requiredMaximumVersion を管理設定に書くと、範囲の外では起動しなくなります。autoUpdatesChannel を "stable" にすると、おおむね1週間前の版を使います（既定は "latest"）。

{
  "autoUpdatesChannel": "stable",
  "minimumVersion": "2.1.100"
}

利用状況の監視と、設定変更の監査

• OpenTelemetry：CLAUDE_CODE_ENABLE_TELEMETRY=1 を設定すると、利用状況の計測を自社の収集基盤へ送れます。プロンプトの中身の記録は既定でオフで、OTEL_LOG_USER_PROMPTS=1 を設定したときだけ記録されます。
• ConfigChange フック：セッション中に設定ファイル・管理設定のファイル・スキルのファイルが変わったときに動き、変更の記録やブロックに使えます。
• PreToolUse フック：ツールが実行される前に動き、危険なコマンドを止めるなど独自の確認を足せます。使い方はClaude Codeのフックの解説で説明しています。

クラウド実行（Claude Code on the web）とRemote Control

ブラウザから使う Claude Code on the web で、Anthropicが用意する環境を使う場合、公式が挙げる守りの要点は3つです（組織が自社の環境で動かす場合、分離・通信・Gitの認証情報は自社の責任です）。

• 分離された仮想マシン：セッションごとに、Anthropicが管理する独立した仮想マシンで動き、通信は既定で制限されます
• 認証情報の保護：GitHubの認証情報は暗号化してAnthropicのサーバーに保存され、仮想マシンには入りません
• 監査ログ：クラウドのセッション内のすべての操作が記録されます

一方、Remote Control（Webの画面から手元のClaude Codeにつなぐ形）は仕組みが違い、コードの実行とファイルの操作は手元に留まり、クラウドの仮想マシンやサンドボックスは使われません。つないでいる間は会話の記録が端末間で同期するためAnthropicのサーバーに保存されます。Webでの使い方はClaude Code on the webの解説で説明しています。

企業導入前のチェックリスト

上の個人向けチェックリストとは別に、組織として決めておく項目です。

Claude Code自体に脆弱性を見つけたときの報告

公式が定める手順は、公開の場で開示せず、HackerOneのプログラムから詳しい再現手順を添えて報告し、公開前にAnthropicが対処する時間をとることです。社内でClaude Codeを使う開発者にも、この流れを伝えておきます。

Claude Codeのセキュリティの限界と導入判断の考え方

ここまでの設定を入れても、次の限界は残ります。導入を判断するときは、これを前提にします。

• denyルールは書かれた文字列で一致を調べ、サンドボックスはシェルコマンドだけを包みます：別の書き方やスクリプト経由の操作、組み込みのファイルツール・フック・手元のMCPサーバーは止められない場合があります。両方を組み合わせ、サンドボックスが実際に動いているかを確かめます。
• プロンプトインジェクションは完全には防げず、確認の責任は利用者にあります：公式も、どんな仕組みもすべての攻撃を防げるわけではないと明記しています。Claudeに渡す内容を必要な範囲に絞り、重要な変更は人のレビューを残します。
• 更新が速い：新しい機能が、新しい考慮点を生むことがあります。組織では更新のチャンネルや更新前の確認の流れを決めておきます。

公式に公表された事例：Claude Codeが悪用された攻撃キャンペーン

Anthropicは2025年11月13日、中国の国家が支援するとみられるグループがClaude Codeを悪用し、世界の約30の組織への侵入を試みた事例を公表しました（出典：Disrupting the first reported AI-orchestrated cyber espionage campaign）。攻撃者は作業を無害に見える小さな依頼に分け、防御側のセキュリティ会社の社員だと偽ってClaudeの安全策を回避し、作業の8〜9割をAIが担ったと推定されています。Anthropicは、アカウントの停止と被害を受けた組織への通知、検知の強化で対応しました。

これは利用者が設定を誤った事例ではなく、AIエージェントが攻撃に使われる側の事例です。この記事の設定で防げるのは、自分の環境でClaude Codeが意図しない操作をしないことまでですが、権限の最小化・認証情報を平文で置かない・更新を止めないといった基本は、被害を小さくする土台になります。

編集の前に自動でバックアップを取るフックの例

設定の中で実用的なのが、Claudeがファイルを書き換える前に、元のファイルを自動で控えておくPreToolUseフックです。権限ルールが「やってよいか」を決めるのに対し、このフックは「やった後に戻せるか」を担保します。次は、Edit・Writeの直前に動かす例です（登録の書式は公式のhooksガイドと同じで、スクリプトは自作の例です。jq が必要です）。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/backup-before-edit.sh"
          }
        ]
      }
    ]
  }
}

スクリプトは .claude/hooks/backup-before-edit.sh に保存し、chmod +x します。入力のJSONから編集対象のパスを取り出し、ファイルがあれば日付つきのフォルダへ時刻を付けて複製します。新規作成でファイルがまだ無いときは何もしません。

#!/bin/bash
INPUT=$(cat)
FILE_PATH=$(echo "$INPUT" | jq -r '.tool_input.file_path // empty')

if [ -n "$FILE_PATH" ] && [ -f "$FILE_PATH" ]; then
  DEST="$HOME/.claude/backups/$(date +%Y-%m-%d)"
  mkdir -p "$DEST"
  cp "$FILE_PATH" "$DEST/$(basename "$FILE_PATH").backup-$(date +%H%M%S)"
fi

exit 0

スクリプト単体の動き（保存先に複製される、存在しないパスでは何もしない）は手元で確かめましたが、Claude Codeに組み込んだ状態での実行は、この記事では検証していません。バックアップは同じ端末の中に残るだけなので、重要なリポジトリはGitでも管理します。

なお、CLAUDE.mdの指示はClaudeの動きを方向づけるもので、Claude Codeが許可する範囲を変えるものではありません（上の「守りは3つの層で考える」のとおり）。守りたいことは、権限ルールやフックといった「仕組み」に落とし込みます。

よくある質問

Q. Claude Codeの初期設定では、どの操作に確認が出ますか？
A. v2.1.283以降、ターミナルとVS Codeの拡張機能では、autoモード（別の分類器モデルが操作を確認し、危険と判断したものを止める）が組み込みの開始モードです。すべての操作を自分で確認したい場合は、claude –permission-mode manual で起動するか、~/.claude/settings.json の permissions.defaultMode を “default”（Manualモード）にします。Manualモードは読み取りだけで始まり、編集やコマンドの実行の前に確認が出ます。

Q. .claudeignoreで読ませたくないファイルを除外できますか？
A. 公式ドキュメントによると、.claudeignore ファイルを置いても効果はありません。読ませたくないファイルは、settings.json の permissions.deny に Read(./.env) のようなルールで指定します。Readのdenyルールは同じパスへの編集・書き込みも止めますが、別のプログラムを経由した読み書きには効かないため、必要に応じてサンドボックスを併用します。

Q. Readのdenyルールに.envを入れれば、.envは絶対に読まれませんか？
A. いいえ。2026年10月16日にClaude Code v2.1.301で試したところ、Readツールと cat .env は拒否されましたが、.env を開くPythonスクリプトの実行はdenyでは止まらず、実行の確認画面で「Yes」を選ぶと中身が表示されました。サンドボックスが動く状態にすると、同じスクリプトは PermissionError で読めませんでした。denyルールとサンドボックスを組み合わせ、Linuxでは socat などが入っていてサンドボックスが実際に動いているかを /sandbox で確かめます。

Q. サンドボックスを有効にすれば、~/.ssh などの認証情報も守られますか？
A. いいえ。公式によると、サンドボックスの中のコマンドは、既定でパソコンのほぼ全体を読み取れ、~/.ssh や ~/.aws/credentials も含まれます。組み込みの拒否リストは無いため、sandbox.credentials に守りたいファイルと環境変数を書いて拒否します。

Q. Team・Enterpriseプランなど商用利用時、コードはモデルの学習に使われますか？
A. 公式のデータ利用の文書によると、Team・Enterpriseプラン、API、他社のクラウド基盤などの商用利用では、顧客が自らデータの提供を選ばない限り、送ったコードやプロンプトは生成モデルの学習に使われません。保存期間は標準で30日です。

Q. 知らないフォルダでClaude Codeを起動したとき、「Yes, I trust this folder」は押してよいですか？
A. 自分で作ったプロジェクト、よく知られたオープンソース、チームのコードなど、中身を知っているフォルダだけ「Yes」を選びます。プロジェクトの設定ファイルにある許可ルールは、信頼するまで使われません。非対話の -p で起動した場合はこの確認自体が出ず、プロジェクトのフックや .mcp.json のサーバーが使われる点に注意が必要です。

Q. Claude Code Security（Claude Security）と /security-review は何が違いますか？
A. /security-review は、現在のブランチの変更を1回だけセキュリティの観点で確認するコマンドです。Claude Security は、リポジトリ全体や差分を複数のエージェントで調べ、検証済みの指摘と修正案を出す機能で、Claude.ai のアプリ（Enterprise向けパブリックベータ）と、Claude Code用のプラグイン（ベータ）があります。作業中に自動で確認させる security-guidance プラグインもあります。

Q. Claude Code自体に脆弱性が見つかったことはありますか？
A. あります。Anthropicは GitHub の anthropics/claude-code のセキュリティアドバイザリで脆弱性を公開しており、2026年10月21日時点で35件（Claude Desktopの分を含む）が載っています。信頼ダイアログを飛ばされるもの、サンドボックスの外へ書き込めるもの、denyルールをシンボリックリンクで回避できるものなどがあり、いずれも修正済みです。自動更新を止めず、手動で更新している場合は最新版にすることが勧められています。

---

まとめ：今日やること・導入前に決めること

個人で使う場合は、まず「起動時の権限モードの確認」「.envなど秘密情報のファイルをReadのdenyで読ませない」「知らないリポジトリやMCPサーバーを安易に信頼しない」の3つから始めるとよいです。そのうえで、確認画面で保存した許可ルールを /permissions で見直し、サンドボックスを有効にして認証情報のファイルを拒否します。実際に試したとおり、denyだけではスクリプト経由の読み取りは止まらず、サンドボックスは必要なものが無いと動かないまま使えてしまうので、/sandbox で動いていることまで確かめてください。

企業として管理する場合は、技術の設定・契約・組織の運用の3つで対策を考えます。技術の設定では、管理設定で権限の基準と bypassPermissions の禁止を強制し、サンドボックスと必要に応じてdev containerで分離します。契約では、商用規約での学習への非利用と保存期間を、法務・情報セキュリティの部門が確認します。運用では、利用ポリシー、計測（OpenTelemetry）と設定変更の監査、更新のチャンネル、脆弱性の報告の流れを決めておきます。書かれたコードの脆弱性は、権限の設定とは別に、/security-review や security-guidance プラグイン、Claude Security で段階的に確認します。Claude Codeの全体像はClaude Codeとはをあわせて参照してください。

参考文献

公式ドキュメント・製品ページ・GitHubのアドバイザリは、2026年10月21日に再確認しました（個別に日付を付けた項目を除く）。

• Anthropic「Security」Claude Code公式ドキュメント
  https://code.claude.com/docs/en/security
• Anthropic「Configure permissions」Claude Code公式ドキュメント
  https://code.claude.com/docs/en/permissions
• Anthropic「Permission modes」Claude Code公式ドキュメント
  https://code.claude.com/docs/en/permission-modes
• Anthropic「Sandboxing」Claude Code公式ドキュメント
  https://code.claude.com/docs/en/sandboxing
• Anthropic「Data usage」Claude Code公式ドキュメント
  https://code.claude.com/docs/en/data-usage
• Anthropic「Deploy managed settings」Claude Code公式ドキュメント
  https://code.claude.com/docs/en/managed-settings
• Anthropic「Development containers」Claude Code公式ドキュメント
  https://code.claude.com/docs/en/devcontainer
• Anthropic「Catch security issues as Claude writes code」Claude Code公式ドキュメント
  https://code.claude.com/docs/en/security-guidance
• Anthropic「Advanced setup」Claude Code公式ドキュメント
  https://code.claude.com/docs/en/setup
• Anthropic「Monitoring」Claude Code公式ドキュメント
  https://code.claude.com/docs/en/monitoring-usage
• Anthropic「Making frontier cybersecurity capabilities available to defenders」（2026年2月20日）
  https://www.anthropic.com/news/claude-code-security
• Anthropic「Claude Security」製品ページ
  https://claude.com/product/claude-security
• Anthropic「Security Advisories」anthropics/claude-code（GitHub）
  https://github.com/anthropics/claude-code/security/advisories
• Anthropic「Trust Center」
  https://trust.anthropic.com
• Anthropic「Automate actions with hooks」Claude Code公式ドキュメント
  https://code.claude.com/docs/en/hooks-guide

関連記事

• Claude Codeとは
• Claude Codeの権限設定
• Claude Codeのサンドボックス
• Claude Codeのベストプラクティス
• Claude CodeのメモリとCLAUDE.md活用
• Claude Codeが動かない・起動しない時の対処法
• Claude CodeとGitHub/Gitの連携