Claude Code vs OpenAI Codex CLI 徹底比較 2026｜ベンチ6軸・タスク10種・料金3シナリオで決める判断フレーム

Claude Code（Anthropic）と OpenAI Codex CLI は、ともにオープンソースのターミナル型コーディングエージェントです。表面的には似ていますが、2025 年後半から 2026 年前半にかけて両社のモデル世代が大きく入れ替わり、CLI の実装も Codex 側が Rust に書き換えられたことで、半年前の比較記事は前提条件から陳腐化しています。Anthropic は Claude Opus 4.7（2026-04-16）と Claude Sonnet 4.6（1M token context beta、2026-02-15）を、OpenAI は GPT-5.5 / GPT-5.2-Codex / GPT-5.1-Codex-Max を相次いで投入しました。

本記事は 2026 年 5 月時点の一次ソースに基づき、Claude Code と Codex CLI を「ベンチマーク 6 軸 / 機能 6 項目 / タスク特性 10 種 / 料金 3 シナリオ / エンタープライズ導入経路 / 移行マッピング / 併用ワークフロー」で中立に比較します。読者として想定しているのは、「どちらを選ぶか」を 30 秒で判断したい意思決定層、「移行や乗り換えを検討中の」現役エンジニア、「組織で導入したい」CTO・情シス・調達担当の 3 層です。検索意図のそれぞれに対して、ベンチマークスコア・機能差・コスト試算・移行手順・失敗事例まで、発注前に必要な判断材料を一度に揃えました。

免責事項: 本記事のモデル名・スコア・料金は本記事更新時点（2026-05-19）の各社公式およびコミュニティ調査ベースです。複数ソース間で数値の食い違いがあるベンチマークについては、本記事第 3 章末の「ベンチ数値の読み方」で別途整理しています。最終確認は各製品の公式ドキュメントで行ってください。本記事の数値は引用元（morphllm、datacamp、nxcode、Anthropic、OpenAI 各公式ページ）への直リンクを残しているため、リンク先で原典に当たれます。情報の鮮度を保つため、本記事は四半期に 1 度の見直しを目安に更新します。

結論 — 用途別の使い分け一覧（30 秒サマリー）

判断に迷ったときに最初に見る表です。10 個の典型シナリオを「Claude Code 寄り」「Codex CLI 寄り」「どちらでも可（既存契約で決める）」に分類しました。

「どちらか一方しか使えない」状況は実務ではほぼありません。むしろ併用パターン（本記事第 9 章で詳述）が現実解になるケースの方が多いことを覚えておいてください。両方の月次サブスクが負担になる場合でも、「設計＝Claude / 量産＝Codex」の分担で 1 ユーザーあたり実費を抑えられます。なお本記事では、製品名としての「Codex CLI」と OpenAI のコーディングモデル群を指す総称としての「Codex」を文脈に応じて使い分けます。CLI ツール固有の話題は「Codex CLI」、モデルやエコシステム全般を指す箇所は「Codex」と表記しています。

TL;DR — 7 行で読む Claude Code vs Codex CLI 2026

• モデル最高峰は Anthropic が Opus 4.7（SWE-Bench Verified 87.6% / Pro 64.3%）、OpenAI が GPT-5.5（SWE-Bench Verified 88.7%）。Verified は GPT-5.5 が 1.1pt リード、Pro は Opus 4.7 が 5.7pt リード。
• Terminal-Bench 2.0 は Codex CLI（GPT-5.5）77.3%、Claude Code 65.4% で約 12pt 差。Blind 評価 では逆に Claude Code が 67% 勝率、Codex CLI が 25%（残り 8% は同等）。
• トークン効率は同一タスクで Codex CLI が 約 4 倍少ない（Figma クローン: Claude 6.2M / Codex 1.5M）。Scheduler App や API 統合でも 3.2〜3.6 倍差。
• Subagent 並列は Codex CLI が manager-worker 最大 8 並列（isolated sandbox）、Claude Code は Agent Teams（共有タスクリスト + 直接通信、ハード上限なし）。
• CLI 実装は Claude Code が Node.js、Codex CLI が Rust 95.7%。CI / バッチ起動性能は Codex 優位、MCP / Skills / Plugins の生態系は Claude 優位。
• コストは API 単価が近いが、Claude Code は Pro / Max サブスクで定額化しやすい一方、Codex CLI は ChatGPT サブスクに同梱され追加コストが小さい。個人〜10 名規模では実費差は小さく、100 名規模 + CI では Codex のトークン効率が効く。
• エンタープライズは Claude Code が AWS Bedrock / GCP Vertex AI / Azure AI Foundry、Codex CLI が Azure OpenAI Service を中心とした統合。既存クラウド契約が選定の最大要因。

1. Claude Code と Codex CLI の現在地（2026 年 5 月時点）

1-1. Claude Code（Anthropic）の主力モデルと機能

Claude Code は Anthropic が公式に提供するターミナル型コーディングエージェントです。リポジトリ全体を自動で読み込み、自然言語の指示でファイル編集・コマンド実行・テスト実行を承認制で進めます。GitHub では Claude Code 経由のコミットが 1 日あたり 326,000 件以上（全公開コミットの約 10%）に達しているとの集計が出ており、実務での採用規模では現時点トップクラスです。

2026 年 5 月時点で安定運用フェーズに入っている主要機能は以下です。

• 主力モデル: Claude Opus 4.7（高難度タスク向け、SWE-Bench Verified 87.6% / Pro 64.3%）、Claude Sonnet 4.6（日常開発の主力、1M token context が beta）、Claude Haiku 4.5（高速・低コスト）
• コンテキスト圧縮: /compact コマンド、auto-compact（コンテキスト 95% 到達で自動発動）、/clear / /rewind、サブエージェント
• 拡張機構: CLAUDE.md（プロジェクトルール）、Hooks（前後処理スクリプト）、MCP（外部ツール連携）、Agent Teams（並列タスクの相互通信）、スラッシュコマンド、Skills（再利用可能なドメイン知識パック）、Plugins（配布可能な拡張バンドル）
• エンタープライズ経路: AWS Bedrock / Google Cloud Vertex AI / Microsoft Azure AI Foundry / Anthropic 直接 API
• 料金: Pro $20/月（個人）、Max $100-200/月（ヘビー）、Team / Enterprise（組織契約）、API は Sonnet 4.6 で入力 $3 / 出力 $15（per 1M tokens）

Claude Code の設計思想は「許可制で人間が判断を保持する」アプローチです。書き込みや外部コマンド実行の前に承認を求め、エンジニアが主導権を持ったままエージェントを使う前提でツール群が組まれています。.claude/settings.json の permissions で自動許可するコマンド群（allowlist）を細かく定義でき、ドメイン制限つきの fetch やバックグラウンドプロセス起動も可能です。

1-2. Codex CLI（OpenAI）の主力モデルと機能

Codex CLI は OpenAI が公式に提供するオープンソースのターミナル型エージェントです。2025 年 4 月に TypeScript 版が公開された後、わずか 2 か月後の 2025 年 6 月に Rust へ全面書き換えされ、現在はコードベースの 95.7% が Rust で実装されています。Apache-2.0 ライセンスで公開され、2026 年 4 月時点で GitHub スター 75,600 を超えました。

2026 年 5 月時点の主要機能は以下です。

• 主力モデル: GPT-5.5（汎用最高峰、SWE-Bench Verified 88.7%）、GPT-5.2-Codex（コーディング特化、xHigh reasoning、SWE-Bench Verified 80.0% / Pro 56.4%）、GPT-5.1-Codex-Max（long-horizon native compaction、24 時間連続稼働）
• コンテキスト圧縮: GPT-5.1-Codex-Max の native compaction（複数のコンテキストウィンドウを跨ぐ million-token 実行、thinking tokens 30% 削減）
• Subagents: 2026-03-14 GA、manager-worker モデルで最大 8 並列、各 worker が isolated cloud sandbox 内で実行
• in-app browser: Codex アプリ内のブラウザでローカル / 公開ページを開き、ページ上にコメントを残しながら Codex CLI に修正を依頼可能
• ratatui TUI: 即時モードレンダリングでサブミリ秒応答、CI で並列起動してもオーバーヘッドが小さい
• エンタープライズ経路: Azure OpenAI Service / OpenAI 直接 API
• 料金: ChatGPT Plus $20/月、Pro $200/月、Business $25/seat、Enterprise（組織契約）、API は GPT-5.2-Codex で入力 $1.50 / 出力 $6.00（per 1M tokens、参考値）

Codex CLI の設計思想は「サンドボックスで物理的に行動範囲を制限する」アプローチです。デフォルトではネットワークが遮断された隔離環境内で変更を行い、結果をエンジニアが確認して反映します。実行ポリシー（approval_policy: auto / read-only / untrusted / full-access）と Sandbox Mode（read-only / workspace-write / danger-full-access）をプロジェクトごとに切り替えられます。

1-3. 設計思想の違い（許可制 vs サンドボックス）

両者の最大の違いは「AI の暴走をどこで止めるか」の哲学です。

Claude Code の許可制は、Bash 実行・ファイル書き込み・ネットワーク呼び出しのたびにエンジニアに承認を求めます。「人間がコマンド単位で判断する」前提のため、複雑な許可リスト（allowlist）を設定するか、Hooks を使ってトリガーごとに任意のスクリプト（lint、テスト、Slack 通知など）を差し込むのが運用パターンです。エンジニアが主導権を持ち続ける分、安全性は高い反面、サブエージェント並列を多用するとコマンド承認が頻発する課題があります。

Codex CLI のサンドボックスは、デフォルトで OS カーネルレベルの隔離（macOS Seatbelt、Linux Landlock）を強制し、ネットワークを遮断したコンテナ内で変更を行います。差分プレビューで人間が確認するまでファイルシステムには反映されません。「AI を制御する側」がコードではなく環境にいるため、サブエージェントを 8 並列で走らせても暴走リスクが構造的に低い設計です。一方、サンドボックス制約を緩めすぎる（danger-full-access）と本番マシンへの副作用リスクが一気に上がる点に注意が必要です。

「どちらが正しい」ではなく、社内セキュリティポリシーがコマンド承認の運用に耐えられるか / サンドボックスの隔離が前提インフラに乗るかで選択が決まります。詳しい設計差はClaude Code 完全ガイドとOpenAI Codex CLI 完全ガイドを参照してください。

2. モデル世代別 比較タイムライン（2025〜2026）

両社のモデル投入ペースは年間 3〜5 世代と非常に速く、半年前の比較記事は既に陳腐化しているケースが多いです。以下は 2025 年後半〜2026 年前半の主要リリースを並べたものです。

この表が示す通り、コーディング能力の最高峰は 2026 年 5 月時点で Claude Opus 4.7 と GPT-5.5 が拮抗しており、SWE-Bench Verified では 1.1 ポイント差、SWE-Bench Pro では Claude が 5.7 ポイントリードしています。一方、Codex CLI 側は CLI 自体の実装が Rust 化されて以降、CI 用バッチ実行や TUI の応答性で先行し、Subagents GA（2026-03-14）で並列実行も整いました。

「最強モデル」の座は四半期ごとに入れ替わっているため、特定の世代のスコアだけで長期契約を決めないことが重要です。プラットフォーム選択はモデル能力ではなく、既存契約・社内ポリシー・開発者体験で判断する方が安全です。

3. ベンチマーク 6 軸 完全比較（2026 年 5 月時点・一次ソース付き）

ここからは独立したベンチマーク 6 つで両ツールを並べて比較します。すべての数値に一次ソース URL を併記し、ばらつきが大きいものは本章末の「ベンチ数値の読み方」で別途解説しています。

3-1. SWE-Bench Verified（Claude 87.6% vs GPT-5.5 88.7%）

SWE-Bench Verified は 500 件の人手検証済み GitHub Issue を end-to-end で解決させる、エージェンティック・コーディングの標準ベンチマークです。タスクの粒度は「実Issueに対する修正PR作成」レベルで、コードの読解・複数ファイル横断・テスト実行までエージェントが自律的に行えるかを測ります。

GPT-5.5 が 1.1pt リードしていますが、評価ハーネス・reasoning effort・tool 使用回数の条件はベンダーごとに異なるため、1 ポイント差は誤差範囲と考えて差し支えありません。「SWE-Bench Verified の最高峰スコア」を採用条件にすると、半年ごとに首位が入れ替わってツール選定が振り回されます。安定的な判断軸は「自社の主要 Issue タイプ（言語・規模・言語）でどちらが安定して動くか」です。

3-2. SWE-Bench Pro（Claude Opus 4.7 64.3% でリード）

SWE-Bench Pro は Verified より難度の高い多言語・長文脈版で、より実務に近い課題を扱います。

Pro では Claude Opus 4.7 が 5.7pt リードしています。Pro はクロス言語・長文脈・複合 Issue に強いモデルが有利で、Anthropic が「思考の深さ」を重視する開発方針との相性が出ている形です。

3-3. Terminal-Bench 2.0（Codex 77.3% でリード）

Terminal-Bench 2.0 はライブ・ターミナル環境でのエージェント挙動を評価するベンチマークで、シェル操作・ファイル探索・コマンド構築の能力を測ります。

Codex CLI が約 12pt リードしています。これは Codex CLI の Rust 実装によるサブミリ秒 TUI 応答、ratatui ベースの即時レンダリング、Sandbox 内でのシェル操作最適化が組み合わさった結果です。一方、別ソースでは GPT-5.5 単体で 82.7% との集計もあり、Codex CLI 経由とモデル単体評価の差で数値がずれる点に注意が必要です（詳しくは本章末の「ベンチ数値の読み方」を参照）。

3-4. CursorBench（Claude Code 70%）

CursorBench は Cursor 社が公開している実コードベース上の評価指標で、企業内コードベースに近い分布のタスクを扱います。

Codex 側の CursorBench スコアは現時点で公開されていないため厳密な比較はできませんが、企業コードベース寄りの評価で Claude Code が 70% に達している点は記録に値します。

3-5. Blind 評価 勝率（Claude 67% vs Codex 25%）

Blind code quality 評価は、両ツールの出力コードを匿名化して人間レビュアーが「どちらが良いコードか」を選ぶ手法です。コミュニティが実施した複数回のテストで以下の結果が報告されています。

出典: nxcode（2026）

なお、この数値は単一のコミュニティ調査ベースで、Anthropic / OpenAI の公式発表ではありません。サンプル数（推定 100-300 タスク）・評価者属性・タスク分布の偏りを含む点に注意してください。

Claude Code が 67% で過半数を取り、Codex CLI に 2.7 倍の差を付けています。「人間が読みやすい・保守しやすい・イディオマティック」と感じるコードを書くという定性指標で Claude Code に分があるという結論ですが、この数値の解釈にはサンプル数・評価者属性・タスク分布による偏りが含まれます。詳しい方法論レビューは本記事第 11 章を参照してください。

3-6. トークン効率（タスク別実測 3 例）

同一タスクを両ツールに与えたときのトークン消費比較です。コミュニティテスターによる独立検証ベンチマーク（2026 年 2 月）の結果を示します。

出典: morphllm（May 2026）

Codex CLI は同一タスクで Claude Code の約 3〜4 倍少ないトークンで完了します。これは GPT-5.1-Codex-Max の native compaction、reasoning effort のチューニング、サンドボックス内での試行コスト削減が組み合わさった効果と推測されます。

ただし、「4 倍少ない」をそのまま「4 倍安い」と読み替えるのは早計です。Claude Pro $20/月サブスクの範囲内で個人が使う限り、トークン効率差は実費に直結しません。実費差が顕在化するのは API 課金中心の 100 名規模以上、または Subagent を多用する CI バッチワークロードです（本記事第 6 章で具体的に試算）。

3-7. ベンチ数値の読み方

ベンチマーク数値は出典・時期・条件によって以下のようにばらつきます。誤読を避けるための注意点を整理します。

• モデル単体評価 vs CLI 経由評価: Terminal-Bench 2.0 で GPT-5.5 単体 82.7% / Codex CLI 経由 77.3% の数値が両方公開されています。前者はモデル本体のスコア、後者は CLI のオーバーヘッド込みです。記事内で「Codex CLI」と表記する場合は CLI 経由値を採用しています。
• テスト条件の違い: reasoning effort（high / xHigh）、tool 使用回数の上限、temperature の設定がベンダーごとに異なります。1〜2 ポイント差は誤差範囲。
• 自社コードベースとの乖離: ベンチマークは「平均的なタスク分布」ですが、自社の言語・スタイル・テストカバレッジによって体感は逆転しえます。ベンチではなく PoC で判断するのが安全（本記事第 12 章参照）。
• 数値の更新頻度: 両社のリーダーボードは月次で更新されるため、3 か月前の数値は既に古い可能性があります。本記事は 2026-05-19 時点の集計。
• コミュニティ調査の限界: morphllm / datacamp / nxcode などのコミュニティ調査は、評価条件・サンプル数・評価者属性の開示が公式リーダーボードより少ない点に注意。傾向の把握には使えても、絶対値の比較には慎重さが必要です。

「絶対的な勝者」を 1 つに決めようとせず、自社の主要タスク特性に照らして読み解くのがベンチマーク活用の正しい姿勢です。本記事の数値も「2026 年 5 月時点のスナップショット」と捉え、半年後には全く別の結論になりうることを前提に判断してください。

4. 機能比較マトリクス（6 項目）

機能カテゴリごとに 2026 年 5 月時点の仕様を並べます。

4-1. 安全策（許可制 vs サンドボックス）

Claude Code は「許可制」、Codex CLI は「サンドボックス」を中心に据えた安全策を採用しています。

社内ポリシーが「コマンド単位の承認をログ化する文化」なら Claude Code、「OS レベルで環境を隔離する文化」なら Codex CLI が馴染みやすい設計です。具体的なポリシー設計では、Claude Code は permissions.autoApprove に ["Bash(npm install:*)", "Bash(pnpm test:*)"] のように細かい正規表現を書く運用、Codex CLI は sandbox_mode = "workspace-write" で「現在のワークスペースのみ書き込み可、ネットワークは遮断」のような環境境界を引く運用が標準です。

4-2. Subagent（Agent Teams vs manager-worker 8 並列）

**Claude Code は Agent Teams で「協調」、Codex CLI は manager-worker で「速度」**を志向します。

Codex の subagents は GA が 2026-03-14、manager-worker モデルで明示的に分割します。Claude Code の Agent Teams は共有タスクリストと直接通信で「深度」を狙う設計です。トレードオフは「Isolated 速度 vs 協調 深度」と整理できます。詳しくはClaude Code サブエージェント活用ガイドを参照してください。

4-3. コンテキスト圧縮（auto-compact vs native compaction）

Claude Code はコンテキストを 5 つの手段で能動的に管理、Codex CLI は GPT-5.1-Codex-Max の native compaction で連続稼働を実現しています。

Claude Code 側の主な手段は以下です。

• /compact [focus]: 焦点を引数で指定して圧縮
• auto-compact: コンテキスト使用率 95% で自動発動（/config で閾値変更可）
• /clear: コンテキストを完全リセット
• /rewind: 直前の状態に巻き戻し
• Agent Teams / サブエージェント: メインコンテキストから切り離して並列実行

詳しい使い分けはClaude Code のコンテキスト圧縮 5 手段で解説しています。

Codex CLI 側、特に GPT-5.1-Codex-Max は compaction が training に組み込まれた native 機能として動作します。複数のコンテキストウィンドウを跨いでも重要情報を保持しながらプルーニングし、thinking tokens を 30% 削減、長セッション全体では 20〜40% のトークン削減を実現します。OpenAI 社内テストで 24 時間以上の連続稼働で自律的にコード修正・テスト反復を継続した実績が公開されています。

4-4. ブラウザ操作（MCP vs in-app browser）

Codex CLI は in-app browser を CLI に統合、Claude Code は MCP 経由で外部ブラウザを制御します。

Codex の in-app browser はローカル開発サーバや公開ページを Codex アプリ内で開き、ページ上にコメントを残すと Codex がページレベルのフィードバックに対応してコード修正に反映します。フロントエンド開発の試行錯誤ループが短縮されるのが利点です。Claude Code はブラウザ機能そのものは強力ですが、初期設定の手数が増えます。

4-5. 実装言語（Node.js vs Rust）と起動性能

Claude Code は Node.js、Codex CLI は Rust（95.7%） で実装されています。

この違いはCI / バッチ実行で顕在化します。Codex CLI は単一の Rust バイナリで配布され、Node.js ランタイムが不要、起動はサブミリ秒単位です。GitHub Actions などで数十並列にエージェントを起動するワークロードでは、Codex CLI の起動オーバーヘッドの小ささが効きます。

Claude Code は Node.js 上で動くため起動コストはやや大きいものの、その分プラグイン・スラッシュコマンド・MCP サーバ等の周辺生態系が JavaScript / TypeScript で書きやすく、社内ツール連携の柔軟性で先行しています。

4-6. 拡張機構（Hooks / Skills / MCP vs profiles / approval_policy）

両ツールの拡張機構は哲学が異なります。

Claude Code の拡張機構:

• CLAUDE.md / CLAUDE.local.md: プロジェクト固有設定（ローカルは git ignore 対象）
• Hooks: コマンド前後、PR 作成前、コミット前などの任意トリガーで実行されるシェルスクリプト
• MCP: 外部ツール・データベース・API との双方向連携プロトコル
• Agent Teams / サブエージェント: 専門エージェントの定義と並列実行
• スラッシュコマンド: チーム共通のワークフローテンプレ
• Skills: 再利用可能なドメイン知識パック（trigger キーワードで自動発動）
• Plugins: 配布可能な拡張バンドル

Codex CLI の拡張機構:

• AGENTS.md: プロジェクト指示書（CLAUDE.md 相当、60,000+ OSS で採用）
• approval_policy: auto / read-only / untrusted / full-access
• sandbox_mode: read-only / workspace-write / danger-full-access
• profiles: 個人開発 / チーム / CI 用などプロファイル切り替え
• [mcp_servers]: STDIO / HTTP MCP サーバの統合
• [agents]: サブエージェント定義
• OpenAI Responses API / Agents SDK: 外部から Codex を呼び出して高度なエージェント構成を実装

「深く拡張する」なら Claude Code、「設定とポリシーで挙動を制御する」なら Codex CLI、と整理すると現場感覚に近いです。

5. タスク特性別 使い分けマトリクス（10 タスク）

よくある開発タスク 10 種類について両ツールの適性を整理します。記号は「◎=主要な設計思想と強く合致 / ○=可能だが副次的」、推奨は「迷ったらこれ」の意。

各タスクの判断根拠を以下で展開します。

5-1. 単発スクリプト・短時間タスク

「30 秒で書き捨てのワンライナーを作りたい」「小さな bash スクリプトを試作したい」レベルでは、Codex CLI の起動速度が明確に優位です。Rust 単一バイナリでサブミリ秒起動するため、ターミナルで codex exec "this script" を叩く感覚で、Node.js の数百 ms ウォームアップがない分の体感差が大きいです。トークン消費も Codex は単発タスクで効率が良く、3〜4 倍少ない傾向。

具体例として、「現在のディレクトリ配下の .log ファイルから ERROR 行だけ抽出して JSON 出力するスクリプトを書いて」というタスクで、Codex CLI なら起動から完成まで体感 5 秒以内、Claude Code は Node 起動 + コンテキスト読み込みで 10〜15 秒かかる差があります。1 日に 10 件こなすと累積で 1〜2 分の差になり、トータルの開発体験に影響します。

Claude Code はインタラクティブセッションの長い対話を前提とした設計なので、単発タスクは過剰スペックになりがちです。一方、単発タスクが多いインフラエンジニア・SRE 系の業務では Codex の方が時短効果を実感しやすいです。

5-2. TDD で新機能を実装

Skills を使って TDD ワークフローをパッケージ化できる Claude Code が強みを発揮します。「/add-feature を呼ぶと requirements.md → tasklist.md → Red → Green → Refactor」と Skill 内に処理を畳めるため、チーム全員が同じ TDD フローを再現できます。Hooks で pnpm test を自動実行するように設定すれば、修正のたびに回帰検証が走る運用も可能です。

Skills の強力さは「trigger キーワードで自動発動する」点にあります。description フィールドに「TDD で機能を追加する場合に使う」と書いておくと、ユーザーが自然言語で「ユーザー認証機能を追加して」と頼んだ瞬間に該当 Skill が呼び出されます。チーム共通の品質ゲートを Skill にパッケージ化することで、新メンバーも初日から正しいワークフローに沿えます。

Codex CLI でも /init で AGENTS.md にテスト方針を埋め込めますが、Skill ほど「ドメイン知識を再利用可能なパッケージにする」概念が成熟していません。AGENTS.md の本文に TDD フローを書いても、ユーザーが毎回「TDD で進めて」と明示しないとプロンプト解釈に揺れが出る点が課題です。

5-3. 大規模リファクタリング（数百ファイル）

ここは両方が強みを持つ領域で、設計が「協調的か独立的か」で選ぶことになります。

• Claude Code: .claude/agents/refactor-*.md で複数の専門エージェントを定義し、Agent Teams で findings を共有しながら範囲分割。「リファクタ A の結果がリファクタ B の判断に影響する」協調的なケースに強い。
• Codex CLI（GPT-5.1-Codex-Max）: 1 つの長時間セッションで million-token level のコンテキストを compaction しながら処理。または manager-worker 8 並列で「同型のリファクタ 8 件」を独立に走らせる。「ファイル A のリファクタ結果がファイル B に影響しない」場合に並列度で優位。

たとえば「Tailwind CSS v3 → v4 への移行を 200 コンポーネントに適用」のような同型タスクは Codex の 8 並列が明確に速い一方、「DDD への段階的再設計（ドメイン境界の引き直しを伴う）」のように相互依存が強いタスクは Claude Code の Agent Teams で findings 共有しながら進めるほうが安全です。

トークン効率は Codex 優位なので、コスト最重視なら Codex、品質と協調性重視なら Claude Code の住み分けです。実務では両方を併用し、独立性の高いリファクタを Codex に投げ、影響範囲の大きい部分を Claude で慎重に進めるパターンが定着しつつあります。

5-4. 設計議論・アーキテクチャ決定

Claude Code の Agent Teams が真価を発揮する領域です。「フロントエンドエージェント」「バックエンドエージェント」「セキュリティエージェント」「DevOps エージェント」を立てて、設計案を相互にチャレンジさせるパターンが定着しています。findings を共有しながら合意形成するので、人間 1 人 + Claude では気付かない盲点を潰せます。

たとえば「新しいマイクロサービスの認証フロー設計」では、セキュリティエージェントが「JWT の有効期限と Refresh Token の運用」を指摘し、バックエンドエージェントが「Refresh Token のDB保管とローテーション戦略」を返し、DevOps エージェントが「Secrets Manager との統合とローテーション自動化」を加える、といった多角的検証が 1 セッション内で進行します。人間は最終判断者として議論を見守り、必要な時だけ介入する運用です。

Codex の manager-worker は worker 同士が直接通信しないため、設計議論の往復が苦手。設計フェーズは Claude、実装フェーズは Codex の併用が現実的です（本記事第 9 章で詳述）。

5-5. E2E テスト生成

Codex CLI の in-app browser でブラウザを開きながらテストを書ける点が大きな差別化要因です。「このボタンをクリックして遷移先を検証するテストを書いて」と Codex に依頼すると、in-app browser で実際にクリックして遷移先を確認し、Playwright / Cypress のテストコードに反映できます。

Claude Code でも Playwright MCP を導入すれば同等以上の機能ですが、初期設定の手数が増えます。E2E テスト生成を月に何十本も回すなら Codex の in-app browser が時短に直結します。逆に「DOM 構造の深い検証」「ネットワーク監視」「Lighthouse パフォーマンス計測」までやりたいなら Claude Code + Chrome DevTools MCP の組み合わせの方が機能的に強力なので、テストの種類で選ぶのが妥当です。

5-6. フロントエンド UI デバッグ

フロントエンドは Codex CLI の in-app browser が体験面で優位です。localhost:3000 で動いている開発サーバを Codex アプリ内で開き、ページ上にコメントを残すと、その箇所のコードを Codex が修正します。視覚的フィードバックループが短いので、CSS や状態管理のバグ調査でストレスが減ります。

Claude Code 側は Chrome DevTools MCP / Claude Preview MCP / Claude in Chrome で代替できますが、フロントエンド専業エンジニアからは「最初から CLI に統合されている Codex の方が思考が止まらない」との声が多いです。

5-7. バックエンド API 実装

Claude Code の MCP 生態系が活きる領域です。社内 DB（PostgreSQL / MySQL MCP）、監視（Datadog / Grafana MCP）、課題管理（Jira / Linear MCP）、社内 Wiki（Confluence / Notion MCP）を CLI から直接参照しながら API を実装できます。「Jira チケットの仕様を読み込んで、DB スキーマを照合しながら API エンドポイントを実装」のような複合タスクが 1 セッションで完結します。

具体的なフローとしては、@jira CARD-1234 で Jira チケットを参照、@postgres SELECT * FROM users LIMIT 1 で DB スキーマを確認、@notion 認証フロー設計書 で社内 Wiki の関連ドキュメントを引用、と段階を踏んで仕様を確定してから実装に入ります。Codex CLI でも個別の MCP サーバを設定すれば同等のことは可能ですが、複数の社内ツールを 1 セッションで横断する用途では Claude Code 側の MCP サーバ実装の数と認証フローの完成度に分があります。

Codex CLI も MCP に対応していますが、サーバ実装の数とエンタープライズ向け実装の成熟度では Claude Code 側に分があります。

5-8. CI/CD パイプライン統合

Codex CLI の Rust 単一バイナリが CI 性能を直撃します。GitHub Actions で並列ジョブを大量に起動する設計（PR レビュー / 自動修正 / セキュリティスキャン）では、Node.js ランタイムのウォームアップが不要な Codex CLI が起動・実行ともに高速です。

Claude Code も claude --print の headless 実行に対応していますが、Node.js のウォームアップ分の差は残ります。月間数千回 CI 起動するワークロードでは、起動オーバーヘッド差が累積する点に注意。

5-9. コードレビュー・PR 自動化

Hooks による「PR 作成前トリガー」が使える Claude Code が強みを発揮します。pre-pr Hook で artisan + guardian エージェントを並列起動してレビュー、4.2/5 未満なら PR 作成をブロックする運用が定着しています。レビュー基準を Hooks で固定できるため、チーム全員が同じ品質ゲートを通れます。

加えて Claude Code は「/review スラッシュコマンドで多角的観点（命名 / 構造 / DRY / セキュリティ / エッジケース / テスト網羅性）を一発でチェック」のような専用ワークフローが組まれており、レビューエージェント DSL の成熟度が高いです。Stop hook で commit 直前に自動レビューを差し込み、人間レビューの前段フィルタとして機能させる運用も普及しています。

Codex CLI でも pre-commit 系のシェルスクリプトで類似のことは可能ですが、専用のレビューエージェント DSL は Claude Code の方が成熟しています。「review-only な subagent を立ててコメントを残させる」運用は両ツールで可能ですが、UI の見え方と差分のハイライト機能では Claude 側に一日の長があります。

5-10. オンボーディング（既存リポジトリ把握）

Claude Code の MCP で社内 Wiki / Jira / GitHub Issues を横断検索できる点がオンボーディングで優位に働きます。新規メンバーが「このコードベースの背景は何か」「過去の Issue で言及された制約は何か」を 1 セッションで把握できます。

具体的な活用例として、新規メンバーが入社初日に @claude このリポジトリの構造と主要な設計判断を教えて と聞くと、Claude が CLAUDE.md・主要な PR 履歴・関連 Jira チケットを横断して 5 分で全体像を返してくれます。これはオンボーディング期間（通常 2-4 週間）を 1-2 週間に短縮する効果があり、エンジニアの立ち上がりコストを大きく下げます。

Codex CLI は in-app browser でドキュメント参照を CLI 内で完結できますが、複数の社内ツールを横断する MCP 連携の数では Claude Code 側に分があります。

6. 料金実費シミュレーション（3 シナリオ + 計算式）

両社の料金体系は API 単価で似ていますが、サブスクの設計とトークン効率差で実費が変わります。以下は 2026 年 5 月時点の代表的な仮想ケースです。為替は 1 USD = 150 JPY で換算しています。

6-1. シナリオ A: 個人開発（月 20 時間）

計算式: 月額 = サブスク + (1日のトークン消費 × 営業日 × API 単価)

個人開発レベルでは実費差はほぼなし。トークン効率 4 倍差はサブスクの範囲内で吸収されるため、選定は機能差（in-app browser が欲しいかどうか、Skills を作りたいかどうか）で決めるのが妥当です。

仮にヘビーに使う個人開発者（月 40-60 時間）でも、Claude Max $100-200/月 または ChatGPT Pro $200/月 のレンジに収まります。サブスクのレート制限に到達した時だけ API 課金が発生する設計なので、「月初に Pro を契約 → 中旬でレート制限到達 → 月末まで API 課金で凌ぐ」のような運用パターンもあります。

6-2. シナリオ B: 小規模チーム（10 名 × 月 100 時間）

計算式: 月額 = (サブスク × seats) + (チーム合計のトークン消費 × API 単価) + 周辺ツール

10 名規模でも実費差は 5〜10% 程度。Codex のサブエージェント multi-window compaction でトークン消費効率が活きる場面はありますが、サブスクの定額制で吸収される範囲です。判断ポイントは「設計議論を Agent Teams で回したいか」「UI デバッグの頻度が高いか」など機能差になります。

6-3. シナリオ C: 中堅企業（100 名 + CI バッチ + Subagent 多用）

計算式: 月額 = seats + (CI + Subagent 合計トークン × API 単価)

100 名規模では Codex が約 1.5〜2 倍安い結果になりました。これは API 課金部分のトークン効率 4 倍差が累積するためです。ただし、Anthropic 側は Bedrock の prompt caching（入力トークン最大 90% 削減）を活用すれば差が縮みます。実費は社内のキャッシュヒット率に大きく依存します。

たとえばコードベースが大きく、毎回同じディレクトリ構造を読み込ませる運用なら、キャッシュヒット率 80% を狙えます。その場合 Opus 4.7 の入力トークン実費は $15/M → $1.5/M（90% 削減）に近づき、Codex CLI とのコスト差は 50% 程度に縮小します。逆にキャッシュが効きにくい多様なリポジトリを扱う組織では Codex の効率が活きるため、**自社のワークロードの「同質性」**が判断軸になります。

6-4. コスト計算式と注意点

3 シナリオに共通する計算式は以下です。

月額コスト = (サブスク単価 × seats) + (1日トークン消費 × 営業日 × API単価) + 周辺コスト

注意点:

• 公式料金は変動します。Anthropic / OpenAI とも四半期で料金改定が入ることがあるため、必ずAnthropic 料金ページ・OpenAI 料金ページで再確認してください。
• prompt caching の有無で実費が大きく変わります。Claude API は最大 90% 削減、Codex CLI も類似機能あり。CI バッチでは必須機能。
• 為替変動の影響は中堅以上で無視できません。1 USD = 130〜160 JPY のレンジで予算組みを。
• Subagent の並列度設定でトークン消費が指数的に増えるため、max_subagents を config.toml / .claude/settings.json で必ず制限すること。

詳細な料金構造と最適化テクニックはClaude Code 料金プラン徹底解説も参照してください。

7. エンタープライズ導入経路の比較

エンタープライズ導入では、CLI 機能の差よりもどのクラウド・どの契約系統に乗せるかの方が初期コストを左右します。

7-1. Claude Code: AWS Bedrock / GCP Vertex AI / Azure AI Foundry

Anthropic の Claude モデルは、Anthropic 直接 API のほか、AWS Bedrock / Google Cloud Vertex AI / Microsoft Azure AI Foundry から呼び出せます。3 大クラウドすべてに乗っているマルチクラウド対応が強みです。

既存クラウド契約と認証・課金・データ所在地を統合できるため、エンタープライズ調達の障壁が小さいのが特徴です。

7-2. Codex CLI: Azure OpenAI Service 中心

OpenAI モデルは Azure OpenAI Service 経由でのエンタープライズ統合が中心です。Azure を既に使っている組織にとっては、Entra ID / RBAC / Defender for Cloud / Purview などの統制機能をそのまま流用できます。

AWS / GCP 中心の組織にとっては Azure 経由のクロスクラウド構成になり、運用負担が増える可能性があります。逆に Azure 中心ならガバナンス一本化が可能です。

7-3. データ所在地・監査ログ・コンプライアンス

学習にデータを使わない契約は両社とも提供しています。最終確認は調達担当者経由で実施してください。詳細はClaude Code エンタープライズ導入ガイドで整理しています。

7-4. 日本リージョン対応状況

両社とも日本リージョンが整備済みで、データ所在地要件への対応は同等です。

8. CLAUDE.md ↔ AGENTS.md 完全マッピング表

Claude Code を使っているチームが Codex CLI に移行する場合、または逆方向の移行で最大の作業は CLAUDE.md と AGENTS.md の変換です。両ファイルは「プロジェクトルール / コーディング規約 / テスト方針」をエージェントに渡す目的が共通で、共通フィールドは 80% ほど重なります。一方、固有部分（Hooks / Skills / approval_policy / sandbox_mode）は手動で再構成が必要です。

8-1. 共通フィールド（規約・スタック・テスト方針）

以下のフィールドはそのままコピーで動くことが多いです。

移行作業の80%はこのコピペで済みます。

8-2. Claude 固有（Hooks / Skills / Plugins / サブエージェント DSL）

以下の Claude Code 固有機能は、Codex CLI には直接対応する仕組みが無いか、別形式での再実装が必要です。

8-3. Codex 固有（approval_policy / sandbox_mode / profiles）

以下の Codex CLI 固有機能は、Claude Code への移行時には**「許可制 + Hooks」での再実装**になります。

8-4. 変換スクリプト例（agents-to-claude.sh）

以下は AGENTS.md → CLAUDE.md の 80% 自動変換を試みるシェルスクリプトの例です（実環境では検証して使用してください）。

#!/usr/bin/env bash
set -euo pipefail

src="${1:?AGENTS.md のパスを指定}"
dst="${2:-CLAUDE.md}"

# 共通フィールドはそのままコピー
cp "$src" "$dst"

# Codex 固有フィールドを Claude 形式に置換
sed -i.bak \
  -e 's/approval_policy.*=.*/(Claude では .claude\/settings.json で permissions.autoApprove を設定してください)/' \
  -e 's/sandbox_mode.*=.*/(Claude では Devcontainer または .claude\/settings.json で制限してください)/' \
  -e 's/\[mcp_servers\]/(Claude では .claude\/mcp.json に変換してください)/' \
  "$dst"

# サブエージェント定義は手動変換が必要
if grep -q '\[agents\]' "$src"; then
  echo "⚠️  [agents] セクションを検出しました。.claude/agents/*.md に手動変換してください"
fi

echo "✅ $dst を生成しました。Claude 固有機能（Hooks / Skills）は手動で追加してください"

逆方向（CLAUDE.md → AGENTS.md）も同じ要領で [agents] セクションと approval_policy を追加するスクリプトを書けます。

8-5. 移行時の落とし穴

9. 併用ワークフロー — 両方使う「2026 年スタンダード」

実務では、Claude Code と Codex CLI を「どちらか一方」ではなく併用するケースが増えています。代表的なパターンを 4 つ紹介します。

9-1. パターン A: Codex で探索、Claude で実装

新しい技術スタックや未知のライブラリを調査するフェーズでは Codex CLI の in-app browser とサンドボックスを使い、設計が固まったあとの本実装は Claude Code のサブエージェントと MCP 連携で進めるパターンです。

• 探索: Codex CLI（in-app browser、サンドボックス、codex exec で並列試行）
• 実装: Claude Code（CLAUDE.md / Skills / MCP / Hooks）

「ブラウザで仕様書を読みながらコード断片を試す」「ドキュメントの引用元にすぐ飛ぶ」探索フェーズで Codex が活きます。実装フェーズでは Skills を再利用したいので Claude に切り替え。新規プロジェクトの初期段階で技術選定が固まっていない時期に特に有効で、3-5 日の探索期間中はサブスク 2 系統を維持し、確定後は実装ツールに集約する運用もコスト管理として合理的です。

9-2. パターン B: 言語・タスクで分担（フロントエンド vs バックエンド）

得意領域でツールを使い分ける運用です。たとえばフロントエンドは Codex CLI の in-app browser を活かし、バックエンドのリファクタリングは Claude Code のサブエージェント並列で回す、といった分担です。

• フロントエンド（UI 検証含む）: Codex CLI
• バックエンド（大規模変更）: Claude Code

エンジニア個人ごとに専門性が決まっている組織で運用しやすいパターン。各人が得意ツールを集中して使うため、Skills や AGENTS.md の整備が進みます。組織として両ツールのライセンスを揃えるコストは増えますが、エンジニア 1 人あたりは「メインツールに習熟」できる体制が組めるため、習得コストを最小化できる利点があります。社内の Skill / AGENTS.md レビュアーをツールごとに分けて、相互に内容を翻訳する役割を設けるとさらに効果的です。

9-3. パターン C: 第二意見クロスチェック

重要な PR やマイグレーションスクリプトを、両方のエージェントに独立してレビューさせ、結論を突き合わせる運用です。モデル提供元が違うため、見落としが偏らないのが利点です。

• 第一実装: いずれか（主担当ツール）
• 第二意見（レビュー専用）: もう一方
• 差分・指摘の突き合わせを開発者が判断

法務確認やセキュリティ監査に近い性質のレビューで効果が高く、「1 つのモデルだけに依存しない」リスク分散にもなります。具体例として、本番 DB マイグレーション PR では Claude Code が「ロック挙動」「データ整合性」を観点に、Codex CLI が「ロールバック手順」「テスト網羅性」を観点にレビューし、両者の指摘を突き合わせる運用が定着しつつあります。両方の指摘が一致する箇所は確実に修正し、片方だけの指摘は人間が判断する流れです。

9-4. パターン D: 設計＝Claude / 量産＝Codex（5 フェーズ手順）

最も実務的な併用パターンです。設計議論を Claude Code の Agent Teams で深く詰め、確定した実装タスクを Codex CLI の manager-worker 8 並列で量産します。

各フェーズ間で設定ファイルを切り替えます。Claude Code 側の Stop hook で cp CLAUDE.md AGENTS.md を自動実行する運用で、両ツール間の文脈引き継ぎを半自動化できます。逆方向の引き継ぎは、Codex 側の pre-commit フックで AGENTS.md の差分を CLAUDE.md にマージする運用が必要です。完全自動化は難しいので、週次のレビュー会で「両ファイルの整合性確認」を 5 分入れる運用が現実的です。

実例として、koromo の開発フローでは「月曜に Claude Code で 1 週間の機能設計と Issue 分解」→「火〜木で Codex CLI に Issue を投げて並列実装」→「金曜に Claude Code で PR をまとめてレビュー → マージ判断」というリズムが定着しています。曜日でツールを切り替える運用が、エンジニアの認知負荷も減らせる方法として浮上しています。

両方を採用する場合、サブスクと API 利用料の合計が増えるため、月次の実費レビューを回す体制を最初に組んでおくのが現実的です。

10. 乗り換え失敗パターン 5 選

Claude Code → Codex CLI、または逆方向の乗り換えでよく見る失敗を 5 つ整理します。

10-1. CLAUDE.md のサブエージェント定義をそのまま AGENTS.md に貼る

症状: Codex がサブエージェント定義を無視する。/agents で確認しても何も表示されない。Task ツールから呼んでも「Agent not found」エラー。

原因: Claude Code のサブエージェントは .claude/agents/*.md の YAML フロントマター形式で定義します。Codex CLI は config.toml の [agents] セクションで TOML 形式で定義するため、フォーマットが互換性ゼロです。

対処: YAML → TOML への手動変換が必要。name / description / tools は対応するが、Tools: All tools のような Claude 特有の指定は Codex の tools = ["read", "write", "exec"] 形式に書き換える。実例:

[agents.artisan]
description = "設計美学レビューエージェント"
tools = ["read", "grep"]
model = "gpt-5.2-codex"

10-2. /compact 依存ワークフローを Codex に持ち込む

症状: 長時間セッションでコンテキスト溢れ、エラーで強制リセット。「Context window exceeded」のエラーが頻発する。

原因: Claude Code の /compact は明示的に呼び出す圧縮機構ですが、Codex CLI には対応するコマンドがありません。代わりに GPT-5.1-Codex-Max の native compaction に頼る設計です。Claude Code ユーザーがコンテキスト管理を「明示的圧縮 + auto-compact」に依存していると、Codex 側ではタイミングが掴めず溢れます。

対処: GPT-5.1-Codex-Max を主力モデルに設定し、auto compaction の挙動を信頼する。明示的な圧縮が必要なら codex resume でセッションを区切る運用に変更。長時間タスクを 1 セッションに収める必要があるなら GPT-5.1-Codex-Max を選び、複数セッションに分けるなら GPT-5.2-Codex で十分です。

10-3. Slash Command 互換を確認しない（/agents は Codex 専用）

症状: /agents を叩いても認識されない、または逆に Claude の /skill-name が Codex で動かない。チームのドキュメントに書かれたコマンドが半分使えない。

原因: 両ツールのスラッシュコマンドは互換性が部分的。/init / /clear / /help のような基本コマンドは両方にあるが、/agents（Codex）/ /compact（Claude）/ /rewind（Claude）/ /fork（Codex）など固有コマンドは互いに存在しません。

対処: 移行前にスラッシュコマンド対応表を作成し、ワークフロー内で使っているコマンドを 1 つずつ確認する。チームの内部ドキュメント（オンボーディング資料）も更新し、移行後の正しいコマンド名を周知する。Claude の /skill-name は Codex 側では AGENTS.md 本文に手動展開するため、Skill 1 個を 1 ページのマークダウン文書に展開する移行作業が必要です。

10-4. MCP サーバ引き継ぎで認証が破綻

症状: 移行先で MCP サーバが起動しない、または認証エラーで接続不能。MCP server failed to start / Auth flow not supported のエラーが出る。

原因: 両ツールとも MCP に対応しているが、Claude 専用 MCP サーバ（Claude in Chrome、Claude Preview MCP など）や認証フローが Claude 固有のサーバがあります。Codex への移行時にこれらは動きません。

対処: 移行先で対応する MCP サーバを選び直す。Playwright MCP / Chrome DevTools MCP は両ツール対応なので、ブラウザ操作はこれらに統一しておくと移行が楽。Codex CLI の [mcp_servers] セクション形式に書き換える際は、認証フローの確認も忘れずに。OAuth フローを使う MCP は、両ツールで挙動が微妙に異なる場合があるので、移行直後にフルテストを回しておくこと。

10-5. メモリ移行漏れで文脈消失

症状: 移行後にエージェントが過去の決定事項を覚えていない、毎回同じ質問を返してくる。「以前に決めた命名規則を忘れている」「ユーザーの好みを毎セッションでゼロから聞かれる」。

原因: Claude Code は CLAUDE.md の [[memory]] ブロックやユーザー設定の ~/.claude/memory/ で永続記憶を持ちます。Codex CLI には対応する仕組みが無く、移行時に文脈が消えます。Claude 側のメモリは長期間蓄積されているケースが多く、暗黙的に頼っていることに移行後気付くパターンが多発します。

対処: 移行前に ~/.claude/memory/MEMORY.md の内容を AGENTS.md 本文に明示的に展開する。「過去のセッションで決定したこと」「ユーザーの好み」「プロジェクト固有の判断基準」を箇条書きで残すことで、Codex 側でも参照可能になる。展開時には「memory タイプ」（user / feedback / project / reference）の区別を AGENTS.md 内のセクション見出しに反映すると見通しが良い。

11. Blind 67% 勝率の方法論レビュー（中立性確保）

「Claude Code は Blind 評価で 67% 勝率」という数値はインパクトがありますが、鵜呑みにせず、方法論を批判的に読み解くことが重要です。

11-1. サンプル数と評価者属性

公開されている Blind 評価のサンプル数は推定 100〜300 タスクで、統計的に十分とは言い切れないレンジです。一般的に、A/B テストで有意差を確認するには 1,000 サンプル以上を集めるのが安全側ですが、Blind 評価のような高コスト評価ではそこまでのサンプルを集めるのが難しい現実があります。

また、評価者の属性（フロントエンド / バックエンド / インフラ / DevOps）が公開されていないため、評価者の専門領域に偏ったタスク分布である可能性があります。「フロントエンドエンジニアが UI コードを評価」と「インフラエンジニアが IaC を評価」では、Claude / Codex の優位性が逆転しうる点に注意。評価者属性とタスク種別のクロス分布が公開されない限り、結論を一般化するのは早計です。

11-2. 「同等」8% の解釈

Claude 67% / Codex 25% / 同等 8% の合計は 100% です。「同等」と判定された 8% は、両ツールが実質互角だったタスクを示します。これは少なく見える数値ですが、**「タスク 12 本に 1 本は両ツールの出力が見分けがつかない」**水準であり、無視できる量ではありません。

「Claude が圧勝」という結論を導く前に、「同等 8% のタスクはどんな種類か」を確認すべきです。実用上、同等品質なら起動の速い Codex や、トークン効率の良い Codex を選ぶ理由が立ちます。

11-3. 自社コードベースで結果が逆転する理由

ベンチマークは「平均的なタスク分布」を仮定していますが、自社固有の以下の要因で結果は変わります。

• 使用言語: TypeScript / Python / Go / Rust / Java など、モデルの得意分布が異なる
• コーディングスタイル: 関数型 / オブジェクト指向 / DDD などのスタイル
• テストカバレッジ: TDD 文化が定着しているとモデルの試行錯誤コストが減る
• 依存ライブラリ: ニッチな OSS を使っていると学習データの濃淡が出る
• コメント / ドキュメントの密度: 文脈読み取りに影響

「Blind 67%」はあくまで参考値で、最終判断は自社 PoC で行うべきです。

11-4. PoC で確認すべき 5 観点

自社で 2 週間の PoC を回すなら、以下の 5 観点を必ず計測してください。

1. 完了時間: 同一タスクを両ツールで処理し、人間 + エージェントの合計時間を計測
2. 手戻り頻度: レビューでの差し戻し回数、PR 反映までの修正回数
3. エッジケース対応: エラー系・境界値・想定外入力への対応力
4. 社内規約への適合度: CLAUDE.md / AGENTS.md の指示にどれだけ忠実か
5. 主観満足度: チームメンバーの「使ってて気持ちいいか」スコア（1-5）

これらを 1 シート（Spreadsheet）に記録し、2 週間後の振り返りで判断します。最低 5 人のエンジニアが参加しないと主観満足度のサンプルが少なすぎて意味のあるデータになりません。PoC 期間中は 1 日 15 分の振り返りタイムを設けて、定性的なフィードバック（「Claude の Agent Teams が議論を回しすぎて時間がかかった」「Codex の sandbox が CI 統合で安心感がある」など）も拾うと、数値に出ない判断材料が得られます。

12. 2 週間 PoC 設計ガイド

ツール選定で最も信頼性が高いのは、自社のコードベースで 2 週間の PoC を回すことです。

12-1. タスク群選定（バグ修正 / 新機能 / リファクタ）

PoC で扱うタスクは多様性とリアリティが重要です。以下の組み合わせを推奨します。

• バグ修正 3 件: 各 2-4 時間の小規模、再現手順が明確なもの
• 新機能 2 件: 各 1-2 日の中規模、要件が確定しているもの
• リファクタ 1 件: 1-2 日の中規模、複数ファイル横断
• コードレビュー 5 件: PR レビュー（10-30 ファイル変更）

12-2. 評価指標（完了時間 / 手戻り頻度 / 主観満足度）

評価シートの最低項目は以下です。

12-3. セキュリティチーム調整

PoC 開始前に、セキュリティチームに以下を確認してください。

• サンドボックス vs 許可制、どちらが社内ポリシーと整合するか
• データ送信先（Anthropic / OpenAI / Bedrock / Azure）の許諾状況
• 学習除外契約の有無
• 監査ログ要件（保持期間、リージョン分離）

12-4. 経理・調達調整

• 既存クラウド契約（AWS / Azure / GCP）と相性の良い導入経路を経理・調達と擦り合わせ
• 月次の実費試算（サブスク + API + 周辺コスト）を CFO 視点で出す
• 為替変動リスク（1 USD = 130〜160 JPY のレンジ）を予算に反映

12-5. PoC 完了後の意思決定フレーム

PoC 終了時に「Claude Code 採用」「Codex CLI 採用」「併用採用」のいずれかを決める判断フレームは以下です。

判断結果を decision-memo.md にまとめて、半年後に再評価する仕組みを残しておくと、モデル世代の入れ替わりに追随できます。

12-6. 関連記事

選定の前後で参照すると判断精度が上がる関連記事です。

• AI コーディングエージェント徹底比較 2026 — Claude Code / Codex CLI 以外も含む俯瞰
• Claude Code 完全ガイド — Claude Code 単体の機能網羅
• OpenAI Codex CLI 完全ガイド — Codex CLI 単体の機能網羅
• Claude Code 料金プラン徹底解説 — 料金プラン詳細
• Claude Code サブエージェント活用ガイド — Agent Teams / サブエージェントの詳細
• Claude Code のコンテキスト圧縮 5 手段 — コンテキスト圧縮詳細
• Claude Opus 4.7 と Claude Code — 最新モデルの詳細性能
• Claude Code エンタープライズ導入ガイド — 組織導入の実務
• Claude Code MCP 連携 — MCP サーバ統合

よくある質問

まとめ — 「どちらか」ではなく「どう組み合わせるか」で判断する

Claude Code vs Codex CLI の選択は、CLI ツールの機能比較を超えた AI プラットフォーム戦略の選択です。2026 年 5 月時点では、SWE-Bench Verified で GPT-5.5 が 1.1pt リード（88.7% vs 87.6%）、SWE-Bench Pro では Claude Opus 4.7 が 5.7pt リード（64.3% vs 58.6%）、Terminal-Bench 2.0 では Codex CLI が 12pt リード（77.3% vs 65.4%）、Blind 評価では Claude Code が 67% で過半数取得、トークン効率は Codex が約 4 倍少ない、と評価軸ごとに異なる結論になります。

決め手は、（1）既存クラウド契約との適合性（AWS/GCP/Azure）、（2）社内セキュリティポリシー（許可制 vs サンドボックス）、（3）主要タスク特性（設計議論か量産か、フロントエンドかバックエンドか）、（4）AI 活用の中長期ロードマップ、の 4 点です。両ツールとも無料でインストール可能ですので、まずは自社のコードベースで 2 週間ずつ実際に試し、本記事の評価指標シートに沿ってチームのフィードバックを記録してください。

**「どちらか」ではなく「どう組み合わせるか」**で判断するのが、2026 年スタンダードです。Claude Code を設計フェーズに、Codex CLI を量産フェーズに分担し、PR レビューで第二意見を求める構成が、現時点で最もバランスが良い運用です。組織で導入する場合は、まず 5-10 名のチームで 2 週間の PoC を回し、定量指標（完了時間 / 手戻り頻度 / トークン消費 / 月額実費）と定性フィードバック（主観満足度 / 規約適合度）の両方を記録してください。半年〜1 年ごとにこの評価を回し、モデル世代の入れ替わりに追随することで、長期的なツール戦略が安定します。

両ツールの併用検討や、組織導入で「どこから始めるべきか」を判断したい場合は、koromo の AI 戦略・CAIO 代行サービスで実装支援・PoC 設計伴走・コスト試算レビューまで提供できます。「Claude Code と Codex CLI を併用したいが、どの業務にどう振り分けるべきかわからない」「CLAUDE.md / AGENTS.md の整備を 1 から始めたい」「セキュリティポリシーとの整合性を確認したい」といった相談は、無料相談から承っています。