AIに自作をレビューさせない—作る役と検証役を分ける設計
実装したAIに同じ文脈でレビューさせると、自分の書いたものを甘く見る。だから実装役と検証役を分け、レビューは読み取り専用の別セッションに切り離す。その設計と運用を、一人会社の実例で書く。
AIに書かせたコードを、そのままAIにレビューさせていいのか。だめでした。作った本人（同じ文脈のAI）に「これでいい？」と聞くと、ほぼ「いいですね」と返ってきます。自分の書いたものを、自分で甘く見るからです。だから私たちは、作る役とレビューする役を、別のセッション・読み取り専用の権限で切り離しています。
私たちは社長1名とAI COO（Claude Code）だけの会社で、開発の多くをAIエージェントに任せています。そのなかで一番痛い目を見たのが、この「自作を自分でレビューさせる」パターンでした。実装した本人に検証を頼むと、間違いを見つけるどころか、間違いを正当化する説明だけが上手くなっていく。この記事は、それを避けるために実際に組んでいる「作る役とレビューする役を分ける」設計と、その運用の話です。
🪞なぜ自作レビューは甘くなるのか
実装直後のAIは「正しい」前提を抱えたまま。だから自作レビューは、粗探しでなく正当化に働きます。
実装したばかりのAIの頭には、「この方針は正しい」という前提がべったり残っています。 その状態でレビューを頼んでも、新しい目で読み直してはくれません。直前に自分が下した判断を、肯定する方向に働くだけです。 人が、書いた直後の文章の誤字を見落とすのと同じ。ただAIはもっとやっかいで、聞けば「なぜこれで正しいのか」を、すらすらと作文してしまう。甘さが、説得力のある言葉で覆い隠されるんです。
同じ会話のなかで「実装 → 自己レビュー → 修正 → また自己レビュー」と回すと、説明が少しずつ現実からずれていきます。 伝言ゲームと同じで、最初の「まだ確かめていない」が、いつのまにか「確かめた」にすり替わる。 ――これを、一度ならず経験しました。だからレビューは、別の役に、別の文脈でやらせる。そう決めています。
⚙️実装役（Generator）と検証役（Verifier）を分ける
実装役と検証役を別に立て、テスト結果は自己申告でなく、検証役が自分で実行して確かめます。
私たちが社内の開発ハーネスとして育てている willink-claude-kit では、実装するエージェント（Generator / Maker）と、その成果を確かめるエージェント（Verifier / Checker）を、はっきり別に立てています。 肝は、検証役に実装役のテスト結果をそのまま信じさせないこと。「テストを書きました、通りました」という自己申告は、受け取りません。検証役が自分の手で走らせて、終了コードや変更ファイルの範囲みたいに、機械が白黒つけられるものだけを合否の根拠にします。
役を分けるだけで、なぜここまで効くのか。答えはシンプルです。検証役は「この実装は正しい」という前提を、そもそも共有していないから。 前提を持たない相手に読ませると、実装役が「当然わかるだろう」と飛ばした部分が、そのまま疑問として浮かび上がります。この「文脈の非共有」こそが、独立したレビューの正体だと思っています。
🔒レビューには修正権限を持たせない
レビュー役に書き込み権限を渡さない。指摘は出せるが直せない。直すのは別の役の仕事にします。
役を分けたうえで、もう一段こだわっているのが、レビュー役に修正権限を渡さないことです。社内には、成果物を客観評価するためだけの読み取り専用コマンドがあります（私たちは /review と呼んでいます）。ファイルの書き込みも編集も、できません。 指摘は出せる。でも、自分では直せない。直すのは、別のコマンド・別のセッションの仕事です。
まわりくどく見えますよね。でも理由があります。 レビュー役がその場で直せると、指摘とパッチが一体化して、「なぜ問題なのか」の記録が残らないまま、こっそり書き換わっていく。 しかも直す権限を持った瞬間、レビュー役は「自分が直したもの」を、また自分でレビューする立場になる。 ――最初に避けたかった、自作レビューの罠に逆戻りです。 読み取り専用という縛りは、レビューの独立性を制度として担保する、地味だけど効く仕掛けなんです。
🧩別セッションにする理由
実装はメイン、レビューは独立した子セッション。差分と最終成果物だけを、まっさらな目で読ませます。
実装はメインのセッションで進めて、レビューは独立した子セッション（サブエージェント）で走らせています。 同じセッションのまま続けると、実装中の大量のやり取りが、レビュー役の判断にも流れ込む。結局「文脈を共有した相手」に戻ってしまうんです。 読み取り専用の別セッションに切り出せば、レビュー役は差分と最終成果物だけを、まっさらな目で受け取れます。
運用の細かい話も、ひとつ。組み込みのPRレビュー機能には、指摘と同時に作業ツリーまで直せてしまうものがあります。 便利です。でも、セルフレビューの段では、あえてその「直せる」機能は使いません。評価する道具と、直す道具を、名前からして別に持つ。この区別を曖昧にしないことが、あとで効いてきます。
🚦「たぶん大丈夫」を機械のゲートで潰す
自己判定は「9割達成」でも実測は約55%だった。決定論ゲートに置き換え、98%超まで担保しました。
この設計が本当に効くと確信したのは、ある比較実験でした。 ゴール到達型のタスクで、AIに自己判定で完了を宣言させたら、「9割方は達成できました」と返ってきた。 ところが、機械的なゲート――テストが実際にコンパイルされ、通ったかを終了コードで確かめる仕組み――を挟むと、実測はおよそ55%。 そもそも、テストがコンパイルすら通っていませんでした。自己申告と現実が、ここまで開いていたんです。
同じタスクを、決定論的なゲートで合否を判定し直すと、最終的に98%超まで引き上げられました。 差を生んだのは、AIが急に賢くなったからではありません。「達成したはず」という自己判定を、機械が白黒つけるゲートに置き換えた。ただ、それだけです。作る役の自己申告を信じない。独立した検証役と、機械の合否で確かめる。 ――この設計にこだわる理由が、数字ではっきり見えた瞬間でした。
🧭小さな一人会社だからこそ、役を分ける
人手が少ないほどAIの自己採点は鵜呑みにできない。役の分離と機械ゲートを、仕組みで埋め込みます。
社長1名とAI COOだけの会社で、なぜこんな回りくどいことをするのか。 むしろ逆なんです。人手が少ないからこそ、AIの自己採点を鵜呑みにできない。 誰かがあとから全部を見直す余裕なんて、ありません。 だから、作る役とレビューする役を分ける。レビュー役から修正権限を取り上げる。最後は機械のゲートで確かめる。 この規律を仕組みとして埋め込んでおけば、少人数でも「たぶん」で出荷しない状態を、保てます。
まとめると、結論はひとつです。AIに、自分の作品を自分でレビューさせない。作る文脈と、確かめる文脈を、別の役・別のセッション・読み取り専用の権限で、切り離す。派手な話ではありません。でもAIに実務を任せるうえで、この線引きが一番効いていると感じています。 もしあなたもAIに開発を任せているなら、まず「作る役とレビューする役が、同じAIになっていないか」だけ、確かめてみてください。
開発パートナーを探していますか？
AIでプロダクトを最速で形にしませんか？
最短1週間でMVPを開発。アイデアの検証から本番リリースまで、i-Willinkがフルサポートします。まずはお気軽にご相談ください。
無料で相談する