AI 同士がレビューし合う ― 人が貼り付けていた品質チェックを自律で回す

これまで私たちは、AI が書いたコードのレビューを、人が ChatGPT に貼り付けて依頼していました。設計書やコードを AI が書き、それを人がコピーしてレビューにかけ、返ってきた指摘をまた貼り戻して直す。品質は上がりますが、人が毎回「のりしろ」として間に入る必要がありました。

いまは Codex CLI という道具を使い、Claude Code（設計と実装を担う AI）が、別の AI に自律的にレビューを任せられます。計画から、レビュー、実装までを、人の手を介さずに回せるようになりました。本稿は 2026 年 7 月時点の一次体験に基づく記録です。AI は日々進化し、モデルも入れ替わるため、ここに書くのは「今この瞬間」の話だと最初に断っておきます。

これまで ― レビューを人が手で貼り付けていた

従来のやり方はこうでした。AI が設計書やコードを書く。それを人が ChatGPT にコピー＆ペーストしてレビューを依頼する。返ってきた指摘を読み、また AI に貼り戻して直す。この往復は品質の担保に効きますが、人が毎回コピペの中継役をやる必要があり、そこが速度と手間のボトルネックでした。

加えて、当時の AI は「コードを書く」ことが得意な一方で、書いたものを深く読み返して反証するレビューは、実務に使える精度には届いていませんでした。

いま ― AI が別の AI に自律でレビューを任せる

ここで使うのが Codex CLI です。CLI（コマンドラインインターフェース）とは、画面のボタンではなく、コマンド（文字の命令）で操作する道具のこと。Codex CLI は、OpenAI が提供する、そのコマンドで動くコーディング用の AI です。

これを使うと、Claude Code が Codex を「別のレビュアー AI」として自律的に呼び出せます。人が ChatGPT に貼り付ける代わりに、AI が AI にレビューを依頼し、指摘を受け取り、直す。計画→レビュー→実装のループが、人の手を介さずに回るようになりました。

変化はもう一つあります。以前の AI は「コードを書くだけ」のエージェントでした。いまは Codex が使う GPT-5.6 Sol を ultra モードで動かすことで、実装を読んで反証するだけでなく、設計や戦略の是非まで踏み込んで考えるようになったと感じています。ここは正確に書いておくと、「Sol」はモデルの名前、「ultra」は複数のエージェントを並行して走らせて統合する実行モードの名前で、両者は別物です。Sol は、OpenAI が米国時間 2026 年 7 月 9 日（日本時間 7 月 10 日）に一般提供を開始したモデルです。

使い始めるには

専門のチームがなくても自分たちで始められる、という規模感が伝わるよう、簡単に書きます。方法は大きく2通りです。

• 一番手軽なのは、Claude Code に任せる方法です。Claude Code に Codex 用のプラグインを入れ、/codex setup と打つと、Codex が入っているかを確認し、入っていなければ導入まで案内してくれます。自分でターミナルを開く必要はなく、Windows のデスクトップ版でも同じです。
• 自分で入れる場合は、ターミナルで npm install -g @openai/codex を実行し、codex を起動して ChatGPT（OpenAI）アカウントでサインインします（コマンドは codex login）。

導入の詳しい手順は、OpenAI の公式リポジトリ（Codex CLI）にまとまっています。あとは Claude Code に「実装を読むレビューを Codex に頼んで」と伝えるだけで、AI が AI にレビューを依頼して回してくれます。

実装の前に、設計の穴を先回りで塞ぐ

効いた場面を、顧客の中身は伏せて一般化して書きます。ある新機能について、コードを書き始める前の設計の段階で、「出展者ごとに、自分のデータだけを見られる」という権限（アクセス制御）の設計を、3 ラウンドかけてレビューしました。

対象は完成したコードではなく、これから作る設計です。だからここで指摘が入るということは、実装される前に問題の芽を摘めるということです。ラウンドを重ねるごとに指摘は深くなり、収束していきました。たとえば、権限の判定条件が広すぎて、そのまま作れば他社のデータまで見えうる設計になっていた点。同意の状態を確認しないまま画像を扱う設計だった点。複数の更新が同時に走ったときにデータが競合しうる構造だった点。いずれも、放っておけばいずれ表面化しうるのに、文字列検索（grep）や型チェックでは表に出ない類のものです。SQL の意味、複数の処理が同時に走ったときの挙動、データ同士のつながりを「読んで」はじめて分かります。

大事なのは、これらが世に出る前の設計段階で見つかったことです。これは二つのゲートを通す運用で成り立っています。設計が既存の仕組みと噛み合うかを見る「設計整合」のゲートと、実際のコードやデータ構造を直接読んで反証する「実装接地」のゲート。人ひとりは、このゲートの外側で最終判断だけを担います。人ひとり＋ひとつの AI では、書いた本人が自分の見落としに気づけない。そこを別の AI が設計と実コードを読んで、早い段階で突く、という分担です。

「対話を重ねると精度が上がる」は、まだ仮説

面白いのは、エージェント同士が往復するほど、指摘が深まっていったことです。ここから「対話・思考の積み重ねが、レビューの精度に効いているのではないか」という仮説を持っています。ただしこれは私たちの一次体験に基づく仮説であって、因果が証明されたわけではありません。

公平を期して書き添えます。公開されているベンチマークでは、AI レビューの検出率はまだ限定的で、テストによっては別のモデルの方が成績が上、という結果もあります。だから私たちは「AI が何も言わない＝安全」とは考えていません。課金や権限、データを壊しうる変更では、AI レビューに加えて、自動テストと人の最終確認を必ず併用しています。AI レビューは、人やテストの代わりではなく、見落としを減らす一つの層です。

ビジネスにとっての意味 ― 品質を「仕組み」に持たせる

ここまでを経営の言葉に翻訳すると、こうなります。品質を「優秀なレビュアーがいるかどうか」という属人的なものに委ねるのではなく、「設計と実装を別々のゲートに通し、AI どうしがレビューし合う」という運用の型に持たせる。そうすれば、少人数でも、品質を構造的に担保しやすくなります。

これは私たちが内製化支援で大切にしている観点そのものです。複数の AI を役割で束ねること（AI 活用設計）、使いながら品質を担保し続ける仕組みをつくること（運用導線）。派手な自動化よりも、この地味な「型」が、少人数での品質を支えます。自社の開発で品質をどう担保するかにお悩みでしたら、お問い合わせからご相談ください。