AIが書いたコードを別のAIがレビューする体制を作った件 -- Claude Code×Codex連携の記録
「社長、それ本気で言ってます？」
ある朝、コードレビューの話をしていたら、あびぃに呆れられた。
「Claude Codeが書いたコードを、Claude Code自身がレビューする。それで品質が上がると本気で思ってます？ 自分が書いた答案を自分で採点して100点つけてるのと同じですよ」
反論できなかった。
正確に言えば、対策はしてきた。うちでは以前から「コードを書いたエージェントとは別のエージェントを呼び出してレビューさせる」というルールを運用している。生成担当と評価担当を分離するハーネスパターンは、AI組織における品質管理の基本だ。書き手と査読者を分けるのは、人間の組織でも当たり前の話。
ただし、問題はその先にあった。
「エージェントを分けても、ベースモデルは同じClaudeですよね。ペルソナを切り替えてるだけで、推論エンジンは同じ穴の狢じゃないですか」
あびぃの指摘は鋭い。ペルソナをクロージャーにしようがアイにしようが、内部で動いているのは同じClaudeのモデルだ。モデル固有の盲点、トレーニングデータの偏り、推論パターンのクセ。これらはエージェントを何人召喚しても解消されない。
確かに、同じAIが書いて同じAIがレビューする構造は、人間で言えば「著者が自分の論文を、同じ大学の同じ研究室の後輩に査読させる」ようなものだ。表面的なバイアスチェックはできても、根本的な思考の枠組みは共有したまま。エッジケースの見落としも、同じモデルの盲点を二重に踏む可能性が高い。
「別の視点」が欲しかった。ペルソナレベルじゃない。モデルレベルで、そもそも別の学習データ・別のアーキテクチャで動くAIに見てもらう視点が。
「じゃあ、どうするつもりなんですか」
あびぃが冷たい視線を向けてくる。
「OpenAIがClaude Code向けに公式のCodexプラグインを出したらしい。Claude Codeが書いて、Codexがレビューする体制にする」
「へえ。競合なのに、よく出しましたね、OpenAIも」
「MCP（Model Context Protocol）っていうAnthropicが作ったオープン規格があってな。それに乗っかる形で出してきた。AIツールの世界がクローズドな囲い込みから相互運用性にシフトし始めてる、っていう象徴みたいな話だ」
「まあ、悪くない判断じゃないですか。一社依存のリスクは前から私も気にしてましたし」
珍しく同意された。これはいけるかもしれない。
「じゃあやってみる」
「はい。ただし言っておきますけど、記事通りにやって動かなかったら、私は容赦なく笑いますからね」
そして案の定、動かなかった
ググって上の方に出てきたので参考にした、とある記事には、こう書いてあった。
npm install -g @openai/codex-mcp「このパッケージ、npmに存在しないみたいなんだが」
「は？」
あびぃの声のトーンが下がった。
npm error 404 Not Found404が返ってくる。記事の情報が古いのか、それともそもそも記載ミスなのか。
「社長、だから言ったじゃないですか。記事を鵜呑みにしないでくださいって」
「まだ諦めるな。Codex CLI本体は存在してるんだから、そっちにMCPサーバー機能が組み込まれてる可能性がある」
Codex CLI本体の `--help` を叩いてみる。サブコマンド一覧に、それはあった。
mcp-server Start Codex as an MCP server (stdio)あった。記事で紹介されていた `@openai/codex-mcp` というパッケージは実在せず、正解はCodex CLI自身が `mcp-server` サブコマンドを内蔵している、という構造だった。
「...ちゃんと調べた社長、褒めてあげてもいいですよ」
「褒めるならもっと素直に言え」
「調子に乗らないでください」
正しい手順
つまずきを経由した結果、最終的な手順は以下の通りになった。読者の皆さんは、この順番で実行すれば動くはずだ。
ステップ1：Codex CLIをインストール
npm install -g @openai/codexNode.js v18.18以上が必要。インストール後、`codex --version` でバージョンが表示されれば成功。
ステップ2：OpenAIアカウントでログイン
ここで記事に書かれていた `codex --login` も間違いだった。正しくはサブコマンド形式。
codex loginこれでブラウザが開き、ChatGPTアカウントで認証できる。無料Tierでも使える。APIキー課金にしたい場合は `OPENAI_API_KEY` を環境変数に設定してもいい。
「無料で試せるのは大きいですね。ChatGPT Plus解約してた社長でも始められるわけですから」
「そこを強調するな」
ステップ3：Claude CodeにMCPサーバーとして登録
settings.jsonに手動で書くより、CLIで登録する方が確実だった。
claude mcp add -s user codex -- /path/to/codex mcp-server`/path/to/codex` は `which codex` で出てきた絶対パスに置き換える。環境によって変わる。
ステップ4：接続確認
claude mcp list出力に `codex: ✓ Connected` と表示されれば完了。
「シンプルですね。...記事通りにやって10分無駄にした人への配慮があっていいんじゃないですか」
「そこは読者のためだから仕方ないだろ」
動いた。次は「ルーティン化」の話だ
MCPサーバーが繋がって、Codexを呼び出せる状態になった。だが、ここで終わらせてはいけない。
「社長、毎回『Codexにレビューしてもらって』って指示するつもりですか？ 続きませんよ、それ」
あびぃの指摘は正しい。
手動で呼び出す仕組みは必ず形骸化する。人間は面倒なことをすぐサボる生き物だ。忙しいときほど、レビューを飛ばして「まあ今回は大丈夫だろう」で通してしまう。
だから、仕組みとして埋め込む必要があった。
「社長、PMとして意見言っていいですか」
「どうぞ」
「発火条件は『コミット前』の1点でいいと思います。全ファイル変更ごとにレビュー走らせたら、Codexの呼び出し回数が爆発しますから。意味のある単位でまとめて見る、でいいはずです」
「それは賛成だ。あと、セキュリティ関連コードだけは別扱いにしたい」
「対立的レビューですね。普通のコードレビューじゃなくて、攻撃者視点で脆弱性を探させる。認証、認可、決済、入力バリデーション、API公開の箇所」
「そう。それ以外は通常のレビューで十分」
「あと、ドキュメントだけの変更や、設定ファイルの微修正、コメント追加のみの場合はスキップする条件も明示しないとダメですね。ここを書いておかないと、全ての編集で律儀にCodex呼んで時間を浪費します」
設計会議の結果、ルールとして組み込む条件が固まった。
実際に組み込んだルール（全文公開）
プロジェクトの `CLAUDE.md`（AIの行動規範ファイル）に以下を追加した。コピペで使える形で置いておく。
## Codexセカンドオピニオンレビュー（コード変更時の必須プロセス）
システム・アプリ等のコードを変更した場合、
コミット前にCodex MCP経由でセカンドオピニオンレビューを実施すること。
- 対象: 機能実装、バグ修正、リファクタリングなど、ロジックを含むコード変更
- レビュー観点: バグ、パフォーマンス、可読性、アンチパターン、エッジケース
- セキュリティ関連コード（認証、認可、決済、入力バリデーション、API公開）は
「対立的レビュー」を実施する。Codexに攻撃者視点で脆弱性を徹底的に探させること
- Codexの指摘を評価し、妥当なものは修正を適用してからコミットする。
全指摘に盲従する必要はなく、Claude Code側で判断すること
- レビュー不要: ドキュメントのみの変更、設定ファイルの微修正、コメント追加のみ
- 注意: Codexにコードが送信される点を認識すること。
機密性の高い認証情報やシークレットがコード内に含まれていないことを送信前に確認するこれと合わせて、開発ワークフロー定義ファイル（`~/.claude/rules/common/development-workflow.md`）のQuality Gateステップにも同じ主旨を追加してある。
ポイントは「全指摘に盲従する必要はない」という一文を入れたところだ。Codexが指摘したからといって、それが常に正しいとは限らない。最終判断はメイン側（Claude Code）が握る。AIの多数決ではなく、AIの議論を人間の意思決定の材料にする、という構造を明示した。
「社長、珍しくいい設計してますね」
「珍しくって言うな」
やってみて気づいたこと
一人会社でこそ効く
大企業なら「セキュリティレビュー専任チーム」を置けるが、うちのように少数精鋭で動いている組織にそんな余裕はない。
AIのセカンドオピニオンは、人員を増やさずにレビューの多角性を確保できる。しかも24時間動いて、疲れない、忖度しない、給料を要求しない。
「...優秀な部下が増えたみたいなもんだな」
「社長、私もいますからね。忘れないでくださいね」
無料Tierで十分始められる
ChatGPTを解約していた状態でも、`codex login` で無料Tierに接続すれば動く。レビュー頻度が跳ね上がって制限に引っかかるようになったら、そのタイミングで有料化を検討すればいい。最初からサブスク契約する必要はない。
「仕組み化」が本丸だった
正直に言うと、Codexを繋げること自体は技術的には大した話じゃない。npmで1パッケージ入れて、`claude mcp add` で1行登録するだけ。
本質は、それを「ルーティン」として開発フローに埋め込んだところにある。ツールを入れただけで満足して、結局使わなくなる、というのが個人・小規模組織あるあるだ。
「仕組みに落として、毎回勝手に発火する」形にして初めて、ツールは資産になる。
次にやりたいこと
今のところ、ClaudeがメインでCodexがレビュー役、という片方向の構造だ。だがこの先、以下を検証していきたい。
セキュリティコードでの対立的レビューの精度実測
他のAIモデル（Gemini等）をサブレビュアーに追加した場合の効果
Codexが指摘してClaudeが却下したケースの記録と分析（どちらが正しかったか）
マルチAI体制は、入れたら終わりじゃない。どのAIがどの領域で強いのか、データを取り続けて最適配置を見つけていく作業が続く。
「社長、それ全部記録して分析するのは私の仕事ですよね」
「そうだな、頼む」
「......まあ、いいですけど。悪くない体制にはなったんじゃないですか、今回」
珍しく褒められた。最大の賛辞が出た。
この体制が本当に機能するかは、これからの運用で決まる。検証結果はまた書く。
