AIコーディングエージェント 権限モデル比較 — Claude Code・Codex・Cursor・Devin
Claude Code・Codex CLI・Cursor・Devinの権限モデルを、固定ルールか動的判定かという軸で比較。auto modeの分類器方式が何を変えたかも解説します。
権限モデルの分岐点は「誰が承認するか」
AIコーディングエージェントの権限モデルは、実行前の承認を固定ルールで決めるか、それとも動的な判定役に委ねるかで大きく2系統に分かれます。Codex CLIとCursorは、承認方針とサンドボックスの範囲を設定値で固定するルールベース型です。Claude Codeのauto modeとDevinのSmartモードは、ルールに加えて別のモデルが個々のアクションを都度審査する動的判定型を持っています。
この違いは、チームが権限設計にどれだけ手間をかける必要があるかに直結します。ルールベース型は動作が予測しやすい代わりに、新しい操作パターンが出るたびにルールを足す必要があります。動的判定型はルールを書いていない操作にも対応できる代わりに、判定役自体のコストと、判定理由がどこまで開示されるかという別の論点を抱えます。
比較する4つの権限モデル
比較対象を先に固定します。いずれも「エージェントに実行前の承認を求めるか、求めないか」を制御する仕組みですが、構成要素が異なります。
Claude Codeは6つの権限モード(default・acceptEdits・plan・auto・dontAsk・bypassPermissions)を切り替える方式です。Pro・Max・Teamプランではautoモードが既定になっており、承認プロンプトの代わりにSonnet 5をベースにした分類器が個々のアクションを審査します。分類器はpermissions.allow・ask・denyのルールが評価された後に呼ばれる二段構えで、autoMode.environmentに記述した信頼済みリポジトリやドメインの情報を読んで判定材料にします。権限モードとは別に、Bashコマンドの実行範囲を絞るサンドボックスの仕組みも独立して存在し、この2層構成はClaude Codeのサンドボックス設計にまとめています。
Codex CLIはOpenAIが提供するCLIで、approval_policy(on-request・untrusted・never)とsandbox_mode(read-only・workspace-write・danger-full-access)という2軸の設定値で権限を組み立てます。判定はすべて事前に決めた設定値どおりに進み、実行中に別モデルが個々のアクションを審査する仕組みは持ちません。ネットワークアクセスは既定でオフで、有効にするには設定ファイルへの明示的な記述が必要です。
CursorはCLI設定ファイル(~/.cursor/cli-config.jsonまたはプロジェクト単位の.cursor/cli.json)に、Shell・Read・Write・WebFetch・Mcpという5種類の権限トークンをallow・denyリストとして書く方式です。denyルールがallowルールより優先されます。この上に、確認を省いて自動実行する「Auto-Run」という上乗せの動作モードがありますが、コマンドの許可リスト自体は依然として固定ルールの集合です。
Devinは6つの権限モード(Normal・Accept Edits・Smart・Bypass・Autonomous・Plan)を持ちます。ルールの優先順位はDeny→Ask→Allow→Defaultの順で、Claude Codeと同じ「拒否が最優先」という設計です。特徴的なのはSmartモードで、ワークスペース内の編集は自動承認しつつ、それ以外の操作は「高速なモデルが安全性を判定」して処理します。AutonomousモードはCLIの--sandboxフラグとペアでのみ有効になり、OSレベルの隔離が実装する制限の範囲内でシェルコマンドとネットワーク取得を自動承認します。
評価軸: 固定ルールか、動的な判定役か
4つを比べる軸は次の5つに絞れます。
| 軸 | 見るポイント |
|---|---|
| 既定の起点 | 見るポイント対話セッション向けに作られているか、CIパイプライン向けに作られているか |
| 判定主体 | 見るポイント設定済みのルールだけで決まるか、実行時にモデルが個別に判定するか |
| サンドボックスとの関係 | 見るポイント権限モードとOSレベルの隔離が独立した仕組みか、一体で設計されているか |
| Git操作特有の制限 | 見るポイントforce pushやブランチ限定のような操作をどう既定で扱うか |
| 組織レベルでの上書き可否 | 見るポイント管理者側からルールを配布・固定できるか |
AIコーディングツール全体の選び方を先に押さえたい場合は、AIコーディングツール比較も参考になります。
比較表: 既定モード・判定方式・Git操作の制限
| 項目 | Claude Code | Codex CLI | Cursor | Devin |
|---|---|---|---|---|
| 権限の組み立て方 | Claude Code6つの権限モード切り替え | Codex CLIapproval_policy×sandbox_modeの2軸設定 | Cursor5種の権限トークン(Shell/Read/Write/WebFetch/Mcp)のallow・denyリスト | Devin6つの権限モード切り替え |
| 判定主体 | Claude Codeルール評価後、autoモードでは分類器モデルが個別判定 | Codex CLI設定値どおりの静的判定のみ | Cursor設定値どおりの静的判定のみ | Devinルール評価後、Smartモードでは高速モデルが個別判定 |
| サンドボックスとの関係 | Claude CodeBashサンドボックスと権限モードは独立に組み合わせ可能 | Codex CLIsandbox_modeが権限設定そのものの一部 | CursorAuto-Runは権限トークンの上乗せモード | Devin--sandboxフラグがAutonomousモードの前提条件 |
| force push等の扱い | Claude Codeautoモードで既定ブロック、明示的な指示があれば解除 | Codex CLIポリシー次第(danger-full-accessは非推奨) | Cursordenyルールで明示登録が必要 | DevinDeny→Ask→Allow→Defaultの優先順位で判定 |
| 組織レベルの配布 | Claude Code管理設定(managed settings)でルールを配布・固定可能 | Codex CLIプロファイル(beta)を配布可能 | Cursorプロジェクト単位の設定ファイルで共有 | Devinチーム向けの設定配布に対応 |
auto modeは、ルールベースの権限モデルをどう変えたか
Claude Codeのauto modeが他と違うのは、分類器がコード編集やGit操作だけでなく、会話中に述べた境界そのものを判定材料にする点です。「pushしないで」「レビューが終わるまで待って」と伝えると、既定のルールが許可する操作であっても分類器はそれをブロック信号として扱います。この境界はルールとして保存されるわけではなく、会話履歴から都度読み直される設計のため、コンテキストの圧縮でその発言が失われるとブロックが外れる可能性がある点は、固定ルール(denyルール)との明確な違いです。
DevinのSmartモードも「高速なモデルによる安全性判定」という発想は共通していますが、無人実行の主な安全策はモデル判定ではなくAutonomousモード+OSレベルのサンドボックスに寄っています。つまりClaude Codeは「モデルによる文脈読み取り」を、Devinは「OSによる物理的な隔離」を、それぞれ無人実行時の主軸に据えている違いがあります。CodexとCursorはどちらの動的な判定役も持たず、事前に書いたルールとサンドボックスの範囲だけで安全性を担保する設計です。
Claude Codeにはもう一段、権限モードそのものより手前で効く固定の防壁もありますが、その強さは対象によって異なります。rm -rf /のようにファイルシステムの根やホームディレクトリを狙う削除コマンドは、bypassPermissionsモードであっても確認を求められる設計です。一方、.gitや.claudeといったディレクトリへの書き込みは通常のモードでは確認対象になるものの、bypassPermissionsモードでは自動的に許可される点に注意が必要です。動的判定型のツールほど、こうした固定の下限をどこに引いているかが安全性の実質を左右します。設定ファイル全体の書き方はClaude Code settings.json完全ガイドで扱っています。
各モデルの強みと弱み
ルールベース型(Codex CLI・Cursor)の強みは、動作が完全に予測可能で監査しやすいことです。設定ファイルを読めば、その環境で何が起こり得るかを事前にすべて把握できます。弱みは、想定していなかった操作パターンが出るたびに、ルールを手動で追加しなければならないことです。
動的判定型(Claude Codeのauto mode・DevinのSmartモード)の強みは、ルールを書いていない未知の操作にもある程度対応できることです。プロダクトを跨いだ抽象的な危険パターン(シークレットの外部送信、本番環境への破壊的操作など)を、個別のコマンド名を列挙しなくても検出しようとします。弱みは、判定役自体のコストとレイテンシが発生することと、判定理由が常に詳しく開示されるとは限らないことです。Claude Codeの分類器は多くのセッションでBlocked by classifierという固定文言だけを返し、具体的な理由を書かないケースがあります。
使い分け早見表
| 用途 | 向いている権限モデル | 理由 |
|---|---|---|
| 動作を完全に予測可能な状態で運用したい | 向いている権限モデルCodex CLI(approval_policy固定)、Cursor(allow/denyリスト) | 理由事前設定どおりにしか動かないため監査しやすい |
| 未知の危険操作にもある程度備えたい | 向いている権限モデルClaude Code(auto mode)、Devin(Smartモード) | 理由モデルによる都度判定が固定ルールの穴を補う |
| CIパイプラインで完全無人実行したい | 向いている権限モデルCodex CLI(workspace-write+never)、Claude Code(dontAsk) | 理由事前承認済みの操作だけを許可し、それ以外は自動拒否する設計 |
| コンテナ内での完全自律実行を明示的に組みたい | 向いている権限モデルDevin(--sandbox+Autonomous)、Claude Code(bypassPermissions) | 理由OSレベルの隔離を前提にした専用モードを持つ |
| 組織全体でルールを固定配布したい | 向いている権限モデルClaude Code(managed settings)、Codex CLI(プロファイル) | 理由開発者側で緩められない拘束力を持つ配布経路がある |
よくある質問
Cursorのauto-runはClaude Codeのauto modeと同じ仕組みか
いいえ。CursorのAuto-Runは、あらかじめ設定した許可リストに載っているコマンドの確認を省く仕組みです。Claude Codeのauto modeのように、リストに無い未知の操作を別モデルが都度判定する仕組みは持っていません。
Codex CLIには危険な操作を止めるモデル判定はあるか
公式ドキュメントで確認できる範囲では、Codex CLIの承認はapproval_policyとsandbox_modeの設定値どおりに進む静的な仕組みです。Claude CodeやDevinのように、個別のアクションを別モデルが審査する機能は確認できていません。
Devinの権限モードはいくつあるか
6つです。Normal・Accept Edits・Smart・Bypass・Autonomous・Planで、このうちAutonomousは--sandboxフラグを付けたときだけ選べます。優先順位はDeny→Ask→Allow→Defaultの順で評価されます。
権限モデルを比較するときに、価格や実行速度より先に確認する価値があるのはどこか
既定でどこまで自動実行されるかと、force pushや本番デプロイのような取り消しにくい操作がブロック対象に含まれているかの2点です。ここが甘いまま自律度だけ上げると、意図しない操作が既定で通ってしまう構成になりがちです。
サンドボックスと権限モードは同じものか
いいえ、製品によって関係が違います。Claude Codeでは権限モードとBashサンドボックスは独立していて、組み合わせて使います。Codex CLIではsandbox_modeの値そのものが承認方針の一部を兼ねています。Devinでは--sandboxフラグを付けたときだけAutonomousモードが選べる、前提条件の関係です。比較するときはこの結合度の違いを見落とさないことが要点です。
4つの製品を同時に導入して比較検証する必要はあるか
必須ではありません。まずは自分のチームが実際に使っている1つの製品で、既定の権限モードが何を自動承認しているかをclaude auto-mode configのような確認コマンドで洗い出すところから始めると、他製品との比較軸も具体的に見えてきます。設定を変える前に現状把握を済ませておくと、後から挙動の変化を切り分けやすくなります。
まとめ
AIコーディングエージェントの権限モデルは、固定ルールで動作を決め切るか、動的な判定役に一部を委ねるかで設計思想が分かれます。Codex CLIとCursorは前者、Claude Codeのauto modeとDevinのSmartモードは後者に属し、それぞれ得意な失敗パターンが違います。監査のしやすさを優先するならルールベース型、未知の操作への耐性を優先するなら動的判定型が選択肢になります。
どちらの型を選ぶ場合でも、既定でどこまで自動実行されるかと、取り消しにくい操作がブロック対象に入っているかの2点は、導入前に必ず確認する価値があります。設定ファイルの書式やコマンド名は製品ごとに異なるため、比較表の項目をそのままチェックリストとして使い、自分のチームの運用フローに当てはめて確認するのが実務的です。