AIチャットボットは導入すべき？FAQと人への引継ぎを比べる方法

何を解決するために導入する？

最初に決めるのは、ボットの機能ではなく、問い合わせのどこで顧客と担当者が困っているかです。「電話を減らしたい」だけでは、案内を見つけにくいのか、当日の確認が多いのか、担当不在で返事が止まるのかが分かりません。原因が違えば、先に直す場所も変わります。

この質問には、通常の受取時間を知る用事と、今日受け取れるかを確かめる用事が混ざっています。通常案内がサイトの奥にあり見つからないなら、まず案内の見出しやリンクを直す案が考えられます。一方、今日の在庫を誰も確認していないなら、案内をすぐ表示できても受取可否は確定しません。

最近の問い合わせを、自社で利用が認められた範囲で振り返ります。顧客が知りたかったこと、案内のどこに答えがあるか、担当者が追加で確かめたこと、返事が止まった場所を分けて読みます。個人名や注文内容を外部AIへ渡さなくても、質問の種類と仕事の流れを整理するところから始められます。

試行の目的も具体化します。たとえば「通常の案内へ迷わずたどり着けること」と「当日可否を確認する窓口へ必要事項が届くこと」は別の目的です。回答が表示された回数だけを数えても、受取の用事が終わったかは分かりません。誤った約束、途中で止まった質問、担当者に残る確認まで含めて見ると、採用する理由を説明できます。

FAQ・回答下書き・顧客向けボットをどう比べる？

FAQは、よくある質問と答えをまとめた案内です。回答下書きは、AIが作った案を担当者が資料と照合してから返信する使い方です。ここでいう顧客向けボットは、顧客がサイト上で質問し、システムがその場で案内を返す使い方を指します。担当者が間に入る位置が違うので、同じ条件で比べます。

この表は試す項目で、三方式の成果を測った結果ではありません。同じ質問でFAQの答えと窓口を見つけられ、目的の案内へ進めるなら、FAQの改善を選ぶ判断ができます。回答下書きは、資料との照合と返信を含めた負担が、自社の許容する範囲に収まるかを試してから選びます。顧客向けボットは、通常案内の条件を保ち、未回答の用事が窓口へ届くことを実際の掲載先で確かめられた範囲に限って検討します。個別確認が多いという理由だけで、AIの下書きが役立つとは決めません。

同じ資料と質問で、仕事全体を見る

比較には同じ現行資料と質問を使います。FAQ側だけ古い資料にしたり、ボット側だけ簡単な質問にしたりすると、方式の違いを確かめにくくなります。資料が変わった場合は、その変更と試した版を記録し、異なる条件の結果を混ぜません。

見る範囲は、回答が出るまでの時間だけではありません。FAQを直す、案を確認する、担当へ渡す、返事をまとめる、ボットの資料を更新する仕事まで含めます。ボットが即答しても、担当者が後で誤った約束を訂正しているなら、その訂正を負担から外さないでください。

採用の判断は「AIが使えるか」より「この用事を、許容できる確認と費用で終えられるか」です。FAQの改善で十分なら、その方法を続けます。下書きが役立っても顧客への直接回答が合わないなら、人が確認する範囲にとどめます。直接回答を試す場合も、通常案内など対象を絞り、結果を確かめてから広げます。

担当者向けの案の作り方と照合は、FAQを使ったAI回答案と人への引継ぎで詳しく説明しています。ここでは、その使い方も含めて導入方法を選びます。

どの資料を使わせ、何を答えない？

顧客へ直接案内するボットには、外部へ示してよい現行資料を用意します。社内で読める文書でも、そのまま顧客に見せてよいとは限りません。公開用の受取案内と、社内の個別判断・取引条件を分け、どの資料をどの利用者向けに使うかを決めます。

架空例の案内にあるのは「通常、平日の営業時間内」という条件です。「今日受け取れる」という結論は書かれていません。ボットの説明が自然でも、通常案内から今日の在庫や営業を補ってしまえば、会社が確認していない約束になります。引用リンクが付いていても、リンク先の原文がその約束を支えているかを読む必要があります。

資料ごとに現行版、適用する対象、更新する担当を確かめます。臨時休業の案内が通常案内と別にあるなら、両方が検索と回答に反映されるかを試します。内容が食い違う場合は、日付が新しいという理由だけで片方を採用せず、どの案内が適用されるかを会社の資料責任者へ確認します。

製品の設定にも条件があります。Microsoft Copilot Studioの公式FAQは、生成回答が参照資料自体の正確さを自動確認するものではないと説明しています。また、同製品の情報源は種類により認証条件が異なります。「社内資料につないだから、元の閲覧権限がどの接続方法でも自動で守られる」と一般化せず、使う資料・接続方法・利用者で確かめます。

製品仕様の根拠：Copilot Studioの生成回答FAQ、情報源と認証条件。他製品の仕様や安全性を保証する説明ではありません。

資料に答えがない、質問の条件が足りない、複数資料が矛盾する場合も設計の対象です。質問を詳しく聞くと解けるのか、資料そのものが不足しているのか、人の判断が必要なのかを分けます。どの場面でも長い回答を作ることを目指さず、必要な案内を返せない場合の表示と窓口を用意してください。

RAGは、質問に関係する資料を探して、その内容を回答の材料へ渡す仕組みです。資料を使う回答の構造と社内向けの準備は、RAGの仕組みと社内資料の準備を参照できます。RAGという名前だけで、顧客への案内が正しいと判断しないことが大切です。

人への切替は、案内を出せば完了？

「担当者へお問い合わせください」と表示することと、人が問い合わせを受け取り、確認して返事をすることは別です。導入前には、どこまでをシステムが運び、どこからを顧客や担当者が操作するのかを、実際の画面と窓口で確かめます。

連絡先の表示と、会話の転送を分ける

既存のお問い合わせページを案内する方式なら、顧客が自分でページを開き、必要事項を送る場合があります。ボットとの会話が自動で窓口へ渡るとは限りません。顧客へ同じ説明をもう一度求めるなら、その手間も比較に含めます。

会話を人へ転送する方式なら、窓口システムとの接続と、担当者が受け取る画面が必要です。Copilot Studioの公式手順でも、人への実転送には接続条件があり、未接続の場合の連絡先案内とは区別されています。利用する製品で、履歴、質問、確認済みの内容、未確認の用事のどこまでを渡せるかを確認します。

製品仕様の根拠：Copilot Studioの人への引継ぎ。接続先や構成により扱える情報・操作は変わります。

部品受取の例なら、「通常案内は表示した」「今日の在庫・営業・受取可否は未確認」「顧客は今日の受取を希望している」というつながりを残します。「在庫の質問」とだけ要約して渡すと、営業時間の案内や今日の受取という目的が抜けるかもしれません。試行では、窓口で元の質問と残る確認を読み取れるかを見ます。

担当者が不在の時間を、先に試す

時間外にボットが案内を返せても、人が確認を始められる時刻は会社の体制によって決まります。窓口不在のときは、既存の連絡方法、確認を始める目安、緊急時に使う正しい案内を決めます。実際には対応できない即時返信や、確定していない受取を約束する表示を置かないでください。

引継ぎの状態も分けます。リンクを表示しただけか、問い合わせの送信が終わったか、窓口に届いたか、担当者が受領したか、返事が戻ったかを同じ「完了」にまとめません。送信や接続に失敗した場合は、顧客が再試行や別の連絡方法を選べるかを確かめます。

公開前と資料変更後に何を試す？

公開前は、答えを返せそうな質問だけでなく、答えてはいけない質問も用意します。各質問について、使うべき資料、残す条件、答えられないときの動作を先に決めると、もっともらしい返事を見てから合格にすることを防げます。

実行時には、必要な資料が取得されたか、回答がその条件を保ったか、人へ渡す用事が残ったかを分けて見ます。違う資料を選んだのか、正しい資料の例外を回答で落としたのか、転送だけが失敗したのかで、直す対象が変わります。Amazon BedrockのRAG評価にも、検索のみと検索・生成を組み合わせた評価の区分があります。ただし、その機能だけで窓口の受領や顧客の用事の完了まで確かめたことにはなりません。

評価の区分の根拠：Amazon BedrockのRAG評価。ここに挙げた試験表は記事独自の例です。

テスト画面に加え、実際の掲載先でも確かめる

製品のテスト画面で返事が正しくても、会社サイトへの埋め込みや、接続した窓口で同じ動作になるかは別に確認します。スマホで案内を読めるか、チャットを閉じても通常の案内や連絡先に戻れるか、切替先で質問が失われないかを試します。ページ表示を妨げる位置や、使い方の分からない入口も見直します。

Copilot Studioの公式資料も、テスト画面は公開先のすべての動作を再現するものではなく、無操作時間や背景のイベントなどは対応するチャネルで確認が必要な場合があると説明しています。自社で使う掲載先と接続方法に合わせて、必要な動作を確かめてください。

製品仕様の根拠：Copilot Studioのテスト方法。一つの製品のテスト成功を、別製品や別の掲載先へ当てはめません。

一度通った質問も、資料や受付条件が変われば再確認の対象になります。臨時休業、受取方法の変更、窓口交代など、案内に影響する変更を起点に、該当する質問をもう一度試します。資料の更新担当と、ボットへ反映する担当が違う場合は、どこまで反映が終わったかを確認できるようにします。

対象の質問、資料の版、試した日時と掲載先、期待した案内、実際の回答・切替結果を残します。結果がない欄を成功や0件へ置き換えず、未確認として分けます。狭い試行でうまくいったことは、その質問と条件の範囲の結果です。すべての顧客や将来の資料まで同じ成果が続く保証にはしません。

月額料金のほかに何の仕事が残る？

費用は製品の月額だけで決めず、自社で終えたい仕事と依頼範囲をそろえて比較します。利用者数や会話量に応じた料金、前提となる契約、初期設定、窓口との接続、試験、運用と変更への対応を分けます。どの方式が安いかは、自社の利用量と契約・残る作業を確認するまで決まりません。

会社側には、使ってよい資料を決める、通常案内と個別判断を分ける、期待する返答を確認する、資料と窓口を更新する仕事が残ります。依頼先が設定を担当しても、今日の営業や在庫を誰が確かめ、会社として何を案内するかは別に決める必要があります。外注費と社内作業を分けると、見積に含まれない負担を見つけやすくなります。

FAQの改善案と比べる場合も、同じ用事が終わる範囲にそろえます。FAQは案内を整える費用、ボットは会話機能だけの費用という比較では、必要な人への確認が片方から抜けるかもしれません。見積ごとに、どこまでが完成した状態か、何を自社で用意するか、どの変更から追加費用になるかを聞きます。

試行では、案内を探す時間だけでなく、回答の確認、引継ぎ、誤案内の訂正、資料更新に使った時間も記録します。比較期間や対象質問が違う結果を足さず、問い合わせが多い日と少ない日の差も条件として残します。削減できた作業があっても、別の確認が増えていないかを確かめます。

売上や問い合わせへの効果を見たい場合は、チャットの利用、問い合わせの送信、窓口での受付、用件の完了を分けます。ボットを使った回数だけで売上への貢献を決めず、使える既存の計測と業務記録でどこまで確かめられるかを先に決めます。計測できない部分は、分からないまま区別して導入判断に使います。

一般的なAI導入の見積のそろえ方は、AI導入費用と1年間の見積もり方で確認できます。製品の公開料金を、そのまま自社の構築総額や運用総額にはしません。