[Claude Code] OpenAI Codexとのクロスレビュー運用 - 自己レビューの盲点を別系統のAIで埋める

こんにちは。サービス開発室の武田です。

Claude Codeを使い始めて、しばらくは使うAIもClaude1つだけでした。Claudeに実装させて、Claudeにレビューさせて、最後は自分でチェックして判断する。これで回ってはいました。

ただ、満足していたわけではありません。実装後に自分でテストするとエラーが出ることもありました。リリースしてからバグが見つかることも、それなりにありました。当時は自分のチェックでそれをある程度抑えながら進めていた、という状態でした。

ちょうどそのころ、世間ではマルチAIエージェントの話題が盛り上がっていました。私自身は半信半疑でした。そんなとき、OpenAIのCodexを試す機会が訪れます。Claudeが書いたプランやコードを、そのままCodexにも見せてみました。すると、Claudeの抜け漏れをちゃんと指摘してくるのです。しかもそれが、トークンがマスクされず画面に出てしまうような、マージしてしまったら笑えない類のものでした。何度か試すうちに、これは効果があると感じることが増え、計画書やPRをクロスレビューにかける頻度を増やしていきました。

今回は、私が実際にやっている「Claude×Codexのクロスレビュー運用」を、実例ベースで紹介します。すでにClaude Codeを使っている方に「もう1つAIを足すだけでこんなに違うのか」と感じてもらえたらうれしいです。セットアップ自体はすぐに終わります。

なぜ「2つ目のAI」なのか

コードレビューは、1人で見るより2人で見たほうが穴は減ります。視点の違う人に見てもらうと、自分では気付けない盲点が見つかるものです。

AIでも同じことが起きます。ただ、ここがポイントなのですが、同じモデルに自己レビューさせても盲点は盲点のまま残りがちです。Claudeが書いたコードをClaudeがレビューすると、同じ思考の癖や同じ前提を共有しているので、抜けるところはそろって抜けやすくなります。

これは感覚だけの話ではありません。LLMは外部フィードバックなしの自己修正が苦手で、しかも自分の出力を高く評価しがち、という研究もあります。

https://arxiv.org/abs/2310.01798

https://arxiv.org/abs/2410.21819

そこで、系統のまったく違うモデル、つまりAnthropicのClaudeとOpenAIのCodexに同じ対象を見せます。片方が踏み込まなかったところに、もう片方が踏み込む。人間のペアレビューをAIどうしでやるイメージですね。これが意外と違いを生みます。

セットアップ（skill-codex）

2つのAI連携と言っても、やることはほぼありません。前提は2つだけです。

• codex CLIをインストールして、ログインを済ませておく
• Claude Codeにskill-codex（非公式のサードパーティ製プラグイン）を入れる

codex CLIはOpenAI公式のコマンドです。npmでグローバルインストールします（Node.jsが前提）。

npm install -g @openai/codex
codex login

codex loginはChatGPTサブスクリプションかOpenAI APIキーで通せます。私はChatGPTログインで運用しています。

skill-codexのリポジトリはこちらです。

https://github.com/skills-directory/skill-codex

インストールはClaude Code内で次の2コマンドだけです。

/plugin marketplace add skills-directory/skill-codex
/plugin install skill-codex@skill-codex

すでに起動中のセッションに足した場合は/reload-pluginsで読み込みます。更新は/plugin update skill-codex@skill-codexです。

これを入れると、Claude Codeが会話の中からcodex execを呼び出せます。あとはClaudeに「これをCodexにもレビューさせて」というだけです。実際に走るのはこんなコマンドです。

codex exec -m gpt-5.5 \
  --config model_reasoning_effort="high" \
  --sandbox read-only \
  --skip-git-repo-check \
  "このリポジトリの設計ドキュメント（ADR）と実コードを照合し、設計の実装可能性をレビューして" 2>/dev/null

ポイントだけ補足します。

• --sandbox read-onlyはレビュー用途の指定で、少なくともローカルのファイルは書き換えさせない。ただしread-onlyがやめるのはあくまでCodexの書き込みで、レビュー対象を読ませている以上、機密値を含むコードを渡さない配慮は別途必要
• 2>/dev/nullはCodexがstderrに出す推論や進捗の出力を捨て、結論だけ受け取る指定。Claude Codeのコンテキストを無駄に食わせない工夫（エラーも一緒に消えるので、失敗時やデバッグ時は外す）
• gpt-5.5とmodel_reasoning_effort=highは、設計レビューのような重い思考向けに高めの推論強度を割り当てる指定

私は普段、自分でこのコマンドを打つことすらしていません。Claudeに「Codexにもレビューさせて」と頼むと、モデルと推論強度を確認したうえで勝手に投げて、結果を要約して返してくれます。

なお、執筆時点ではOpenAIから公式のcodex-plugin-ccも公開されています（2026年3月末リリース）。こちらはコード差分レビュー（/codex:review）やCodexへの実装委譲（/codex:rescue）など、人間がスラッシュコマンドで起動する用途に寄っています。本記事のような自然言語ベースのクロスレビュー運用なら、いまのところskill-codexのほうがよさそうです。

https://github.com/openai/codex-plugin-cc

クロスレビューの「型」

毎回やっているのは、だいたいこんな流れです。

1. Claudeが計画書や実装、PRを作る
2. Claude自身に独立レビューさせる（自分が作ったものを、いったん客観視させる）
3. 同じ対象をCodexにも並列でレビューさせる
4. Claudeが、出てきた指摘を「共通指摘」「Codex固有」「Claude固有」に仕分ける
5. Codex固有の指摘は鵜呑みにせず、Claudeが実コードや公式ドキュメントで裏取りする
6. 採否は最後に人間（私）が決める

この仕分けがキモです。両者がそろって挙げた共通指摘は、それだけ優先的に裏取りする価値が高いものです。ただし2つのAIが同じ前提のままそろって間違えることもあるので、最後の採否は自分で判断します。逆に、片方だけが挙げた固有指摘は、もう片方の盲点になっていた可能性が高い。ここから出てくる指摘が、一番大事です。

では、実際にどんな発見があったのか。例を見ていきます。

実例1：Claudeが見落とした重大バグをCodexが拾った

社内のある業務システムで、Slack通知をスレッドにまとめる機能の設計ドキュメント（ADR）をレビューしたときの話です。

まずClaudeに独立レビューさせたところ、制御フローやリトライ周りで「実装前に直すべき重大な点」が3件出てきました。これだけでも十分な収穫です。続けて、同じADRと実コードをCodexにも並列でレビューさせました。

するとCodexが、Claudeが挙げなかった指摘を2件出してきました。

• 認証トークンがマスクされず画面に出てしまう設計になっている
• リトライがSlack固有処理をバイパスしている

1つ目は、送信時に復号したトークンが、マスクされないままDTOからAPI、画面表示まで素通しになる設計だった点です。レビューで指摘され、実装前に塞げました。2つ目は、再送時に保存済みのペイロードをそのまま投げており、Slack向けの変換やレスポンス判定を一切通らない構造でした。

「Codexがそう言っている」だけでは採用しません。Codexのレビューが返ってくると、Claudeは自分から実コードを当たります。今回はトークンの格納箇所、DTO、画面表示、再送処理を1つずつ確認し、どちらも事実でした。特にトークン露出のほうは、ADRが「リスクは単純化される」と逆のことを書いていた箇所で、影響の大きい指摘でした。

この2件を踏まえて、Claudeの当初の判定「修正すればApprove」は「要再設計」に引き上がりました。一方で、ClaudeとCodexの両方が独立に挙げた共通指摘（成功・失敗判定、429リトライの矛盾、トランザクション境界の問題）は、確度の高い必須修正として扱えました。

もし自己レビューだけで進めていたら、トークンがマスクされず画面に出る設計のまま実装に進んでいたでしょう。

実例2：テストは通る、でも実機ではじめて見える回帰

次はAWS Configの設定管理を、旧方式から新方式（recordingModeなどに対応したv2）へ移行したときの話です。実装がひととおり終わったあと、Codexにもクロスレビューさせました。

ここでもCodexが、Claudeのレビューでは弱かった点を突いてきました。

比較ロジックが、既存レコーダーのrecordingModeなどを「None（未設定）であること」を暗黙の前提にしている。だがAWS ConfigのAPI仕様上、これらはOptionalでもレスポンスに返り得るフィールドだ。もし返ってくるアカウントがあると、毎回差分ありと判定されて、毎回put_configuration_recorderが走ってしまう。

注目したいのは、Codexが「Optionalだが返り得る」というAWS ConfigのAPIモデル上の事実まで踏み込んで指摘してきたことです。

とはいえ、これも机上の懸念のままでは確証になりません。「検証環境で実際にDescribeConfigurationRecordersを叩いて、何が返ってくるか見てみよう」という判断になりました。ローカルのテストは全部通っている。それでも、実機のレスポンスを見るまで確定しない種類のリスクだったわけです。

最終的には「期待値がNoneのときは比較をスキップする」ガードと、それを検証する回帰テストを足して決着しました。Codexが机上で見つけた懸念を、実機検証で確証に変える。この流れがうまくハマった例です。

他にもこんな場面で役立っています

毎回ドラマチックなバグが出るわけではありませんが、地味に役立つ場面はたくさんあります。

まずは計画段階の壁打ちです。実装前の設計をCodexに見せると、運用上の落とし穴が早く見つかります。たとえば「複数メール送信で1通だけ失敗したとき、履歴に『送信成功』と嘘を書かないか？」のような指摘です（社内のある通知系システムの監査ログ設計）。

権限周りの境界条件でも違いが出ます。IAMロールを自動管理するしくみで、ある例外（AccessDenied）を広く握ってしまう実装に対して、「その絞り込みは雑すぎる。操作ごとに限定すべき」と具体的に指摘されました。

型やDTOの不整合スキャンも便利でした。フロントが送っているフィールドをバックエンドのDTOが黙って無視している、といった複数ファイルにまたがる不整合も、Codexに当てると網羅的に洗い出せます。

Codexは「権威」ではなく「同僚」として扱う

ここまでCodexを持ち上げてきましたが、運用で一番大事にしているのはCodexを権威ではなく同僚として扱うことです。これはskill-codexのガイドにも "colleague, not an authority" と明記されています。

特に意識しているのが知識カットオフです。Codexが使うモデル単体の知識には学習時点のカットオフがあり、それより新しいAWSやClaudeのアップデートは把握しきれていないことがあります。ただ、だからといって「新しい話題だからCodexの言うことは怪しい」と決めつけるのも危険です。

実際、こんなことがありました。ある調べものをさせていたとき、Codexが「その情報はすでに公開済みのはずだ」とURL付きで指摘してきました。そのURLが学習時点より後に公開されたものだったので、Claudeは最初「カットオフより新しいのだから、捏造だろう」と疑いました。ところが念のため裏取りしてみると、URLは実在し、Codexのほうが正しかったのです。skill-codex経由のCodexは標準ではWeb検索を持たないので、公開先のURL命名規則から組み立てて当てたものと考えられます。外したのは「新しいから怪しい」という、Claudeの先入観でした。

もちろん逆に、Codexが古い前提のまま誤った指摘をしてくることもあります。だからこそ、思い込みでどちらかに決めつけず、新しいトピックほど実機や公式ドキュメントを当たって裏取りすることが重要になります。

もう一例、もっと頭をひねる場面の話です。趣味で取り組んでいた、計算量の重い数学パズルがあります。Claudeが最初に書いたアルゴリズムはO(n²)で、扱いたい規模（n=10⁷）では答えを出すのに理論上21日かかる状態でした。そこで私が「Codexにも相談してみよう」と提案します。Claudeが自分の導出を整理して、Codex（gpt-5.5、xhigh）に相談しました。するとCodexが「この問題にはある対称性があるので、本来必要に見えた探索そのものが消える」という構造的な突破口を出してきたのです。

ところがClaudeは以前、まさにその対称性を「成り立たない」と疑っていた経緯がありました。そこでClaudeは鵜呑みにせず、既知の検証値（独立した2つの実装が一致している答え）と突き合わせて確かめました。結果、Codexのほうが正しかったのです。書き直したアルゴリズムはO(n log n)程度に落ち、同じ計算が2.5秒で終わるようになりました。最終的な答えも、別実装による検証値と完全に一致しています。

ここで言いたいのは「Codexはすごい」ではありません。どちらのAIも間違え得るので、片方の指摘を鵜呑みにはしません。テスト・実機・ドキュメントでの裏取りまで、Claudeが自律的に進めてくれます。最後はその材料を見て、人間が判断する。クロスレビューは「2つのAIに採点してもらう仕組み」ではなく、「2つの視点を材料にして、人間が判断の質を上げる仕組み」だととらえています。

効果と、正直なところのコスト

よいことばかり書いても怪しいので、正直なところも書いておきます。まず効果から。

• 見落としが減る。特にClaude自身の思考の癖に起因する盲点を拾える
• 共通指摘と固有指摘の仕分けで、修正の優先度に確度の根拠が付く
• PRやADRに「Claude + Codexでクロスレビュー済み」と透明性を残せる。レビュアーへの説明にもなる

一方でコストもあります。

• 2つ目のAIの利用料がかかる。当然、無料ではない
• すべてにかけるのは過剰。重要な設計ドキュメントと影響範囲の大きいPRに絞る
• レビュー時間は増えるが、Codexは並列で投げて待つだけで、体感の増加は小さい

費用対効果でいえば、実例1の「トークン露出を実装前に止められた」1件だけでも、コストを払う価値はありました。

まとめ：これから始める人へ

仕様駆動でAIが実装を担う時代になって、人間の仕事は「書く」より「読む・判断する」側へ移っています。そのとき、判断材料を1つのAIだけに依存しないというのは、思った以上に大きいです。

すでにClaude Codeを使っているなら、始めるのは簡単です。

1. codex CLIを入れてログインする
2. Claude Codeにskill-codexを入れる
3. 重要な設計ドキュメントかPRを1本、「これCodexにもレビューさせて」とお願いしてみる

そして返ってきた指摘を、Claudeが共通と固有で仕分けてくれます。Claudeが見落としていた1件が固有指摘として出てきた瞬間、たぶん「あ、これは続けよう」となるはずです。私はそうでした。