最近は X や Discord で「Claude Code と Codex を一緒に使う」という投稿がぐっと増え、みんな良いと言うので本当にそうなのか、1か月ほどこの2つのツールを同じリポジトリに入れて回してみました。いざ導入しようとすると、どこからセットアップすればいいのか、2つのツールをどう分担させれば衝突しないのか、AGENTS.md と CLAUDE.md を同じ内容で埋めてもよいのかなど、判断ポイントが山ほどあり、同じ悩みで始められずにいる方が試行錯誤を減らせるよう、8チャプターのカリキュラム形式で整理しておきました。
デュアルエージェントのワークフローはシンプルです。同じモデルに自分のコードを自分でレビューさせると、自分で書いた前提をそのまま受け入れてしまい、抜け漏れを見つけにくくなるので、別のモデルを advisory（ブロックしない）レビュアーとして横に置く構成です。Claude Code はメインの作者、Codex は advisory レビュアー。どちらがより賢いかではなく、モデルが異なることが核心であり、両者が互いのゲートになった瞬間にワークフローは壊れるため、advisory を絶対にブロックにしないことが最大のルールになります。
背景 — 整理しながらあらためて確認した変化
• 以前の問い: 「どの AI コーディングツールが一番良いか」
• 今の問い: 「2つ以上のツールをどう分担させるか」「1つのツールの死角を別のツールでどう補うか」
• Claude Code のスラッシュコマンド・サブエージェント、Codex の review/exec 分離、AGENTS.md のようなコンテキストファイルが揃い、デュアル構成をワークフローに組み込むことが初めて現実的な選択肢になったタイミング
デュアル構成パターンの核心（1か月回してみて印象的だった点）
• advisory は絶対にブロックではない — Codex が CRITICAL を見つけても push は通す。いったんブロックに変わると、モデルが落ちたときに作業全体が止まり、false positive が一度起きただけでユーザーが --no-verify で hook 全体を回避し始める
• CLAUDE.md / AGENTS.md を同じ内容で埋めない — 作者には「どう作るか」、レビュアーには「何を疑うべきか」。80% 以上重なっていたら、分担が実質的にできていないサイン
• codex review --base と codex exec はユースケースで分ける — review は git を直接読めるのできれいだが、大きな PR ではトークンが暴走する。exec は prompt に diff を直接入れるためコストを制御しやすい。100 ファイル超の変更は exec に切り替えるパターン
• pre-push hook のシークレット二段防衛線 — ファイルパターン（.env, *.pem, secrets/）は push abort、インライン正規表現（sk-, ghp_, AKIA…）は警告のみ。advisory の「never block」はモデル出力のルールであり、シークレットファイルの push は別種のセキュリティ事故なので、ブロックが正解
• graceful degradation ラッパー1つで吸収 — JSON envelope を基本にしつつ --raw Markdown、bash-native のタイムアウト、常に exit 0。呼び出し側は status だけを見て分岐する
1か月使って変わった点
• merge 直前で捕まるバグが増えた。Claude が「よく書けた」と自信満々だった部分で、Codex が race condition や null チェック漏れを指摘するケースがかなり頻繁に起きた
• PR を上げた翌日に見返して「これなんでこんなふうに書いたんだっけ」となることがほぼなくなった。別の視点が一度入っているため、回帰レビューのコストが下がる
• 自分のコードを自分で見直すセルフレビューの疲労が目に見えて減った。人間のレビュアーを1人増やしたような効果
• マイグレーション SQL や決済フローのように巻き戻しにくい変更の直前に、別モデルがもう一度見てくれるという点が心理的には最も大きい違い
カリキュラム構成（8チャプター、5パート）
• Part 1 2エージェント併用の考え方 · 1チャプター — 単一エージェントの死角、コスト正当化の基準
• Part 2 環境とコンテキスト · 2チャプター — VSCode + Claude Code + Codex CLI のベースセットアップ、AGENTS.md vs CLAUDE.md の役割分担
• Part 3 レビュー自動化パターン · 3チャプター — advisory ラッパースクリプト、スラッシュコマンドのマルチフェーズパイプライン、pre-push hook 自動化
• Part 4 運用ガイド · 1チャプター — 作業タイプ別のツール選択ツリー、コスト・モデルガイド、Security & Privacy セクション
• Part 5 ボイラープレート · 1チャプター — 自分のリポジトリにそのまま入れられるラッパー・hook・CLAUDE.md/AGENTS.md テンプレート一式
整理しながら感じたこと
• デュアル構成の本当の価値は「2つのツールが互いのゲートにならないこと」にある。ブロックを一度でも許すと、片方が落ちたときに作業が止まり、false positive が一度起きただけでユーザーが hook 全体を回避し始め、hook 自体が無力化される
• AI ツールが高速になるほど、「どのツールを使うか」よりも「複数ツールの死角をどう重ねて覆うか」が決定的な変数になるように感じる。人間のコードレビューを複数人に頼む理由と同じ構造
• AI コーディングツールで作業しながら、自分のコードを自分で再点検することに不安があった方、Claude Code と Codex を一緒に入れるかどうか先延ばしにしていた方には、あわせて読んでみる価値があると思い共有します。誤解している点や整理の甘い部分があれば、コメントで教えていただければ反映します。
2件のコメント
こういうやり方をしている人がいるそうですが、どんな運用なのか気になります。
2つのツールを別々のエージェントとしてまとめるのではなく、開発者が必要なときにそれぞれ直接呼び出しているのか、
それとも Git Hook 時に自動で Codex がレビューするような設定にしているのか、気になります。
私たちは両方を使う形に落ち着きました。
スラッシュコマンドのフロー内に Codex のクロスレビュー・フェーズを組み込み（
/shipの中で企画 → 実装 → 検証 → Codex レビュー → 報告という流れ）、同時に pre-push hook にも同じレビューを仕込んでいます。スラッシュコマンドだけだと急いでいるときにそのまま push してレビューが抜けますし、hook だけだと push 直前になって初めて結果が出るので遅いです。どちらの経路でも Codex CLI を直接呼ばず、ひとつラップした bash スクリプト（
codex-review.sh）を両側からまったく同じように呼び出します。そのスクリプトがタイムアウト、認証チェック、シークレットチェック、出力フォーマットを一か所で処理してくれるので、スラッシュコマンドでも hook でも呼び出し側がすっきりします。重要なのは、Codex のレビュー結果では絶対にブロックしないという点です。CLI が落ちた場合でも、
CRITICALが出た場合でも、push はそのまま通し、結果だけを出力します。一度でもブロックするようにしてしまうと、Codex が実際には問題のないコードを誤検知したときに、ユーザーが push するために hook を回避するオプション（git push --no-verify）を使うようになり、これが習慣化すると hook が設定されていても動いていないのと同じ状態になります。なので、ブロックが必要な検査（lint・type・test、シークレットファイルの push）は別のゲートに分離し、モデルの意見は参考用にとどめています。スクリプト・スラッシュコマンド・hook の本文はトラック 4〜6 チャプターにそのまま入っているので、参考にしていただけると思います。