「Codex側もpermissionsを強化してるみたいだけど、Claude Codeとどう違うんですか」 — 企業導入の場で出る質問です。両者ともAIエージェントの権限管理は重要視していて、設計の方向性に差が出てきました。
この記事は、CodexのPermission Profilesと、Claude Codeのpermissionsの違いを整理したものです。
Codex Permission Profilesは「継承可能な権限テンプレ」
Codexの権限管理は、最近 Permission Profiles という枠組みで整理されました。
特徴は3つあります。
ひとつめは、list APIs。複数のプロファイル(=権限の組み合わせのテンプレート)を一覧で管理できる仕組みが入りました。
ふたつめは、inheritance(継承)。あるプロファイルを「親」として、子プロファイルがその設定を引き継げる。組織で共通設定を作って、プロジェクトごとに差分だけ持つ、という運用が組みやすくなりました。
みっつめは、managed requirements.toml。プロファイルの中身を構造化されたファイルで管理できる作り。社内ポリシーの一元管理に効きます。
加えて、Windows sandbox integration が強化され、/permissions 表示で named permission profile が明示される、というUI改善も入っています。
Claude Codeのpermissionsは「Settings + permission modes」
対するClaude Code側は、permissionsをsettings.jsonと、permission modes(動作モード)の組み合わせで管理する設計です。
.claude/settings.json に許可(allow)・確認(ask)・拒否(deny)のルールを書く形式。permission modesはShift+Tabで切り替わる動作モード(通常・自動承認・プランなど)で、設定とモードを組み合わせて運用します。
設定ファイルとモード切替の2軸、というのがClaude Code側のアプローチ。
設計思想の差
両者を表で並べます。
観点 | Codex Permission Profiles | Claude Code permissions |
|---|---|---|
構造 | プロファイル単位(継承可能) | settings.json + permission modes |
共有 | 親プロファイル・子プロファイル | リポジトリ.claude/settings.jsonをコミット共有 |
動的切替 | プロファイル切替 | Shift+Tabでモード切替 |
構造化管理 | managed requirements.toml | JSON記述 |
Windows対応 | sandbox integration強化 | settings.jsonは共通 |
Codexは「テンプレートの継承」、Claude Codeは「設定ファイル+モード切替」。Codex側のほうがエンタープライズ寄りの設計、と言えます。
エンタープライズ導入で効くのは
権限管理の話は、5人くらいの小さなチームでは「全員許可で運用」で済むことが多い。実際に効いてくるのは、20人以上のチームか、複数プロジェクトの並走です。
CodexのPermission Profilesが効くのは、組織で共通の権限ポリシーを敷きたい場面。「全社員はこの権限まで」「開発部署はこれを追加」「人事部署はこちらだけ」という重ね方が、継承機能で素直に表現できます。
Claude Codeのほうは、プロジェクト単位の設定ファイルをGitで共有して回す運用が現実的。リポジトリごとに .claude/settings.json を含めれば、関わる全員に同じ設定が配布される。シンプルです。
「組織横断のポリシーが多いならCodex」「プロジェクト単位で完結するならClaude Code」、という分け方が現実に近い。
私の使い分けの実例
参考までに、いまの私の運用です。
このSEOメディア(claudecodelab.jp)の運用はClaude Code側。.claude/settings.json をリポジトリにコミットしておけば、関わる人(私だけですが)に同じ設定が回ります。シンプルで運用負担なし。
業務委託先の大規模な案件はCodex側で対応。複数のサブプロジェクトがあって、組織共通のセキュリティポリシーと、プロジェクト固有の追加権限を分けて管理したい時、Codexのプロファイル継承が便利です。
両方触ると性格の違いがはっきり出る、というのが正直なところです。
安全運用の3層チェック
権限管理だけでなく、AIエージェントの安全運用には全体としての設計が要ります。私はClaude Codeのpermissionsを第1層に、pre-commit hookを第2層に、CIを第3層に置く構成を推奨しています。
CodexのPermission Profiles + sandbox integrationも、この3層の中の第1層に置く設計と相性がいい。ツールの違いはありますが、3層構造の発想は両者に通じます。
まとめ
- CodexのPermission Profilesは「継承可能なテンプレ」「list APIs」「managed requirements.toml」
- Claude Codeのpermissionsは「settings.json + permission modes」の2軸
- Codexはエンタープライズ寄り、Claude Codeはプロジェクト単位の運用に振っている設計
- 組織横断ポリシーが多いならCodex、プロジェクト完結ならClaude Code
- Claude Code側はリポジトリにsettings.jsonをコミットすれば全員に配布できる手軽さ
- どちらも安全運用3層チェックの第1層として位置づけられる
