目次
Claude Codeで --dangerously-skip-permissions フラグを設定したにもかかわらず、Claudeがチャット内で「この操作を実行してよいですか?」と確認を求めてくる——そんな経験はありませんか?
「バイパスしているはずなのに、なぜ確認が来るのか」と思いがちですが、これはバイパスが効いていないのではありません。Claude Codeの許可システムには、2つの独立したレイヤーが存在しており、バイパスモードが制御できるのはそのうちの1つだけだからです。
この記事では「バイパスとは何か」という基礎から、2つの許可レイヤーの違い、Claudeが自ら確認を求める操作のパターン、そして自動化をスムーズに進める実践的な方法まで、具体例とともに解説します。
1. そもそも「バイパス」とは何か
ソフトウェアにおける「バイパス(bypass)」とは、通常の確認・承認フローを迂回して処理を進めることを指します。たとえば、ショッピングサイトで「確認画面をスキップして即購入」するボタンは、確認フローのバイパスです。
Claude Codeの通常動作では、ファイルの編集やシェルコマンドの実行前に確認ダイアログが表示されます。
# 通常モードでは、実行前に確認が入る
$ claude
> index.jsを修正してください
[Claude] このファイルを編集してよいですか? [y/n]
この確認フローをスキップ(迂回)するのが、権限バイパスモードです。
# バイパスモード:確認ダイアログなしで実行
$ claude --dangerously-skip-permissions
# または
$ claude --permission-mode bypass
フラグ名に dangerously(危険) が含まれている点が重要です。Anthropicはこのモードをコンテナや隔離環境専用として位置づけており、通常のローカル開発環境での使用は推奨していません。バイパスモードの詳細なリスクはClaude Code権限バイパスモードのリスクと安全な使い方で解説しています。
2. 確認が来る本当の理由——2層構造の正体
「バイパスを設定したのに確認が来る」という現象の答えは、Claude Codeの許可システムが2つの独立したレイヤーで構成されているからです。
この2つのレイヤーを混同してしまうことが、「バイパスが効いていない」という誤解の原因です。それぞれを詳しく見ていきましょう。
3. 層1:ツール権限UI(バイパスで制御できる)
1つ目のレイヤーは、ツール実行前の確認ダイアログです。Claude Codeがファイルを編集したり、シェルコマンドを実行したりする際に表示される対話的なUIのことです。
| ツール | 表示される確認ダイアログの例 |
|---|---|
| ファイル編集 | 「index.jsを変更してよいですか?」 |
| Bash実行 | 「npm install を実行してよいですか?」 |
| Webアクセス | 「https://... にアクセスしてよいですか?」 |
バイパスモードが無効化するのは、まさにこのレイヤーです。 --dangerously-skip-permissions を使うと、上記の確認ダイアログが一切表示されなくなり、Claudeがツールを自由に実行できるようになります。この意味では、バイパスモードは正常に機能しています。
補足:権限モードは5段階ある
Claude Codeにはdefault・acceptEdits・plan・auto・bypassPermissionsの5段階の権限モードがあります。バイパス(bypassPermissions)はその中で最も制限が少ないモードです。各モードの詳細はバイパスモードの詳細解説記事を参照してください。
4. 層2:AIの安全判断(バイパスでは制御できない)
2つ目のレイヤーは、Claudeの自律的な安全判断です。これはツールの確認UIとは全く別のものです。
Claudeは、実行しようとしている操作が「重大な影響を持つ可能性がある」と判断したとき、チャット内のテキストで確認を求めてきます。これはツール実行の仕組みではなく、ClaudeのAIとしての会話行動です。
バイパスモードの --dangerously-skip-permissions は層1のUIダイアログをスキップするものですが、この層2のAI判断を停止させる効果はありません。なぜなら、層2はClaudeのモデル自体に組み込まれた行動原則だからです。
よくある誤解
「バイパスモードを設定したのにClaudeが止まった → バイパスが効いていない」
→ 正確には「層1のUIは無効化されているが、層2のAI判断が確認を求めている」状態です。バイパスは正常に機能しています。
5. Claudeが自ら確認する操作のパターン
Claudeが「自ら確認が必要」と判断する基準は主に3つです。
① 不可逆性
元に戻せない操作は、Claudeが慎重になります。ファイルの完全削除、git push --force、データベースのDROP TABLEなどが代表例です。間違えてしまったときの影響が大きいため、Claudeは一旦立ち止まって確認を求めます。
② 影響範囲の広さ
本番環境への操作、大量ファイルの変更、他のユーザーに影響する変更など、影響が広範囲に及ぶ操作では確認が入りやすくなります。「ローカルの1ファイルを変更する」より「本番DBのスキーマを変更する」の方が確認頻度が高いのはこのためです。
③ セキュリティリスク
.env ファイルや認証トークン、APIキーなどを外部に送信するような操作は、セキュリティリスクが高いとClaudeが判断し、確認を求めます。
これらの判断はClaudeのAIモデルに組み込まれたものであり、設定ファイルで完全にオフにすることはできません。AIエージェントが自律的に動作する際の安全設計についてはAIエージェントとは何かも参考になります。
6. なぜ2層構造なのか——設計思想
なぜこの2層構造にするのでしょうか。わかりやすいアナロジーで説明します。
建設作業員に部屋のリフォームを依頼し、合鍵を渡したとします。「合鍵があるから何でもやっていいよ」と伝えました。これは「ツール権限の付与」に相当します。
しかし、職人が壁を壊そうとして「これ、耐力壁じゃないですか?本当に壊してよいですか?」と聞いてきたとします。合鍵を渡されていても、職人は自分の専門的な判断から確認してきたわけです。
この確認は「合鍵(ツール権限)」とは無関係です。職人の職業的判断・安全意識から来ています。「合鍵を渡す=職人の判断力を停止させる」ことにはなりません。
Claudeも全く同様です。バイパスモードは「Claudeにツールを使う鍵を渡すこと」ですが、ClaudeのAIとしての判断力まで停止させるものではありません。むしろ、高リスクな操作の前にClaudeが自ら立ち止まる動作は、意図された安全機能です。
7. 自動化を進めるための実践的な対処法
CI/CDパイプラインなど、Claudeに途中で止まらずに作業を完了してほしい場面もあるでしょう。確認頻度を下げるための実践的な方法を紹介します。
対処法1:CLAUDE.md で文脈を明示する
プロジェクトルートに CLAUDE.md を作成し、作業環境と制約を明記することで、Claudeが「これは安全な環境だ」と判断しやすくなり、余分な確認の頻度が下がります。
# 作業環境について
このリポジトリはCI/CDパイプライン内のテスト環境で実行されています。
- 実行環境:完全に隔離されたDockerコンテナ
- 本番環境への影響:なし
- すべての変更はロールバック可能
特別な確認を求めずに作業を進めてください。
対処法2:タスクを小さく・具体的に指示する
曖昧な指示はClaudeの不確実性を高め、確認を誘発します。
| 指示のタイプ | 例 | 確認頻度 |
|---|---|---|
| 曖昧な指示 | 「このプロジェクトをクリーンアップして」 | 高い |
| 具体的な指示 | 「/tmp/ 内の .log ファイルをすべて削除して」 | 低い |
| 曖昧な指示 | 「デプロイして」 | 高い |
| 具体的な指示 | 「staging環境に npm run deploy:staging を実行して」 | 低い |
対処法3:autoモードを先に検討する
完全なバイパスモードが本当に必要かどうか、まず autoモード を試してみてください。autoモードは安全性分類器がバックグラウンドで動作しつつ、多くの操作を自動承認します。「確認プロンプトが煩わしい」という理由だけでバイパスモードを選ぶ必要はありません。
重要な前提
どのような設定をしても、Claudeの安全判断を完全にゼロにすることはできません。これはバグや制限ではなく、意図された設計です。特に高リスクな操作でClaudeが確認してくることは「正常な動作」として受け入れることが重要です。
8. まとめ
| 項目 | 内容 |
|---|---|
| バイパスとは | ツール実行前の確認ダイアログ(層1)をスキップすること |
| バイパスで無効化できるもの | ツール権限UI(「このコマンドを実行してよいですか?」) |
| バイパスで無効化できないもの | ClaudeのAI安全判断(会話内で確認テキストを送ってくる動作) |
| Claudeが確認する基準 | 不可逆性・影響範囲の広さ・セキュリティリスク |
| 確認頻度を下げる方法 | CLAUDE.md で文脈明示 / タスクを具体的に / autoモードの活用 |
| 2層構造の理由 | ツール許可とAI判断は根本的に別の概念だから |
「バイパスモードなのに確認が来る」のは、バイパスが効いていないのではなく、2つのシステムが独立して動作しているからです。この区別を理解することで、Claude Codeの動作を正確に予測し、より効率的に活用できるようになります。
Claudeの各プロダクトの違いを理解したい方はClaude.aiとClaude Codeの違いも参考にしてください。
FAQ
バイパスモードで全ての確認をゼロにすることはできますか?
ツール実行のUIダイアログ(層1)は無効化できますが、ClaudeのAI安全判断(層2)による確認を完全にゼロにすることはできません。これは設計上の安全機能です。ただし、CLAUDE.mdで作業環境を丁寧に説明したり、タスクを具体的に指示したりすることで、確認頻度を大幅に下げることは可能です。
Claudeが確認してくるのはバグですか?
バグではありません。バイパスモードはツール権限UIをスキップするものですが、ClaudeのAI判断を停止させるものではありません。特に不可逆性が高い操作や、本番環境・機密情報に関わる操作の前にClaudeが確認してくることは意図された安全設計です。「バイパスが効いていない」のではなく「2つのシステムが独立して動作している」だけです。
CI/CDパイプラインでClaudeが途中で止まらないようにするには?
①CLAUDE.md または システムプロンプトで「これは完全に隔離されたCI/CD環境であり、すべての操作は安全な環境内で実行される」ことを明示する、②タスクを小さく具体的に指示する(曖昧な指示は確認を誘発する)、③バイパスモード + Dockerコンテナで環境を隔離する、の3点が特に効果的です。それでも完全には止められないケースがある点は前提として理解しておいてください。
ツール権限ダイアログとClaudeの確認は見た目で区別できますか?
はい、区別できます。ツール権限ダイアログ(層1)はClaude Codeのターミナルに「Allow bash command? [y/n]」のようなインタラクティブUIとして表示されます。一方、ClaudeのAI判断(層2)による確認は、Claudeが通常の会話テキストとして送ってくるメッセージです(「本番DBへの変更になりますが、実行してよいですか?」など)。表示形式が全く異なるため、慣れれば簡単に区別できます。