Claude CodeとCodexを一緒に使う：3つの作業パターン

エージェントとバイブコーディングに関する実践資料：Ailootのドキュメント。

2026年、なぜ1つのツールだけでは足りなくなったのか？#

2026年5月、OpenAIはCodex CLIのGPT-5.5モデルでAnthropicの領域に踏み込みました。最近のベンチマークでは、CodexはターミナルタスクとSWE-bench Verifiedモードで明確な優位性を示しています。AnthropicはOpus 4.8とDynamic Workflowsで応じ、SWE-bench Proでのリードを維持しました（データ漏洩を防ぐために設計されたテストで、ベンチマークデータを使ってモデルを学習させても有利になりません）。詳しい直接比較はCodex対Claude Codeガイドで取り上げています。ここでは、さっそく両者の組み合わせを見ていきましょう。

2026年には、単独の勝者はいません。目立つのは、チームが低コストな自律作業にはCodexを、リスクの高いアーキテクチャ上の判断にはClaude Codeを使い続けているというパターンです。

作業の分担を決める重要な違いは次のとおりです。

• Claude Codeは調査役です。 長く掘り下げた対話を続け、前提を問い直し、解決策を選ぶ前に複数のアプローチを検討します。最初から正しい対応が明らかでない場面に向いています。
• Codexは実行役です。 タスクを受け取り、サンドボックスで成果に向けて作業を進めます。すぐに依頼して結果を得るサイクルが必要な、明確なタスクに向いています。

両方のツールを使えるなら、「考えること」と「実行すること」のどちらかを選ぶ必要はありません。タスクの種類に応じて任せ先を決められます。どちらを先にインストールするか決めていない場合は、Codex対Claude Codeガイドで直接比較しています。

パターン1：Claude Codeがコードを書き、Codexがレビューする#

このパターンでは、Claude Codeが引き続き主担当の編集役です。CodexはPRの段階で、クラウドモードを通じてのみ参加します（CodexはChatGPTまたはGitHub Appから直接実行されるため、2つ目のターミナルは必要ありません）。

実際の進め方：

1. ステップ1：Claude Codeで機能を書く

   VS Codeでリポジトリを開き、Claude Codeを起動して、Plan Modeに切り替え、機能のアーキテクチャについて話し合います。コードの草案、テスト、マイグレーションが作成されます。機能ブランチにコミットします。

2. ステップ2：GitHubでPRを作成する

   機能ブランチからmainへのプルリクエストを開きます。説明欄に@codex review this PR for edge cases, security issues, and test coverage gapsと入力します。

3. ステップ3：Codexが非同期でレビューする

   クラウドモードでは、Codexがリポジトリをサンドボックスにクローンし、差分を読み、テストとリンターを実行し、脆弱性を探します。5〜15分後、PRに直接コメントを残します。

4. ステップ4：Claude Codeで変更を加える

   Claude Codeに戻り、Codexのコメントをコンテキストとして渡します。「レビューで見つかった点を共有します。1、3、5を修正してください。」Claudeが変更を加え、リポジトリに公開します。

このパターンが機能するのは、ClaudeとCodexが異なるデータセットで学習され、異なる考え方を持つからです。CodexはClaudeのモデルの盲点によって見落とされた点を見つけ、逆も同様です。

パターン1のリスク：

• Codexはアーキテクチャ上の問題を見落としたまま、承認してPRをクローズすることがあります。重要な判断は自分でも確認してください。
• トークンコストが二重になります。ClaudeとCodexが同じコードを分析するためです。複雑な機能では見返りがありますが、小規模な機能には割高です。
• クラウドモードのCodexは、環境変数やローカルデータベースなどのローカル環境を確認できません。機能がそれらに関係する場合は、手動実行に切り替えてください。

パターン2：Codexが草案を作り、Claude Codeがアーキテクチャを整える#

2026年に紹介されたプロジェクトでは、このパターンを使って、メール通知を備えた登録ファネルのプロトタイプを一晩で作る必要がありました。この状況では、Claude Codeとアーキテクチャを1時間話し合うこともできます。一方、Codexは12分で動く草案を作りました。

進め方：

進め方はこうです。最初の15分間はCodexが下準備を進め、その後Claudeが本番品質まで仕上げます。

Codexに最初から仕上がりを整えるよう頼むと、曖昧さに行き詰まります。Claude Codeに最初から速さを求めると、あれこれ考え直し始めます。それぞれに本来向いている作業を任せてください。

パターン2のリスク：

• Codexが前提を含む草案を生成し、後から整理するのが難しくなることがあります。草案の方向性が違っていたら、修正するより捨てて作り直すほうが安く済みます。
• Claude Codeは変数名の変更に30分を費やし、本当のアーキテクチャ上の問題を忘れることがあります。「きれいにして」ではなく、具体的な変更を指示してください。
• セッション間でコンテキストが失われます。Codexが意図したことをClaude Codeに理解させるには、AGENTS.md（パターン5を参照）か、ファイル冒頭の詳しいコメントが必要です。

パターン3：Codexはインフラ、Claude Codeはビジネスロジックを担当#

考え方はシンプルです。コードベースの異なる部分には、それぞれ異なる働き方が適しています。

このパターンは、複数のClaude Codeインスタンスを並行して実行するアプローチを補完します。そちらではgit worktreeを使って同じモデルに異なるタスクを担当させますが、こちらでは2つの異なるエージェントが責任範囲を分担します。

インフラ層（Codex）：

• GitHub Actions：新しいジョブの追加、キャッシュの調整、CIの高速化。
• テスト：リファクタリング後に統合テスト一式を書く。
• Prismaマイグレーション：マイグレーションを生成し、ロールバックできることを確認する。
• Docker / Coolifyの設定：環境変数を追加し、ヘルスチェックを更新する。
• Cronジョブ：Cronハンドラー一式を書く。

インフラタスクには、定型コードを含む小さなファイルが多数あることが多いため、Codexが適しています。「じっくり考える必要」にとらわれず、最後まで作業を進めます。

ビジネスロジック（Claude Code）：

• 登録ファネル：各ステップでユーザーに何を表示するか。
• 割引、分割払い、ギフト用プロモーションコードを考慮した料金計算。
• 自動通知のワークフロー：どのトリガーと条件を使うか。
• 外部API連携：エラー処理、再試行、キャッシュ。
• 財務モデル：ユニットエコノミクスの計算と収入予測。

これらのタスクには製品について考えながら対話を重ねることが必要なため、Claude Codeが適しています。シナリオについて話し合わなければ、ユーザーが実際に困っている点を考慮しない技術的な解決策になってしまいます。

リポジトリ内での作業分担：

project/
├── .github/workflows/      ← Codex (CI, tests)
├── infra/                  ← Codex (Docker, Coolify, migrations)
├── scripts/                ← Codex (task scripts)
├── tests/                  ← Codex (integration tests)
├── src/
│   ├── lib/                ← Claude Code (business logic)
│   ├── app/                ← Claude Code (routes, forms, pages)
│   └── components/         ← Claude Code (UI)
└── prisma/
    └── schema.prisma       ← Claude Code (data models—product decision)

これは厳格なルールではありません。たとえば公開後の通知送信など、GitHub Actionに製品上の意味がある場合は、Claude Codeがその編集を担当することもあります。ただし、タスクの80%はこの分担にうまく当てはまります。

CLAUDE.mdとAGENTS.mdをどう同期するか？#

Claude CodeとCodexを並行して使った経験の中で、予想外の問題が起きました。Claude CodeはCLAUDE.mdに書かれた「確認なしにマイグレーションを変更しない」というルールに従いました。一方Codexはそのルールを見られず、ためらわずに作業環境でマイグレーションを実行しました。データベースが3回壊れた後、両方のファイルを適切に同期する方法を見つける必要が生じました。

両ファイルとも、プロジェクト情報、会話の好み、テストコマンド、対象外フォルダー、コミット規約を書けます。共通に適用するルールを再利用し、固有のコマンドと設定を分けます。マイグレーションの変更禁止が両者に適用されるなら、両方の指示に含めてください。

両方のファイルで共通する内容：

• 技術スタック：フレームワーク、データベース、ORM。
• プロジェクトの説明：何のためのものか、誰向けか、主要なエンティティ。
• 禁止事項：触れてはいけないフォルダーと、実行してはいけないコマンド。

異なる内容：

• Claude Code固有のフック、設定レイヤー、MCP設定は該当する設定ファイルに置きます。その規約の文章をCLAUDE.mdから案内できますが、コピーしただけで移植可能な実行設定にはなりません。
• AGENTS.mdはオープン標準です。Codex、Cursor、Aider、Continue、Cline、Factory Droidなど、25以上のエージェントが読み込みます。別のガイドではAGENTS.md形式をさらに詳しく取り上げています。CodexのMCP設定は~/.codex/config.toml（TOML形式。ClaudeのようなJSON形式ではありません）に保存されます。

2026年によく使われるパターンは、モノレポの/context/フォルダーにルールの正本を置き、同期スクリプトでCLAUDE.md、.cursor/rules/*.mdc、AGENTS.mdを生成する方法です。ツール固有のファイルは読み取り専用とし、編集するのは正本だけです。

同期スクリプトは、pre-commitフックまたはGitHub Actionを通して実行します。CLAUDE.mdに直接変更を加えると、CIが失敗します。これにより、ツール間のルールのずれを防げます。

もう1つの選択肢は、Claude Code向け公式Codex Pluginです（2026年3月30日発表、バージョン1.0.4）。Claude Codeに/codex:review、/codex:adversarial-review、/codex:rescueコマンドを追加します。Codexはサブエージェントとして、独自の~/.codex/config.tomlとAGENTS.mdを使用して動作します。これにより2つ目のターミナルが不要になりますが、AGENTS.mdは引き続き必要です。

両方を使い続ける費用と節約効果は？#

以下は2026年6月時点の料金です（AnthropicとOpenAIの公式サブスクリプションページのデータおよびCodex公式ページ）：

最低限の実用的な組み合わせ： Claude Pro（$20）+ ChatGPT Plus（$20）= 月額$40。1日に数回セッションを行う個人プロジェクトには十分です。

積極的にバイブコーディングを行う人向けの実用的な組み合わせ： Claude Max 5x（$100）+ ChatGPT Plus（$20）= 月額$120。紹介された経験では、直近2か月間この組み合わせを使い、その間に3つのプロジェクトを公開しましたが、Claudeの利用上限に達することはありませんでした。

チーム向けの組み合わせ： Claude Max 20x（$200）+ Codex Pro（$200）= 月額$400。PRレビューやクラウドタスクをローカル作業と並行して継続的に実行する場合に適しています。

節約につながる点：

• 機能ごとの作業時間が減る。 著者の計測では、5月から6月にかけて12個の機能を対象に、「アイデアが浮かんだ」から「本番稼働」までの時間が、Claude Code単独の4時間から、組み合わせ利用の2.5時間に短縮されました。著者のタスクで計測した結果であり、あなたの場合は異なる数値になるでしょう。
• 不具合が減る。 紹介された観察によると、CodexによるPRレビューでは、Claudeが見落とした問題10件のうち2〜3件を発見します。本番環境で問題が1件起きるごとに、修正に1〜2時間かかるうえ、サービス停止につながる可能性もあります。
• 並列作業。 ユーザーがClaudeで機能Bに取り組む間、Codexはクラウドモードで機能Aを処理します。これにより処理能力が2倍になります。

週に1〜2個の機能を書く場合は元が取れません。その場合はClaude Code Proだけで十分です。

2つ目のツールが不要なのはどんなとき？#

この組み合わせが誰にでも必要なわけではありません。かえって余計な雑音になることもよくあります。2つ目のツールが不要な状況を4つ紹介します。

1. 始めたばかりの個人プロジェクト。 アイデアが1つだけで、試している段階なら、Claude CodeとPlan Modeだけで1か月は十分です。速度がボトルネックになったら、組み合わせを追加しましょう。

2. 厳しい予算。 月額$20が上限なら、Claude Proを使えば十分です。Claude単独でバイブコーダーのタスクの80%に対応できます。

3. シンプルなアーキテクチャ。 フォーム付きのウェブサイト、シナリオが数個のボット、APIラッパーのスクリプトなどでは、レイヤーで分担しても何も得られません。Claude Codeだけで対応できます。

4. すべてがすでにうまくいっている。 すでにClaude Codeを使っていて、過去1か月に行き詰まったり失敗したりしたタスクが1つもないなら、うまくいっているものを変える必要はありません。必要性が明らかになったらCodexを追加しましょう。

反対に、2つ目のツールを導入する時期が来た明確なサインは次のとおりです。

• Claude Codeがボトルネックになり、自分の作業を進めずにClaude Codeを待つようになった。
• 定型的なインフラ作業（マイグレーション、CI、テスト）が増え、それをClaudeで進めるのが嫌になった。
• チーム内の人によってすでに使うツールが異なり、共通言語が必要になった。
• ベンチマークで、Codexが自分のタスクの種類（たとえばターミナル操作）をより速く処理できると分かった。

一晩で組み合わせを設定する方法#

最初の夜に行う具体的な計画：

1. ステップ1：Codex CLIをインストールする

   ターミナルでnpm install -g @openai/codexを実行します。codex loginでログインするとブラウザーが開き、ChatGPTアカウントでサインインできます。Codexはサブスクリプション（Plus / Pro）を認識し、その利用上限を使います。

2. ステップ2：運用ドキュメントとしてAGENTS.mdを書く

   CLAUDE.mdを確認し、両ツールへ適用するテスト・lint、コミット形式、禁止フォルダー、スタックをAGENTS.mdで再利用します。会話の好みも共有できます。固有コマンドの参照を調整し、実行フックやMCPは各ツールの設定へ置いてください。Markdownのコピーだけでは設定されません。

3. ステップ3：プロジェクトに合ったパターンを選ぶ

   CIを使う個人開発者ならパターン1（Claudeが書き、Codexがレビュー）を使います。新規プロジェクトでスピードが必要ならパターン2（Codexが草案を作り、Claudeが整理）を使います。インフラ層がある既存プロジェクトならパターン3（レイヤーで分担）を使います。

4. ステップ4：1週間試す

   選んだパターンを5〜7個の機能で試します。時間を記録し、それぞれにどちらのツールが適していたかを記録します。1週間後には、自分の実際の利用状況が分かります。

5. ステップ5：ルールの同期を設定する

   同期に関するセクションを参考に、scripts/sync-agent-rules.shスクリプトを追加します。pre-commitフックまたはGitHub Actionとして接続します。これでルールが両方のファイルに自動的に反映されます。

この組み合わせは魔法ではありません。2つの知性を使い、それぞれが相手の弱点を補うだけです。大切なのは「ClaudeかCodexか」という議論にとらわれないことです。適切な答えは、以前から「タスクの種類に応じて、ClaudeとCodexの両方を使う」だったのです。

エージェント活用の実践資料：Ailootのドキュメント。

その他の資料とツール：Ailoot。