AIが生成したコードをそのまま実行したら、エラーが出た。コードを見ても問題は見当たらない。でも動かない。——それ、あなたのせいじゃない可能性がある。
そのエラー、あなたのせいじゃない
バイブコーディングを始めた人の多くが最初につまずく壁に「AIが書いたコードが動かない」というものがある。エラーメッセージが出て、自分の設定が悪いのか、インストールを間違えたのか、と悩む。しかし犯人はAI自身だったというケースが、想像以上に多い。
AIが「存在しないAPIやパッケージを生成してしまう」現象を「ハルシネーション（幻覚）」と呼ぶ。もともとは医学用語で、実際には存在しないものを知覚してしまう症状を指す。AIコーディングの文脈では、実際には存在しない関数名・メソッド名・パッケージ名を、さも本物のように生成してしまうことを指す。
厄介なのは、AIが「わからない」と言わないことだ。「prisma.$upload() を使ってください」と、公式ドキュメントを調べてきたかのような口調で書く。自信の強さは正確さの保証にはならない。これはアナウンサーが流暢に台本を読み上げるのに似ている。読み方が完璧でも、台本に架空の単語が混じっていても、迷いなく読み上げてしまう。
AIが生成するコードでエラーが出たとき、最初に疑うべきはAIが架空のAPIを呼んでいないかどうかだ。「自分の設定ミス」と決めつける前に、この記事で紹介する診断法を試してほしい。
なぜAIは存在しないコードを書くのか
AIは「正解を知っている」のではなく、「それらしいコードを統計的に生成する」仕組みで動いている。膨大なコードデータを学習し、「このような文脈ではこういうコードが続く」というパターンを学ぶ。
問題はここにある。まず、学習データには「カットオフ」がある。AIが学習したのは特定の時点までのデータだ。それ以降にリリースされたバージョンや、大幅に変更されたAPIのことは知らない。10年前の地図を持ったナビゲーターが、取り壊されたビルに「ここに進んでください」と案内するのと同じだ。
次に、AIは「パターンに合う見た目」のコードを生成する。たとえばPrismaの文脈で prisma.something() の形を生成するとき、「somethingが実際に存在するかどうか」は考慮されない。コードの見た目として自然かどうかで生成される。試験当日に問題集が変わったのに、古い問題集しか知らない状態で答えているようなものだ。
2025年に発表された数学的研究により、現在のLLMアーキテクチャの下ではハルシネーションは構造的に不可避であることが示されている（Trend Micro - The Mirage of AI Programming）。RAGや人間によるレビューで削減はできるが、ゼロにはならない。
また、「2025年のライブラリを使って」というプロンプトを与えると、最大84%のタスクで架空のライブラリが生成されたという研究もある（arXiv 2509.22202）。16種類のAIモデルを調査した結果、パッケージハルシネーションがゼロのモデルは一つも存在しなかった（USENIX - We Have a Package for You）。
3種類のエラーパターン
ハルシネーション由来のエラーには、いくつかの典型的なパターンがある。順番に見ていこう。
パターン1：APIが廃止・変更されている
OpenAI Python SDKはv1.0.0で大幅な破壊的変更を行った。古い書き方と新しい書き方で、まったく異なるコードになる。
# ❌ AIが生成しがちな古い書き方（openai < 1.0.0 時代）
import openai
response = openai.ChatCompletion.create(
model="gpt-3.5-turbo",
messages=[{"role": "user", "content": "Hello"}]
)
# → AttributeError: module 'openai' has no attribute 'ChatCompletion'
# ✅ 現在の正しい書き方（openai >= 1.0.0）
from openai import OpenAI
client = OpenAI()
response = client.chat.completions.create(
model="gpt-4o",
messages=[{"role": "user", "content": "Hello"}]
)
このエラーはOpenAIコミュニティに多数のスレッドが立つほどの混乱を引き起こした（OpenAI Community - TypeError: openai.createCompletion is not a function）。AIツール（ChatGPT自身を含む）が古い構文を推薦し続けたためだ。
解決策は openai migrate コマンドの実行、または手動で client.chat.completions.create() に書き直すことだ（OpenAI Community - openai.ChatCompletion error）。
パターン2：存在しないメソッドを呼んでいる
TypeScriptアプリ開発でよく使われるPrismaというデータベースライブラリに関連した事例がある。
// ❌ AIが生成した架空コード（prisma.$upload は存在しない）
const result = await prisma.$upload({
bucket: "avatars",
file: imageBuffer,
});
// → TypeError: prisma.$upload is not a function
// ✅ Supabase Storageを使った正しい実装
import { supabase } from "@/lib/supabase";
const { data } = await supabase.storage
.from("avatars")
.upload(fileName, imageBuffer);
prisma.$upload というメソッドはPrismaに存在しない。しかしコードとして見た目が自然なため、コードレビューの知識がない人には気づきにくい（31 Days of Vibe Coding - When AI Hallucinates）。同じ調査では @prisma/cache という存在しないパッケージパスも生成された。
パターン3：架空のnpm/PyPIパッケージを使っている
最も見分けにくいパターンだ。存在しないパッケージをインストールしようとしてエラーが出る。
// ❌ AIが生成した架空パッケージ参照
import Stripe from "@stripe/stripe-js/v4";
// → npm install 時に「npm error 404 Not Found」
// ✅ 実際のStripe.js（npmで確認済み）
import { loadStripe } from "@stripe/stripe-js";
オープンソースのAIモデルが推薦するパッケージの21.7%が架空（存在しないnpm/PyPIパッケージ）だという調査がある。商用モデルでも5.2%が架空パッケージを参照していた。756,000件のコードサンプルを検証した結果、約20%で存在しないパッケージが推薦されていた（USENIX - We Have a Package for You）。
さらに、同じプロンプトを10回繰り返した場合、架空パッケージが43%の確率で再出現する（Dark Reading）。AIが「このパッケージは存在する」と確信しているかのような一貫性で生成し続けるのだ。
架空パッケージが本物の罠になる
架空パッケージには、エラーで終わらないケースがある。
セキュリティ研究者のSeth Larsonが命名した「スロップスクワッティング（slopsquatting）」という攻撃手法がある。攻撃者が「AIが繰り返し生成する架空パッケージ名」をPyPIやnpmに先行登録し、悪意のあるコードを仕込んでおく手口だ（Trend Micro - Slopsquatting）。
タイポスクワッティング（人がタイプミスする名前を先取りする古典的手口）の派生概念だ。AIが同じ架空パッケージ名を繰り返し生成するなら、そのパッケージ名を先に登録してしまえばいい。npm install ai-suggested-package と実行した瞬間、マルウェアがインストールされる。
オープンソース開発者のSimon Willisonは「コードのハルシネーションはLLMのミスの中で最も危険度が低い」と述べている（simonwillison.net）。理由は「コードを実行した瞬間に、架空のメソッドは即座にエラーとして明らかになる」からだ。これは正しい。
しかし架空パッケージのスロップスクワッティングは話が別だ。パッケージをインストールする時点ではエラーが出ないまま悪意あるコードが入り込む可能性がある。エラーが「出る」ものと「出ない」ものを区別して理解しておく必要がある。
ハルシネーションか、設定ミスか：診断フロー
エラーが出たとき、まずどう動くかのフローを整理しておこう。
新しいパッケージを npm install する前にも一手間かける必要がある。インストール前にパッケージ名を npmjs.com または pypi.org で検索し、実在を確認する。この1分の確認がスロップスクワッティングを防ぐ。
5つの実践習慣
ハルシネーションはゼロにならない。だから「起きた後の対処法」だけでなく、「起きにくい指示の出し方」と「早期発見の習慣」を組み合わせるのが現実的だ。
1. バージョンを明示したプロンプトを使う
# ❌ 曖昧なプロンプト
「OpenAI APIを使って文章を要約するコードを書いて」
# ✅ バージョン指定プロンプト
「openai Python SDK バージョン1.0以上を使って、
client.chat.completions.create() で文章を要約するコードを書いて」
バージョンを指定することで、AIが古い構文を使う確率を下げられる。ライブラリ名だけでなく、使っているメソッドの名前まで指定するとさらに効果的だ。
2. 10行ずつ動かす
大量のコードを一度に生成して実行するのではなく、小さな単位で生成して都度動作確認する。エラーが出たとき、どこが原因かをすぐに特定できる。バイブコーディングの爽快感は減るが、デバッグに費やす時間は大幅に減る。
3. 初めて使うパッケージ名は必ずnpmかPyPIで確認する
AIが提案したパッケージ名をそのまま npm install しない。必ず npmjs.com か pypi.org で実在を確認してからインストールする。スロップスクワッティング対策としても必須の習慣だ。
4. 公式ドキュメントを副画面で開く
使っているライブラリの公式ドキュメントをブラウザで開いたまま作業する。AIが提案したAPIが実在するかどうかを都度確認する。ほとんどのライブラリはドキュメントサイトに検索機能があるので、メソッド名を検索するだけで数秒で確認できる。
5. エラーはすぐAIに投げ返す
「エラーが出た。自分の設定が悪いのかもしれない」と悩む前に、エラーメッセージをそのままAIにコピーして「このエラーが出ている。バージョン○○の正しい書き方を教えて」と聞く。AIは自分のハルシネーションに気づけないことも多いが、エラーを見て修正を提案できることが多い。
AIを信頼するな、使いこなせ
ハルシネーションはAIの欠陥ではなく、仕組み上の特性だ。AIは「正確な情報」を検索して返すのではなく、「確率的に自然な出力」を生成する。この違いを理解した上で使うのと、知らずに使うのでは結果がまったく変わる。
「最新APIの正確な仕様」はAIの苦手領域だと知った上で、公式ドキュメントと組み合わせて使う。AIに「コードの骨格」を作ってもらい、メソッドの実在確認は自分で行う。この役割分担が、バイブコーディングの先にある「Ship Coding」への入口だ。
エラーが出たとき、真っ先に「自分のせいかもしれない」と考えるのをやめることから始めよう。「AIが架空のコードを書いた可能性がある」という視点を持つだけで、デバッグにかかる時間は大きく変わる。