AIチャットボット導入の進め方｜電話対応・オペレーター支援AIとの使い分け

「ウェブサイトにチャットボットを置けば、問い合わせ対応が楽になるはず」という相談を受けることがあります。実際に効果が出るケースもありますが、どの問い合わせを任せるかを決めないまま導入すると、顧客からの多様な質問にAIがそれらしく答えてしまい、間違った案内をそのまま届けてしまう事故につながります。

この記事では、チャットボットの2つの方式の違い、具体的なツールの向き不向き、電話対応・オペレーター支援AIとの使い分け方を整理します。

ルールベース型とLLM型、何が違うか

チャットボットは大きく2種類に分かれます。

ここでの時間感覚はあくまで目安であり、対象業務の複雑さや確認体制によって変わります。重要なのは、「選択肢をボタンで示すだけで足りる問い合わせ」と「自由な言い回しで聞かれる問い合わせ」を混同しないことです。前者にLLM型を使うのは過剰投資になりやすく、後者にルールベースを使うと「その質問には対応していません」ばかりが返ってくる結果になります。

具体的なツールの向き不向き

名前の挙がりやすいツールについて、得意・不得意を整理します。価格や具体的な機能の有無は変わりやすいため、検討時は各社の最新情報を確認してください。

LINE公式アカウントの自動応答は、キーワード応答やメニュー形式の構築に向いています。日本の顧客にとって入力のハードルが低く、営業時間案内や予約導線など、定型的な一次対応には扱いやすい選択肢です。一方で、込み入った相談には向いておらず、無理に分岐を増やすと管理が煩雑になります。

Dify のようなLLMアプリ構築ツールは、自社のFAQやマニュアルを根拠資料として読み込ませ、その範囲内で回答させる構成（RAGの考え方。詳しくはRAGを社内検索へ使うときの考え方で解説しています）を比較的柔軟に組み立てられます。ただし、プロンプトや根拠資料の設計、公開後の動作確認に相応の作業が発生するため、社内に運用担当を置けることが前提になります。

Microsoft Copilot Studio のような、Microsoft 365と連携するボット構築ツールは、すでにTeamsやSharePointを業務基盤として使っている会社であれば、既存の資料や権限管理と連携しやすい利点があります。逆に、Microsoft製品をあまり使っていない会社がこのためだけに導入するのは、学習コストに見合わない場合があります。

ZendeskやIntercomのようなヘルプデスクツールには、問い合わせ管理と組み合わせた自動応答の機能が組み込まれ始めています。すでに有人のチャットサポートやチケット管理をこれらのツールで運用している会社であれば検討しやすい一方、ヘルプデスクツール自体を使っていない会社が、チャットボットのためだけに乗り換えるのは遠回りになりがちです。

ChatGPTの画面をそのまま使うという誤解もよく見かけますが、ChatGPTの通常の利用画面は社内担当者が下書きを作る用途には向いていても、そのままウェブサイトに埋め込んで顧客対応に使う仕組みではありません。顧客向けに公開するには、APIを使って自社サイトやLINEと接続する実装が別途必要です。

回答範囲を決めるシステムプロンプトの例

LLM型を検討する場合、最初に決めるべきは「何を答えるか」より「何を答えないか」です。以下は、営業時間・サービス内容・料金の問い合わせに限定して回答させる、システムプロンプトの一例です（実際の運用では自社の文言・資料名に置き換えてください）。

あなたは◯◯社の問い合わせ対応アシスタントです。
以下のルールを厳守してください。

1. 回答してよい話題は「営業時間」「サービス内容」「基本料金プラン」の3つのみ。
2. 上記3つに関する情報は、添付された社内FAQ資料のみを根拠にする。
   資料に記載がない内容は、推測で答えず
   「担当者からご案内しますので、少々お待ちください」と返答する。
3. 個別の契約内容、値引き交渉、クレームに関する発言を検知した場合は、
   即座に「担当者におつなぎします」と返し、それ以上の回答を続けない。
4. 資料にない固有名詞（競合他社名、個人名など)が含まれる質問には、
   一般論として回答せず、同様に担当者への引き継ぎメッセージを返す。
5. 回答は3文以内を基本とし、長い説明が必要な場合は
   「詳しくは担当者からご説明します」で区切る。

このように、答えてよい範囲と、担当者に引き継ぐ条件を先に文章化しておくことで、「AIがそれらしく作り話をする」事故を防ぎやすくなります。社内FAQをAIで整える方法では、この根拠資料側の整理について詳しく解説しています。

電話対応・オペレーター支援AIとどう使い分けるか

チャットボットを検討する前に、同じ問い合わせを電話で受けている場合は、電話対応はAIでどこまで自動化できる？やオペレーター支援AIの設計との役割分担を整理しておくと、重複した仕組みを二重に作らずに済みます。

大まかな目安として、次のように考えると役割分担を整理しやすくなります。

• 顧客がすぐに文字で入力できる定型的な一次対応（営業時間、予約手順など）→ チャットボット（ルールベース中心）
• 顧客が電話を使い慣れている、または急ぎの相談 → 従来の電話対応、または通話中のオペレーター支援AI
• 相談内容が毎回異なり、過去のFAQでは拾いきれない → 有人対応を主軸にし、チャットボットは一次受付のみ

チャットボットを「電話の代わり」として一気に置き換えるのではなく、電話に出られない時間帯の一次受付や、定型的な質問のフィルタリング役として位置づけると、導入のリスクを抑えやすくなります。

導入する価値が低いケース

次のような場合は、チャットボット導入を急がず、まず問い合わせの実態を数えることをおすすめします。

• 1日あたりの問い合わせ件数が数件程度で、担当者が電話やメールで十分さばけている
• 問い合わせ内容が毎回大きく異なり、FAQ化できるパターンがまだ見えていない
• 根拠資料となるFAQやマニュアルがまだ整理されておらず、何を参照させればよいか決まっていない

特に3つ目は見落とされがちです。チャットボットを先に導入してから資料整備を後回しにすると、「資料がないので答えられません」ばかりを返す状態になり、かえって顧客の印象を悪くします。

まとめ

チャットボットは、ルールベース型かLLM型かで設計の手間も誤回答のリスクも大きく変わります。ツール選びの前に、どの問い合わせを任せるか、何を答えないかを先に決めること、そして電話対応やオペレーター支援AIとの役割分担を整理することが、事故の少ない導入につながります。

Domani Luceのコールセンター向けAI活用支援では、現在の問い合わせ対応の内訳を伺い、チャットボットに向く部分と、人が対応すべき部分を一緒に整理します。ご関心があれば、無料相談からお問い合わせください。