Claude Code で承認をスキップする4つの手段とは
Claude Code の承認スキップとは、ツール実行のたびに出る確認を、設定であらかじめ通す仕組みです。
Claude Code は、読み取り以外のツール呼び出しを実行する前に必ず止まります。ファイルの編集、シェルコマンドの実行、ネットワークへのアクセスがその対象です。意図しない削除や外部への通信を人が水際で止めるための設計ですが、1つのタスクで数十回の確認が積み上がると、待ち時間と作業の切り替えだけで時間が溶けていきます。
確認を減らす手段は大きく4つあり、それぞれ「何を通すか」と「誰が判断するか」が違います。
| 手段 | 通るようになるもの | 判断するのは | 向く場面 |
|---|---|---|---|
| 権限モードの切り替え | モードごとに決まった範囲 | Claude Code の内蔵ルール | まず試したいとき |
| 許可リストの設定 | 自分が書いたパターンに一致する呼び出し | 自分が書いたルール | 繰り返す作業を固定したいとき |
| auto モード | 分類器が安全と判断したもの | 別の分類器モデル | 長時間の作業を任せたいとき |
| 全スキップのフラグ | ほぼすべて | 誰も判断しない | 隔離された環境の中だけ |
この4つは排他ではなく、重ねて使えます。実務では「許可リストで毎回通す作業を固定し、それ以外は auto モードの分類器に判断させる」といった組み合わせが現実的です。
確認の設計は、AIに任せる範囲を広げようとしたときに最初にぶつかる壁でもあります。GiftX の調査では、AIエージェントが複数工程の業務を半自動から自動で進める層は全体の10.5%にとどまり、その層が挙げた課題の1位は「毎回の指示・調整に手間がかかる」（32.9%、複数回答）でした。使い始めの人ではなく、いちばん進んでいる層が手間で詰まっているという結果です。詳細な調査データは「ビジネス職生成AI活用実態調査（2026年版）」にてご覧ください。
関連記事：Claude Codeとは？できること・料金・使い方と社内導入の判断軸
Claude Code の権限モードの種類｜6つのモードの違い
権限モードは、確認をどこまで出すかの土台を決める設定です。Claude Code には6つのモードがあり、識別子は default / acceptEdits / plan / auto / dontAsk / bypassPermissions です。CLI 上の表示名は default が「Manual」で、以降は「Accept edits」「Plan」「Auto」「Don’t ask」「Bypass permissions」となります。
| モード | 確認なしで通るもの | 想定する使いどころ |
|---|---|---|
| `default`（Manual） | 読み取りのみ | 触り始め、慎重に進めたい作業 |
| `acceptEdits` | 読み取り、ファイル編集、`mkdir` や `mv` など基本的なファイル操作 | 差分を後からまとめて確認する進め方 |
| `plan` | 読み取り中心。ソースの編集はしない | 変更前に構造を調べたいとき |
| `auto` | 分類器の判定を通ったもの全般 | 長時間まとめて任せたいとき |
| `dontAsk` | 事前に許可したツールのみ。他は自動で拒否 | 人が張り付けない自動実行 |
| `bypassPermissions` | ほぼすべて | 隔離されたコンテナや仮想マシンの中のみ |
モードを切り替える3つの方法
切り替え方は、効かせたい範囲によって3つに分かれます。
- セッション中に切り替える：
Shift+Tabを押すとdefaultからacceptEdits、planの順に回り、状態はステータスバーに表示されます - 起動時に決める：
claude --permission-mode planのように--permission-modeを渡します - 既定値として固定する：設定ファイルの
permissions.defaultModeに書きます。置き場所はユーザー全体なら~/.claude/settings.json、プロジェクト共有なら.claude/settings.json、個人のローカル設定なら.claude/settings.local.jsonです
Shift+Tab の循環に出てくるモードは環境によって変わります。auto は利用条件を満たしているときだけ加わり、bypassPermissions は起動時に有効化したときだけ加わります。dontAsk は循環には現れず、起動オプションでのみ指定します。
モードを上げても通らないもの
モードを緩めても無条件では通らない領域があります。.git や .claude、.vscode といったディレクトリ、.zshrc や .npmrc といったシェル・パッケージマネージャの設定ファイルは保護パスとして扱われ、bypassPermissions 以外では自動承認されません。リポジトリの状態と Claude Code 自身の設定が勢い余って書き換わることを防ぐ線引きです。
自分で書いた拒否ルールと明示的な確認ルールも、どのモードでも効き続けます。モードは土台、ルールはその上に重ねる例外、と考えると整理しやすくなります。
settings.json の許可リストで承認をスキップする使い方
モードより粒度が細かいのが許可リストです。permissions には allow（確認なしで通す）、ask（必ず確認する）、deny（拒否する）の3つの配列があり、deny、ask、allow の順に評価されて最初に一致したものが結果になります。
評価順は固定です。deny に Bash(aws *) と書くと allow に Bash(aws s3 ls) と書いても通りません。広い拒否の中に狭い例外を作れないので、拒否は触らせたくない範囲だけに絞り、細かい制御は許可側で書きます。
シェルコマンドのルールを書く
ルールは Bash(パターン) の形で書き、* はコマンド文字列の任意の位置に置けます。allow に Bash(npm run *) と書けば npm run で始まるコマンドが通ります。
ここで効くのが空白の有無です。Bash(ls *) は ls -la に一致しますが lsof には一致しません。Bash(ls*) なら両方に一致します。末尾の * の前に空白を置くと単語の区切りが要求されるため、意図しないコマンドまで通す事故を減らせます。
複合コマンドも考慮されています。Bash(safe-cmd *) を許可しても safe-cmd && other-cmd は通りません。&&、||、;、|、&、改行が区切りとして認識され、それぞれの部分がすべて一致しなければ実行されません。
全国8,000人調査で、AI活用方法によって生産性向上に約3.8倍の差が生まれることが判明。
ファイルのルールを書く
読み書きのルールは Read(パターン) と Edit(パターン) で書きます。パターンは gitignore と同じで、先頭の記号で基準になる場所が変わります。
| 書き方 | 基準になる場所 | 例 |
|---|---|---|
| `//path` | ファイルシステムのルート | `Read(//Users/alice/secrets/**)` |
| `~/path` | ホームディレクトリ | `Read(~/Documents/*.pdf)` |
| `/path` | その設定ファイルの置き場所 | `Edit(/src/**)` |
| `path` または `./path` | 現在のディレクトリ | `Read(*.env)` |
/Users/alice/file は、ファイルシステムのルートからのパスとしては扱われません。スラッシュ1つは設定ファイルの位置を基準にするため、ルートから書きたいときは // で始めます。書き間違えても静かに一致しないだけなので、気づきにくい箇所です。
共有する範囲も分けられます。全員に効かせたいルールは .claude/settings.json に書いてコミットし、自分の環境だけの例外は .claude/settings.local.json に置きます。範囲の広い許可を共有側に入れると他のメンバーの環境まで一律に緩めるので、共有側に置く価値があるのは拒否ルールのほうです。
auto モードで承認をなくす使い方
auto モードは、確認の代わりに別の分類器モデルが操作を審査する仕組みです。全部を素通しにするのではなく、依頼の範囲を超える操作、見覚えのないインフラを対象にした操作、読み込んだ内容に誘導された疑いのある操作をブロックします。
関連記事：Claude Code Auto Modeとは？仕組み・設定・安全な使い方を整理
使える条件と、有効にする方法
使えるかどうかはプランではなくモデルで決まります。すべてのプランで利用でき、Anthropic API 上では Claude Opus 4.6 以降、Sonnet 4.6 以降、または Fable 5 が対象です。組織の管理者が permissions.disableAutoMode を "disable" にしている場合は使えません。
有効なときは Shift+Tab の循環に現れ、permissions.defaultMode に auto と書けば既定にもできます。ただしプロジェクト側の設定ファイルに書いた auto は無視されます。リポジトリ側が自分に auto モードを与えられないようにするための制限なので、既定にするならユーザー設定に書きます。
何が止まり、何が通るのか
既定でブロックされるのは、取り返しがつかない操作と外に出ていく操作です。本番環境へのデプロイ、クラウドストレージの一括削除、権限の付与、git reset --hard のように未コミットの変更を捨てる操作などが該当します。逆に、作業ディレクトリの中でのファイル操作、依存関係のインストール、読み取りだけの通信は既定で通ります。分類器が連続で3回、または合計で20回ブロックすると、auto モードは一時停止して通常の確認に戻ります。
会話で述べた制約も効く
許可リストとの使い分けで押さえておきたいのは、会話の中で人が述べた制約も分類器がブロックの根拠として扱う点です。「まだプッシュしないで」と伝えれば、既定では通る操作でもその後は止まります。ただしルールとして保存されず、そのつど会話から読み直されるため、会話が長くなって該当する発言が圧縮で失われると制約も失われます。確実に止めたい操作は deny ルールで書いてください。
公式ドキュメントも、auto モードは確認を減らす仕組みであって安全を保証する仕組みではないと明記しています（出典: claude.com）。慎重に見たい操作のレビューを置き換えるものではありません。
—dangerously-skip-permissions の使い方と、承認をスキップしてよい環境の条件
すべての確認を外すのが --dangerously-skip-permissions です。起動時にこのフラグを渡すか、permissions.defaultMode に bypassPermissions を指定すると有効になります。claude --permission-mode bypassPermissions も同じ意味です。
このモードでは保護パスへの書き込みも通ります。.git や .claude の中身が確認なしで書き換わるということなので、リポジトリの履歴や Claude Code 自身の設定が壊れても止まりません。それでも残る確認は3種類あります。自分で書いた ask ルール、組織が確認必須に設定したコネクタのツール、そしてファイルシステムのルートやホームディレクトリを消そうとする操作です。rm -rf / や rm -rf ~ は、このモードでも確認が出る安全装置として残されています。
関連記事：Claude Code は安全に使える？セキュリティリスクと最初にすべき設定
起動できない条件がある
Linux と macOS では、root や sudo での実行時にこのフラグは拒否されます。表示されるのは --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons というメッセージで、起動そのものが止まります。
権限のない環境で全確認を外すと、システム上のあらゆるファイルとサービスに手が届いてしまうためです。コンテナの中で自動実行したい場合は、非 root ユーザーで動く開発コンテナの構成を使う想定になっています。
使ってよい環境の線引き
このフラグを使ってよいのは、壊れても捨てられる環境の中だけです。判断の目安は3つあります。
- ホスト側のファイルに手が届かないこと：コンテナや仮想マシンの中で、作業用のディレクトリだけがマウントされている状態が該当します
- 認証情報がその環境に置かれていないこと：クラウドの鍵や SSH の鍵が読める場所にあるなら、確認を全部外す判断は取れません
- 外部に書き込む権限を持っていないこと：本番環境への接続情報を持ったまま全確認を外すのは、事故が起きたときに取り返しがつきません
逆に、普段の開発マシンでそのまま使うのは避けたほうが安全です。確認を減らしたいだけなら、前の章の auto モードのほうが目的に合います。組織として使わせたくない場合は、管理者向けの設定で permissions.disableBypassPermissionsMode を "disable" にすると、このモード自体を封じられます。
サンドボックスと Hooks で承認を減らす実践的な守り方
確認を減らすアプローチには、権限設定とは別の層もあります。
サンドボックスは OS の側で境界を強制する
/sandbox で有効にすると、シェルコマンドとその子プロセスが OS のレベルで隔離され、書き込める場所と到達できるドメインが制限されます。macOS では Seatbelt、Linux と WSL2 では bubblewrap が使われます。
効き方は権限設定と根本的に違います。権限ルールはコマンドを実行する前に文字列を見て判断しますが、サンドボックスは実行中のプロセスに対して OS が境界を強制します。コマンド名から想像できる以上のことを実際にやってしまう場合でも、境界の外には出られません。
PreToolUse フックで条件を書く
PreToolUse フックは、ツールが実行される直前に自分のスクリプトを差し込み、その出力で通す、止める、人に聞くのいずれかを返す仕組みです。許可リストのパターンでは表現しきれない条件、たとえばコマンドの中身を解析して判断したいときに使えます。
組み合わせ方の目安は範囲の広さで分けることです。触らせたくない範囲は拒否ルールで落とし、日常的に繰り返す作業は許可リストで通し、条件が複雑なものだけフックで判断する。この順で書くと、後から読んだ人が理由をたどれる設定になります。
全国8,000人調査で、AI活用方法によって生産性向上に約3.8倍の差が生まれることが判明。
許可リストを設定したのに承認が出るときの原因
設定したはずなのに確認が出る、というのは最も多いつまずきです。原因は次の5つの型に分かれます。
- 評価順：
denyとaskはallowより先に評価されます。広いaskルールが残っていると、後から狭い許可を足しても確認が出続けます - 空白：
Bash(npm test*)とBash(npm test *)は一致する範囲が違います - ラッパー：
timeoutやniceは取り除いてから照合されますが、devbox runやnpx、docker execは取り除かれません。内側のコマンドまで含めたルールを1つずつ書きます - ツール名：
Write(docs/**)は参照されません。パス判定に使われるのはEdit(パス)とRead(パス)だけで、Editがファイルを編集する系のツール全体をカバーします - 保護パス：
.claudeや.gitへの書き込みは、許可ルールを書いてもbypassPermissions以外では自動承認されません
上から順に見ていくと、たいていは2つ目までで原因が見つかります。ツール名の取り違えは起動時に警告が出るので、そこも合わせて読んでみてください。
Claude Code に長時間の作業を任せている自社の事例
GiftX の開発チームでは、外部から受け取った API 仕様書を AI コーディングエージェントに渡し、自社の標準形式に沿ったクライアントとテストコードをまとめて生成する運用をしています。仕様書を読んでクライアントを手で実装し、テストを書くまでに約3日かかっていた工程が、生成された結果をレビューして直すだけの約半日になり、工数はおよそ83%削減されました。
この工程が成立しているのは、途中で止まらずに走り切れるからです。ファイルの生成とテスト実行を許可リストに載せ、コミットと外部への通信だけ確認を残す形にしています。人が判断するのは「この形で正しいか」の一点で、途中の1つ1つの書き込みではありません。確認を減らす設定は待ち時間を削るだけでなく、任せられる作業の単位そのものを変えます。
Before/After で見る承認をスキップした効果
社内ツールのリファクタリングを AI コーディングエージェントに任せる、という日常的な作業で考えます。実務3年目の開発担当が1人で回している想定です。
| 項目 | Before | After |
|---|---|---|
| 進め方 | 編集とテスト実行のたびに確認が出て、画面の前を離れられない | 編集とテスト実行を許可リストに登録し、コミットと外部通信だけ確認を残す |
| 1タスクの確認回数 | 数十回 | 3回 |
| 待ちと切り替えの時間 | 約90分のうち約35分 | 約6分 |
削減率にすると約83%です。1日3タスク回すなら週あたり約7時間が別の作業に回ります。効果の実体は時間そのものより、まとまった時間が戻ってくることにあります。数分おきに確認を求められる状態では、その間に別の作業を進められません。
すぐ使える承認設定のチェックリスト
設定を変える前に、次の項目を上から順に確認してみてください。
- 触らせたくない範囲を先に決めましたか。認証情報のファイル、本番環境に触るコマンド、履歴を書き換える操作を
denyに書いてから許可を足す順序にします - 共有する設定と個人の設定を分けましたか。全員に効かせたいルールは
.claude/settings.json、自分の環境だけの例外は.claude/settings.local.jsonです - パターンの基準になる場所を確認しましたか。
/src/**と//src/**とsrc/**はそれぞれ違う場所を指します - 複合コマンドを想定しましたか。区切り文字でつないだコマンドは、それぞれがルールに一致しなければ通りません
- 全確認を外す設定を使うなら、その環境は壊れても捨てられますか。ホストのファイルに届かない、認証情報が置かれていない、外部に書き込む権限がない。この3つが条件です
- まず1つの作業から始めましたか。繰り返している作業を1つ選び、それに必要なコマンドだけを載せるところから始めます
順序を逆にすると、許可を広げるたびに危ない範囲まで一緒に開きます。上から3つまでを決めてから許可を書き足すと、後から見直すときにも理由をたどれます。
AIエージェントに作業を任せ始めるときに陥りがちな3つの落とし穴
設定そのものより、任せ方の設計でつまずくことのほうが多いのが実情です。よく見かける型を3つ挙げます。
落とし穴1｜いきなり全ての確認を外そうとする
最初から全部を素通しにすると、どこまで任せて問題なかったのかが分からないまま進みます。範囲を絞って始めれば、外して良かった線と外すべきでなかった線が実データで見えてきます。
落とし穴2｜壮大な自動化構想から考えて手が止まる
開発全体をどう自動化するかから設計を始めると、決めることが多すぎて着手できません。今週も繰り返している作業を1つ選ぶほうが早く進みます。
落とし穴3｜既製品のチャット型AIツールでは業務フローに組み込めない
汎用のチャット型ツールは、自社の手順や制約を覚えさせるところに限界があります。実際の業務フローに組み込むには、自社の情報と手順に合わせて作り込める形が必要になります。
スモールスタートで1業務をAIエージェントに任せる
現実的なのは、繰り返している1つの作業を選び、その作業に必要なコマンドだけを許可リストに載せて回してみることです。うまくいけば範囲を1段広げ、止まるべきところで止まらなければ戻す。この単位なら、判断も撤退も自分たちで握れます。範囲を広げた記録が残っていれば、次に任せる作業を決めるときの材料にもなります。GiftX では、こうしたスモールスタート前提のAIエージェント構築を1業務単位から伴走支援しています。詳細は AIエージェント構築支援サービス をご覧ください。
よくある質問
承認を自動で通すには、どこから設定するのがいちばん簡単ですか
セッション中に Shift+Tab を押してモードを切り替えるのが最短です。ファイル編集を通したいだけなら acceptEdits で足ります。繰り返す作業が決まっているなら、/permissions から許可ルールを追加して固定するほうが安定します。
auto モードと全スキップのフラグは何が違いますか
判断する主体が違います。auto モードは別の分類器モデルが操作ごとに審査してブロックしますが、全スキップのフラグは誰も審査しません。保護パスへの書き込みも通るため、隔離された環境の外で使うものではありません。
全スキップのフラグは安全ですか
安全を担保する仕組みは入っていません。残る確認は、自分で書いた確認ルール、組織が確認必須にしたツール、ルートやホームディレクトリを消す操作の3種類だけです。壊れても捨てられる環境の中でのみ使う前提の機能です。
権限の設定はどのファイルに書きますか
ユーザー全体に効かせるなら ~/.claude/settings.json、プロジェクトで共有するなら .claude/settings.json、自分の環境だけなら .claude/settings.local.json です。管理者が配布する設定が最も強く、これは個人の設定で上書きできません。
まとめ
Claude Code の確認を減らす手段は、権限モード、許可リスト、auto モード、全スキップのフラグの4つです。モードで土台を決め、許可リストで繰り返す作業を固定し、判断が難しい部分は分類器かフックに任せる。この順で重ねると、どこを人が見ているのかが後から追える設定になります。
全スキップのフラグだけは性質が違い、壊れても捨てられる環境の中でのみ成立します。普段の開発マシンで確認を減らしたいなら、auto モードとサンドボックスの組み合わせのほうが目的に合います。
そして設定より先に効くのは、任せる範囲の決め方です。すべてを一度に自動化しようとせず、繰り返している1業務を選んでその作業に必要な範囲だけを開ける。スモールスタートで1業務をAIエージェントに任せることが、結果的にいちばん早く成果に届きます。
AIエージェント活用の伴走支援をご検討の方へ
本記事で紹介した設定を踏まえて、自社の業務でもAIエージェントに任せる範囲を具体的に広げたい、相談したいとお考えの方は、ぜひGiftX AIエージェント構築支援までお問い合わせください。
GiftX AIエージェント構築支援では、貴社の業務に合わせて1業務単位のスモールスタートから本番運用まで、AIエージェント構築をワンストップで支援します。ユースケースの洗い出しから、PoC、本番運用、社内ナレッジ化まで伴走します。
AI活用にご関心のある方は、ぜひ一度ご相談ください。
▶ GiftX AIエージェント構築支援の詳細・お問い合わせはこちら
