Claude Codeの権限ルールはモデル自体ではなく、エージェントランタイムによって強制されます。この区別は聞こえるより重要です。プロンプトまたはCLAUDE.mdの指示は、Claudeが何をしようとするかを形作りますが、公式の権限ドキュメントが明確に示すように、Claude Codeが実際に許可することは変わりません。アクセス権を付与または取り消すには、/permissionsを使用するか、以下で説明する設定ファイル、権限モード、またはPreToolUseフックを使用します。このポストは、すべての層を説明します。モードの選択、優先順位の理解、動作するポリシーファイルの作成、テスト、およびシステム全体が支援できない場所を知ることです。
権限モードを選択する
選択したモードが他のすべての基盤を設定します。5つあります。
Manualはほとんどのファイル編集、シェルコマンド、ネットワーク呼び出しの前にClaude Codeを停止します。各操作を確認します。遅いですが、何も驚きはありません。
Autoは承認権を分類器モデルに委譲し、あなたの代わりにアクションをレビューします。Pro、Max、Teamプランでは、権限モードドキュメントに従って、これが組み込み起動モードです。分類器には、どのアクションをレビューするか、どれをスキップするかに関する独自のルールがあるため、autoは「すべて承認」と同じではありません。
Accept Editsはファイル操作を自動承認しますが、シェルコマンドのプロンプトは引き続き表示されます。所有し理解しているコードベースで個人作業をする場合、妥当な中間点です。
Planはファイル編集とシェルの書き込みを完全にブロックします。Claudeは読み取り、推論、計画を出力できますが、アクションは実行できません。何か変わる前にアプローチを確認したい初期段階のレビューに適しています。
dontAskは明示的な許可リストにないツールを自動的に拒否します。プロンプトなし、黙って拒否します。これはCI/CDパイプラインに適したモードです。誰も監視していません。
bypassPermissionsはすべてのチェックをスキップします。Claudeは望むことを何でも実行します。サンドボックス化された一時的な環境で便利です。本番リポジトリに対して実行するべきではありません。
VS Codeで起動モードをピン留めするには、ユーザー設定のclaudeCode.initialPermissionModeをdefault、manual、acceptEdits、plan、またはbypassPermissionsに設定します。注意: 設定はautoを受け入れません。Autoで起動するには、設定を未設定のままにして、モード指示から一度選択してください。拡張機能はその後の会話でその選択を記憶します。
ターミナルセッションの場合、~/.claude/settings.jsonまたは管理設定でpermissions.defaultModeを設定します。その値は、フィーチャーフラグ取得が利用可能な場合にPro、Max、Teamプランに適用されます。
知る価値のある1つの特殊なケース: 組織がclaude.aiコネクタツールをaskに設定している場合、そのツールの許可ルールはautoまたはbypassPermissionsモードでも有効になりません。Claude Codeは毎回プロンプトします。dontAskモードでは、プロンプトの代わりにコールを拒否します。
ルールと設定の優先順位がどのように機能するか
5つの層、上から下に評価されます。上位の層が勝ちます。
- 管理設定(
managed-settings.json): IT導入、上書き不可。組織がここでSSHをブロックしている場合、それは最終的です。 - ローカル設定(
.claude/settings.local.json): マシンごと、デフォルトではgitignored。個人または機密性の高いオーバーライドはここに配置します。 - プロジェクト設定（
.claude/settings.json）：リポジトリにコミット済み。そのプロジェクトのチーム全体で共有されます。 - ユーザー設定（
~/.claude/settings.json）：グローバルデフォルト。上位レイヤーがオーバーライドしない限り、すべてのプロジェクトに適用されます。 - セッションフラグ：
--dangerously-skip-permissionsや同様のランタイム引数。
管理者セットアップドキュメントには、知っておく価値のあるロックダウンコントロールが2つあります：allowManagedPermissionRulesOnly（マネージド設定をパーミッションルールの唯一のソースにし、ユーザーおよびプロジェクトファイルを無視する）と permissions.disableBypassPermissionsMode（バイパスオプションを完全に削除する）。契約社員がクライアントリポジトリに触れるエージェンシーを運営している場合、この2つの設定を組み合わせることで、開発者がこっそり取り消すことができない絶対的な上限が実現します。
各レイヤーは3つのルールタイプを受け入れます：allow、deny、ask。レイヤー内では deny が allow より優先されます。シェルパターンマッチングがサポートされています（例えば Bash(git *)）。ただし正確に指定してください：テスト時には完璧に見えるパターンでも、実際のコマンド文字列が予想と異なると、ギャップが生じることがよくあります。
ドキュメントが明示的に指摘していることの1つ：WebFetch を拒否すると Claude の fetch ツールがブロックされますが、Bash が許可されている場合、curl と wget はまだあらゆるURLに到達できます。サンドボックス化（/sandbox 経由）は OS レベルで強制されるドメインアローリストで、そのギャップを埋めます。パーミッションとサンドボックス化は異なるレイヤーをカバーしており、本格的なものには通常両方が必要です。
クライアント・リポジトリ・ポリシーの例
チームがビルドを実行してデータベースを読み取ることはできるが、デプロイスクリプトやシークレットに触れるべきではないクライアントプロジェクト向けの .claude/settings.json の例を以下に示します。これは本番ポリシーのコピペではなく、代表的な構造です。
{
"permissions": {
"defaultMode": "auto",
"allow": [
"Bash(npm run build)",
"Bash(npm run test*)",
"Bash(git log*)",
"Bash(git diff*)",
"Bash(git status)",
"Read(**)"
],
"deny": [
"Bash(rm -rf*)",
"Bash(git push*)",
"Bash(kubectl*)",
"Edit(.env*)",
"Edit(deploy/**)"
]
}
}
これと並行して、各開発者のマシン上の ~/.claude/settings.json は、一般的な使用のために curl を許可するなどの個人的なグローバル信頼を処理します。機密認証情報またはマシン固有のパスは .claude/settings.local.json に入ります。git はこれをコミットしません。
CLAUDE.md の側では、強制ルールではなく規約とプロジェクトコンテキストを設定します。CLAUDE.md へのエージェンシーガイドが、オーサリングワークフローを詳しく説明しています。
ポリシーをリアルなコマンドでテストする
ポリシーを使い捨てリポジトリに入れます（一時ディレクトリ内の bare git init で十分です）。その後、3つのルールカテゴリすべてを対象とした複数のコマンドを実行します。どれが プロンプトを表示し、どれが暗黙に実行され、どれがプロンプトなしで拒否されるかを確認することが目標です。
代表的なテストシーケンス：
npm run build（許可リストにあるため自動承認されるべき）git diff HEAD~1（自動承認されるべき）git push origin main（拒否されるべき）rm -rf node_modules（拒否されるべき）deploy/内のファイルを編集（拒否されるべき）src/index.jsを編集（否定ルールなし、明示的な許可なし：動作はモードに依存）- 外部URL への
curl呼び出し（Bash 許可ルールとサンドボックスがどう相互作用するかをテスト）
特にケース6を注視してください。auto モードではクラシファイアがこれをレビューします。dontAsk モードでは許可リストに載っていないため暗黙に拒否されます。この違いは、あるモードでテストして別のモードでデプロイする開発者を驚かせます。
これの上にイベントレベルのオートメーション（ファイル保存時のリンター実行、特定のツール呼び出し時の通知トリガー）を追加する場合、それはパーミッションではなく hooks に関わります。hooks ガイドで PreToolUse と PostToolUse の全詳細をカバーしています。
チームが無人実行やCI統合を必要とする場合、Claude Codeエージェントセットアップを使用して、最初から設定ベースラインを正しく取得することを検討してください。
管理設定と無人ジョブ
人間が「承認」をクリックできない場合、権限モデルは完全に事前に宣言する必要があります。これはdontAskモードと管理設定の明示的な許可リストを指します。
管理セットアップドキュメントはこれのための管理キーとしてpermissions.defaultModeを提供します。これをdontAskに設定してから、ジョブが必要とするもの正確にpermissions.allowで列挙してください。リストに記載されていないものはすべて暗黙的に拒否されます。これがパイプラインで必要なものです。
公式ドキュメントがエージェントチームシナリオ（リードセッションがチームメイトを生成する場合）について記載している注意事項：
- チームメイトはリードの権限設定で開始します。リードが
--dangerously-skip-permissionsで実行する場合、すべてのチームメイトも同様に実行します。 - スポーン後に個別のチームメイトモードを変更できますが、スポーン時には変更できません。
- チームメイトの権限プロンプトはリードセッションに表示されます。計画承認は設計された例外です。リードは別のプロンプトなしでそれらを付与します。
Managed Agents（プラットフォームレベルのオーケストレーションサービス）は現在Managed Agentsの概要のとおりベータ版です。フォールバックなしでベータ機能を中心に本番パイプラインを設計しないでください。
permissions.disableAutoModeフラグについて：これを設定すると、その組織の開発者にとって自動モードがオプションではなくなります。すべてのセッションが人間または明示的な許可リストがすべての呼び出しを行うモード、つまり分類器ではなく留まるようにする場合に便利です。
権限が保証できないもの
正直に答えると、かなり多くのことです。
シェルパターン拒否ルールはセキュリティ境界ではありません。これらはClaude Codeが構築するコマンド文字列に対して照合されますが、十分に創意的なプロンプトインジェクションまたはシェルコマンドの巧妙な言い換えにより、パターンが捕捉しない文字列が生成される可能性があります。権限ドキュメントは明確です。拒否ルールとサンドボックスは異なるレイヤーをカバーしています。両方が必要であり、その場合でもリスクを軽減しており、排除していません。
bypassPermissionsモードは、許可されたコードを無害にしません。Claudeが実行するコードにバグが含まれていたり、予期しない動作をしたりする場合、権限チェックをスキップすることは、「Claudeが実行することを決定した」と「それが起こった」の間にゲートがなかったことを意味します。
権限はまた、Claude が記述または実行するコード内に何があるかを検証しません。インストールする依存関係、実行するスクリプト、作成するファイルの内容：これらのいずれも権限システムで検査されません。これはランタイムポリシーに近い、サプライチェーンの衛生に関する別の懸念です。
そしてモデル自体は強制層ではありません。「本番環境のシークレットには決してアクセスしない」と言うCLAUDE.md指示を記述できます。これらの指示はClaudeの意図を形成します。設定が誤ったアロー ルールがそれを許可することを防ぎません。ランタイムが強制層です。設定ファイルはランタイムの設定方法です。それに応じてそれらを扱ってください。
FAQ
権限設定は自動的にマシン間で同期されますか？
いいえ。ユーザー設定（~/.claude/settings.json）は各マシンにローカルです。プロジェクト設定（.claude/settings.json）はgit経由で同期されます。管理設定はIT インフラストラクチャによって配布されます。ユーザーレベルのファイルの組み込み同期はありません。各開発者は独自に設定する必要があります。
開発者は管理設定をオーバーライドできますか？
管理設定が許可する範囲内でのみ可能です。allowManagedPermissionRulesOnlyが設定されている場合、ユーザーとプロジェクト権限ルールは完全に無視されます。このフラグがない場合、ユーザーとプロジェクト設定は許可ルールを追加できますが、管理拒否をオーバーライドすることはできません。
ヘッドレス環境やCI環境での権限プロンプトはどうなりますか？
dontAskモードでは、許可リストにないもの はすべて暗黙的に拒否されます。プロンプトを表示するターミナルがないため、プロンプトは表示されません。これは設計によるものです。ヘッドレス環境のautoモードでは、分類器は引き続き実行されますが、プロンプトを解決できない場合（TTYなし）、動作はランナー設定によって異なります。無人ジョブには、明示的な許可リストを含むdontAskを使用してください。
パーミッションモードは MCP ツールと組み込みツールに同じように適用されますか？
ほぼそうですが、違いがあります。Claude Code が直接フェッチした MCP ツールは mcp__claude_ai_<server>__<tool> として表示されます。Allow ルールと deny ルールはその名前でターゲット指定できます。組織が「常に質問」に設定したコネクタからのツールは、モードに関係なく常にプロンプトが表示されます。ただし「dontAsk」モードの場合は代わりに拒否されます。
`.claude/settings.json` をパブリックリポジトリにコミットしても安全ですか？
ファイル自体はツール名とパターンが含まれた JSON であり、シークレットは含まれていません。ただし、パブリックな allow リストはリポジトリを読む人に Claude Code がプロンプトなしで実行するオペレーション内容を正確に知らせてしまいます。オープンソースプロジェクトならおそらく問題ありませんが、プロプライエタリなプロジェクトの場合はコミット内容を確認してください。シークレットと API キーは設定ファイルには決して含めず、Claude Code の設定外の環境変数に配置する必要があります。
最も重要なポイント：deny ルールとサンドボックスは異なる問題を解決するもので、どちらか一方がもう一方に代わることはありません。誤りのコストが実質的な環境で Claude Code を実行する場合は、両方を設定してください。