顧客向けチャットボットの基礎

皆さん、こんにちは！林です。今日は企業向けAIチャットボットの基礎を説明しようと思います。

企業向けのAIサービスは、いわゆるGoogleのGeminiやOpenAiのChatGPTなどの学習済みの生成AIをそのまま入れても、社内情報を返すことはできません。そりゃそうです。社内情報を学習してませんから。

しかしとはいえ、

会社の製品に関する情報や、社内情報を返してくれるチャットボット

ということをどうしてもやりたくなるのです。これができれば、企業は大幅なコストカットになるからです。

なので今回は、これを実現するための基礎。しかもなるべく実務者の方が参考にできるような説明をします。なるべくむずかしい言葉を避けて整理します。

生成AIは日進月歩が非常に激しいですが、それでも陳腐化しないように原理原則を説明できるように心掛けたつもりです。なので、新しいツールや技術がどんどん出てきたとしても、こちらの記事の内容は参考になるのではないかと思います。不明点が出たら、適宜こちらの記事を参照して頂ければと思います。

第1章 どのようにして動いているのか

繰り返しになりますが、既存の生成AIのままだと企業情報は参照せず、製品やプランの違いを分けず、出典も示すことだできません。これだと企業独自のチャットボットとして導入できません。

しかしながら、生成AIを一から作るのはとんでもなく技術も費用もかかります。よってそれは現実的ではありません。サム・アルトマンにはなりたくありません（笑）。なので、既存の生成AIエンジンを利用し、そこに企業情報を検索させる機能を追加したチャットボット作る、というのがベーシックなアイディアです。RAG、という手法を用いるのですが、細かいことは気にしなくてよいです。

その企業向けボットはどういう仕組みで動いているのか？これには大きく分けて6つのステップあります。以下のようなイメージです。

1. 質問を受け取る

   文章から何を知りたいかをつかみ、含まれていれば製品・プラン・購入経路などの条件も読む。足りない条件は短く聞き返す。

2. 範囲をしぼる

   公開かつ現行版のページに限定して、該当外のプロダクト・旧バージョンの説明はここで除外する。

3. 探す

   ことばで検索しつつ、言い回しが違っても同じ内容を拾えるよう意味の近さでも探す。わかりにくいかもしれませんが、言葉そのもので検索をかけると全く同じ言葉しか引っかかりませんので、数値にして検索をします。

4. 条件で整える

   集めた候補から製品、プラン、販売チャネル、更新日に合わないものを除く。重複はまとめ、順序を整える。

5. まとめる

   • 結論（1行）

   • 根拠（ページ名・見出し・更新日・リンク）

   • 次の一歩（手続き先）

     の順で回答を返す。

6. 答えられない時は止める

   個人情報が必要／条件が不足／該当ページなしは推測しない。できないと伝え、有人窓口へ案内する。

第2章：仕組みの全体像

じゃあ、今度は、どのようにして作るのか、さくっと説明します。全体像の把握にとどめて頂いて、細かいことは気にしなくて大丈夫だと思います。detailは、全体像を掴んだ後に深堀りして理解頂ければよいかと思います。

1. 集める：対象文書を最新バージョンを準備する

   では始めましょう。まずは対象となる文書の最新バージョンを用意します。

   • 部門ごとに似たファイルが散財している

   • 改定日が、まちまち

   • 最新バージョンと古いバージョンが混在している

     こんな状態だと、そもそものデータソースがいまいちってことですから、作り込んでも正しい答えは絶対に返ってきません。なので、まずは最新バージョンを用意することが大切です。

     その上で、対象データの種類（FAQ、規程、マニュアル等）をはっきり明示し、最新版だけを1箇所に集め、改定日と公開可否などの平仄を揃えます。

2. 切る（Chunking）：文書を「ひと息で読める塊」に分ける

   次に、文書を塊に切っていきます。現状のままだと、1つの長くて大きいドキュメントがどかっとあるだけの状態です。こうなると、章や項が長いままになってしまうので、ユーザの欲しい文章やワードは取得しにくい状態です。

   なのでこれをどうするかというと、一塊で、読みやすいサイズに分けます。例えば以下のような感じです。

   • FAQはQとAを一体に。
   • 規程は条・項・但し書きをひとまとめに。
   • マニュアルは前提・操作・確認をセットに。

   そして、この塊ごとに、見出し、章節、改定日をメタデータとして紐づけて保存します。

   これで、答えの場所を指名しやすくなり、引用も一発で決まるようになります。

   ちなみにこの1つの塊のことをチャンク、といいます。この言葉は重要なので、是非覚えておいて下さいね、チャンク、ですよ、チャンク。

3. 各チャンクを「意味を表すベクトル」にして保存する（Embedding）

   次に、チャンクのワードを数列に変換します。現状だと、例えば

   • 在宅勤務
   • リモート勤務

   のこの2つは、人間が聞くと、同じことやがなー！ですが、ボットに検索をしても、同じものとは判断してくれません。

   なのでこれをどうするかというと、各チャンクを意味のベクトルに変換し、似た内容順に並び替えるのです。社内の略称や別名を対応させ、数字・日付・章番号といった手がかりは残します。これで、言い回しが違っても、似た意味の候補を拾えるようになります。

4.  索引（Indexing）：各チャンクを「ことば・意味・条件」で検索できるようにする

   では、次のステップです。通常、検索といえば、文字列としての検索のみを思い浮かべる方が多いのではないかと思います。でも生成AIを企業に導入する際には、もっと良い方法を用います。以下の3つの方法です。

   • テキスト索引
   • ベクトル索引
   • メタデータ索引

   それぞれ見てゆきましょう。

   • テキスト索引

   その文字の通り、キーワード一致で引く方法です。これは先程申し上げたよくある方法ですね。

   例としては、質問「返品 期限」を投げると「返品ポリシー＞期間」を返すようなものです。

   • ベクトル索引

   文章を意味の数列にして近さで引く方法です。言い換えや表記ゆれに強いです。全く同じテキストでなくても、検索できるようになります。

   ベクトル化することにより、テキスト索引では出来なかったような、「サブスク 解約」という質問を投げた際の「定期購入の解約」や「自動更新の停止」といった回答が返せるようになります。

   • メタデータ索引

   ページにつけた付せん情報、例えば

   • 公開範囲
   • 購入チャネル
   • プラン
   • 商品カテゴリ
   • 更新日

   で先に絞る方法です。これにより、ユーザーが例えば「プラン=スタンダード」や「チャネル=オンライン」といった指定に結果を返せるようになります。

   そして、検索時は適切な権限管理も重要です。他部署のドキュメントや、或いは見るべきではないそれらが見れてしまった場合、社内であっても立派にインシデントになりますし、顧客向けのボットであればなおさら影響範囲は甚大です。ですので、権限管理を行ったデータソース、そして最新バージョンだけを検索対象にします。そのあとで上の索引を引き、出典・章節・改定日つきで返します。

   このステップを踏むことにより、古い条文や対象外を先に外した上で、　関連性の高い上位候補が出せるようになります。

5. 検索：「上位の複数候補」を集める

   キーワード一致だけでは、漏れが発生します。かといって逆に意味検索だけでは似すぎた候補が固まってしまい、例外を見落としてしまいます。さらに、購入チャネル、プラン、商品カテゴリといった条件一致を無視すると誤案内が増えます。これらも合わせないといけません。やることいっぱいですね笑 

   そこで、今挙げた語彙検索×意味検索×条件フィルタを組み合わせて、最後にリランキングといって候補の再順位付けを行うことで精度を上げます。

   そしてここで、1件だけを残すのではなく、3-5件を残すようにします。次の工程で矛盾解消や例外の提示を行えるようにしておくためです。

6.  組み立て：引用を先に確定し、要約を最小限にして回答カードの型に流し込む

   5までで、上位3-5件の候補から抜粋・出典・条件を束ねたコンテキストができました。しかしこのままだと、同じ内容の重複や原則と例外の混在が起きやすく、要約が長くなって出典や次の行動が見えづらいままです。

   まず、このまま、つまり5までで終わると、どう見えるかを確認してみましょう。AからDまで全て、利用者が受けるとイラッとする回答ばっかりの例を作ってみました笑

   A：要約だけで根拠がない

   回答：返品は一定期間内で可能です。詳しくはポリシーをご確認ください。

   問題：日数（30日or14日）がなく、出典・更新日・URLもない。

   B：リンク列挙だけで結論がない

   回答：関連情報はこちらです。・返品ポリシー ・店舗での返品 ・返品フォーム

   問題：結論ゼロ、注意/例外なし。読者が読み直す必要がある。

   C：引用の並べるだけになっている

   回答：・オンラインは30日 ・店舗は14日

   問題：結論が出ていない、次の一歩なし。

   D：結論がなく、読み手が迷う

   回答：返品は30日ですが、場合によっては14日のことも…

   問題：条件が不明、出典・更新日なし、導線なし。

   しかし、実際には、私達はこういう回答が欲しいわけです。

   **結論：**オンライン購入は30日以内、店舗購入は14日以内に返品できます。

   **出典：**返品ポリシー＞期間／店舗購入（更新日：2025‑04‑01、URL）

   **注意/例外：**開封後の衛生商品は対象外です。

   **次の一歩：**返品フォームを開く／最寄り店舗を探す

   そのためには、まず根拠となる一文を先に確定し、重複を外して矛盾を整理した上で、結論を1行に絞り、回答カード（結論→出典→注意/例外→次の一歩）の順に並べ替えて整えます。

   これにより、数字や条件を原文どおり保った短い結論になり、根拠にすぐ戻れて、フォームやマイページへの導線が明確になります。その結果、一次解決率が上がり、再問い合わせが減り、現場で役に立つようになります。

7.  答える：読み手に「次の一歩（申請先・期限・連絡先）」を示す

   最後は、回答カードの下段に申請先・期限・連絡先を固定で置き、通知や共有にそのまま使える形にします。これで、ユーザーの質問にしっかりと答えられた上で、必要に応じて問い合わせ先へと中継できることになります。

第3章 運用

実際の運用では、ヘルプ、ポリシー、料金、配送、保証、製品ガイドなどの主となるドキュメント(ここでは主文書といいますね)とは別に、補助データも、2章で見てきたステップである chunk → embedding → indexingを行って持っておきます。

1. 主文書インデックス

はい、これは根拠となる本文です。これは2章で見てきたましたね。

• 用途：回答の根拠を探す土台。

• 登録：1単位＝1要点でチャンク化し、意味に変換（embedding）して索引（indexing）に入れる。

• 使い方：検索時に上位3〜5件を取り、コンテキスト（上位抜粋＋出典＋条件のセット）を作る。

  2. 回答カード用インデックス

• 用途：回答の並びと表現の型を安定させる。結論、出典、注意or例外、次の一歩の順を守るための参照用。

• 登録：1カード＝1チャンクでembedding→indexing。カード名をつけること。これは例えば、「返品_基本」や「配送_通常」のようなものでよい。

• 使い方：組み立て時に主文書インデックスの上位候補と合わせて参照し、コンテキストをその型に沿って配置する。この時、結論1行、出典表示、導線を必ず載せることが必須です。

  何やら抽象的でよくわからんと思うのですが、例にすると以下のようなイメージです。

• カード名：返品_基本

• 結論：オンライン購入は到着から30日以内に返品できます。

• 出典：返品ポリシー＞期間（更新日：20XX‑XX‑XX）

• 次の一歩：返品フォーム／店舗検索

  このように、主文書に直接混ぜないで、「型」だけを別インデックスにしておくと、文章の整え直しが早くなります。

  3. 言い換え表インデックス

  お客様の言い回しには、複数のバリエーションがあります。これらのバリエーションをうまく仕様側で吸収できるようにするとよいわけです。そのためには、言い換え表のインデックスを作る必要があります。クエリの拡張に使います。登録は、1行＝1チャンクの短文でembedding→indexingを行います。使い方としては検索の最初に参照し、質問語を同義語で広げてから主文書を検索します。簡単ですね。

  例としては以下のような感じです。

• 例：

  • 返金＝払い戻し
  • サブスク＝定期購入＝自動更新
  • ギフトレシート＝ギフト用領収書
  • 追跡＝配送状況の確認
  • 再配達＝再配送

  ここまでみてきたものをまとめると、使い方のフローとしては以下のような感じになります。

  • 言い換え表インデックスで質問語を広げる。

  • 広げた語で主文書インデックスを検索し、上位3〜5件でコンテキストを作る。

  • 回答カード用インデックスを参照し、結論→出典→次の一歩の型で短く整えて返す。

    イメージつきましたでしょうか？

1.  日々の運用作業

   いい加減疲れていませんか？もう少しで終わりますので、もうちょっとだけ我慢して下さいね。今回は辞書的に記事を書いていますので、運用時に、あ！あそこに書いてあった！と思って頂き、適宜参照して頂ければ大変幸いです。

   はい、では、dailyの運用について考えておきましょう。当然のことながら、100%の精度は難しいわけです。なので日々改善を繰り返すようなイメージになります。

   運用担当は前日のチャットログを確認し、外れた回答を何件か選びます。3件ぐらいが良いかな、と思います。運用担当はその外れた原因を

• 探し方

• 切り分け

• 言い換え

• 見せ方

  のどれか1つに分類し、原因となった項目の修正を行います。修正内容としては、例えば、言い換え表の追加、タグ修正や、回答カードの並び調整などになろうかと思います。

  以下に、原因ごとの修正例を書いておきます。これでだいぶイメージつきやすくなるのではないかと思います。

  **言い換えが原因：**言い換え表インデックスに1行＝1チャンクを追加し、embedding→indexingを更新する。

  **見せ方が原因：**回答カードインデックスの該当カードを1カード＝1チャンクで差し替え、embedding→indexingを更新する。

  **探し方／切り分けが原因：**主文書インデックス側のタグやチャンク境界を見直し、再登録を行う。

  以下に、外れ回答の例を示しておきます。ご参考頂ければと思います。

  A. 探し方（検索・絞り込みの問題）

  シナリオ：お客様は「返品は何日以内ですか？」と質問した。

  実際の答え：ボットは「30日以内です」と答えた。

  問題：ボットは購入チャネル（オンライン／店舗）で先に絞っていないですよね。サイト上の店舗購入は14日という条件があったとして、それを無視したことになります。加えて、コンテキストに改定日やチャネル条件が入っていないです。

  対処：運用担当は検索の入口を「チャネル > ことば > 意味」の順に固定する必要があります。そして、運用担当は返品ページにチャネル・改定日のタグを付けるべきです。

  修正後：ボットは「オンライン購入は到着から30日、店舗購入はレシート日付から14日です。出典：返品ポリシー＞期間（更新日：20XX‑XX‑XX）。次の一歩：返品フォーム／店舗検索」と答える。これで解決です。

  B. 切り分け（ページの分け方の問題）

  シナリオ：お客様は「配送は何日かかりますか？」と質問した。

  実際の答え：ボットは「通常は2〜4営業日です」とだけ答え、長い但し書きは省いた。

  問題：対象となる文書が、通常品と例外（大型商品／取寄せ）を同じ塊で持っており、検索プロセスが、途中の文を拾って結論がぼやけた。

  対処：運用担当は配送ガイドを1単位＝1要点で切り直し、通常配送のチャンクと例外（大型・取寄せ）のチャンクを分けるのが良いと思います。そして、各チャンクに見出し・章節・更新日を紐づけします。コンテキストは通常→例外の順とします。

  修正後：ボットは「通常品は2〜4営業日です。出典：配送ガイド＞通常配送（更新日：…）。大型商品／取寄せは＋2〜3日。詳細は同ガイド＞例外をご確認ください。次の一歩：注文履歴で追跡」と回答できるようになります。

  C. 言い換え（お客様の言葉とサイトの言葉のずれ）

  シナリオ：お客様は「サブスクの解約方法は？」と質問した。

  実際の答え：ボットは「見つかりません」と答えた。

  問題：ドキュメントには「定期購入」「自動更新の停止」とあったとして、言い換え表にサブスク＝定期購入＝自動更新が登録されていないことが原因ですね。

  対処：運用担当は言い換え表インデックスに「サブスク＝定期購入＝自動更新」を1行＝1チャンクで追加し、embedding→indexingを更新。解約ページにも別名タグを付ける。

  修正後：ボットは「定期購入（サブスク）の解約はマイページ＞定期購入＞自動更新の停止から行えます。出典：定期購入ガイド＞解約（更新日：…）。次の一歩：解約手続きページ」と回答できるようになります。これで解決です。

  D. 見せ方（回答の並び・導線の問題）

  シナリオ：お客様は「保証でバッテリー交換は無料？」と質問した。

  実際の答え：ボットは制度説明だけを返し、出典や手続き先を示さなかった。

  問題：回答カードが結論→出典→次の一歩の順になっていない。コンテキストにある出典（ページ名・見出し・更新日）を表示していない。

  対処：運用担当は回答カードインデックスのカードを見直し、1カード＝1チャンクで差し替えてembedding→indexingを更新。回答は1行の結論 > 出典 > 注意or例外> 次の一歩（修理予約）に揃えるべきです。

  修正後：ボットは「保証期間内の自然故障はバッテリー交換が無償です。出典：保証ポリシー＞対象部品（更新日：…）。次の一歩：サポート＞修理予約」と回答できるようになります。

  チェック項目をまとめると

  • 購入チャネル／プラン／最新版で先に絞ったか。

  • 通常と例外を別の塊で見せたか。

  • 言い換え表インデックスにお客様の言い方が載っているか。

  • 結論→出典→次の一歩の順で出しているか（回答カードインデックスを使えているか）。

  といったところかな、と思います。

2. ドキュメント更新時

   各部門の担当者は、更新したドキュメントを運用担当に渡します。運用担当は旧バージョンについては検索対象外にした上で、最新バージョンを登録します。登録時は、ドキュメントを適切なチャンクに分けた上で、購入チャネル・プラン・商品カテゴリ・改定日のタグを付ける必要があります。

   そして、ドキュメントなどの更新に合わせて、案内の内容が変わった場合は回答カードインデックス、用語が変わった場合には、言い換え表インデックスの変更が必要になります。これは3-1で説明したのと同じことです。そして該当カードや該当行を再チャンク→embedding→indexingすることになります。この作業をすることにより、ボットは古い情報や対象外の条件を返さなくなります。

3.  表現のバリエーションを増やす

   会社側で表現のバリエーションをある程度用意はされるとは思うのですが、お客様側でどんな言い回しがあるかまでの想定には、限度があるかと思います。ですので、運用担当は問い合わせ文と検索ログからお客様の言い方を拾います。例えば以下のようなイメージです。

   • 返金＝払い戻し

   • 再配達＝再配送

   • ギフトレシート＝ギフト用領収書

   運用担当は言い換え表インデックスに1行＝1チャンクで追加し、embedding→indexingを更新する。更新後は、正答を返すかどうか、10問程度の質問を投げて確認したほうが良いと思います。この作業を繰り返すことでで、ボットは表記の違いに強くなります。

4.  毎週の品質確認

   品質が低下していないかどうかを確認するために、毎週、同じ内容でよいので、10問程度の質問を実行してみるのが良いと思います。

   そして各回答の結論・出典・更新日を確認し、コンテキスト（抜粋＋出典＋条件）が揃っているかどうかを確認します。そして外れ回答を見つけたら、外れが多いカテゴリ（探し方、切り分け、言い換え、見せ方）から修正を依頼し、必要なら該当インデックス（主文書／回答カード／言い換え表）を更新し、改善を繰り返します。

5.  見せ方の調整

   回答カードの順序は、

   • 結論
   • 出典
   • 注意／例外
   • お問い合わせ等次のアクション

   の順に保つようにしましょう。結論は1行にそろえ、出典リンクをすぐ後ろに置き、手続きリンク（返品フォーム／修理予約／注文追跡）を最新にする。

   表現の型を変えた場合は、くれぐれも、回答カードインデックスの該当カードを再チャンク→embedding→indexingしておくようにして下さい。

6.  例外や本人確認が必要な質問の扱い

   注文番号が必要な質問、本人確認が必要な質問、公開範囲外の情報を含む質問を検知した際には、個別事情になりますので、答えるべきではありません。これが答えられたら逆にえらいことです。なのでこういう場合にはボットは推測をやめて「できません」と伝えるようにします。そして、有人窓口（チャット、メール、電話）の導線と案内文を最新に保つようにしましょう。

7.  月次の棚卸し

   月次で、不要なデータの削除やタグの最適化が必要になります。具体的には使われないチャンクと旧バージョンを確認し、削除、或いは非公開にします。そしてタグ（購入チャネル・プラン・商品カテゴリ・改定日）を見直し、当たり具合と外れの内訳をまとめて次月の改善に回す。陳腐化した言い換え行も、インデックスから削除して軽量化すると良いと思います。使われない言い回しなんて不要ですから。

第4章 さいごに

非常に長い文章になってしまいましたが、これで運用まで見越して、導入を検討頂けるのではないかな、と思います。企業向け生成AIのチャットボットは、万能なものではありません。なので、日々の運用を地味にこつこつと推進する必要があります。ただそれでも、人が張り付いて顧客向けに回答するよりはずっと人件費の削減になるはずです。是非行ってみて下さい。