TL;DRPallasは、AI…
TL;DR
LLMを使った仕様駆動開発では、あるエージェントで作った仕様書を別のエージェントに渡すと、実装品質が大きく下がることがあります。OracleからPostgreSQLへの移行タスクで検証した結果、仕様の長さだけでは品質は決まらず、エージェントごとの解釈の違いが影響することが分かりました。対策として、仕様の書き換えや検索拡張（RAG）が有効な場合があります。
解説
ねえ智也くん、このブログのタイトル見て！「LLM開発エージェント間で仕様書は使い回せるか？」って。なんか面白そうじゃない？
ああ、それね。要するに、あるAIエージェントが作った仕様書を別のエージェントに渡して実装させると、品質が落ちることがあるって話だよ。
え、そうなの？同じ仕様書なら同じように作ってくれそうだけど、なんで品質が変わるの？
それが、エージェントごとに解釈の仕方が違うからなんだ。特に、OracleからPostgreSQLへの移行みたいな複雑なタスクだと、仕様書の書き方次第で結果が大きく変わるらしい。
へー、じゃあ仕様書を長く詳しく書けばいいってわけでもないの？
うん、この研究では仕様の長さだけでは品質は決まらないって言ってる。むしろ、エージェントがどう解釈するかが重要で、同じ仕様書でもエージェントが違うと結果が変わっちゃうんだ。
じゃあ、どうやって対策するの？仕様書を書き直すとか？
そうそう、仕様の書き換えや、検索拡張（RAG）を使うのが有効な場合があるって書いてあるよ。RAGで関連情報を追加してあげると、エージェントの解釈が安定するみたい。
なるほどね。でも、なんでこんな研究をしたんだろう？
理由は、実際の開発現場でエージェントを切り替えることがあるからだよ。例えば、仕様書を作るエージェントと実装するエージェントが別々だと、その間で情報がうまく伝わらないと困るでしょ。
確かに、チームで分担するなら、引き継ぎがうまくいかないと大変だもんね。
あと、この研究のすごいところは、OracleからPostgreSQLへの移行という具体的なタスクで検証してる点だよ。実際のプロジェクトで使える知見になってる。
でも、限界もあるんでしょ？
うん、この研究では特定のタスクとエージェントの組み合わせしか試してないから、他のタスクやエージェントでも同じ結果になるとは限らない。あと、RAGの効果もタスクによっては薄いかもしれないって。
なるほどね。でも、仕様書をただ長くすればいいってもんじゃないってのは、なんか人間の仕事と似てるかも。
確かに、人間でも要件定義書が長すぎると逆に混乱するからね。
じゃあ、私が将来AIエージェントに仕事を頼むときは、仕様書を短く簡潔にまとめるのがコツかな？
いや、短くしすぎてもダメだよ。適切な情報量と、エージェントが理解しやすい構造が大事なんだ。
あはは、やっぱりAIも人間と同じで、ちょうどいい塩梅が難しいんだね。
まあ、AIに限らず、伝える側の努力が必要ってことだよ。