Claude と Codex の二刀流レビュー ―― 別系統AIで盲点を炙り出す
目次
同じ盲点を共有しないために。系統の違うAIを突き合わせる
1人で開発していて、いちばん心もとないのは品質の担保です。書いた本人が見直すと、書いたときと同じ思い込みのまま読んでしまう。では AI に書かせて AI に見直させればいいかというと、同じ系統の AI どうしでは、同じ盲点をそろってすり抜けてしまう。
そこで効いたのが、系統の違う2つの AI ―― Claude（Anthropic）と Codex（OpenAI）―― を突き合わせる「二刀流」のレビューでした。
なぜ別系統なのか
同じ訓練の流れをくむ AI は、得意なことも、苦手なことも似ています。だから、片方が見落とす欠陥は、もう片方も見落としやすい。同系統どうしのレビューは、安心感のわりに穴がそろう。
モデルの家系が違うと、その穴がずれます。一方が素通りした問題に、もう一方が引っかかる。実際の回し方はこうです ―― まず Claude 側で、観点を分けた5体のレビュー役を並行で走らせます。pr-review-toolkit という公開プラグインの構成で、それぞれ見る角度が違います。
- code-reviewer：コードの誤りや規約違反
- silent-failure-hunter：握りつぶされた例外、黙って失敗する処理
- comment-analyzer：コメントと実装の食い違い
- pr-test-analyzer：テストの抜け・カバレッジ
- type-design-analyzer：型の設計
そのうえで、同じ変更を、別系統の Codex にもかけます。
一度、こんなことがありました。データベースの関数から引数を一つ削ったとき、アプリ側の呼び出しはすべて直したのに、データベースの振る舞いを SQL で確かめるテストのほうに、古い呼び出しが一箇所だけ残っていた。観点の違うこの5体が全員で見落とし、別系統の Codex だけが、それを拾いました。観点を増やしても同系統では揃って見落とすところを、家系の違いがすくい上げる ―― 二刀流のいちばん分かりやすい効きどころです。
何を機械に、何を AI に
もっとも、レビューのすべてを AI に任せるわけではありません。線引きがあります。
答えが一意に決まることは、機械に任せる。ここを支えているのが、決定論的な ―― 同じ入力なら必ず同じ結果になる ―― テストと自動チェックの一群です。
- GitHub Actions：PR を出すたびに、決めたチェックが自動で走る。lint、型チェック、ビルド、各種テスト。緑が揃わないとマージできない、という関所です。
- pgTAP：データベースの関数や権限を、SQL で直接テストする。たとえば「この関数は、ログイン中の一般顧客の権限では実行できないこと」をテストとして固定しておく。権限がうっかり開いてしまう変更が入れば、CI が赤くなって止まる。
- vitest：画面やロジックの単体テスト。スコアの計算や表示が、決めたとおりに動くかを確かめる。
これらは「事実」を固定する仕掛けです。人の気分にも、AI の調子にも左右されない。だからこそ、さきほどの「古い呼び出しが残っていた」類のミスは、見落とせば CI が必ず赤くなる ―― 別系統 AI の指摘と、機械的な関所が、二重の網になります。
一方で、設計の良し悪し、見落とした副作用、命名や責務の置きかたといった「意味」の判断は、AI（と、最後は人間）に任せる。ここを取り違えて、「決まった語が含まれているか」のような代理指標で文章や設計の質を測ろうとすると、たいてい外します。形式と事実は機械、意味は人と AI ―― この切り分けが、二刀流の土台です。
実装より先に「完了」を決める
決定論的な網を活かすコツは、順番にあります。コードを一行でも書く前に、「完了とは何か」を機械が判定できる形で先に決めておく。
たとえば ――「この古い書き方が、全ファイルから消えていること（検索して0件）」「この条件が SQL で必ず真であること」「このテストが通ること（終了コード0）」。完了の定義を数値やコマンドで先に書いておくと、実装の途中で基準がなしくずしに緩むのを防げます。レビューする側も、「クライテリア通りか」を確かめるだけで済む。
画面とサーバーのやり取りの形や、データベースの列の定義といった「契約」に関わるところは、もう一段きびしくします。着手前に“現物”を直接確認し、それを唯一の正として仕様に書き出してから、実装に入る。推測で書いた仕様をそのまま実装に渡すと、ズレが下流まで伝播してしまうからです。地味ですが、これが手戻りをいちばん減らしました。
実際は、一度で終わらない
正直に書くと、レビューは一周では終わりません。
仕様や設計を固める種類の変更だと、指摘がゼロに収束するまで十数ラウンド回ることも珍しくない。一周で終わらないのは、片方の修正が次の論点を生むからです。直す → 別の綻びが見える → また直す。地道な往復ですが、これを厭わず回せるからこそ、1人でもチーム並みの目を変更にあてられます。
（なぜ、それだけのレビューを罪悪感なく回せるのか ―― という話は、開発側の AI のコスト構造に関わるので、追って別の記事で。）
人ではなく、系統の差で炙り出す
二刀流が効くのは、欠陥を「誰が優れている・劣っている」ではなく「系統の差」で炙り出すからです。そこに、決定論的なテストと CI という機械の関所が重なる。書いた本人の思い込みからも、単一モデルの癖からも半歩離れたところで、欠陥が見つかり、固定される。1人開発の品質を、人手を増やさずに底上げする現実的な手立てが、ここにありました。
この作り方を1年かけてどう組み立てたかは マイクロSaaSの技術スタックは、1年でこう変わった に、AI に実環境を触らせる土台については MCP は何を変えたか に書きました。開発まわりの他の記事は dev カテゴリ にまとめています。
そうして二重三重に目を通しながら作っているマイクロSaaS が、PentaTrail です。外から見える攻撃面を AI で継続的に把握する、CTEM のサービスです。もしよければ、あなたの会社の「外から見える攻撃面」を、一度のぞいてみてください。