AIエージェントが書いたコードを、別のエージェントに検品させる

実装したエージェントに「レビューして」と頼んでも、返ってくるのは自己申告になる。実装役とは別に検品専任を立てたら、同じコードから実害のある欠陥が3件出た。どれも実装役には何度聞いても出てこなかったものだ。

1. 実機で動いたコードから、手動テストが構造的に踏めない欠陥が出る

事象

実機で一通り触って動作を確認したあと、コード全体をレビュー専任のエージェントに読ませた。2件出た。

• フォアグラウンド復帰時に、日付に依存する表示が更新されない
• 通知の権限を拒否した場合に、画面が無反応になる

どちらも、実機で触っていた数分間には現れない。

原因

テストが雑だったわけではない。検証セッションの形そのものが、その経路への到達を許していない。

• 「翌日また開く」— 検証は数分で終わるので、日付が変わる瞬間をまたがない
• 「権限を拒否する」— 動作を見たいので、最初のダイアログでは必ず「許可」を押す

手で触る限り、この2つは何回繰り返しても踏めない。回数の問題ではないので、丁寧にやっても出てこない。

解決策

実装役とレビュー役を分けたうえで、指示に3つ入れる。

• 実装役の報告を信用せず、コードを読んで検証しろ
• 指摘には、実際に失敗するシナリオを書け
• 修正後、旧コードにテストを当てて再現させろ

2つ目が曖昧な指摘を消す。「〜の可能性があります」で終わる指摘は、シナリオを書かせると自分で取り下げることが多い。3つ目は、指摘が机上の空論でないことの裏取りになる。

同じ立て方で拾えたものがもう1件ある。既存アプリの広告表示を別アプリへ移植したとき、SDKの初期化を呼ぶ1行だけが抜けていた。 型チェックは通る。ビルドも通る。クラッシュもしない。広告枠が空のまま、インプレッションが0で静かに続くだけだ。在庫が無くて配信されていないようにしか見えないので、自力では最も気づきにくい部類になる。レビュー役に「元の実装を実際に読んで突き合わせろ」と指示して出た。

移植レビューで見るべきは「動くか」ではなく「失敗したときに観測できるか」だった。読み込み失敗のハンドラを足しておけば、配信前のテストビルドで露見する。

2. リサーチの出力には、潰す係をぶつける

事象

競合調査をエージェントに投げると、「競合にあって自分にない機能」が大量に返ってくる。これをそのまま実装計画に流す前に、提案を潰すのが仕事の批判専任を別に立ててぶつけた。

批判側が、リサーチにも提案リストにも載っていなかった欠陥を2件、実コードから掘り出した。

• 通知の補充がアプリ起動に依存していて、一定期間開かないと静かに止まる
• 初期サンプルデータがそのまま本番の通知経路に流れて、偽の予定を鳴らす

原因

反対意見が出るから効く、のではない。探索の向きが反転するからだ。

リサーチ役は「足りないもの」を外向きに探す。その姿勢のままでは、自分の内側が既に壊れている可能性を構造的に見ない。批判役は逆向きに探すので、同じコードから別のものが見える。

解決策

批判側のプロンプトに1行入れる。「潰せなかったものは、正直に潰せなかったと書け」。これが無いと全部にケチを付けるので、信号のほうが消える。

そのうえで、批判側の指摘も鵜呑みにしない。実際、技術面の「その前提はもう古い」という指摘は正しかったのだが、確定したのは自分で grep とパッケージレジストリを引いたあとだった。エージェントを増やしても、裏取りの手は減らない。

3. 依頼文は一次情報ではない

事象

修正依頼を5件まとめて出したら、2件は既に実装済みだった。

原因

依頼者の記憶が実装とズレている。特に「前に作ったはず」の領域で起きる。依頼文をそのまま実装させると、二重実装になるか、既存の挙動を壊す。

同じ根で、宣伝文にも当たった。「キーボード入力なしで記録が完結する」と書こうとしてコードを見たら、片方の入力欄にだけ数値を増減するボタンが無い。無条件には成立しない誇張だった。

解決策

着手前に該当コードを読ませ、現況と突き合わせる。既にあるものは実装させず、「ここにこう実装済み」と場所を示して依頼者に判断を返す。

実装前の数分で、二重実装と虚偽表示の両方が止まった。

実際に渡している指示

4行に落ち着いた。役割を分けること自体より、この文面のほうが効いている。

• 実装役の報告を読むな。コードを読め
• 指摘には、実際に失敗する具体的なシナリオを書け
• 潰せなかったものは、潰せなかったと書け
• 着手前に、その依頼が既に実装済みでないか確認しろ

3行目を入れる前は、批判役が全部にケチを付けて使い物にならなかった。