生成AIのハルシネーションが開発に混ざるとき｜見つけ方と防ぎ方
生成AIは、事実と違うことを自信ありげに答えることがあります。この「もっともらしい間違い」はハルシネーションと呼ばれ、システム開発では動かないコードや仕様の食い違いとして現れます。この記事では、開発の中でどんな形で現れるのか、どうやって見つけるのか、そして最初から混ざりにくくするにはどうすればよいのかを順に整理します。
ハルシネーションとは何か、開発ではどんな形で現れるか
ハルシネーションとは、生成AIが事実ではない内容を、もっともらしい文章やコードとして出力する現象のことです。大規模言語モデル（LLM）は、学習したデータをもとに「次に来そうな言葉」を組み立てて文章やコードを作ります。そのため、知らないことや曖昧なことについても、空白を埋めるように「それらしい答え」を作ってしまう場合があります。
厄介なのは、間違いが間違いの顔をしていないことです。文章は整っていて、コードも読みやすく、説明も筋が通っています。見た目だけでは判断できないので、開発の現場では「どこに混ざりやすいか」を知っておくことが、確認の効率に直結します。代表的な形を4つ挙げます。
存在しない関数やライブラリを使う
実在しない関数名、設定項目、ライブラリ名をコードに書いてくることがあります。名前の付け方が実在するものに似ているため、読んだだけでは違和感がありません。実行すればエラーで気づけるものが多い一方、使われないまま残る分岐の中に紛れていると、後から問題になります。
また、実在しないパッケージ名を提案された場合に、その名前で悪意のあるパッケージが公開されていると、気づかずに取り込んでしまう危険も指摘されています。コードの動作だけでなく、依存先に何を追加したのかを確認する習慣が必要です。セキュリティの観点はAI生成コードのセキュリティ｜確認点と人の役割でも整理しています。
古い情報や別バージョンの書き方を混ぜる
ライブラリやクラウドサービスの仕様は更新されます。AIが学習した時点の書き方と、今使っているバージョンの書き方が違う場合、すでに廃止された方法や、別のバージョンの書き方がそのまま出てくることがあります。動く場合もあれば、動かない場合もあり、さらに「今は動くが近いうちに使えなくなる」という場合もあります。
仕様を取り違える、都合よく解釈する
要件が曖昧なとき、AIは質問を返さずに、もっともらしい解釈を選んで先へ進むことがあります。たとえば「会員は退会できる」とだけ伝えた場合に、退会後のデータを即時削除する作りにするのか、一定期間残すのかは、本来は事業側が決めることです。AIが一方を選んで作ってしまうと、コードとしては正しく動いても、事業の意図とは違うものができます。
「確認したふう」のテストや説明
テストコードや作業報告にも、間違いは混ざります。何を検証しているのか分からないほど条件が緩く、常に成功するテスト。実際には実行していないのに「テストはすべて通りました」と書かれた報告。変更していない箇所を「修正しました」と説明する文章。こうしたものは、一見すると品質が確保されているように見えるため、他の間違いよりも安心感を与えてしまう点が問題です。
なぜ開発の中では見つけにくいのか
ハルシネーションが開発で見つかりにくい理由は、大きく3つあります。
1つ目は、間違いが「動く」ことです。エラーにならず、画面にも何かが表示されます。しかし、計算の端数処理や権限の判定のように、結果が少しずれているだけの場合、利用者が増えるまで気づけません。
2つ目は、量が多いことです。AIは人よりはるかに速くコードを出すため、確認する側が追いつかなくなります。作る速度が上がった分、確認の設計を変えなければ、見逃しが増える方向に働きます。
3つ目は、説明が上手いことです。AIは自分の出力について、もっともらしい理由を添えます。その説明が正しいかどうかは別の問題ですが、読み手は説明に引っ張られて「そういうものか」と納得してしまいます。
つまり、AIの出力を人が「読んで確認する」だけでは足りません。読む以外の確認手段を、開発の流れの中にあらかじめ組み込んでおく必要があります。
見つけ方：動かす、照合する、疑う
ここからは、混ざった間違いを見つけるための具体的な方法です。ポイントは「AIの説明を信じる前に、実物で確かめる」ことです。
実際に動かして確かめる
最も基本的で、最も効果が高いのは、実際に動かすことです。コードの正しさを文章で議論するより、画面を触り、データを入れ、結果を見るほうが早く確実に分かります。特に、次のような点は実際の操作で確かめます。
- 想定通りの入力で、想定通りの結果になるか
- 空欄、極端に大きい値、想定外の文字など、普通ではない入力でどうなるか
- 権限のない利用者が、見えてはいけない画面やデータに触れないか
- 途中で操作をやめたり、戻ったりしたときに、データが壊れないか
最近は、AIが自作したアプリを自分で操作して動作確認する機能も出てきています（Cursorの新機能、AIが自作アプリを操作して動作確認）。確認の手間を減らす助けにはなりますが、確認の観点を決めるのは人です。何を確かめるのかが曖昧なままでは、「確認したふう」の報告が増えるだけになります。
一次情報と照合する
ライブラリの関数、設定項目、クラウドサービスの仕様のように、外部の事実にもとづく部分は、公式のドキュメントと照らし合わせます。AIが挙げた関数名がドキュメントに載っているか、使っているバージョンの書き方と合っているか、といった確認です。
照合の対象は、次のように絞ると現実的です。
- 新しく追加された外部ライブラリやパッケージの名前と提供元
- 外部サービスのAPIの呼び出し方と、料金や上限に関わる設定
- 認証、決済、個人情報の扱いなど、間違えると影響が大きい部分
すべてを照合するのは現実的ではないため、「間違えたときの影響の大きさ」で優先順位を付けます。
テストの中身を疑う
テストが通っていることと、品質が確保されていることは別の話です。AIが書いたテストは、何を検証しているのかを人が読んで確認します。見るべき点は、期待する結果が具体的に書かれているか、失敗するべきケースで実際に失敗するか、仕様書の内容と対応しているか、の3点です。
テストを意図的に壊してみる方法も有効です。コードの一部をわざと間違った内容に変えて、テストが失敗するかを見ます。失敗しなければ、そのテストは何も守っていません。テスト自動生成の任せ方はAIのテスト自動生成｜任せる範囲と人が見る確認項目で詳しく扱っています。
別の視点でレビューする
同じAIに「間違いがないか確認して」と頼むだけでは、同じ思い込みを繰り返すことがあります。作る役割と確認する役割を分け、できれば別のモデルや別の指示でレビューさせると、見落としが減ります。ただし、AIによるレビューも万能ではありません。AIが指摘しやすい点と、人が判断すべき点の違いはAIコードレビューで指摘される点と人が判断する点にまとめています。
防ぎ方：入力・仕組み・役割分担
見つける努力だけでは限界があります。そもそも混ざりにくくする工夫も、あわせて必要です。
入力：決めるべきことを先に言葉にする
仕様の取り違えは、AIに渡す情報が曖昧なほど起こりやすくなります。次のような情報を、先に言葉にして渡します。
- 誰が、何のために使うシステムなのか
- 今回作る範囲と、作らない範囲
- 判断が分かれやすいルール（退会後のデータの扱い、権限の種類、金額の端数処理など）
- 使うライブラリやサービスの名前とバージョン
「分からないことは推測せず、質問すること」「根拠のない内容は『不明』と書くこと」と指示に入れておくのも有効です。AIは指示がなければ空白を埋めようとするため、空白を埋めずに質問してもらう方向へ誘導します。伝え方の手順はAI開発の仕様の伝え方｜作りたいものを言葉にする手順で整理しています。
仕組み：自動で止まる関門を置く
人の注意力に頼る確認は、疲れや忙しさで抜けます。そこで、自動で検査する仕組みを開発の流れに入れます。
- 型の検査や静的解析（コードを動かさずに問題を見つける仕組み）
- 自動テストが通らなければ次に進めない設定
- 依存ライブラリの追加を検知し、確認なしに取り込まれないようにする仕組み
- 本番環境の情報や機密情報を、AIに渡さない取り決め
機密情報の扱いは生成AI開発の情報漏洩を防ぐ確認点｜機密と事業アイデアで確認できます。
こうした仕組みは、ハルシネーションをなくすものではありません。間違いが混ざった場合に、早い段階で気づけるようにするためのものです。
役割分担：決めるのは人、確かめるのも人
AI駆動開発で重要なのは、「何を作るか」と「品質の最終判断」を人が持つことです。AIは要件の整理、設計、実装、テストの下書きなど多くの作業を速く進めますが、事業の意図に合っているかどうか、リスクを受け入れるかどうかは、AIには決められません。この考え方はAI開発でも品質には人の確認が必要な理由でも触れています。
仕様に照らしてコードが正しいことを確かめる仕組みも登場しています（PDD Kit登場、AIのコードを仕様に照らして証明する）。こうした技術が進んでも、「仕様そのものが事業の意図に合っているか」は人が決める部分として残ります。
新規事業で特に注意したい場面
新規事業では、一般的なシステム開発よりもハルシネーションの影響が大きくなる場面があります。
前例が少ない領域
AIが得意なのは、世の中に例が多い作りです。新規事業のように独自のルールや前例の少ない仕組みを扱う場合、AIは似た例から推測して埋めようとするため、推測が外れる可能性が高くなります。独自のフローや専門性の高い業務ルールは、人が言葉にして渡し、実物で確かめる比重を高めるのが安全です。
決済・認証・個人情報
お金や個人情報に関わる部分は、間違いの影響が大きい領域です。外部サービスに任せられる部分は任せ、自作する部分は、人による確認とテストを厚くします。判断の分け方は新規事業の決済システム開発｜外部サービスと自作の分け方が参考になります。
事業の機能としてLLMを組み込む場合
開発の道具としてAIを使う場合だけでなく、作るシステムの中にLLMの機能を入れる場合にも、ハルシネーションは問題になります。たとえば、利用者の質問にAIが答える機能で、事実と違う回答が出る場合です。この場合は、開発前に「どの程度の間違いなら許容できるか」「間違えたときにどう扱うか」を決め、評価の方法を用意しておく必要があります。進め方はLLMアプリ開発の精度評価｜開発前に決める5つの項目で整理しています。
実物を見ながら確かめる
仕様の取り違えは、文章だけで確認していると見つかりません。動くプロトタイプを作り、事業側の担当者が実際に触ることで、「これは意図と違う」という指摘が早い段階で出ます。AIの出力に混ざった解釈のズレも、実物を触れば見つけやすくなります。進め方はシステム開発の認識のズレを防ぐ、実物を見ながらのすり合わせで扱っています。
まとめ
生成AIのもっともらしい間違いは、存在しない関数、古い書き方、仕様の取り違え、確認したふうのテストという形で、開発の中に混ざります。見た目が整っているため、読むだけでは気づけません。そのため、次の3つを組み合わせて備えます。
- 見つける：実際に動かす、公式の情報と照合する、テストの中身を疑う、作る役と確認する役を分ける
- 防ぐ（入力）：決めるべきことを先に言葉にし、分からないことは質問してもらう
- 防ぐ（仕組みと役割）：自動検査の関門を置き、何を作るかと品質の最終判断は人が持つ
ハルシネーションを完全になくすことは、現時点では難しいとされています。大切なのは、混ざる前提で開発の流れを組み立てることです。
私たちJustFitは、構想をもとに約1ヶ月で動くプロトタイプを先に作る受託開発サービスです。複数の専門AIが役割を分けて進める独自の開発基盤「LAF」を使い、人は何を作るかの決定と品質の最終判断を担います。実物を見ながら確かめられる進め方で、AIの出力に混ざるズレを早い段階で見つけやすくしています。詳しくはJustFitのサービス紹介をご覧ください。