自社では2026年9月から、Claude Code を実装役、OpenAI の Codex をレビュー役にして併用しています。
2つ並べてみると、性能の差より先に同じファイルを両方が書き換える事故と、レビューの往復が終わらない問題にぶつかりました。そのとき決めた分け方を、順に紹介します。
役割は「実装」と「レビュー」で固定する
どちらのAIも、実装とレビューの両方をこなせるのが実情です。そのぶん、毎回どちらに何をさせるかを決め直していると、 そのたびに手が止まります。
自社では、ふだんの作業から公開までを Claude Code、出来上がった分析や判断の検証を Codex、と固定しました。 書いた側と別のAIが読むので、書いた本人が気づかない前提の誤りが出てきます。
検証を頼むときの依頼文には、対象のファイルの場所と版、見てほしい論点、見なくていい範囲の3点を書くことにしました。 範囲を書かずに渡すと、レビュー役は気になったところを全部拾ってくるので、肝心の論点が埋もれます。
書き込むフォルダを分け、相手の場所は読むだけにする
最初に決めたのがこの分け方です。
| 場所 | 書き込むAI | もう片方 |
|---|---|---|
| 業務の本体（記事・設定・台帳） | Claude Code | 読むだけ |
| Codex の分析・作業記録 | Codex | 読むだけ |
| 共通の資料 | 依頼された範囲で両方 | ― |
2つのAIが同じファイルを書くと、あとでどちらの版が正しいのか分からなくなります。 レビューも相手の原文は直さず、自分の側に別のファイルで残すようにしました。
この分け方は、両方の指示書（Claude Code の CLAUDE.md と Codex の AGENTS.md）に同じ内容で書いてあります。 片方にしか書いていないと、書いていない側が知らずに越えてきます。 越えられると困る場所には、書き込みを止めるフックも足しておくと確実です。
指示書の読み方が、2つで逆になっている
併用して最初に戸惑うのが、指示書の探し方の違いです。公式ドキュメントの記述を並べてみました。
| Claude Code | Codex | |
|---|---|---|
| 指示書の名前 | CLAUDE.md（新しい版は AGENTS.md も読める） | AGENTS.md（別名は設定で足せる） |
| 探す向き | 起動したフォルダから上の階層へ | プロジェクトのルートから起動したフォルダまで下へ |
| 分量の目安 | 1ファイル200行以内が目安 | 合計32KiBで読み込みを打ち切る（既定値） |
| 両方あるとき | CLAUDE.md があれば AGENTS.md は読まない（既定） | AGENTS.md の系統だけを探す（既定） |
共通の決まりを1か所に置きたいなら、CLAUDE.md の中から AGENTS.md を読み込む書き方（@AGENTS.md）を使いましょう。公式に用意されている方法です。
同じ文章を2つの指示書に貼り分けると、片方だけ直して食い違うので、どちらかを本体にして片方から読み込む形にそろえます。
出典: How Claude remembers your project／Custom instructions with AGENTS.md（いずれも2026年10月15日に確認）
受け渡しはファイルで、毎回同じ7項目にする
2つのAIは直接やり取りしません。依頼も返答もファイルに書き、人が「読んで」と渡します。 人を挟むと遅く見えますが、何をいつ渡したかが記録に残ります。 受け取った側は、受け取った日時とファイル名を自分の作業記録に1行書く決まりです。
返答の項目は、毎回同じにしました。
- 受け取った資料と、その版（いつの時点のものか）
- 指摘ごとの採否
- 根拠と反証（相手の誤りと、自分の側の誤りの両方）
- すでに済んでいて、やり直さないもの
- 直すなら、最小の差分
- 人が決めること
- 人が決めた結果
1番目の「版」が抜けると、相手は古い状態のまま指摘してきます。 自社でも、片方が直した後のものを、もう片方が直す前の版で検証していたことがありました。
同じ日に同じ対象を触るときは、先に申告する
レビューを待っている間も、実装側の作業は止めません。止めると本来の仕事が進まないからです。 そのかわり、Codex が読んでいる最中に Claude Code の側で直したものがあれば、返答の1番目に書くことにしています。
「今日このファイルを直した」と1行あるだけで、相手は元のデータを取り直してから次に進めるはずです。 書いていないと、直す前の版を前提にした指摘がそのまま返ってきます。
逆に、Codex が同じ対象を触る予定を作業記録に書いていたら、Claude Code は着手する前にその節を読みます。 どちらが先に触るかを決めるのは人で、AI同士には決めさせません。
レビューで実際に拾えた誤り
別のAIに読ませて出てきた誤りのうち、自分では気づけなかった型を挙げます。
- 起点日の取り違え：効果を測る起点を「申し込んだ日」で数えていました。正しくは「掲載された日」です。
- 別の案件の文脈が混ざる：ある案件の運用メモに、別の案件向けの方針が2行まぎれ込んでいました。
- 同じ日付が3通りに割れる：1つの判定日が、資料によって3つの値で書かれていました。
どれも、書いた側には正しく見えている誤りです。逆に Codex の側にも誤りはあって、 すでに閉じた論点を古い資料から拾い直してくることが何度かありました。 返答の4番目（済んでいるもの）を固定したのは、これを止めるためです。
往復の回数に上限を置く
併用でいちばん時間を取られたのはここでした。指摘を受けて直し、直した結果をまた検証に出す。 これを続けたら、1つの案件だけでやり取りが40回を超えていました。
いまの決まりは1つの論点につき1往復です。判定を受けたら、直すのも確かめるのも実装した側で済ませ、 再検証は頼みません。2往復目を出すのは、判定どおりに直したら具体的な不具合が出たときと、 判定が人の決めたこととぶつかったときに限っています。
「念のため、もう一度見てもらう」を繰り返すことです。レビュー役は頼まれれば何かしら指摘を返してくるので、 終わりの合図を人が決めておかないと往復は止まりません。
依頼文の最後には「この論点の検証依頼は今回で最後です。追加の往復は要りません」と書いています。 レビューする側にも、これが最後の1回だと伝わるようにするためです。
併用が向く仕事、1つで足りる仕事
| 仕事 | 向く形 | 理由 |
|---|---|---|
| 公開物や判断の検証（数字・根拠・前提） | 併用 | 前提を共有していない読み手が要る |
| 設定や仕組みの設計 | 併用 | 抜けを別の視点で拾える |
| 定型の整形・変換 | 1つで足りる | 機械の検査で確かめられる |
| 急ぎの小さな修正 | 1つで足りる | 往復のほうが修正より長くなる |
機械で測って白黒がつくものは、レビューに回さず検査で確かめます。 AIのレビューも人の目も、使うのは測れないところだけにしています。 検査の作り方は公開前チェックを人からAIへ渡すまでに書きました。
よくある質問
契約はどちらも必要ですか
必要です。Claude Code は Claude の有料プランか API、Codex は OpenAI 側の対象プランか API の契約が要ります。 対象プランは変わることがあるので、それぞれの料金ページで確かめてください。
1つのフォルダで両方を動かしても大丈夫ですか
動きはします。ただ、同じファイルを両方が書き換えないように、書き込む場所は分けておいてください。 指示書に書いたうえで、守らせたい場所にはフックで止める仕組みを足します。
AGENTS.md と CLAUDE.md、どちらを本体にすればいいですか
両方のAIで共有する決まりは AGENTS.md に書き、Claude Code だけに伝えたいことを CLAUDE.md に書いて、 その中で AGENTS.md を読み込む形がまとめやすいです。 Codex は既定では CLAUDE.md を探しにいかず、Claude Code は CLAUDE.md があると AGENTS.md を読まないので、 読み込みの1行を入れておかないと共有の決まりが Claude Code に届きません。
どちらに実装させるのがいいですか
どちらでも回ります。決めたら毎回そのままにしておくほうが、迷う時間は確実に減りました。
レビューの指摘はそのまま採用していいですか
採否は実装した側で決めてください。指摘には古い版をもとにしたものも混ざるので、版を確かめてから直すのが安全です。
2つのAIの意見が食い違ったら、どうしますか
最後は人が決めることになります。食い違いは返答の6番目（人が決めること）に書き、同じ型の判断は1問にまとめて聞くようにしています。 小さな食い違いを1つずつ聞くと、人の側の確認作業が積み上がってしまうためです。