Claude Code セキュリティガイド：権限、MCP、サンドボックス

従来のチャットボットは API の背後に構成されているため、最悪でもハルシネーションが起きる程度です。ですが、AI コーディングエージェントはリポジトリ内やターミナル内、そして（多くの場合）クラウドの認証情報の中に配置されます。つまり、かつてチャットボットと呼んでいたものよりも、特権的な開発環境にずっと近い場所に置かれるということです。

問題は、作業スピードを落とさずに Claude Code をどう安全に使うかです。権限、MCP コントロール、サンドボックスを適切に調整すれば、それが実現できます。

この記事では、Claude Code のセキュリティモデルが実際にどう機能し、どこに注意を払うべきか、そして意図以上のアクセスを与えずに有用性を保つための実践方法を順に説明します。

Claude と Claude Code が初めての場合は、無料の Claude Code 101 コースに登録して、午後のひとときで基礎を掴んでください。

Claude Code のセキュリティモデルを理解する

ルールを調整する前に、Claude Code が実際に何を制御しているのかというメンタルモデルが必要です。

要素は5つあります。何を許可するかを決める権限システム、個々の機能範囲を絞るツールアクセス制御、外部連携向けの MCP 権限、OS レベルでの分離を行うサンドボックス化、そして事後レビューのための監査性です。それぞれが異なる問題を解決しますが、積み重なって機能します。

権限システム

権限システムは静的なレイヤーです。

settings.json で、allow、ask、deny の3つのリストを使って Claude にできることを宣言します。ルールは deny、ask、allow の順で評価され、最初に一致したものが適用されます。deny ルールは、より広い allow ルールに一致する場合でも呼び出しをブロックします。

どのルールにも一致しない場合、Claude はセッションの defaultMode にフォールバックします（モードについては次のセクションで説明します）。

ツールアクセス制御

権限はエージェント全体ではなくツールに紐づきます。

Claude Code には独自の組み込みツールがあります。例えばシェルコマンド用の Bash、ファイルシステム操作の Read と Edit と Write、HTTPS リクエストの WebFetch、検索用の WebSearch などです。各ルールはツール名と、（任意で）括弧内の指定子を持ちます。例えば Bash(git commit:*) や Read(./.env) のように書きます。

これによって最小権限の原則が機能します。例えば Bash(npm run:*) をテスト用に許可しても、Claude にフルのシェルアクセスを与えずに済みます。

MCP 権限

MCP サーバーは、Claude Code を設計外のツールでも拡張します。

各サーバーは独自のツールセットを提供します（GitHub サーバーはプルリクエスト用ツール、データベースサーバーはクエリ用ツールなど）。権限システムはそれらにも適用されますが、構文が異なります。括弧付きの指定子ではなく、mcp__servername__toolname という形式でルールを記述します。

覚えておくべき点は、MCP によって検討事項がほぼ倍増するということです。シェルに対して何ができるかだけでなく、接続したあらゆる外部システムに対して何ができるかも決めることになるからです。

サンドボックス化

サンドボックス化は Bash ツールの配下で行われる OS レベルの安全策です。

権限ルールは Claude に「すべきこと」を指示します。サンドボックスは OS レベルでファイルシステムアクセスと外向きネットワーク呼び出しを制限することで「できること」を強制します。macOS では Seatbelt により標準で動作します。Linux と WSL2 では、あらかじめ bubblewrap と socat をインストールする必要があります。

この2層は似ていますがカバーするシナリオが異なります。権限は Claude が試みること自体を止め、サンドボックスはプロンプトインジェクションにより Claude が試みてしまった場合でも、その試行が成功しないようにします。

監査性

最後の要素は、何が起きたかを確認できることです。

/permissions コマンドは、すべての有効なルールとその出どころの設定ファイルを一覧表示するため、「なぜ Claude はそれを実行したのか？」に答えられます。フック（PreToolUse、PostToolUse など）を使えば、あらゆるツール呼び出しを自分のシステムにログできます。チーム向けには、OpenTelemetry エクスポーターで使用状況やツール呼び出しのデータを既存のオブザーバビリティ基盤へ送信できます。

Claude Code の権限とアクセス制御

安全性の大半は権限設定に由来するため、この領域の調整に最も時間を使うことになります。

ファイルアクセス

Claude はデフォルトで、起動したディレクトリ内のファイルを読み取り・編集できます。

読み取りは Read ツール、編集は Edit と Write が制御します。いずれも括弧内にパスパターンを受け付け、gitignore 風の構文を使います。例えば Read(**/.env) は任意の深さのすべての .env ファイルに一致し、Edit(src/**) は src/ 配下のすべてに一致します。

Read の deny は Claude Code のファイル系ツール（Read、Grep、Glob、LS）に適用されますが、最善努力に過ぎません。Bash 経由で実行した Python や Node のスクリプトは、そのファイルを開けてしまいます。これは、読み取りが Claude の Read ツールではなくシェル経由で行われるためです。秘匿情報が重要な場合は、Read の deny に加えて、該当パスに対する cat、head、tail を Bash で deny してください。

作業ディレクトリ外へのアクセスを拡張するには、settings.json の additionalDirectories を使用します。これにより、リポジトリ外の共有ライブラリやホームディレクトリ内の設定ファイルにアクセス権を与えつつ、作業ディレクトリの境界を完全に外すことなく対応できます。

コマンド実行

Bash ツールは最も慎重に範囲を絞る必要があります。

素の Bash ルールはあらゆるコマンドを許可します。Bash(npm run:*) のように範囲を絞ったルールは、一致する呼び出しのみを許可します。ここではコロンとアスタリスクのパターンを使う必要があり、Claude Code はシェル演算子も理解するため、Bash(safe-cmd:*) のルールは safe-cmd && rm -rf / には一致しません。

一部のコマンドは既定で読み取り専用と見なされ、どのモードでもプロンプトなしで実行されます。対象は ls、cat、echo、pwd、head、tail、grep、find、wc、which、diff、stat、du、cd、および読み取り専用の git です。手動でこのリストを縮小することはできませんが、いずれに対しても ask や deny ルールを追加して既定を上書きできます。

事前承認されていないものは、既定モードで Claude がプロンプトを表示します。プロンプトには正確なコマンドが表示され、1回だけ承認、パターンに一致する今後の呼び出しをすべて承認、または拒否を選べます。

権限モード

権限ルールは静的ですが、権限モードは未一致の呼び出しの扱いを変えます。

モードは5つあります。

• default：各ツールの初回使用時にプロンプトを表示します。

• acceptEdits：作業ディレクトリ内のファイル編集を自動承認し、シェルコマンドは引き続き制御します。編集は信頼するがシェルは信頼しない場合に便利です。

• plan：Claude は読み取りと分析のみ可能で、ファイル編集やコマンド実行はできません。コードレビューや計画のセッションに適したモードです。

• dontAsk：明示的に allow リストにないものは自動拒否します。

• bypassPermissions：すべてのプロンプトをスキップします。コンテナや VM のような完全に分離された環境でのみ安全です。

セッション途中でも Shift+Tab で主要な3つのモードを切り替えられ、settings.json で既定を選択することもできます。

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "deny": ["Read(**/.env)", "Read(**/.env.*)"]
  }
}

チームの場合、マネージド設定によりユーザーが上書きできないレイヤーを提供できます。ファイル形式は同じ JSON で、システムパスに配置されます。

• /Library/Application Support/ClaudeCode/managed-settings.json（macOS）

• /etc/claude-code/managed-settings.json（Linux）

• C:\ProgramData\ClaudeCode\managed-settings.json（Windows）

マネージド設定の deny ルールは、そのマシン上のあらゆるプロジェクトに適用されます。これにより、組織全体で「.env を誰も読まない」「bypassPermissions を誰も使わない」といったルールを強制できます。

これらすべての背後にある原則は、サービスアカウントにも適用する「最小権限」です。

作業に必要な最小限の権限から始め、壁に当たったときにだけ広げてください。Anthropic 自身のガイダンスも同様です。Claude が行う変更をレビューし、/permissions でルールを監査し、プロジェクト固有の設定はバージョン管理にチェックインして、チーム全員が Claude が扱える対象に合意できるようにします。

Claude Code のサンドボックス化

Claude に自律的な実行を許すほど、サンドボックス化の重要性は高まります。

シェルコマンドは自分が読めるファイルはすべて読み取り、書き込み権限のあるものは何でも変更できるため、Bash ツールは最も広範な露出を持ちます。サンドボックスは、あらゆる Bash コマンドとその子プロセスに OS レベルの境界を課します。そのため、各呼び出しを手動で承認しなくても、境界内でより自由に実行できます。Anthropic は、より安全な自律実行を支えるために、この機能を組み込んでいます。

重要な詳細として、サンドボックスは Bash とその子プロセスのみに適用されます。Read、Edit、Write ツールは制限されず、引き続き権限システムを通過します。

ネイティブサンドボックス

ネイティブサンドボックスは Claude Code に組み込まれており、/sandbox で有効化します。

macOS では組み込みの Seatbelt フレームワークを使用するため、インストールは不要です。Linux と WSL2 では、ファイルシステム分離のために bubblewrap、ネットワークプロキシのために socat をインストールします。ネイティブの Windows は未対応のため、WSL2 ディストリビューション内で Claude Code を実行します。

ファイルシステムの境界は分かりやすいでしょう。読み取りは拒否パスを除きどこでも可能で、書き込みは作業ディレクトリと許可した追加パスの内部でのみ可能です。サンドボックス内から ~/.bashrc に書き込もうとすると、Claude が失敗を認識する前に「Operation not permitted」が返ります。

ネットワークの境界は少し異なります。外向きトラフィックはサンドボックス外で動くプロキシサーバーを経由し、リクエストごとに allowedDomains リストと照合されます。新しいドメインは代わりに権限プロンプトを表示するため、Claude が何にアクセスしようとしているかを正確に把握できます。

動作する構成例は次のとおりです。

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "filesystem": {
      "allowWrite": ["/workspace", "/tmp"],
      "denyRead": ["~/.aws", "~/.ssh"]
    },
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org"]
    }
  }
}

Anthropic の社内利用では、サンドボックス化により権限プロンプトが 84% 減少しています。

開発用コンテナ

開発用コンテナは、分離のレベルをさらに高める選択肢です。

Anthropic には、Ubuntu 環境を用意し、リポジトリをマウントし、エージェントに作業用シェルを提供する Claude Code 向けのリファレンス devcontainer があります。ネイティブサンドボックスに対する利点は再現性で、チーム全員が同じツール・同じセットアップの同一環境を得られます。

一方で、オーバーヘッドが増えるという欠点もあります。

コンテナビルド、ファイルのマウント、そして（場合によっては）フィードバックループの遅さが加わります。個人開発では、通常はネイティブサンドボックスで十分です。チームや CI 用途では、このセットアップは価値があります。

Docker ベースの分離

長時間の自律エージェントセッションには、Docker を使うとサンドボックスの境界をさらに強化できます。

一般的なセットアップは次のようになります。

• 最小限のベースイメージ：タスクに不要なパッケージマネージャーやネットワークツールを削除します。
• 非 root ユーザー：Claude は決して root で動作せず、システムファイルの変更やグローバルパッケージのインストールができません。
• 読み取り専用のルートファイルシステム：コンテナのルートを読み取り専用でマウントし、特定の出力ディレクトリのみ書き込み可能にします。
• 外向きプロキシ：外向きネットワークをプロキシ経由にし、パッケージレジストリ（npm、PyPI）は許可、それ以外は拒否します。これにより npm install は動作しますが、任意の curl は動きません。
• リソース制限：CPU、メモリ、I/O の上限を設定し、プロセスがホストを落とせないようにします。

Docker Sandboxes は各サンドボックスに専用のマイクロ VM とプライベートな Docker デーモンを与えます。ホスト側のデーモンは docker ps にサンドボックスを表示すらできません。境界はコンテナというより VM に近く、開発者が懸念するコンテナ脱出経路の大半を封じます。

エンタープライズのサンドボックス戦略

組織にとっては、サンドボックス技術を使うかどうかではなく、どう積み重ねるかがポイントです。

多くの組織は次のように進めます。

• 権限ルールは managed-settings.json に置き、個々の開発者が上書きできないようにします。

• ネイティブサンドボックスを権限レイヤーの下に配置します。

• その下に開発用コンテナや Docker を配置します。

• 最も高い信頼が必要なシナリオ（本番アクセス、シークレットの取り扱い）では、ホストのファイルシステムをマウントしない専用 VM を最終レイヤーとします。

Web 上の Claude Code は同じ考え方のマネージド版です。各セッションは Anthropic 管理の VM で実行され、git トークンのような機微な認証情報はサンドボックス外のプロキシに置かれ、インフラストラクチャで境界が強制されます。

Claude Code における MCP セキュリティ

MCP は Claude Code の中で最も成長が速い領域です。

接続する MCP サーバーごとに、Claude にできることはおおむね掛け算で増えますが、同時にプロンプトインジェクションや依存関係の侵害が到達しうる面も広がります。

例えば次のとおりです。

• GitHub MCP サーバーは、Claude にプルリクエストへのアクセスを与えます。
• データベース MCP サーバーは、スキーマとクエリを与えます。
• Slack サーバーは、チャンネルへのアクセスを与えます。

どれも問題ではありませんが、MCP には独自のガバナンスが必要になるという意味です。MCP ツール経由で取得したコンテンツ（Web ページや API レスポンス）には、Claude がユーザー入力として実行してしまう指示が注入されている可能性があります。さらに、各サーバーは認証情報と認証経路を追加し、それぞれ別に管理する必要が生じます。

ツール権限

MCP ツールは、組み込みツールとは異なる命名規則を使います。

ルール形式は mcp__servername__toolname で、括弧付きの指定子はありません。例えば mcp__github__create_pull_request はそのツールの呼び出しだけを許可し、mcp__github__delete_repo の deny は危険なツールをブロックします。Bash や Read と同じように、allow、ask、deny のリストが機能します。

優先順位のルールも同じで、deny、ask、allow の順です。mcp__github__delete_* のマネージド設定での deny は、そのマシン上のすべてのプロジェクトで有効です。

リソース権限

MCP サーバーは、ツールに加えてリソースを公開することがあります。

リソースとは、Claude が読み取れるようサーバーが提供するデータ（プロジェクト管理サーバー上のファイルやデータベースサーバー上の行など）です。リソースアクセスもツール呼び出しと同じ信頼チェックを通過し、初回の MCP サーバー接続では、いずれのツールやリソースにも到達する前に信頼検証が行われます。

既定の考え方は、リソースももう一つのツールとして扱うことです。認証情報を与えないものには、リソースアクセスも与えないでください。

承認済み MCP サーバー

Anthropic Directory には、Anthropic が掲載基準に照らしてレビューしたコネクターが一覧されています。

組織においては、社内の許可リストを使うパターンが有効です。次の2つの設定で制御できます。

• allowedMcpServers：開発者がプロジェクトに追加できるサーバーのグロブパターン（例えば company-* として、社内で保守するサーバーのみに限定）。

• deniedMcpServers：開発者が追加しようとしても追加できないサーバーのパターン。

すべてのセッションに必須で存在させたいサーバーは、マネージド設定に置く managed-mcp.json で配布するのが適切です。開発者はエントリを削除・変更できません。

共有リポジトリで避けるべき設定が enableAllProjectMcpServers です。これは .mcp.json に定義されたすべての MCP サーバーを自動承認します。個人作業では便利ですが、チェックインされるものには危険です。悪意のある PR が .mcp.json に新しいサーバーを追加し、プロンプトなしで実行されてしまう可能性があるからです。

最小権限のツールアクセス

Bash の権限と同じ原則を MCP に適用します。

出発点は各サーバーが持つ認証情報の種類です。データベース MCP サーバーは、書き込み権限のあるプライマリではなく、読み取り専用のリードレプリカに接続すべきです。API の MCP サーバーは、組織全体へのフルアクセスを持つパーソナルトークンではなく、必要最小限のエンドポイントにスコープされたトークンを使うべきです。その他も同様です。

サブエージェントも MCP アクセスの範囲を絞る方法です。.claude/agents/ のサブエージェント定義では、mcp:<server>:<tool> の構文でアクセス可能なツールを正確に宣言できます。例えば「deploy-agent」にはインフラサーバーを与え、「review-agent」には Read、Grep、Glob のみを与える、といった具合です。エージェントは付与されていないツールを呼び出せません。

MCP ガバナンス

Claude Code を大規模に運用するチームや組織では、MCP にも本番統合と同等のガバナンスが必要です。

つまり、承認済みサーバーのレジストリ（責任者の明示）、ツール呼び出しのエンドツーエンドの監査ログ（どの MCP ツールが、誰により、どのパラメータで呼ばれたか）、そして承認リストの定期的な見直しです。Claude Code の OpenTelemetry エクスポーターは、既存のオブザーバビリティ基盤にそのまま取り込める形式で監査データを提供します。

大規模組織では、集中管理の MCP ゲートウェイが最も整った形です。

開発者は個別のサーバーを登録する代わりにゲートウェイへ接続します。ゲートウェイは認証を処理し、ツールレベルのロールベースアクセスを強制し、単一の監査ログを出力します。認証情報のスプロールも解消でき、開発者全員があらゆる API キーのコピーを持つ代わりに、ゲートウェイ側の一組の認証情報で済みます。

シークレット管理と機微データ

Claude Code はユーザーが読めるものは何でも読めるため、シークレットにも到達可能です。

既定では、Claude Code はユーザーアカウントが読めるあらゆるファイルを読めます。これは、プロジェクト内の .env、~/.aws/ の AWS 認証情報、~/.ssh/ の SSH 秘密鍵、シェルの rc ファイル内の GitHub トークン、Claude が作成するサブプロセスの環境変数などを含みます。これは完全に正常で、設計どおりの挙動です。

ワークスペースからシークレットを排除する

まずは、Claude が読むディレクトリにシークレットを置かないようにします。

.env は最も一般的な例です。プロジェクトルートにあり、あらゆる開発ツールが読み込み、Claude の文脈に入れたくない値（データベース URL や API キー）がちょうど含まれています。

次のようなパターンが使えます。

• シークレットを作業ツリー外のディレクトリ、例えば ~/.config/myapp/secrets.env に移し、環境マネージャーや外部ファイルを指す direnv 設定を通じて読み込みます。

• コンテナ化された作業では、バインドマウントの外側に .secrets/ フォルダを置き、コンテナ内からそのファイルが見えないようにします。

• permissions.deny に Read(**/.env) と Read(**/.env.*) を追加し、さらに Bash(cat:*/.env) の deny を組み合わせて、Read ツールで読めないものをシェルスクリプトでも読めないようにします。

シークレットマネージャーを使う

デモを超えるプロジェクトでは、シークレットはシークレットマネージャーに置くのが正解です。

ベンダー（1Password、AWS Secrets Manager、HashiCorp Vault、Doppler、Infisical）に関わらずパターンは同じです。シークレットはマネージャーに置き、シェルやランタイムは必要に応じて取得し、必要なプロセスにのみ公開します。Claude は実際の値を見ることはありません。

Claude Code では、CLAUDE_CODE_SUBPROCESS_ENV_SCRUB を設定して、サブプロセスから Anthropic やクラウドプロバイダーの認証情報を除去するか、sandbox.credentials を使ってサンドボックス化されたコマンドで特定の変数を未設定にします。前者は、Claude が ANTHROPIC_API_KEY をビルドスクリプトに渡すのを防ぎ、後者は機微な環境変数がシェルコマンドに流入するより広いケースをカバーします。

リポジトリアクセスを制限する

3つ目の選択肢はリポジトリレベルでの制限です。

開発者に本番専用の設定へ書き込み権限が不要なら、その開発者の Claude Code セッションにも不要です。これは当然に聞こえますが、多くのチームでは開発者が日常的に使う以上に広範なアクセス権を持っており、Claude はそれをすべて継承します。

次の2つの手順を検討してください。

• 本番用設定を、より厳格なアクセス制御の別リポジトリに分離し、Claude が作業する開発環境には本番のシークレットをそもそも含めないようにします。

• Claude がやり取りするあらゆるサービスに対して、スコープされたトークンを使います。例えば、コードレビュー用の GitHub トークンに repo:delete は不要です。

チームのための Claude Code セキュリティ

個人開発者なら settings.json を自由に変更できます。しかしチームではそうはいきません。全体のセキュリティは、最も弱いマシンの最も弱い設定に依存するからです。チームや組織での導入では、管理者が配布し、個々のユーザーが上書きできない別レイヤーのコントロールが用意されています。

マネージド設定

マネージド設定が基盤となります。

ファイルは管理者権限がないと書き込みできないシステムパスにあります。

• /Library/Application Support/ClaudeCode/managed-settings.json（macOS）

• /etc/claude-code/managed-settings.json（Linux）

• C:\ProgramData\ClaudeCode\managed-settings.json（Windows）

このファイルの設定は、ユーザーレベルやプロジェクトレベルの設定よりも優先されます。ここに置いた deny ルールは、そのマシン上のすべてのプロジェクトに適用され、開発者が自分の settings.json を編集しても削除できません。多くの組織は、MDM（モバイルデバイス管理）や他の開発ツールの配布に使う設定チャネルを通じて、このファイルを配布します。

マネージド層で知っておくべき設定は次のとおりです。

• permissions.deny による機微パスや危険なコマンドのルール

• defaultMode を default または plan に設定（bypassPermissions は絶対に不可）

• allowManagedPermissionRulesOnly: true で権限セットを固定

• enableAllProjectMcpServers: false を設定して MCP を明示承認に限定

• ログ出力用の OpenTelemetry エクスポーター設定

共有の権限制御ポリシー

チームで Claude にできることを合意したら、その合意はバージョン管理しましょう。

プロジェクトレベルの設定は、リポジトリルートの .claude/settings.json にあります。ここにチェックインされた内容は、そのリポジトリで Claude を実行する全員に適用されます。プロジェクト固有の allow / deny を置くのに適した場所です。

このとき、マネージド設定とプロジェクト設定の役割分担を理解しておく必要があります。

• マネージド設定は組織ポリシーを含みます（bypassPermissions は誰も使わない、.env は誰も読まない など）。

• プロジェクト設定はワークフロー上の取り決めを含みます（このリポジトリのテストは npm test で実行、このリポジトリのデプロイスクリプトは対象外 など）。

チームのガバナンス

チーム展開では、ポリシーレイヤーに責任者が必要です。

Claude Code を大規模運用する多くのチームでは、セキュリティとプラットフォームエンジニアリングの少人数グループが、マネージド設定、MCP 許可リスト、フックスクリプト、OpenTelemetry パイプラインの責任を持ちます。このグループが例外申請をレビューし、新しいユースケースに合わせてポリシーを調整します。

次の内容は文書化しておくとよいでしょう。

• 対象とするリポジトリと対象外のリポジトリ、そしてリスクに応じたモード（規制データを扱うリポジトリはおそらく plan、マーケサイトのリポジトリは acceptEdits で可 など）。
• 誰が例外を承認できるか、その追跡方法。
• 定期レビュー（四半期ごとが一般的）で、権限ルール、MCP サーバー、インシデントデータを見直すこと。

監査ログ

Claude Code は、あらゆるツールの判断、MCP サーバー接続、権限モードの変更、API リクエストについて OpenTelemetry イベントを出力します。マネージド設定で OTLP エンドポイントを構成するまで、データは送信されません。

テレメトリ用の最小限のマネージド設定ブロックは次のとおりです。

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.internal:4317"
  }
}

既定では、プロンプト内容とツールパラメータはエクスポートから除外されます。収集されるイベントはメタデータであり、会話全文ではありません。プロンプト本文を含めるには OTEL_LOG_USER_PROMPTS=1 を、ツール引数を含めるには（監査では通常こちらを望みます）OTEL_LOG_TOOL_DETAILS=1 を設定します。どちらもプライバシーへの影響があるため、多くのチームは明確なポリシーとして扱い、保存前にテレメトリ基盤でフィルタリングや編集を行います。

利用状況のモニタリング

監査の基盤となるのと同じ OpenTelemetry ストリームが、利用状況のモニタリングにも使われます。

Claude Code は、トークン使用量、リクエストあたりのコスト、セッション数、ツール判断率といったメトリクスをエクスポートします。集計すれば、どのチームが最も価値を得ているか、どのワークフローで拒否が多いか、どのモデルがコストを押し上げているかが分かります。Datadog、Honeycomb、SigNoz、Elastic、Splunk などのバックエンドは標準の OTLP 形式を取り込みます。

decision=deny の permission_decision イベントが急増している場合、Claude がやり過ぎている可能性もあれば、チームの allow ルールが厳しすぎるだけの可能性もあります。

よくある Claude Code セキュリティのミス

多くの Claude Code インシデントでは、少数の誤設定が繰り返し見られます。ここではそれらと対処方法を紹介します。

権限が広すぎる

権限システムの効果を弱める最短経路は、許可範囲を広げすぎることです。

コマンドごとのプロンプトは負担になりがちで、簡単な解決策として広い Bash(*) の allow や defaultMode: bypassPermissions を設定してしまうことがあります。どちらも権限システムの効果をほとんど台無しにします。

allow ルールは実際に使う特定のツールやコマンドへ絞り（例：Bash(npm test:*)、Bash(git status)）、それ以外はプロンプトに任せてください。最初はプロンプトが増えますが、数回のセッションで使用コマンドを許可リスト化すれば、プロンプトはほぼ止まります。

無制限の MCP アクセス

2つ目のミスは、使用する認証情報や到達範囲を確認せずに MCP サーバーを接続することです。

これはたいてい、enableAllProjectMcpServers を有効にし、公開 MCP ディレクトリからいくつかサーバーを接続して、その後レビューされないまま放置されることで起きます。弱い認証情報を持つサーバーから機微情報が漏れる頃には、設定のかなり奥で承認された接続になっており、誰も覚えていません。

解決策は権限と同じです。allowedMcpServers による明示的な許可リスト、全員に必要なサーバーのための社内 managed-mcp.json、そしてリストの定期レビューを行いましょう。

サンドボックスなし

サンドボックスが無効だと、Claude とファイルシステムの間にあるのは権限システムだけです。

各コマンドを承認する短い対話セッションなら問題ありません。しかし、自律実行、allow ルールを広げたセッション、外部ソースのコードに触れる作業には向きません。

/sandbox で有効にしてください。依存関係が未インストールであれば、プラットフォームごとに必要なものがメニューに表示されます。有効化後はプロンプトが減り、allow ルールで防ぎきれないケースを OS が捕捉します。

変更を盲目的に受け入れる

acceptEdits は便利であると同時に危険でもあります。

Claude が関数を書き換え、こちらが監視している状況では自動承認でも構いません。しかし、Claude が1時間かけて30ファイルを反復的に変更していると、差分を読まなくなり、エージェントを信頼し始めてしまいます。問題はそこから起きます。

次の2つの習慣を身につけてください。

• Claude を自律実行させる前に必ずコミットして、git reset 一発でロールバックできるようにします。

• セッションの最後に累積差分を見るのではなく、Claude 作成の各コミット前に差分をレビューします。

監査ログを無視する

テレメトリなしで Claude Code を運用するチームは、「どのセッションがそれを行ったのか？」に答えられません。イベントは各マシンにローカルで溜まり、そこで止まります。監査ログが必要になったその時が、設定していなかったことに気づく最悪のタイミングです。

最低限の有用な基準は、tool_decision、permission_decision、api_request イベントを、チームが運用するオブザーバビリティ基盤へエクスポートすることです。そこから、ユースケースに応じてダッシュボードやアラートを構築します。

結論

チャットボットの最悪ケースは、誤った回答です。しかしコーディングエージェントの最悪ケースは、あなたの認証情報で本番環境に対してシェルコマンドが実行されることです。

だからこそ、この3本柱が重要になります。

• 権限が、Claude に許可される行為を決める
• MCP コントロールが、到達可能な外部システムを決める
• サンドボックスが、最初の2つでは足りない場合にどうするかを決める

それぞれが、他ではカバーできない失敗モードを補完します。合わせることで、Claude が実際に働く境界が定義されます。

生成 AI の認定取得を目指している場合は、比較、主要コース、準備のコツ、FAQ をまとめた 2026 年版・生成 AI 認定のベストガイド も参照してください。