Claude Code を使い始めると、すぐにこの画面にぶつかります。「このコマンドを実行してもいいですか？」という確認です。最初は丁寧でいいのですが、10回、20回と続くと手が止まります。
ここで多くの人が「毎回聞かれるのが面倒だから、全部許可」に倒します。作業は速くなりますが、ファイルを消すコマンドも、外部にデータを送るコマンドも、同じように素通りするようになります。
この記事では、確認の回数を実用的なところまで減らしつつ、戻せない操作だけは必ず止まる設定の作り方を扱います。設定ファイルを1つ書くだけで、追加のツールは要りません。
この記事でわかること
- 権限を「許可・確認・禁止」の3つの箱で考える方法
- 設定ファイルをどこに置くか（3階層の使い分け）
- 最初にそのまま入れて使える設定の実例
- やりがちな失敗3つと、その直し方
Claude Code をまだ入れていない方は、先に Claude Codeのインストールと使い方入門｜ターミナルで動くAIコーディングアシスタント をご覧ください。
権限は「許可・確認・禁止」の3つの箱で考える
Claude Code の権限設定は、突き詰めると操作を3つの箱に振り分ける作業です。設定ファイルの中では allow／ask／deny という名前になっています。
| 箱 | 意味 | 入れるもの |
|---|---|---|
allow（許可） | 確認せず実行する | 何度やり直しても困らない操作 |
ask（確認） | 毎回たずねる | 影響はあるが、取り消せる操作 |
deny（禁止） | そもそも実行させない | 戻せない操作・外に出る操作 |
振り分けの基準は1つだけで足ります。「間違えたとき、元に戻せるか」です。
テストを走らせる、ビルドする。これらは何度やっても壊れないので allow でかまいません。一方、ファイルの削除、外部への送信、本番環境への反映は、実行された後では取り返しがつきません。ここは deny に置きます。
なお、作業フォルダ内のファイルを読むことや、git status・ls のような読み取り専用のコマンドは、最初から確認なしで動きます。わざわざ allow に書く必要はありません。
この「戻せるかどうかで線を引く」考え方は、AI全般の業務適用でも同じです。表1枚で作る承認の仕組みは AI出力の承認フローの作り方｜表1枚で始める人の確認の入れどころ にまとめました。
「禁止」を書かないと意味が薄れる
見落とされやすいのが deny です。許可リストだけを育てていくと、書き忘れた操作はすべて「確認」に落ちます。確認が多いと、人は中身を読まずに承認するようになります。
これは権限設計の世界では昔から知られている失敗で、確認のしすぎは、確認しないのと同じ結果になります。だからこそ「やらせない」を少数だけ明示して、残りの確認の重みを保ちます。
判定の順番も覚えておくと迷いません。Claude Code は禁止 → 確認 → 許可の順に照合し、最初に当たったものを採用します。しかも、どの設定ファイルに書かれた禁止でも、他のファイルの許可より先に効きます。禁止は、あとから誰かが許可を足しても上書きされないということです。
ただし「禁止」は鍵ではない
1つ注意があります。コマンドの禁止ルールは、Claude が書いたコマンドの文字列を見て止める仕組みです。たとえば rm を禁止しても、/bin/rm のように書き方を変えたものまでは止まりません。公式ドキュメントも、これをセキュリティ上の壁ではないと明記しています。
普段の作業で Claude が書くコマンドを止めるには十分ですが、「どんな手段でも絶対に触らせたくないもの」がある場合は、この設定だけに頼らないでください。公式にはサンドボックス（OS側で読み書きや通信を制限する機能）という別の仕組みが用意されています。
設定ファイルはどこに置くか｜3階層の使い分け
置き場所が3つあり、どれに書くかで「誰に効くか」が変わります。ここを間違えると、チームに共有したい設定が自分だけに効いていた、ということが起きます。
| 場所 | 効く範囲 | Gitに入るか |
|---|---|---|
~/.claude/settings.json | 自分の全プロジェクト | 入らない |
.claude/settings.json | そのプロジェクト全員 | 入る（共有される） |
.claude/settings.local.json | そのプロジェクトの自分だけ | 入らない |
使い分けの目安はこうです。
- どの仕事でも変わらないもの（削除は禁止、など）→
~/.claude/settings.json - そのプロジェクト固有で、全員に効かせたいもの（このリポジトリのテストコマンドは許可）→
.claude/settings.json - 自分の環境事情（自分だけが使うツール）→
.claude/settings.local.json
.claude/settings.json は Git に入る、つまりチーム全員の環境に配られるという点だけ注意してください。ここに個人の事情を書くと、他の人の環境で意図しない許可が増えます。
最初に入れる設定の実例
まずは ~/.claude/settings.json に、この形を置くところから始めてください。そのまま使えます。
{
"permissions": {
"allow": [
"Bash(npm test *)",
"Bash(npm run build)",
"Bash(npm run lint)"
],
"ask": [
"Bash(git push *)",
"Bash(npm install *)"
],
"deny": [
"Bash(rm *)",
"Read(./.env)",
"Read(./secrets/**)"
]
}
}短いですが、これで「確認の大半が消えて、危ないものだけ止まる」状態になります。あとは実際に使いながら、止まって困ったものを allow に足していくのが早道です。最初から完璧な一覧を作ろうとしないでください。
書き方のコツ｜末尾の「 *」
慣れないうちに必ず引っかかるのが、コマンドの指定方法です。
| 書き方 | 意味 |
|---|---|
Bash(npm test) | 完全にこの文字列のときだけ |
Bash(npm test *) | npm test で始まるコマンド全部（npm test 単体も含む） |
Read(./.env) | 作業フォルダ直下の .env |
Read(./secrets/**) | secrets フォルダ配下すべて |
ポイントは末尾の「空白＋*」が「〜で始まるもの全部」を表すことです。Bash(npm test) と書くと、npm test -- --watch のようにオプションが付いただけで一致しなくなります。「毎回許可しているのに毎回聞かれる」ときは、だいたいここが原因です。
空白は省略しないでください。Bash(ls *) は ls で始まるコマンドに一致しますが、空白のない Bash(ls*) は lsof のような別のコマンドにまで一致します。古い記事では Bash(npm test:*) のようにコロンを使った書き方も見かけますが、これは Bash(npm test *) と同じ意味です。
なお、設定ファイルを手で書かずに済ませることもできます。確認画面で「Yes, and don't ask again」を選ぶと、そのコマンドが許可として保存されます。保存先は ~/.claude/settings.json ではなく、そのプロジェクトの .claude/settings.local.json です。つまり許可はプロジェクトごとで、別のフォルダで作業すると改めて聞かれます。まずはこの方法で1週間使い、たまった許可を見直して、全プロジェクト共通にしたいものだけ ~/.claude/settings.json に移すのが、現実的には一番早いです。
やりがちな失敗3つ
① 面倒になって全部許可にする
最も多い失敗です。確認をすべて飛ばす設定を入れると、削除も送信も素通りします。公開されているリポジトリや、顧客データを扱うフォルダでこれをやると、事故は「起きるかどうか」ではなく「いつ起きるか」の話になります。
どうしても確認を減らしたいなら、全部許可ではなくallow を具体的に増やし、deny を数行だけ書く方が、速さと安全の両方が手に入ります。
② 機密ファイルを読み取り対象から外していない
.env やAPIキーを置いたフォルダは、明示的に deny へ入れてください。読み取りは「何も壊さない安全な操作」に見えますが、読まれた内容はそのままAIへの入力になります。
読み取りの禁止は、Claude のファイル読み込みに加えて cat のような読み取りコマンドにも効きます。ただし、Claude が書いたプログラムが中でファイルを開く場合までは止まりません。先ほどの「禁止は鍵ではない」と同じ話です。本当に見せてはいけないファイルは、そもそも作業フォルダの外に置くのが確実です。
ここで扱っているのはClaude Code というツールに何をさせるかの設定です。その手前の、会社として「どのデータをAIに見せてよいか」を決める話は AIに社内データを使わせる前に決める権限管理の3層と5ステップ で扱っています。ツールの設定は、そちらで決めた範囲を守らせるための手段です。
③ 共有すべき設定を自分専用の場所に書く
.claude/settings.local.json は Git に入りません。ここにプロジェクト共通のルールを書くと、自分の手元だけが快適で、他のメンバーは延々と確認を押し続けることになります。「チーム全員に効かせたいか」を基準に、置き場所を選び直してください。
よくある質問
Q. 設定を変えたら、すぐ反映されますか？
A. はい。Claude Code は設定ファイルの変更を見張っていて、保存すれば作業中のセッションにそのまま反映されます。開き直す必要はありません。設定ファイルを直接開かなくても、Claude Code の中で /permissions と打てば、いま効いているルールの一覧と、それぞれがどのファイルに書かれているかを確認・編集できます。
Q. どのくらい許可すれば「ちょうどいい」ですか？
A. 目安は「1時間の作業で確認が数回」です。それ以上なら allow が足りず、逆にまったく止まらないなら deny の書き忘れを疑ってください。
Q. 会社で複数人が使う場合、何から決めればいいですか？
A. deny だけ先に全員で合意してください。許可は各自が使いながら増やせばよく、揃っている必要はありません。揃っていないと困るのは「やらせないこと」の方だけです。全員に効かせる禁止は、Git に入る .claude/settings.json に書きます。
Q. ファイル整理のような自動化にも同じ考え方が使えますか？
A. 使えます。Claude Codeでファイル整理を自動化｜Macのダウンロードフォルダ編 では「移動はさせるが削除はさせない」という形で、同じ線の引き方を実際のフォルダ整理に当てはめています。
まとめ
- 権限は許可・確認・禁止の3つの箱に振り分ける。基準は「間違えたとき元に戻せるか」だけ
denyを必ず書く。禁止はどのファイルに書いても許可より先に効く。ただしコマンドの文字列で止める仕組みで、鍵ではない- 置き場所は3階層。チーム全員に効かせたいものだけ
.claude/settings.jsonに書く - コマンド指定は末尾の「空白＋
*」で「〜で始まるもの全部」。「許可したのに毎回聞かれる」の原因はほぼこれ - 最初から完璧を目指さない。短い設定で始め、止まって困ったものを足していく
権限設定は、AIに仕事を任せるための「ブレーキ」です。ブレーキが効くとわかっているから、アクセルを踏めます。
ただ、実際の導入でつまずくのは設定の書き方より、「うちの業務で、何を禁止に入れるべきか」が決まらないことの方です。削除や送信のような分かりやすいもの以外に、その会社にしかない「戻せない操作」が必ずあります。frural では、お手持ちの業務を洗い出して許可・確認・禁止に振り分けるところからご一緒しています。設定ファイルの作成と、チームへの展開まで含めて構いません。サービスの詳細はこちら、ご相談は お問い合わせ からどうぞ。