本番音声エージェントのRAG：ハルシネーションを止める

## 音声エージェントのRAG：通話中のハルシネーションを止める

ネット上の「RAGチャットボット開発」チュートリアルは、どれも同じものを作っています。テキスト入力欄、ナレッジベース、そして小さな「出典」チップを下に添えて回答を貼り付けるボット。Voiceflowの人気のノーコード旅行ボット入門では、RAGを「新入社員を教育するようなもの」とまで表現しています。利用者が出典を目で確認でき、回答を読み返せるウェブサイトのウィジェットなら、それで十分でしょう。

しかし電話にはそのどれもありません。出典チップはない。さかのぼって読み返す履歴もない。かけてきた相手は、リアルタイムで話される一文を聞き、それを自社が今まさに交わした約束として受け取ります。エージェントが返金期限を捏造したり、価格を言い間違えたり、存在しない予約を確定したりしても、逃げ込める「出典」の脚注はありません。残るのは録音された約束だけです。

本記事は、一般的な解説記事が飛ばしている音声前提のRAGガイドです。リアルタイムのレイテンシ予算に収まる検索、画面に出せないデータのグラウンディング、回答拒否とエスカレーションの設計、そして音声回答のハルシネーションを実際に評価する方法を扱います。

## 音声でハルシネーションがより深刻になる理由

捏造された事実が、チャットよりも通話で危険になる理由は三つあります。

1. **出典が目に見えない。** テキストなら、誤った回答の隣にリンク付きの出典があれば、利用者はクリックして自分で修正できます。音声では、モデルの言い切る自信そのものがインターフェースです。流暢な誤答は、流暢な正答とまったく同じに聞こえます。
2. **リアルタイムで一発勝負。** チャットなら読み返して考え直せます。電話の相手は音声を線形に処理し、そのまま次へ進みます。誰かが指摘するより先に、誤りは受け入れられてしまいます。
3. **口頭の約束は法的責任になる。** 「はい、48時間以内なら無料でキャンセルできます」は、実質的に御社のポリシーです。録音され、時刻が記録され、拘束力があるように響きます。大規模言語モデルは、有用で流暢であるよう訓練されており、言い控えるようには訓練されていません。電話ではその既定の振る舞いが法務上の問題になります。

ここでのRAGの目的は「賢そうに聞こえること」ではありません。**検索できたことだけを話し、それ以外は声に出して断ること**です。

## 電話エージェントのRAG構成：レイテンシ予算内に収める検索

音声における厳しい制約はターンレイテンシです。人は約800ミリ秒を超える沈黙に気づき、約1.2秒を超えるとエージェントにかぶせて話し始めます。STTから検索、LLM、TTSまでのループ全体を、自然に感じさせるにはおおよそ**1秒の予算**に収めなければなりません。

発話1ターンのおおまかな配分は次のとおりです。

| 工程 | 予算 |
|---|---|
| STTの確定（発話終了検出） | 約150〜300ミリ秒 |
| 検索（クエリのエンベディング＋ベクトル検索＋リランキング） | **約150〜250ミリ秒** |
| LLMの最初のトークン | 約300〜500ミリ秒 |
| TTSの最初の音声 | 約150〜300ミリ秒 |

検索に割けるのは約200ミリ秒です。この制約により、テキストボットが平然と使っている素朴な手法は使えなくなります。

- **ターンの途中でマルチホップ検索をしない。** 検索は1ターンにつき1回。クエリ拡張はオフラインか並列で行い、直列につながない。
- **エンベディングを事前計算してキャッシュする。** ナレッジベースは前もってエンベディング化しておき、リアルタイムで処理するのは相手の発話クエリだけにする。
- **投機的検索。** 発話終了を待たず、*途中経過*のSTT結果で検索を開始し、後から確定させる。これで100〜200ミリ秒を取り戻せます。
- **LLMの出力をTTSへストリーミングする。** 後続のトークンを生成しながら、最初の節を話し始めます。ただしグラウンディングは最初のトークンより*前*に決着している必要があります。一度声に出した節は取り消せません。

## 回答のグラウンディング：チャンク分割、リランキング、口座データの引用

音声のグラウンディングでは、扱いの異なる二種類のデータがあります。

**静的な知識（規約、料金、FAQ）。** チャンクは小さく、200〜400トークンにします。音声回答は短く、肥大した文脈はモデルを複数チャンクにまたがる合成へ誘い、それがハルシネーションの発生源になるからです。上位k件には必ず**リランキング**をかけます。20件の候補に対してクロスエンコーダのリランカーをかけて上位3件に絞ると、誤ったチャンクに基づく回答が目に見えて減ります。モデルに渡すのは10件ではなく2〜3チャンクです。

**動的な口座データ（注文状況、残高、予約）。** これはベクトル検索の対象ではなく、記録システムへのライブの関数呼び出しで取得します（`make integration for ai agents`のようなWebhook経由、あるいは直接API）。原則は、**ツールの応答に存在するフィールド値だけをモデルが口に出してよい**ことです。`order.status`が欠けているなら、エージェントが「おそらく発送済みでしょう」と推測することは許されません。口座に関する事実は型付きJSONとしてプロンプトに届くよう構成し、フィールドは一字一句そのまま引用するようモデルに指示します。

通話中に出典を提示できない以上、「引用」はプロンプト内の**出所情報**に置き換わります。取得した各チャンクにソースIDを付与し、「CHUNK_IDブロックの内容だけを根拠に答える」という条件をモデルに内部的に課します。どのチャンクが音声回答を生んだかは監査用にログへ残します。引用は相手のためではなく、*あなた自身*のためのものです。

## 回答拒否とエスカレーション：推測するより「担当者におつなぎします」

音声でハルシネーション対策として最も効果が大きいのは、質のよい回答拒否の経路です。検索が信頼度のしきい値を超える結果を返さなかったとき、正しい出力は最善の推測ではなく、エスカレーションです。

1ターンあたり、二択ではなく三つの明示的な出口を設計します。

- **回答する** — しきい値を超える根拠チャンクがある → 裏付けのある事実を話す。
- **確認する** — クエリが曖昧 → 短い質問を一つ返し、検索をやり直す。
- **引き継ぐ** — 検索スコアが低い、対応範囲外、または不満の兆候を検知 → 「正確にお答えしたいので、専門の担当者におつなぎします」＋文脈を引き継ぐ[ウォームトランスファー](/glossary/warm-transfer)。

しきい値はベクトル類似度だけでなく、リランカーのスコアに紐づけます。そして引き継ぎのコストを下げること。きれいな転送で終わる通話は失敗ではなく*成功*です。転送を避けようとして推測することこそ、冒頭で述べた「録音された法的責任」を招く道筋です。

## 通話中の作り話を減らすプロンプト設計

音声の`rag prompts`はチャット用より厳しくなります。誤答を和らげてくれる出典が画面に出ないからです。

- **記憶からの回答を禁止する。** 「あなたはCONTEXTブロック以外の知識を持たない。回答がCONTEXTにない場合は、確認する旨を伝えるか、転送すること」。これを明記し、[システムプロンプト](/glossary/system-prompt)の終盤でもう一度繰り返します（末尾に近いほど効きます）。
- **口座データはフィールドを一字一句そのまま。** 「数値、日付、ステータスは、ツールの結果に現れたとおり正確に述べること。推定も丸めも決してしない」。
- **規約についてチャンクをまたぐ合成を禁じる。** 「最も関連する単一のチャンクから回答すること。二つの規約を組み合わせて新しい規約を作らない」。
- **発話長の上限。** 「人が耳で追える一文か二文で答えること」。長い回答ほど脱線し、作り話を始めます。
- **不確実性を表す言い回しを用意する。** 「確認のうえ折り返しご案内します」といった、公式に認められた逃げ道をモデルに与えます。そうすれば拒否は失敗状態ではなく、選べるトークンの経路になります。

## 音声RAGの出力を評価する

音声RAGを感覚でリリースすることはできません。書き起こしを対象とするオフラインの評価基盤を用意します。

- **忠実性（faithfulness）** — 回答内のすべての主張が、取得した文脈から導けるか。（文脈, 回答）のペアをLLMジャッジで採点します。目標は0.95超。
- **グラウンディング度／回答の関連性** — 回答は取得したチャンクを使ったのか、それとも無視して勝手に話したのか。
- **ハルシネーション率** — 文脈にない主張を含む回答の割合。これが最重要指標です。エラーバジェットと同じようにリリースごとに追跡します。
- **拒否の適合率／再現率** — 引き継ぐべきときに引き継ぎ、答えを持っているときには*引き継がなかった*か。過剰な拒否は顧客体験を損ない、不足した拒否は法的責任を生みます。
- **検索のhit@k** — LLMを責める前に、そもそも正しいチャンクが取得できていたかを確かめます。「ハルシネーション」の大半は検索の取りこぼしです。

これをデプロイのたびに、実際の通話書き起こしのゴールデンセットで実行します。本番で発生したハルシネーションは、そのつどリグレッションテストとしてセットに追加します。

## 内製か導入か：Finnが引き受ける範囲

音声RAGスタックを自前で組むということは、サブ秒の検索基盤、リランキング、STT/TTSのストリーミング、[バージイン](/glossary/barge-in)、拒否と引き継ぎの状態機械、ウォームトランスファー、書き起こしの評価基盤――これらすべてを自分たちで抱え、しかもすべての通話でレイテンシ予算内に収め続けることを意味します。週末のチュートリアルで済む話ではなく、数か月がかりの`ai agent development`です。

Finnは音声グラウンディングの層を最初から備えています。ターン予算に合わせて調整された検索、フィールドを一字一句守るグラウンディング付きの口座データ関数呼び出し、標準搭載の回答拒否とウォームトランスファー、そしてそのまま評価に流し込める通話単位の書き起こし。お客様はナレッジベースと記録システムをご用意ください。音声で話される回答を事実に保つのはFinnの役目です。

## 関連リンク
- `/blog/ai-voice-agent-vs-ivr-enterprise-guide` — 決定論的なIVRが終わり、根拠に基づく音声AIが始まる地点
- `/blog/how-to-manage-high-call-volumes-without-hiring-more-agents-2026` — グラウンディングに投資する価値を生む自動応答の経済性
- `/blog/ai-voice-agent-pricing-comparison-2026` — 検索＋LLM＋TTSスタックの分あたりコスト
- `/blog/blog-draft-your-help-desk-ends-at-the-ticket-where-voice-ai-closes-the-loop-2026-a9e2754c` — 通話後にループを閉じる

## FAQ
_Emit as FAQ JSON-LD (schema.org/FAQPage)._

**Q：音声エージェントにおけるRAGとは何ですか？**
A：[検索拡張生成](/glossary/retrieval-augmented-generation)は、通話時に取得した自社の規約、料金、口座データにエージェントの発話回答を接地させる仕組みです。モデルの推測ではなく、ナレッジベースにある事実を話すようになります。

**Q：電話でのLLMのハルシネーションはどう防ぎますか？**
A：回答前に検索とリランキングを行い、取得した文脈だけから話すようモデルに指示し、口座のフィールドは一字一句そのまま引用し、検索の信頼度が低いときは人間に引き継ぎます。

**Q：RAGは音声の1ターンにどれだけレイテンシを追加しますか？**
A：ターン全体を約1秒とし、そのうち検索に約150〜250ミリ秒を見込みます。エンベディングを事前計算し、検索は1回だけ実行し、少数の候補にリランキングをかけ、STTの途中経過で検索を開始すれば予算内に収まります。

**Q：音声回答のハルシネーションはどう測りますか？**
A：LLMジャッジで書き起こしの忠実性とグラウンディング度を採点し、ハルシネーション率をエラーバジェットとして追跡し、リリースごとにゴールデンセットで拒否の適合率／再現率と検索のhit@kを測定します。

検索、拒否、評価の基盤を自分で作らずに、事実に基づく音声応答を実現しませんか。**Finnがすべての通話をどう接地させるかをご覧ください。デモのご予約はhirefinn.aiから。**