AIにバグ修正を頼む前に、怪しい場所と仮説を添える

AIにバグ修正を頼むとき、つい症状を全部渡したくなります。エラー全文、画面で起きたこと、再現した操作、思いつく背景。もちろんそれらは大事です。人間の開発者に相談するなら、再現手順や期待結果がないと話が始まりません。

ただ、AI agent に任せる場面では、症状が長いだけだと「どこを見ればよいか」がぼやけます。読める情報は多いのに、直すための入口が見つからない。これは、仕事の相談でも少し似ています。困っていることをたくさん話しても、相手が最初に見る場所を決められないと、相談は前に進みにくいです。

今回の研究は、バグ報告を AI 修復 agent へのタスク仕様として見直しています。441件のバグ報告を分類し、mini-SWE-agent に修復させた結果、単に長い報告よりも、怪しいファイル・関数・行のような場所の手がかりや、自然文でもよい修正仮説が成功と結びついていました。

ここから借りられる見方はシンプルです。AIに「壊れています」と伝えるだけでなく、「ここが怪しいかもしれない」「こう直すと変わるかもしれない」を仮説として添える。正解を出し切る必要はありません。AIが探索する範囲を少し狭めるための、地図の端を渡すくらいの感覚です。

今日できることは、不具合メモに二行だけ足すことです。まず症状を一文で書きます。次に、怪しい場所を一つだけ書きます。最後に、直し方の仮説を一つだけ添えます。たとえば「保存ボタンを押すと500になる。怪しい場所: profile update の controller。仮説: nil の avatar を前提にしていないかもしれない」のような形です。

この書き方にすると、AIへの依頼が少し変わります。「原因を探して」ではなく、「この仮説が外れている可能性も含めて、まずこの周辺から確認して」と頼めるようになります。AIに丸投げするのではなく、自分の見立てを渡したうえで、広げてもらう使い方です。

注意したいのは、仮説が強すぎるとAIを間違った方向へ寄せることです。怪しい場所と直し方は、決定ではなく仮置きとして書くほうが扱いやすいです。「この仮説が違う場合は、先に反証して」と一言添えるだけでも、確認の幅が残ります。

うまくいったら、バグ報告の最後に「当たっていた手がかり」と「外れていた見立て」を一行で残しておく。次に似た不具合が出たとき、未来の自分とAIの両方が助かります。AIに直してもらう時代ほど、人間側の観察と仮説を雑にしない。その小さな記録が、修正の入口を作ってくれます。