IBM Bob にリファクタリングを頼んだら、頼み方を学ぶことになった

Spring のリファレンス実装をリファクタリング対象として IBM Bob に見せたところ、15項目の改善提案が返ってきた。その中に『飼い主ID の検証コードはデッドコードだから削除できる』という指摘があったが、別のAI（Claude）は『それはデッドコードではなく、セキュリティ防御だ』と異論を唱えた。最初は意見が対立したが、聞き直して精査させると、Bob は自分の誤りを認め、そのID チェックが IDOR 攻撃への防御であることに気づいた。

最高に興味深いのは、この『AI vs AI』の対立が実は正しい依頼の仕方を学ぶ転機になったという点だ。最初の依頼は『リファクタリング提案をして』という丸投げに近かったため、Bob は表面的な『改善の余地あり』として提案した。しかし『本当にそうか、テストも含めて精読してください』と聞き直し、さらに『厳格なレビュアーの立場で反証を探してください』と役割を明示的に与えると、見える景色が変わる。Bob は自分から関連テストを探し、実装意図を読み解き、提案を撤回した。つまり、AI に何を求めるか、どの視点を託すかで、検査の深さが決まるのだ。『チェックしてください』と『反証を探してください』では同じコードを読んでも結果が違う。

社内システムの品質確認を AI に任せるなら、単なる『改善提案』ではなく『本当に安全か、実装意図と矛盾していないか、テストで証明できるか』という厳格なレビュアーの役割を明示的に与えよう。AI は与えられた役割に応じて検査の粒度が変わる。役割と視点の指定が、素人の提案と専門的な審査の分かれ目になる。