「Codex と Claude Code、どっちがいいですか」
よく見かける質問です。そして、比較記事もたくさんあります。
ただ、自分は、どちらか一方を選んでいません。 両方を契約して、役割を分けて使っています。
具体的には、こうです。Claude Code にコードを書かせて、Codex にレビューさせる。 指摘が出たら、それを Claude Code に戻して直させて、もう一度 Codex に見せる。
この往復が、思っていたより効きました。
シリーズの最終回として、この使い方を書きます。
この記事で分かること
- なぜ別のAIにレビューさせると効くのか
- 実際の往復の手順
- レビューを頼むときの書き方
- 指摘の扱い方
- この方法の注意点とコスト
1. なぜ、別のAIに見せるのか
1-1. 書いた本人には、粗が見えにくい
これは、人間でも同じだと思います。
自分が書いた文章は、読み返しても間違いに気づきません。 頭の中に「何を書きたかったか」があるので、書かれていない部分まで、読めてしまう。
AIにも、似たことが起きます。
コードを書いたモデルに「レビューして」と頼むと、たいてい「問題ありません」と返ってきます。当然です。 そのモデルが「これでいい」と判断して書いたものなので。
1-2. 別のモデルは、別の前提で読む
ところが、書いていないモデルに見せると、指摘が出ます。
理由は、前提を共有していないからです。「なぜこう書いたか」を知らないので、コードだけを見て判断します。すると、書いた側が当然だと思っていた部分に、疑問が向きます。
自分の場合、この形にしてから、リリース後に見つかる問題が減りました。
1-3. 人間のレビューと似た構造
これは、チーム開発でコードレビューをする理由と、ほぼ同じです。
他人が読むと、書いた人が見落としたものが見つかる。 一人で開発していると、この機会がありません。
AIを2つ使うと、それに近いことができます。
2. 実際の往復
2-1. 全体の流れ
自分がやっている手順です。
1. Claude Code に書かせる。 機能を追加する、バグを直す、といった実装です。
2. Codex に見せて、レビューさせる。 ここで指摘が出ます。
3. 指摘を Claude Code に戻して、直させる。
4. もう一度 Codex に見せる。
指摘がなくなるまで、3と4を繰り返します。 といっても、たいてい2周ほどで落ち着きます。
2-2. Codex 側でやること
レビューさせるときは、同じフォルダで Codex を起動します。
cd ~/projects/my-app
codex --sandbox read-only読み取り専用で起動するのがコツです。
レビューさせるだけなので、書き換える必要がありません。 読み取り専用にしておけば、うっかり修正させてしまうこともありません。
そして、こう頼みます。
直前の変更をレビューしてください。
修正はしなくていいので、気になった点を挙げるだけにしてください「修正しなくていい」と明示するのが大事です。これがないと、勝手に直し始めることがあります。
2-3. 変更部分だけを見せる
プロジェクト全体をレビューさせると、時間もクレジットもかかります。
直前の変更だけに絞ると効率的です。
/diff第3回で紹介したコマンドです。何が変わったかを表示させてから、そこをレビューさせます。
Git を使っているなら、こう頼むのも確実です。
git diff の内容をレビューしてください。
変更された部分だけを見て、それ以外は読まなくて大丈夫です2-4. Claude Code 側に戻す
Codex が出した指摘を、そのまま Claude Code に渡します。
別のツールでレビューしたところ、以下の指摘がありました。
それぞれについて、対応が必要かどうかを判断して、
必要なものだけ直してください。
（ここに指摘を貼る）
対応しないものについては、その理由を教えてください「必要なものだけ」と書くのが重要です。次の節で詳しく書きます。
3. レビューの頼み方
指示の仕方で、返ってくる内容が変わります。
3-1. 観点を指定する
漠然と「レビューして」と頼むと、表面的な指摘が並ぶことがあります。変数名がどうこう、といった話です。
見てほしい観点を指定すると、質が変わります。
以下の観点でレビューしてください。
- 想定外の入力で壊れないか
- エラーが起きたときに、握りつぶしていないか
- 書きかけや、消し忘れが残っていないか
- 関係のないファイルが混ざっていないか
- 同じ処理が複数箇所に重複していないか
重要度の高い順に並べて報告してください「重要度の高い順に」と付けると、優先順位がついて扱いやすくなります。
3-2. 前提を伝える
何を作っているかを知らないと、的外れな指摘になります。
これは、社内で使う小さなツールです。
外部に公開しないので、大規模なアクセスは想定していません。
その前提でレビューしてくださいこれがないと、過剰な指摘が来ることがあります。個人のツールなのに、大規模サービス向けの提案をされる、といった具合です。
3-3. 変更の意図を伝える
この変更は、フォームの入力チェックを追加したものです。
意図したとおりになっているかを中心に見てください何をやろうとした変更なのかを伝えると、「意図と実装が合っているか」という観点で見てくれます。
4. 指摘の扱い方
ここが、いちばん大事かもしれません。
4-1. 全部を直さないでください
出てきた指摘を、機械的に全部適用してはいけません。
理由は2つあります。
的外れな指摘が混ざります。 前提を知らないので、この状況では不要な提案が出てきます。
そして、直すたびに新しい問題が生まれる可能性があります。 指摘を直すために書き換えた部分に、別の問題が入り込む。
4-2. 3つに分ける
自分は、指摘を3つに分けています。
本当の問題。 → 直します。
指摘としては正しいが、この場面では不要。 → 直しません。「意図的にこうしている」と記録します。
誤解や、前提の違いによるもの。 → 直しません。
この判断は、人間がやります。 ここを機械に任せると、意味がなくなります。
4-3. 直さない理由を残す
直さないと決めたものは、理由をどこかに書いておくと、あとで役に立ちます。
同じ指摘が、次のレビューでも出てくるからです。そのたびに考え直すのは無駄です。
第4回で扱った AGENTS.md に書いておくのも一つの方法です。
# 意図的にこうしている
- この処理は毎回同期的に実行しています（順序が保証される必要があるため）。
非同期化の提案は不要です。4-4. 何周もしない
指摘がゼロになるまで繰り返す必要はありません。
自分の場合、2周ほどで止めています。 それ以上やると、細かい好みの話になっていって、クレジットだけが減ります。
「重要度の高いものが片づいたら終わり」くらいの線引きが、ちょうどいいと思います。
5. 2つの向き不向き
「どちらがいいか」ではなく、どちらが何に向くかという話です。
5-1. 使い分けの実感
自分の使い方だと、こうなっています。
書かせる側には、まとまった実装を任せています。 機能を追加する、まとめて直す、といった作業です。
レビューさせる側には、書かれたものを見せています。 実装はさせません。
これは「どちらが優れているか」ではなく、役割を固定したほうが往復しやすいからです。両方に書かせると、どちらの変更なのか分からなくなります。
5-2. 逆にすることもできます
役割は、逆でも成立します。
Codex に書かせて、Claude Code にレビューさせる。同じことです。
大事なのは、書いた側と読む側を、別のモデルにすることです。どちらをどちらに割り当てるかは、好みの問題だと思います。
5-3. 料金の考え方が違います
第1回で書いたとおり、Codex は ChatGPT のプランに含まれます。 すでに ChatGPT に課金しているなら、追加投資はありません。
両方を契約すると、当然その分の費用がかかります。 ここは正直に書いておきます。
ただ、すでに片方に課金している人が、もう片方を足すという判断なら、そこまで大きな話ではないかもしれません。
6. この方法の注意点
6-1. クレジットを消費します
往復するたびに、両方で消費します。
レビューは、コードを読み込んで、指摘を書き出す作業です。入力も出力も発生します。
節約するなら、
変更部分だけを見せる。 全体を読ませない。
2周で止める。 完璧を目指さない。
小さい変更では、往復させない。 一行直しただけのものにレビューは要りません。
6-2. 時間はかかります
当然ですが、往復するぶん時間がかかります。
急ぎの作業には向きません。時間をかけてもいい場面、たとえば公開前の確認や、他人が使うコードを書くときに向いています。
6-3. 判断は人間に残ります
指摘の取捨選択は、自動化できません。
というより、そこを自動化すると、この方法の意味がなくなります。 判断を人間が握っているから、的外れな修正を止められる。
「AIに任せて楽をする」というより、「一人で見落とすものを、機械に拾わせる」という感覚に近いです。
6-4. 万能ではありません
見落とされるものもあります。
コードだけを見て分かることには限界があります。実際に動かさないと分からない問題、画面を見ないと分からない問題は、この方法では拾えません。
テストや、実際の動作確認の代わりにはなりません。
7. 一人で開発している方へ
この方法を始めた理由を、最後に書いておきます。
一人で作っていると、レビューしてくれる人がいません。
自分で書いて、自分で確認して、自分で公開する。間違いに気づく機会が、構造的にありません。
チームなら、他人が読んでくれます。「ここ、こういう場合はどうなりますか」と聞かれて、初めて気づくことがある。その機会が、一人だとゼロです。
AIを2つ使うのは、その機会を無理やり作る方法だと思っています。
完璧ではありません。人間のレビューとは違います。それでも、ゼロよりはずっとましでした。
まとめ
- どちらか選ぶ必要はありません。 役割を分けて併用できます
- 書いた側は、自分の粗が見えにくい。 別のモデルは、別の前提で読む
- 手順は「書かせる → レビューさせる → 戻して直す → もう一度見せる」
- レビューさせる側は、読み取り専用で起動する
- 「修正しなくていい」と明示する。 勝手に直し始めるのを防ぐ
- 変更部分だけを見せる。 全体を読ませると、時間もクレジットもかかる
- レビューは観点を指定する。 漠然と頼むと表面的な指摘になる
- 前提を伝える。 ないと過剰な指摘が来る
- 指摘を全部直さない。 本当の問題／不要／誤解 の3つに分ける
- 判断は人間がやる。 ここを自動化すると意味がなくなる
- 2周ほどで止める。 完璧を目指すとクレジットが減るだけ
- テストや動作確認の代わりにはならない
シリーズのまとめ
全5回、お読みいただきありがとうございました。
第1回 料金とインストール。 Codex 単体の契約はなく、ChatGPT のプランに含まれること。
第2回 基本の使い方。 サンドボックスと承認ポリシーの2軸。
第3回 コマンド早見表。 よく使うものと、一覧の確認方法。
第4回 設定ファイル。 config.toml と AGENTS.md の役割分担。
第5回 往復させる使い方。 別のAIにレビューさせる。
全部を一度に覚える必要はありません。 最初は第1回と第2回だけで足ります。設定を詰めるのは、毎回同じオプションを打つのが面倒になってからで十分です。
そして、Claude Code のシリーズも書いています。 併用を考えている方は、そちらもあわせてどうぞ。
※本記事の情報は2026年8月時点のものです。仕様は変更されることがあるため、最新の情報は公式ドキュメントをご確認ください。
