AIチャットボットの次世代型。根拠も添えて回答する、コールセンター向けチャットボットを制作しました

2026年8月29日 2026年8月29日

blueleaf

AI チャットボットを業務に入れようとすると、たいてい同じところで止まります。

「その答え、本当に合っているんですか」

もっともな問いです。社内の規程やマニュアルを読ませて答えさせても、返ってくるのは文章だけ。合っているかどうかを確かめるには、結局その担当者が資料を開いて探し直すことになります。それなら最初から自分で探したほうが速い、という結論になりがちです。

先日、コールセンターと現場の窓口で使われている社内の情報検索システム向けに、AI チャットボットのデモを作りました。そこで採ったのが、答えと一緒に、その根拠になったページそのものを返すという形です。回答の中に [1] [2] という番号が入り、それをクリックすると元のページが横に開いて、根拠になった段落が枠で囲まれた状態まで飛びます。

ご存じの方には、Google の Gemini Notebook（旧 NotebookLM）で回答に出典が並ぶ形が近い、と言うと伝わりやすいかもしれません。

AI の答えを、確かめてからお客様に伝えたい。 そういう現場をお持ちでしたら、この形が合うと思います。この記事では、その画面と、そのために中で何をしているかをご紹介します。

1. 画面で何が起きるか

利用者がやることは、普通のチャットと同じです。質問を打つだけです。

返ってくる答えが違います。

チャット画面のイメージ。回答の中に出典番号が入り、右側に根拠のページが開いて該当箇所が囲まれている

順に見ていきます。

① 回答の中に、出典番号が入る 答えの文章の、根拠になっている記述の直後に [1] [2] が入ります。番号はその場で検索して実際に取り出したページに振られたもので、AI が番号を勝手に作ることはできません。

② 回答の下に、出典カードが並ぶ 番号ごとに、ページのタイトルと更新日が並びます。更新日を出しているのは、社内資料には同じ主題の古い年度版が残っていることが多く、「どちらが新しいか」が答えの正しさに直結するからです。

③ カードを押すと、元のページが横に開く 別のタブに飛ぶのではなく、チャットの右側にそのまま表示されます。会話を続けながら根拠を見られる形です。

④ 根拠になった段落が、枠で囲まれて表示される ページを開いただけでは、どこを読めばいいのか分かりません。AI が答えの材料に使った段落を琥珀色の枠で囲み、そこまで自動でスクロールします。 確認にかかる時間が、ページを開いて読む時間ではなく、囲まれた数行を読む時間になります。

利用者から見ると、「答えを読む」と「根拠を確かめる」が同じ画面で連続します。 ここが、この形のいちばんの違いです。

2. なぜコールセンターだと、この形が要るのか

一般的な社内チャットボットなら、答えだけ返せば足りる場面も多いと思います。今回この形にしたのは、使う場面がはっきりしていたからです。

オペレーターの方は、AI の答えを読んで終わりではありません。それを自分の言葉で、電話の向こうのお客様に伝えます。

つまり、答えは一度かならず人を経由して外に出ます。そして間違えれば、そのまま実害になります。金額や期限や条件を1つ言い間違えれば、お客様への謝罪と訂正が発生します。

この立場の人にとって必要なのは、「たぶん合っている答え」ではありません。「数秒で確かめられる答え」です。

同じ理由で、次のような場面でも同じ形が向くと考えています。

お客様に読み上げる／そのまま送る内容を扱う業務（コールセンター、窓口対応、サポート）
間違えると金銭や契約に影響する業務（料率、手数料、期限、適用条件の案内）
新しく入った方が、資料の場所ごと覚える必要がある業務

3つ目は、実際に作ってみて気づいた点です。根拠のページが毎回開くので、使っているうちに「この種の質問はこのページに書いてある」が身につきます。 答えだけを返す形だと、これは起きません。

もうひとつ、判断が要る問い合わせは、最終的にスーパーバイザーに確認してから回答するという流れも変わりません。このとき、AI の回答と根拠のページがそろっていれば、そのまま相談の材料になります。 「これってどうでしたっけ」から始めるより、どの規程のどの記述の話なのかが最初から共有できるぶん、確認は短く済みます。

逆に言えば、雑談や発想の壁打ちのように根拠が要らない用途では、この形はむしろ邪魔になります。 出典カードのぶん画面が重くなり、応答も遅くなるからです。

3. 根拠を出すために、中で2つのことをしています

「出典を付ける」は、プロンプトに「出典を書いてください」と指示するだけでは成立しません。指示だけだと、もっともらしい出典番号を創作します。 実際に今回も、AI が実在しない電話番号を回答に書いたことがありました。

そこで、2つの関門を置いています。

① 調べてから答える。無ければ「確認できませんでした」と言う

AI には「まず調べる」ことを義務づけていて、記載が見つからなければ、正直にそう答えます。 数値・期限・条件を推測で埋めることを明示的に禁止しています。

さらに、お客様向けの案内文については、AI に文章を作らせていません。 既存の定型文をそのまま引いてきて、変わる部分だけを差し替える形にしました。案内文は表現が決まっているものなので、生成する必要がないからです。

② 出てきた数字を、機械で出典と突き合わせる

2つのうち、いちばん実害を止めたのがこちらです。

回答に電話番号・金額・長い数字・URL が出てきたら、それが取り出した出典の中に文字列として存在するかを、プログラムで確認します。 見つからなければ、画面にこう出ます。

この値は出典に含まれていません。そのまま使わないでください。

対象を「間違えると実害が出る値」に絞っているのがポイントです。日付やパーセントまで対象にすると、表記の揺れで誤検出だらけになって誰も見なくなります。

プロンプトで禁止しても、AI は数字を作ることがあります。 ならば、出てきた後に機械で照合する関門を置く。ここは人の注意力に頼らない設計にしました。

4. いまの実測値と、まだ検証中のところ

営業デモとしてお出しする以上、体感ではなく数字が要ります。実際のデータから100問の想定質問セットを作り、実機に投げて測りました。

項目	実測
正答率	8割前後（7回計測で 75〜82%）
応答時間	10秒以内が100問中 97〜100問／完了まで中央 4.3秒
英語での質問	10〜13秒（日本語より遅い）

ただし、この数字はまだ確定値ではありません。 ここから上がる見込みのある要素が、いまの時点で3つ見えています。順に書きます。

① 100問は、お客様の実際の問い合わせではない

この100問は、資料の中に「〜はできますか。」のような疑問文の形で書かれている見出しを機械的に抜き出し、そこから逆算して作ったものです。実際のよくある質問の一覧をいただいたら、測り直す必要があります。

外した分の中身も見ました。外れた質問を1件ずつ確認したところ、「資料に情報が無かった」はゼロでした。すべて資料にはあるのに引けなかった、あるいは古い年度のほうを引いたという型です。つまり、精度を上げる余地は検索側にあって、資料側にはない、ということが分かりました。

② 資料の新旧が入り混じっている

長く運用されている資料には、同じ主題の古い版と新しい版が両方残っています。今回外した分にも、古い年度のほうを引いてしまったケースが含まれていました。

いまは更新日で新しいほうに加点する形で対応していますが、資料の側を整理すれば、この型の間違いはそのまま減るはずです。 ここはまだ試していないので見込みですが、精度を上げる手としてはいちばん素直だと考えています。

③ 英語の遅さは、探し方を変えれば縮められそう

英語での質問が遅いのは、英訳のあるページが4割強しかなく、探し直しが増えるためです。

日本語の資料で検索して、回答を書くときだけ英語にする、という組み立てにすれば速くなるのではないか、と見ています。ここもまだ試していません。 現時点では仮説です。

5. さらに、権限による表示制御を搭載しました

ここまでは「根拠を添える」話でしたが、今回はもうひとつ、立場によって見えるものを変える仕組みを載せています。

社内の資料には、誰が見てもよいものと、そうでないものが混ざっています。今回のシステムには閲覧権限が7種類あり、スーパーバイザーだけが見られる情報、オペレーターまでは見られる情報、現場の窓口担当者にも見せる情報、という具合に分かれていました。

AI チャットボットを載せるとき、ここは避けて通れません。全部読ませたうえで「これは言わないで」と指示する形にすると、言い方を変えられた時点で外れます。

見えないものは、AI の手元に渡しません

今回は、検索するときの SQL の条件式に権限を入れました。 その立場で見えない本文は、そもそも AI に渡りません。渡っていないものは、どう聞かれても答えられません。指示ではなく、経路で止めています。

同じ条件を、3つの経路すべてに効かせています。

経路	効かせ方
検索	検索の条件式そのものに権限を入れる
ページの表示	見えないブロックは、表示の段階で置き換える
添付ファイル	ファイルの配信そのものを権限で判定する

3つ目が抜けやすいところです。本文だけ絞っても、添付ファイルが素通しなら結果は同じだからです。

画面の上部で立場を切り替えると、同じ質問でも答えが変わります。 上の画面イメージにある「どの立場で見るか」がそれです。

実際に攻撃してみて、確かめました

作ったあとで、自分たちで侵入テストを行いました。

システムへの指示文を引き出す試み、役割になりきらせる試み、仮定の形で聞き出す試み、他言語で聞き出す試み、5回の会話を重ねて誘導する試み —— これらはすべて防げていました。権限を条件式の側に置いた設計が働いています。

一方で、実装の抜けも見つかりました。 立場を切り替えたときに前の会話が残っていて、そこから上位権限の内容が出てしまう、という穴です。会話の履歴に、切り替える前に取り出した本文がそのまま残っていたためでした。立場が変わったら履歴を捨てるように直して塞いでいます。

設計が正しいことと、実装に穴がないことは別でした。攻撃してみるまでは「守れている」とは言えないというのが、ここでの実感です。

6. この形が向くかどうかの見分け方

同じ作りが、どの会社でも効くわけではありません。作ってみて分かった見分け方を書いておきます。

向くのは、次の3つが揃っている場合です。

社内に、答えが書いてある資料がすでにある（規程・マニュアル・FAQ・過去の対応記録）
その答えを、人が確認したうえで外に伝える（お客様、取引先、応募者など）
資料が更新され続けている（古い版と新しい版が混在している）

3つ目は意外に思われるかもしれませんが、更新が続いている資料ほど、この形の価値が出ます。 更新日を出典カードに出して「新しいほうを採る」ようにできるので、人が探すより間違えにくくなるからです。

逆に、資料そのものが整備されていない領域では、AI を入れても答えは出てきません。 ただし今回、それも収穫のひとつになりました。AI が答えられなかった質問の一覧が、そのまま「資料に足りていないところの一覧」になるからです。毎日更新されている社内資料なら、AI が穴を見つけて翌日には埋まる、というサイクルが作れます。