Claude Code はファイルを書き換え、コマンドを実行する。だからこそ「これを実行していいか?」と途中で確認を取る仕組みが備わっている。本章では、その仕組みと、状況に応じた緩め方・締め方を見ていく。

確認されること・されないこと

すべての操作で確認が入るわけではない。

  • 確認なし ─ ファイルの読み取り、grep や ls などの読み取り専用コマンド
  • 確認あり ─ ファイルの作成・編集、bash コマンド (読み取り専用以外)、MCP ツールの呼び出し

「読むだけなら止めない、書く・実行するなら一度確認する」という設計である。

確認が出たときの選択肢

確認のダイアログには通常、おおむね次のような選択肢が並ぶ。

  • 許可する ─ この一回だけ許可する
  • 許可して、今後は聞かない ─ 同じ操作を今後も自動で許可する (例: npm test)
  • 拒否する ─ Claude は方針を変えて別のアプローチを試みる

「許可して、今後は聞かない」を選ぶと、その操作はプロジェクト単位で記憶され、次回以降は確認なしで通る。同じコマンドを繰り返す作業では、これを使うと中断が大幅に減る。

モードを切り替える

毎回確認するのが煩わしい場合 ─ もしくは逆に、より慎重に進めたい場合 ─ には、パーミッションモードを切り替える。

モード自動承認の範囲適した場面
default読み取りのみ。それ以外は確認通常 / 慎重に進めたい時
acceptEdits読み取り + 作業ディレクトリ内のファイル編集 + 一般的なファイル操作 (mkdir mv cp など)コードを書き続けるフェーズ
plan読み取りのみ。編集自体ができない変更前の調査・計画

CLI では Shift+Tab を押すと default → acceptEdits → plan を順に巡回する。現在のモードはステータスバーに表示される。VSCode 拡張の場合は、入力ボックス下のモード表示をクリックして切り替える。

acceptEdits は「自分でまとめてレビューするから、途中の確認はいらない」時に向いている。Claude が書き上げてから git diff で差分を一気に見る流れになる。plan は逆に、いきなり手を動かさせず、まず読み解いて計画だけ立てさせるためのモード。書き換えそのものを禁止する点で default とは性格が違う。

auto モード

これらに加え、auto モードという選択肢もある。Claude が何かを実行する前に、別の分類器モデルが「このアクションは危なくないか」を自動判定し、危ないものだけブロックする仕組みである。長時間タスクで「ほとんど反射的に許可を押している」状態を減らせる。

ただし auto モードには利用条件がある。

  • Max / Team / Enterprise / API プランのいずれか (Pro では使えない)
  • Claude Sonnet 4.6 以降、または Opus 4.6 以降のモデル
  • Anthropic API 経由 (Bedrock / Vertex 等は対象外)

研究プレビュー段階の機能のため、「一般的な方向は任せられるが、機密度の高い操作のレビュー代わりにはしない」というスタンスで使うのが推奨されている。

全部スキップするモード ─ 注意

bypassPermissions モード (起動フラグ --dangerously-skip-permissions も同じ) は、確認をすべてスキップする。Claude は止まらず、書きたいものを書き、実行したいものを実行する。

これは便利だが、危険でもある。ホストシステムに損害を与えられない隔離環境 ─ コンテナ、VM、devcontainer のような場所でしか使うべきではない。普段使いのマシンで安易に切ってはいけない。

「中断を減らしたい」が動機なら、まずは acceptEdits か auto モードで足りないかを試す。bypassPermissions を選ぶ場面は、本来かなり限定的である。

保護されたパス

どのモードを使っていても、特定の場所への書き込みには必ず確認が入る。リポジトリの状態や Claude 自身の設定が偶発的に壊れるのを防ぐ安全装置である。

  • .git / .vscode / .idea / .husky
  • .claude/ (ただし commands agents skills などのサブディレクトリは除外)
  • .gitconfig / .bashrc / .zshrc / .mcp.json / .claude.json など

これらは acceptEdits でも bypassPermissions でも止まる。覚えておくと「なぜここだけ確認が出るのか」と戸惑わずに済む。

監視は手放さない

仕組みがどれだけ整っていても、最終的に責任を取るのは自分である。Claude は便利な相棒だが、相棒も間違える。確認ダイアログを読まずに反射で許可を押し続けるなら、確認の意味は薄くなる。

逆に、毎回真剣にレビューできているなら、acceptEdits や auto モードに切り替えて手を緩めて構わない。緊張と弛緩を場面で使い分けるのがうまい付き合い方である。

次章では、確認が出てから「許可するかどうか」をどう判断するか、つまり Claude が示す変更内容の読み方について扱う。

参考情報