Claude と Codex の二刀流レビュー：別系統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 カテゴリ にまとめています。
こうして二重三重に目を通しながら作っているのが、PentaTrailです。外から見える会社の攻撃面を、AIで継続的に把握するCTEMのサービスです。
