エラーをAIに直させる手順：貼り方・情報の渡し方・切り分け
エラーが出たときに、メッセージをそのまま貼るだけで直ることもあれば、何往復しても直らないこともあります。違いを生むのは、エラーの貼り方と、周辺情報の渡し方です。
最終更新: 2026-07-23・読了目安 約3分
エラーメッセージは全文貼るのが基本
エラーに遭遇したとき、要約したり一部だけを伝えたりすると、AIが原因を推測するための手がかりが減ってしまいます。エラーメッセージは、表示された内容を省略せず全文貼ることが基本です。特にスタックトレース（エラーが発生するまでの処理の呼び出し順）は、原因箇所を特定する重要な情報なので、途中で切らずに渡しましょう。
「なんかエラーが出た」だけで済ませず、実際に表示された赤い文字やターミナルの出力をそのままコピーして貼る、という基本動作を徹底するだけでも、AIの初回の推測の精度は大きく変わります。ターミナル操作に慣れていない場合はターミナル入門の記事もあわせて参照してください。スタックトレースがどのような情報を含むかは、MDN Web Docs「Error.prototype.stack」のような技術文書でも解説されています。
エラーメッセージ以外に伝えるべき情報
エラーメッセージだけでは伝わらない情報もあります。次の項目もあわせて伝えると、AIは的確な仮説を立てやすくなります。
- 何をしようとしていたか：どの操作・どのボタンを押した結果のエラーか
- 直前に何を変更したか：エラーが出る直前にどんな指示・編集をしたか
- 再現するかどうか：毎回起きるのか、たまに起きるのか
- 期待していた動作：本来どうなってほしかったか
「直前に何を変更したか」は特に重要です。多くのエラーは直前の変更に起因するため、変更履歴を追える状態にしておくと切り分けが早まります。この考え方はGit/GitHub入門で扱っている履歴管理の価値そのものです。
切り分けの手順
AIに直してもらっても直らない場合、闇雲に「直して」を繰り返す前に、問題を切り分ける手順を踏みましょう。
- 影響範囲を絞る：エラーが起きる最小限の操作・コードだけを再現できないか確認する
- 直前のコミットに戻してみる：戻して直るなら、問題は直近の変更にある
- 1つずつ仮説を試す：AIが提示した仮説を、一つずつ検証しながら潰していく
- 別の言い方で聞き直す：同じ説明を繰り返しても解決しない場合、状況の伝え方自体を変えてみる
この切り分けの姿勢は、テストで動作を確認する考え方とも重なります。詳しくはAIとテスト駆動開発でも扱っています。
「直った」を鵜呑みにしない
AIが「修正しました」と報告しても、実際にエラーが解消したかどうかは自分の目で確認する必要があります。AIは提示したコードが動くはずだという前提でコメントすることがありますが、実行環境やデータの違いによって、実際には直っていないこともあります。修正後は必ず同じ操作を再現し、エラーが本当に消えたかを確かめましょう。
よくある失敗パターン
- エラーメッセージを要約して伝える：重要な手がかりが抜け落ちる。
- 「動きません」とだけ伝える：何がどう動かないのかが不明で、AIは的外れな修正をしがちになる。
- 直前の変更を伝えない：原因の絞り込みに時間がかかる。
- 同じ指示を繰り返すだけ：直らないときほど、状況の伝え方や切り分けの手順を変える必要がある。
よくある質問
Q1. エラーメッセージは一部だけ抜粋して伝えてもよいですか？
できるだけ避けてください。要約したり一部だけを伝えたりすると、原因を推測するための手がかりが減ります。特にスタックトレースは省略せず全文を貼ることが、初回の推測の精度を大きく左右します。
Q2. AIに「直りました」と言われたら安心してよいですか？
必ず自分の目で確認してください。AIは提示したコードが動くはずだという前提でコメントすることがありますが、実行環境やデータの違いによって、実際には直っていないこともあります。同じ操作を再現して確かめましょう。
Q3. 何度直してもらってもエラーが解消しません。どうすればよいですか？
同じ指示を繰り返す前に、影響範囲を最小限に絞る、直前のコミットに戻して切り分ける、仮説を1つずつ検証するなど、状況の伝え方や切り分けの手順を変えてみてください。