AIが間違えたとき、誰が気づくのか──KPMGレポート撤回から考えるハルシネーション統制の設計

KPMGとEYが相次いで撤回した理由──「確認する人間がいなかった」

KPMGの「エージェント型AI時代の卓越性を再定義する」と題したレポートには、AIが各社のAI活用状況を説明する記述が複数含まれていましたが、UBS、英国NHS、スイス連邦鉄道、ロンドン交通局から次々と「内容が不正確または誤解を招く」と否定されました。

AIリサーチグループGPTZeroがレポートの多数の不正確さを特定し、ファイナンシャル・タイムズが報道しました。これを受けKPMGはレポートを撤回し、「人間による監視を含む責任あるAI利用ガイドラインに従うことを改めて確認する」とコメントしています。

注目したいのは、この問題がKPMG一社に限らなかったことです。同時期にEYも、同様の理由でAI関連レポートを撤回しています。大手コンサルティング2社が相次いで同じ失敗をした。AIが生成したコンテンツを確認せずに公開するという慣行が、業界に広がっていたことを示しています。

このコメントを読んで、私は少し考え込みました。「人間による監視を含む」——その人間監視が機能しなかったから撤回したわけですから、「改めて確認する」とはどういうことなのか。おそらくは、公開前に十分な確認が行われなかった、ということでしょう。優秀なプロフェッショナルが集まる組織でも、AIの出力を「確認する仕組み」がなければ、誤情報は見逃されます。

私たちが現場で受ける相談の中でも、これに近い話は珍しくありません。「AIで作った資料をそのまま上司に送ってしまった」「AIが生成した数値が間違っていて、会議で指摘されて恥をかいた」——こういった経験を持つ担当者は、想像以上に多くいます。規模が大きくなれば、それが対外的なレポートになる。KPMGの事例は、対岸の火事ではありません。

では、なぜこういったことが起きるのか。ハルシネーションの仕組みから整理します。

「嘘をついている」わけではない──AIハルシネーションの仕組み

まず、誤解を解いておきたいことがあります。AIはわざと嘘をついているわけではありません。AIハルシネーションとは、生成AIが事実と異なる情報を自信を持って出力する現象のことですが、これはAIの設計上の特性から必然的に起きます。

生成AIの大規模言語モデル（LLM）は、大量のテキストから「次にどんな言葉が来るか」の確率を学習することで動いています。質問に対して「もっともらしい答え」を生成するのが得意ですが、「正確に確認してから答える」という動作はしません。辞書や知識データベースを引いているのではなく、確率的に「それっぽい文章」を組み立てています。

だから、存在しない論文の著者名を自信を持って答えたり、実際には行われていないAI活用事例を流暢に語ったりします。「嘘をついている」のではなく、「正確に確認せずに作っている」のです。

特にハルシネーションが起きやすいのは、以下のような場面です。

• 固有名詞と数値: 人名・社名・統計数値は、もっともらしく作られやすい
• 最新情報: 学習データにない直近の出来事は「推測」で補完される
• 一次情報の引用: 元の文書を参照せず、記憶から再構成する

KPMGのレポートが問題になったのも、まさに「他社のAI活用状況」という固有情報を引用した部分でした。AIはそれらしく書けますが、事実確認はしません。

エージェント型AIでハルシネーションが「連鎖」する

従来の生成AI（チャット型）でのハルシネーションは、人間が一度確認すれば止まります。しかしエージェント型AIでは、構造が根本的に変わります。

エージェント型AIとは、AIが人間の指示なしに自律的にタスクを進めるシステムです。ある調査では、製造業や金融でエージェント型AIを複数連携させて使う「マルチエージェント構成」が急増していることが報告されています。たとえば「情報収集エージェント」「分析エージェント」「レポート作成エージェント」を直列につなぐ構成です。

ここで問題が起きます。情報収集エージェントが誤情報を含む出力をすると、それが分析エージェントへの入力になります。分析エージェントはその誤情報を正しいものとして処理し、さらに積み上げた上でレポート作成エージェントに渡します。誤情報が確認されないまま連鎖し、最終成果物に複合的なかたちで混入する。1段階のハルシネーションが、3段階のエージェントを経ると修正しにくい形になっている——これは私たちが複数の案件で実際に目にしてきたことです。

エージェント型AIの強みは「人間が介在しなくても動き続ける」ことですが、これは同時に「人間が確認しないまま進む」ことでもあります。前の記事（エージェント型AIの業務導入で本当に難しいのは「動かすこと」ではない）で書いた「人間の承認ポイント」の話は、ハルシネーション対策の観点からも同じ結論に行き着きます。

企業が気づきにくい3つのパターン

ハルシネーションが厄介なのは、「これは間違いかもしれない」と思わせる書き方をしないからです。自信満々に、流暢に、整った文章で出力されます。企業が特に見逃しやすいパターンを3つ挙げます。

パターン1：「それっぽい数値」を疑わない

AIハルシネーション 企業導入において最も見落とされやすいのが数値の誤りです。「市場規模は2026年に○○億円に達する見込み」「導入企業の○○%が効果を実感」——こうした数値がレポートに入っていると、出典を確認する人は一割にも満たないことが多いです。AIが生成した場合でも、根拠のない数値が書かれた際に「この数値の出典は？」と問い返すまでのプロセスを持っていない組織がほとんどです。

パターン2：低頻度だが重要な箇所に集中する

単純な質問には正確に答えられても、専門性が高い・情報が少ない・最新の事実を含むという条件が重なるほどハルシネーションの頻度は上がります。問題は、そういった「難しい問い」に対する回答が、業務上もっとも重要な判断を含む場合が多いことです。よく使う部分ほど正確で、一番大事な部分ほど危うい、という構造があります。

パターン3：バックオフィス業務で確認の目がない

経営会議に上がる資料は複数人が目を通しますが、バックオフィスの定型業務——社内向け報告書、取引先へのFAQ自動返信、社内マニュアルの更新——は担当者が一人で回すことが多いです。AIが補助に入ると作業は速くなりますが、確認する人数が増えるわけではありません。むしろ「AIが作ってくれたから」という安心感で、以前より確認が薄くなるケースすら見てきました。

人間の関所をどこに置くか──リスクに応じた承認設計

「全部確認すればいい」という解決策は机上の論理です。AIを使う目的の一つが作業量の削減である以上、全件人間確認では本末転倒になります。実務で機能する設計は、リスクに応じて確認の密度を変えることです。

私たちが現場で使っているリスク分類の考え方を紹介します。

高リスク：外部公開・契約・最終意思決定に関わる出力

対外的に送るメール、契約書のドラフト、プレスリリース、取引先への提案資料——これらはAIがどれだけ流暢に書いても、人間が全文を確認する工程を外しません。KPMGのレポートはまさにここに分類されます。「高リスクは全件通す」というルールを組織で共有していれば、あの撤回は防げた可能性があります。

中リスク：内部で使う分析・報告・判断の参考資料

会議の議事録、週次レポート、内部の市場調査まとめ——これらは全件確認は不要ですが、サンプリング確認（週1回・月1回のランダムチェック）は設けます。問題のパターンが見つかったら、そのカテゴリは高リスクに格上げします。

低リスク：ドラフト作成・調査補助・テキスト整形

メールの文章案、社内向けFAQの初稿、データの整形——これらはAIが出力したものを人間が最終的に編集してから使う前提であれば、細かい確認は不要です。ただし「最終的に人間が手を触れる」という前提が崩れると低リスクではなくなります。

私たちの現場経験では、この分類を「先に決める」かどうかが決定的に違いをもたらします。多くの企業はAIを導入してから「ハルシネーションが問題になった」時点で対策を考えます。その順番では、既に起きた問題への対処になります。分類を先に設計しておけば、問題は起きにくくなり、起きても影響範囲が限定されます。

RAGで「答える範囲」を事前に絞る

人間の関所はハルシネーションの「出口」での対策です。それと組み合わせて有効なのが、「入口」でAIが使える情報を限定する設計です。

RAG（検索拡張生成：社内のドキュメントをAIに読み込ませて回答精度を上げる技術）は、AIが「自分の持っている情報だけで答える」状態を変える仕組みです。RAGを使うと、AIは回答を生成する前に指定した文書を参照します。「この社内マニュアルに書いてあること以外は答えない」という設計が可能になります。

製造業の知財部門で私たちが構築したシステムでは、出願前の意匠が他社と似ていないかを一次チェックするAIに、公開特許データベースと社内の過去意匠だけを参照させています。それ以外の情報源からの推測回答は出力しないよう設計しました。このシステムでハルシネーションが大幅に減ったのは、RAGで「答えの範囲」を先に絞ったからです。

プロンプト設計でも同様の効果が出せます。「提供されたドキュメントに基づいて答えてください。確認できない場合は『確認できません』と答えてください」という指示を入れると、AIは不確かな情報をもっともらしく作ることが減ります。完全にはなくなりませんが、頻度は下がります。正直なところ、この一行を加えるだけで体感できる変化があります。

ハルシネーションを「ゼロにしない」という現実的な方針

ここまで対策を書いてきましたが、率直に言えば、ハルシネーションを完全にゼロにすることは現時点では不可能です。生成AIの確率的な性質上、どれだけ工夫しても一定の頻度で誤情報は出ます。

だからこそ、目指すべきは「ゼロにする」ではなく「管理できる状態にする」です。具体的には以下の3つを組み合わせます。

1. 許容度を業務別に設定する

議事録のドラフトに小さな事実誤認が入る確率と、対外契約書に誤記が入る確率では、許容できる上限が全く違います。業務ごとに「この出力は○○まで許容する、それを超えたら人間確認」という線引きを明文化します。

2. 記録を残し、パターンを把握する

どの業務のどのタイプの質問でハルシネーションが出やすいかは、使い続けると分かってきます。記録がなければ改善できません。私たちが設計するシステムでは、AIの出力と人間の修正内容を対で記録し、月次でパターンを確認する仕組みを設けます。地味な作業ですが、これをやっている組織はやっていない組織より明らかに速く改善します。

3. 人間が最終的な品質に責任を持つ

これは技術の話ではなく、役割の設計の話です。AIが作ったものの品質は、AIの責任ではなく、それを使った人間の責任です。「AIが間違えた」は言い訳になりません。この前提を組織として共有しているかどうかが、AIガバナンスの出発点になります。

IBMが「AIオペレーティングモデル」の指針で述べている通り、AIに目的を与え、動きを監督し、最終の品質に責任を持つのは人間です。これはHuman-in-the-Loop（人間が意思決定や確認の要所に入る設計）という考え方で、AIガバナンスの中心的な概念として2026年の企業AI導入では標準的に語られるようになっています。AI ハルシネーション対策の本質は、AI技術の精度を上げることではなく、この「人間が責任を持てる仕組み」を設計することにあります。

私たちが現場で見た「確認の仕組み」の作り方

少し具体的な話をします。

ある中堅食品メーカーで、社内の品質管理マニュアルをベースに現場担当者の質問に答えるAIシステムを構築したことがあります。このシステムで最初に決めたのは「AIが答えた内容の根拠となるマニュアルのページ番号を一緒に表示する」というルールでした。担当者はAIの回答を見てから、必要なら元のマニュアルを確認できます。答えの出典が見えることで、「なんとなく信じる」から「根拠を確認できる」に変わりました。

別の案件では、営業担当者が使う提案資料の自動生成システムを作りました。このとき設計した関所は1つだけです。「顧客への送付前に担当者が全文を読んで承認ボタンを押す」。シンプルですが、これだけで「AIが作ったから確認しなくていいか」という判断が起きなくなりました。承認ボタンを押すという行為が、責任を担当者に戻す設計です。

共通しているのは、技術的に凝ったことをするより、「確認の仕組みを業務フローに組み込む」方が効果的だということです。確認を「任意」にすると人は省略します。「仕組みとして漏れなく通る」ように設計することが、ハルシネーション対策の実務的な本質です。

もう一例、看護シフト自動生成のシステムを構築した際の話をします。AIが提案するシフト案には夜勤連続日数・月間上限時間といった現場ルールが反映されていますが、それでも「ルールは守っているが現場の感覚に合わない」という修正が出ることがありました。ここで取り入れたのが「AIの提案に対して担当者がコメントを残して承認する」フローです。コメントを義務付けることで、担当者がシフト案を眺めるだけでなく、本当に読んでいるかどうかが確認できます。義務的なコメント入力という小さな設計変更が、確認の質を変えました。

ハルシネーション対策で高価なツールを入れる前に、こういった業務フローの設計変更から始めることを私たちは推奨しています。コストをかけずに、今日から始められることが少なくとも一つはあります。

よくある質問

Q. ハルシネーションはRAGを入れれば解決しますか。

RAGは有効な対策ですが、万能ではありません。参照できる文書の範囲外の質問には、それまでと同様にハルシネーションが起きます。「RAGを入れたから安心」ではなく、「RAGで減らして、人間の確認で補う」の組み合わせで考えてください。

Q. 確認作業でかえって業務効率が落ちませんか。

「全部確認する」なら確かに落ちます。しかしリスクベースの設計（高リスクだけ全件、中リスクはサンプリング）であれば、AIを入れる前より確認コストが下がることがほとんどです。業務全体の確認作業量を設計前後で比較してみてください。

Q. どのAIモデルを使えばハルシネーションが少ないですか。

モデルの進化は速く、ここに書いた情報はすぐに古くなるので断言は避けます。ただし言えるのは、どのモデルを使っても確認の仕組みは必要だ、ということです。最新モデルでも確認なしに使うより、旧モデルでも確認の仕組みがある方が業務上の信頼性は高くなります。

Q. 社内のAIシステムに対してもハルシネーション対策は必要ですか。

必要です。内部向けだから問題ないということはなく、社内向けの誤情報は意思決定の質を下げます。特に経営資料、採用・人事関連、法務・コンプライアンスに関わる出力は、外部向けと同じ水準の確認を設けることをおすすめします。

「生成AIの信頼性」を高める、3つの組み合わせ

ここまで個別の対策を述べてきましたが、生成AI 信頼性を組織として高めるには、3つのアプローチを組み合わせて設計することが効果的です。

1つ目は入口の制御。RAGで参照できる情報源を限定し、AIが「知らないことを作る」状況を減らします。2つ目は出口の確認。リスク分類に基づいた承認フローで、問題のある出力が外に出る前に止めます。3つ目はフィードバックのループ。確認で見つかった誤りを記録し、定期的に傾向を分析して入口と出口の設計に反映します。

この3つは独立して機能しますが、組み合わさることで全体の精度が上がります。どれか一つで「解決した」と考えるより、「3つで管理する」という設計思想に立つ方が現場での失敗は少なくなります。AI ハルシネーション 対策を単体のツール導入として捉えるか、統制の設計として捉えるかで、1年後の定着度に大きな差が出ます。

企業においてこの取り組みは「AIガバナンス」と呼ばれることもありますが、大企業向けの難しい話ではありません。中堅・中小企業でも、上記の3つの組み合わせを業務に合わせて実装することで、AIの出力を信頼して使える環境は作れます。

まず試すなら

ハルシネーション対策を「技術の問題」として捉えると、解決策はモデルの選定やRAGの導入になります。しかし本質は「統制の設計」です。明日から動ける3つの手順を示します。

1. 自社のAI出力を3つに分類する — 「高リスク（外部・意思決定）」「中リスク（内部・分析）」「低リスク（ドラフト・補助）」に現在使っているAI活用を振り分ける。分類するだけで「どこに関所が必要か」が見えてきます
2. 高リスクの出力に確認フローを一つ追加する — まず高リスクの出力だけに「送付前に担当者が確認するステップ」を業務フローに組み込む。ツールは何でもよい。ポイントは「任意」ではなく「スキップできない」設計にすること
3. 1か月後に記録を見直す — 確認で見つかった誤りのパターンを記録しておき、1か月後に振り返る。パターンが分かれば、RAGで対応するか・プロンプトを変えるか・中リスクから高リスクに格上げするかが判断できます

AI-Pathでは、**無償の業務プロセス診断（BPR）**を実施しています。現状のAI活用でどこにハルシネーションリスクが潜んでいるか、どこに確認の関所を設ければいいかを、業務フローに沿って一緒に整理します。「AIを入れたはいいが、信頼できているか分からない」という段階で一度ご相談ください。

参考リンク

• KPMG pulls report on AI usage due to apparent hallucinations（TechCrunch）
• 「業務の前提そのもの」をどうアップデートする？ IBMが説く「AXの要件」を考察（ITmedia エンタープライズ）
• エージェントAIの精度を高めるために：ハルシネーションリスクから連鎖的エラーまで解説（Acrovision）
• AI-Path 導入事例