Claude Code の承認を減らす方法: 承認スキップ・自動承認の設定と安全な使い方

Claude Code に作業を任せると、ファイルの編集やコマンドの実行のたびに「実行してよいですか」と確認が出ます。1日に何十回も続くと、中身を読まずに「はい」を押すようになります。いわゆる承認疲れです。確認を減らしたいと考えるのは自然で、公式ドキュメントにも何段階かの仕組みがあります。ただ、いちばん手前に見える Claude Code 承認スキップ（確認をすべて飛ばす設定）は、いちばん安全でない方法でもあります。

この記事では、確認が出る理由、権限モード、allow と deny のルール、サンドボックス、承認スキップのリスクと安全な使い方、そして確認を1か所でまとめて処理する方法を説明し、最後に Codex の承認設定にも触れます。内容は、2026年10月7日に確認した Anthropic と OpenAI の公式ドキュメントに基づいています。Windows マシンでは claude --help で6つのモード名（acceptEdits、auto、bypassPermissions、manual、dontAsk、plan）と --dangerously-skip-permissions を、codex --help で --sandbox と --ask-for-approval を確かめました（Claude Code 2.1.280、Codex CLI 0.160.1）。設定ファイルの書き換えやセッションの実行は、していません。

なぜ Claude Code は確認を求めるのか

Claude Code は、作業ディレクトリの中でファイルを読むだけなら確認しません。確認が出るのは、コマンドの実行、ファイルの変更、Web の取得や検索のような、外に影響しうる操作です。Manual モードでの扱いは次のとおりです。

確認は、間違った削除、意図しない外部への通信、読み込んだ文書に仕込まれた指示（プロンプトインジェクション）に従った操作を、実行の前に止めるための仕組みです。権限のルールを強制しているのはモデルではなく Claude Code 本体なので、プロンプトや CLAUDE.md に「確認せずに実行して」と書いても、許可の範囲は変わりません。範囲を変えられるのは、/permissions、ルール、権限モード、PreToolUse フックです。

権限モードを使い分ける

実行中のセッションでは Shift + Tab でモードが切り替わります。dontAsk はサイクルに入らず、--permission-mode dontAsk で指定します。bypassPermissions は、--permission-mode bypassPermissions か --dangerously-skip-permissions で起動したときだけ入れます。起動時にモードを決めるにはフラグを使い、毎回同じモードで始めたいなら %USERPROFILE%\.claude\settings.json に defaultMode を書きます。

claude --permission-mode plan

{
  "permissions": {
    "defaultMode": "default"
  }
}

プロジェクトの .claude/settings.json や .claude/settings.local.json に "bypassPermissions" を書いても反映されず、Manual で始まります。"auto" も同じです。リポジトリに入っている設定ファイルだけで、承認スキップのセッションが始まらないようになっています。

acceptEdits と plan と dontAsk

acceptEdits は、作業ディレクトリの中のファイル編集と、mkdir、touch、rm、rmdir、mv、cp、sed を確認なしで通します。それ以外のコマンドや、ディレクトリの外への書き込みは、今までどおり確認が出ます。編集の確認だけが煩わしい人に向きます。plan は、ソースを編集させずに調べて計画だけを作らせるモードで、Shift + Tab か、プロンプトの先頭の /plan で入ります。方針を先に固めておけば、あとの確認が減ります。dontAsk は、許可したツール以外を聞かずに拒否するので、人がいない環境で何が動くかをあらかじめ決められます。

auto：別のモデルが審査する

auto は、確認を減らしながら無防備にはしない、という位置づけのモードです。実行の前に、分類用の別のモデルが操作を確認し、依頼の範囲を超える操作や、読み込んだ内容に誘導されたと思われる操作を止めます。公式ドキュメントによると、次のような操作は既定でブロックされます。

• curl | bash のような、ダウンロードしたコードをそのまま実行する操作
• 機密データの外部への送信、本番へのデプロイ、force push
• git reset --hard や git clean -fd のような、未コミットの変更を捨てる操作
• --dangerously-skip-permissions を付けて別のエージェントを起動すること

一方で、作業ディレクトリ内の読み取りと編集は、審査を通らずそのまま実行されます。作業中のリポジトリへの push も確認なしで通るので、push の前に自分で確認したいなら、次の節の ask ルール（Bash(git push *)）を使ってください。分類器が同じ種類の操作を連続3回、または合計20回ブロックすると、auto は一時停止して確認に戻ります。auto には対応モデルが必要で、Haiku と古いモデルは対象外です。v2.1.283 以降の既定が auto なので、Claude Code を更新した人は、気づかないうちに auto で動いているかもしれません（設定ファイルで別の defaultMode を指定していれば、その指定が残ります）。画面下のステータスバーの ⏵⏵ auto mode on で確認できます。公式ドキュメントには次の注意書きがあります。

原文：Auto mode reduces permission prompts but does not guarantee safety. Use it for tasks where you trust the general direction, not as a replacement for review on sensitive operations.

方向性を信頼できる作業には向きますが、重要な操作のレビューの代わりにはなりません。

自動承認の設定：allow と deny のルールで絞る

モードを緩めずに承認を自動化する方法が、ルールです。セッション中に /permissions を実行すると、現在のルールと、どの settings.json から来たかが表示され、ここで追加も削除もできます。ルールは allow（確認なしで実行）、ask（毎回確認）、deny（禁止）の3種類で、評価は deny、ask、allow の順です。deny はどの設定ファイルに書いてあっても効き、allow では覆せません。書式は Tool(specifier) で、Bash では * が空白を含む任意の文字列に当てはまります。公式ドキュメントの例を組み合わせると、次のようになります。

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(npm test *)",
      "Bash(git commit *)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)"
    ]
  }
}

この設定では、npm のスクリプトとコミットは確認なしで動き、push は毎回確認され、.env と secrets フォルダの読み取りは禁止されます。ask ルールは auto モードでも確認を強制します。Windows では、パスが POSIX 形式に直されてから照合されるので、C ドライブ全体の .env は Read(//c/**/.env) と書きます。

ルールには、知っておくと迷わない決まりがいくつかあります。&& や ; でつないだコマンドは、各部分がそれぞれルールに当てはまる必要があります。プロジェクトの .claude/settings.json に入っている allow ルールは、そのフォルダの「信頼」ダイアログを承認するまで使われません。他人のリポジトリを開いたとき、勝手に許可が増えない仕組みです。deny と ask は制限するだけなので、この制約を受けません。また、bypassPermissions では allow ルールは効きませんが、deny ルールは効きます。

確認なしで許可してよいコマンド

以下は、公式の例を踏まえた私たちの目安です。許可してよいのは、結果が読み取りか、やり直せる変更にとどまり、対象が決まっているコマンドです。

• 許可しやすい：テストやビルド（npm test、npm run *）、状態を見る git（git log *）、ローカルへのコミット（git commit *）。
• 毎回確認したい：push、デプロイ、パッケージのインストール、外部への通信。
• 禁止したい：.env や認証情報の読み取り、rm の広い指定。
• 広く許可しない：Bash(*) や Bash(python*) のような任意のコードを通すルール、Bash(git *) のようにすべてのサブコマンドを通すルール。npx や docker exec の後ろに何が来ても通してしまうルールも避けます。

Bash のルールは、Claude が書いたコマンドの文字列に対する照合です。Bash(curl *) を deny にしても、/usr/bin/curl や sh -c 'curl ...' は止まりません。公式ドキュメントも、Bash の deny はセキュリティの境界ではないとしています。確実に止めたいなら、OS レベルで制限するサンドボックスか、PreToolUse フックを使います。また、ルールで許可しても、.git や .claude などの保護パスへの書き込みは事前承認になりません。

サンドボックスは、ネイティブ Windows では動かない

Claude Code のサンドボックスは、シェルコマンドが触れるファイルとネットワークを OS の機能で制限します。公式ドキュメントの記述は明確です。

原文：The sandbox runs on macOS, Linux, and WSL2. On native Windows, Claude Code runs commands unsandboxed. To use the sandbox on a Windows machine, run Claude Code inside a WSL2 distribution.

Windows で使うなら、WSL2 の中で Claude Code を動かします。WSL1 では動きません。サンドボックスは初期状態では無効で、セッションで /sandbox を実行してモードを選びます。auto-allow モードなら、サンドボックスの中で動くコマンドを確認なしで承認し、deny ルールと内容を指定した ask ルールは、そのまま効きます。対象はシェルコマンドと、その子プロセスだけです。Read、Edit、Write などの組み込みツールや MCP サーバーは外で動き、権限ルールで制御します。サンドボックスの中のコマンドが書き込めるのは、作業ディレクトリなどに限られますが、読み取りはマシンのほとんどの場所に及びます。~/.ssh や ~/.aws/credentials も含まれるので、読ませたくないものは filesystem.denyRead か、Read の deny ルールで指定してください。

Claude Code 承認スキップ（bypassPermissions）のリスク

承認スキップは、次のどちらで起動しても同じ bypassPermissions モードになります。

claude --permission-mode bypassPermissions
claude --dangerously-skip-permissions

確認の画面も、安全チェックも止まります。保護パスへの書き込みも通ります。保護パスには .git が入っているので、Claude が Git の履歴や設定を書き換えることも可能です。ローカルのコミットだけを保険にしないでください。公式ドキュメントの警告は、次のとおりです。

原文：Only use this mode in isolated environments like containers, VMs, or dev containers without internet access, where Claude Code cannot damage your host system.

さらに bypassPermissions は、プロンプトインジェクションや意図しない操作に対する保護を一切提供しません。確認を減らしたいだけなら、公式は auto モードを勧めています。承認スキップでも残る歯止めは、deny ルール、ask ルールに当てはまる操作、ファイルシステムのルートやホームディレクトリ、C:\ のようなドライブのルートを対象にする rm と rmdir の確認です。

最初に承認スキップで対話セッションを始めると、責任を受け入れるかを尋ねる警告が出ます。VS Code 拡張では「Allow dangerously skip permissions」、デスクトップアプリでは「Allow bypass permissions mode」を有効にするまで選べません。自分で使えなくしたいときは、ユーザー設定に次を書きます。

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

承認スキップを使うなら、公式ドキュメントが求めるとおり、コンテナ、VM、開発コンテナの中で、非 root のユーザーで、外向きの通信を絞って動かします。コンテナに入れてもリスクは残ります。開発コンテナの中で承認スキップを使うと、悪意のあるプロジェクトが、コンテナの中で触れるもの（~/.claude の認証情報を含む）を外へ持ち出せることがある、と公式は警告しています。信頼できるリポジトリだけで使い、~/.ssh やクラウドの認証情報は、コンテナにマウントしないでください。

場面ごとの組み合わせ

承認を減らすことと安全であることは、その場面に合った境界を先に用意すれば両立できます。以下は、公式の整理から導いた組み合わせです。

承認を緩めるほど、失敗しても戻せる状態が重要です。作業の前に git status をきれいにし、機能ごとにブランチを切って、こまめにコミットしてください。

承認疲れを減らす：確認は1か所でまとめて行う

承認疲れの原因は、確認の数だけではありません。セッションが複数あると、どこで何が止まっているかが分からず、確認待ちに気づくのが遅れます。確認を減らすのとは別に、確認を1か所に集めて、まとめて処理するという方法があります。複数のプロジェクトを同時に動かしているときに、特に困る点です。

AigoPilot は、すべてのプロジェクトの Claude Code と Codex のセッションを1つのウィンドウに並べ、確認待ちのセッションを1つの一覧にまとめます。権限の確認には、コマンドの全文や変更の中身が表示され、「許可」「許可しない」「似た場合も許可」を選べます。権限モードは、「完全に安全」「バランス」（初期設定）「フルアクセス」「カスタム」の4つです。バランスでは、プロジェクト外の削除のような危険な操作だけを確認します。AigoPilot は、--dangerously-skip-permissions も auto モードも使わずにセッションを始めます。許可する範囲が広いモードは、何を許すかを一覧で示した画面で、あなたが承認するまで有効になりません。

iPhone アプリは、権限の確認にコマンドの全文を表示して、離れた場所から許可と拒否ができます（App Store での公開準備中です）。承認をスマホからまとめて行う仕組みの詳細は、専用のページにまとめています。スマホから操作する方法の選択肢は、別の記事にまとめています。

Codex の承認とサンドボックス

Codex の安全は、2つの設定の組み合わせで決まります。サンドボックスモード（sandbox_mode）は、コマンドが技術的にできること（書き込める場所、ネットワーク）を決めます。値は read-only、workspace-write、danger-full-access です。承認ポリシー（approval_policy）は、実行の前に人に確認するタイミングを決めます。on-request は、サンドボックスの外に出るときに確認し、never は確認しません。

codex --sandbox workspace-write --ask-for-approval on-request
codex --sandbox workspace-write --ask-for-approval never

Claude Code の承認スキップと違って、--ask-for-approval never を付けてもサンドボックスは残り、書き込みの範囲とネットワークの制限は守られます。境界ごと外す --dangerously-bypass-approvals-and-sandbox について、公式は「No sandbox; no approvals」で「推奨しない」としています。--approve-for-me や approvals_reviewer = "auto_review" を使うと、確認が必要な操作を別のレビュー用エージェントが審査します（Claude Code の auto に近い仕組みです）。Codex のネットワークは既定でオフで、workspace-write でも .git と .codex は読み取り専用のままです。ネイティブ Windows にもサンドボックスがあり、config.toml の [windows] で sandbox = "elevated"（推奨）か "unelevated" を選びます。

まとめ：確認を減らす順番

1. よく出る確認を、/permissions から allow ルールにする。同時に、読ませたくないファイルを deny ルールに入れる。
2. 編集の確認だけが煩わしいなら acceptEdits、全体を減らしたいなら auto。push のような節目には ask ルールを置く。
3. WSL2 を使えるなら、/sandbox の auto-allow を足す。
4. それでも足りない無人の作業は、コンテナか VM の中で動かす。承認スキップは、ここで初めて検討する。

承認は、面倒な手続きである前に、取り返しのつかない操作を人が見る最後の機会です。減らすなら、人が見なくても被害が出ない範囲を、先に作っておくのが筋です。確認は一度で減らし切るものではありません。何度も出る確認があれば、そのたびにルールへ移し、危ない操作だけが人の目に残るように整えていきます。

よくある質問

出典

• 権限モードの選択：code.claude.com/docs/ja/permission-modes（2026年10月7日に確認）
• 権限の設定、ルールの書式：code.claude.com/docs/ja/permissions（2026年10月7日に確認）
• サンドボックスの設定：code.claude.com/docs/ja/sandboxing（2026年10月7日に確認）
• サンドボックス環境の選択、開発コンテナ：code.claude.com/docs/ja/sandbox-environments、code.claude.com/docs/ja/devcontainer（2026年10月7日に確認）
• CLI リファレンス、設定ファイル：code.claude.com/docs/ja/cli-reference、code.claude.com/docs/ja/settings（2026年10月7日に確認）
• Codex の承認とセキュリティ、Windows サンドボックス：learn.chatgpt.com/docs/agent-approvals-security、learn.chatgpt.com/docs/windows/windows-sandbox（2026年10月7日に確認）