2026年9月30日。問い合わせ対応にRAGを加えるとき、検索対象を広げ、すべての質問に回答し、検索スコアが高ければ自動送信する設計は、PoCでは簡単でも運用時の誤回答を切り分けにくくします。
この記事は公開資料をもとにした設計提案です。以下の構成や判定条件は未実装・未検証で、導入実績や精度の数値を示すものではありません。対象読者は、問い合わせの分類・回答案生成を業務システムに組み込むエンジニアとテックリードです。
技術的な問いと前提
問い合わせRAGのゴールは、文章らしい回答を常に返すことではありません。問い合わせに対して、権限のある有効な根拠を見つけ、根拠の範囲で回答案を作り、根拠が足りないときに安全に保留できることです。
このため、回答の失敗を「LLMの精度」にまとめず、少なくとも検索・根拠評価・回答生成・送信判断に分けます。MicrosoftのRAG評価ガイドも、検索側ではPrecision@KやRecall@Kなどを、回答側では忠実性や関連性などを別々に評価する方法を説明しています。
最初に捨てる3つのパターン
| 捨てるパターン | 運用時に困ること | 代わりに置く設計 |
|---|---|---|
| 1. 関連しそうな文書を全部検索する | 古い版、重複、別商品の説明が同じ候補に混ざり、何が回答根拠か追えない | 公開状態・有効期間・商品や窓口などの属性で候補集合を絞り、検索件数は評価データで決める |
| 2. 根拠がなくても必ず回答する | 該当情報がない質問にも、もっともらしい補完が入る | 「該当根拠なし」「根拠が競合」「質問の条件不足」を回答保留の状態として定義する |
| 3. 類似度スコア1つで自動送信する | 類似度は検索候補との近さであり、回答の正しさ・最新性・送信可否を直接保証しない | 検索品質、回答の根拠対応、文書の有効性、送信リスクを別々に判定する |
この3つは、閾値やプロンプトを先に調整するほど後から直しにくくなります。先に「どの状態なら回答案を作らないか」を定義すると、必要なログや人手確認の場所も設計できます。
採用する処理境界
問い合わせ
↓
分類・必要情報の確認
↓
権限と有効期間で絞った検索
↓
根拠の充足・競合・鮮度を判定
├─ 不足 / 競合 / 期限切れ → 保留理由を記録して人へ
└─ 十分 → 根拠ID付き回答案を生成
↓
根拠との対応・禁止表現・宛先を検査
├─ 合格 → 運用ルールに応じて承認または送信
└─ 不合格 → 人へ回す
回答生成には、参照した根拠IDと該当箇所を構造化して添えます。モデルには「根拠にない内容を埋めない」「根拠同士が矛盾する場合は結論を出さない」と指示します。ただし、指示だけを品質保証にしません。出力後に、回答の主張が引用箇所で支えられているか、根拠の文書が現在有効かを別工程で検査します。
失敗を分離する評価セット
評価データは、通常質問だけでなく、該当情報なし、旧版と新版の競合、閲覧権限外、複数条件の組み合わせ、追加確認が必要な質問を含めます。各ケースに期待する根拠文書と期待する動作（回答・質問返し・保留）を持たせます。
| 評価段階 | 例 | 見るもの |
|---|---|---|
| 検索 | 必要なFAQが上位候補に入るか | Recall@K、順位、権限フィルター |
| 根拠判定 | 根拠不足や矛盾を検出できるか | 不足・競合・期限切れの見逃し |
| 回答案 | 主張を引用箇所で支えられるか | 根拠との対応、余分な断定 |
| ルーティング | 危険な回答を送信経路に流さないか | 保留率、誤通過、担当先 |
Microsoftの回答評価ガイドは、忠実性・完全性・関連性など複数の観点を扱い、生成モデルの非決定性にも触れています。単一の総合点だけをリリース条件にせず、重大ケースの失敗を個別にゲートする設計が必要です。
本番運用で残すログ
一件ごとに、問い合わせID、検索条件、対象文書IDと版、有効期間、検索順位、根拠判定、プロンプトとモデルの版、回答案、保留・承認の理由を記録します。本文の保存が不要なら、個人情報を含む問い合わせ全文をログへ複製せず、アクセス制御と保持期間を別に定めます。
文書更新後は、該当する評価ケースを再実行し、検索対象への反映と旧版の除外を確認してから切り替えます。問い合わせの種類や失敗理由ごとに、検索漏れ・根拠不足・情報の陳腐化・分類誤りを集計すれば、埋め込みやプロンプトを闇雲に変える前に修正箇所を絞れます。
自動送信を使う場合も、送信可否は類似度だけで決めません。対象業務、誤回答時の影響、評価セットでの合格条件、監視と停止手段を揃え、条件を満たさない質問は人の確認へ戻します。初期段階では回答案の作成までを自動化し、承認ログを集めてから自動送信範囲を見直す方法が扱いやすい設計です。
今後の改善
最初に作るべきものは巨大なFAQ索引ではなく、回答・保留を分ける代表ケースと、その期待根拠です。運用後は人が修正した回答や保留理由を評価データに戻し、検索・根拠判定・生成のどこを直すかを分けて改善します。数値目標は問い合わせの種類と誤回答の影響を確認してから決めます。
同様の仕組みの設計・構築・運用については相談可能。
参考リンク
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。