ログを貼らずに「動きません」だけ投げるのは、ほぼ自爆だ。Claude Code に原因切り分けを頼むなら、症状の説明より先に、エラーログをそのまま渡したほうが速い。これは開発作業でも、ファイル整理でも、書類の自動生成でも同じである。曖昧な依頼は、余計なやり取りを増やしてコンテキストを食い、最後に「それ、最初に出してくれれば済んだのに」になる。
Claude Code は、端末上で見えているエラー文や関連ファイルを手がかりに、何が壊れているかをかなり実務的に絞れる。だが、こちらの頼み方が雑だと、関係ない方向を見始める。筆者も最初は「なんか失敗する」で投げて、延々と見当違いの説明を掘らせたことがある。ログを最初から貼っておけば、あの無駄な往復はかなり減ったはずだ。
まず、頼み方の基本形はこれでいい。
次のエラーログを読んで、原因候補を優先度順に切り分けてください。
不明な点は、追加で見るべきファイルやコマンドも挙げてください。
推測だけで断定せず、ログから読める事実と推測を分けてください。
[ここにエラーログを貼る]
これだけでも十分使えるが、実際には少し足したほうが強い。Claude Code が困るのは、ログ単体では文脈が足りないときだ。だから、次の三つを添えると切り分けの質が上がる。
ひとつ目は、何をしていたときのエラーかだ。たとえば「Node の依存関係を入れた直後」「ディスク整理のために重複ファイルをまとめた直後」「Word 書類を生成する処理を回した直後」など、直前の操作を書く。
ふたつ目は、失敗した操作を再現できるかどうかだ。毎回失敗するのか、たまに失敗するのかで、原因の当たり方が変わる。
みっつ目は、関連するファイルやコマンドだ。ログだけでなく、実行したコマンド、設定ファイル名、触ったディレクトリを一緒に出す。
たとえば開発寄りなら、こんな頼み方になる。
このエラーログの原因を切り分けてください。
状況:
- 直前に package.json を更新した
- npm install のあとに実行した
- 失敗は毎回再現する
見てほしいもの:
- ログの中で原因に直結する行
- まず確認すべきファイル
- 修正の優先順位
ログ:
[ここに全文]
非エンジニア寄りの使い方でも同じだ。たとえば、フォルダ内の大量ファイルを整理していて止まったなら、操作した内容をそのまま書く。
このエラーを見て、どこで詰まっているかを切り分けてください。
状況:
- 画像ファイルを月別フォルダに移動する作業をしていた
- 同名ファイルの扱いで止まった
- どのファイルを残すべきか判断したい
してほしいこと:
- エラーの意味をわかりやすく説明する
- 競合している可能性がある箇所を挙げる
- 次に確認する順番を教える
ログ:
[ここに全文]
ここで大事なのは、Claude Code に「直して」と丸投げしないことだ。先に「切り分けて」と頼むほうがいい。修正まで一気に走らせると、原因が曖昧なままファイルを書き換えて、あとで戻す羽目になる。diff がやたら大きくなって、「何を直したのか追えない」といういつもの地獄に入る。筆者はこれで一度、原因確認前に手当たり次第の修正を進めてしまい、結局やり直した。急ぐほど、先に切り分けるほうが安い。
ログの貼り方にもコツがある。長いログを途中で切るなら、先頭と末尾を残すのが基本だ。特に末尾には、実際の失敗理由が出やすい。逆に、前半だけ貼って「ここで止まる」と言うと、肝心の例外メッセージが欠ける。長すぎる場合は、全文を貼ったうえで「特に注目してほしいのは末尾のこの部分」と指示すればよい。
以下のログ全文を見てください。
特に末尾のエラー文と、そこに至る直前の数行を重視してください。
原因候補を3つまでに絞り、どれが本命かも書いてください。
[全文]
もうひとつ、やりがちな失敗がある。人間は自分が見たエラーだけを貼りたくなるが、Claude Code には前後関係が要る。ひとつの例外メッセージが、別の失敗の結果として出ていることは珍しくない。たとえば「ファイルがない」という表面上のエラーでも、実はその前に権限設定が崩れていた、パスの指定がずれていた、作業フォルダを勘違いしていた、という話はよくある。だから、同じ失敗を繰り返しているなら、1 回分より複数回分のログを並べたほうがいい。
同じ失敗が3回出ています。
3回分を見比べて、毎回共通している行と、再現ごとに変わる行を分けてください。
共通部分を原因の手がかりとして扱ってください。
[ログ1]
[ログ2]
[ログ3]
この頼み方は、Claude Code にとってもかなり扱いやすい。共通部分と変動部分を分けて見れば、環境依存なのか、入力依存なのか、ファイル依存なのかを絞りやすいからだ。特にファイル整理や文書生成では、対象ファイルの一部だけが壊れているのか、フォルダ構造全体の問題なのかで、対処がまるで変わる。
注意点もある。機密情報をそのまま貼らないことだ。API キー、個人情報、案件名、社外秘のパスがログに混じることは普通にある。必要なら伏せ字にしてから貼ればいい。ただし、伏せ方が雑で原因部分まで消すのは本末転倒だ。ファイル名、拡張子、エラーメッセージの型は残す。値だけ隠す。ここを雑にやると、原因切り分けの精度が落ちる。
置き換えルール:
- 実名やIDは [REDACTED] にする
- ファイル名の拡張子は残す
- エラーメッセージ本文はできるだけ残す
- パスは末尾のディレクトリ構造がわかる程度に残す
もうひとつの落とし穴は、ログに対して最初から答えを決め打ちすることだ。「たぶん権限だと思う」「きっと文字コードだろう」と先に言ってしまうと、Claude Code までそっちに引っ張られる。切り分けを頼むときは、仮説は添えてもいいが、主役にしないほうがいい。
仮説としては権限周りを疑っていますが、先入観は持たずにログから判断してください。
原因候補を、証拠の強さつきで並べてください。
この言い方が効くのは、Claude Code が「怪しいところを当てる」より、「ログから外せるものを落とす」作業に向いているからだ。原因を一発で当てる必要はない。むしろ、まずは候補を減らす。そこから追加ログを取りにいく。この往復が一番速い。
応用するなら、依頼の最後に「次に取るべきログ」まで聞いておくといい。原因候補だけでは、次の一手がぶれるからだ。
原因候補を出したあと、追加で取るべきログや確認コマンドも提案してください。
こちらで次に何を見ればいいか、順番つきで教えてください。
この形にしておくと、Claude Code は単なる説明係ではなく、切り分けの相棒になる。ログを貼る。状況を一言添える。推測と事実を分けさせる。次に見る場所まで出させる。この4点を守るだけで、手戻りはかなり減る。
最後に、いちばん実用的な型を置いておく。迷ったらこれを使えばいい。
次のエラーログを読んで、原因を切り分けてください。
断定ではなく、ログから言える事実と推測を分けて書いてください。
必要なら、次に確認すべきファイル名やコマンドも挙げてください。
状況:
- 何をしていたか
- 直前に変えたもの
- 再現性があるか
ログ:
[ここに全文]
これで足りないなら、たいてい足りないのはログではなく前提情報だ。そこを埋めればいい。逆に、前提があるのにログを貼らないのは、いちばん損する頼み方である。