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

Claude Codeは、ファイルの書き換えやコマンド実行の前に許可を求める権限の仕組みを持ち、settings.jsonの許可・拒否ルールやサンドボックスで、AIが触れられる範囲を絞れます。企業で使う場合は、権限ルールの設計と定期的な権限の棚卸しを導入前に決めておくことが、安全に使う前提です。

Claude Codeは、Anthropicの生成AI「Claude（クロード）」が、手元のパソコンでファイルを読み書きし、コマンドを実行するツールです。できることが多いぶん、何を許すかは利用者が決める必要があります。この記事では、個人が今日できる設定のチェックリストから、権限ルールの書き方、サンドボックス、送ったデータの保存期間、企業・チームでの管理方法、書かれたコードの脆弱性を見つける公式機能「Claude Security」までを、Anthropic公式ドキュメント（2026年10月16日確認）にもとづいて解説します。

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モード」が組み込みの開始モードです。autoモードでは、利用者の代わりに別の分類器モデルが操作を確認し、危険と判断したものだけを止めます。すべての操作を自分で確認したい場合はManualモードで起動します（公式 Permission modes）。

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

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

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

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

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

パッケージのインストール時に動くスクリプトは、利用者と同じ権限で動きます。Claude Codeに依存パッケージの追加を任せる場合は、次の2つを組み合わせると、こうした事故の被害を小さくできます（どちらも公式の設定です）。

• Bash(npm install *) などをaskルールに入れ、パッケージの追加は毎回自分で確認する（autoモードでも、askルールは効きます。実際の画面は下の「実際に試して分かったこと」にあります。ルールは書かれた文字列で一致を調べるので、npm i のような別の書き方を使う場合はそれも足します）
• サンドボックスを有効にし、credentials で ~/.ssh・クラウドの認証情報・トークンの環境変数を拒否し、通信先を allowedDomains に絞る。サンドボックスの制限は、コマンドから起動されたプログラム（インストール時のスクリプトを含む）にも及びます

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

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

守りは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のセキュリティ設定チェックリスト（個人・チーム共通）

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

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（脆弱性スキャン）とは：書かれたコードの脆弱性を見つける公式機能

この後で解説する権限やサンドボックスが「AIに危険な操作をさせない」ための守りだとすれば、Anthropicはもう1つ、「書かれたコードに潜む脆弱性を見つける」ための機能も提供しています。2026年2月20日に「Claude Code Security」が、TeamプランとEnterpriseプランの利用者向けの限られた研究プレビューとして発表されました。既知のパターンに照らすのではなく、部品どうしの関係やデータの流れを読み取って脆弱性を探し、人が確認するための修正案（パッチ）を出します（出典：Anthropic公式発表）。

2026年10月時点の公式製品ページでは、名称が「Claude Security」になり、Claude Enterprise向けのパブリックベータと、Claude Code用のプラグイン（ベータ）が案内されています（出典：Claude Security 公式ページ、2026年10月16日確認）。

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

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

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

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

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

企業で導入を検討する場合は、「Claude Codeの権限・設定（次の節以降）」と「Claude Securityなどによる脆弱性の確認」を、別の対策として分けて考えると整理しやすくなります。前者はAIの操作の範囲を絞るもの、後者は人やAIが書いたコードの欠陥を見つけるものです。

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

権限モードは6種類

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

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

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

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

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

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

Manualモードには、ほかにも次のような守りがあります（公式 Security）。

• 内容を解析しきれないBashコマンドは、実行の前に確認が出ます。Bash(git *) のような一部分への許可ルールがあっても、この確認は省かれません。
• どのルールにも当てはまらないコマンドは、既定で確認が必要です（当てはまらなければ止める作り）。
• 起動したフォルダとそのサブフォルダの外をファイルツールで読み書きする前に、確認が出ます。ただしこれは確認画面による境界なので、承認したBashコマンドは、自分のユーザーの権限が及ぶ場所ならどこにでも書けます。OSのレベルで止めたい場合はサンドボックスを使います。

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

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

ルールは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 *)"
    ]
  }
}

公式によると、denyルールはコマンドの文字列に書かれたとおりに一致を調べます。そのため、書き方を変えた呼び出しまでは止められない場合があります。通信そのものを止めたいときは、コマンドの文字列に頼らないサンドボックスの通信制限を併用します。権限設定の全体はClaude Codeの権限設定の解説で詳しく説明しています。

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

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

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

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

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

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

公式は「組み込みの認証情報の拒否リストは無く、指定したファイルと変数だけが制限される」と明記しています。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は標準の仕組み（Seatbelt）で動き、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タブで不足が無いかを確かめ、動かないときに止めたい場合は sandbox.failIfUnavailable を true にしておくと確実です。また、作業フォルダの外にあるファイルは、credentials に書くまで読めました。守りたい認証情報のファイルは、1つずつ書き出しておく必要があります。

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

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

検証から決めた設定の組み合わせ

1. .env などは、Readのdenyルールで読ませないようにする（組み込みのツールと cat などを止める）
2. サンドボックスを有効にし、/sandbox で動いていることを確かめ、failIfUnavailable を true にする（スクリプト経由の読み取りを止める）
3. 作業フォルダの外にある認証情報のファイルは、credentials に1つずつ書く
4. 確認画面で python3 * や node * のような広い許可を「今後確認しない」で保存しない。保存したものは /permissions で見直す
5. パッケージの追加など、止めて確かめたい操作はaskルールにする（autoモードでも確認が出る）

知らないリポジトリ・プロンプトインジェクション・MCPへの備え

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

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

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

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

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

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

プロンプトインジェクションへの公式の備え

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

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

MCPサーバー：監査の責任は利用する側にある

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

Windowsでの注意：WebDAV

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

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

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

送る情報を減らしたい場合の設定も、公式に載っています。使用状況の計測は 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、2026年10月16日確認）。配り方は、端末の管理方法に合わせて選びます。

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

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

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

実際の画面：/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、2026年10月16日確認）。

• autoUpdatesChannel を "stable" にすると、おおむね1週間前の版を使い、大きな不具合のあった版を飛ばします。既定の "latest" は、出た版をすぐに受け取ります。組織では管理設定でチャンネルを揃えられます。
• Homebrewでは、claude-code が stable、claude-code@latest が latest を追います。apt・dnf・apkのリポジトリは署名つきで、同じく2つのチャンネルがあります。
• 各リリースには、全プラットフォームのバイナリのSHA256を記した manifest.json が公開され、AnthropicのGPGの鍵で署名されています。配布前に署名を確かめられます。
• 自分たちの配布経路で版を固定したい場合、DISABLE_UPDATES で手動の更新も含めて止められます。

プロジェクトが使う依存パッケージの確認は、Claude Codeの機能ではなく、CIの既存のスキャナーで行う、というのが公式の整理です（上の5段階の表の最後の行）。

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

• 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が用意する環境を使う場合、公式は次の7つの守りを挙げています（組織が自社の環境で動かす場合、分離・通信・Gitの認証情報は自社の責任です）。

• 分離された仮想マシン：セッションごとに、Anthropicが管理する独立した仮想マシンで動きます
• 通信の制限：既定で制限され、無効にしたり、特定のドメインだけ許可したりできます
• 認証情報の保護：GitHubの認証情報は暗号化してAnthropicのサーバーに保存され、仮想マシンには入りません。仮想マシンが持つのは、そのセッションだけに使える短い期限の認証情報です
• pushの制限：GitHubへの通信を仲介するプロキシが、ブランチの削除と、タグなどブランチ以外のpushを拒否します。どのブランチを更新できるかは、GitHub側のブランチ保護ルールで決まります
• 監査ログ：クラウドのセッション内のすべての操作が記録されます
• 自動の片づけ：使われていないセッションの仮想マシンは回収されます
• 削除：セッションはいつでも削除できます

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

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

導入審査で確認しておきたい4つの観点（IPAの資料も参考に）

IPAは「AIセキュリティ短信」で、生成AIを業務で使うときの留意点を継続して公表しています。導入前の社内審査では、その資料も参考にしながら、次の4点を確認しておくと整理しやすくなります。(1)データの送信先と利用規約の確認、(2)入力するデータの機密区分、(3)出力物の品質の検証、(4)利用ポリシーの策定と教育です。なお、この4点は実務上の整理として当サイトが挙げたもので、IPAの資料の項目をそのまま写したものではありません。

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

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

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

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

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

一次情報：自社の運用ルール（CLAUDE.md）にみるセキュリティの原則

クリスタルメソッド株式会社では、代表・河合継がClaude Codeを3.5世代から1年以上、自社のSEO運用ツールや記事生成基盤の開発という実務の中で使い続けています。その過程で、社内では「CLAUDE.md」と呼ぶ運用ルールに、セキュリティに関わる原則を段階的に追加してきました。

• ファイルの生成・更新やプログラムの実行の前には、作業計画を報告し、承認を得てから実行する
• 本番のデータベースや外部のAPIに触れる操作には、接続先の確認・試し実行（dry-run）・物理的なバックアップを義務づける
• テスト用のダミーのキーやデータを、コメントであってもソースコードに残さない
• Edit・Writeツールでファイルを変える直前に、自動でバックアップを取る仕組み（PreToolUse フック）を2025年11月に入れ、変更をいつでも戻せるようにしている

ただし、CLAUDE.mdの指示はClaudeの動きを方向づけるもので、Claude Codeが許可する範囲を変えるものではありません（上の「守りは3つの層で考える」のとおり）。そのため、守りたいことは権限ルールやフックといった「仕組み」に落とし込んでいます。個別の事故の内容は開示できませんが、共通して得た教訓は「破壊的な操作ほど、事前の確認と元に戻す手段を仕組みとして強制する」という一点です。

よくある質問

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

Q. 確認画面で「Yes, and don’t ask again」を選ぶと、どうなりますか？
A. Bashコマンドとウェブ取得のドメインについては、許可のルールがリポジトリの直下の .claude/settings.local.json に保存され、以後そのリポジトリのすべてのセッションで確認なしに通ります。ファイル編集の許可は保存されず、セッションの終わりまでです。保存されたルールは /permissions で確認・削除できます。

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に送ったコードやプロンプトは、どれくらいの期間保存されますか？
A. 公式のデータ利用の文書（2026年10月16日確認）によると、Free・Pro・Maxでモデル改善への利用を許可している場合は5年、許可していない場合は30日です。Team・Enterprise・APIの標準は30日で、ゼロデータリテンションは条件を満たした Claude for Enterprise の組織で個別に有効化されます。/feedback で送った会話は5年保存され、手元の端末には会話の記録が既定で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月16日時点で35件（Claude Desktopの分を含む）が載っています。信頼ダイアログを飛ばされるもの、サンドボックスの外へ書き込めるもの、denyルールをシンボリックリンクで回避できるものなどがあり、いずれも修正済みです。自動更新を止めず、手動で更新している場合は最新版にすることが勧められています。

Q. MCPサーバーのセキュリティは誰が担保していますか？
A. Anthropicはディレクトリに載せるコネクタを掲載基準に照らして確認しますが、個々のMCPサーバーのセキュリティ監査や管理は行いません。自作か信頼できる提供元のものだけを使い、組織では管理設定で使えるサーバーを制限します。

Q. Claude Code自体に脆弱性を見つけた場合、どう報告すればよいですか？
A. 公式が定める手順は、(1)公開の場で開示しない、(2)HackerOneのプログラムから報告する、(3)詳しい再現手順を添える、(4)公開する前にAnthropicが対処する時間をとる、の4つです。

Q. Windows環境でClaude Codeを使う際に注意すべき点はありますか？
A. Windowsのネイティブ環境ではサンドボックスが使えず、コマンドはサンドボックスなしで動きます。使う場合はWSL2の中でClaude Codeを動かします。また公式は、WebDAVの有効化や、WebDAVのサブフォルダを含みうるパスへのアクセスを許すことを勧めていません。権限の仕組みを迂回する経路になりうるためです。

---

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

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

企業として管理する場合は、技術の設定・契約・組織の運用の3つで対策を考えます。技術の設定では、管理設定で権限の基準と bypassPermissions の禁止を強制し、サンドボックスと必要に応じてdev containerで分離します。契約では、商用規約での学習への非利用と保存期間を、法務・情報セキュリティの部門が確認します。運用では、利用ポリシー、計測（OpenTelemetry）と設定変更の監査、更新のチャンネル、脆弱性の報告の流れを決めておきます。

書かれたコードの脆弱性は、権限の設定とは別に、/security-review や security-guidance プラグイン、Claude Security で段階的に確認します。まず開発環境だけに限って始め、設定と教育を整えてから範囲を広げると、無理なく進められます。Claude Codeの全体像はClaude Codeとはをあわせて参照してください。

参考文献

• 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
• IPA「AIセキュリティ短信」一覧ページ、独立行政法人情報処理推進機構
  https://www.ipa.go.jp/digital/ai/security/ai-security-bulletin.html

関連記事

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