「Auto Mode にしておいたら、触ってほしくないファイルまで書き換わっていた」「逆に、毎回 yes/no を押すのが面倒で結局誰も使わなくなった」といった声は、Claude Code を現場に入れ始めた管理職から最近よく聞く相談です。
便利さと事故の距離が近いツールほど、「どこまで任せるか」を決める作業を後回しにすると現場が止まります。本記事では、Claude Code の Permissions と Auto Mode を、単なる禁止リストではなく「境界設計」として捉え直し、任せる範囲を意思決定するためのフレームを整理します。受託開発の現場で、PM やテックリードがエンジニアと合意するときに使える形に落としました。
なぜ Permissions を「禁止リスト」で考えると失敗するのか
Permissions の設定をエンジニアに任せると、多くの現場で「とりあえず危なそうなコマンドを deny に並べる」運用になりがちです。この方法がうまくいかないのには、主に3つの理由があります。
- 禁止リストは漏れる：危ないコマンドは無限に発見されるので、後追いで追加し続けることになります。
- 承認疲れを起こす：ask が多すぎると、人間が中身を見ずに yes を押すモードに入ります。これは「許可している」のと同じです。
- 責任の所在がぼやける：誰がどの判断で許可したかが残らず、事故が起きたときに「Claude が悪い」で止まります。
代わりに「Auto Mode で任せる量と、チームが背負うリスクの量は比例する」という発想に切り替えることが重要です。任せる範囲を増やすほど開発は速くなりますが、同時に「人間が見なくても安全」と保証する設計の重さも増えます。Permissions は、この、任せる量とガード強度のバランスを可視化する仕組みだと考えると、設計の優先順位が見えてきます。
任せる範囲を決める3つの軸
実際に Permissions を引くときは、コマンド単位で考える前に、まず「作業をどの軸で分類するか」を先に決めます。私たちが現場で整理をお手伝いする際は、次の3つの軸を用いています。
軸1：信頼境界（自分のリポジトリと外部リソース）
ローカルの作業ツリー内で完結する操作と、外部に副作用を残す操作は別物です。前者は基本 allow で問題ありませんが、後者は ask 以上にすべき領域です。
- 自リポジトリ内のファイル編集・テスト実行 → allow 候補
git pushやgh pr merge、本番DBへの接続、外部APIへの書き込み → ask または deny
「ローカルで何が起きても git で戻せる」かどうかが、判断のラインです。
軸2：影響範囲（自分・チーム・顧客）
同じファイル編集でも、誰に跳ね返るかで重みが違います。
- 自分のブランチ：allow で速度を出す
- チームの共有ブランチ・CI 設定・依存関係（
package.json、ロックファイル）：ask - 本番設定・顧客に出す成果物・契約に紐づくドキュメント：deny を基本
ここを曖昧にすると、Auto Mode が深夜に依存バージョンを上げて翌朝チームが詰まる、という典型的な事故が起きます。
軸3：取り返しのつきやすさ
リカバリー可能性で最後に押さえます。
- 履歴で戻せる（
git、IDE の undo）：allow に寄せてよい - 戻すのに人手がかかる（メール送信、外部 webhook、課金API）：ask 以上に固定
- 戻せない（本番DELETE、外部公開）：deny で機械的に止める
3軸はすべて「人間が後から修復できるか」に収束します。Permissions は技術設定ではなく、「事故が起きたときに、誰がどれだけ時間を使って復旧するのか」を先に合意する作業なのです。
allow / ask / deny の運用テンプレート
3軸で分類したあとは、Permissions を3階層で持つのが運用しやすい形です。受託開発の現場では、私たちは次の雛形をたたき台にすることが多いです。
allow（Auto Mode で動かしてよい）
- 自リポジトリ配下にあるファイルの読み書き
npm testやpytestなどのテスト実行- ローカルでの型チェック・lint
- 一時ディレクトリ（
tmp/）への書き込み
これらは「壊れても git で戻せる」「結果が手元で完結する」操作群です。Auto Mode の価値は、ここを止めずに走らせ続けられる点にあります。
ask（人間の確認をはさむ）
git commitやブランチ作成- 依存ファイル（
package.json、requirements.txt、ロックファイル）の更新 - 環境変数の追加・変更
- マイグレーションSQLの実行
- 共有ブランチへの push
ここは Auto Mode の「速度」を捨てて、変更内容を人間が読む時間を確保するための領域です。承認疲れを避けるため、ask の数は意図的に絞ります。
deny（Claude Code には実行させない）
- 本番環境への接続全般
- 鍵情報を含むファイル（
.env、*.pem、credentials.json）の読み書き rm -rf、git push --force、git reset --hard origin/...- 外部APIで課金が発生するエンドポイントへの直接コール
- 顧客成果物の最終ファイル（契約書類・納品物）の自動編集
deny に並ぶのは「事故ったら金銭・契約・信頼に跳ねる」操作です。コマンド単位ではなく、「この操作は必ず人間がキーボードで打つ」と決めた領域だと整理すると、エンジニアにも説明しやすくなります。
3階層を実際の .claude/settings.json に落とすと、次のような形になります。
{
"permissions": {
"allow": [
"Bash(npm test:*)",
"Bash(npm run lint:*)",
"Bash(npx tsc --noEmit)",
"Bash(git diff:*)",
"Bash(git status)",
"Write(src/**)",
"Write(tmp/**)"
],
"deny": [
"Bash(git push --force:*)",
"Bash(git reset --hard:*)",
"Bash(rm -rf:*)",
"Read(.env*)",
"Write(.env*)",
"Write(*.pem)",
"Bash(psql *production*:*)"
]
}
}allow に明示したコマンドは Auto Mode でそのまま実行され、deny に一致するコマンドはセッション中に実行要求が来ても即座に拒否されます。allow にも deny にも含まれない操作は、実行前に確認（ask）が入ります。
Auto Mode を安全に走らせる4つのガード
allow を広げる前提として、Auto Mode の周りには、次の4つのようなガードを必ずセットで設けておきましょう。
- 作業ディレクトリの隔離：本番系リポジトリと検証用 worktree を物理的に分ける。Auto Mode は検証用でしか走らせない、というルールから始めると事故が激減します。
- 差分を必ず人間がレビューする経路を残す：commit は ask に置き、PR の段階でエンジニアが目を通します。AI生成コードはレビュー観点があらかじめ揃っていないと素通りしやすいので、チームでチェックリストを用意しておきます。
- CI で物理的に止める：lint・型・テスト・依存ライセンスチェックを CI に積んでおき、Auto Mode が暴走しても merge までに必ず引っかかる状態を作ります。
- ログと再現性の確保：Auto Mode が実行したコマンドと差分は、後から追えるようにリポジトリ内（または会話ログ）に残します。事故対応の起点になります。
ガードがない状態で allow だけ広げるのは、ブレーキを外したまま速度だけ上げるのと同じです。「allow を1段階広げるなら、ガードも1段階強くする」と決めておくと、現場の合意が早くなります。
段階導入：いきなり全社で Auto Mode に振らない
境界設計ができても、最初から全社統一の Permissions を配るのはおすすめしません。導入は、例えば次の3段階で広げていくのが現実的です。
- 個人開発者の手元（1〜2週間）：allow を狭めにして、Auto Mode の挙動と承認疲れの感覚をつかむ。
- 小さいチーム単位（1〜2ヶ月）：チームで合意した allow/ask/deny セットを共有し、事故と「便利さ」の両方を棚卸しする。Permissions ファイルはリポジトリ管理にし、変更履歴を残します。
- 組織標準として展開：プロジェクト種別（受託 / 内製 / R&D）ごとにテンプレートを用意し、新規プロジェクト立ち上げ時に選ぶだけにする。
各段階で重要なのは、「禁止しすぎて使われない」状態と「許可しすぎて事故る」状態の中間点を、現場の声を聞きながら調整していくサイクルを回すことです。チーム導入の流れ全体はClaude Code が社内で使われない3つの原因｜定着させる3段階フレームで扱っています。
管理職が最後に押さえる視点
Permissions と Auto Mode の境界設計は、技術設定の話に見えて、本質は「どこまでをチームの責任として引き受けるか」という意思決定です。エンジニアに丸投げせず、PM や管理職が最終ラインを引く必要があります。具体的には、
- deny に並ぶ項目を、自分の言葉で経営や顧客に説明できるか
- Auto Mode の事故が起きたとき、誰が一次対応に入る体制になっているか
- 半年後、allow を広げる判断は何をもって行うか
この3点を、Permissions 設定とセットで言語化しておくことをおすすめします。PMが Claude Code を使うときの全体的な線引きはPMがClaude Codeを使うときの3ルールもあわせてご覧ください。
まとめ
- Permissions は禁止リストではなく、「任せる量＝リスクの量」を可視化する境界設計として捉える。
- 任せる範囲は、信頼境界・影響範囲・取り返しのつきやすさの3軸で分類する。
- 運用は allow / ask / deny の3階層に落とし、ask は承認疲れしないよう意図的に絞る。
- Auto Mode は4つのガード（隔離・人間レビュー経路・CI・ログ）とセットで運用する。
- 全社一斉ではなく、個人 → チーム → 組織標準と3段階で広げる。
Claude Code を「便利だけれど怖いツール」から、「安全に任せられる戦力」へ変えるための鍵は、コマンドを覚えることではなく、任せる範囲を設計する力にあります。テックエイドでは、AI を組み込んだ受託開発チームの運用設計を、講座と現場支援の両面でサポートしています。
AI・開発生産性のオンライン講座一覧はこちらから、Permissions 設計や AI 運用ルール作りにそのまま使える講座をご確認ください。