目次
Claude Codeで --dangerously-skip-permissions フラグを設定したにもかかわらず、Claudeがチャット内で「この操作を実行してよいですか？」と確認を求めてくる——そんな経験はありませんか？
「バイパスしているはずなのに、なぜ確認が来るのか」と思いがちですが、これはバイパスが効いていないのではありません。Claude Codeの許可システムには、2つの独立したレイヤーが存在しており、バイパスモードが制御できるのはそのうちの1つだけだからです。
この記事では「バイパスとは何か」という基礎から、2つの許可レイヤーの違い、Claudeが自ら確認を求める操作のパターン、そして自動化をスムーズに進める実践的な方法まで、具体例とともに解説します。
1. そもそも「バイパス」とは何か
ソフトウェアにおける「バイパス（bypass）」とは、通常の確認・承認フローを迂回して処理を進めることを指します。たとえば、ショッピングサイトで「確認画面をスキップして即購入」するボタンは、確認フローのバイパスです。
Claude Codeの手動モード（設定値は default）では、ファイルの編集やシェルコマンドの実行前に確認ダイアログが表示されます。なお端末と VS Code では、Claude Code v2.1.283 以降はどのプラン・接続先でも起動時の既定が自動モードで、多くの確認は分類器の審査に置き換わっています（それより前の版で既定が自動モードなのは Pro・Max・Team プランだけ。管理者が自動モードを無効にした組織や、自動モードに対応していないモデルでは手動で始まります）。
# 手動モードでは、実行前に確認が入る
$ claude --permission-mode default
> index.jsを修正してください
[Claude Code] index.js を編集してよいですか？ → Yes / No から選ぶこの確認フローをスキップ（迂回）するのが、権限バイパスモードです。
# バイパスモード：確認ダイアログをほぼ出さずに実行
$ claude --dangerously-skip-permissions
# または
$ claude --permission-mode bypassPermissionsフラグ名に dangerously（危険） が含まれている点が重要です。Anthropicはこのモードをコンテナや隔離環境専用として位置づけており、通常のローカル開発環境での使用は推奨していません。バイパスモードの詳細なリスクはClaude Code権限バイパスモードのリスクと安全な使い方で解説しています。
ただし、確認ダイアログが頻繁に出るなら、先にそもそもバイパスで動いているかを確かめてください。バイパス中は、端末のステータスバーに ⏵⏵ bypass permissions on と表示されます。表示されない場合によくある原因は2つです。
- プロジェクトの設定に書いた：
.claude/settings.jsonや.claude/settings.local.jsonのdefaultModeにbypassPermissionsと書いても効かず、手動モードで始まります（v2.1.257 以降）。ユーザー設定（~/.claude/settings.json）か管理設定に書くか、起動時のフラグで指定します。 - 途中から切り替えようとした：バイパスは、起動時に有効にしたセッションでしか選べません。有効にせずに始めたセッションでは、Shift+Tab を押してもバイパスは出てきません。
また、初めてバイパスで対話セッションを始めるときは、確認なしで実行される操作に責任を持つかを尋ねる警告が1度だけ表示されます（承認はユーザー設定に保存されます）。
2. 確認が来る本当の理由——2層構造の正体
「バイパスを設定したのに確認が来る」という現象の答えは、Claude Codeの許可システムが2つの独立したレイヤーで構成されているからです。
Claude Codeの許可システム：2層構造
バイパスモードが無効化できるのは「層1」だけ（その層1にも残る確認がある）
--dangerously-skip-permissions が無効化するのは層1の確認のほぼすべて（ask ルール・重要なパスの削除などは残る）。層2はバイパスできない。
この2つのレイヤーを混同してしまうことが、「バイパスが効いていない」という誤解の原因です。それぞれを詳しく見ていきましょう。
3. 層1：ツール権限UI（バイパスで制御できる）
1つ目のレイヤーは、ツール実行前の確認ダイアログです。Claude Codeがファイルを編集したり、シェルコマンドを実行したりする際に表示される対話的なUIのことです。
| ツール | 表示される確認ダイアログの例 |
|---|---|
| ファイル編集 | 「index.jsを変更してよいですか？」 |
| Bash実行 | 「npm install を実行してよいですか？」 |
| Webアクセス | 「https://... にアクセスしてよいですか？」 |
バイパスモードが無効化するのは、まさにこのレイヤーです。 --dangerously-skip-permissions を使うと、上記のような確認ダイアログはほぼ表示されなくなり、Claudeがツールを自由に実行できるようになります。.git や .claude といった保護されたパスへの書き込みも、バイパスなら確認なしで通ります。この意味では、バイパスモードは正常に機能しています。
バイパスでも出る確認（層1の例外）
ただし「ほぼ」です。公式ドキュメントは、次のものはバイパスを含むどのモードでも自動では承認しないと明記しています（出典：Claude Code公式「Choose a permission mode」、2026年9月22日時点）。
- ask ルールに一致した操作：設定の
permissions.askに書いた操作（例：Bash(git push *)）は、バイパスでも毎回確認が出ます。 - あなたの操作が要るツール：Claudeが選択肢つきで質問する
AskUserQuestion、利用者の操作が必要と指定された MCP ツール、組織が「確認する（ask）」に設定したコネクタのツール。 - 重要なパスを消す
rm・rmdir：ファイルシステムのルートとその直下（/usrなど）、ホームディレクトリ、作業フォルダとその親などを狙う削除。公式はこれをモデルの誤りに備えた「回路遮断器（circuit breaker）」と呼び、allow ルールでもフックでも承認させません。ただし Desktop アプリと VS Code では、v2.1.309 から確認を出さずにすぐ拒否し、書き換えの手がかりを返します（人がいないセッションを止めないため。公式の変更履歴）。 - そのほか：セッションをまたぐメッセージングの安全策と、
permissions.blockReadsOutsideWorkingDirectoriesを有効にしているときに作業フォルダの外を読む Bash コマンド。
ルールの扱いも押さえておきましょう。deny（拒否）ルールはバイパスでも効き、一致した操作を止めます。一方、allow（許可）ルールはバイパスでは意味を持ちません（もともとすべて通るため）。なお -p で動かす非対話の実行では、これらの確認は入力を待たずに拒否されます。
補足：権限モードは6つある
Claude Codeの権限モードは、手動（default）・編集を受け入れる（acceptEdits）・プラン（plan）・自動（auto）・権限をバイパス（bypassPermissions）の5つに、Shift+Tab の切り替えには出てこない dontAsk（確認が要る操作をすべて自動で拒否する、CI 向けのモード）を加えた6つです。バイパス（bypassPermissions）はその中で最も制限が少ないモードです。各モードの詳細は権限モードの解説記事を参照してください。
4. 層2：AIの安全判断（バイパスでは制御できない）
2つ目のレイヤーは、Claudeの自律的な安全判断です。これはツールの確認UIとは全く別のものです。
Claudeは、実行しようとしている操作が「重大な影響を持つ可能性がある」と判断したとき、チャット内のテキストで確認を求めてきます。これはツール実行の仕組みではなく、ClaudeのAIとしての会話行動です。
バイパスモードの --dangerously-skip-permissions は層1のUIダイアログをスキップするものですが、この層2のAI判断を停止させる効果はありません。なぜなら、層2はClaudeのモデル自体に組み込まれた行動原則だからです。
よくある誤解
「バイパスモードを設定したのにClaudeが止まった → バイパスが効いていない」
→ 正確には、止まり方で見分けます。チャットの文章で聞いてきたなら「層1は無効化されているが、層2のAI判断が確認を求めている」状態です。端末に許可を求めるダイアログが出たなら、ask ルールや重要なパスの削除など、バイパスでも残る層1の確認です。どちらの場合も、バイパスは正常に機能しています（どちらでもないのに確認が続くなら、そもそもバイパスで起動していない可能性があります）。
ただし、層2は安全の保証ではありません。Claudeが確認するかどうかはその場の判断で、危険な操作の前で必ず止まるとは限りません。公式ドキュメントも、バイパスはプロンプトインジェクションや意図しない操作に対して何の保護にもならないと警告しています。絶対に実行させたくない操作は、deny ルールで止めてください。
5. Claudeが自ら確認する操作のパターン
操作タイプ別：どちらの層が確認を行うか
層1（ツール権限UI）と層2（AI安全判断）の比較
Claudeが「自ら確認が必要」と判断する基準は主に3つです。
① 不可逆性
元に戻せない操作は、Claudeが慎重になります。ファイルの完全削除、git push --force、データベースのDROP TABLEなどが代表例です。間違えてしまったときの影響が大きいため、Claudeは一旦立ち止まって確認を求めます。
② 影響範囲の広さ
本番環境への操作、大量ファイルの変更、他のユーザーに影響する変更など、影響が広範囲に及ぶ操作では確認が入りやすくなります。「ローカルの1ファイルを変更する」より「本番DBのスキーマを変更する」の方が確認頻度が高いのはこのためです。
③ セキュリティリスク
.env ファイルや認証トークン、APIキーなどを外部に送信するような操作は、セキュリティリスクが高いとClaudeが判断し、確認を求めます。
なお、同じ削除でも、ルート・ホーム・作業フォルダそのものなど重要なパスを消す rm・rmdir は、バイパスでも Claude Code 自身（層1）が止めます（CLI は確認を出し、Desktop アプリと VS Code は v2.1.309 からすぐ拒否します）。Claudeの判断に任されない、数少ない確認の1つです。
これらの判断はClaudeのAIモデルに組み込まれたものであり、設定ファイルで完全にオフにすることはできません。AIエージェントが自律的に動作する際の安全設計についてはAIエージェントとは何かも参考になります。
6. なぜ2層構造なのか——設計思想
なぜ2層構造なのか——設計思想
建設作業員のアナロジーで理解する
なぜこの2層構造にするのでしょうか。わかりやすいアナロジーで説明します。
建設作業員に部屋のリフォームを依頼し、合鍵を渡したとします。「合鍵があるから何でもやっていいよ」と伝えました。これは「ツール権限の付与」に相当します。
しかし、職人が壁を壊そうとして「これ、耐力壁じゃないですか？本当に壊してよいですか？」と聞いてきたとします。合鍵を渡されていても、職人は自分の専門的な判断から確認してきたわけです。
この確認は「合鍵（ツール権限）」とは無関係です。職人の職業的判断・安全意識から来ています。「合鍵を渡す＝職人の判断力を停止させる」ことにはなりません。
Claudeも全く同様です。バイパスモードは「Claudeにツールを使う鍵を渡すこと」ですが、ClaudeのAIとしての判断力まで停止させるものではありません。むしろ、高リスクな操作の前にClaudeが自ら立ち止まる動作は、意図された安全機能です。
7. 自動化を進めるための実践的な対処法
CI/CDパイプラインなど、Claudeに途中で止まらずに作業を完了してほしい場面もあるでしょう。確認頻度を下げるための実践的な方法を紹介します。
対処法1：CLAUDE.md で文脈を明示する
プロジェクトルートに CLAUDE.md を作成し、作業環境と制約を明記することで、Claudeが「これは安全な環境だ」と判断しやすくなり、余分な確認の頻度が下がります。
# 作業環境について
このリポジトリはCI/CDパイプライン内のテスト環境で実行されています。
- 実行環境：完全に隔離されたDockerコンテナ
- 本番環境への影響：なし
- すべての変更はロールバック可能
特別な確認を求めずに作業を進めてください。対処法2：タスクを小さく・具体的に指示する
曖昧な指示はClaudeの不確実性を高め、確認を誘発します。
| 指示のタイプ | 例 | 確認頻度 |
|---|---|---|
| 曖昧な指示 | 「このプロジェクトをクリーンアップして」 | 高い |
| 具体的な指示 | 「src/ 内の未使用の import を削除して」 | 低い |
| 曖昧な指示 | 「デプロイして」 | 高い |
| 具体的な指示 | 「staging環境に npm run deploy:staging を実行して」 | 低い |
対処法3：autoモードを先に検討する
完全なバイパスモードが本当に必要かどうか、まず autoモード を試してみてください。autoモードは安全性分類器がバックグラウンドで動作しつつ、多くの操作を自動承認します。さらに、確認の質問で止まらずに作業を続けるよう Claude に促す働きもあります（プロンプトやスキルが質問を前提にしている場合は聞きます）。「確認プロンプトが煩わしい」という理由だけでバイパスモードを選ぶ必要はありません。なお、ask ルールに一致した操作は自動モードでも確認が出ます。
重要な前提
どのような設定をしても、Claudeの安全判断を完全にゼロにすることはできません。これはバグや制限ではなく、意図された設計です。特に高リスクな操作でClaudeが確認してくることは「正常な動作」として受け入れることが重要です。また層1にも、ask ルールや重要なパスの削除のように、バイパスで消えない確認が残ります。
8. まとめ
| 項目 | 内容 |
|---|---|
| バイパスとは | ツール実行前の確認ダイアログ（層1）をほぼすべてスキップすること |
| バイパスで無効化できるもの | ツール権限UI（「このコマンドを実行してよいですか？」）、.git・.claude など保護されたパスへの書き込みの確認も含む |
| バイパスで無効化できないもの | ClaudeのAI安全判断（会話内で確認テキストを送ってくる動作）と、層1の例外（ask ルール・重要なパスの rm／rmdir・AskUserQuestion） |
| バイパスでのルールの扱い | deny は効いて止める／allow は意味がない |
| Claudeが確認する基準 | 不可逆性・影響範囲の広さ・セキュリティリスク |
| 確認頻度を下げる方法 | CLAUDE.md で文脈明示 / タスクを具体的に / autoモードの活用 |
| 2層構造の理由 | ツール許可とAI判断は根本的に別の概念だから |
「バイパスモードなのに確認が来る」のは、バイパスが効いていないのではなく、2つのシステムが独立して動作しているからです。この区別を理解することで、Claude Codeの動作を正確に予測し、より効率的に活用できるようになります。
Claudeの各プロダクトの違いを理解したい方はClaude.aiとClaude Codeの違いも参考にしてください。
FAQ
バイパスモードで全ての確認をゼロにすることはできますか？
ツール実行のUIダイアログ（層1）はほぼ無効化できますが、ask ルールに一致した操作、重要なパスを消す rm や rmdir、AskUserQuestion による質問の確認は残ります。ClaudeのAI安全判断（層2）による確認も、完全にゼロにすることはできません。これは設計上の安全機能です。ただし、CLAUDE.mdで作業環境を丁寧に説明したり、タスクを具体的に指示したりすることで、確認頻度を大幅に下げることは可能です。
Claudeが確認してくるのはバグですか？
バグではありません。バイパスモードはツール権限UIをスキップするものですが、ClaudeのAI判断を停止させるものではありません。特に不可逆性が高い操作や、本番環境・機密情報に関わる操作の前にClaudeが確認してくることは意図された安全設計です。「バイパスが効いていない」のではなく「2つのシステムが独立して動作している」だけです。なお、チャットの文章ではなく許可を求めるダイアログが出た場合は、ask ルールや重要なパスの削除など、バイパスでも残る層1の確認です。
CI/CDパイプラインでClaudeが途中で止まらないようにするには？
①CLAUDE.md または システムプロンプトで「これは完全に隔離されたCI/CD環境であり、すべての操作は安全な環境内で実行される」ことを明示する、②タスクを小さく具体的に指示する（曖昧な指示は確認を誘発する）、③バイパスモード + Dockerコンテナで環境を隔離する、の3点が特に効果的です。③では root 以外のユーザーで動かしてください（Linux・macOS では、root や sudo のままだとバイパスでの起動が拒否されます）。また -p で実行すれば、バイパスでも残る確認は入力を待たずに拒否されます。許可した操作だけを動かしたいなら、--permission-mode dontAsk と --allowedTools の組み合わせも公式が CI 向けに挙げています。それでも完全には止められないケースがある点は前提として理解しておいてください。
ツール権限ダイアログとClaudeの確認は見た目で区別できますか？
はい、区別できます。ツール権限ダイアログ（層1）は、Claude Codeのターミナルに、実行するコマンドや編集の内容とともに Yes / No などの選択肢が並ぶ対話型のUIとして表示されます。一方、ClaudeのAI判断（層2）による確認は、Claudeが通常の会話テキストとして送ってくるメッセージです（「本番DBへの変更になりますが、実行してよいですか？」など）。紛らわしいのは、Claudeが選択肢つきで質問する AskUserQuestion です。中身は Claude からの質問ですが、ダイアログの形で出て、層1が自動承認しないツールなのでバイパスでも答えを待ちます。表示形式が異なるため、慣れれば簡単に区別できます。
