前回の続き——「生成」の帰結として間違いは起きる
前回のA-05で、生成AIは検索でも実行でもなく、それらしいトークンを1つずつ選ぶ「生成」の仕組みだと見ました。正しさを保証する工程が、その流れの中に無いという話でした。その当然の帰結として、AIは間違えます。ただし、やみくもに間違えるのではなく、間違い方にはいくつかの型があるのです。この講義では、その型を5つに整理し、次回以降の対処につなげます。
このスライドのポイント
- A-05で見たとおり、生成AIは検索でも実行でもなく、それらしいトークンを1つずつ選ぶ「生成」の仕組み
- 流れの中に「正しさを検証する工程」が無い＝間違いは当然起こりうる
- ただし、間違い方には「型」がある。この講義でその型を5つに整理する
用語の定義——ハルシネーションと文脈
まず、この講義で初めて出てくる2つの言葉を定義します。ハルシネーションとは、実在しないAPIや関数、仕様を、あたかも実在するかのようにAIが生成してしまう現象のことです。A-02で見たAPIのような接続口の名前を、それらしく創作してしまう、といった形で現れます。もう1つ、文脈、いわゆるコンテキストとは、AIがそのやり取りの中で参照できている情報の範囲を指します。会話に含めていない情報は、AIからは見えていません。この2つが、誤りの型を理解する土台になります。
このスライドのポイント
- ハルシネーション: 実在しないAPI・関数・仕様を、あたかも実在するかのように生成してしまう現象
- 文脈（コンテキスト）: AIがそのやり取りの中で参照できている情報の範囲
- 会話に含めていない情報は、AIからは見えていない
なぜ知る必要があるのか
誤りの型を知らないと、二重に困ります。1つは、間違いそのものに気づけないこと。もう1つは、たとえ気づいても、原因が分からず直せないことです。原因ごとに手当ては変わります。情報が足りないなら前提を渡す、知識が古いなら新しい資料を渡す、というように、打ち手が違うのです。型で切り分けられれば、やみくもに同じ指示を繰り返さずに、正しい方向へ手を打てます。
このスライドのポイント
- 型を知らないと二重に困る: ①間違いに気づけない ②気づいても原因が分からず直せない
- 原因ごとに手当ては違う（情報不足なら前提を渡す／古い知識なら新しい資料を渡す）
- 型で切り分けられれば、やみくもに指示を繰り返さずに済む
誤りの5分類（全体像）
誤りを5つの型に整理します。1つ目は情報不足、必要な前提が渡っていない状態で、対処は前提を渡すこと。2つ目は曖昧な仕様、完成の条件がはっきりしない状態で、対処は完成条件を明文化すること。3つ目は古い知識、学習データが過去のものである状態で、対処は最新のドキュメントを渡すこと。4つ目が、先ほどのハルシネーション、存在しないものを生成する状態で、対処は公式ドキュメントで実在を確かめること。5つ目は文脈欠落、関連する情報が会話に入っていない状態で、対処は関連コードを見せることです。
具体例——「ログイン機能を直して」だけでは壊れる
具体例で見ます。既存のアプリに対して、ログイン機能を直して、とだけAIに頼んだとします。AIは、いまのコードがどう書かれているかを知りません。そこで、一般的なログインの実装を、それらしく作って返します。ところが、それは既存の作りと噛み合わず、かえって壊れてしまいます。これは、前提が渡っていない情報不足と、会話に現状コードが入っていない文脈欠落が重なった、複合型の誤りです。
このスライドのポイント
- 依頼: 既存アプリに対し「ログイン機能を直して」とだけ頼む
- AIは現状コードを知らないまま、一般的なログイン実装を生成
- 既存の作りと噛み合わず、かえって壊れる
- 誤りの型: ①情報不足 と ⑤文脈欠落 が重なった複合型
技術サンプルカード——出力を検証する質問集
7枚目は、AIの出力を検証するための質問集です。生成された答えに対して、このAPIや関数は公式ドキュメントに存在しますか、どこに書かれていますか、と実在を確かめます。次に、この書き方はいつ時点の情報ですか、と知識の新しさを確かめます。さらに、いま参照できていない前提があれば挙げてください、と文脈の抜けを確かめます。この3つの質問が、5つの型のどれを潰すのかに、それぞれ対応しています。
混同しやすい概念——「嘘をつく」と「確率的に生成する」
混同しやすいのは、AIが嘘をついている、という捉え方です。正しくは、AIに人を騙す意図はありません。もっともらしい続きを確率的に選んだ結果が、たまたま事実と違っていた、というだけです。ここが実務では大事で、意図の問題ではないので、責めても叱っても直りません。逆に、足りない情報を渡せば直ります。原因は悪意ではなく情報の不足だ、と捉え直すことが、対処の出発点になります。
バイブコーディングでの確認点
バイブコーディングでの確認点です。生成物の中に、見慣れない関数名や設定名があったら、採用する前に実在を確かめてください。エラーが出たときは、直して、とだけ言わず、エラーの文言そのものと現状のコードを渡してから修正を頼みます。A-04で見た差分確認と同じで、AIに丸投げせず、人間が確かめる工程を挟むことが、誤りを実害にしない鍵になります。
このスライドのポイント
- 生成物に見慣れない関数名・設定名があれば、採用前に実在を確認する
- エラーが出たら「直して」だけで頼まず、エラーの文言そのものと現状コードを渡してから修正を頼む
- A-04で見た差分確認と同じく、人間が確かめる工程を省かない
一問一答とまとめ
最後に一問一答です。実在しないAPIを、それらしく出力してしまう現象を、何と呼ぶでしょうか。答えは、ハルシネーションです。30秒でまとめます。AIの誤りには、情報不足、曖昧な仕様、古い知識、存在しないAPIすなわちハルシネーション、文脈欠落の5つの型があり、型ごとに対処が違います。次回は、誤りを減らす側の打ち手として、AIへ渡す情報の種類を整理します。関連資料は、エラー文の読み方、エラー解決プロンプト50、失敗するAIアプリ50です。
このスライドのポイント
- 一問一答: 実在しないAPIをそれらしく出力する現象を何と呼ぶ？ → ハルシネーション
- 30秒まとめ: 誤りは「情報不足・曖昧な仕様・古い知識・存在しないAPI・文脈欠落」の5分類。型ごとに対処が違う
- 次回: 誤りを減らす打ち手として、AIへ渡す情報の種類を整理する
- 関連資料: エラー文の読み方／エラー解決プロンプト50／失敗するAIアプリ50
