「自動承認にしておけば全部ラク」みたいな雑な使い方をすると、だいたいどこかで痛い目を見る。Claude Code は便利だが、便利さの芯にあるのは“どこまで勝手にやってよいか”の線引きだ。ここを曖昧にしたまま走らせると、ファイルを思った以上に触られたり、確認待ちで手が止まったりする。
権限モードを理解する意味は単純で、Claude Code に任せる作業と、人間が止める作業を分けることにある。ファイル整理でも、文章作成でも、コード修正でも同じだ。雑に広く許すより、最初に少しだけ考えておいたほうが、後でやり直しが減る。
まず押さえるべきなのは、Claude Code は「提案だけする」道具ではない、という点だ。ターミナル上で実際にコマンドを走らせ、ファイルを読むだけでなく、書き換えもする。だから権限モードは、AI の賢さとは別に、実行の自由度を調整するための装置だと思っておけばいい。
ざっくり言うと、考え方はこうなる。
この三段階をどう使い分けるかが本題だ。Claude Code には、自動承認の強さを変える設定がある。名前や細部は環境や版で変わることがあるので、手元では docs.claude.com を見て確認したほうがいい。ただ、実務で大事なのは名称そのものではなく、「どの種類の操作まで自動で通すか」という考え方だ。
典型的には、読み取り中心の作業は通しやすい。たとえば、プロジェクト内のファイルを探す、内容を読む、差分を見る、といった処理だ。逆に、削除、上書き、移動、外部への送信、パッケージの導入、シェルでの危ない一括処理は、止めたほうがいい場面が多い。ここを混ぜると事故る。
実際の使い分けは、こんなふうに考えるとわかりやすい。
読むだけの作業
- ファイル一覧を確認する
- 内容を要約する
- 差分を読む
人間が見たほうがいい作業
- ファイルを削除する
- 既存ファイルを上書きする
- まとめて名前を変える
- 複数箇所へ一括反映する
- 依存関係を追加・更新する
非エンジニアの用途でも、この線引きはそのまま効く。たとえば、散らかった書類フォルダを整理したいなら、最初は「中身を見て重複候補や古い資料を挙げる」ところまで自動化していい。だが、実際に削除する段階は確認を挟んだほうがいい。人間のほうが「この PDF は請求書の控えだから残す」といった文脈を持っているからだ。
筆者は、最初にここを甘く見て、まとめて名前を変える作業をかなり大胆に任せたことがある。結果、命名規則はきれいになったのに、あとで参照していたメモやリンクが崩れて、結局手で戻した。差分は小さく見えても、実際に使っている側の参照先まで見ていないと意味がない。自動承認は、作業の見た目を整える力が強いぶん、関係ないところを壊す危険もある。
Claude Code を使うときは、依頼文の書き方でも権限モードの効き方が変わる。あいまいに「整理して」とだけ言うと、相手は勝手に動く余地を広く取る。そうではなく、先に境界を言うのが筋だ。
このフォルダの中身を確認して、重複しそうなファイルと古そうなファイルを候補として挙げてください。
削除はしないでください。最後に、人間が確認すべき順番で一覧にしてください。
このディレクトリ内のMarkdownファイルを読み、見出し構成だけを整理してください。
本文の書き換えはしないでください。変更案は差分で示してください。
こう書くと、承認の要否以前に、Claude Code にやらせていい範囲がはっきりする。権限モードだけに頼るより、指示文でブレーキをかけたほうが事故は減る。ここをサボると、確認ダイアログが出るたびに「え、そこまでやるのか」と毎回驚く羽目になる。
設定を触れるなら、まずは「自動で通す範囲を狭める」側から始めるのがいい。特に、初めて触るディレクトリ、仕事の共有フォルダ、外部に影響する環境では、最初から強い自動承認に寄せないほうがいい。慣れてきたら、読み取り中心の作業だけ広げる。逆順にすると、だいたい雑になる。
注意したいのは、権限モードを上げると Claude Code が賢くなるわけではないことだ。承認が通りやすくなるだけで、指示が雑なら結果も雑だ。しかも、自動承認が強いほど、間違った方向に進んだときの被害が大きい。コンテキストの中で「今どのファイルを触っているか」が見えにくくなると、差分の肥大化も起きやすい。小さく確認しながら進めたほうが、結局は速い。
ファイル整理での実用例をもう少し具体的に書く。たとえば、ダウンロードフォルダにPDFや画像が散乱しているなら、最初の依頼はこうでいい。
このフォルダをスキャンして、種類ごとに候補を整理してください。
実際の移動や削除はしないで、一覧だけ出してください。
重複候補があれば、その理由も短く添えてください。
この段階では自動承認を強くしなくても進められる。次に、一覧を見て人間が判断する。最後に、必要なら移動だけを任せる。削除まで一気に走らせない。ここを分けるだけで事故率がかなり下がる。
コード作業でも同じだ。読み取り、差分提案、限定的な編集、実行の順に分ける。もしテストやビルドを走らせるなら、そのコマンドが何を触るかを先に確認する。自動承認を広げると、便利な反面、いつの間にか「確認しないで実行されたこと」が増える。これは地味に怖い。
実務では、次の運用がいちばん安定する。
1. まず読み取り中心で進める
2. 編集は小さな単位に区切る
3. 削除・上書き・移動は確認を挟む
4. うまくいく作業だけ、自動承認の範囲を少し広げる
この順番を守ると、Claude Code が「勝手にやりすぎる道具」ではなく「任せられる範囲を増やしていく道具」になる。最初から全部許すのではなく、使いながら安心できる領域を増やす。これがまともな運用だ。
最後に、迷ったときの基準を置いておく。対象が戻せる作業か、影響がそのフォルダ内で閉じるか、人間が見ないと意味が変わるか。この三つのうち一つでも怪しければ、自動承認は絞るべきだ。逆に、読むだけ、比較するだけ、提案するだけなら、広げてもいい。
権限モードは、安心のための飾りではない。Claude Code を速くするためのものでもあるが、雑に速くするためのものではない。どこまで許すかを先に決める人ほど、最後に手が止まらない。自動承認は、広げる前に絞る。そのほうが、結局ちゃんと使える。