生成AIの「ハルシネーション」に要注意：モデル調査で実際にあった3つの間違い
生成AIに調べ物を任せると、驚くほどスムーズに答えが返ってきます。ただし、その答えが「もっともらしい嘘」であることも少なくありません。これがいわゆる「ハルシネーション」です。
今回は、実際に技術調査でAIに依頼した際に遭遇した3つの誤りを紹介しながら、ハルシネーションの種類、ビジネス上のリスク、そしてどう向き合えばよいかをまとめます。
ハルシネーションとは何か
ハルシネーションとは、AIが事実に基づかない情報を、あたかも正しいかのように生成してしまう現象です。文章の口調が自信ありげで、根拠らしきものまで添えてくることがあるため、受け取る側が誤りに気づきにくいのが厄介な点です。
特に「調べ物」の場面では、そのまま鵜呑みにしてしまうと後工程に響くため注意が必要です。
ハルシネーションの3つのタイプ
一口にハルシネーションと言っても、起きる原因や現れ方にはいくつかパターンがあります。実例を紹介する前に整理しておきます。
- 捏造型：世の中に存在しないもの（製品バリエーション、数値、文献など）を、いかにも実在するかのように作り出してしまうタイプ。実例①がこれに当たります。
- 混同型：似た名前・似た性質のものを取り違えて、別のものの情報を答えてしまうタイプ。ライセンス名は似た単語が多く、特に混同が起きやすい領域です。実例②がこれに当たります。
- 自己検証エラー型：一度出した誤りに気づけず、検証しないまま似たような誤りを繰り返すタイプ。エラーが出ても「原因はこれのはず」と別の誤答を重ねてしまいます。実例③がこれに当たります。
タイプによって効果的な対策が変わるため、後半の対策パートもこの分類に沿って紹介します。
実例①：存在しないパラメータ数のモデルを回答された（捏造型）
あるモデル（Gemma）について、どんなパラメータ数のバリエーションがあるか、そしてライセンスはどうなっているかをまとめて調査してもらったことがありました。
返ってきた回答は非常に整った表形式で、「7B」「27B」といった実在するラインナップに混ざって、「32billionパラメータのモデルもラインナップされている」という一文がさらっと添えられていました。数字が具体的で、他の情報と並んでいると違和感を覚えにくく、そのまま資料に転記しそうになった場面です。
念のため公式のモデルカードやリリースノートを確認したところ、該当するパラメータ数のモデルはどこにも存在しませんでした。おそらく、既存のラインナップの数字の並びから「ありそうな中間サイズ」を推測して埋めてしまったのだと思われます。実在する情報の中に一つだけ嘘が混ざっていると、全体の信頼性につられて見逃しやすいという典型的なパターンでした。
実例②：ライセンスの誤答（混同型）
要件として「Apache 2.0のライブラリのみ使用する」と決めていたにもかかわらず、AIに調査を依頼したライブラリのライセンスを確認したところ、実際にはGNU系のライセンスだったというケースもありました。
このときの回答は「〇〇ライブラリはApache 2.0ライセンスで提供されており、商用利用も制限なく可能です」という、根拠込みで断定的な言い回しでした。実際にリポジトリのLICENSEファイルを開いてみると、GPL系の記載になっており、要件と真っ向から矛盾していました。
似たようなオープンソースライセンスは名称や条文の構造が似通っているため、AIが学習の過程で混同しやすい領域だと考えられます。数値の誤りと違って、ライセンスの誤答は法務・コンプライアンス上のリスクに直結する点で、より深刻です。
ライセンス誤答が招くビジネスリスク
ライセンスは「間違えました」では済まされないケースがあります。特にApache 2.0のような寛容型（permissive）ライセンスと、GPL系のようなコピーレフト型ライセンスでは、求められる義務が大きく異なります。
- Apache 2.0：改変や商用利用が自由で、自社コードに組み込んでもソースコードを公開する義務はありません。
- GPL系（コピーレフト）：そのライブラリを組み込んだソフトウェアを配布する場合、原則として自社側のソースコードも同じライセンスで公開する義務が発生します（いわゆる「ライセンスの伝播」）。
もし「Apache 2.0だから大丈夫」という誤った回答を信じたまま製品に組み込み、そのまま社外に配布してしまうと、本来公開義務のないはずの自社ソースコードを公開する義務を負ってしまったり、契約上の要件（クライアントとの「Apache系のみ使用」という取り決めなど）に違反してしまったりするリスクがあります。後から気づいて差し替えるとなると、該当ライブラリへの依存を洗い出して置き換える手戻りコストも発生します。数値の誤りは「訂正すれば済む」ことが多い一方、ライセンスの誤りは「気づいた時にはもう配布済み」という取り返しのつきにくさがある点を覚えておく必要があります。
実例③：存在しないバージョンをpip installし続けるループ（自己検証エラー型）
さらに厄介だったのが、存在しないバージョンのライブラリをずっとpip installしようとし、エラーが出ても別の存在しないバージョンを提案し続け、いつまでも失敗ループから抜け出せなくなったケースです。
流れとしては、こちらが「〇〇のバージョン依存でエラーが出ている」と伝えると、AIが「では、このバージョンを指定してインストールしましょう」と特定バージョンを提案してくる → 実行すると ERROR: No matching distribution found for のようなエラーが返る → それを伝えると、AIは「失礼しました、それでは別のバージョンで」とまた存在しないバージョン番号を提案してくる、という繰り返しでした。
AI自身は毎回「今度こそ解決するはず」という自信ありげなトーンで提案してくるため、何回か繰り返されるまで「そもそも存在しないバージョンを言われ続けている」ことに気づきにくいのが特徴です。一つ前の実例と違い、これは単発の誤りではなく、検証しないまま誤りを重ね続ける点に本質的な問題があります。実際にpip index versionsのようなコマンドで存在するバージョン一覧を確認させれば一発で解決する話なのですが、AIが自発的にその確認ステップを踏まなかったために発生したループでした。
なぜこうした誤りが起きるのか
生成AIは、学習データの傾向から「もっともらしい続き」を予測して文章を生成する仕組みです。存在する製品や数字のパターンに似せて、実在しないバージョンやスペックをそれらしく作り出してしまうことがあります。特に、リリース直後の新しいモデルや、マイナーな情報ほど学習データが薄く、誤りが起きやすい傾向があります。
また、AIは基本的に「その場で外部の一次情報を確認せずに、記憶（学習済みの知識）から答える」ことがデフォルトの挙動です。ツールを使って検索・実行確認をさせない限り、誤りに気づく機会自体がないという構造的な問題もあります。
対策：タイプ別に鵜呑みにしないための工夫
捏造型・混同型（実例①②）への対策
- 一次情報にあたる：モデルのスペックやライセンスなど重要な情報は、公式サイトやGitHubリポジトリ、ライセンスファイルなど一次情報で必ず裏を取る
- 数値・法的情報は特に慎重に：パラメータ数やライセンスのような「間違えると影響が大きい情報」は、AIの回答だけで判断しない
- 根拠・出典を出させる：「その情報の出典はどこですか、該当箇所を引用してください」と聞き返すことで、AIが実在しない情報を作っていないか確認しやすくなる
自己検証エラー型（実例③）への対策
- 同じ提案が繰り返されたら一旦止める：pip installのループのように、似た失敗が続く場合はAIの提案を鵜呑みにせず、自分で公式のバージョン一覧やリリースノートを確認する
- 確認コマンドを先に実行させる：「インストールを試す前に、まず存在するバージョン一覧を確認して」と明示的に指示することで、存在しないバージョンを提案されるリスク自体を減らせる
Claudeを使う上での具体的なテクニック
- Web検索機能を明示的に使わせる：「最新の公式ドキュメントをWeb検索で確認したうえで回答して」と伝えることで、学習データだけに頼った回答より精度が上がる
- 公式ドキュメントを直接読ませる：URLやライセンスファイルの中身を貼り付けて「この内容だけを根拠に答えて」と指示すると、記憶からの推測ではなく手元の情報を根拠にした回答になる
- 「わからなければわからないと言って」と明示する：これだけで、曖昧な情報を無理に埋めようとする挙動が減ることがある
- 回答の自己検証をもう一段挟む：「今の回答を、公式情報と照らし合わせてもう一度確認して。矛盾があれば訂正して」と追加で聞き返すことで、一度目の回答に紛れ込んだ誤りに気づけることがある
- Claude Codeのようにコマンド実行できる環境では、確認コマンドを先にやらせる：
pip index versionsのような存在確認コマンドを先に実行させてから対応させることで、存在しないバージョンをそもそも提案されにくくなる
まとめ
生成AIは調べ物を大幅に効率化してくれる一方で、自信満々に誤った情報を返してくることがあります。誤りには「捏造型」「混同型」「自己検証エラー型」といったパターンがあり、特にモデルのスペックやライセンスなど後工程に影響する情報は、AIの回答をそのまま採用せず、一次情報での確認を習慣にすることが大切です。Claudeのようなツールを使う場合も、Web検索や一次情報を根拠にさせる指示を挟むことで、こうしたリスクはかなり減らせます。
