企業向けCustom RAG：ハルシネーションを防ぐ3層アーキテクチャ

結論から言います。 RAGのハルシネーション（hallucination）は、より「賢い」モデルに乗り換えることで防ぐものではなく、運用アーキテクチャで防ぐものです。日本のエンタープライズ案件（保険、公共分野）で私が用いるのは、入力を制御し、**検索（リトリーバル）**を制約し、出力をレビューする、3層の制御フレームワークです。これにより、誤りが許されない領域でも誤答率を限りなくゼロに近づけられます。モデルが「自然に賢くなる」ことに期待するのではなく、です。

TL;DR（エグゼクティブサマリー）

  • 課題： 日本の大手保険5グループおよび公共分野のAIプロジェクトでCustom RAG／AIチャットボットを導入。ここでは一つの誤答（ハルシネーション）が「小さなバグ」ではなく、法的・信用上のリスク（金融庁＝FSAコンプライアンス）に直結します。
  • 解決策： LLMの「賢さ」に頼るのではなく、3層レビュー（3-Tier Review） フレームワーク ―― 入力ゲーティング、検索グラウンディング、ヒューマン・イン・ザ・ループによる出力レビュー。
  • 結果： カスタマーサポートの運用コストを約40％削減しつつ、エンタープライズ水準の精度とコンプライアンスを維持。3年間のライフサイクル全体を通じて安定稼働しました。

ハルシネーションとは、運用の観点から見ると何か？

多くの記事は、ハルシネーションを学術的に「モデルが事実でない情報を生成すること」と定義します。正確ですが、運用に責任を負う立場ではほとんど役に立ちません。

デリバリーマネージャー／システムアーキテクトの視点から、私はこう定義し直します。ハルシネーションとは、システムが「根拠となるデータを持たないこと」について自信満々に答えてしまう状態です。 核心的な問題は「モデルがでっち上げる」ことではなく、システムに「分かりません」と認める仕組みがないことにあります。

SMEの現場であれば、誤答は単に相手を苛立たせる程度かもしれません。しかし日本の保険分野では、約款の条項を誤って説明するチャットボットは法的責任を招きかねません。この二つは同じリスク階級ではないため、同じアーキテクチャを使うことはできないのです。

なぜ「より良いモデルを使う」では解決しないのか？

これは最もよくある落とし穴です。チャットボットがでっち上げをすると、まず「より強力なモデルに替えよう」と考えがちです。しかし強力なモデルは、より説得力をもってハルシネーションを起こすだけで、いつ沈黙すべきかは依然として分かりません。

本当の理由はこうです。ハルシネーションの多くは生成（generate）の段階ではなく、検索（retrieval）の段階で発生します。システムが誤った文書を検索したり、何も取得できないのにモデルに無理やり答えさせたりすれば、どれほど「素直な」モデルでも、その空白を推測で埋めてしまいます。だからこそ私はいつもこう言います。RAGはモデル選定の問題ではなく、データアーキテクチャの問題であると。（この考え方はビジネス課題を解決するシステム思考で詳しく述べています。）

ハルシネーションを防ぐ3層レビュー・フレームワーク

これは、私がエンタープライズのCustom RAGシステムに適用しているフレームワークです。各層は異なる種類の誤りを防ぎます。そして重要なのは、それぞれが独立していること ―― どの層も単独で全責任を負うことはありません。

第1層 ―― 入力ゲーティング（Input Gating）

質問がLLMに到達する前に、システムはそれを分類します。この質問は、システムが答えてよい対応範囲内か？ 対応範囲外（out-of-scope）の質問は即座にブロックし、別ルートへ誘導します ―― モデルに無理に答えさせて、でっち上げを生ませるのではなく。

非構造化データ（契約書のPDF、スキャン文書）の場合、この層にはOCR＋自動スクリーニングも含まれます。インデックス化する前に、原資料を正規化しノイズを除去するのです。ゴミを入れればゴミが出る ―― これはどのモデルにも救えません。

第2層 ―― 検索グラウンディング（Retrieval Grounding）

これは最も重要でありながら、最も見落とされがちな層です。原則はこうです。モデルは検索された文書のみに基づいて答えてよく、その出典を提示できなければならない。 検索結果の類似度が閾値を下回った（十分に関連する文書が見つからない）場合、システムは推測モードに移行するのではなく、強制的に「情報がありません」と答えます。

言い換えれば、私はシステムが**「分かりません」と言えるように**設計します。それは欠陥ではなく、機能なのです。

第3層 ―― ヒューマン・イン・ザ・ループによる出力レビュー

リスクの高い領域では、すべての回答が顧客へ直接送られるわけではありません。機微な領域（条項、金額、法的なコミットメント）に触れる回答は、送信前に人によるレビューを経由させます。よくある質問の大部分は負荷軽減のため完全に自動化し、「コストの高い」回答にだけ人を関与させます。

この設計 ―― 安価な部分は自動化し、高価な部分には人を残す ―― こそが、コンプライアンスのリスクを犠牲にすることなく運用コストを約40％削減できた要因です。

このアーキテクチャが「不要」なのはどんなときか？

私は、あらゆる課題に重厚なアーキテクチャを押し付けることを良しとしません。この3層フレームワークが不要なのは、次のような場合です。

そうした場合は、シンプルなRAG ―― あるいはRAGを使わないこと ―― が正しい選択です。「AIに間違った場所で投資して燃やしてしまう」落とし穴については、自動化の失敗から得た教訓で書きました。

3層アーキテクチャは、誤答に本当の代償があるときのためのものです。そしてそのときこそ、それは一円の価値も無駄にしません。

よくある質問

Q：RAGはハルシネーションを完全になくせますか？ 絶対的な0％を保証できるシステムは存在しません。しかし3層アーキテクチャ ―― 入力ゲーティング、出典提示を必須とする検索グラウンディング、リスク領域でのヒューマン・イン・ザ・ループ ―― により、リスクをエンタープライズとして許容できる水準まで下げられます。さらに重要なのは、それが起きたときに制御できる（なぜ起きたかを追跡できる）ことです。

Q：企業データにはファインチューニングとRAG、どちらを使うべきですか？ 私が見てきたエンタープライズ案件の多くではRAGが有利です。データは絶えず変化し（条項の更新、新規文書）、再ファインチューニングはコストが高く追跡も困難です。RAGならインデックスを更新するだけで知識を更新でき、常に出典を提示できます ―― コンプライアンスが絡む場面では必須の要件です。

Q：エンタープライズのCustom RAG構築で、最大のコストはどこにありますか？ モデルやインフラではなく、原資料の正規化（第1層）と、閾値・レビューフローの設計（第2〜3層）です。ここは「地味」ながら、システムが生きるか死ぬかを決める部分です。モデルの費用しか見積もらないベンダーは、たいてい厳しい環境で本物のRAGを運用した経験がありません。その下で動く検索エンジンそのもの——チャンキング、ハイブリッド検索、リランキング、そして数値の入ったeval表——は本当に動くCustom RAGの内側：チャンキングから検索評価までで開けてみせます。

誤りに本当の代償が伴うプロセスへAI／RAGを導入すべきか検討中で、こうしたシステムを設計から運用まで一貫して担ってきた人材をお探しでしたら、AI自動化の対応領域をご覧いただくか、実際のプロジェクト事例をお読みください。あるいはシステム課題のご相談から、直接お話しいただければと思います。

Nguyen Chau
Delivery Manager / System Architect
日越市場におけるシステムの設計・運用で14年の経験