Claude Codeセキュリティ・権限ガイド — 個人 / チーム / 企業の3レイヤー別に実装推奨値を提示

要点

Claude Codeのセキュリティは、権限システム / サンドボックス / データ扱い の3層から構成されています。どれか1つだけを固めても守れません。権限ルールは「どのツールが使えるか」を、サンドボックスは「BashがOSレベルで触れる範囲」を、データ扱いは「プロンプトと出力がどこに残るか」をそれぞれ制御しており、3つを噛み合わせて初めてagenticな自律実行が現実的な安全領域に入る構造になっています。以下では個人開発者・少人数チーム・企業(Team / Enterprise)の3レイヤー別に settings.json の実装推奨値を扱います。

セキュリティモデルの全体像

Claude Codeのセキュリティは、階層の異なる3つの仕組みを組み合わせて成り立っています。公式ドキュメントの表現に沿うと、それぞれの担当範囲は次のようになります。

権限システムはツール呼び出しの前に評価され、deny -> ask -> allow の順で最初にマッチしたルールが勝つ仕様です。サンドボックスはBashとその子プロセスにのみ適用されるOSレベル境界で、プロンプトインジェクションでClaudeの判断がハイジャックされても、Bashが実際に触れられる範囲を物理的に縛る最終防衛線になります。データ扱いは契約と設定の両面で決まり、Free/Pro/MaxのコンシューマーとTeam/Enterprise/APIの商用で動作が変わる点に注意が必要です。

Claude Codeは初期状態では「読み取りは広く、書き込みはプロジェクト配下に限定」という原則で動きます。Bashコマンドは都度承認、curl や wget のような外部取得系コマンドはデフォルトブロック、初回実行のコードベースと新規MCPサーバーには信頼検証が入ります。ただし -p フラグで非対話的に実行する場合、この信頼検証は無効化される点は忘れずに押さえておきたいところです。

Sandboxingの仕組みと挙動

サンドボックスは /sandbox コマンドで有効化し、settings.json の sandbox ブロックで挙動をカスタマイズします。OSレベル実装はmacOSがSeatbelt、Linux / WSL2がbubblewrap で、WSL1はbubblewrapが動かないためサポート外です。ネイティブWindowsは計画中とされています。

デフォルトのファイルシステム挙動は以下のとおりです。

• 書き込み: 現在の作業ディレクトリとそのサブディレクトリのみ
• 読み取り: 一部の拒否ディレクトリを除きコンピュータ全体

これを超えて kubectl や terraform に書き込みを許すには、sandbox.filesystem.allowWrite でパスを追加します。複数スコープで定義した場合、配列は置き換えではなくマージされるので、管理設定で /opt/company-tools、ユーザー設定で ~/.kube を足すといった積み上げが可能です。

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["~/.kube", "/tmp/build"],
      "denyRead": ["~/"],
      "allowRead": ["."]
    }
  }
}

ネットワーク側はサンドボックス外のプロキシで制御され、allowedDomains にマッチしないドメインは許可プロンプト、もしくは allowManagedDomainsOnly が有効な場合は自動ブロックになります。deniedDomains は allowedDomains のワイルドカードが広くても明示拒否を効かせられる貴重な逃げ道で、ドメインフロンティングや github.com のような広域許可のリスクを抑えるのに使えます。

サンドボックスには2つのモードがあります。

• 自動許可モード: サンドボックス内で成立するBashは承認なしで実行、境界を超えるものは通常の権限フローへフォールバック
• 通常の許可モード: サンドボックス内でも既存の権限フローを通す

なお docker や watchman はサンドボックス内では動きません。excludedCommands でサンドボックス外に逃がすか、jest --no-watchman のように回避設定を当てます。dangerouslyDisableSandbox という意図的なエスケープハッチもあり、厳格運用では "allowUnsandboxedCommands": false でこれを封じる選択肢があります。ネイティブバイナリ化とサンドボックス周りの強化はv2.1.113で特に大きく入ったので、併せて確認しておくと背景が掴みやすいです。

権限モードの選び方

権限モードは settings.json の defaultMode または /permissions で切り替えます。公式が提供しているモードは6種類あり、それぞれ「何を自動で通して、何を必ず聞くか」のトレードオフが異なります。

bypassPermissions は .git / .claude / .vscode / .idea / .husky への書き込みだけは必ず確認するなど、最低限の保険を残す形で設計されています。ただし本番マシンで使うべきではなく、公式もコンテナやVMの隔離環境限定を明示しています。組織として使わせたくない場合は、管理設定で permissions.disableBypassPermissionsMode を "disable" に固定できます。

権限ルール本体はシンプルで、Tool または Tool(specifier) の形で書きます。Bashはワイルドカードを前後に置け、Bash(npm run *) と Bash(* --help *) はそれぞれ異なる位置にワイルドカードがあります。注意したいのは Bash(curl http://github.com/ *) のような引数を絞るパターンは脆弱という公式の注意で、-X オプションの差し込みやプロトコル違い、変数経由のURLなどで簡単に回避されてしまいます。curl / wget系はブロックリストで落とし、ドメイン制御は WebFetch(domain:github.com) とPreToolUseフックで補強するのが現実解です。

Read / Editルールはgitignore互換のパターンで、//path が絶対、/path がプロジェクトルート相対、~/path がホーム相対、./path がCWD相対という取り扱いになります。Read(/Users/alice/file) はプロジェクトルート相対として解釈されてしまうので、絶対パスが欲しいときは //Users/alice/file と書きます。ここは罠が多いところで、管理設定を書く側が最初にハマりやすいポイントです。

データの扱い(入力 / 出力 / 学習)

プラン別のデータ扱いを整理すると、以下のように分かれます。

Claude Codeはローカル実行で、プロンプトと出力はTLSでAnthropic APIへ送られます。Bedrock / Vertex / Foundry経由ではテレメトリ・エラーレポート・/bug 送信はデフォルトオフ、Claude API直結ではデフォルトオンで、それぞれ DISABLE_TELEMETRY / DISABLE_ERROR_REPORTING / DISABLE_BUG_COMMAND で個別に落とせます。すべてまとめて黙らせるなら CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC で非必須トラフィック全体をオプトアウトできます。

セッション品質調査の扱いは独特で、1〜3またはdismissの数値評価のみが記録され、会話トランスクリプトは送られません。この調査への回答は学習データには使われないと明示されています。CLAUDE_CODE_DISABLE_FEEDBACK_SURVEY=1 または feedbackSurveyRate: 0 で完全に無効化できます。

Claude Code on the webを使うときはデータフローが変わります。リポジトリはAnthropic管理VMにクローンされ、GitHub認証情報はサンドボックス内に入らず、pushはワーキングブランチに制限され、すべての操作は監査ログに残り、セッション終了後に環境は自動破棄されます。一方Remote ControlはWeb UIからローカルプロセスに繋ぐ形なので、実行とファイルアクセスはローカルに留まり、クラウドVMは関与しません。

3レイヤー推奨設定: 個人 / チーム / 企業

利用形態別に settings.json の推奨プリセットを並べると次の通りです。公式が提示する単一ベストプラクティスは存在しないため、「守りたい資産」と「作業効率」のバランス で線を引くのが現実的です。

個人レイヤーでは、サンドボックスを有効にしつつ、互換性のないツールのために allowUnsandboxedCommands: true を残しておくと詰まりにくくなります。~/.claude/settings.json に autoMode.environment を書いて自分のGitHub orgや信頼できるバケットを列挙しておくと、将来 auto モードに切り替えたときに誤検知が減ります。

チームレイヤーでは、.claude/settings.json をリポジトリにチェックインして共有します。Bash許可は npm run * / pnpm * / git commit * などプロジェクト固有の安全なコマンド列に絞り、Bash(git push *) と Bash(curl *) / Bash(wget *) は deny に置きます。データ流出を実質的にブロックしたい場合は、WebFetchドメイン許可リストとPreToolUseフックを併用するのが確実です。

企業レイヤーでは、管理設定(MDM / OSレベルポリシー / サーバー管理設定)に核となる制約を置き、ユーザー設定・プロジェクト設定では緩められない構造にします。allowManagedPermissionRulesOnly: true でユーザー側の allow 追加を封じ、allowManagedDomainsOnly: true でネットワーク許可も管理設定に寄せ、disableBypassPermissionsMode: "disable" で逃げ道を塞ぎます。forceRemoteSettingsRefresh: true を併用すると、管理設定が取得できない状態では起動そのものを止められます。EnterpriseプランではZDRを組織単位で有効化でき、/bug 送信は DISABLE_BUG_COMMAND=1 で原則封じる方針が機密リポジトリには馴染みます。

この早見表は どのレイヤーでも「サンドボックス必須」「curl/wgetはdeny」「bypassPermissionsは封じるか最小化」 という3点が共通の骨格になっています。そこから業務事情に応じて緩める / 締めるを選ぶと、設定が発散しにくくなります。

監査と可観測性

セキュリティ設定は書いて終わりではなく、運用中の可視化が伴って初めて機能します。公式がサポートする監査の経路は以下のとおりです。

• /permissions で現在有効な権限ルールとその出所(どの settings.json から来たか)を一覧
• OpenTelemetryメトリクス(CLAUDE_CODE_ENABLE_TELEMETRY=1 で有効化)による使用状況の収集
• ConfigChange フックでセッション中の設定変更を検知・ブロック
• Sandbox境界を超えようとした試行のOSレベル通知
• Claude Code on the webの監査ログ

特に ConfigChange フックは、チーム運用で「誰かが settings.local.json を書き換えて権限を広げた」といったケースの抑止に効きます。Bedrock / Vertex / Foundry経由であれば、プロバイダー側の監査基盤にログを寄せて既存のセキュリティSIEMに取り込む構成も取りやすい形になっています。

よくある落とし穴

• Bash引数パターンでのURL制限: Bash(curl http://... *) は -X 差し込みや変数経由で容易に破られます。curl / wgetは deny に置き、WebFetch + PreToolUseフックで絞るのが確実です。
• Read / Editのパス表記: /Users/alice/file はプロジェクトルート相対です。絶対パスは //Users/alice/file と書きます。管理設定で間違えると、狙った場所を守れません。
• -p フラグでの信頼検証スキップ: 非対話実行では初回コードベースや新規MCPの信頼検証が無効になります。CIから呼ぶときは、信頼済みリポジトリだけを対象にするか、ネットワーク面をサンドボックスで縛る必要があります。
• allowWrite の広げすぎ: $PATH 上のディレクトリや .bashrc / .zshrc への書き込みを許すと、他プロセスの実行コンテキストで任意コード実行につながり得ます。
• Unixソケット許可: allowUnixSockets で /var/run/docker.sock を許すと、docker経由で実質的にホストへ抜けられます。サンドボックスの意味が消えるので、原則許可しない方向で設計します。
• bypassPermissions を本番マシンで使う: 書き込みが作業ディレクトリ配下に限られるとはいえ、プロンプトインジェクションで任意のBashが通る前提で考えるべきモードです。VMやコンテナ以外では使わない、が安全です。
• /bug の痕跡: /bug は会話履歴全体をAnthropicへ送ります(5年保持)。機密リポジトリでは DISABLE_BUG_COMMAND=1 で封じる選択肢があります。

まとめ

Claude Codeのセキュリティ設計は、権限システム(ツール粒度) / サンドボックス(OS粒度) / データ扱い(契約粒度) の3層を噛み合わせて、agenticな自律実行の現実的な安全領域を作り出す構造です。個人開発では sandbox.enabled: true とcurl / wgetのdenyから始め、チームではプロジェクト settings.json をリポジトリに共有、企業では管理設定で allowManagedPermissionRulesOnly と allowManagedDomainsOnly を締めて逃げ道を封じる、という段階的な締め方が現実的な落としどころになります。ネイティブバイナリ化とサンドボックス強化の流れはv2.1.113で一段前進しているので、リリースノートも併せて追っておくと、設定の意図と将来の方向性がつかみやすいです。