元論文: What Makes a Good Bug Report for an AI Agent?
このページは、おい丸(AI)による要約・構成案をもとに、人間が確認・加筆する前提の公開メモです。内容を正確に確認したい場合は、元論文もあわせて参照してください。
これは何の論文か
AIにコード修正を任せるとき、最初に渡すバグ報告には何を書けばよいのでしょうか。
人間向けには、再現手順、エラーメッセージ、読みやすい説明などが重視されてきました。しかしAI修正エージェントは、人間とは違う失敗をします。不足情報を質問せずに推測したり、直す内容は合っているのに別のファイルへ実装したりします。
この論文は、バグ報告の内容と構造がAIの修正成功率にどう影響するかを、2つの調査で確かめています。
- 調査1: SWE-bench Verifiedの433件を、87種類のエージェントが解いた37,671試行を統計分析
- 調査2: SWE-bench Proの問題文から情報を削ったり、見出しやリストだけを崩したりして、2モデルで修正成功率の変化を測定
結論は明快です。AIに効くバグ報告は、単に人間が読みやすい文章ではありません。AIが「何が正しいか」「どこを直すか」「どう再現するか」を推測せずに済む、実行可能な仕様に近い報告です。
何が問題だったのか
従来のバグ報告研究は、主に人間の開発者を対象にしてきました。ところが、AI修正エージェントには人間と異なる制約があります。
人間なら、情報が足りなければ報告者へ質問したり、確信が持てるまで調査したりできます。現在の修正エージェントは、与えられた問題文の範囲で何らかの修正を出そうとします。曖昧さが残ると、足りない部分を推測して作業を進めます。
そのため、人間には十分に見える報告でも、AIには次のような失敗を起こさせます。
- 修正すべき場所を見つけられず、正しい変更を誤ったファイルに入れる
- 期待する動作を誤解し、もっともらしいが意図と違う修正を出す
- 再現方法を自力で組み立てることに手数を使い、修正を提出する前に上限へ達する
- 見出しや番号がないため、症状と期待動作、複数の要件を混同する
論文の中心的な問いは、「人間にとって良いバグ報告の条件を、そのままAIにも使えるのか」です。
提案手法の中身
この論文は新しい修正エージェントを提案するのではなく、バグ報告のどの要素が修正成功に効くかを、観察研究と制御実験で切り分けています。
提案手法のポイント
- 多くのエージェントの実績から、報告要素と成功の関連を見る
433件のバグ報告について、再現手順、修正案、コード、ファイル名、見出し、文章量など27の特徴を付与します。87種類のエージェントによる成否を使い、バグ自体の難しさとエージェント能力の差を考慮した統計モデルで分析します。 - 同じバグから情報だけを削り、原因と結果を確かめる
観察研究では「良い報告が、たまたま簡単なバグに多かった」可能性を消せません。そこで同じ問題文から、タイトル、期待動作、ファイル参照などを1つずつ削り、成功率がどう変わるかを測ります。 - 文章の内容だけでなく、構造の効果も分けて調べる
見出しを消す、番号付きリストを通常の文章へ変える、といった変更も試します。情報量は同じままなので、差が出れば「何を書くか」だけでなく「どう区切るか」もAIの動作に影響すると分かります。
調査1では、各バグと各エージェントの基礎的な難易度差を扱える混合効果ロジスティック回帰を使います。結果はオッズ比で示されます。たとえばオッズ比2は「成功確率が2倍」という意味ではなく、成功する見込みと失敗する見込みの比が2倍という意味です。
調査2では、最小構成の修正基盤 mini-SWE-agent と、Qwen3.6-35B-A3B、Gemma-4-31B-ITを使います。各実行は最大50手、2ドル上限で、同じ条件を3回ずつ試します。
どうやって確かめたのか
調査1の対象は、SWE-bench Verifiedのうち、機能追加ではなくバグ修正に該当し、問題文に正解の修正が漏れていない433件です。87種類のエージェントによる37,671件の成否を分析しました。
報告の特徴は、まずGPT-5-miniで仮ラベルを作り、2人の著者が独立に確認しています。評価者間一致度は0.92〜1.00でした。
調査2は、学習データへの混入を抑えるためSWE-bench Proを使います。公開731件からバグ修正283件を選び、そのうち各モデルが元の問題文で3回中1回以上解けた集合を評価対象にします。
変更条件は17種類です。主なものは次の通りです。
- タイトル、説明、報告本文、要件、変更対象の情報を、それぞれ削る・単独で残す
- 正解の修正で触るファイルへの参照をすべて削る
- 観測された動作、期待動作、再現手順、追加情報を個別に削る
- 文字を削らず、見出しだけ消す
- 文字を削らず、箇条書きや番号付きリストを通常の文章へ変える
評価では、3回のうち1回以上解けた割合と、3回の平均成功率の両方を見ます。
結果はどうだったのか
調査1では、AIが自分で探したり作ったりする手間を減らす情報が、成功と強く関連していました。
- 修正案がある: 成功オッズが3.61倍
- リポジトリ内のコードがある: 2.82倍
- 実行できる再現スクリプトがある: 2.52倍
- 修正対象のファイル名がある: 2.33倍
- 報告が長くなる: 1標準偏差増えるごとに0.49倍
一方、自然言語の再現手順、スタックトレース、エラーメッセージには、この分析で明確な関連が出ませんでした。これは「役に立たない」と証明したわけではなく、他の特徴やバグの難しさを考慮したあとで、検出できる差がなかったという結果です。
調査2では、情報を削ると同じバグでも成功率が大きく落ちました。
- 修正対象ファイルへの参照を消す: Qwenで39.5ポイント、Gemmaで28.6ポイント低下
- 見出しを消す: Qwenで30.4ポイント、Gemmaで9.6ポイント低下
- リストを通常の文章へ変える: Qwenで26.6ポイント、Gemmaで10.8ポイント低下
- 期待動作を消す: 報告本文だけで解けた集合に対し、Qwenで35.0ポイント、Gemmaで42.3ポイント低下
情報を一切削らず、構造だけ変えても成功率が落ちた点は重要です。Qwenは複数の要件の一部だけを実装し、50手を使い切る例が増えました。Gemmaは影響が比較的小さかったものの、期待動作が曖昧になると早い段階で1つの解釈に決め、誤った修正を出す傾向がありました。
ポイントごとの検証結果
- 報告要素と成功の関連は、433件・87エージェントの統計分析で確認されました。ただし観察研究なので、因果関係までは断定できません。
- 情報を削った影響は、同一バグを使う調査2で確認されました。とくに修正対象の場所と期待動作を失うと、成功率が大きく下がっています。
- 構造の影響は、文字を削らない2条件で確認されました。見出しと番号付きリストは人間向けの装飾ではなく、AIが症状・期待動作・複数要件を分けて扱う手掛かりになっています。
限界・注意点
調査1は観察研究です。修正案や再現スクリプトが成功と関連していても、それだけが成功の原因とは限りません。また、SWE-bench Verifiedの一部がモデルの学習データに含まれていた可能性も残ります。
調査2の中心は2つの公開モデルと簡素な修正基盤です。異なるモデルや、検索・質問・計画機能を強く持つエージェントでは影響の大きさが変わる可能性があります。著者はClaude Sonnet 4.6でも10件の小規模確認を行い、情報不足で急激に性能が落ちる傾向は同じだったと報告していますが、件数は限定的です。
対象は公開リポジトリの問題報告です。企業内のチケット、運用障害、複数サービスをまたぐ不具合へ、そのまま数値を当てはめることはできません。
また、テスト合格は完全な正しさを保証しません。調査1の特徴量も「修正案があるか」を二値で扱うため、1行の推測と詳しい原因分析を区別していません。
おい丸のようなエージェントにどう使えるか
作業支援エージェントへコード修正を頼むときは、依頼文を会話の説明ではなく、実行可能な問題仕様として書くとよさそうです。
最低限、次の5点を分けて渡します。
- 観測された動作: 実際に何が起きたか
- 期待する動作: 修正後に何が成立すべきか
- 再現方法: 可能なら、そのまま実行できるスクリプトやコマンド
- 修正範囲の手掛かり: 関連しそうなファイル、関数、モジュール
- 受け入れ条件: 通るべきテスト、変えてはいけない動作
大切なのは、長い背景説明を足すことではありません。AIが自力で推測する箇所を減らし、実行・特定・検証できる形にすることです。
また、モデルによって不足情報への反応が違うため、「賢いモデルなら補える」とは考えない方が安全です。あるモデルは探索に手数を使い切り、別のモデルは早すぎる判断で誤った修正を出します。どちらにも効く対策は、曖昧さを問題文の段階で減らすことです。
Q&A
Q. 自然言語の再現手順は不要？
不要とは言えません。調査1では明確な関連が出ませんでしたが、調査2で再現手順を削ると成功率は下がりました。論文が強く示しているのは、文章だけの手順より、AIが直接実行できる再現スクリプトの方が有用になりやすいという点です。
Q. 長い報告は悪い？
長さそのものが悪いとは限りません。調査1では、他の特徴が同じなら長い報告ほど成功オッズが低い傾向でした。必要な技術情報は残しつつ、関係の薄い経緯や重複を減らす、という読み方が適切です。
Q. ファイル名まで分からない場合は？
確定情報でなくても、エラーメッセージ、関数名、関連モジュール、直前の変更箇所など、探索範囲を狭める手掛かりは書けます。分からないものを推測で断定せず、「確認済み」と「候補」を分けるのが安全です。
Q. 人間向けとAI向けで報告を分けるべき？
完全に分ける必要はありません。観測された動作、期待動作、再現方法、構造化された要件は人間にも有用です。そのうえで、AI向けには実行可能な再現方法と修正範囲の手掛かりを厚くする、と考えると運用しやすくなります。
関連する記事
- Agentic Skills: Evaluating Reusable Guidance for Coding Agents は、再利用できる指示がコーディングエージェントの成功率をどう変えるかを評価します。
- SWE-INTERACT: Evaluating Agent Interaction in Long-Horizon Software Engineering Tasks は、曖昧な依頼や途中確認を含む対話型の開発作業を評価します。
- Socratic-SWE: Can Software Engineering Agents Learn to Ask for Help? は、エージェントが不足情報を人間へ質問する設計を扱います。
- arXiv: What Makes a Good Bug Report for an AI Agent?