AICLI CHEATS ● 基礎知識 04 · AI CLI の権限モード総まとめ 最終更新 2026.05.17
04
基礎知識 / FUNDAMENTALS

AI CLI の権限モード総まとめ

Claude Code、Codex CLI、Gemini CLI、Copilot CLI の「全部承認スキップ」フラグを横並びに比較。何が違って、どれが本当に危険なのか。

公開 2026.05.17

AI CLI を業務で触り始めるとほぼ全員がぶつかる問題がある。「承認プロンプトが多すぎて手が止まる」「でも全部スキップするフラグは怖い名前がついている」。各ツールがその答えとして用意しているフラグを並べると、危険度のグラデーションが見えてくる。

各ツールの「全承認スキップ」フラグはこう呼ばれている。

ツールフラグ名前から伝わる温度感
Claude Code--dangerously-skip-permissions「危険」と公式が言ってる
Codex CLI--full-auto + --sandbox danger-full-accessフル自動 + 危険サンドボックス
Gemini CLI--yoloYou Only Live Once
GitHub Copilot CLI--allow-all-tools / /yolo全ツール許可

名前のつけ方は違うが、要するに全部「Enter 押す前にもう一度考えろ」というやつ。

なぜ承認プロンプトがあるのか

LLM エージェントは指示の解釈を間違えることがある。「依存関係を整理して」と言ったら package.json を消すコードを実行する、みたいな事故が普通に起こる。承認プロンプトは、その実行直前に人間が見て止められる最後のチェックポイント。

問題は、安全な操作（ls、git status、ファイル読み込み）にも承認が出ることが多くて、流れ作業になってしまう点。流れ作業になると、危険な操作も流してしまう。だから「安全なものは事前許可、危険なものだけ毎回確認」というのが理想形。

各ツールの承認スキップ方式の違い

Claude Code

claude --dangerously-skip-permissions

全ツールが事前承認なしで実行される。設定ファイル（.claude/settings.json）で allow / deny リストを書く方法もあって、これだと「Read は事前許可、Bash(rm) だけ拒否」のような細かい制御ができる。

破壊力の制御: 細かい制御は設定ファイル側、--dangerously-skip-permissions は全部許可。中間がない。

Codex CLI

承認モードとサンドボックスが独立している。

codex --approval-mode full-auto --sandbox workspace-write

これだと「ファイル編集もコマンド実行も自動でやるが、ホスト全体には書けない」という中間状態を作れる。本当に何でも許すのは:

codex --full-auto --sandbox danger-full-access

ここまでやって初めて Claude Code の --dangerously-skip-permissions と同等の権限になる。

破壊力の制御: 承認とサンドボックスを別軸で持つので調整しやすい。

Gemini CLI

gemini --yolo

全部スキップ。ストレートな実装。サンドボックスは --sandbox で別途指定。

gemini --yolo --sandbox

--sandbox 単独だと「サンドボックス内で全自動」になる。これでもホスト書き込みは制限される。

破壊力の制御: --yolo 単独はホストにも書ける。サンドボックスとの組み合わせで安全度を上げる発想。

GitHub Copilot CLI

copilot --allow-all-tools
copilot --allow-tool='shell(npm test)'
copilot --deny-tool='shell(rm)'

--allow-tool / --deny-tool で個別指定ができる。「shell(npm test) だけは毎回承認なし、それ以外は通常通り承認、shell(rm) は完全拒否」みたいな運用がやりやすい。

破壊力の制御: 全許可と細粒度許可・拒否がフラグレベルで揃っている。

横並び比較

項目Claude CodeCodex CLIGemini CLICopilot CLI
全承認スキップ--dangerously-skip-permissions--full-auto--yolo--allow-all-tools
細粒度 allow設定ファイルconfig.toml設定ファイル--allow-tool
細粒度 deny設定ファイルconfig.toml設定ファイル--deny-tool
サンドボックス明示なし（OS依存）3段階 (read-only/workspace-write/danger-full-access)--sandbox フラグ(実装は内部)
セッション中の全許可設定変更が必要設定変更が必要設定変更が必要/yolo

実運用での使い分け

ホスト環境で常用するとき

全部スキップ系のフラグは使わない。承認プロンプトをうるさく感じたら、安全なコマンドだけ事前許可リストに足す。Copilot CLI なら --allow-tool='shell(npm test)' のように、Claude Code なら .claude/settings.json の allow リスト、Gemini と Codex も同様。

隔離環境（VM、Docker）で長時間タスクを任せるとき

このときは全スキップ系を使ってよい。前提として:

  1. ホストへの影響がないことが完全に保証されている
  2. ネットワーク経由で外部に何を送られても困らない
  3. 環境ごと捨てる前提

特に 3 が重要。エージェントが意図せず外部 API を叩き続けて課金が膨らむケースがあるので、コスト上限も忘れずに。

CI で実行するとき

CI 環境はそれ自体が隔離環境だが、別の問題がある。CI のシークレット（デプロイキー、本番DB認証など）にエージェントがアクセスできてしまう。CI で全スキップ系を使うときは、シークレットを渡さない別のジョブとして分離するか、エージェントから見えない場所に置くこと。

名前に込められた温度感

並べてみると、各ツールの命名にはチームの思想が透ける。

  • Claude Code の --dangerously-skip-permissions は「危険」と明言。フラグ名で躊躇させる作り
  • Codex の danger-full-access も同じ思想。サンドボックスの選択肢として「danger-」がつく
  • Gemini の --yolo は割り切ったネーミング。冗談めかしているが、結果は同じ
  • Copilot の --allow-all-tools は機能名そのまま。中立的

どれを使うにせよ、フラグ名を見て「あ、これはまずいやつだ」と毎回思える状態を保ったほうがいい。alias で claude --safe みたいな別名に隠すと、感覚が麻痺する。

関連記事