作った本人には、検品させない — AIの成果物は、経緯を知らないサブエージェントに採点させている

しばらくのあいだ、僕はAIが作ったものを、そのまま出していました。

作らせたその場で「これで大丈夫？」と聞く。すると、だいたい大丈夫だと返ってきます。じゃあ大丈夫なんだろう、と思って出す。今にして思えば、あれは確認ではなくて、確認したつもりでした。

変えたのは単純なことで、経緯をまったく知らない別のAI（サブエージェント）を呼んできて、そいつにQAを回させるようにしました。作った側には、もう聞きません。それだけで、それまで素通りしていた粗が、急に出てくるようになりました。

今では、何を作らせても最後に「QA回して」と言います。ほとんど口ぐせです。

作った本人には、自分の粗が見えない

なぜ同じAIに聞いてはいけないのか。理由は、たぶん人間とまったく同じです。

自分が書いた文章の誤字は、読み飛ばします。目が文字を追っているようで、実際には「自分が言おうとしたこと」のほうを読んでいるからです。他人が読めば一行目で気づくものが、書いた本人には最後まで見えない。

AIも似たようなことになります。直前まで自分が組み立てていた理屈の中にいるので、その理屈ごと間違っていても、内側から見るかぎり筋は通っている。そこへ「これで大丈夫？」と聞けば、自分の筋道をもう一度たどって、大丈夫です、と返してくる。嘘をついているわけではなくて、立っている場所が悪いだけです。

一度、はっきり出たことがありました。数字の合わない仕組みを調べさせたとき、レナードが「原因はこれ一つです」と言い切ってきたんです。レナードというのは、毎日使っている Claude Code に付けた呼び名です。

筋は通っていたし、僕もそれで納得しかけました。念のため、サブエージェントにQAを回させたら、条件を満たす答えは三通りありました。唯一ではなかった。

自信たっぷりに断定してくるときほど、その断定の内側に閉じている。以来、言い切りが返ってきたときこそ、外から一度当てるようにしています。

製造と品質管理は、分かれている

この話は、ものづくりの仕事をしていれば、たぶん一瞬で通じます。

多くの会社で、製造と品質管理は絶対に分かれています。作った人間ももちろん、自分で確認はします。でも、最終的に出荷していいかを決めるのは、品質管理のほうです。

品質管理の仕事は、「ダメならダメ」と言うことです。それを通せばいくらの売上になるとか、ここで止めたらラインがどれだけ止まるとか、そういうことは関係ない。基準を外れていたら止める。どれだけ損失が出ようと止める。それが役割として与えられている。

なぜ、そこまでして分けるのか。作った人間には、思い入れがあるからです。手間をかけたぶんだけ、もったいないという気持ちが働く。これくらいなら許容範囲じゃないか、と自分を納得させる理由を、いくらでも見つけられてしまう。悪気があるわけではなくて、作った人間の立ち位置が、どうしても通したがる側に寄っている。

だから、通したい側と、止める側を、はじめから別の人間に割り振っておく。役割で分けてしまえば、その日の気分にも思い入れにも左右されなくなります。いい製品が最後に出てくるのは、誰かが特別に厳しいからではなくて、この分け方があるからです。

作らせたAIに、そのまま「これで大丈夫？」と聞いていたというのは、製造の人間に出荷判定までやらせていたのと同じでした。しかも相手は、人間よりずっと素直に「大丈夫だと思います」と言ってきます。

経緯は、教えない

今は、サブエージェントに渡すものを二つだけに決めています。レナードが作ったものと、QAのブリーフ。この二つだけです。

渡さないほうは、「どういう狙いで作ったか」と「どこで苦労したか」。これを教えると、忖度が入ります。人間でもそうで、事情を先に聞いてから見ると、どうしても甘くなる。あれだけ苦労したんだから、まあいいか、と。だから狙いも経緯も伏せたまま、出てきたものとブリーフだけを渡して、判断材料をその二つに限定してしまいます。

ありがたいことに、ここはAIのほうが人間より徹底できます。サブエージェントは裏で立ち上がるので、本当に何も知らない状態から始まる。前の会話も、途中の言い訳も、一切引き継がれません。事情を知らないふりをするのではなく、実際に知らない。この「知らないやつを連れてこられる」という一点が、独立したQAがちゃんと機能する理由だと思っています。

利点はもうひとつあって、こちらの会話が汚れません。QAは、成果物とブリーフを丸ごと読ませる作業なので、それなりに量を食います。レナードにそのままやらせると、そのやり取りが全部コンテキストウィンドウに残って、作業中の会話のトークンを食いつぶす。サブエージェントに出しておけば、向こうでどれだけ読ませても、戻ってくるのはQAの結果だけです。手元は軽いまま済みます。

効いた例を二つ挙げます。

一つは、注文データを取り込む仕組みでした。同じ注文が二重に入らないよう突き合わせる判定を入れてあったのですが、日付の持ち方が場所によって揃っておらず、同じ注文を別物として通してしまう穴があった。作った側は、正しく動いていると見ていました。レナードはそこを見逃しています。サブエージェントが読んで、そこを突いてきました。

もう一つは、コードそのものにはまったく問題がなかったのに、必要な権限の宣言が一行足りていなかった、というものです。書かれた中身は正しい。ただ、僕がボタンを押した瞬間に必ず落ちる状態でした。これもサブエージェントが拾いました。作った側からは、見えていません。

どちらも、止まらなければそのまま本番に出ていたものです。そして本番で気づくというのは、たいてい、誰かに迷惑をかけてから気づくということです。

ブリーフを、毎回同じにしておく

やってみて、もう一つ大事だと分かったことがあります。このQAのブリーフを、毎回同じにしておくことです。

観点を決めずに「チェックして」とだけ頼むと、回すたびに違うところを指摘してきます。しかも厄介なことに、粗を探せと言われた相手は、粗が無ければ作り出します。これはAIに限った話ではなくて、人にレビューを頼んでも同じことが起きる。「何か言わなきゃ」が働くので、些細な指摘が湧いてくる。外部の認証を受けるとき、そう感じたこと、ないですか？

なので、何をどう見るかを先に書き出して、ブリーフとして固定しておきます。この観点だけを見ろ、それ以外は指摘するな、と縛る。ブリーフがあると、QAをやる側が新しい粗を発明できなくなります。

前に、繰り返す作業を「スキル」という型に固定した話を書きました。あのとき、答えが機械的に決まるものは小さなプログラムに落とし、良し悪しを見きわめるものはルーブリックで縛る、という段の話をしています。このQAのブリーフは、そのルーブリックのほうです。ブレを止める道具として作ったものが、そのまま「あら探しの柵」にもなっていた、というのは後から気づきました。

止めどきを、先に決めておく

ブリーフと同じくらい効いたのが、止めどきです。

以前、本の原稿を読者役のAIに何度もレビューさせたことがありました。よかれと思って何度も回したのですが、回すほど細かいところに潜っていって、しまいには自分の原稿が壊れて見えました。あれは、原稿が壊れたのではなく、レビューが壊れていたんだと思います。

一回目は、いちばん本質的なことを言ってきます。二回目は改善の幅が減る。三回目以降は、直すことで良くなっている保証がだんだん無くなって、あるところから改悪に転じる。放っておくと、満点を追って永遠に直し続けることになります。

今は三つ決めてあります。回数は一回、多くて二回。合格ラインは「致命的なものが無ければ出す」で、好みのレベルの指摘は採らない。そして観点は固定する。三つ目がいちばん強くて、これがあると内側から勝手に止まります。

僕はもともと、七割八割で出してあとから直す、というやり方でやっています。QAを付けたのは品質を満点にするためではなくて、致命的なものだけを外に出さないためです。そこを混ぜると、QAが目的になって手が止まります。

QAは、出す時だけのものではなかった

最近もうひとつ変えたことがあります。レナードが作ったものだけでなく、作りはじめる前の提案にもQAを通すようにしました。

きっかけは、しょうもない取り違えでした。レナードに毎回読ませているメモリが、上限に迫っている。そう思って、レナードに改善案を三つ出させました。

いつもなら、そのまま書かせて終わりです。今回はその前に、出てきた提案のほうをサブエージェントに回して、前提からQAを回しました。すると、上限の単位を取り違えていた。バイト数だと思っていたものが、実際には文字数でした。上限までは、まだずいぶん余裕があったんです。

結果、三つの提案のうち一つは丸ごと要らなくなり、もう一つは規模が半分以下に縮みました。QAを回さずにレナードに書かせていたら、要らない工事と、消さなくてよかった六十二行の削除を、そのまま確定させていたことになります。

作らせたもののQAは「これは良いか」を見ます。提案のQAは「そもそもこれは要るか」を見る。外したときの損は、後者のほうがずっと大きい。前提が間違っていると、その下でやった作業が全部無駄になるからです。そのわりに、提案のほうは誰もQAを回しません。自分で立てた前提なので、正しいことにして先へ進んでしまう。作った本人に検品させない、という話は、そのまま前提にも当てはまりました。

おわりに

作る側と、止める側を分ける。ものづくりの現場では当たり前で、誰も疑いません。分ける手間を払ってでも、不良を一つ外に出すほうが高くつくと、みんな知っているからです。

その当たり前が、相手がAIになった途端に抜けました。しかも、賢いモデルを使っているときほど抜けます。これだけのものを作ってくるモデルなら、間違いにも気づくだろう、と。

でも、モデルの差ではありませんでした。問題は立ち位置のほうで、自分が作ったものの外側には、原理的に立てない。誤字を読み飛ばすのと同じことが、もっと大きな単位で起きているだけです。

だから僕は、作らせた相手には検品させません。経緯を知らないサブエージェントを呼んできて、ブリーフだけ渡して、致命的なものだけ拾わせる。それで通ったら出す。手間は一手増えますが、増えたのは一手だけです。

この記事に出てきた言葉

• レナード … 毎日の作業を任せている Claude Code に付けた呼び名。映画『メメント』の主人公から取っています。
• サブエージェント … 本体とは別に立ち上げる、独立したAIの作業役。前の会話を一切引き継がないので、事情を知らない第三者として使えます。
• ブリーフ … 作業を頼むときに先に渡す指示書。何がゴールで、どこは触らないで、何が揃ったら終わりかを書いておきます。
• QA … 品質保証（Quality Assurance）。作ったものを出す前に、基準を満たしているか確かめる工程のこと。製造業では独立した部門が担います。
• コンテキストウィンドウ … AIが一度に抱えていられる範囲。会話が長くなるほど埋まっていき、埋まると古いところから押し出されます。
• トークン … AIが文章を読み書きするときの単位。読ませた量も書かせた量も、ここで数えられます。
• スキル … 繰り返す作業の手順を型に固定して、呼ぶだけで同じ品質が返るようにしておく仕組み。
• メモリ … AIに毎回読ませておく、確定した事実や決めごとのファイル。都度説明しなくても前提が引き継がれます。
• モデル … AIの中身そのもの。同じ道具でも、賢いモデルと速いモデルを選び分けられます。
• ルーブリック … 何をどう見るかの判断基準を、採点の前に表にして渡しておくもの。

この記事は、シリーズ「AIに染まりきるまでの4ヶ月」の実践編です。前の記事『意外と語られない、AIの使い方3つ — 声の辞書を育てる・資料を軽くする・残りを見えるようにする』では、AIに頼む手前を整える三つの習慣を書きました。この記事では、AIに頼んだ後——AIが作ったものを誰にチェックさせるか——を書いています。