第4回 ハルシネーション — 出ない前提ではなく、出る前提で確認する

この回のキーメッセージ

情報漏洩だけがセキュリティではない。誤情報を業務で使うことも事故になる。

このシリーズでは、誤情報・数値間違い・AIの推測に基づく誤った意思決定までを含めて「安全な業務利用」と呼んでいる。ここからは ④回答は正しいか・⑤使ってよいか の話になる。

1. ハルシネーションとは、もっともらしい誤りのこと

事実ではない内容・根拠のない内容を、それらしく回答してしまう現象。日本語では「幻覚」と訳される。

AIが悪意を持って嘘をつくのではない。文脈から次に来る言葉を選んで、その場で文章を組み立てている から起きる。予測変換がとてつもなく賢くなった状態を思い浮かべるとよい。予測変換は、事実かどうかを判断していない。

ここで「AIは検索していない」と単純化するのは誤りになる。現在の業務AIは言語モデル単体ではなく、社内データの検索、意味的な索引、Web検索、計算機能などを組み合わせている。正確な言い方はこうなる。

根拠を検索したり計算機能を使ったりする場合もあるが、最終的な回答には生成処理が含まれるので、誤りは残る。

現れ方は主に3つ。

• 架空の引用 — 実在しない出典・条文・判例をそれらしく作る
• 意図の取り違え — 指示と微妙にずれた要約が返る
• 計算の誤り — 集計や単純な計算を間違える

計算機能を使う場合もあるが、数値は表計算の数式や原本で再計算する のが確実な対処になる。

2. 根拠があるかどうかは、文面からは分からない

回答が出るまでの流れを分解する。

1. 質問 — 利用者が依頼を入力する
2. 材料を探す — 社内データ・索引・Web検索など複数の経路から探しに行く
3. 不足を補う — 材料が足りない部分も、文章としては自然な形で埋まってしまうことがある
4. 自然に読める — 出来上がった文章として提示される

決定的なのは4番目だ。正しい部分と誤っている部分で、文体は変わらない。自信のなさそうな書き方にはならない。だから読んだだけでは見分けられない。

文章の自然さは、正しさの証明にはならない。

つまり「ハルシネーションが出ないようにする」ではなく、「出る前提で確認する」 という考え方をとる。仕組み上の性質であって、故障ではない。

3. 誤りは主に4つの場面で発生する

無作為に起きるわけではない。条件が分かっていれば、頼み方の側で減らせる。

場面	何が起きるか	よくある依頼文
① 情報がない	参照できる資料がなく、推測で埋める	「昨年度の大阪イベントの参加者数を教えて」
② 指示が曖昧	何を出すかが定まらず、的外れな要約になる	「この案件についてまとめて」
③ 元資料が誤り	元データが間違っていれば、正しく読んでも回答は誤る	（依頼文の問題ではない）
④ 材料が不足	判断に必要な情報が揃わないまま結論を出す	「この見積は妥当ですか」

③は性質が違う。元のExcelで売上が1,000万円と誤記されていれば（実際は100万円）、AIは元資料を正しく読んでいる。この場合AIは仕事をしている。AIの精度をいくら見ても防げず、元データの品質という別の問題 になる。

②の改善例を挙げると差が分かりやすい。「この案件についてまとめて」では売上・納期・課題・リスク・顧客要望のどれを求めているか定まらない。「添付した案件管理表のみを参照し、案件名・売上・原価・粗利率・納期を一覧にしてください」なら、出力が何であるべきかが決まる。

④も同じで、「この見積は妥当ですか」は、過去見積・市場価格・原価・粗利・契約条件がなければ判断材料そのものが存在しない。

4. 照合するのは4種類だけ

回答の全文を読み直すのは現実的ではない。影響の大きい4種類に絞って原本と照合する。

1. 数字 — 金額、件数、日付、率。原本で再計算する
2. 固有名詞 — 会社名、人名、製品名、部署名
3. 出典 — 参照元が実在するか、リンク先の中身が主張と一致するか
4. AIの推測 — 元資料に書かれていない評価・断定が付け加わっていないか

4つ目が最も見落とされる。文章として自然に読めてしまい、原本にない評価だと気づきにくい。たとえば採用の要約で、候補者について「コミュニケーション能力が低い」といった、元資料のどこにも書かれていない評価が付いていることがある。

ここでも AIには整理までを任せ、判断は人が行う という分離が効く。

5. 確認は4つの手順で足りる

前節が「何を見るか」で、こちらが「どの順番で見るか」。

1. 抜き出す — 回答から数字・固有名詞・出典・推測を拾い出す
2. 原本と照合する — 元資料に当たって突き合わせる
3. 出典を確認する — 示された参照元を開き、中身を確かめる
4. 未確定を残す — 確認できなかった項目は「要確認」と明記して残す

手順を固定する理由は、確認が面倒だと省かれるから。順番が決まっていれば短時間で回せる。

4つ目が効く。不明な項目を空欄のまま流すと、後工程の誰かが確定情報として扱ってしまう。「要確認」と書いて残せば、後から追える。

6. 確認の強度は業務影響と対外性で決める

全部を同じ強さで確認する必要はない。誤ったときの影響と、社外に出るかどうかの2軸で分ける。

	社内で完結	社外に出る
影響が小さい	社内アイデア出し → 軽く目を通す	社外向け文書の下書き → 固有名詞と数字を照合
影響が大きい	社内の数値報告 → 数字を原本で再計算	見積・契約・採用 → AIは下書きまで。決めるのは必ず人

右上（影響が大きく社外に出る）は、AIに下書きまで任せても、決めるのは必ず人 という切り分けにする。社内規程が別の基準を定めていれば、そちらが優先される。

7. 検証しやすい回答は、依頼文で作れる

プロンプトはAIを上手に操るテクニックではなく、人が検証しやすい回答を作るためのリスク低減策 と捉える。

同じ資料を渡すにしても、依頼文をこう変えるだけで差が出る。

	Before	After
依頼文	「この見積書について分析してください」	「添付した見積書のみを参照し、顧客名・金額・納期・支払条件を一覧にしてください。記載のない項目は推測せず『要確認』としてください。金額と日付は参照箇所を示してください」

変わっているのは5点だ。情報源の限定 / 出力対象の限定 / 推測の禁止 / 不明時の処理 / 根拠の明示。回答の巧拙ではなく、この5点の差が検証コストを下げる。

文例を増やす必要はない。5つの型を場面に応じて組み合わせる だけで足りる。

型	そのまま使える表現
情報源を限定する	「添付資料のみを参照してください」
推測を禁止する	「記載されていない内容は推測しないでください」
不明時の扱いを決める	「不明な項目は『要確認』としてください」
根拠を明示させる	「金額・日付・固有名詞は参照箇所を示してください」
役割を分離する	「判断ではなく、確認事項の抽出まで行ってください」

最後に留保を付けておく。これを書けばハルシネーションがゼロになるわけではない。確率を下げ、残った誤りを見つけやすくする工夫だ。

→ 前: 第3回 Shadow AI ｜ 次: 第5回 権限と過剰共有