$ — 聴く教室、開講中 —
~/episodes/ep10 — now playing

$ play ep10 — だい10かい の授業

#10 エラーが出た。どうする?— 詰む人と進む人の分かれ道

2026.08.29 | 23:01

#10 エピソードアート
きょうの持ち帰りエラーは故障じゃなくて、ただの報告。自分で読まずにそのままAIに渡して、直したら「直ったか確認して」まで言う。

まず結論

エラーが出た。じゃあどうするか。ひとことで言うと——

エラーの内容は自分で読まずに、そのままClaude Codeくんに渡す。

赤い文字の英語を、あなたが解読する必要はありません。「こういうのが出たよ」とそのまま見せるだけです。

そしてもうひとつの大事な結論。エラーの正体は「故障しましたよ、というお知らせ」ではなく、「いま、こういう理由で止まってます」というただの報告です。エラーが表示されるということは、何が問題なのかを機械がわざわざ文章で説明してくれているということ。いちばん怖いのは、エラーも出さずに黙って変なことになるパターンのほうで、それと比べるとエラー表示はだいぶ親切寄りの現象です。

よくある3つの誤解

  1. 「エラーが出た=何かが壊れた、ってことでしょ?」 — 実際は逆で、エラーの多くは「何かが壊れる前に止まりました」の合図。炊飯器が「お米が入ってません」と表示して止まっているのと同じで、条件が揃っていないから、変なことになる前に止まってくれている状態です。
  2. 「エラー文は英語だから、英語ができないと無理でしょ?」 — エラーの文章を読むのはAIの仕事。しかもClaude Codeの作業中に出たエラーは、Claude Codeくん自身が先に把握していて、あなたが報告するまでもなく「原因はこれなので、こう直します」と動き出すことも多い。あなたの英語力の出番が、そもそもありません。
  3. 「エラーが出るのは、自分の頼み方が悪かったせいでしょ?」 — プロのエンジニアも、毎日エラーを出しています。プログラムの世界は「書いて→動かして→エラーが出て→直して」の繰り返しが標準サイクルで、エラーは失敗の烙印ではなく通常サイクルの中のただの1工程。料理の味見と同じで、味見して直すのはプロと同じ進め方です。

エラーの正体は「報告書」

エラーの赤い文字は、決まった型で書かれた報告書です。中身はだいたいこの3点セット。

  • どこで」止まったか
  • なにが」原因か
  • どうすれば」いいかのヒント

電車の遅延のお知らせ(「どこどこ駅で、何々のため、運転を見合わせています」)と同じ書式です。あのお知らせでパニックにならないのは、「いつもの状況報告」だと知っているから。エラーも同じで、英語と専門用語で書かれているから怖く見えているだけです。

そしてこの報告書は、あなたが自分で読まなくていい。遅延情報の読み解きは駅員さん(Claude Codeくん)に任せて、「で、私はどうすればいいですか?」と聞けばいいだけです。

エラーが出たときの3手

1手目: 深呼吸して、何も押さない

ふざけているようで大真面目。エラーの文章は貴重な報告書なので、消してはいけません(現場保存)。ボタン連打・意味のない再起動・画面を閉じて見なかったことにする——は全部、報告書を破り捨てながら「何が起きたかわからない」と言っている状態です。特に再起動は、報告書が消えるだけで原因はそのまま残るので、だいたい同じエラーにもう一度遭遇します。

2手目: そのままClaude Codeくんに渡す

Claude Codeとの会話の中で出たエラーなら、この一言だけで大丈夫。

エラーが出たみたいだけど、どういうこと?

Claude Codeの外(普段使っているアプリなど)で出たエラーは、文章をコピーして貼り付けて聞きます。

これが出たんだけど、何が起きてるか教えて?

大事なコツはひとつだけ。エラーの文章を要約せず、全文そのまま渡すこと。 親切心で「なんとかっていうエラーが出て〜」と自分でまとめると、報告書の大事な部分が抜け落ちます。「なんか赤い文字でエラーが出て動きません」だけだと「どんなエラーでしょうか?」の往復が1回増える。現物を運ぶだけの配達員に徹するのが、いちばん賢いやり方です。

3手目: 説明させてから、直させる

Claude Codeくんはサッと直そうとしてくれますが、ここで一言挟みます。

直す前に、何が起きてたのか、わたしにもわかるように説明して

理由は2つ。同じエラーに次に出会ったとき「あ、あれね」と自分で気づけるようになること。そして、説明をさせるとClaude Codeくん自身の直し方も的確になることが多いことです。

いちばん大事な「直った」の確かめ方

Claude Codeくんの「直しました」は、正確に言うと「直したつもりです」。人間の仕事でも「修理しました」の後には必ず動作確認があります。なので、エラー対応の締めくくりはこの一言です。

直ったかどうか、確認して見せて

もとの作業をもう一回やらせてみて、今度はエラーなく通ることを見届けて、できれば結果の中身もチラッと見る。集計表なら「もう一回、集計を最後まで実行してみて」と言って完走を見届け、数字を1箇所だけでも検算してみる。ファイル整理なら、整理後のフォルダを自分の目でざっと眺めてみる。かける時間は1〜2分で十分です。

大事なのは時間の長さではなく、「『直したつもり』と『ほんとに直った』は別物」という区別が自分の中にあるかどうか。この区別が持てれば、AIとの仕事で大きい事故を起こすことはなくなります。

確認してもダメだったら: 「戻る」がある

そのときは第9回の「Git」の出番。

一旦、セーブした時点に戻して、別のやり方を考えよう

エラーが起きる前の状態に戻れるから、エラーを深追いする必要がありません。ドツボにハマるのは「戻る」という選択肢を忘れているときなので、「エラーを直すか、元の状態に戻すか、いつでも選べる」を覚えておいてください。

エラーが怖くなくなると、行動範囲が変わる

エラーに怖さを抱えている人は、エラーが出なさそうな小さくて無難なお願いしかしなくなります。怖くない人は「うまくいってなかったらエラーが出るから、そのとき何とかしよう」とどんどん新しいことを試せる。海外旅行で「迷ったら翻訳アプリで聞けばいいか」と思えるとホテルから離れた路地裏まで歩けるのと同じで、同じClaude Codeを使っていても、この一点で行動範囲が全然違ってきます。

エラーの文章をそのまま渡す。説明させる。直させる。自分で確かめる。ダメなら戻る。——これさえ押さえれば、好きな方向にどんどん進んでいけます。

~/next-steps