Claude Code 自動承認｜毎回のyesを消す5つの設定と解除

「このコマンドを実行しますか？」が出るたびにyを押していて、作業より承認のほうが多い気がする——あるいは、まとめて許可したいけれど勝手に本番へpushされたら困る。Claude Codeを毎日触っていれば、どちらかは頭をよぎったはずです。結論から書くと、Claude Codeの毎回のyesは、自動承認の5つの設定で消せます。しかも2026年8月14日以降、Pro・Max・Teamプランでは自動承認のオートモードがセッションの初期状態になり、何も設定しない人も、既に自動承認側に立っている状態です。この記事では、編集部が公式ドキュメントで確認した5つの設定と、オートモードが既定になって実際に変わったこと、自動承認にしても必ず止まる操作、そして手動承認へ戻す手順までをコマンド例つきでまとめます。

01Claude Codeの自動承認とは｜毎回のyesは何を聞いているのか

Claude Codeの承認ダイアログは、ツールを実行する直前に「この操作を許可してよいか」を人間に確認する仕組みです。自動承認とは、この確認を人以外の判断に置き換えて、実行まで一気に通すことを指します。置き換える相手はふたつあり、ひとつは事前に書いておいた許可ルール、もうひとつはオートモードで動く分類器モデルです。どちらを使うかで、消える確認の範囲と、残るリスクの形が変わります。

そもそも確認が出る操作と、はじめから出ない操作

確認は全操作に出るわけではありません。公式ドキュメントの権限一覧によると、ファイルの読み取りやGrepは作業ディレクトリと追加ディレクトリの中であれば承認なしで実行されます。承認が要るのは、シェルコマンドの実行、ファイルの作成・編集、WebFetch、WebSearchです。シェルコマンドのうち一部の読み取り専用コマンドと、あらかじめ登録された公式ドキュメントのドメインへのWebFetchは、この例外に含まれます。つまり「毎回yesを押している」と感じる正体は、ほぼBashコマンドとファイル編集の2種類です。

自動承認には「モード」と「許可ルール」の2つの入り口がある

Claude Codeは、権限モードで「そもそも聞くかどうか」の基準を切り替え、許可ルールで「この操作は聞かない」を個別に指定します。モードはdefault（CLI上の表示はManual）・acceptEdits・plan・auto・dontAsk・bypassPermissionsの6種類で、ルールはallow・ask・denyの3種類です。判定はdeny、ask、allowの順に走り、最初に一致したものが結果を決めます。モードごとの細かい差はClaude Codeの権限モード完全ガイドで表にまとめてあるので、本記事では自動承認に直結する部分だけを扱います。

02毎回のyesを消す5つの設定

承認を減らす手段は公式に5つ用意されています。承認が減る幅が大きい順ではなく、失敗したときの被害が小さい順に並べると、下の表のようになります。全部を一度に入れる必要はなく、自分の作業がどれで足りるかを先に決めるほうが安全です。

設定	自動で通るもの	保存される範囲	向いている場面
①オートモード	分類器が安全と判定した操作すべて	セッション単位（既定の起動状態にもできる）	長い作業を止めずに進めたいとき
②Yes, and don’t ask again	いま許可したコマンドやドメイン	.claude/settings.local.jsonにリポジトリ単位で保存	よく使うコマンドを1件ずつ潰していくとき
③permissions.allow	自分で書いたルールに一致する操作	書いた設定ファイルの適用範囲	チーム全員に同じ許可を配りたいとき
④/fewer-permission-prompts	読み取り系のBash・MCP呼び出し	プロジェクトの.claude/settings.json	何を許可すべきか自分で判断できないとき
⑤acceptEditsモード	ファイル編集とmkdir・touch・mv・cpなど	作業ディレクトリと追加ディレクトリ	差分をあとでまとめて確認したいとき

FIG.1 毎回のyesを消す5つの設定と、それぞれが覆う範囲

①オートモードに切り替える｜分類器が代わりに判定する

オートモードは、実行の直前に分類器モデルが操作を審査し、依頼の範囲を超えるもの・見知らぬインフラを触るもの・読み込んだ外部コンテンツに誘導された疑いがあるものだけをブロックします。人が押していたyesを、別のモデルが押すと考えると近いです。オートモードは全プランで利用でき、Anthropic APIではClaude Opus 4.6以降、Sonnet 4.6以降、またはFableモデルが必要です。Bedrock・Google CloudのAgent Platform・Microsoft Foundry経由ではSonnet 5、Opus 4.7以降、Fableモデルに限られます。

その場で切り替える方法と、毎回この状態で起動する方法

いま動いているセッションを切り替えるなら、CLIでShift+Tabを押します。ステータス行の表示が⏵⏵ auto mode onになれば入れ替わっています。起動時から指定するなら次のとおりです。

claude --permission-mode auto

毎回この状態で立ち上げたい場合は~/.claude/settings.jsonに書きます。ここで注意したいのが保存先で、autoという値はプロジェクト側の.claude/settings.jsonや.claude/settings.local.jsonに書いても無効です。設定したのにManualで起動するときは、まず置き場所を疑ってください。

{
  "permissions": {
    "defaultMode": "auto"
  }
}

②「Yes, and don’t ask again」で許可をためていく

承認ダイアログには、1回だけ許可する選択肢のほかに「Yes, and don’t ask again」が並びます。Bashコマンドで選ぶと、そのコマンドの許可ルールがgitリポジトリのルートにある.claude/settings.local.jsonへ保存され、以後は同じリポジトリのどのディレクトリで起動しても確認が出なくなります。同じように残るのは、ドメイン単位で保存されるWebFetchと、リポジトリ単位で保存されるWebSearchです。ただしファイル編集の許可だけは保存されず、セッションが終われば消える点は覚えておいてください。

選択肢が「1回だけ許可」しか出ないこともあります。ルールが覆う範囲を画面に全部表示できないとき、Claude Codeはあえて保存の選択肢を隠します。その場合は/permissionsから自分でルールを足すのが確実です。

③permissions.allowに自分で書く

許可の形はツール名またはツール名(条件)です。*は空白を含む任意の文字列に一致するため、コマンド群をまとめて1行で書けます。下は、この記事で推奨する最小構成です。ビルドと整形だけを通しています。

{
  "permissions": {
    "allow": [
      "Bash(npm run build)",
      "Bash(npx prettier *)",
      "Read"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ]
  }
}

askに書いたルールは、オートモードでも必ず確認が出ます。分類器の判定より先に評価される仕組みで、「自動承認は使いたいが公開だけは自分の目で見たい」という要望をaskルールだけで満たせる設計です。ルールの書式をもっと細かく詰めたい場合は、Claude Codeの権限バイパスは危ない？毎回の承認を減らす設定で書き方と落とし穴を扱っています。

④/fewer-permission-promptsに許可リストを作らせる

何を許可すればよいか自分で決められないときは、/fewer-permission-promptsを実行します。これまでのセッション記録を走査して、よく呼ばれている読み取り系のBashコマンドとMCPツールを拾い、優先度をつけた許可リストをプロジェクトの.claude/settings.jsonに書き込む組み込みスキルです。自分の作業ログが根拠になるので、使いもしないコマンドを広く開けてしまう事故を避けられます。

⑤acceptEditsモードで編集だけ自動にする

コマンド実行までは任せたくないという判断もあります。acceptEditsは、ファイルの作成・編集に加えてmkdir・touch・rm・rmdir・mv・cp・sedを作業ディレクトリの中でだけ自動承認するモードです。それ以外のBashコマンドはこれまでどおり確認が出ます。差分はgit diffであとから見る、という進め方と相性がよい設定です。

5つのうちどれから始めればよいですか？

手元のローカル作業なら①のオートモード、共有リポジトリなら③のask付き許可ルールから始めるのが安全です。①は承認の数がいちばん減る代わりに判断を分類器に預けます。③は減り方こそ穏やかですが、通す範囲を自分の言葉で書いた分だけしか広がりません。

03オートモードが既定になって何が変わったか

2026年8月14日の変更で入れ替わったのは機能そのものではなく、初期状態です。オートモードはそれ以前から選べる設定として提供されており、自分でモードを切り替えた人だけが使っていました。既定化によって、権限まわりを一度も触っていない人が自動承認の側に立つようになりました。あわせて分類器を挟む分のオーバーヘッド課金はPro・Max・Teamで廃止されているため、常時オンでも料金は増えない扱いです。

どの環境がオートモードで立ち上がるのか？

ターミナルとVS Code拡張で、Pro・Max・Teamプランを使っている場合です。Enterpriseプラン、Claude ConsoleのAPIキー、claude -pによる非対話実行、Agent SDK、Bedrock・Google CloudのAgent Platform・Microsoft Foundry経由のセッションは、いずれも従来どおりManualで始まります。バージョン条件もあり、macOS・Linux・WSLはv2.1.228以降、ネイティブWindowsはv2.1.233以降が必要です。インストールやアップグレード直後の最初のセッションもManualで立ち上がります。

承認の主体が人から分類器へ移った

既定化で実務上いちばん大きい変化は、止まる場所が変わったことです。手動承認では、危険な操作でも安全な操作でも同じダイアログが出るため、人は内容を読まずに通す癖がつきます。オートモードでは安全側の操作が黙って流れ、分類器が引っかけたものだけが画面に残ります。承認の回数は減り、残った1件の重みが増える設計です。加えてオートモードは、Claudeが確認の質問で途中停止しないよう振る舞いを寄せます。依頼やスキルがはっきり確認を前提にしている場合は、これまでどおり質問が出ます。

自分で書いた許可ルールは、オートモードでも生きるのか？

自分で書いた許可ルールがそのまま生き続けるとは限りません。オートモードが有効な間、Bash(*)のような任意コード実行を許すルールと、Monitorを名指しするルールは一時的に停止されます。Bash(npm test)のような範囲の狭いルールは有効なままで、分類器より先に判定される点が違いです。逆に、狭いルールも含めて全部のシェルコマンドを分類器に通したい場合はautoMode.classifyAllShellをtrueにします。判定の待ち時間と引き換えに、見落としの経路をひとつ塞げる設定です。

04自動承認でも止まる操作｜設定では通せない3種類

「全部自動になる」と考えて設定すると、想定と違う場所で止まります。Claude Codeには、モードや許可ルールに関係なく必ず人の判断を挟む階層があり、承認は次の順で処理されます。

1denyルールに一致したら即ブロック

2askルールに一致したら必ず確認ダイアログ

3範囲の狭いallowルールに一致したら通す

4オートモードなら分類器が審査

5実行、またはブロックして別の手段を探させる

FIG.2 承認が処理される順序（分類器は権限システムの後段に立つ）

どのモードでも自動承認されない操作

公式ドキュメントは、bypassPermissionsを含むすべてのモードで自動承認しない操作を明示しています。明示的なaskルールに一致する操作、組織がaskに設定したコネクタツール、AskUserQuestionのようにユーザーの入力を必要とするツール、そして重要パスを狙うrm・rmdirです。重要パスにはファイルシステムのルート、その直下のディレクトリ、ホームディレクトリ、作業ディレクトリとその親が含まれます。rm -rf "$DIR"/*のように変数直下をglobで消す形も、変数が空だった場合にルート直下の削除になるため同じ扱いです。

保護パスへの書き込みは許可ルールでは通らない

もうひとつ、allowルールを書いても通らない領域があります。.git・.claude・.vscode・.idea・.husky・.devcontainerなどのディレクトリと、.zshrc・.npmrc・.mcp.jsonといった設定ファイル群です。保護パスへの書き込みは、allowルールに一致しても分類器へ回される仕組みです。Edit(.claude/**)と書いても素通りにはならず、手動承認のモードでは確認が出て、オートモードでは分類器が判定します。

分類器が既定でブロックする操作と、既定で通す操作

分類器の既定ルールは公開されており、claude auto-mode defaultsでJSONとして手元に出せます。実務で当たりやすいものを抜き出すと次のようになります。既定で通る側に「作業中リポジトリのブランチへのpush」が入っている点は、想像と食い違いやすいところです。

操作	オートモードでの扱い
作業ディレクトリ内のファイル操作	そのまま実行
lockfileやmanifestに書かれた依存のインストール	そのまま実行
読み取りだけのHTTPリクエスト	そのまま実行
作業中リポジトリのブランチへのpush（既定ブランチを含む）	そのまま実行
force push、git reset --hard、git clean -fd	ブロック
本番デプロイ、本番マイグレーション、terraform destroy	ブロック
ダウンロードしたコードの実行（curlからのパイプ実行）	ブロック
セッション開始前から存在したファイルの不可逆な破壊	ブロック
.gitや.claudeへの書き込み	分類器の判定へ回る
askルールに一致する操作	どのモードでも確認が出る

FIG.3 オートモードで通る操作・止まる操作の代表例

pushが既定で通るのは、いま作業しているリポジトリのブランチに限られます。productionやgh-pagesのように、デプロイ先や公開先であることが名前から分かるブランチは既定の対象外で、そこへのpushは内容ごとに分類器が判断します。

分類器が信頼するのは、作業ディレクトリと、セッション開始時点で設定されていたリモートだけです。セッション中にgit remote addやgit remote set-urlで足したリモートは信頼の外に置かれます。社内のGitHub Organizationや共有バケットを日常的に触るなら、~/.claude/settings.jsonのautoMode.environmentに書き足しておくと、正常な操作が止まる回数が減ります。

05危険な場面と、手動承認への戻し方

公式ドキュメントは「オートモードは確認を減らすが、安全を保証しない」と明記しています。方向性を任せてよい作業に使うもので、慎重な確認の代わりにはならない、という位置づけです。では具体的にどの場面が危ないのかを、先に押さえておきます。

無人実行・本番リポジトリ・削除系で何が起きるか？

いちばん注意が要るのは無人実行です。claude -pによる非対話実行で--permission-prompt-toolを指定していない場合、承認ダイアログを出す先がありません。ブロックが続いても実行が止まらず、その操作だけが実行されないままClaudeは作業を続けます。夜間バッチで回していると、失敗に気づくのは翌朝です。定期実行の組み方はClaude Codeの定期実行を自動化する方法で扱っていますが、無人化するほどdenyを先に置く価値が上がります。

本番に触るリポジトリでは、会話の中で「pushしないで」と伝える方法も分類器に届きます。ただし境界はルールとして保存されず、分類器が毎回トランスクリプトから読み直すため、コンテキストの圧縮でその発言が消えると効力を失います。確実に守らせたい線は、会話ではなくaskかdenyで書いてください。削除系についても、消したいパスを変数のまま渡さず、実際のパスを文字で書くほうが分類器の判定が通りやすくなります。

ブロックが続くとオートモードは自動で解除される

暴走を止める仕組みも入っています。分類器が3回連続、または通算20回ブロックすると、オートモードは一時停止して通常の確認ダイアログに戻ります。出てきた確認を承認すれば、オートモードへ復帰する動きです。この回数は設定で変更できません。

手動承認に戻す3つの方法

戻し方は場面ごとに3通りです。いま動いているセッションだけ戻すならShift+Tabで、オートモードからの1回目の押下でManualに切り替わり、以降はdefault→acceptEdits→planと巡回します。次の起動から手動に固定したいなら、起動時にフラグを渡すか、ユーザー設定に書きます。

claude --permission-mode default

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

~/.claude/settings.jsonに保存すると、次のセッションからステータス行に⏸ manual mode onが出ます。なお実装は「Manual」という表示名を使いますが、設定ファイルに書く値はdefaultです。v2.1.200以降はmanualという別名も受け付けます。

組織でオートモードを使わせない設定

受託開発や金融系のように、担当者ごとの初期状態がぶれると困る現場もあるはずです。TeamプランとEnterpriseプランの管理者は、managed settingsで次のように書くとオートモードを選べなくできます。Shift+Tabの巡回からautoが消え、--permission-mode auto付きで起動してもManualで始まります。

{
  "permissions": {
    "disableAutoMode": "disable"
  }
}

v2.1.251以降は、稼働中のセッションにこの設定が届いた時点でオートモードから抜け、auto mode disabled by settingsと表示されます。

06実務での設定例｜サイト制作と自社ツール開発

この記事で推奨する設定を2種類挙げます。どちらも「通す範囲を広げる」より先に、「どこで止めるか」を決める順で書いてあります。

サイト制作・LP制作：ビルドは通し、公開の手前で止める

静的サイトやLPの制作では、ビルド・画像最適化・整形を何度も回します。ここはオートモードに任せて構いません。取り返しがつかないのは公開の瞬間だけなので、askでgit pushとデプロイコマンドを名指しします。プロジェクト直下の.claude/settings.jsonに置けば、案件のリポジトリを開いた全員に同じ確認が出ます。

{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(vercel deploy *)",
      "Bash(npx wrangler deploy *)"
    ]
  }
}

自社ツール開発・無人実行：権限モードを起動時に渡す

社内向けの自動化をヘッドレスで走らせるときは、設定ファイルより先に起動コマンドを直します。公式のheadlessドキュメントによると、claude -pの非対話実行はどのプランでもManualから始まるため、使いたい権限モードは毎回フラグで渡す必要があります。あわせて--permission-prompts noneを付けると、承認を答える人がいない実行で待ち続けずに済みます。確認が必要になった操作はその場で拒否され、Claudeには「誰も承認できないので再試行するな」と伝わり、処理はそのまま進みます。このフラグはv2.1.259以降で使えます。

claude -p "依存の更新とテストまで通して" --permission-mode auto --permission-prompts none

設定ファイル側では、読ませたくないファイルをdenyで名指しし、社内のリモートを分類器の信頼範囲に足しておきます。

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(~/.ssh/**)",
      "Bash(rm -rf *)"
    ]
  },
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.com/example-inc and all repos under it"
    ]
  }
}

ここでBash(rm -rf *)を安全網と考えないでください。公式ドキュメントによると、Bashのルールは最初の*より前を書いたとおりに照合します。つまりこの1行が止めるのはrm -rfで始まる書き方だけで、rm -frやrm -r -fのように並びが変われば一致しません。さらにnpx・docker exec・devbox runのような実行ラッパーは、Claude Codeが読み飛ばすラッパーの一覧に入っておらず、内側のコマンドがそのまま走ります。公式ドキュメントはBash(devbox run *)がdevbox run rm -rf .にも一致すると明記しています。無人実行で実際に守ってくれるのは、重要パスを狙うrm・rmdirをどのモードでも自動承認しない仕組みと、本番デプロイやマイグレーションを止める分類器のほうです。denyはその上に重ねる1枚として書きます。

autoModeブロックは~/.claude/settings.json・managed settings・--settingsフラグからしか読まれません。プロジェクト内の.claude/settings.jsonに書いても分類器には届かない仕様で、リポジトリ側から信頼範囲を勝手に広げられない設計になっています。書き終えたらclaude auto-mode configで反映を確認してください。上限に当たって処理が途切れる問題は権限とは別系統なので、Claude Codeが上限で止まらない自動再開の設定と戻し方を合わせて見ておくと無人運用が安定します。

オートモードに切り替わらないときの確認順

「auto modeが選べない」「設定したのにManualで起動する」場合の確認順は決まっています。まず使用中のモデルが対応しているかを見ます。Sonnet 4.5やOpus 4.5、Haiku、claude-3系はどのプロバイダーでも対象外です。次に、いずれかの設定ファイルでdisableAutoModeが有効になっていないかを確認します。それでも変わらない場合はdefaultMode: "auto"の置き場所を見直してください。プロジェクト側の設定ファイルに書いたautoは無効です。なお、Anthropic側がサーバー側で一時的に停止していることもあり、その回答を受け取ったセッションは終了まで手動のままなので、時間を置いて新しいセッションを立ち上げます。

FAQよくある質問

07まとめ：自動承認をどこまで広げるかの判断基準

自動承認をどこまで広げるかは、「その環境で取り返しのつかない操作が起きうるか」で決まります。ローカルの制作案件や検証用リポジトリなら、オートモードのまま進めて承認の中断をなくす利益のほうが大きいです。本番インフラや顧客データに届く環境では、askでpushとデプロイを手前に止め、denyで読ませたくないファイルを名指しし、その上でオートモードを使うのが現実的な線です。まずは手元の1プロジェクトで/fewer-permission-promptsを実行し、自分が普段どのコマンドで止められていたかを一覧にするところから始めると、許可の範囲を勘で決めずに済みます。実装前に安全に計画を立てるモードはClaude CodeのPlan Modeとは？切り替え方と暴走を止める設定、行き過ぎた変更を戻す手順はClaude Code /rewindの取り消しとforkの違いでまとめています。

• Anthropic「Auto mode is now the default in Claude Code」（2026年8月7日公開。8月14日からPro・Max・Teamの新規セッションがオートモードで動くこと、分類器オーバーヘッドの課金撤廃を編集部が確認）
• Anthropic「Claude Code Docs — Choose a permission mode」（権限モード一覧・オートモードの既定化条件・分類器の既定ブロック/許可ルール・保護パス・重要パス・フォールバック回数を編集部が確認）
• Anthropic「Claude Code Docs — Configure permissions」（allow/ask/denyの評価順・ルール書式・「Yes, and don’t ask again」の保存先を確認）
• Anthropic「Claude Code Docs — Configure auto mode」（autoMode.environmentの読み取りスコープ・classifyAllShell・claude auto-mode各サブコマンドを確認）
• Anthropic「Claude Code Docs — Commands reference」（/fewer-permission-prompts・/permissions・/auto-mode-setupの説明を確認）