問い合わせ対応をRAGで半自動化する仕組み。全自動にしないのが正解という話

こんにちは。TIFFIN開発チームです。「問い合わせメールの返信に毎日2時間かかっている。AIでなんとかならないか」——生成AIが当たり前になってから、この相談が本当に増えました。答えから言うと、なんとかなります。ただし「AIが勝手に全部返信する」を目指すと失敗します。目指すべきは「AIが根拠つきの下書きを作り、人が確認して送る」半自動化です。この記事では、その中核技術であるRAGの仕組みと、導入を成功させる現実的な手順を、専門用語をなるべく使わずに解説します。

RAGとは:自社の資料を「根拠」に答えるAI

ChatGPTのような生成AIをそのまま問い合わせ対応に使うと、2つの問題にぶつかります。自社のことを知らない(製品仕様も納期も価格も答えられない)、そして知らないことを聞かれると、それらしい嘘を作ってしまうことがある。

RAG(Retrieval-Augmented Generation:検索拡張生成)は、この2つをまとめて手当てする構成です。動きはシンプルで、質問が来たら(1)まず自社の資料——製品マニュアル、価格表、よくある質問、過去の回答メール——の中から関係する箇所を検索し、(2)見つかった箇所だけを根拠として渡してAIに回答文を生成させます。AIの記憶に頼らず、毎回「カンニングペーパーを渡してから書かせる」イメージです。

この構成の実務上の最大の利点は、回答に「どの資料のどこを根拠にしたか」を添えられることです。確認する人は根拠を見て数秒で判断できます。根拠が出せない質問には「分かりません」と言わせる設計にできるのも、素のAIとの大きな違いです。

なぜ全自動にしないのか

技術的には、生成した回答をそのまま自動送信することもできます。それでも私たちが「人の承認を挟む」設計を勧めるのには理由があります。

• 間違いのコストが非対称だから。100件のうち99件正しくても、1件の誤案内(在庫がないのに「あります」、対応不可なのに「できます」)が実害と信用毀損になります。人の確認は、この1件を止めるための保険です
• 問い合わせは「例外の見本市」だから。クレーム、値引き交渉、複合的な相談——定型から外れたものほど人の判断が必要で、そして定型から外れたものこそ問い合わせに来ます
• 承認の記録が次の学習データになるから。人がどう直したかが貯まると、下書きの精度を上げる材料になります。全自動にすると、この改善ループが回りません

「確認するなら手間は減らないのでは?」と思われるかもしれませんが、体感はまったく違います。白紙から書くのと、8割できた下書きを直すのとでは、1通あたりの時間も精神的な負荷も別物です。返信品質の均質化(新人も古株も同じ水準)という副産物もあります。

仕組みの全体像:5つの部品

RAGによる問い合わせ半自動化は、次の5つの部品でできています。

1. 受付口——メール、Webフォーム、LINEなど。複数チャネルを1つの受信箱に集約するところから始まります
2. ナレッジベース——検索対象になる自社資料の置き場。ここの質が回答の質の上限を決めます(次章)
3. 検索——質問文と「意味が近い」資料を探す部分。キーワード一致ではなく意味で探すので、言い回しが違っても見つかります
4. 生成——検索結果を根拠に、宛名や文体まで整えた返信下書きを作る部分
5. 承認画面——下書きと根拠を並べて表示し、人が編集・承認・送信する画面。実は使い勝手がいちばん定着を左右する部品です

ポイントは、5つのうちAIらしいのは3と4だけだということです。残りは地に足のついた業務システムの世界で、ここが弱いと「AIはすごいのに使われないツール」ができあがります。私たちが業務システム開発とAI開発を同じチームでやっている理由もここにあります。

いちばん大変なのはAIではなくナレッジ整備

導入プロジェクトで工数が一番かかるのは、モデルの調整ではなくナレッジ整備です。よくある現実はこうです——製品情報は誰かのPCのExcelに、価格の最新版は営業部長の頭の中に、対応ルールは「先輩がそうしていたから」。この状態でRAGを入れても、検索する先に正しい答えが存在しないので、AIは活躍できません。

整備のコツを3つ挙げます。

• 完璧な文書を書こうとしない。過去の「良い返信メール」はそのまま一級のナレッジです。まず過去メールから始める
• 日付と出典を必ず付ける。価格や納期のように変わる情報は、古い資料が検索に引っかかると誤案内の元になります。「いつ時点の情報か」をデータに持たせる
• 更新の担当を決める。ナレッジは生ものです。製品が変わったら誰が直すのか、最初に決めておかないと半年で腐ります

ちなみに、この「正しい情報がどこにあるかを1か所に決める」作業は、業務システム化の話と完全に同じ構造です。紙とExcelの業務をシステム化する前に整理すべき3つのことで書いた「正の所在」の議論が、そのままRAGにも効きます。

導入手順:まず過去の問い合わせ100件を分類する

「RAGを入れたい」と思ったら、ツール選定の前にやるべきことがあります。直近の問い合わせ100件を眺めて、ざっくり分類することです。

この分類をすると、意外な事実が見えることがあります。たとえば1行目の「同じ質問の繰り返し」が大半なら、最初の打ち手はRAGではなくサイトの導線改善かもしれません。実際、工具メーカー作業工具メーカーC社様のBtoB受発注サイトを構築したときは、在庫や注文状況をお客様自身がWebで確認できるようにしたことで、電話・FAXでの問い合わせ自体を減らす方向が効きました。AIで返信を速くする前に、聞かなくても分かる状態を作る——この順番も忘れずに検討してください。

その上でRAGを入れるなら、進め方は小さく行きます。

1. 分類で「定型だが個別情報が要る」に入った1〜2カテゴリだけを対象に始める
2. 過去メール+主要資料でナレッジベースの初版を作る(この時点では数十文書で十分)
3. 1〜2名の担当者だけで1か月使い、下書きの採用率と修正内容を記録する
4. 採用率が上がってきたら対象カテゴリと利用者を広げる

向く問い合わせ・向かない問い合わせ

最後に、期待値の調整です。RAGの半自動化が効くのは「答えが自社資料のどこかに書いてある(書ける)質問」です。逆に、次のようなものは人の仕事として残ります。

• 感情への対応が本体であるもの(クレームの初動、お詫び)
• 会社としての判断が要るもの(特別対応、値引き、契約条件)
• 資料化されていない暗黙知だけが根拠のもの——ただしこれは、対応するたびにナレッジに書き足していけば、少しずつAIの守備範囲に移せます

体感の目安として、問い合わせ対応の時間が半分になれば大成功、3割減でも十分に投資回収できる、というのが私たちの相場観です。「全部AIに」という威勢のいい話より地味ですが、確実に効きます。

TIFFINでは、受付口の整備(フォーム・メール・LINE)からナレッジ整備の伴走、RAG本体、承認画面まで一式で開発しています。「うちの問い合わせ、AIでどこまでいけそうか」を過去メールを見ながら診断するところからで構いません。お気軽にご相談ください。