解説ねえ、智也くん！この「SW…
TL;DR
SWE-bench Verifiedの441件のバグ報告書を分析した結果、AI修復エージェントの成功には「影響箇所の特定（ローカライゼーション）」と「修正提案（コードまたは自然言語）」が最も強く関連することが分かりました。逆に、人間にとって有用な「再現手順」や「期待される動作」はエージェントの成功率に有意な影響を与えませんでした。バグ報告書は、物語的な記述ではなく、修復タスクを直接指示する「エージェントファースト」な形式にすべきです。
解説
ねえ智也くん、この論文のタイトル、面白そう！「AIエージェントがバグを直しやすいバグ報告書の書き方」って、つまり人間向けとAI向けで書き方変えたほうがいいってこと？
そう。SWE-bench Verifiedの441件のバグ報告書を分析して、どの情報がAI修復エージェントの成功に効くかを調べたんだ。
へえ、441件も！それで何がわかったの？
一番効いたのは「影響箇所の特定（ローカライゼーション）」と「修正提案（コードか自然言語）」だった。逆に、人間には便利な「再現手順」や「期待される動作」は、エージェントの成功率にあまり関係なかった。
え、再現手順ってバグ報告の基本じゃない？それが効かないって意外だなあ。
人間がバグを再現するには必要だけど、AIはコードベース全体を読んで直接修正するから、再現手順よりどこを直すかの情報のほうが重要らしい。
なるほどね。じゃあ、バグ報告書は「物語」じゃなくて「指示書」みたいに書けってこと？
そう。論文では「エージェントファースト」な形式って呼んでる。修復タスクを直接指示する書き方だね。
でもさ、それって人間が読んだらわかりにくくない？両方に対応するのは難しいんじゃない？
そこが課題。この研究はあくまでAIエージェントの成功率に焦点を当ててて、人間の読みやすさは考慮してない。実際の開発現場では、人間とAIの両方が読むから、バランスが大事だと思う。
なるほどね。でも、AIが直しやすい報告書の書き方がわかっただけでも進歩だよね。私もこれからバグ報告書書くときは「どこをどう直せ」って書こうかな。
ああ。ただし、この研究はSWE-benchのデータセットに限った話だから、他のプロジェクトや言語でも同じ傾向かはわからない。
うーん、まだ限界もあるんだね。でも、AIにバグ直してもらう未来が楽しみ！私が書いたバグ報告書、AIが「この指示、わかりやすい！」って褒めてくれたりして。
AIが褒める機能はまだないよ。