Claude Codeの権限設定を徹底解説！自動承認を安全に使う方法も紹介

Claude Codeで作業を進めると、コマンドの実行やファイルの変更のたびに確認が表示されます。安全のための仕組みとわかっていても、同じ内容へ何度も「Yes」を返すうちに、確認そのものが作業の流れを止める要因になってきます。かといって、確認を全部飛ばす設定の危険性も気になるところです。

この記事では、Claude Codeの権限の仕組みと、確認を減らすための設定を弱い順に4段階で解説します。読み終えるころには、自分の作業に合った段階を選び、安全を保ったまま承認を自動化できるはずです。結論から言うと、危険なスキップ用フラグに頼らなくても、許可ルールとモードの組み合わせで確認の大半は減らせます。

Claude Codeの権限の仕組みを理解する

設定に入る前に押さえる仕組みは以下の4つです。

• 権限はallow・ask・denyの3つのルールで決まる
• 設定はファイルの階層で管理される
• 操作の種類ごとに確認の扱いが違う
• 権限モードは6種類から選べる

権限はallow・ask・denyの3つのルールで決まる

Claude Codeの権限ルールは3種類です。確認なしで許可するallow、毎回確認するask、禁止するdenyがあります。評価順はdeny・ask・allowの並びで固定されており、最初に一致したルールが適用される仕組みです。ルールの細かさは評価順に影響しないため、広いdenyルールは狭いallowルールより常に優先されます。

現在の設定は、セッション内で/permissionsコマンドを実行すると確認と管理が可能です。確認を減らす作業は、この3種類のルールを自分の作業に合わせて書くことから始まります。

設定はファイルの階層で管理される

権限ルールはsettings.jsonファイルに保存されます。置き場所には階層があり、管理者が配布するmanaged settingsが最優先で、以下プロジェクト・個人の設定が重なる構造です。どこかの階層でdenyされた操作は、別の階層のallowでは許可できません。

対話中に「Yes, don't ask again」で永続承認したBashコマンドは、プロジェクト内の.claude/settings.local.jsonに保存されます。知らないうちに増えた許可を確認したいときも、このファイルを見れば一目瞭然です。

操作の種類ごとに確認の扱いが違う

すべての操作が同じように確認されるわけではありません。公式ドキュメントの整理では、作業フォルダ内のファイル読み取りは承認不要です。システムを変更しうるBashコマンドは承認必須で、許可の永続保存もできます。ファイルの編集も承認必須ですが、承認の効力はセッション終了までです。

「さっき許可したのにまた聞かれた」の一部は、この違いによるものです。ファイル編集の承認はセッションをまたいで残らない仕様のため、毎回聞かれたくない場合は権限モードの設定で対応します。作業の対象が複数のフォルダにまたがる場合は、追加ディレクトリの指定で境界そのものを広げる方法も用意されています。

権限モードは6種類から選べる

確認の頻度をまとめて決める権限モードは、公式ドキュメントによると現在6種類です。

標準のdefaultは、画面上では「Manual」と表示されます(設定値としてはdefaultのまま)。モードの切り替えは、セッション中のShift+Tabキーで行います。起動時の--permission-mode指定や設定ファイルのdefaultModeでの既定指定も可能です。以降の4段階は、このモードとルールをどう組み合わせるかの話になります。

確認を減らす設定【弱い順に4段階】

確認を減らす公式の手段を、影響の小さい順に並べると以下の4段階です。

• 第1段階: allowルールで頻出コマンドを許可する
• 第2段階: acceptEditsモードでファイル編集を自動承認する
• 第3段階: サンドボックスの自動許可モードを使う
• 第4段階: autoモードはAIの安全チェック付きで自動承認する

第1段階: allowルールで頻出コマンドを許可する

最初の一歩は、毎回承認している定番コマンドのallowルール化です。公式ドキュメントの例に沿うと、settings.jsonに次のように書きます。

{"permissions": {"allow": ["Bash(npm run *)", "Bash(git commit *)"], "deny": ["Bash(git push *)"]}}

Bash(npm run *)のように*を使えば、まとめての許可が可能です。*が一致するのは前方だけではなく、公式ドキュメントによると先頭・途中・末尾の任意の位置で使え、スペースをまたいだ部分にも一致します。「Bash(ls *)」と「Bash(ls*)」は別物で、前者はlsコマンドだけ、後者はlsofのような別コマンドにも一致してしまう点に注意してください。よく使う操作だけをピンポイントで開ける方法のため、影響範囲を自分で把握しながら書くのが利点です。

第2段階: acceptEditsモードでファイル編集を自動承認する

セッション単位で切り替えるなら、権限モードの変更が手軽です。acceptEditsモードにすると、作業フォルダ内のファイル編集と、mkdirやmvなどの一般的なファイル操作コマンドが自動承認されます。

切り替えはShift+Tabキーで、Manual(default)・acceptEdits・planの順に循環します(条件を満たすとbypassPermissionsやautoも循環に加わり、dontAskは循環に含まれません)。編集の承認がセッション限りで消える仕様への、公式が用意した答えがこのモードです。逆に慎重に進めたい場面では、ファイルを編集せず計画の提案だけを行うplanモードへ同じキーで切り替え可能です。

第3段階: サンドボックスの自動許可モードを使う

サンドボックスを有効にすると、OSレベルの隔離の中で完結するコマンドを確認なしで実行する自動許可モードが選べます。書き込みは作業フォルダ内に限定され、ネットワークは承認制のまま守られます。

自動許可モードでも、明示的なdenyルールと、git pushのような一部の操作への確認は残る設計です。有効化はセッション内の/sandboxコマンドから行え、選んだモードはプロジェクトの設定ファイルに保存されます。安全の枠を先に固めて、枠の中は自由にさせる考え方で、確認の削減幅と安全性のバランスが良い段階です。

第4段階: autoモードはAIの安全チェック付きで自動承認する

autoモードは、バックグラウンドで安全チェックを実行しながら自動承認するモードです。公式ドキュメントによると、別のAI(分類器)が実行前に操作を審査し、依頼内容から逸脱した操作や危険な操作をブロックします。自分でルールを書かなくても、リスクのある操作だけが止まる仕組みです。

このautoモードは、公式ドキュメントによるとPro・Max・Teamプランでは新しいセッションの既定のモードになっています(自分で既定を設定している場合はその設定が維持されます)。つまり「確認を減らす設定」は、多くの人にとって最初から有効な状態です。事前承認済みの操作以外を自動で拒否するdontAskモードも用意されており、どの段階まで進むかは、扱うデータの重要度と相談して決める形です。

dangerously-skip-permissionsは最後の手段

確認を全部飛ばす手段の位置づけは以下のとおりです。

• bypassPermissionsモードは公式が隔離環境限定と警告している
• 組織では設定で使用を禁止できる

bypassPermissionsモードは公式が隔離環境限定と警告している

確認をすべてスキップするbypassPermissionsモード(起動フラグは--dangerously-skip-permissions)も存在します。ただし公式ドキュメントは、Claude Codeが損害を与えられないコンテナやVMなどの隔離環境でのみ使用するよう明記しています。

このモードでも、ルートディレクトリやホームディレクトリの削除のような操作には、最後の砦として確認が出る設計です。似た名前の--allow-dangerously-skip-permissionsは別のフラグです。モードを即座に有効化するのではなく、Shift+Tabの循環に選択肢として加えるだけの働きをします。とはいえ普段のパソコンで常用する設定ではありません。第1〜4段階で確認はほぼ減らせるため、スキップに頼る前に段階側を先に試すのが安全な順番です。

組織では設定で使用を禁止できる

会社の環境では、bypassPermissionsモードの使用自体を禁止できます。permissions.disableBypassPermissionsModeをdisableに設定し、管理者配布のmanaged settingsに置けば、利用者側では上書きできない仕様です。同様に、autoモードを禁止するpermissions.disableAutoModeも用意されています。

autoが既定になる流れを踏まえると、組織としては「autoを許すか、Manualを既定に戻すか」の判断も新たに必要です。チームでClaude Codeを使う場合は、個人の判断に任せず、組織としてモードの扱いを決めておくと事故の芽を摘めます。

安全側の守りを固める設定

確認を減らすほど重要になるのが、守りの設定です。

• denyルールで触らせない操作を先に塞ぐ
• denyルールの限界はサンドボックスで補う

denyルールで触らせない操作を先に塞ぐ

自動化を進める前に、絶対に触らせない操作をdenyで固定します。公式ドキュメントの構文例では、Bash(git push *)のようなコマンド単位、Read(./.env)のようなファイル単位で禁止を書けます。denyはどの階層のallowよりも優先されるため、確認を減らした後も効き続ける防波堤です。

対象はコマンドとファイルに限りません。WebFetch(domain:example.com)のような書き方で、アクセスできる接続先をドメイン単位で制御するルールも公式の構文に含まれています。ツール名だけをdenyに書くと、そのツール自体がClaude Codeから見えなくなる仕組みもあり、使わせたくない機能は丸ごと消す選択も可能です。

.gitや.claudeといった重要な場所への書き込みは、公式ドキュメントによると保護パスの扱いです。allowルールを書いても自動承認されません。設定ファイル自体をAIに書き換えさせない守りが、仕組みの側にも入っています。

denyルールの限界はサンドボックスで補う

注意点として、ReadやEditのdenyルールが効くのは、組み込みのファイルツールと主要なファイル系コマンドまでです。ファイルを間接的に開く自作スクリプトなどには適用されないと公式ドキュメントに明記されています。

全プロセスへの強制にはサンドボックスの有効化が必要です。権限ルールで判断の層を、サンドボックスでOSによる強制の層を作る多層防御が公式の推奨で、確認を減らす設定ほどこの2段構えが効いてきます。全体の安全設計は次の記事で解説しています。

Claude Codeのセキュリティを徹底解説！安全に使う設定と企業運用も紹介

Claude Codeの権限設定に関するよくある質問

設定でつまずきやすい点は以下の3つです。

• 許可したのに確認が出るのはなぜですか？
• allowルールとautoモードは何が違いますか？
• チームで同じ権限設定を使うにはどうしますか？

許可したのに確認が出るのはなぜですか？

よくある原因は、allowより先にdenyやaskのルールが一致しているケースです。評価の順番はdeny・ask・allowで固定されており、ルールの細かさは考慮されません。公式ドキュメントも、Bash(aws *)のような広いdenyが、Bash(aws s3 ls)のような狭いallowに一致する呼び出しごと塞ぐ例を挙げています。

見落としやすいのが、仕様として意図的に確認が出るパターンです。許可リストに載っていても、コマンドインジェクションの疑いを検出した場合は手動承認に切り替わり、ルールに一致しない操作は確認側に倒れると公式に説明される設計です。安全側の挙動のため、異常ではありません。

もう1つの原因は、ファイル編集の承認がセッション限りで消える仕様です。/permissionsで現在のルールを確認し、意図しないdeny・askがないかを見直してください。

allowルールとautoモードは何が違いますか？

allowルールは、自分が事前に決めた操作だけを無条件で許可する方式です。対してautoモードは、ルールを書かなくても、AIによる安全チェックを通しながら自動承認する方式になります。

確実に範囲を制御したいならallowルール、手間をかけずに広く自動化したいならautoモード、と使い分ける関係です。denyルールによる禁止はどちらのモードでも優先されます。ただし公式ドキュメントによると、autoモード中はBash(*)のような広すぎるallowルールが一時的に無効化されるため、「autoにしたら一部のallowが効かなくなった」と感じる場面は仕様どおりの挙動です。

チームで同じ権限設定を使うにはどうしますか？

プロジェクトのsettings.jsonに権限ルールを書き、リポジトリのバージョン管理に含めて共有するのが公式の想定する方法です。メンバー全員が同じallow・denyで作業できます。

さらに強制力が必要な場合は、管理者が配布するmanaged settingsの出番です。個人やプロジェクトの設定では上書きできないため、組織の最低ラインを技術的に固定できます。

Claude Codeの権限設定は4段階とdenyの組み合わせで自動化しましょう

Claude Codeの確認を減らす公式の手段は、allowルール・acceptEditsモード・サンドボックスの自動許可・autoモードの4段階です。影響の小さい段階から試せば、危険なスキップ用フラグに頼らずに承認の大半を自動化できます。Pro・Max・Teamでは新しいセッションでautoが既定になっているため、「どう減らすか」に加えて「autoの動きを理解して手綱を握る」ことも大切になりました。

安全側は、denyルールで触らせない操作を先に固定し、denyが届かない領域をサンドボックスで補う2段構えが基本です。bypassPermissionsモードを隔離環境限定とする公式の線引きを守り、組織では禁止設定まで検討します。

まずは自分が毎日承認しているコマンドを3つ書き出し、allowルールにするところから始めましょう。