AIにデバッグを頼む時は「整理しすぎない」方がいい

エラーが出たとき、AIにそのまま全文を貼るのは気が引けて、つい「要するにこういうエラーです」と自分で要約してから渡してしまうことがあります。長いログをそのまま貼るのは申し訳ない、という感覚もあると思います。

ただ、筆者が実際にCursorでデバッグを依頼していると、情報を削って渡したときほど的外れな修正案が返ってくる、という場面によく出会います。今回はその対策を1分Tipsとしてまとめます。

今日の結論

• デバッグ時に情報を削りすぎると、AIが本当の原因を見落とすことがあります
• エラー全文・再現手順・期待結果をセットで渡すのが基本です
• 整理は「何を試したか」の時系列程度で十分です

整理しすぎたエラー報告で起きる問題

「エラーメッセージが長いから」と要約してAIに渡すと、的外れな修正案が返ってくることがあります。たとえば「TypeErrorが出ました」だけ伝えると、AIは推測で修正案を作るしかなく、実際のスタックトレースに書かれていたファイル名や行番号、変数名といった手がかりを使えません(執筆時点の実測)。

結果として、的外れな修正を何往復も試すことになり、要約して時間を節約したつもりが逆に時間がかかる、ということが起こります。

なぜ「整理」がAIの判断を狂わせるのか

人間が「重要じゃない」と判断して削った部分に、実は原因が隠れていることがあります。たとえば次のような情報は、一見ノイズに見えても原因特定の手がかりになりやすいです。

• エラーメッセージの前後にある警告（warning）
• スタックトレースの2行目・3行目（要約すると省略されがち）
• ファイルパスの大文字小文字やスペル
• 「何度目の実行で起きたか」「直前に何を変更したか」

AIは人間より文脈の手がかりを多く与えられたほうが、原因の絞り込みが正確になる傾向があります。整理することで情報量そのものが減ってしまうと、AIにとっては逆に判断材料が足りない状態になります。

AIに渡す情報の作り方

手順はシンプルです。

1. エラーメッセージ全文をコピーする(省略・要約はしない)
2. 再現手順(何をしたら起きたか)を3行で書く
3. 期待していた結果を1行で書く
4. 関連ファイルパスがあれば明示する
5. AIの修正案を1つずつ試し、結果をフィードバックする

NG/OK の例

一度にすべての修正案を試すのではなく、1つずつ試して結果(直った/直らない/別のエラーが出た)をAIに返すと、次の修正案の精度も上がりやすいです。

チェックリスト

まとめ

• デバッグ依頼では、情報を削るより「時系列で並べる」程度の整理にとどめるのがおすすめです
• 特にCursorで無料枠を使っている場合、やり取りの往復が減ることはトークン消費の節約にもつながります。詳しくはCursor無料版の実測Hubを参考にしてください
• Cursorでエラーが出た直後の確認順は、関連記事「Cursor開発でエラーが出た時の切り分け順」も参考になります
• 前に読む: 長文AI出力をスクロールコンテナで読みやすくする方法
• 次に読む: AIへの依頼文に「初心者向けに説明して」を足すと精度が上がる
• 関連: pushの前にnpm run buildを実行する理由

免責

本記事は2026年6月21日時点でのCursorを使った実測に基づきます。AIの修正案の精度はモデルやバージョンによって変わる可能性があるため、最終的な判断は実際の挙動を確認しながら進めてください。