AIレビューを往復させるルールを作ったら、4往復目に重大指摘がまた4件出ました

AI に書かせたコードを、別の AI にレビューさせています。その記録は前の記事に書きました。1つのツールで、同じ急所を3回直すことになった話です。

あれは1本のツールで起きたことの実録でした。この記事はその後ろ側、AIレビューを何回まわすか・いつ終わりにするかを決めたルールの話です。同じやり方で4件まわしたので、往復ごとの実数も並べます。

先に書いておくと、この形はコードだけのものではありません。私が始めたのも仕事の作業がきっかけで、いまは文章のチェックにも同じやり方を使っています。

結論から言うと、レビューは1回では終わりませんでした。しかも回数を重ねれば素直に減る、という形にもなりませんでした。

先に結論

• 4件まわして、うち2件は途中で重大な指摘が増えた。減り方は一直線ではない
• 決めたルールは3つ。上限5往復・終わりの条件・意見が割れたら人間が裁く
• 人間の仕事は指摘を採るか採らないかを決めて、理由を残すこと
• 別の系統の AI を当てると、同系統で5回見つからなかった欠陥が出ることがある
• コードに限らず使える。文章のチェックでも、片方だけでは出てこない指摘が出る
• この仕組みは日本語のルールファイルで書ける。コードは要らない

発端は、自分の目で判断できなかったこと

そもそもの発端は、Claude に書かせたコードが本当に良いものかどうか、私の目では判断できなかったことです。第三者の目がほしい。それも人ではなく、いつでも呼べる形で。

行き着いたのが、2つの AI に議論させて、その結果を成果物として私が確認する形です。書いた AI に自己点検させるのではなく、別の AI と向かい合わせる。私は議論の中身を全部は追えなくても、割れた論点と結論なら確認できます。

始めたのは2026年の4月ごろで、きっかけは全部が仕事でした。ブログを再開するより前です。たとえば、顧客からのメールに付いてくる添付ファイルを自動で仕分けるツールを作ったときがそうでした。動いてはいるけれど、これを業務に乗せていいのかが自分では判断できない。

そして、この形が効くのはコードだけではありませんでした。文章のチェックでも同じことが起きます。Claude が「この言い方がいい」と判断したものに、Codex が別の視点から指摘を返します。「この書き方だとこう受け取られる可能性がある」といった形です。どちらが正しいかは私が決めますが、片方だけでは出てこなかった論点が机の上に乗ります。

往復の回数や終わり方をルールとして固めたのは、副業のほうでThreads の投稿ツールを作ったときです。私が Claude に書かせたコードを、OpenAI の Codex にレビューさせました。

1回目の指摘を直したら、2回目で同じ場所の別の入口を突かれました。それも直したら、3回目でまた同じ場所でした。往復ごとの重大な指摘は 1件・1件・1件・0件で、4往復目にようやく「重大な指摘なし」が返ってきました。

ここで気づいたのは、1回で止めていたら2回分の欠陥がそのまま残っていた、ということです。しかも1回目の時点では、私は「直った」と思っていました。

それなら往復を前提にすればいい、と考えました。ただし何回でもやれるわけではないので、終わりの条件を先に決める必要がありました。

重大な指摘は一直線には減らない

同じルールで4件まわしました。往復ごとの重大な指摘の件数です。「重大」は、そのまま出すと壊れる・情報が漏れる・取り返しがつかない、に当たるものを指しています。

4件のうち2件で、途中の往復で件数が増えています。3件目は5往復目で1件から2件に増えました。4件目は3往復目で3件から4件に増え、その次も4件のままです。

つまり「減ってきたから次で終わるだろう」という読みは成り立ちません。件数の傾きを終了の合図にすると、増えた回の手前で止めてしまいます。

増える理由は2つあると考えています。1つは、直した箇所の周りが見えるようになって次の層が出てくること。もう1つは、修正そのものが新しい穴を開けることです。後者は4件目で実際に起きました。

AIレビューで決めたルールは3つ

上限は5往復

無限に続けないための線です。5往復で終わらなければ、残っている論点を並べて私が判断します。延長するかどうかもそこで決めます。実際に4件のうち2件は延長しました。

終わりの条件は「重大な指摘なし」と書かれること

「特に問題ないと思います」のような曖昧な返しで終わらせません。レビューを依頼するときに、重大な指摘がなければその旨を明記するよう毎回書いています。あわせて、未解決だと考える論点が残っていれば列挙するようにも頼みます。

これは自己申告で閉じる穴を塞ぐためです。指摘に対応したあとで内容を変えたなら、その変更を見せる往復をもう1回挟むまで終わりにしません。

意見が割れたら、上限を待たずに人間が裁く

こちらが根拠を書いて断った指摘を、相手が「まだ解決していない」と再提示してきたときです。同じ論点で2回目になったら、そこで往復を止めて私が判断します。

AI 同士を向かい合わせると、どちらも自分の主張を続けることがあります。放っておくと往復の枠を水掛け論で使い切ります。

もう1つ、範囲の線引きも決めています。1往復目で示した目的と変更内容が範囲で、そこから外れた既存の問題は別の課題として記録に回します。ただし情報漏れ・データの消失・取り返しのつかない外部への影響だけは、範囲外でもその場で扱います。

人間の仕事は、採否を決めて理由を残すこと

指摘は3つに分けます。採用・不採用・持ち越しです。不採用にするときは理由を書くのを必須にしました。

理由を残すのは、後から見返すためです。断った指摘が後で正しかったと分かることもあります。そのとき「なぜ断ったか」が残っていないと、同じ判断をもう一度やり直すことになります。

実際に断った例があります。Threads ツールのレビューで、投稿の途中経過を記録しておく仕組みを持つよう提案されました。理屈は通っていますが、個人が1日1回使うツールに対して複雑さが割に合わないと判断して、根拠を書いて断りました。

持ち越しは、今回の範囲から外れるけれど直す価値はある、というものです。握りつぶさないように、行き先を決めてから閉じます。

「AI に任せる」ではありません。AI 同士を向かい合わせて、人間が軍配を上げる形です。

別の系統の AI を当てると出てくるもの

4件目の残量表示ツールで、はっきり出ました。Claude や Codex の利用枠があとどれだけ残っているかを画面の隅に出しておく、作りかけの自分用ツールです。実装も、その前のレビューも Claude 系でやっています。バッチごとのレビューと全体レビューで合計5回通しました。

そのあと Codex に渡したら、3件出てきました。5回のレビューでは出てこなかったものです。

いちばん重かったのは、通信が別のアドレスへ転送されたときに認証情報がそのまま付いていく、というものでした。このツールはローカルの認証情報を読んで使うので、当たれば漏れます。指摘を受けてローカルにサーバーを立てて試したら、実際に届いていました。

そしてその修正が、新しい穴を開けました。対策のコードを入れた影響で、「認証情報が漏れていないか」を確かめる自動チェックが壊れました。実際には何も確かめないまま、合格だけを出すようになっていたのです。このプロジェクトでいちばん大事なチェックです。

これは実装を担当した AI が「自分の範囲の外だが気になる」と報告してきて見つかりました。往復を続けていなければ、その合格表示を信じたまま進んでいたはずです。

一方で、往復が増えるほど時間はかかります。4件目は7往復かかりました。

何でもかんでも回すわけではありません。複数のファイルにまたがる変更・見た目や動きが変わる変更・認証や個人情報に触れる変更に限って回しています。

記事も同じ仕組みで回しています

冒頭に書いた文章のチェックを、記事でもそのまま運用しています。書いた AI と検品する AI を分ける形です。

まず機械の検品です。禁止している言い回しや表記の崩れを、スクリプトで機械的に洗います。次に、経緯を知らない AI に原稿だけを渡してレビューさせます。渡すのは「この原稿をレビューしてください」の1行だけで、なぜそう書いたかは説明しません。

理由を知らないほうが判定が安定すると考えているからです。書いた側の事情を伝えると、それを汲んだ判定に寄るように感じています。

この記事自身もその工程を通っています。上の表に出てくる3件目「記事の検品ルール改修」は、この検品の仕組みを直したときの記録です。

そしてこの仕組みは、全部が日本語で書けます。ルールを書いたファイルを置いて、AI にそれを読ませるだけです。上限5往復も、終わりの条件も、意見が割れたときの扱いも、文章で書いてあります。プログラムは1行も要りません。

AI に何かを作らせている人なら、レビューを1回で終わらせない形にするだけで拾えるものがあると思います。次は、この往復で作っている残量表示ツールそのものについて書きます。X のアルゴリズムを読んだ記事と同じで、自分で確かめたことだけを書きます。