プロはAIの出したコードの「動いた」をこう見る：本番に入れた2週間後、別の画面で同じ系統のエラーが出た

開発チームの担当者が、エラーの文面を文章を作るAI（LLM）に貼った。返ってきた修正コードを貼ると、プログラムは動いた。

チームは、修正を本番に入れた。

2週間後、別の画面で、同じ系統のエラーが出た。

修正は、確かに効いていた。プログラムは、確かに動いた。

では、動いたあの瞬間、コードの中には何が残っていたのか。

修正コードの正体は、コードの形をした仮説

AttributeErrorの文面を貼ると、LLMは修正コードを一つ返す。返ったコードには、LLMが推した原因が一つ入っている。

カラクリは単純だ。LLMの修正案は、原因についての仮説の一つにすぎない。

観察した事実を説明する仮説を立てる推論を、アブダクション（仮説形成）と呼ぶ。LLMの修正案は、アブダクションの仮説をコードの形にしたものだ。

LLMは、学習したデータから、もっともらしい回答を推し量って返す。古い情報や、バージョン違いの情報も混ざる。

デバッグとは、狭くはプログラムの誤りを見つけて直す作業だ。広くは、テストや性能の調整を含めた問題の洗い出し全般を指す。

動けば採用という使い方は、病名を調べる前に解熱剤を飲み続けるのと同じである。熱は下がっても、熱を出した原因は体に残る。

動いた瞬間に分かったのは、症状が消えたことだけだった。原因は、手つかずのまま残っていた。

動いたコードに、何が紛れ込むか

仮説が外れるだけなら、まだよい。LLMは、架空のメソッドを提案する場合もある。

架空の部品は、メソッドにとどまらない。Spracklenらの研究チームは、16種類のLLMで57万6,000件のコードを作らせた。

存在しない追加部品（パッケージ）を勧めた割合は、平均で商用モデルが5.2%以上、オープンソースのモデルが21.7%以上だった。

架空のパッケージ名は、20万5,474種類にのぼった（USENIX Security 2025）。

開発者も、ほぼ正しいコードの怖さを知っている。Stack Overflowは2025年の開発者調査で、最大の不満を聞いた。

ほぼ正しいが少し違うAIの解決策、を挙げた人は66%。AIが書いたコードのデバッグに時間がかかる、を挙げた人は45.2%だった。

修正まで自動で任せると、危うさは増す。テストを通すことだけを目標に掲げて任せると、合格基準を甘くする修正も、目標の上では正解になる。

動いたという事実は、どれも見分けてくれない。

差がつくのは、修正より先に原因の候補を尋ねる一文

ただし、どのコードも同じだけ調べる必要はない。書き捨ての試作なら、動けば十分な場合もある。

どこまで調べるかは、コードを使う期間と、壊れたときに困る人で決める。本番に入れるコードなら、修正より先に原因を確かめる。

回答の質は、渡す情報で決まる。まず、エラーのメッセージとスタックトレース（エラーに至る呼び出しの記録）を渡す。

再現条件、最小限に切り出したコード、言語とライブラリのバージョンも添える。すでに試して外れた手も書く。

次の文面のかっこの中を、自分の状況に書き換えて使える。

（例：Python 3.9 で Django）を使っています。
エラー：（例：/create_item に POST を送ると、views.py の42行目で AttributeError: 'NoneType' object has no attribute 'id' が出ます）
添付：トレースバックと該当の関数
お願い：原因の候補を、可能性の高い順に三つ挙げてください。候補ごとに調べ方を書いてください。修正コードは、原因を確かめた後に頼みます。

要は最後の一文だ。修正コードを後に回すと、LLMは候補ごとに、何が観察できるはずかを返す。

調べ方の基本は三つ。ログを一行足す、変数の中身を表示する、入力を変えて再現させる。

候補は、一つずつログに当てはめる。外れた候補から消していく。

「直った」と言える三つの点検

修正案が返ってきたら、三点を見る。

1. LLMが挙げた原因が、自分のログやコードと合っているか。
2. 使っているバージョンで動くか。
3. なぜ直るかの説明が、突き止めた原因とつながるか。

三つ目が欠けた修正は、偶然うまくいった可能性を残す。

修正が失敗する入力や状況も、LLMに挙げさせる。挙がった状況は、テストと回帰テスト（直した後に他の機能が壊れていないかの確認）で試す。

エラーが消えたことを示すテストと、原因を突き止めるテストは、別物だ。

2週間後のエラーを防ぐもの

2週間後、別の画面に出た同じ系統のエラー。三つの点検を通す機会は、動いたあの日にあった。

LLMの修正案は、原因についての仮説だ。修正コードより先に、原因の候補と調べ方を出させる。

直ったと言える条件は、人が決める。なぜ直るかの説明が原因とつながったら、回帰テストを足して修正を取り込む。

2週間後のエラーの種は、動いたあの瞬間、すでにコードの中にあった。

出典

• We Have a Package for You! A Comprehensive Analysis of Package Hallucinations by Code Generating LLMs（USENIX Security、2025年）
• 2025 Developer Survey: AI（Stack Overflow、2025年）

この記事の考え方は、拙著『ChatGPT はじめてのプロンプトエンジニアリング』の4章2節、三つの推論パターンをAIで行う部分に書きました。この節を読むと、AIの答えを採用する前に、失敗する理由を問い返して確かめる手がかりを得られるようになります。