AI コーディングエージェントを安全に使う：Claude Code の権限・サンドボックス・確認の設定

なぜ設定するのか

コーディングエージェントは、ファイルを書き換え、コマンドを実行し、外部の情報を読み込みます。その「実行できること」は事故の入り口にもなります。誤った削除、.env の読み取り、信頼できない文書に仕込まれた指示（プロンプトインジェクション）による意図しない操作などです。

公式ドキュメントによると、許可の判断をするのは Claude Code 本体で、モデルではありません。プロンプトや CLAUDE.md に「.env は読まない」と書いても、それはモデルへの依頼にとどまります。止めたいことは仕組みで止めます。

ここでは権限ルール、パーミッションモード、サンドボックスの3層を扱います。hooks の詳細は別の記事に譲ります。

権限の3段階：allow・ask・deny

権限ルールは permissions の allow（許可）、ask（毎回確認）、deny（拒否）の3リストに書きます。形式は Tool または Tool(specifier) で、たとえば Bash(npm run build)、Read(./.env)、WebFetch(domain:example.com) のように書きます。Bash だけなら、そのツールの全呼び出しに一致します。

評価の順序は deny、ask、allow で、最初に一致したものが結果になります。広い deny は狭い allow より優先され、allow で例外を掘ることはできません。

Bash のルールでは * が空白を含む任意の文字列に一致します。公式は、サブコマンドの後ろに * を置くよう案内しています。

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

Bash(git log *) は git log だけを許しますが、Bash(git *) は git のあらゆるコマンドを許します。

deny ルールは「境界」ではない

公式は、Bash の deny／ask ルールを安全境界ではなく、コマンド文字列への一致だと説明しています。Bash(curl *) は curl https://example.com を止めますが、/usr/bin/curl ... や sh -c 'curl ...' は止めません。確実に止めたい操作は、後述のサンドボックスや、hooks による独自の検査と組み合わせます。

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

範囲	ファイル	対象
ユーザー	~/.claude/settings.json	自分の全プロジェクト
共有	.claude/settings.json	プロジェクトの全員（git で共有）
個人	.claude/settings.local.json	自分のそのプロジェクト
管理	managed-settings.json など	組織の全員

優先順位は強い順に、管理設定、コマンドライン（--settings）、プロジェクトの個人設定、プロジェクトの共有設定、ユーザー設定です。ただし permissions.allow のようなリストは、上書きではなく結合されます。

押さえておきたい点が3つあります。

1. 共有の .claude/settings.json の allow ルールは、各自がそのフォルダを信頼（トラスト）してから有効になります。deny と ask はすぐに効きます。
2. 「Yes, and don't ask again」を選ぶと、allow ルールが .claude/settings.local.json に保存されます。
3. ルールは /permissions、読み込まれた設定ファイルは /status で確認できます。

パーミッションモード

モードは、承認を求める頻度を切り替えます。permissions.defaultMode で既定値を決め、claude --permission-mode <モード> で起動時に指定し、セッション中は Shift+Tab で切り替えます。

モード	確認なしで動くもの
default（Manual）	読み取りのみ
acceptEdits	読み取りと、作業ディレクトリ内のファイル編集・基本的なファイル操作（mkdir mv cp など）
plan	読み取りと調査のみ。計画を承認するまで編集しない
auto	分類器が各操作を確認して実行
dontAsk	確認が要る操作はすべて自動拒否。事前許可したものだけ動く
bypassPermissions	確認を省く

初めて触るコードベースや大きな変更の前は plan が向きます。claude --permission-mode plan で起動するか、プロンプトの先頭に /plan を付けます。acceptEdits でも、.git や .claude などの保護対象と作業ディレクトリ外は確認が残ります。

auto は、公式ドキュメントでは v2.1.283 以降の対話的なターミナルと VS Code の初期モードとされています。分類器は、依頼の範囲を超える操作や、悪意ある内容に誘導されたような操作を止めます。curl | bash、本番デプロイ、force push などが止まる例で、ask と deny のルールも有効です。

bypassPermissions（--dangerously-skip-permissions と同じ）は、保護対象への書き込みも含めて確認を省きます。公式は、コンテナや VM のような隔離環境でのみ使うよう求めています。deny ルールはこのモードでも効きます。

サンドボックスで実行範囲を囲う

権限ルールは「呼び出すか」の判断で、サンドボックスは「動いているコマンドが何に触れるか」を OS のレベルで制限します。

• 既定は無効です。/sandbox で有効にするか、~/.claude/settings.json で sandbox.enabled を true にします。
• macOS は Seatbelt、Linux と WSL2 は bubblewrap で実現しています。ネイティブの Windows では WSL2 が必要です。
• 書き込みは作業ディレクトリなどに限られ、.claude の設定、.mcp.json、.git/hooks は保護されます。
• ネットワークは、プロキシ経由で sandbox.network.allowedDomainsに載せたホストのみです。

読み取りの既定は広く、~/.ssh や ~/.aws/credentials のような認証情報も対象に含まれます。止めるには sandbox.filesystem.denyRead や sandbox.credentials を使います。Read や Edit などの組み込みツール、MCP サーバー、hooks はサンドボックスの外で動きます。denyRead は Read ツールを止めないため、この穴は deny ルールで補います。

逃げ道もあります。コマンドがサンドボックス内で失敗すると、Claude が dangerouslyDisableSandbox 付きで再試行することがあり、禁じるには "allowUnsandboxedCommands": false を設定します。excludedCommands のコマンドは外で動くため、狭く指定します。さらに強い隔離には、Claude Code 全体をコンテナや VM で動かすことを公式は勧めています。

守るべきもの：.env・鍵・本番

最初に塞ぎたいのは、機密ファイルの読み取りです。前掲の Read(./.env) などの deny がその形です。

この Read の deny は、組み込みのファイルツールと、cat など Claude Code が認識するファイルコマンドに適用されます。grep -r pattern . のようにファイルを名指ししない読み取りや、任意のサブプロセスによる読み取りは対象外です。

層を重ねるのが現実的です。~/.ssh や ~/.aws、トークンの環境変数は、サンドボックスの denyRead や sandbox.credentials（"mode": "deny"）で隠します。本番への操作は該当コマンドを ask か deny にし、本番の認証情報は開発用マシンに置かないのが確実です。

外部入力のリスク

Web ページ、Issue、README、MCP サーバーの返答には、命令が紛れ込む可能性があります。公式が挙げる備えです。

• curl や wget は、既定では自動承認されません。
• 未信頼のフォルダや .mcp.json のサーバーには、承認の確認が出ます。

公式は、承認前にコマンドを確認すること、信頼できない内容を直接渡さないこと、外部サービスを触るスクリプトは VM で動かすことを勧めています。

MCP は特に注意が必要です。公式は自作か信頼できる提供元のサーバーを使うよう勧めており、Anthropic は MCP サーバーの監査をしないと明記しています。接続はMCP接続の記事を参照してください。MCP ツールのルールは mcp__<サーバー名>__* の形で書けます。外部の情報を読むエージェントに強い権限を同時に持たせないことが基本で、人間による確認を省く場所は慎重に選びます。

チーム・組織での運用

チームでは .claude/settings.json をコミットしてルールを共有し、個人の例外は .claude/settings.local.json に置きます。

組織が強制したいルールは、管理設定で配布します。配布は claude.ai の管理コンソール、MDM、システムディレクトリのファイルなどで行い、ファイルは macOS なら /Library/Application Support/ClaudeCode/managed-settings.json、Linux と WSL なら /etc/claude-code/managed-settings.json です。公式の例は、.env などの Read deny に加え、permissions.disableBypassPermissionsMode を "disable"、allowManagedPermissionRulesOnly を true にしています。

管理設定は最上位で、ユーザーやプロジェクトの設定では上書きできません。allowManagedPermissionRulesOnly で権限ルールの出どころを管理設定に限れ、サンドボックスは sandbox.failIfUnavailable などで必須にでき、MCP サーバーは allowManagedMcpServersOnly で絞れます。

チェックリスト

• .env、secrets/ に Read の deny を入れた
• git push や本番操作は ask か deny にした
• 新しい作業は plan から始め、bypassPermissions は隔離環境のみ
• サンドボックスを有効にし、allowedDomains を最小にした
• MCP は信頼できるものだけにしている
• 共有設定をコミットし、/permissions で状態を確認した

最初は厳しめに始め、頻繁に出る確認だけを allow に移すのが無理のない進め方です。