背景

この連載では、Claude Codeの公式ドキュメントを1ページずつ読み解いていきます。公式ドキュメントは情報が網羅されている分、「結局どの機能を、どんな場面で使えばいいのか」は自分で考える必要があり、読むのに意外と時間がかかります。そこで、私が実務で使うために読み込んだ内容を「使う場面→実例コード」の順に整理して残していくことにしました。専門家の解説というより、一次情報を読んだ記録です。推測や動作を確認していない部分には、その都度そう書きます。

1. これは一言でいうと何か

Claude がファイルを編集したりシェルコマンドを実行したりする前に、一時停止して承認を求めます。権限モードは、その一時停止がどのくらいの頻度で起きるかを制御する設定です。

選ぶモードがセッションの流れをそのまま決めます。デフォルトなら来るたびにレビューし、緩いモードなら Claude が中断なく長く作業して完了時に報告します。機密作業では監視を強め、方向性を信頼できる場面では中断を減らす、という使い分けになります。

2. どういう場面で役立つか

まず6つのモードを、確認なしで実行される範囲で並べます。

モード	確認なしで実行されるもの	最適な用途
default	読み取りのみ	開始、機密作業
acceptEdits	読み取り、ファイル編集、一般的なファイルシステムコマンド（mkdir、touch、mv、cp など）	レビュー中のコードの反復処理
plan	読み取りのみ	コードベースの探索、変更前
auto	すべて、バックグラウンド安全チェック付き	長時間タスク、プロンプト疲労の軽減
dontAsk	事前承認済みツールのみ	ロックダウン CI とスクリプト
bypassPermissions	すべて	隔離されたコンテナと VM のみ

具体的な場面に落とすとこうなります。

• エディタや git diff で後からまとめてレビューしたい：acceptEdits。1編集ずつ承認する代わりに、作業ディレクトリ内の編集を通します。
• 大きな変更の前に方針を固めたい：plan。読み書きせず調査と提案だけを行い、計画を承認した時点で指定した権限モードに切り替わって実装が始まります。
• CI やスクリプトで完全に非対話にしたい：dontAsk。プロンプトが出る呼び出しはすべて自動的に拒否され、permissions.allow と読み取り専用 Bash コマンドだけが通ります。

向かないケース・使ってはいけないケース。

1. bypassPermissions を通常の開発環境で使うのは避けてください。ドキュメントは「Claude Code がホストシステムに損害を与えられない隔離環境でのみ」と限定しています。プロンプトインジェクションや意図しないアクションに対する保護を提供しません。
2. auto を機密操作のレビュー代わりにするのも想定外の使い方です。研究プレビューであり、「プロンプトを減らしますが安全性を保証しません」と明記されています。一般的な方向性を信頼できるタスク向けです。
3. 権限プロンプトは残したまま自律性だけ上げたいなら、モードではなくプロアクティブ出力スタイルを設定します。

3. コード・コマンドの実例と解説

前提条件

• Shift+Tab でサイクルできるのは default → acceptEdits → plan だけです。auto はアカウントが要件を満たす場合に、bypassPermissions は有効化フラグ付きで起動した後に現れます。dontAsk はサイクルに一度も現れず、フラグでのみ設定します。
• モードは設定コントロールで決めるもので、チャットで Claude に頼んで変えるものではありません。
• モードはベースラインです。上に権限ルールを重ねて個別のツールを事前承認・ブロックします。拒否ルールと明示的な確認ルールは bypassPermissions を含む全モードで効きますが、許可ルールは全部承認済みのモードでは意味を持ちません。

起動時にモードを指定する

claude --permission-mode plan

セッションを計画モードで開始します。acceptEdits、dontAsk、bypassPermissions も同じ書式です。同じフラグは -p の非対話的実行でも機能します。なお bypassPermissions は、有効化フラグ付きで起動したセッションから入ることはできず、再起動が必要です（--dangerously-skip-permissions は同等のフラグです）。

既定のモードを設定する

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

設定ファイルに置くと、毎回フラグを渡さずに済みます。プロジェクトの .claude/settings.json に "defaultMode": "plan" を書けば、チーム全体の既定を計画モードにできます。

ここにセキュリティ上の重要な例外があります。Claude Code v2.1.142 以降は、.claude/settings.json と .claude/settings.local.json の auto を無視します。リポジトリが自分自身に自動モードを付与できないようにするためです。自動モードを既定にしたいなら ~/.claude/settings.json に書きます。

自動モードで何がブロックされるか

自動モードでは、別の分類器モデルがアクション実行前にレビューします。既定でブロックされるのは、curl | bash のようなコードのダウンロードと実行、機密データの外部送信、本番へのデプロイとマイグレーション、クラウドストレージでの大量削除、IAM やリポジトリ権限の付与、フォースプッシュや main への直接プッシュ、git reset --hard や git clean -fd のような未コミット変更を破棄する操作などです。

逆に既定で許可されるのは、作業ディレクトリ内のローカルファイル操作、ロックファイルやマニフェストで宣言済みの依存関係インストール、.env を読んで一致する API に認証情報を送ること、読み取り専用 HTTP リクエスト、開始したブランチや Claude が作成したブランチへのプッシュです。

会話で述べた境界も、分類器はブロック信号として扱います。 「プッシュしないで」と言えば、既定ルールが許す場合でも一致するアクションがブロックされます。ただしこれはルールとして保存されず、毎回トランスクリプトから読み直されるため、コンテキストのコンパクションでそのメッセージが消えると境界も失われます。確実に止めたいなら拒否ルールを使ってください。

Bedrock / Vertex AI / Foundry で自動モードを有効にする

{
  "env": {
    "CLAUDE_CODE_ENABLE_AUTO_MODE": "1"
  }
}

これらのプロバイダーでは、既定で自動モードが Shift+Tab サイクルに現れません。~/.claude/settings.json の env ブロックに追加すると有効になります（v2.1.158 以降）。組織全体なら同じブロックを管理設定に置きます。管理者側は disableAutoMode を "disable" にすればロックオフでき、こちらが有効化変数を上書きします。

root では起動を拒否される

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

Linux と macOS では、bypassPermissions で root や sudo 下で実行しようとすると Claude Code は起動を拒否します。コンテナで自律的に走らせたいなら、非 root ユーザーで動く dev container 設定を使ってください。

その他（VS Code / JetBrains / Desktop / Web・モバイルでの切り替え方法とラベル対応、Ultraplan、showClearContextOnPlanAccept、分類器の決定順序とサブエージェント3段階チェック、コストとレイテンシ、claude auto-mode defaults、保護されたファイルの完全な一覧）は公式ドキュメントを参照してください。

4. まとめと次回予告

• モードは「確認の頻度」を決めるベースライン。上に許可・拒否ルールを重ねて調整します。
• Shift+Tab で回るのは3つだけ。auto と bypassPermissions は条件付き、dontAsk はフラグ専用です。
• bypassPermissions は隔離環境専用。プロンプトを減らしたいだけなら auto が本来の選択肢です。

最も実務で効くのは「保護されたパス」の存在です。 bypassPermissions を除くすべてのモードで、一部のパスへの書き込みが自動承認されることはありません。リポジトリ状態と Claude 自身の設定を偶発的な破損から守る仕組みです。

対象は .git、.vscode、.idea、.husky、.cargo、.devcontainer などのディレクトリ（.claude も含みますが、Claude が worktree を置く .claude/worktrees は除外）と、.gitconfig、.bashrc や .zshrc などのシェル設定、.npmrc・.yarnrc などのパッケージ設定、.mcp.json、.claude.json といったファイル群です。

ここで見落としやすい挙動が1つあります。 permissions.allow に Edit(.claude/**) のようなルールを書いても、保護されたパスへの書き込みは事前承認されません。安全性チェックが allow ルールの評価より先に走るためです。モード別の結果は、default / acceptEdits / plan ならプロンプト表示、auto なら分類器へルーティング、dontAsk なら拒否、bypassPermissions なら許可、と決まっています。プロンプトが出るモードでは「このセッション中は Claude に自身の設定編集を許可する」選択肢が提示されます。

次回予告：モードの上に重ねる allow / ask / deny ルールを扱う「権限」を取り上げます。

関連ページ（本記事で触れた概念の詳細）：allow / ask / deny ルールと管理ポリシー →「権限」、分類器に信頼できるインフラを教える →「自動モードを設定する」、PreToolUse と PermissionRequest によるカスタム権限ロジック →「Hooks」、ブラウザベースの計画レビュー →「Ultraplan」、Bash の隔離 →「サンドボックス化」、-p 実行 →「非対話的モード」。

---

本記事は執筆時点の公式ドキュメント（権限モードを選択する）に基づきます。最新は公式ドキュメントをご確認ください。