「dangerously-skip-permissionsって名前が怖すぎて使えない」
Claude Codeを使い始めると、必ずこのフラグを目にする。そして2026年3月、新たな疑問が加わった。
「autoモードが来たらしいけど、dangerously-skip-permissionsと何が違うの？」
この2つは一見「どちらも確認ダイアログなしで動く」ように見えるが、設計思想がまったく異なる。dangerously-skip-permissionsは「人間の判断を完全に排除する」、autoモードは「AIが各操作の危険度を判断する」 — この違いを理解することが、今後のClaude Code活用の鍵になる。
この記事では、2026年3月現在のClaude Codeパーミッションシステムを6つのモード全体像から解説し、dangerously-skip-permissions vs autoモードの本質的な違いに迫る。
📌 注意:
autoモードは2026年3月時点でResearch Preview段階。利用できるユーザーは限定的な可能性がある。
なぜパーミッション制御が必要なのか
Claude Codeはファイルの読み書き、Bashコマンドの実行、外部APIへのリクエスト — これらをすべて「自律的に」実行できる。AIが自律的に動くからこそ、意図しない操作を防ぐ仕組みが必要になる。
パーミッションシステムは公式ドキュメント上「Allow/Ask/Denyルール」で構成され、評価順序は deny → ask → allow だ。本記事ではこれに加えてCLAUDE.mdによるスコープ制限を組み合わせた実用的な3層防御として整理する（筆者の整理であり、Anthropic公式の呼称ではない）：
[Layer 3] Confirm（確認モード）= Allow/Ask/Denyルール
→ settings.json の defaultMode でどのレベルで確認を求めるか設定
→ 本記事のメインテーマ
[Layer 2] Scope（作業範囲制限）
→ CLAUDE.mdで作業ディレクトリ・禁止操作を記述
[Layer 1] Deny（絶対禁止ルール）
→ settings.json の deny配列でブロックするコマンドを定義
→ 例: rm -rf * は永続的にブロック
多くのユーザーが「パーミッションモードだけ変えれば自動化できる」と考えがちだが、3層すべてを設計することで初めて安全な自動化が実現する。
6つのパーミッションモード一覧
Claude Codeには現在5つの標準パーミッションモードが存在し、さらに2026年3月にResearch Previewとしてautoモードが追加された（autoは--enable-auto-modeフラグで有効化する別仕組み）。
| モード | 確認プロンプト | ファイル操作 | Bashコマンド | AI判断 | 向いている用途 |
|---|---|---|---|---|---|
plan | なし（実行不可） | ❌ 不可 | ❌ 不可 | — | コード分析・プランニングのみ |
default | 各ツール初回使用時 | ⚠️ 一部確認 | ⚠️ 要確認 | — | 通常の対話型開発 |
acceptEdits | ファイル編集は自動 | ✅ 自動 | ⚠️ 要確認 | — | コーディング作業を快適に |
dontAsk | ダイアログなし（許可外は拒否） | 設定次第 | 設定次第 | — | CI/CDヘッドレスエージェント |
bypassPermissions | なし（全自動） | ✅ 自動 | ✅ 自動 | — | 完全隔離環境での自動化 |
auto ⭐NEW | AIが危険度判定 | ✅ 自動（低リスク） | 🤖 AI判断 | ✅ あり | 日常開発（Research Preview） |
各モードの詳細解説
plan — 「見るだけ」モード
planモードはClaude Codeのすべてのツール実行を完全にブロックする。コードを読んで分析し、計画を提案することしかできない。
// settings.json
{
"permissions": {
"defaultMode": "plan"
}
}
こんなときに使う:
– 「このコードが何をしているか説明して」という分析依頼
– 変更のリスクを確認してからGOサインを出したい
– Claude Codeを使い始めて、AIがどう動くか学びたい
default — 「標準」モード
インストール直後のデフォルト。各ツールの初回使用時に確認プロンプトが表示される（公式: “Standard behavior: prompts for permission on first use of each tool”）。一度承認したツールはセッション中は再確認されない。
こんなときに使う:
– 通常の日常的な開発作業
– 新しいプロジェクトをClaude Codeに任せるとき
– 「任せたいけど、重要な操作は自分で確認したい」というバランス型
バランスは良いが、コーディング作業を続けると「ファイル編集するたびに確認ダイアログが来る」のがストレスに感じる場合もある。その場合は次のacceptEditsが最適だ。
acceptEdits — 「コーディング最適化」モード
ファイル操作（Read/Write/Edit）を自動承認しつつ、Bashコマンドなど潜在的に危険な操作は引き続き確認を求める。
// settings.json
{
"permissions": {
"defaultMode": "acceptEdits"
}
}
こんなときに使う:
– ガッツリとコーディング作業をするとき
– ファイルの編集は任せたいが、コマンド実行は自分で確認したい
– 「defaultより快適にしたいが、bypassPermissionsはさすがに不安」というとき
# セッション開始時にacceptEditsモードで起動
claude --permission-mode acceptEdits
実際の開発で最もバランスが取れているモードとして、多くのユーザーに支持されている。ただし auto モードが正式リリースされれば、その役割を置き換える可能性がある。
dontAsk — 「明示的許可リスト」モード
あまり知られていないが、CI/CDや自動化に最も適した設計のモードだ。
動作の仕組み:
1. permissions.allow（settings.json）で事前承認されたツール → 実行
2. それ以外のツール → 確認ダイアログなしで拒否（静かに失敗）
// settings.json
{
"permissions": {
"defaultMode": "dontAsk",
"allow": [
"Read(*)",
"Write(src/**)",
"Bash(npm test)",
"Bash(npm run lint)"
]
}
}
こんなときに使う:
– CI/CDパイプラインにClaude Codeを組み込む
– 「テストの実行とログ解析だけに限定したい」というヘッドレス実行
制限事項: Claude Code CLI（settings.json）では誰でも利用可能。ただしClaude Agent SDKとして組み込む場合はTypeScript SDKのみ対応（Python SDK未対応）。CLIユーザーには制限はない。
bypassPermissions — 「完全自動化」モード
すべての権限チェックをスキップし、確認ダイアログなしで全操作を実行する。
// settings.json
{
"permissions": {
"defaultMode": "bypassPermissions"
}
}
Anthropicの公式スタンス: 「コンテナやVMなど完全に隔離された環境でのみ使用すること」
こんなときに使う:
– Dockerコンテナ内でのClaude Code自動化
– 一時的なCI/CDランナー（使い捨て環境）
– 個人のサンドボックス環境での実験・プロトタイピング
auto — 「AI判断」モード ⭐ Research Preview（2026年3月）
2026年3月、Anthropicがリサーチプレビューとして投入した新モード。
従来のモードと根本的に違う点が一つある。Claude自身が各操作の危険度を評価し、承認が必要かどうかを決める。
動作の仕組み（※Anthropicは正確な判断基準を公式公開していない。以下は一般的な傾向）:
– 読み取り専用の操作 → 自動実行
– 外部ネットワーク接続を伴うコマンド → ユーザーに確認
– ファイルシステムへの広範なアクセス → Claudeが文脈を判断して決定
# Research Preview版での有効化
claude --enable-auto-mode
こんなときに使う:
– 日常の開発作業で確認ダイアログを減らしたい
– acceptEditsより賢い自動化が欲しい
– AIに判断を任せながらも完全放棄はしたくない
コスト面の注意: autoモードはトークン消費が増加する。各操作前にClaude自身が「この操作に確認が必要か」を推論するため、レスポンスの遅延とコスト増が発生しうる。
dangerously-skip-permissions vs auto モード — 本質的な違い
これが本記事の核心だ。どちらも「確認ダイアログを減らす」方向性を持ちながら、その設計思想はまったく異なる。
dangerously-skip-permissions（= bypassPermissions）の考え方
人間の判断 → 完全排除
Claude → すべて実行してよい
このフラグは「環境ごと隔離することで安全を担保する」というアプローチだ。確認しないのではなく「壊れても困らない環境だから確認不要」という前提がある。
# CLIフラグで一時的に使う
claude --dangerously-skip-permissions
# または settings.json で永続化
{
"permissions": {
"defaultMode": "bypassPermissions"
}
}
安全のための前提条件:
– Dockerコンテナ / 使い捨てVM
– 本番データへのアクセスなし
– ネットワーク制限が別途かかっている
auto モードの考え方
人間の判断 → AIが代替
Claude → 危険度を評価して実行可否を決める
このモードは「AIの判断力を使って確認の必要性を減らす」というアプローチだ。環境の隔離は必要なく、Claudeが文脈を理解して適切な判断を下す。
claude --enable-auto-mode
想定される用途:
– 通常のローカル開発環境
– 本番に繋がっていない開発マシン
– 「頭を使いたくないが環境を隔離する手間もかけたくない」ケース
比較表: どちらを選ぶべきか
| 観点 | dangerously-skip-permissions | auto モード |
|---|---|---|
| 安全の担保 | 環境の隔離（コンテナ等） | Claudeの判断 |
| 危険操作への対応 | すべて実行（Deny設定で補完） | 危険と判断した操作は確認 |
| トークンコスト | 増加なし | 増加（推論コスト） |
| 利用環境 | 完全隔離環境が必須 | ローカル開発でも使用可 |
| 現在の状態 | 安定版 | Research Preview |
| 向いているユーザー | CI/CD・コンテナ活用者 | 日常開発で快適さを求める人 |
一言で言うなら:
– dangerously-skip-permissions = 「環境が安全だから何でもやっていい」
– auto = 「AIが判断するから確認しなくていい」
dangerously-skip-permissions の正体
改めて整理すると、dangerously-skip-permissionsはbypassPermissionsモードのCLIエイリアスだ。
# この2つは同じ意味
claude --dangerously-skip-permissions
claude --permission-mode bypassPermissions
なぜ怖い名前のフラグが存在するのか？Anthropicの設計意図として「このフラグを使うときは十分理解してから使え」という警告が込められている。一時的な有効化（CLIフラグ）と永続化（settings.json）を使い分けることで、「まず試してから組み込む」というワークフローを促す意図もある。
ユースケース別の選び方
ケース1: 通常の対話型開発
推奨: acceptEdits（現在）/ auto（Research Preview解禁後）
理由: ファイル編集は自動で快適に。Bash操作は確認できて安心。
ケース2: コードレビュー・分析だけしたい
推奨: plan
理由: 変更不可でコード解析に専念。「壊れるのが心配」という不安がゼロ。
ケース3: CI/CDに組み込みたい（安全第一）
推奨: dontAsk + allowリスト明示
理由: 許可外の操作は拒否。予測可能で安全な自動化。
設定例:
{
"permissions": {
"defaultMode": "dontAsk",
"allow": ["Read(*)", "Bash(npm test)", "Bash(npm run build)"]
}
}
ケース4: Dockerコンテナで完全自動化
推奨: bypassPermissions（= --dangerously-skip-permissions）
前提: コンテナが壊れても問題ない隔離環境であること
設定例:
{
"permissions": {
"defaultMode": "bypassPermissions",
"deny": [
"Bash(curl * | bash *)",
"Bash(wget * && bash *)"
]
}
}
ケース5: ローカル開発で確認ダイアログを最小化したい（新）
推奨: auto（Research Preview）
前提: Claude Code最新版で --enable-auto-mode が使えること
注意: Research Preview段階のため、本番ワークフローへの組み込みは慎重に。
安全な設定パターン — Deny設定との組み合わせ
bypassPermissionsやacceptEditsを使う場合でも、Layer 1のDeny設定を組み合わせることで安全性を高められる。
個人開発向け最小Deny設定
{
"permissions": {
"defaultMode": "acceptEdits",
"deny": [
"Bash(rm *)",
"Bash(rm -r*)",
"Bash(rm -rf*)",
"Bash(git reset --hard *)",
"Bash(git push --force*)"
]
}
}
bypassPermissions + 最低限のガード
{
"permissions": {
"defaultMode": "bypassPermissions",
"deny": [
"Bash(rm -rf *)",
"Bash(curl * | bash *)",
"Bash(wget * -O- | sh *)",
"Bash(sudo *)"
]
}
}
Anthropic公式の推奨: devcontainerの活用
Anthropicは完全自動化のためのリファレンス実装として公式devcontainerを提供している。このコンテナには以下が事前設定されている：
- ファイアウォールルールで外部接続をnpmレジストリ・GitHub・Claude APIなど必要なサービスのみに制限
- デフォルト拒否のネットワークポリシー
- この環境なら
dangerously-skip-permissionsを安心して使えると公式ドキュメントで明記
Agent Teams での注意点
Claude Codeで複数エージェントを並列実行する場合、チームメイトはリーダーのパーミッション設定を継承する。
リーダーが --dangerously-skip-permissions
→ 全チームメイトも bypassPermissions で動作する
これはパワフルな反面、意図せず全エージェントが制約なしに動く状態になりうる。Agent Teams使用時は特にDeny設定でのLayer 1防御が重要だ。
まとめ
dangerously-skip-permissionsはbypassPermissionsモードへのCLIショートカットであり、「環境の隔離を前提にすべての操作を自動化する」モードだ。
2026年3月に登場したautoモードはこれとは異なり、「Claudeが各操作の危険度をAIで判断する」新世代のアプローチ。どちらも「確認ダイアログを減らす」が、安全担保の方法が根本的に異なる。
| 使いたいとき | 選ぶモード |
|---|---|
| 安全にコード分析 | plan |
| 普通に開発 | default |
| コーディング快適に | acceptEdits |
| CI/CD（明示的制御） | dontAsk + allowリスト |
| 隔離環境での完全自動化 | bypassPermissions / dangerously-skip-permissions |
| ローカルで賢い自動化（Preview） | auto |
3層防御（Deny設定・スコープ制限・モード選択）を組み合わせることで、どのモードも安全に活用できる。dangerously-skip-permissionsも怖い名前に惑わされず、適切な環境で使えば強力なツールだ。
コメント