エラーの原因特定と解決策の探索

エラー解決でAIを使う際に最も多い失敗は、赤いエラーログだけをコピーしてそのまま投げ込むことです。同じエラーメッセージでも言語やバージョンによって原因がまったく異なるため、環境を知らないAIは最も典型的な原因の1つだと決めつけ、的外れな解決策を指示してしまいます。

コンテキストの段落がその決めつけを防ぎます。フレームワークやバージョン、OSを明記することで、使用していない設定の修正を指示されるのを回避できます。「このコードを今日初めて触る」という一言は、説明の難易度や丁寧さを適切にコントロールしてくれます。

タスクで原因を「可能性の高い順に最大3つ」求める理由は、デバッグ作業の多くが消去法だからです。1つだけ提示されてそれが外れていた場合、最初からやり直すことになりますが、3つあれば次の候補へスムーズに移行できます。続くステップ別の確認手順は、AIが単なる原因の解説に終始せず、ユーザーが今すぐ取れる具体的な行動を回答するように促します。

出力形式の表では「根拠」の列が重要です。根拠を書かせることで、スタックトレースに実際にある手掛かりと一般論を明確に区別できます。このようなデバッグプロンプトでは、ログやコードを """ で囲むことも重要です。エラーログにはクォーテーションや改行、時には自然言語の案内文が含まれているため、明確に区切らないとAIがログの一部を指示文として誤読してしまうことがあります。

関連コードを別途入力させるのも意図的です。エラーメッセージは「どこで落ちたか」は教えてくれますが、「なぜその値が空だったのか」までは教えてくれません。スタックトレースが指し示す行とその周辺を併せて渡すことで、原因候補が一般論から自分のコードに即した具体的な推論へと変わります。

最もありがちな原因を1つ決めつけ、それに基づいた修正コードをいきなり提示してきます。コード全体を渡していないため、提案されたコードは実際のファイル名や変数名と食い違っており、貼り付けても別のエラーが発生します。確認手順も示されないため、外れたときに次に何を確認すべきかわからず、結局同じ質問を言い換えて繰り返すことになります。