Claude Media
AIコーディングエージェント 権限モデル比較 — Claude Code・Codex・Cursor・Devin

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つの権限モード(defaultacceptEditsplanautodontAskbypassPermissions)を切り替える方式です。Pro・Max・Teamプランではautoモードが既定になっており、承認プロンプトの代わりにSonnet 5をベースにした分類器が個々のアクションを審査します。分類器はpermissions.allowaskdenyのルールが評価された後に呼ばれる二段構えで、autoMode.environmentに記述した信頼済みリポジトリやドメインの情報を読んで判定材料にします。権限モードとは別に、Bashコマンドの実行範囲を絞るサンドボックスの仕組みも独立して存在し、この2層構成はClaude Codeのサンドボックス設計にまとめています。

Codex CLIはOpenAIが提供するCLIで、approval_policy(on-requestuntrustednever)とsandbox_mode(read-onlyworkspace-writedanger-full-access)という2軸の設定値で権限を組み立てます。判定はすべて事前に決めた設定値どおりに進み、実行中に別モデルが個々のアクションを審査する仕組みは持ちません。ネットワークアクセスは既定でオフで、有効にするには設定ファイルへの明示的な記述が必要です。

CursorはCLI設定ファイル(~/.cursor/cli-config.jsonまたはプロジェクト単位の.cursor/cli.json)に、ShellReadWriteWebFetchMcpという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 CodeCodex CLICursorDevin
権限の組み立て方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_policysandbox_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点は、導入前に必ず確認する価値があります。設定ファイルの書式やコマンド名は製品ごとに異なるため、比較表の項目をそのままチェックリストとして使い、自分のチームの運用フローに当てはめて確認するのが実務的です。

この記事を共有:XはてブLinkedIn