実装はClaude・レビューはCodex｜分業で品質を高める開発術

なぜ「実装は Claude、レビューは Codex」なのか

AI がコードをレビューする際の最大の課題は「自己評価の盲点」だ。同一モデルが自分の生成したコードをセルフチェックすると、自分が選んだ設計の前提をそのまま正しいと仮定してしまいやすい。根本的なアーキテクチャの問題や、別のアプローチを取れば回避できたバグは、セルフレビューでは見つかりにくい構造になっている。

この問題を解決するのが 異なる会社・異なるアーキテクチャの AI を組み合わせる アプローチだ。Anthropic の Claude Code と OpenAI の Codex はモデルの学習データも推論の傾向も異なるため、片方が見落とした問題を相手が拾う相補的な関係を作りやすい。

Classmethod の技術ブログでは「Claude Code が見落とした認証トークンのログ露出バグを Codex が指摘した」「テストはグリーンだが実機で壊れる回帰を Codex が事前に検出した」という実践事例が報告されている。(出典: dev.classmethod.jp)

分業フローの全体像

このフローは 3 つのフェーズで構成される。

1. Claude Code が実装する — 仕様に基づいてコードを生成・編集し、ファイル操作・テスト実行・コミットまでを担う
2. Codex がクロスレビューする — Claude の出力を別系統の AI が検証し、設計の前提を問い直す外部視点でフィードバックを返す
3. 人間が判断してマージする — 両 AI のレビュー結果を統合して最終判断を下す。AI は「判断材料」であって、意思決定は人間が行う

重要なのは Codex を「権威」ではなく「同僚」として扱う点だ。Codex のレビュー内容を盲目的に取り込むのではなく、Claude と Codex の双方が指摘している問題を優先し、片方だけの指摘はコンテキストを読んで人間が判断する。(出典: dev.classmethod.jp)

セットアップ — Claude Code と Codex CLI を準備する

Claude Code のインストール

macOS / Linux / WSL では 1 行でインストールできる。

curl -fsSL https://claude.ai/install.sh | bash

Windows は WinGet にも対応している。

winget install Anthropic.ClaudeCode

Claude Pro 以上のサブスクリプションが必要。最新プランは Claude 公式 pricing を参照。(出典: code.claude.com)

Codex CLI のインストール

npm install -g @openai/codex
codex login

ChatGPT Plus / Pro / Business / Edu / Enterprise のいずれかを保有していれば追加課金なしで使える。インストール後は ChatGPT アカウントでサインインするか、API キーで認証する。(出典: developers.openai.com)

レビュー専用に読み取り専用モードで起動する

Codex をレビューのみに使う場合は --sandbox read-only オプションでファイル書き込み権限を与えないことが推奨される。

codex exec --sandbox read-only "このコードの問題点を指摘して"

このオプションにより、Codex がコードを誤って変更するリスクをゼロにした状態でレビューだけを受け取ることができる。

クロスレビューの基本フロー

手動で運用する場合の基本手順は次のとおりだ。

1. Claude Code で実装・テストを完了させ、変更ファイルを確定する
2. 変更ファイルのパスとその差分(git diff など)を取得する
3. 別のターミナルで Codex を --sandbox read-only モードで起動し、変更内容を渡す
4. Codex のレビュー結果(指摘事項・severity)を受け取る
5. Claude Code と Codex の両方が指摘している問題を最優先で修正する
6. どちらか片方のみが指摘した内容は人間がコンテキストを読んで判断する
7. 修正後に再度 Codex にレビューを依頼し「ok: true」を確認してマージする

このフローでの肝は「共通指摘 > 固有指摘」の優先度判定だ。Claude と Codex が両方指摘する問題は確度が高く、片方だけが挙げている問題はモデル固有のバイアスが混じっている可能性もある。(出典: dev.classmethod.jp)

codex-review スキルで往復を自動化する

手動で 2 つのターミナルを行き来する手間を省くために、Claude Code の Skills 機能を活用した自動化が普及している。

note の記事で紹介されている「codex-review スキル」は、.claude/skills/codex-review/SKILL.md に設定ファイルを置くだけで、Claude Code がレビュー完了後に自動で Codex を呼び出し、結果を返してもらう仕組みだ。(出典: note.com)

スキルの内部ロジックは 3 段階で構成される。

1. 規模判定 — 変更量(small / medium / large)を判定し、レビューの戦略を変える
2. Codex 読み取り専用レビューの実行 — codex exec --sandbox read-only を呼び出し JSON 形式で結果を受け取る
3. 修正→再レビューの反復 — ok: true が返るか最大 5 回繰り返す

出力の JSON スキーマには ok(合格/不合格)、severity(blocking / advisory)、カテゴリ分類が含まれ、後続の自動化フローに組み込みやすい構造になっている。

実装計画ファイル(PLANS.md)に「各フェーズ完了後に必ず codex-review を実行する」と明記しておくことで、Claude Code が自律的にこのゲートを通るよう設計できる。

tmux-sender でよりシームレスに連携する

複数のターミナルペインを tmux で管理する開発者には、tmux-sender を使った連携が有効だ。

Zenn の記事では、Claude Code のカスタム設定として以下のようなコマンドを定義し、別ペインの Codex に直接コマンドを送る方法が紹介されている。(出典: zenn.dev)

# Claude Code のカスタム設定から別 tmux ペインへコマンドを送る
tmux send-keys -t codex-pane "codex exec --sandbox read-only 'この差分をレビューして'" Enter

このアプローチでは、Claude Code の作業フロー内から直接 Codex のレビューを起動し、結果がペインに表示されるまでの流れをほぼ自動化できる。さらに MCP(Model Context Protocol)と組み合わせて Jira チケットの内容を Claude Code に読み込ませてから実装を始めると、仕様書→実装→クロスレビューの一連のフローを連続して走らせることができる。

実践事例 — Codex が拾った重大な見落とし

Classmethod の報告から、具体的な 2 事例を紹介する。

事例 1: 認証トークンのログ露出

Claude Code が実装した API 連携コードで、認証トークンがデバッグログに書き出される状態になっていた。Claude のセルフレビューでは「動作に問題なし」と評価されたが、Codex が「ログへのトークン書き出しはセキュリティリスク」と指摘し、本番リリース前に修正することができた。

事例 2: テストはパスするが実機で発生する回帰

ユニットテストはすべてグリーンだったが、Codex がモックの前提条件を精査し「実機とモックの前提が異なっており本番で壊れる」と指摘。実機検証なしに出荷するリスクを事前に防いだ。

どちらの事例も、Claude が「自分が作った設計の前提の上で」チェックしていたために見落としが発生している。Codex は「その前提条件自体が正しいか?」を問い直す外部視点として機能した点が共通している。(出典: dev.classmethod.jp)

コストと現実的な運用ポイント

このフローを実際に運用する際に押さえておきたい注意点を整理する。

費用面: Claude Pro 以上(月額 $20 前後〜)と ChatGPT Plus 以上(月額 $20 前後〜)の 2 系統のサブスクリプションが必要になる。最新の価格は Claude 公式 pricing と ChatGPT 公式 pricing を確認してほしい。

適用範囲: 全コードに適用するとコストが増大するため、まず「重要な PR」「設計変更を含むマージ」に限定して始めるのが現実的だ。Classmethod の記事でも「設計ドキュメントと PR に絞ると対効果が高い」と指摘されている。

現時点の制限: tmux-sender スキルや codex-review スキルは公式サポートの機能ではなく、コミュニティによる実装だ。Claude Code や Codex のアップデートで動作が変わる可能性があり、定期的なメンテナンスが必要になる。(出典: zenn.dev)

最終責任は人間が持つ: AI 2 系統を使っても、マージの最終判断は必ず人間が行う。「Codex が ok と言ったから」という理由だけでコードを出荷するのではなく、AI のフィードバックは材料として扱い、人間が文脈を読んで判断することが前提だ。

まとめ

「実装は Claude Code・レビューは Codex」フローのポイントをまとめると次のとおりだ。

• 同一 AI のセルフレビューは「自己評価の盲点」を構造的に抱えている
• Claude(Anthropic)と Codex(OpenAI)の異なる系統を組み合わせることで相補的なレビューが成立する
• まずは 2 ターミナル並列起動から始め、慣れたら codex-review スキルや tmux-sender で自動化する
• 「両方が指摘している問題」を最優先にし、片方だけの指摘は人間が判断する
• 重要な PR に絞って導入することでコストと効果のバランスを取りやすい

Claude Code と Codex はともに機能追加が続いており、連携フローも進化中だ。まずは手元のリポジトリで重要な PR 1 件に適用してみることが、最も低コストな第一歩になる。