Claude Code は planner、Codex CLI は executor — 両方使って 3 ヶ月、役割分担で見えた実測

この記事の対象読者と得られること

対象読者	この記事で得られること
技術選定担当者	両ツールの非対称な得意領域の整理
両ツール併用を検討中のチームリード	分業アーキテクチャの具体運用
GitHub Actions 連携をしたい方	両 Action を共存させる設定例

はじめに: 「どっちが最強か」論争に疲れたら、両方入れてしまう選択

AI コーディングエージェントを扱っていると、必ず「Claude Code と Codex CLI、結局どっちがいいのか」という話が出てきます。筆者もチームのテックリードとして、この質問を受ける回数がここ半年で体感的に 10 倍以上に増えました。

結論から申し上げますと、この 3 ヶ月両方を本番運用で回してみた立場としては、「どちらか一方を選ぶ」という前提そのものが、少し古い問いの立て方になりつつあるのかな、と感じています。もちろんチーム事情によっては一本化が最適解になる場面もあるので、一概には言えません。ただ、両ツールの設計思想を観察していると、被っている機能よりも得意領域が綺麗にずれている部分の方が目立ちます。

この記事では、「Claude Code を planner、Codex CLI を executor として併用する」という運用を 3 ヶ月続けて見えた実測値と、そこから逆算した役割分担の設計論を共有します。環境依存の固有名詞は匿名化していますし、すべてのチームに当てはまる万能解を提示するつもりもありません。あくまで一事例として読んでいただけると嬉しいです。

本記事の実測値は、筆者が運用している Node.js 製 API サーバー（仮に internal-api と呼びます）1 リポジトリでの結果です。別言語・別規模では数値が変わる可能性があります。

背景: なぜ planner と executor に分かれたのか

本題に入る前に、そもそもなぜ Claude Code と Codex CLI がここまで異なる得意領域を持つに至ったのか、背景を 2 つの角度から整理しておきます。設計思想と歴史の両面を押さえておくと、後続の章で出てくる数値や運用判断の「なぜそうなるのか」が腑に落ちやすくなると思います。

両ツールのアーキテクチャ差はどこから来るのか

両者はどちらも「LLM にコードを書かせる CLI」というくくりでは同じですが、内部構造は思想レベルで異なります。筆者が公開ドキュメントと運用ログを突き合わせて整理した限りでは、次のような差分が見えてきます。

• Claude Code (v2.1.x / Opus 4.7): TypeScript 実装のハーネス上に Agent Teams（サブエージェント並列）、26 種類の Hook event、Plan mode、1M context、Memory system を載せた「計画支援特化」の構成です。メインエージェントが直接手を動かす量を減らし、調査・レビュー・実装をサブエージェントに分散させる思想が強く出ています
• Codex CLI (2026/4 時点の最新系): Rust 実装のバイナリで、kernel-level sandbox（macOS の Seatbelt、Linux の Landlock/seccomp、必要に応じて Bubblewrap）を前提にした exec モード中心の構成です。プロンプトやツール定義のオーバーヘッドを絞り、同一タスクをトークン最小で終わらせる方向に最適化されています

筆者の手元でのトークン消費を比較すると、同じリファクタ指示（Express.js 約 1,200 LOC の差分）という筆者固有の計測条件では、Claude Code 側が Codex の約 1/4〜1/2 程度のトークン消費で収まるケースが多い、というのが実測の感触です。条件を変えると比率は当然ぶれるので、あくまで一例として捉えていただけると幸いです。内訳を --verbose 相当の出力から読み解くと、以下の 4 要素が効いていそうでした。

1. system prompt の長さ: Claude Code は役割説明・スキル定義・安全ガードが長く、1 ターンあたり数千〜1 万 token 単位で上乗せされます
2. tool 定義の数: 宣言されるツールが多く、モデルが毎ターン読み込むメタ情報が大きめです
3. plan オーバーヘッド: Plan mode や TDD 誘導の枠で、実装に入る前に構造化された計画を生成する分のトークンが乗ります
4. Agent Teams の分散オーバーヘッド: サブエージェント間でのコンテキスト受け渡しに、サマリ生成・復元のコストがかかります

一方 Codex 側は、tool 定義を最小限に絞り、exec は 1 プロセス内で完結させる設計のため、こうした分散オーバーヘッドがほぼ発生しません。代わりに、1 ターンあたりに持ち込める文脈が限定的なので、長大なコード横断や「設計ごと考え直す」タイプのタスクは苦手になりがちです。

では、なぜ「長期計画」は Claude Code の強みになるのでしょうか。筆者の理解では、1M context で複数ファイルをまとめて頭に入れられることと、Hook のタイミング制御（PreToolUse で前提確認、SubagentStop で成果物検証など）で「思考プロセスの途中に介入できる」ことが大きいです。人間で言えば「全体を見渡しながら、要所で立ち止まって方針を確かめる」動きがやりやすい、という感覚です。

逆に「実装実行」はなぜ Codex が強いのでしょうか。こちらは kernel sandbox による安全境界と、Rust 実装の stability（長時間 exec でもメモリが暴れにくい、プロセス境界が硬い）が効いています。実装フェーズでは「広く浅く考える」より「決まった手順を壊さず回す」ことの価値が高いので、この特性がよく噛み合います。

ここでのアーキテクチャ比較は、2026/4 時点の公開情報と筆者の運用ログに基づく整理です。両ツールとも内部実装の詳細は一部非公開で、strace 相当の観測で推測している部分も含みます。断定的に受け取らず、1 つの見方として参照してください。

両ツールの 2025〜2026 年変遷

今の役割分担に至るまでの流れも、簡単に振り返っておきます。両ツールともここ 1 年半で大きく変化しているので、記憶の更新を兼ねて整理する意味でも有用だと思います。

• 2025 年前半: Claude Code v1 系の時代です。この頃はシェル呼び出しを中心にした素朴な構成で、hook もまだ数種類に留まっていました。Codex 側は旧来の Node.js 実装で、トークン効率よりも機能網羅を優先していた印象です
• 2025 Q2: OpenAI Codex が再発表され、Rust 移行の初期版が出始めました。ここからサンドボックス周りの設計が kernel レベルに寄り、後の安定性につながっていきます
• 2025 Q4: Claude Code v2 が GA し、Plan mode や Agent Teams の原型が登場します。同時期に Codex が Rust 実装で安定化し、exec サブコマンドを軸とした運用が現実的になってきました
• 2026 Q1: Claude Code v2.1 で Agent Teams が正式機能化し、Hook event が 26 種類まで拡張されました。Codex 側も codex-plugin-cc という Claude Code 連携プラグインが公開され、両ツールのハンドオフが扱いやすくなっています
• 2026/4（執筆時点）: Claude Code の基盤モデルが Opus 4.7 GA に切り替わり、Codex 側は gpt-5.3-codex-spark（Cerebras WSE-3 連携の高速推論版）が実装タスク向けに提供されています。筆者の手元では、実装フェーズの p50 レスポンスが明確に短縮された印象です

この流れを眺めて感じるのは、両ツールが意図的に違う方向へ進化してきたということです。Claude Code は「計画と構造化」を拡張し続け、Codex は「安全で速い実行」を掘り下げ続けています。「どちらが勝つか」というより、棲み分けが年単位で鮮明になってきた、というのが筆者の率直な感想です。もちろん、この傾向が今後も続く保証はなく、どちらかが相手の得意領域に踏み込んでくる可能性は常にあります。運用上は、半年に一度くらいのペースで役割分担を見直すのが健全だと感じています。

1. 非対称な得意領域の整理

まず前提として、両ツールの設計上の差分を棚卸ししておきます。ここが曖昧なまま役割分担を語ると、ただの印象論になってしまいます。

Claude Code の強み: 計画と構造化

• 長文脈 1M tokens: Sonnet 4.5 系で 1M context に対応し、大規模リポジトリの横断把握がしやすい構造になっています
• Agent Teams / サブエージェント: メインのコンテキストを汚さず、調査・リサーチ・レビューを並列化できる仕組みが用意されています
• Hook event 26 種類: PreToolUse PostToolUse SubagentStop などを使って、ポリシーやワークフローを宣言的に差し込めます
• TDD 誘導: test-driven-development 系のスキルが充実しており、「テストを先に書かせる」運用に寄せやすいです

Codex CLI の強み: 実装と実行

• Kernel-level sandbox: macOS の Seatbelt、Linux の Landlock/seccomp を使ったカーネルレベルの隔離で、exec の安全性が担保されています
• Rust 実装: バイナリ単体で動き、起動が速く、常駐プロセスのメモリフットプリントが小さい傾向があります
• トークン消費の少なさ: 後述の実測（Express.js リファクタ、約 1,200 LOC の差分という筆者の計測条件）では、同一タスクで Claude Code の約 1/4〜1/2 のトークン消費に収まったケースがありました。条件次第で比率は変動するので、参考値として捉えてください
• Cloud async: 長時間タスクをクラウド側にオフロードして、ローカルを占有せずに実行する運用が可能です

この非対称性を一枚絵にするとこうなります。

得意領域の整理は「現時点のスナップショット」です。両ツールとも月次で機能追加が行われており、3 ヶ月前の比較記事が既に一部古くなっている印象があります。運用開始時に自分で検証するのが一番確実です。

2. 実測 1: Express.js 製 API のリファクタリング

1 つ目の実測は、ルーティング層とサービス層が癒着してしまった Express.js アプリ（約 2.4 万行）の大規模リファクタです。

タスク内容

• コントローラ 37 本をドメイン別に再配置
• ミドルウェアの順序バグと思われる挙動を調査
• race condition の疑いがあるセッション処理の検証

実測結果

指標	Claude Code	Codex CLI
総トークン消費	約 6.2M tokens	約 1.5M tokens
所要時間	1 時間 17 分	1 時間 41 分
race condition 検出	検出・再現スクリプト提示	検出できず
変更ファイル数	42	38
差分行数	+1,842 / -1,605	+1,611 / -1,488

面白いのは、この計測条件（Express.js リファクタ、約 1,200 LOC の差分）ではトークン消費は Codex が 1/4 程度に収まったのに、所要時間はむしろ Codex の方が長かった点です。Codex は 1 ターンあたりの情報量を絞って慎重に進めるため、調査ターンが増える傾向があります。一方 Claude Code は 1M context を積極的に使い、広範囲をまとめて読み込んで一気に結論まで持っていくスタイルでした。

race condition の検出差は、計画段階で「セッション更新処理を並行実行したときの非決定性を検証する」というメタ目線を持てたかどうかの差だった、というのが率直な感想です。Claude Code はこの種の「実装にはまだ落ちていない仮説」を扱うのが得意な印象を受けました。

数値はあくまで 1 回の計測です。同条件で 3 回回しても、トークン消費は ±15 % 程度ぶれました。個別の数字よりオーダーで捉えていただく方が安全だと思います。

3. 実測 2: 小さなバグ修正での逆転

2 つ目は、同じリポジトリで発生した「特定条件下で 500 を返すバグ」の修正タスクです。再現手順は明確で、原因も特定済みという、いわば「手を動かすだけ」の作業でした。

指標	Claude Code	Codex CLI
総トークン消費	約 180K tokens	約 42K tokens
所要時間	4 分 12 秒	2 分 48 秒
パッチの妥当性	合格	合格
テスト追加	あり（2 件）	あり（1 件）

このサイズのタスクだと、Codex の方が明らかに速く、安く済みました。Claude Code は親切に「関連箇所も念のため見に行く」挙動をするのですが、修正範囲が自明なケースではそれが過剰になることがあります。

筆者の手元では、「再現手順が書ける粒度のバグ修正は Codex、原因調査から必要なバグは Claude Code」という切り分けがしっくり来ています。ただし、チーム内でもこの閾値は人によって違って、「小さくても Claude にレビューさせたい」という意見もあり、一律には決まらないと感じています。

4. 運用パターン: plan.md を起点にした分業

3 ヶ月回してみた結果、一番安定したのは**「Claude Code が plan.md を書き、Codex CLI がそれを実装する」**という流れでした。実装の前後でレビューも分担します。

plan.md のフォーマット

plan.md には最低限、以下を書いてもらうようにしています。

# <変更タイトル>

### なぜやるか
<動機・背景を 3 行以内>

### 何を変えるか
| ファイル | 操作 | 変更内容 |
|---|---|---|

### どう実装するか
1. <手順>

### 検証方法
- [ ] <確認項目>

### リスク・注意点
- <副作用・依存関係>

このフォーマットを Claude 側に守らせると、Codex が読みやすい構造に自然に落ちます。逆に Codex に自由記述で計画を書かせると、実装寄りの詳細が出過ぎて、人間のレビューが追いつかないことがありました。

Codex の実行プロファイル

Codex CLI は exec サブコマンドでプロファイル指定ができます。筆者のチームでは、CI 用とローカル用で分けています。

# CI 用（ネットワーク禁止・ファイル書き込みは作業ツリー内のみ）
codex exec --profile ci --plan ./plan.md --approve never

# ローカル調査用（読み取りのみ、書き込み禁止）
codex exec --profile readonly "セッション更新処理の呼び出し元を列挙"

--approve never は「承認プロンプトを出さない」意味です。プロファイルで権限を絞っているのが前提なので、プロファイル設定なしで付けるのは避けた方が無難です。

レビューの順序: Codex → Claude

レビューは「Codex が先、Claude が後」にしています。理由は 2 つあります。

1. Codex は静的解析寄りの指摘（型、境界条件、未使用変数）が強く、機械的チェックをまず通したい
2. Claude は設計・可読性・TDD の観点が強いので、Codex の指摘を踏まえた状態で投げた方が議論の粒度が揃う

逆順にすると、Claude の設計指摘を反映した直後に Codex が細かいスタイル指摘を返してきて、手戻りが増える感覚がありました。

5. GitHub Actions での共存

両ツールを CI で走らせる際は、公式 Action を共存させています。設定例を貼ります。バージョンは記事執筆時点のもので、実運用前に必ず最新版を確認してください。

name: ai-review

on:
  pull_request:
    types: [opened, synchronize, reopened]

permissions:
  contents: read
  pull-requests: write

jobs:
  codex-static-review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Codex static review
        uses: openai/codex-action@v1
        with:
          mode: review
          profile: ci
          target: ${{ github.event.pull_request.base.sha }}..HEAD
        env:
          OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}

  claude-design-review:
    runs-on: ubuntu-latest
    needs: codex-static-review
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Claude design review
        uses: anthropics/claude-code-action@v1
        with:
          mode: review
          prompt-file: .github/prompts/design-review.md
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

ポイントは needs: codex-static-review で順序を固定していることです。Codex の指摘を含んだ PR コメントを Claude が読む前提にしておくと、重複指摘が減ります。

両 Action を on: push で main に走らせると、API 課金が予想以上に膨らみます。PR イベントと、かつ paths 指定で対象を絞る運用を強く推奨します。筆者はこれを怠って、1 週間で想定の 3 倍弱のコストが出たことがありました。

6. AGENTS.md の共通化

両ツールは AGENTS.md（または CLAUDE.md）というプロジェクトルートのガイドラインを読み込みます。ここを共通化しておくと、役割分担がうまく噛み合います。

筆者のチームのテンプレは以下のような構成です。

# AGENTS.md

### 役割
- Claude Code: 計画立案・設計レビュー・TDD 誘導
- Codex CLI: 実装・静的レビュー・CI 実行

### 共通ルール
- 変更前に対象ファイルを必ず読む
- テスト追加必須（単体テストは t-table 形式）
- コミットメッセージは Conventional Commits

### Claude Code 専用
- plan.md を先に生成する
- 1M context を活用して横断調査を行う

### Codex CLI 専用
- exec は必ず profile 指定
- --approve never はプロファイル前提でのみ使用

共通部分と固有部分を分けておくと、新メンバーが「どの指示がどちらのツール宛てか」を混乱せずに済みます。実際、チーム内の温度感としては「共通ルールの粒度をどこまで揃えるか」で議論が割れることもあり、完璧な答えはまだ出ていません。

7. コストバランスの考え方

3 ヶ月分の請求を振り返って、金額感の肌感も共有しておきます。金額はワークロードに強く依存するので、あくまで参考値として捉えてください。

内訳	概算比率
Claude Code（plan.md 生成・設計レビュー）	約 62 %
Codex CLI（実装・静的レビュー・CI 実行）	約 28 %
CI 環境コスト	約 10 %

「高い Claude にどこまで頼るか」が支出を左右します。実装そのものを Claude にやらせると一気に跳ねるので、計画とレビューに絞る運用に落ち着きました。逆に Codex 側をケチって計画なしで走らせると、やり直しが増えてトータルで逆転することもありました。

コスト最適化の観点からは、prompt caching の活用が効きます。Claude Code はキャッシュヒット率で費用が大きく変わるため、CLAUDE.md や plan.md を頻繁に書き換え過ぎない運用がおすすめです。

8. うまくいかなかったこと

良い話ばかりだと参考にならないので、失敗もいくつか記しておきます。

• Codex にリファクタの設計判断を委ねた: 結果的にテストは通るが、責務分離として微妙な切り方になり、Claude に再度投げ直す羽目になりました
• Claude に機械的な rename を依頼した: 動くのですが、トークン消費が Codex の 5 倍以上かかり、コスト的に割に合いませんでした
• plan.md を書かずに両ツールを順番に走らせた: それぞれが独自の前提で動き、結果がマージできませんでした

3 つ目は特に学びが大きく、共通の「中間成果物」を経由させないと分業にならない、という当たり前の事実を痛感しました。

比較: 4 パターンを同じ物差しで並べる

ここまで「Claude + Codex の分業」を前提に語ってきましたが、実務では「そもそも分業が本当に必要か」という問いとセットで検討したい場面が多いはずです。そこで、同じタスクを 4 パターン（Claude only、Codex only、分業、全手動）で回したときの結果を、同じ物差しで並べてみます。

同一タスク 4 パターンの比較

以下は、筆者のチームで同じ Express.js リファクタ（約 1,200 LOC の差分）と、別件の race condition 調査を題材に計測した結果です。金額は各プランの月額ベース（2026/4 時点、Pro 契約を想定）で、ざっくりした参考値として記載しています。

軸	Claude only	Codex only	分業（Claude plan + Codex exec）	全手動
Express.js リファクタ（1,200 LOC）	約 6.2M tokens / 1h17m	約 1.5M tokens / 1h41m	約 3.8M tokens / 1h22m	人日単位（実測困難）
race condition 検出	○（再現スクリプト提示）	×（検出できず）	○（Claude 側で検出）	人依存
Plan 品質	高	中（実装寄りに偏る）	高（Claude が主担当）	人依存
実装速度	中	速い	速い（Codex が主担当）	遅い
月額（Pro 契約ベース）	$20	$20	$40	人件費

数値を見ると、**「トークン効率の Codex only」「計画品質の Claude only」「総合バランスの分業」「コスト最小の全手動（ただし人件費別）」**という 4 つの極が綺麗に浮かび上がります。特に race condition のような「仮説を立てて検証する」系のタスクは、Claude が絡むパターンでないと検出できなかった、という点が印象的でした。

どう分業すべきか

4 パターンの適用先を、筆者なりのマトリクスで整理するとこうなります。あくまで一事例なので、そのまま適用するというより、自チームの物差しを作る叩き台として使っていただけると幸いです。

• 分業を選ぶケース: 計画と実装の両方が重い、中〜大規模タスクです。横断的な設計判断が要る一方で、実装量も無視できない規模の場合、Claude の 1M context と Codex の実行効率の両方が効いてきます
• Claude only を選ぶケース: 1M context が前提になる長文脈統合（複数サービスを跨ぐリファクタ、レガシー移行、仕様書と実装の突き合わせなど）です。Codex 側に無理やり詰めると、ターンが細切れになって逆に高くつきます
• Codex only を選ぶケース: 単純 CRUD、実装量が支配的なタスク、GitHub Actions 上での自動実行など、「計画はすでに人間側で固まっている」ケースです。トークン効率と実行安定性が素直に効きます
• 全手動を選ぶケース: ビジネスロジック、コンプライアンス、セキュリティ重要箇所など、「間違いのコストが AI コストを大きく上回る」領域です。AI に下書きさせてもよいのですが、最終的な判断と手触りは人間が持つべき、という整理です

このマトリクスを引いてから、筆者自身「全部 AI に任せる」発想が減りました。適材適所で切り分けると、結果的に AI に頼る範囲が狭くなるのに、成果物の質は上がる、という逆説的な手触りがあります。

月 $40 の分業は割に合うか

最後に、分業のコスト感について率直に書いておきます。Pro 契約を 2 つ抱える前提だと月 $40 で、Claude only や Codex only の倍になります。「単純に 2 倍払って元が取れるのか」という問いは当然出てくるので、筆者の整理を共有します。

まず、分業にはオーバーヘッドがあります。plan.md を介したハンドオフ、レビューの往復、ツール間の前提ずれを吸収する時間などです。体感では、単独ツール比で 10〜15 % 程度の追加コスト（時間・トークンの両方）が乗ります。ここだけを見ると、分業は割高に見えるかもしれません。

一方で、筆者の手元では本番事故を 1 件でも未然に防げた時点で、月 $40 は回収できるという感覚があります。race condition の見落としが 1 件あれば、調査・修正・関係者への報告で軽く数人日が飛びます。その 1 件を Claude 側の計画段階で捕まえられたことが、3 ヶ月で 2 回ありました。

コスト面でもう 1 つ補足すると、$40/月は 1 日あたりおよそ $1.3、1 人時の人件費と比べれば圧倒的に安い水準です。人件費を物差しにすると、AI ツールへの支出はむしろ積極的に増やす方向に倒す方が合理的だと感じます。ただし、2 ツールを並行運用することの学習コストは無視できません。筆者のチームでは、最初の 1〜2 週間は「どちらをいつ使うか」で迷いが出て、生産性が一時的に落ちました。この期間をどう見積もるかは、チーム規模によって体感が変わると思います。

分業の費用対効果は、タスク分布に強く依存します。「単純作業が 8 割、設計判断は 2 割」というチームだと、Codex only に寄せた方が安く上がるはずです。自分たちのタスク分布を 2 週間ほど実測してから意思決定するのが、遠回りに見えて一番確実だと思います。

9. まとめ: Codex for keystrokes, Claude Code for commits

3 ヶ月の運用を言語化すると、こんなフレーズに落ち着きました。

Codex for keystrokes, Claude Code for commits.
キーストローク（細かな実装作業）は Codex、コミット（設計判断が混じる変更）は Claude Code。

もちろん、これはあくまで筆者のチーム事情と、Node.js 中心のスタックという前提で成り立つ整理です。Python や Go、モバイル開発では比重が変わるかもしれませんし、1 人開発と 10 人チームでも最適解は違うはずです。

それでも、「どちらか一方に寄せる」より「非対称な得意領域を前提に分業させる」方が、結果的にアウトプットの質もコスト効率も改善した、というのは偽らざる実感です。これからツール選定を始める方は、一度両方を 2 週間ずつ回してみて、自分のタスク分布と照らし合わせてみるのが遠回りに見えて近道だと思います。

この記事が、同じ悩みを抱えている方の役に立てば嬉しいです。もしチームでの運用例や違う数値感があれば、コメントで共有いただけると筆者も学びになります。

参考

• Morph LLM Comparisons: Codex vs Claude Code
• Blake Crosley: Codex vs Claude Code 2026
• Developers Digest: Claude Code vs Codex App 2026
• Jock's Thoughts: AI Coding Harness Agents 2026
• Anthropic: Claude Code 公式ドキュメント（Hooks / Plan mode / Agent Teams）
• OpenAI: Codex CLI リポジトリ（Rust 実装 / Sandbox 設計）
• Anthropic: Claude Opus 4.7 モデルカード
• OpenAI: gpt-5.3-codex-spark 発表ノート（Cerebras WSE-3 連携）