Claude Codeへのエラーの伝え方｜直し方が変わる報告の型3点セット

先に結論: エラーは①直前の操作 ②画面に出た文言(原文コピペ) ③期待した結果と実際の結果、の3点セットで伝えると、Claude Codeが原因を特定しやすくなり直り方が変わります。

「エラーが出ました、直してください」とだけ伝えて、Claude Codeになかなか意図通りに直してもらえなかった経験はないでしょうか。実は同じエラーでも、伝え方を変えるだけで直り方が大きく変わります。

「Claude Codeに最初に頼むこと10選」の続編として、この記事ではエラーに遭遇したときの伝え方だけに絞って、コピペで使える型を紹介します。

Claude Code全体の使い方は「Claude Codeの使い方完全ガイド」もあわせてご覧ください。この記事は2026年8月時点の情報に基づいています。

この記事の要点

• エラーを伝えるときは「①直前の操作 ②画面に出た文言 ③期待した結果と実際の結果」の3点セットで書くと、Claude Codeが原因を特定しやすくなります。
• エラーメッセージは自分の言葉で要約せず、画面に表示された文言をそのままコピペするのが基本です。
• Claude Codeは@ファイル名で該当ファイルを直接参照でき、Ctrl+V(macOSはCmd+Vやドラッグ&ドロップ)で画像も貼り付けられます(2026年8月時点)。
• 複数のエラーが同時に出ている場合は、1つずつ順番に伝えたほうが原因の切り分けが早く進みます。
• 作業が想定と違う方向に進み始めたら、Escキーでいつでも中断し、そこまでの作業を残したまま追記できます。

前提: なぜ「エラーが出た」だけでは直らないのか

Claude Codeは、渡された情報から原因を推測して修正案を組み立てます。「エラーが出た、直して」だけでは手がかりが少なすぎて、見当違いの箇所を直したり、聞き返しで1往復無駄にしたりしがちです。

SNSでも「AIにエラーを丸投げしても直らなかったが、伝え方を変えたら一発で直った」という声がよく見られます。情報不足のまま「直して」と繰り返すのは、症状を言わずに「治して」と頼むようなもので、遠回りになりがちです。

次に紹介する3点セットは、この手がかり不足を解消する最短ルートです。

エラー報告の3点セット

エラーを伝えるときに欠かせないのは、①直前に何をしたか(実行した操作やコマンド) ②画面に出た文言(エラーメッセージの原文) ③期待した結果と実際の結果、の3点です。この3つがそろっていれば、Claude Codeは再現条件と失敗箇所をほぼ一意に特定できます。

実際に伝えるときは、次のようにテキストにまとめて貼り付けると確実です。

①直前の操作: npm run build を実行した
②画面の文言: Module not found: Can't resolve './utils' in './src/App.tsx'
③期待と実際: ビルドが通ることを期待したが、上記のエラーで止まった

この3点さえそろっていれば、多くの場合Claude Codeは追加の質問をせずにすぐ調査を始められます。番号を振らず地の文で書いても構いませんが、慣れないうちは箇条書きにしたほうが書き漏らしを防げます。

Claude Codeでの伝え方: コピペ・@参照・Escの使い方

型が決まったら、あとはClaude Codeの実際の操作に落とし込むだけです。

• エラー原文はそのまま貼る: ターミナルに表示されたメッセージを選択してコピペするのが最も確実です。要約すると、ファイルパスや行番号、変数名といった重要な情報が抜け落ちてしまいます。
• 該当ファイルは@で参照する: 「@src/App.tsxのこの関数で〜」のように@に続けてパスを入力すると、Claude Codeがファイルの中身を直接読み込んで会話に含めます。@を入力するとパス候補のメニューが開き、Tabキーで補完できます。
• スクリーンショットより文字列を優先する: Claude Codeは画像をCtrl+V(macOSはCmd+V)やドラッグ&ドロップで貼り付けられ、UIの見た目やエラーダイアログの確認には便利です。ただし長いスタックトレースは画像だと途中で見切れやすいため、テキストで渡せる場合はテキストを優先してください。
• Escで止めて追記する: 実行中に見当違いの方向へ進み始めたと感じたら、Escキーでいつでも中断できます。それまでの作業内容は残ったままなので、「そこじゃなくて、こっちのファイルを見て」と追記すればすぐに軌道修正できます。

悪い例 → 良い例

同じエラーでも、伝え方でここまで違います。

--- 悪い例 ---
さっきのエラー直して

--- 良い例 ---
①直前の操作: `npm test` を実行した
②画面の文言: TypeError: Cannot read properties of undefined (reading 'map') at src/utils/format.ts:42
③期待と実際: テストがすべて通ることを期待したが、上記エラーでテストスイート全体が停止した

悪い例では「さっき」がいつのことで、どのコマンドの結果なのかをClaude Codeが再度確認する必要があります。良い例なら、原因調査に必要な情報がすべて最初のメッセージに含まれているため、確認なしで修正に着手できます。

エンジニアではない方の間では、エラー画面をまずスクリーンショットで撮ってそのままAIに見せるという手軽な伝え方が広く支持されています(2026年8月時点)。

この始め方自体は問題ありませんが、貼り付けたスクリーンショットに「①直前にやったこと ②(画像内の文言に加えて)期待していた結果」を一言添えるだけで、③の実際の結果と合わせて3点セットが揃い、Claude Codeの調査精度がさらに上がります。

つまずきポイント: エラー報告でやりがちな失敗

• エラーメッセージを自分の言葉で要約してしまう: 「なんかimportでエラーが出た」のように言い換えると、正確なパスやエラー種別の情報が失われます。多少長くても原文をそのまま貼るほうが結果的に早く直ります。
• 複数のエラーを1つのメッセージに詰め込む: ビルドエラーとテスト失敗を同時に伝えると切り分けにくくなります。複数ある場合は1つずつ報告し、直ったことを確認してから次に進むのが安全です。
• 再現手順を書かない: 「たまに出る」「特定のファイルだけで出る」といった発生条件は、原因調査の時間を左右します。気づいた条件はメモ程度でも添えてください。
• 画面全体のスクリーンショットだけで済ませる: 見た目確認には便利ですが、長いログはテキストのほうが検索・引用しやすく見落としも防げます。

よくある質問

エラーメッセージが英語のままでも、翻訳せずそのまま貼っていいですか?

問題ありません。Claude Codeは英語のエラーメッセージもそのまま解析できます。むしろ翻訳や要約を挟むと情報が欠けるため、原文のままコピペするほうが確実です。

ターミナルのログが長すぎてコピペしきれないときはどうすればいいですか?

ログをテキストファイルに保存して@ファイル名で参照させる方法が確実です。急ぎであれば、エラーが発生した箇所の前後数十行だけを抜粋して貼る形でも十分に伝わります。

同じような伝え方のミスを繰り返さないためにはどうすればいいですか?

プロジェクトのルールをCLAUDE.mdにメモしておく方法があります。「エラー報告は3点セットで」とルール化すれば、次回以降Claude Code自身がその形式を意識しやすくなります。CLAUDE.mdの使い方は「Claude Codeの使い方完全ガイド」で解説しています。

まとめ

エラーの直り方は、伝え方ひとつで大きく変わります。①直前の操作 ②画面の文言(原文コピペ) ③期待と実際、の3点セットを意識するだけで、Claude Codeが的確に原因を特定できるようになります。

複数のエラーは1つずつ、スクリーンショットより文字列、行き詰まったらEscで止めて追記——次にエラーに遭遇したときにぜひ試してみてください。同じ考え方は、CodexやGitHub Copilotにエラーを伝えるときにも有効です。

Codexでのトラブル対処は「Codexが動かない時の対処法」を参考にしてください。

Claude Code自体の不調は「Claude Codeが動かない時の対処法」、用語につまずいたら「AI開発の用語辞典」、最初の頼み方は「Claude Codeに最初に頼むこと10選」もあわせてご覧ください。