Claudeでコードを書いてもらうと、かなりの品質で仕上がってきます。
ただ、同じClaudeに「レビューして」と何度頼んでも、見落としをゼロにはできません。
先日、Redditの r/ClaudeAI で、この課題への興味深いアプローチが話題になっていました。
投稿者は役割を分けています。
書くのはClaude、レビューするのはOpenAIのCodex、という分担です。
本記事では、その議論の内容を整理してお伝えします。
なぜ同じモデル内のレビューには天井があるのか
スレッドで Fit_Ad_8069 というユーザーが鋭い指摘をしていました。
自分で書いたコードを自分でレビューする行為には、構造的な限界があるそうです。
例えるなら、自分で書いたメールを自分で校正する作業に似ています。
「こう書いたはず」という記憶が頭にあります。
その記憶が、実際に書かれている文面を冷静に読み直す邪魔をするわけです。
LLMでも同じことが起きます。
差分を選んだ時の重みの振り方が、レビュー時にもほぼそのまま再現されるからです。
結果として、自分の選択を正当化する方向に傾きやすくなります。
ここに、別モデルを連れてくる意味があります。
異なる出自のCodexが、仕様と差分だけを冷たい目で受け取ります。
そしてClaudeが「問題なし」と片付けた部分にも疑問を投げかけてくれるのです。
投稿者のワークフロー
99xAgency という投稿者は、次のような段取りで作業を回しているそうです。
まず、Codex CLIを tmux セッションで常駐させます。
ClaudeはVS Code拡張から主導権を握り、コードを書きます。
そして、プルリクエストを作成するところまで進めます。
次にClaudeはシェル経由でCodexに声をかけます。
その後、自分は一旦スリープに入るわけです。
tmuxを挟むのには理由があります。
Codexの思考過程がユーザー側から丸見えになるからです。
ファイルアクセス許可のような、人間が判断すべき場面にも介入できます。
Codexがレビューを終えると、PRにインラインコメントが書き込まれます。
設定された時間になると、Claudeは目を覚まします。
そして、Codexのコメントを一件ずつ吟味していきます。
妥当なものだけを、コードに反映させる流れです。
「Claudeが書く→Codexが指摘する→Claudeが検証して直す」というサイクルを回します。
これを、双方が合意する状態まで繰り返すわけです。
投稿者はさらに工夫を加えていました。
pr-pack.md というファイルに、関連ソースや設計判断の背景をまとめておくそうです。
Codexはこの情報を踏まえて、問題点だけを洗い出します。
Claudeは返ってきた指摘を鵜呑みにしません。
一件ずつ検証してから、修正計画に落としていくのです。
PR説明文を書くこと自体に効能がある
もうひとつ、Fit_Ad_8069 の観察で面白かった点があります。
PR説明文を書くこと、それ自体に効能があるという指摘です。
Codexに向けて「自分は何をしたのか」を言語化する段階で、バグが浮かび上がってきます。
全体のうち、三分の一ほどがこの時点で表面化するそうです。
他人に伝えようとする行為には力があります。
自分の選択を一歩引いて見直す機会を、自動的に作ってくれるからです。
これは人間の開発現場でもよく言われます。
しかし、LLMにも同じ効果が働くというのは、考えてみれば納得できる話でしょう。
レビューを依頼する前の段階で、書き手自身が気づける問題がかなりある、ということになります。
落とし穴をいくつか把握しておく
万能ではありません。
同じスレッドで、いくつかのリスクも共有されていました。
ClaudeとCodexは別モデルです。
とはいえ、学習データに重なりがあれば、同じ種類のバグを揃って見逃します。
特に並行処理のプリミティブやタイムゾーン計算で、両者とも自信満々に間違えることがあるそうです。
この領域だけは、最終確認を人間がやるほうが安全でしょう。
もうひとつは、Codexの幻覚問題です。
実は正しく動いているテストを「修正が必要」と誤指摘するケースがあります。
起床直後のClaudeがそれを素直に受け入れると、どうなるでしょうか。
書き換えてしまい、動いていたコードを壊すわけです。
対策は単純です。
Codexの指摘で修正したあとに、必ずテストを再実行させるだけで済みます。
makft 氏の観察も示唆に富んでいました。
Opusが書いたコードをOpus自身にレビューさせると、ほぼ常に「素晴らしい出来です」と返ってきます。
ところが、SonnetやCodexに見せると本物の指摘が返ってくるそうです。
自分に甘い、という意味では人間とよく似ています。
公式プラグインと自作ブリッジの使い分け
実は、Claude Code用の公式Codexプラグインも存在します（github.com/openai/codex-plugin-cc）。
投稿者は、自作のtmuxブリッジと公式プラグインの住み分けを整理していました。
公式プラグインは、ローカルの作業ツリーをその場でレビューします。
結果はClaudeの中に戻ってくる仕組みです。
コミット前の素早い確認には、こちらが手軽で向いています。
一方、tmuxブリッジはCodexをセッション内で走らせます。
そして、レビュー結果をGitHubのPRコメントとして残します。
議論の履歴がPRに蓄積されるわけです。
正式なレビュープロセスに組み込みたい場面に合うでしょう。
両者は競合ではありません。
用途で使い分けるもの、という整理でした。
議論の中では、他のツールにも言及がありました。
- repowire：複数モデルの間で会話させ、相互レビューを行うためのプロジェクト
- Conductor：コーディング関連の作業環境として紹介
- Cursor：複数モデルを同じIDE内で使えるツールとして話題に登場
いずれも、同じ課題に対する異なる方向からのアプローチと言えそうです。
モデルごとの得手不得手
コメント欄では、実体験ベースの使い分けが色々と出ていました。
Claudeは長い文脈を保ちながら作業するタスクに強い、という声が多いです。
フロントエンドの創造的な場面でも評価されていました。
Codexはトラブルシューティングで優位だと評価する人が目立ちます。
バックエンドの作業や、大規模データの取り回しでも評価が高めです。
kaancata 氏は、Codexのほうが大規模データセットを明らかにうまく扱うと感じているそうです。
ただ、florinandrei 氏が茶化していたのも一理あります。
「それ、シャルドネよりカベルネが好きって話じゃない？」というコメントです。
最終的には、各自の作業内容と好みに左右される部分が大きそうです。
コストという現実
このワークフローには、現実的な課題もあります。
ClaudeとCodexの両方に課金する構成です。
そのため、AI関連の支出が単純に倍になります。
投稿者本人も「おかげで月額がまた跳ね上がった」と苦笑していました。
stamoujr 氏も同じ感想でした。
「この方法に辿り着いたから、両方のサブスクリプションを維持する覚悟を決めた」と書いています。
品質と支出のバランスをどう取るかは、使う側の状況次第でしょう。
まとめ
Redditのこの議論から、ひとつの方向性が見えてきます。
LLMを使う開発における「役割分担」の力です。
同じモデルに書かせたコードを、同じモデルに点検させます。
それだけでは、構造的な盲点が残ってしまいます。
別モデルを挟むことで、冷たい第三者の視点を擬似的に持ち込めるわけです。
ただし、両モデル共通の弱点はやはり人間が見るべきです。
そして、Codexの誤指摘をClaudeが機械的に実装してしまう罠にも気をつける必要があります。
テストを毎回回し直す、という単純な習慣が効きます。
この種のリスクを、かなり下げてくれるからです。
