権限モードとは何か、なぜ一度で決めておくのか
権限モードは、毎回確認しなくても Claude Code が何を実行してよいかを一度だけ決めておく設定だ。Claude Code はファイルの読み書き、ターミナルコマンドの実行、パッケージのインストールといった実作業を行うが、動作ごとに「これをやってよいか」を尋ねると、長い作業ほど承認のために張り付くことになる。権限モードはその基準を先に一度決め、安全な範囲では尋ねずに進めさせる。
設定は簡単だ。Claude Code の画面で shift を押しながら tab を押すとモードが順に切り替わる。manual、acceptEdits、plan、auto の四つがこの巡回で移り変わり、今どのモードかは画面下のステータスバー（status bar）に表示される。残り二つ（dontAsk、bypassPermissions）は無人実行や隔離環境などの特殊な場合に使う。
肝心なのは「モードを仕事に合わせる」ことだ。一行ずつ変更を目で確かめたい序盤はよく尋ねるモードが安全で、方向が定まり反復作業だけになれば、あまり尋ねないモードが速い。以下では六つのモードを「どこまで自動で許可するか」の順に見ていく。
| モード | 自動で何をするか | いつ使うか |
|---|---|---|
| manual | 読み取りのみ。ほかは毎回尋ねる | 一動作ずつ確認して慎重に進めるとき |
| acceptEdits | 読み取り + ファイル編集 + よくあるファイルシステム系コマンド | コードを繰り返し直し、あとでまとめてレビューするとき |
| plan | 読み取り・調査・提案のみ。編集はしない | 実行前にまず計画を受け取りたいとき |
| auto | すべて実行しつつ分類器が危険動作を事前に遮断 | 手を離して任せる既定 |
| dontAsk | 事前承認したツールのみ。ほかは静かに自動拒否 | CI・夜間バッチなど承認する人がいないとき |
| bypassPermissions | すべてのチェックを飛ばす | 隔離されたコンテナ・VM の中でのみ |
毎回尋ねる側 — manual と plan
manual は最も保守的なモードだ。Claude Code は読み取りだけを尋ねずに許可し、ファイルの編集やコマンドの実行など、それ以外のすべての動作は実行前に人の確認を受ける。何が変わるかを一つずつ目で見て承認したいとき、あるいは不慣れなコードベースを慎重に扱うときに向く。
plan（プランモード）も読み取りのみだが目的が違う。plan はコードを調査し「何をどう変えるか」の計画を立てて提案するだけで、実際にはファイルを編集しない。大きな作業を始める前に Claude にまずコードを見渡させて実行計画を出させ、それを読んでから方向づける用途だ。計画が緻密なほど、実行時にずれる余地は減る。
レビューを後回しにする側 — acceptEdits
acceptEdits は読み取りとファイル編集、そしてよく使うファイルシステム系のターミナルコマンドまで尋ねずに進める。Claude がコードを直す間、毎回承認ボタンを押す必要なく流れが続き、人は結果が出たあとにまとめて確認する。
だから acceptEdits は「今は速く反復し、レビューは後で」という進め方に合う。すでに方向が定まったコードを何度も磨くときに特に効率的だ。ただし編集を事後に確認する仕組みなので、変わった内容を後で必ず見返すことが前提になる。
手を離す既定 — auto モードと分類器
手を離して任せる場面でまず考えるモードは auto だ。auto モードでは Claude は人に尋ねずに動作を実行するが、その手前で別個の分類器モデル（classifier）が各動作を実行直前に審査する。危険と判断した動作だけを遮り、残りの日常的な作業はそのまま通す。つまり「すべて自動」でありながら、危険なものだけを選んで止める仕組みだ。
分類器が止めるのは「要求の範囲を超えて話を大きくする」動作だ。たとえば本番環境へのデプロイやデータベースのマイグレーション、強制プッシュ（force push）、ダウンロードしたコードをそのままシェルにパイプして実行すること、機微なデータを外部エンドポイントへ送ること、セッションに必要なファイルを消してしまうことなどだ。逆に通すのは日常作業で、プロジェクト内のローカル編集、ロックファイル（lockfile）に記載された依存関係のインストール、読み取り専用のリクエスト、自分のブランチへのプッシュなどだ。
auto は shift+tab 巡回の最後にあり手軽に入れられ、ステータスバーで今 auto かを確認できる。「手を離す既定」と呼ぶ理由は、人が張り付いて承認しなくても、危険な境界だけは分類器が守るからだ。
分類器の盲点と stop hook
auto の分類器には明確な限界がある。分類器は意図を守るだけで、コードが実際に正しく動くかは見ない。たとえば Claude に認証ロジックをリファクタリングさせて、結果が壊れた認証コードでも、分類器はそれをそのまま通す。「壊れている」ことは「危険」ではないからだ。
だから auto はテストを走らせる stop hook と併用するのが定石だ。stop hook は Claude が一区切りの作業を終えた時点で自動的に走る検査で、そこにテスト実行を仕込んでおけば、auto が「何をしようとしているか（意図）」を守る間、hook が「コードが実際に動くか（正しさ）」を確認する。意図は分類器、正しさは hook が分担する形だ。
auto のガードレールはまだ発展途上で、何を止め何を許すかのリストは変わり続ける。実際に auto を使うときは、公式ドキュメントで現在の遮断・許可リストを確認するとよい。
{
"hooks": {
"Stop": [
{ "hooks": [ { "type": "command", "command": "npm test" } ] }
]
}
}無人パイプラインは dontAsk、隔離環境は bypassPermissions
dontAsk は人が承認できない自動化の場面のためのモードだ。あらかじめ承認したツールだけ実行を許し、そのリストにない動作は人に尋ねずただちに自動拒否する。CI パイプライン、予約ジョブ、夜通し走るバッチのように傍に人がいない状況で、誰も押さない承認ウィンドウに引っかかって止まる代わりに、パイプラインを流し続ける。
bypassPermissions はすべてのチェックを飛ばす。Claude Code の「危険を承知で権限確認を飛ばす」（dangerously-skip-permissions）設定と同じで、分類器も承認もなく何でも実行する。それだけ危険なので、隔離されたコンテナや仮想マシン（VM）の中でのみ走らせるべきだ。実際の作業環境で常時使うモードではない。
結論 — モードを仕事に合わせる
権限モードはいくつもあるが、毎日使うものは shift+tab 巡回で届く。手を離す既定は auto で、その安全は二重に守られる。動作の実行前には分類器が意図を検査し、一区切りの終わりには stop hook がコードが実際に動くかを確認する。
傍に承認する人がいない無人パイプラインは dontAsk が担い、すべてのチェックを飛ばす bypassPermissions は隔離されたコンテナと VM の中だけで使う。結局は一つに畳まれる。どこまで手を離すかを度胸ではなく仕事に合わせて決め、その仕事に合う権限モードを選べばよい。