Claude Code と Codex を組み合わせる

ワークフローでは、Claude Code と Codex のどちらに実行させるかを、agent フィールドでタスクごとに指定できます。そのため、1 つのワークフローの中で 2 つのエージェントに作業を分担させることも、一方にもう一方の結果をチェックさせることもできます。以下の説明は、手元のコンピューターに両方がインストールされていて、どちらも問題なく使えることを前提にしています。

組み合わせる理由

2 つのエージェントのモデルは判断の傾向が異なり、同じコードを見ても、見落とす問題はたいてい同じではありません。一方にもう一方の結果をチェックさせたり、両方に同じ作業をさせて比べたりすると、一方だけでは見落としていた問題が見つかります。一方がうまくこなせないタスクや実行を拒否するタスクは、もう一方に任せることもできます。利用上限も 2 つのエージェントで別々に計算されるため、一方が上限に達しても、もう一方に任せたタスクは実行を続けられます。2 つのエージェントの利用上限は互いに影響しないを参照してください。

3 つの分担方法

よく使われる分担の方法は 3 つあり、違いは 2 つ目のエージェントが担う役割にあります。もう一方の結果をチェックして修正するか、もう一方と同じ作業をそれぞれ行うか、自分に向いているタスクだけを引き受けるかです。最初の 2 つは互いにチェックし合うためのもので、3 つ目はそれぞれの得意分野を生かすためのものです。

以下の例はどれも完全なワークフローファイルで、そのまま .codedag/dags/ に保存して実行できます。分担のしかたがわかりやすいように、プロンプトは短めに書いています。実際に使うときは、「タスクの分割とプロンプトの書き方」で紹介している構成に沿って、内容を書き足すとよいでしょう。

一方が作業し、もう一方がチェックして修正する

最も一般的なのは、一方がタスクを終えたあと、次のタスクでもう一方にレビューと修正を任せ、必要に応じて最初のエージェントに戻して再確認させる方法です。どのチェックも、直前のステップのコードを書いていないほうのエージェントが担当します。次のワークフローでは、まず Codex が長すぎる関数をリファクタリングし、続いて Claude Code がそのリファクタリングをレビューして修正し、最後に Codex が Claude Code の修正を再確認します。

tasks:
  - id: 1
    title: 長すぎる関数をリファクタリング
    agent: codex
    mode: yolo
    prompt: |
      プロジェクトの中で最も長く、最も読みにくい関数を 1 つ見つけ、動作を変えずにリファクタリングしてください。まず現在の動作をカバーするテストを追加し、それからリファクタリングして、最後にテストを実行し、すべて通ることを確認します。
      どの関数を選んだか、なぜ選んだか、どんな変更をしたかを、docs/reviews/refactor.md に書いてください。

  - id: 2
    title: リファクタリングをレビューして修正
    dependencies: [1]
    agent: claude
    mode: bypassPermissions
    prompt: |
      前のタスクが関数を 1 つリファクタリングしました。説明は docs/reviews/refactor.md にあります。
      git diff main...HEAD を実行してその変更をすべて確認し、リファクタリングによって元の動作が変わっていないか、追加されたテストが動作の変化を検出できるか、コードが本当に読みやすくなったかをチェックしてください。
      実際に問題だと確認できたものを修正し、テストを実行して、すべて通ることを確認してください。見つかった問題と対処の内容は、docs/reviews/refactor.md の「レビューと修正」の節に追記してください。

  - id: 3
    title: 修正を再確認
    dependencies: [2]
    agent: codex
    mode: yolo
    prompt: |
      docs/reviews/refactor.md の「レビューと修正」の節を読んでください。別のエージェントが今回のリファクタリングをレビューし、修正した記録です。
      git diff main...HEAD を実行して現時点の変更をすべて確認し、修正が正しく、漏れがなく、新しい問題を持ち込んでいないかを 1 件ずつ確かめてください。適切でない修正は、その場で直してください。
      テストを実行してすべて通ることを確認し、再確認の結論を同じファイルの「再確認」の節に追記してください。

3 つのタスクは順番に実行され、デフォルトの分離ブランチモードを使います。ワークスペースがプライマリリポジトリ 1 つだけでも実行できます。下流が始まる前に、上流の変更はコミットとして下流のブランチにマージされています。そのため、レビューのタスクは git diff main...HEAD を実行すれば、今回のワークフローが始まってからの変更をすべて確認できます。ワークフローが main から始まっていない場合は、main を開始時のブランチに置き換えてください。

レビューで見つかった問題とその対処は、すべて docs/reviews/refactor.md に書かれ、次のエージェントはこのファイルから前のエージェントの結論を読み取ります（結論を下流に渡すを参照）。問題が見つからなかった場合も、結論は書かせておきます。書かれていなければ、下流には知る手段がありません。また、分離ブランチモードでは、変更を何も残さなかったタスクは自動承認されず、止まってレビューを待つことになります。

この方法で、作業そのものを担うタスクのほかに増えるのは、チェックのタスクだけです。互いにチェックし合う方法のなかではコストが最も低く、機能の実装、バグの修正、リファクタリングのように、書き終えたらすぐチェックしたい作業に向いています。この方法の限界は、レビューする側が、問題だと判断したものをその場で修正してしまうことです。実際には問題でないものまで「修正」されることがあり、次のエージェントによる再確認は、こうした変更を見つけるためにあります。どの問題も、もう一方の判断を経てから手を付けるようにしたい場合は、チェックと修正を 2 つのタスクに分けることもできます。チェックのタスクは問題を一覧にするだけでコードを変更せず、修正のタスクはもう一方に任せて、指摘が妥当かどうかを 1 件ずつ判断させ、妥当なものだけを修正させます。チェックしたい段階がさらに多い場合は、同じ要領でチェーンを交互に伸ばしていきます。

交互にチェックさせても、最後に自分で確認することの代わりにはなりません。CodeDAG は、エージェントが作業を終えたことをもってタスクの完了と判断し、チェックの結論は読みません。再確認のタスクが直しきれずに最後は諦めた場合でも、タスクは done になり、デフォルトではそのまま自動承認されます（検証タスクを参照）。結果が引き渡される前に自分の目で確認したい場合は、最後のタスクに autoAccepted: none と書きます。レビューの方法は、タスクとワークフローをレビューするを参照してください。

両方がそれぞれ作業し、結果をまとめる

問題をできるだけ見落としたくない場合は、2 つのエージェントに、互いの結果を見せずに同じ作業をそれぞれ行わせます。そのうえで、両方に依存するタスクに、内容の確認、重複の整理、とりまとめを任せます。次のワークフローでは、2 つのエージェントがそれぞれ直近のコミットをレビューし、最後に 1 つの問題リストにまとめます。レビューの範囲を、レビューしたいコミット範囲やディレクトリに置き換えれば、自分のレビューにも使えます。

executionMode: shared-workspace   # 3 つのタスクはどれもレポートファイルを書くだけなので、ブランチは不要
maxConcurrency: 2                 # 2 つのレビューを同時に実行する

tasks:
  - id: 1
    title: 直近のコミットをレビュー（Claude Code）
    agent: claude
    mode: bypassPermissions
    prompt: |
      直近のコミットで加えられた変更をレビューし（git show HEAD で確認できます）、バグ、見落とされているエッジケース、保守しにくい書き方を見つけてください。
      問題ごとに場所、原因、修正案を明記し、docs/reviews/review-claude.md に書いてください（すでにある場合は、そのまま上書きします）。
      レビューは独立して行い、docs/reviews/ にあるほかのファイルは読まないでください。コードを読むだけにして、テストは実行せず、ほかの既存ファイルも変更しないでください。

  - id: 2
    title: 直近のコミットをレビュー（Codex）
    agent: codex
    mode: yolo
    prompt: |
      直近のコミットで加えられた変更をレビューし（git show HEAD で確認できます）、バグ、見落とされているエッジケース、保守しにくい書き方を見つけてください。
      問題ごとに場所、原因、修正案を明記し、docs/reviews/review-codex.md に書いてください（すでにある場合は、そのまま上書きします）。
      レビューは独立して行い、docs/reviews/ にあるほかのファイルは読まないでください。コードを読むだけにして、テストは実行せず、ほかの既存ファイルも変更しないでください。

  - id: 3
    title: 2つのレビューをまとめる
    dependencies: [1, 2]
    agent: claude
    mode: bypassPermissions
    prompt: |
      docs/reviews/review-claude.md と docs/reviews/review-codex.md は、2 つのエージェントが同じコミットをそれぞれ独立にレビューした結果です。
      コードと照らし合わせて 1 件ずつ確認してください。重複している指摘は 1 つにまとめ、妥当でない指摘は削除し、どちらか一方にしかない指摘は残します。
      結果は docs/reviews/review.md に書き、各項目に、どちらのレビューによるものか、または両方が挙げていたかを明記してください。書き込むのはこのファイルだけにしてください（すでにある場合は、そのまま上書きします）。

2 つのレビュータスクのプロンプトは、出力先のパスだけが違います。それぞれが別のファイルに書くので、2 つの経路の結果が互いを上書きすることはありません。まとめのタスクは、2 つのリストをつなぎ合わせるだけでなく、コードと照らし合わせて 1 件ずつ確認します。どちらのエージェントも、妥当でない指摘をすることがあるからです。このタスクはどちらのエージェントに任せてもかまいません。より信頼しているほうを選び、必要に応じて model でより高性能なモデルを指定します。

この例では共有ワークスペースモードを使っています。3 つのタスクはどれもレポートファイルを書くだけなので、ブランチもコミットも必要ありません。2 つのレビューは、レプリカがなくても同時に実行できます。このとき、同時に実行されるタスクの数は maxConcurrency だけで決まります。プロジェクト設定のデフォルト値は、レプリカがない場合は 1 なので、ワークフローの中で 2 と書いています。投入時には、CodeDAG が Non-isolated concurrency mode. と表示し、同時に実行されるタスクの書き込みが互いに分離されなくなることを知らせます。この例では 2 つの経路がそれぞれ別のファイルに書くので、影響はありません。2 つの経路は同じディレクトリで作業し、相手が書いている途中のファイルも見えます。そこでプロンプトでは、独立性を保つために、docs/reviews/ にあるほかのファイルを読まないよう求めています。テストを実行しないよう求めているのも、双方のビルドやテストが同じディレクトリで干渉し合うのを避けるためです。

2 つの経路がどちらもコードを変更する場合は、代わりにデフォルトの分離ブランチモードを使います。2 つの経路はそれぞれのブランチで作業するため、互いの変更はもともと見えません。まとめのタスクが始まる前に、両方の変更がそのタスクのブランチにマージされます。2 つの経路を同時に実行するには、ワークスペースが 2 つ以上必要です。準備の方法は、並列実行とワークスペースを参照してください。

同じ作業を 2 回行うことになるため、この方法は、問題を見落としたときの代償が大きい場面に向いています。マージ前の重要なレビュー、セキュリティチェック、難しいバグの原因分析などです。2 つのエージェントにそれぞれ案を書かせ、まとめのタスクに 2 つの案を比較させて、よいほうを選ばせるか、1 つの案にまとめさせることもできます。

タスクに合わせて割り当てる

互いにチェックさせる必要がない場合は、各タスクをより向いているほうのエージェントに任せるだけ、という組み合わせ方もあります。次のワークフローでは、Claude Code が計画を立て、Codex が計画に沿って実装し、Claude Code が変更の説明を書きます。この割り当てはあくまで一例です。

tasks:
  - id: 1
    title: 計画を立てる
    agent: claude
    mode: bypassPermissions
    prompt: |
      プロジェクトの中から、対応する価値が最も高く、変更範囲も小さい TODO（TODO コメントまたは FIXME コメント）を 1 つ見つけてください。見つからない場合は、変更がごく小さく済む改善を 1 つ選んでください。
      計画を docs/plans/todo.md に書いてください。何を変更するか、どのファイルが関係するか、どう検証するかを含めます。書くのは計画だけにして、コードは変更しないでください。

  - id: 2
    title: 計画に沿って実装
    dependencies: [1]
    agent: codex
    mode: yolo
    prompt: |
      docs/plans/todo.md に沿って、まず最小限のテストを書き、それから実装し、テストを実行してすべて通ることを確認してください。計画ファイルは変更しないでください。

  - id: 3
    title: 変更の説明を書く
    dependencies: [2]
    agent: claude
    mode: bypassPermissions
    prompt: |
      git diff main...HEAD を実行して今回の変更をすべて確認し、docs/plans/todo.md と照らし合わせたうえで、
      コードレビュー担当者に向けた変更の説明を docs/plans/todo-pr.md に書いてください。何を変更したか、なぜそう変更したか、どう検証するかを含めます。

タスクをどちらのエージェントに任せるかは、決まったルールではなく、自分のプロジェクトの事情をもとに決めるべきです。よくある判断材料は次のとおりです。

• 設定。 スキルと MCP サーバーは、エージェントごとに別々に設定します。タスクで使うスキルや MCP サーバーが一方にしか設定されていない場合は、そちらに任せます。
• 実績。 自分のコードベースで、同じ種類のタスクをどちらがより安定してこなせるかです。同じタスクを両方に 1 回ずつ任せてみれば、比較できます。
• 拒否と行き詰まり。 一方が実行を拒否するタスクや、何度やってもうまくこなせないタスクは、もう一方に任せます。たとえば、セキュリティレビューで攻撃経路を説明する内容は、どちらかのエージェントの安全ポリシーでブロックされる可能性があります。
• 利用量。 利用上限に余裕があるほうのエージェントに、タスクを多めに割り当てます。

タスクをもう一方のエージェントに移すときは、agent だけでなく、mode もそのエージェントの書き方に変える必要があります。すべてのタスクに agent と mode を明記するを参照してください。

すべてのタスクに agent と mode を明記する

2 つのエージェントを組み合わせるワークフローでは、すべてのタスクに agent と mode を明記します。そうしておけば、各タスクを誰が、どのアクセスレベルで実行するのかが、ファイルそのものからわかります。mode の書き方は 2 つのエージェントで異なり、検証では、タスクが実際に使うエージェントに合わせてチェックされます。そのため、一方の書き方をもう一方のタスクに使うと、検証に失敗します。たとえば、Codex のタスクに bypassPermissions と書くと、検証は Invalid codex mode 'bypassPermissions' というエラーを出し、Codex で書ける省略形とキーを一覧表示します。どちらのエージェントでも使える省略形は 2 つだけです。yolo はどちらでもフルアクセスを表し、auto はどちらでも、許可の判断をエージェント側の自動レビューに任せることを表します。ただし、Claude Code の auto は、まれに止まってユーザーに許可を求めることがあります。エージェントごとの書き方と、無人実行でどのレベルを選ぶかは、Claude Code での書き方と Codex での書き方を参照してください。

mode だけを書いて agent を書いていないタスクは、プロジェクトのデフォルトのエージェントに任されます。デフォルトのエージェントが異なるマシンに持っていくと、もう一方のエージェントで実行されることになります。そのうえ、どちらのエージェントでも使える省略形の yolo か auto を書いている場合を除いて、元の mode は検証にも通らなくなります。

組み合わせる前の準備

組み合わせる前に、2 つのことを確認します。プロジェクトで使えるエージェントが一方だけに制限されていないことと、2 つのエージェントが同じプロジェクトルールを読めることです。

プロジェクトは、デフォルトでは使えるエージェントを制限しません。初期化のあとでインストールしたエージェントも、設定を何も変えずに、タスクや mergeConflictAgent に書けます。使えるエージェントが制限されるのは、プロジェクト設定に availableAgents を書いている場合だけです。このフィールドは、自分またはチームが意図して設けた制限を表します。このフィールドによって使えなくなっているエージェントをワークフローが使っていると、検証でエラーになり、このフィールドがどのファイルに書かれているかが示されます。メッセージに従って、使いたいエージェントをそのファイルの availableAgents に追加してください。制限そのものが不要になった場合は、フィールドごと削除します。プロジェクト設定の availableAgents を参照してください。

もう 1 つは、2 つのエージェントが読み込むプロジェクトルールのファイルが異なることです。Codex は AGENTS.md を読みます。Claude Code は CLAUDE.md に従い、プロジェクトに CLAUDE.md がある場合は AGENTS.md を直接は読みません。両方に同じルールを守らせるには、ルールを AGENTS.md に書き、CLAUDE.md から @AGENTS.md で参照するのが一般的です。詳しくは、Claude Code のメモリのドキュメントと Codex の AGENTS.md のドキュメントを参照してください。

マージコンフリクトを誰が解決するか

分離ブランチモードでは、並列に進む複数の経路がどれもコードを変更していると、それらの変更をマージするときにコンフリクトが起きることがあります。その場合、CodeDAG は解決のためのエージェントセッションを別に起動します（合流ノードでのマージとコンフリクトを参照）。mergeConflictAgent を書いていない場合、どちらのエージェントが解決するかは、コンフリクトがどこで起きたかによって決まります。

• 合流タスクの開始前に上流の結果をマージするときは、その合流タスク自身のエージェントが、そのタスクの model を使って解決します。たとえば、ある Codex のタスクが Claude Code のタスク 1 つと Codex のタスク 1 つに依存している場合、2 つの経路のコンフリクトは Codex が解決します。
• すべてのタスクが終わり、結果を統合ブランチにマージするときは、プロジェクトのデフォルトのエージェントが解決します。使われるのは、このワークフローを投入した時点で有効だったデフォルトのエージェントです。

そのため、2 つのエージェントを組み合わせるワークフローでは、コンフリクトを解決するエージェントが場合によって異なる可能性があり、しかも、任せたいと思っていたほうになるとは限りません。すべてのマージコンフリクトを一方のエージェントに固定して任せたい場合は、ワークフローファイルのトップレベルに mergeConflictAgent を書きます。

mergeConflictAgent:    # すべてのマージコンフリクトを Codex に任せる
  agent: codex

これを書くと、どちらの場合のコンフリクトも指定したエージェントが解決します。model も mergeConflictAgent のものが使われ、タスクのものは引き継がれません。mode は書かなくてかまいません。コンフリクト解決のセッションはタスクの mode を引き継がず、mode を書いていなければ常にフルアクセスで動作するため、もともと人を待って止まることがありません。このセッションには許可リクエストに応答する手段がないので、ユーザーに許可を求めるレベルを書くと、かえって許可待ちで止まったままになります。フィールドの詳しい説明は、mergeConflictAgent を参照してください。

2 つのエージェントの利用上限は互いに影響しない

Claude Code と Codex の利用上限は、別々に計算されます。一方が上限に達しても、影響を受けるのはそのエージェントに任せたタスクだけです。上限に達したタスクは on-hold で止まり、そのあとに始まった同じエージェントのタスクも、すぐに止まります。もう一方に任せたタスクは、止まったタスクに依存していないかぎり、通常どおり実行されます。

そのため、並列に進む経路ごとにタスクを 2 つのエージェントへ振り分けておけば、一方が上限に達しても、もう一方の経路は先へ進めます。一方、2 つのエージェントが交互に担当するチェーンでは、どちらかが止まると、後ろのタスクは誰に任せたものであっても、止まったタスクが復旧するまで待つことになります。上限に達したあと、影響を受けたタスクだけを止めておき、上限がリセットされてから復旧する方法は、エージェントの利用上限またはレート制限を参照してください。同時実行数と合わせて利用量を配分する方法は、同時実行と利用上限を参照してください。

ここでいう上限は、2 つのエージェントそれぞれのアカウントに設けられた利用上限のことで、CodeDAG クレジットとは関係ありません。タスクをどちらに任せても、CodeDAG クレジットは 1 タスクにつき 1 クレジット消費されます。

関連ページ

• エージェント、モデル、権限モードを選ぶ：タスクごとのアクセスレベルの選び方と、Claude Code と Codex それぞれでの書き方。
• タスクとワークフローをレビューする：相互チェックのあとで自分の目で結果を確認し、承認するか、修正を依頼します。
• コストを抑える：ワークフローの CodeDAG クレジットとエージェントの利用量を見積もり、タスクごとにモデルを選びます。