まず結論
最初に越えるべき壁が security / compliance review なら、Codex から始める方が通しやすい。最初に必要なのが、1つの engineering team を worktree、devcontainer、隔離 repo の中で安全に試し始めることなら、Claude Code から始める方が自然だ。
2026-05-09 時点での違いは、思想論というより rollout model の違いである。今回確認した公開資料では、Codex の強みは first-party compliance path がより明確なことだ。managed network policy、workspace-bound authentication、Compliance Platform visibility が一続きの話として見える。Claude Code の強みは local control surface の分かりやすさだ。明示的な path rule、読みやすい permission mode、OS-level sandboxing、そして OpenTelemetry から SIEM へ流す monitoring path が文書化されている。
大まかな判断を先に置くなら、次の4点で足りる。
- security / platform team が広範 rollout 前に centralized visibility と first-party compliance path を欲しがるなら Codex
- developers が repo 単位や machine 単位で filesystem / network boundary を調整したいなら Claude Code
- どちらも secret が多い production checkout で最初から安全だと見なしてはいけない
- 最初の pilot は、どちらを使うにせよ isolated worktree、throwaway clone、devcontainer を優先するべきだ
すぐ判断するための表
| 優先したいもの | 選ぶべきもの | 理由 |
|---|---|---|
| centralized compliance log と agent-level visibility | Codex | OpenAI は OpenTelemetry export と Enterprise / Edu 向け Compliance Platform availability を公開しており、今回見たソースの中ではこちらがより turnkey な compliance path になっている |
| 細かい local sandbox path control | Claude Code | Anthropic は allowWrite、denyRead、allowRead、denyWrite、そして OS level で効く managed sandbox 設定を明示している |
| known-good destination に寄せた managed network policy | Codex | OpenAI は expected destination を許可し、unknown domain には approval を要求し、workspace-tied auth と組み合わせる outbound policy を説明している |
| developers 自身が読んで調整できる permission model | Claude Code | Anthropic は plan、acceptEdits、auto、dontAsk、bypassPermissions と allow / ask / deny rule を公開している |
| security-team-first の rollout | Codex | 現時点の公開資料では、OpenAI の方が Compliance Platform access と workspace-bound control を turnkey に語っている。一方 Anthropic 側は managed settings、settings audit logs、self-routed OTel telemetry という形でより明示的だ |
| isolated worktree / devcontainer での developer-first pilot | Claude Code | 現在の docs は sandbox mechanics、escape hatch、per-path restriction の説明がより分かりやすい |
今週、何が比較を意味あるものにしたのか
この比較を今やる理由は、抽象的に「AI coding が盛り上がっているから」ではない。直接のきっかけは、具体的な documentation update である。
2026-05-08 に OpenAI は、内部で Codex をどう安全に運用しているかを説明する詳細な安全記事を公開した。重要なのは、これまでの Codex 記事が capability 寄りだったのに対し、今回の文書は governance を operational terms で語っていることだ。この更新で、team evaluation にそのまま使える4つの主張が出た。
- sandboxing と approvals は別レイヤーである
- network access は managed であり、open-ended ではない
- requirements は Codex の複数 surface にまたがって admin-enforced にできる
- agent-native telemetry は export して review できる
Anthropic の Claude Code docs も、この比較から外せない。なぜなら local execution と team rollout の両方にまたがる control surface がすでに文書化されているからだ。OS-enforced sandboxing、path-level read / write rule、domain allowlist、permission mode、managed settings、OpenTelemetry export、そして broad Bash access や弱い network filtering が作る bypass risk まで明示されている。
この2組の docs を並べて初めて、team が本当に知りたい問いに近づく。実際の repo に最初に触らせる coding agent はどちらか。
Codex がいま優位な点
1. centralized governance の公開ストーリーが強い
OpenAI の 2026-05-08 安全記事は、enterprise control についてかなり具体的だ。記事によれば、Codex は次のような要素とともに deploy できる。
- admin-enforced requirements
- managed network policy
- secure OS-keyring credential storage
- workspace-pinned ChatGPT authentication
- sandbox 外の shell command に対する rule-based handling
- desktop、CLI、IDE extension をまたぐ coverage
これは単に「VM に閉じ込めればよい」という話より、現実の enterprise rollout で問われる control surface に近い。複数の surface をまたいで、1つの baseline policy と workspace-bound auth、さらに Compliance Platform visibility を組み合わせる方向に Codex が置かれていることが分かる。
2. より turnkey な compliance logging path
これが今回の比較における Codex の最も分かりやすい優位点だ。ただし、その意味は「Codex には telemetry があり、Claude Code にはない」ではない。
OpenAI は Codex が OpenTelemetry log export をサポートし、user prompt、approval decision、tool execution result、MCP server usage、network proxy の allow / deny event を出せると説明している。さらに、Codex activity は OpenAI Compliance Platform を通じて Enterprise / Edu customer に提供されると明記している。
一方で Anthropic の Claude Code docs も、OpenTelemetry metrics、logs、events を公開しており、user prompt、tool decision、tool result、MCP activity、SIEM export を含む。加えて server-managed settings と settings change audit logging も文書化している。今回の source set における差は telemetry の有無ではなく、より turnkey な first-party compliance path として提示されているかどうかだ。
もしボトルネックが model quality ではなく auditability なら、この違いは実務上かなり大きい。多くの security team は「file が変わった」だけでは足りない。知りたいのは例えば次のことだ。
- user は何を依頼したのか
- agent はなぜその tool を実行したのか
- approval は自動だったのか、人手だったのか
- network request は block されたのか、allow されたのか
OpenAI は、そうした event から compliance review へつなぐ first-party path をより短く公開している。
3. compliance-heavy pilot の説明が短く済む
pilot の前に security / compliance team からの質問へ答えなければならないなら、Codex は現時点で説明の導線が短い。
- bounded sandbox
- managed outbound policy
- approval flow
- centralized logs
これは Codex があらゆる環境で本質的に安全だという意味ではない。強みは、rollout owner が individual developer ではなく platform / security side にある時、導入理由をより短く説明できることにある。
Claude Code がいま優位な点
1. local sandbox control がより明示的
developer の視点で見ると、今回の比較で最も boundary を理解しやすい公開資料は、依然として Anthropic の sandboxing docs だ。
2026-05-09 時点で、Anthropic は Claude Code の sandboxing が次を強制できると文書化している。
- default では current working directory にだけ write access を与える
sandbox.filesystem.allowWriteで追加の writable path を許可する- read access に deny / allow list を設定する
- 外部 proxy を通じて access 可能な domain を制限する
- macOS では Seatbelt、Linux / WSL2 では bubblewrap による OS-level enforcement を行う
rollout を考える時、これは大きい。developers は product-language の抽象語ではなく、path と domain で boundary を理解できるからだ。
2. permission mode が読みやすい
Anthropic の permission model はかなり率直に書かれている。現在の docs では次の mode が公開されている。
planacceptEditsautodontAskbypassPermissions
各 mode の tradeoff も明示されており、bypassPermissions は isolated environment でしか使うべきではない、とかなりはっきり警告している。
そのため Claude Code は、developer が autonomy の速度を自分で制御したい repo pilot に向いている。team は plan から入り、通常の prompt へ進み、task boundary が安定してから auto を試せる。
3. failure mode の説明がより率直
Anthropic の docs は failure mode の書き方が強い。次の点をはっきり警告している。
- sandboxing には filesystem と network の両方の isolation が必要
- broad な allowed domain は exfiltration path を作りうる
- built-in proxy filtering は TLS inspection をしない
ReadとEditの deny rule は Bash subprocess のcatなどを止められない- unsandboxed command を無効化しない限り escape hatch が残る
この手の文書が useful なのは、残っている risk を見えにくくしないからだ。
本当に比較すべき4つの control surface
サンドボックス境界
| 質問 | Codex | Claude Code |
|---|---|---|
| sandboxing は文書化された safety model の一部か | はい。OpenAI は sandboxing を、write、protected path、network reachability を制御する technical execution boundary として説明している。 | はい。Anthropic は filesystem / network isolation を持つ OS-enforced sandboxing を文書化している。 |
| team はこの boundary を中央管理できるか | はい。OpenAI は managed requirements と managed preferences を説明している。 | はい。managed settings を通じて可能。ただし公開 docs は centralized observability より local / repo-level の config detail を強調している。 |
| filesystem model は developer 向けに十分深く説明されているか | 一部はある。主に safety post と周辺 config docs に分かれている。 | はい。path semantics と example がかなり具体的。 |
Codex は governance framing に強い。Claude Code は boundary explainability に強い。
承認モデル
| 質問 | Codex | Claude Code |
|---|---|---|
| low-risk work を friction 少なく進められるか | はい。OpenAI は routine request に auto-review を使えると述べている。 | はい。Anthropic は acceptEdits、auto、標準 allow rule を提供している。 |
| より高リスクの action を review に回せるか | はい。OpenAI は sandbox や policy boundary を越える時の approval を説明している。 | はい。Anthropic は deny / ask / allow rule で routing し、Bash や file edit に prompt を要求できる。 |
| developers が仕組みを直接理解しやすいか | 今回使った source では detail がやや少ない。 | 現在の公開 docs の方が明示的。 |
Codex は managed approval workflow に向く。Claude Code は developer が自分で policy を調整する時に理解しやすい。
ネットワーク制御
| 質問 | Codex | Claude Code |
|---|---|---|
| 推奨 setup で outbound access は open か | いいえ。OpenAI は managed network policy と unfamiliar domain への approval を説明している。 | いいえ。sandbox network control を有効にした場合、Anthropic は host allowlist と managed-domain-only behavior を文書化している。 |
| docs は network-policy の限界を警告しているか | はい。ただし high-level。 | はい。domain fronting や TLS-inspection caveat まで含めてより詳しい。 |
| custom proxy logic は文書化されているか | OpenAI は safety post の中で managed proxy policy に触れている。 | Anthropic は custom proxy configuration を明示している。 |
どちらも network boundary は絞れる。Claude Code の docs の方が、network layer だけでは何を証明できないかをより明示している。
監査とテレメトリー
| 質問 | Codex | Claude Code |
|---|---|---|
| agent-native telemetry export は公開文書化されているか | はい。2026-05-08 の OpenAI post で OpenTelemetry export が説明されている。 | はい。Anthropic は OpenTelemetry metrics / logs / events、optional traces、SIEM export を Claude Code 向けに文書化している。 |
| first-party な enterprise compliance log path は公開文書化されているか | はい。OpenAI は Compliance Platform を明示している。 | 部分的にはある。Anthropic は SIEM export と server-managed settings の audit logging を説明しているが、今回の source には Compliance Platform に相当する first-party platform は出てこない。 |
| security team が意図を復元したい時、どちらがより向くか | first-party compliance surface が欲しいなら Codex の方が向く。 | 自前の SIEM に OTel event を流し、pipeline を組み立てる前提なら Claude Code も向く。 |
今回の source set で最も大きい違いは、packaging であって telemetry の有無ではない。
どんな team が Codex から始めるべきか
次の条件に多く当てはまるなら、先に Codex を試す方が自然だ。
- security team が広範 rollout 前に centralized telemetry を欲し、first-party compliance surface を好む
- desktop、CLI、IDE をまたぐ policy baseline と workspace-bound auth が必要
- network egress を managed allowlist の中に閉じ込める必要がある
- organization が compliance log、SIEM ingestion、admin-enforced control の発想で動いている
- pilot owner が platform / security function であり、単独の engineering team ではない
Codex の first pilot は、例えば次のような shape がよい。
- 1つの low-risk repository か disposable worktree
- test fix、docs update、review-comment follow-up のような bounded task class
- 1つの managed network policy
- approval exception を扱う review workflow
- session class ごとの log review
どんな team が Claude Code から始めるべきか
次の条件に多く当てはまるなら、先に Claude Code を試す方が自然だ。
- developers が sandbox を自分で理解し、調整したい
- repo-level path rule や local machine boundary の方が first-party compliance surface より重要
- worktree、devcontainer、その他の isolated local environment で pilot を回すつもりがある
- approval fatigue を減らしたいが、unrestricted Bash は渡したくない
- allow / ask / deny のような obvious な rule type で permission model を運用したい
Claude Code の first pilot は、例えば次のような shape がよい。
- throwaway branch か worktree
planmode から始めるautoの前に sandbox を有効にする.env、deploy path、git pushに対して明示的な deny rule を入れる- narrow な verification command を1つに絞る
どちらにも共通する minimum safe pilot
product name に気を取られない方がよい。rollout shape の方が、しばしば product choice そのものより重要になる。以下の5つは両方に通用する。
1. isolated repo copy から始める
worktree、throwaway clone、devcontainer を使う。live secret、release script、無関係な作業中 change を抱えた checkout で最初から始めてはいけない。
2. allowed path を先に名前で固定する
良い policy language は退屈で具体的だ。
Allowed paths:
- src/api
- tests/api
- docs/api-migration.md
Forbidden paths:
- .env*
- deployment/
- infra/
- scripts/release/
- package.json
- lockfiles
3. autonomy 開始前に stop rule を置く
例えば次のような stop list を最初に決める。
Stop and ask before:
- pushing or merging
- changing secrets or auth config
- opening billing or admin settings
- installing new dependencies
- contacting a new external domain
- touching more than 5 files outside the allowed paths
4. verification command は1本に絞る
初期 pilot では、focused な verification command が1つあれば十分だ。例としては次のようなものがある。
npm test -- api-client
pnpm lint src/api tests/api
変更の妥当性を証明するために agent がもっと広い command set を必要とするなら、pilot scope が緩すぎる可能性が高い。
5. final diff は人間が review する
どちらの product も merge gate として扱うべきではない。pilot が成功したと言えるのは、人間がすばやく次の3点に答えられる時だ。
- 何が変わったか
- なぜ変わったか
- 実際に何を検証したか
ロールアウトシナリオ別の推奨
シナリオ 1: 開発者の便利さより先にセキュリティレビューが来る場合
Codex を選ぶ。
OpenAI の safety post と Compliance Platform reference は、approval flow、workspace-bound auth、network policy、telemetry export に関する governance question に、より短く答えられる。もちろん本当の内部 review の代わりにはならないが、security stakeholder に対する public control narrative はより turnkey だ。
シナリオ 2: 全社 rollout を待たずに、1つの engineering team を先に動かしたい場合
Claude Code を選ぶ。
sandbox と permissions docs が十分に具体的なので、小さな team が worktree や devcontainer の中で disciplined pilot を設計しやすい。実際以上に lock-down されているふりをしなくてよい。
シナリオ 3: まずローカル実験を行い、その後の全社標準を考えたい場合
最初の local experiment は Claude Code で始め、その先で widening rollout の阻害要因が first-party compliance path だと分かった時点で Codex を再評価する。
シナリオ 4: コンプライアンスレビューへ最短でつなぎたい場合
Codex を選ぶ。
今回の公開証拠で見る限り、Codex の方が first-party compliance path が明確だ。OpenAI は telemetry と Compliance Platform を一緒に提示している。Claude Code はもはや「weak auditability」ではないが、public story は OTel-and-SIEM oriented だ。
よくある質問
エンタープライズセキュリティの観点では、Codex と Claude Code のどちらが向くか
security review が first-party compliance logging、workspace-bound auth、managed network policy から始まるなら、Codex の方が推しやすい。Claude Code も enterprise use は可能だが、公開ストーリーは self-managed 寄りだ。managed settings、OpenTelemetry events、SIEM export はあるが、OpenAI-style の Compliance Platform ではない。
小規模な engineering team の最初の pilot にはどちらが向くか
多くの場合は Claude Code だ。plan、acceptEdits、sandbox path rule、deny rule、明示的な network-domain control など、local boundary を読むための材料が多い。company-wide standardization の前に、まず1つの team が動き始めたい時に向いている。
プラットフォームチームはどちらを先に標準候補として扱うべきか
standardization の起点が first-party compliance plumbing、workspace-bound auth、managed network policy なら、Codex の方が先に推しやすい。起点が local development ergonomics と self-managed OTel / SIEM workflow なら、Claude Code を disciplined sandbox で先に試す方がよい。
全体として、Codex の方が Claude Code より安全なのか
そうとは限らない。何を最適化するかによって答えが変わる。現在の公開 docs では、Codex は first-party compliance workflow に強く、Claude Code は local sandbox detail と policy explainability に強い。最終的な risk を左右するのは brand より rollout shape だ。
どちらの tool でも、production secret を含む repo を安全に扱えるか
初期前提としては no と考えるべきだ。Anthropic の docs は file-tool deny rule が Bash subprocess の read を止めないと明示しているし、OpenAI の Codex guidance も approval と sandboxing を保護モデルの一部として前提にしている。active working tree から secret を外すか、pilot をよりクリーンな environment に移してから進める方が安全だ。
検証メモ
検証日：2026-05-09。
確認した項目：
- OpenAI の Running Codex safely at OpenAI で、managed configuration、approvals、network policy、secure credential handling、OpenTelemetry log export、Compliance Platform reference を確認
- Anthropic Claude Code Sandboxing docs で、filesystem / network isolation、OS-level enforcement、allow / deny path control、unsandboxed-command escape hatch、network-policy limitation を確認
- Anthropic Claude Code Permissions docs で、mode 定義、allow / deny rule、Bash rule behavior、file-tool deny rule が Bash subprocess access を止めないという警告を確認
- Anthropic Claude Code Monitoring docs で、OpenTelemetry metrics / logs / events、SIEM export、prompt、tool decision、tool result、MCP activity の event model を確認
- Anthropic Claude Code Server-managed settings docs で、centrally managed policy delivery と settings change audit logging を確認
主要ソース：
- OpenAI: https://openai.com/index/running-codex-safely/
- Anthropic Claude Code sandboxing docs: https://code.claude.com/docs/en/sandboxing
- Anthropic Claude Code permissions docs: https://code.claude.com/docs/en/permissions
- Anthropic Claude Code monitoring docs: https://code.claude.com/docs/en/monitoring-usage
- Anthropic Claude Code server-managed settings docs: https://code.claude.com/docs/en/server-managed-settings