Claude Codeのpermissions設定｜allow・ask・denyとパーミッションモード・hooksの使い分け【deny18件の実例】

公開日：2026年10月13日

先に結論です。Claude Codeの権限まわりは、パーミッションモードで全体の姿勢を決め、permissionsのdenyとaskで危険な操作を個別に塞ぎ、それでもすり抜けるものだけhooksで止める、という3段で考えてください。みやっち🧑‍💻の設定は、モードはオートモード、denyが18件、askは rm（削除）の1件だけ、allowは0件です。

Claude Codeのpermissionsとは Claude Codeのpermissionsは、settings.json に書く「この操作は許す（allow）・実行前に聞く（ask）・禁止する（deny）」の個別ルールです。パーミッションモードがセッション全体の運転の仕方を決めるのに対し、permissionsはツールやコマンド単位の例外を決めます。hooksは、自分で書いたプログラムが実行の直前に中身を解析して判定する、もう一段の仕組みです。

この記事は、Claude Codeを仕事で使い始めた経営者・個人事業主・士業に向けて、3つの違いと使い分けを公式ドキュメント（2026年10月13日時点）とみやっち🧑‍💻の実際の設定から整理します。セキュリティの話なので、「これで安全」という書き方はしません。事故を減らすための考え方として読んでください。

パーミッションモードとpermissions設定は何が違うのか

混同しやすいのが、モードと設定です。みやっち🧑‍💻は次のように分けて考えています。

モード: Claude Code全体を「どれくらい慎重に動かすか」という運転モード。セッション全体の基本姿勢
設定（allow・ask・deny）: 「この操作は許す・聞く・禁止する」という個別ルール

車にたとえると、モードはオートマかマニュアルかの選択、denyは「この道には入らない」という通行止めの看板です。公式ドキュメントも「モードが土台を決め、その上にpermissionsのルールを重ねる」と説明しています。公式のモードは6つです（設定ファイルに書く値で表記）。

モード	確認なしで進むもの	向いている場面
`default`	読み取りだけ	1つずつ自分で確かめたい作業（画面上の表示はManual）
`acceptEdits`	読み取り、作業フォルダ内のファイル編集、`mkdir`・`mv` などの基本的なファイル操作	中身を見ながら進める作業
`plan`	読み取り中心で、ソースを編集しない	変える前に調べたいとき
`auto`	ほぼすべて。シェルコマンドや通信などは、実行前に別のAI（分類モデル）がチェックする	長い作業、確認疲れを減らしたいとき
`dontAsk`	事前に許可したものだけ。確認が必要なものは自動で拒否	無人で動かす決まった処理
`bypassPermissions`	すべて	公式は、隔離したコンテナや仮想マシンでだけ使うよう警告しています

オートモードが標準になった経緯はオートモードが標準になった件の記事にまとめています。CLIではShift+Tabでモードを切り替えられ、起動時のモードは settings.json の defaultMode で決めます。

allow・ask・denyは、どの順番で判定されるのか

ここが一番大事なところです。公式ドキュメントによると、ルールはdeny → ask → allowの順に評価され、最初に当てはまったものが結果になります。ルールの細かさは順番に影響しません。この順番から、実務で効く性質が3つ出てきます。

allowでdenyに例外は作れない: 広いdenyに当てはまる操作は、より細かいallowがあっても止まります
denyはどのモードでも効く: 公式は「denyはbypassPermissionsを含むすべてのモードでブロックする」と明記しています。askに当てはまる操作も、どのモードでも自動では通りません
どの設定ファイルのdenyも優先される: 個人の設定でallowしても、プロジェクトの設定でdenyしていれば止まります。逆も同じです。会社が配る管理設定（managed settings）は、個人やプロジェクトの設定では上書きできません

もう1つ、公式が注意書きで強調している点があります。permissionsを守らせているのはClaude Codeの仕組みであって、AIモデルではありません。CLAUDE.mdに「.envは読まないで」と書いても、それはAIの行動の方向づけで、許可・禁止そのものは変わりません。オートモードの公式説明も、会話で伝えた「これはしないで」は会話の要約で消えることがあるとして、確実に止めたいならdenyに書くよう案内しています。

settings.jsonにはどう書くのか

書き方は ツール名(対象) の形です。Bashのコマンドは Bash(rm *) のように * で「その先は何でも」を表し、ファイルは Read(…)・Edit(…) にパスを書きます。例を1つ置きます（みやっち🧑‍💻の設定そのものではなく、形を示すための例です）。

{
  "permissions": {
    "defaultMode": "auto",
    "deny": ["Bash(sudo *)", "Bash(dd *)", "Read(**/.env)", "Edit(**/.env)"],
    "ask": ["Bash(rm *)"]
  }
}

書くときに気をつけたい点が3つあります。いずれも公式ドキュメントの記載です。

ファイルの書き込みもEditのルールで判定される: Write(…) のようにパスを書いたルールは、受け付けても判定には使われません。書き込みを止めたいときは Edit(…) で書きます。なお、Read のdenyも同じパスへの編集・書き込みを止めます
defaultMode の auto は個人の設定に書く: プロジェクトの .claude/settings.json や .claude/settings.local.json に auto と書いても効きません。~/.claude/settings.json に置きます
末尾の * の前のスペースにも意味がある: Bash(ls *) は lsof に当たりませんが、スペースの無い Bash(ls*) は当たります

設定ファイルは、個人の ~/.claude/settings.json、プロジェクトの .claude/settings.json（共有用）と .claude/settings.local.json（自分用）、会社が配る管理設定の4か所に置けます。そもそもClaude Codeに社内データを任せてよいかの判断は、セキュリティの記事で整理しています。

みやっち🧑‍💻の設定：モードは自動、denyで穴を塞ぐ

みやっち🧑‍💻は、「普段はかなり自由に作業してほしいが、危険な操作だけは塞ぎたい」なら、モードは自動化寄りにして、個別のdenyで危険な操作だけ塞ぐ、と整理しています。実際の設定もその形です。2026年10月13日時点の個人の settings.json はこうです。

既定のモード: オートモード
deny 18件: sudo・shred・truncate・mkfs・dd・wipefs の取り返しのつかないコマンド6件と、APIキーなどを置く .env のRead・Edit・Write各4件（前述のとおりWriteのルールは判定に使われないので、書き込みは実質ReadとEditのルールで止まっています）
ask 1件: rm（削除）だけは実行前に聞かせる
allow 0件: 通常の作業はモードに任せている

モードを慎重にしすぎると、毎回の確認で止まって、結局使われなくなります。確認の回数はモードで減らし、本当に困るものだけをdenyで塞ぐ。askは rm の1件だけなので、作業中に確認で止まるのは削除のときに限られます。

permissionsで止めきれないものだけhooksに回す

みやっち🧑‍💻の線引きは、permissionsを第一防衛線にして、絶対に事故らせたくないものだけhooksにする、です。hooksは、ツールを使う直前（PreToolUse）などのタイミングで自分のプログラムを動かし、中身を見て止められる仕組みです。

hooksに回す基準は、「コマンドの書き方次第ですり抜ける」「中身を読まないと判定できない」ものです。公式ドキュメントも、Bashのコマンドの引数を細かく縛ろうとするルールは崩れやすいと注意しています。.env のdenyはClaude Codeが認識する cat などのコマンドにも及びますが、ファイル名を書かずに読むコマンドや、PythonやNodeのスクリプトが中でファイルを開く場合には及ばない、と明記されています。そこでみやっち🧑‍💻は、.env の中身を表示するコマンドをPreToolUseのフックで止めています。止める対象は3つです。

表示・持ち出し系のコマンドと .env の組み合わせ
インタープリタのワンライナー（1行で書くプログラム）に .env が入ったもの
リダイレクトで .env を読むもの

方針は「中身を画面に出す操作だけを止め、正規の読み込み方法は妨げない」です。止めたときは、代わりの正しい方法を理由の欄に書いてClaudeに返します。理由が返るので、Claudeが止まったあとに正しいやり方へ切り替えやすくなります。このフックは複数台のMacで同じ設定にそろえています。ほかに、規約で自動アクセスを禁じているSNSへ、ログイン中のブラウザやcurlで取りに行く操作もフックで止めています。URLを含む文章を書くことは止めず、「取りに行く操作」だけを判定しています。

なお、公式は確実に許可・禁止したいものはpermissionsで、コマンドの全文を自分のロジックで調べたいときはPreToolUseフックで、と使い分けを示しています。フックが「許可」と返しても、denyやaskのルールは飛ばせません。hooksはpermissionsの代わりではなく、上に重ねる層です。

これで万全ではない：組織の規定と専門家の確認を

permissions・モード・hooksを組み合わせても、すべての事故や攻撃を防げるわけではありません。Anthropicの公式ドキュメントも「どんな仕組みもすべての攻撃を完全に防げるわけではない」として、AIツールを使うときは常に良いセキュリティ習慣を保つよう求めています。そのうえで、シェルコマンドが触れるファイルやネットワークをOSのレベルで制限するサンドボックスとpermissionsを重ねる多層防御を勧めています。何をdenyに入れるべきかは、扱う情報、顧客との契約、業界の法令、社内規定によって変わります。会社で使う場合は管理者が組織全体の設定を配れるので、まず情報システムの担当者に確認し、必要に応じて弁護士などの専門家にも相談してください。本記事は一般的な考え方の整理で、法的助言ではありません。Codexを使っている方は、承認の考え方をCodexの承認モードの記事にまとめています。

よくある質問

permissionsのdenyとhooksは、どちらを先に設定すべきですか？

denyを先に設定してください。denyはsettings.jsonに1行書くだけで、どのモードでも効きます。hooksはプログラムを書いて保守する手間がかかるので、denyではすり抜けてしまう、中身を読まないと判定できない操作に絞って足すのが、みやっち🧑‍💻の運用です。

オートモードにしても、denyやaskは効きますか？

効きます。公式ドキュメントによると、オートモードでもallow・ask・denyに当てはまる操作は分類モデルより先にルールで決まり、askに当てはまる操作は確認が出ます。ただし、何でも実行できてしまう広いallowは、オートモードに入ると一時的に外されます。

allowは書かなくてもいいのですか？

モードを自動化寄りにしているなら、allowが0件でも作業は進みます。みやっち🧑‍💻の設定もallowは0件です。手動寄りのモードで、毎回聞かれる決まったコマンドだけを通したいときに、allowを足すと確認が減ります。

自分の業務のどこまでをAIに任せ、どこで止めるか。その線引きから一緒に考えたい方は、まず無料セミナーでお会いしましょう。

ブログ一覧へ戻るトップページへ戻る