AIチャットボットの活用｜顧客対応・社内問合せ・ECの設計と評価

AIチャットボットは、顧客への案内、社内情報の検索、ECの商品選びなどで検討できます。ただし、質問へ返事を出すこと、業務の手続きを実行すること、利用者の問題が解決したことは別です。本記事では、顧客対応・社内問合せ・ECの三つを想定用途とし、回答の根拠、権限、人への引継ぎ、評価と総費用を整理します。表や手順は導入を検討するための提案で、全製品の共通仕様や導入効果の保証ではありません。

顧客対応・社内問合せ・ECで、回答と処理の範囲を決める

導入の出発点は、今どのような質問が届き、誰が何を確認して回答しているかを整理することです。件数が多いという理由だけで、すべてを同じボットへ任せません。一般公開できる説明、利用者を確認してから見せる情報、変更の承認が必要な手続きでは、必要な情報と責任が異なります。受付した用件、回答できた範囲、後から人が確認する部分を分け、業務のどこが終われば完了とするかを先に決めます。

本記事で提案する三領域の用途と確認事項

領域	想定する使い方	先に確かめること
顧客対応	公開FAQの案内、用件の受付と担当先への引継ぎ	案内できる規約の版、個別情報の照会権限、未解決時の窓口
社内問合せ	手順の検索、担当部署や申請先の案内	社員ごとの閲覧範囲、資料の責任者、申請と承認の区分
EC	商品条件の説明、選択肢の提示、問い合わせ受付	対象商品の価格・在庫・条件、購入や返品等の実処理との境界

顧客対応では、FAQを提示した段階と個別案件に回答した段階を分けます。営業時間の説明と、特定の注文の配送状況や返金の判断は同じ処理ではありません。注文番号を入力できたことだけで、照会してよい本人だと判定する設計にも注意します。個別情報を扱う場合は、既存の本人確認や担当者の確認、必要な権限と接続先を整理します。

社内向けでは、全員に公開された手順と、特定部署や案件に限定された情報を分けます。検索できる資料が増えたことを、全社員が同じ内容を見てよい理由にはしません。申請方法を案内するだけなのか、申請を作成するのか、承認後の設定変更まで行うのかも区別します。人事や経理等の専門判断が必要な用件は、回答する範囲と担当部署へ戻す条件を確認します。

ECでは、商品の特徴や利用条件を説明する用途と、在庫の確保、決済、注文変更、返品の実処理を分けます。文章が自然でも、価格や在庫の情報が古ければ利用者の判断を誤らせる可能性があります。推薦候補を出す場合も、対象商品、参照時点、説明できる根拠を確認します。購入率が上がることを前提にせず、誤案内、再問合せや返品を含めて検証する範囲を決めます。

根拠資料の版・権限と、答えられない場合の扱いを整える

回答に使う資料は、内容だけでなく、対象業務、利用できる人、有効な版、更新責任者を整理します。FAQに誤りがある場合と、正しい資料を検索できない場合、検索できても別の条件へ当てはめてしまう場合を分けて調べます。FAQを増やすだけで、常に正しい回答が得られるとは扱いません。似た質問でも適用条件が異なる例や、答えを出す根拠がない質問を検証に含めます。

準備の記録には、資料の保管先、参照してよい版、利用者の範囲、外部へ表示できる内容、更新や削除を担当する人を残します。自社情報を検索して回答に使う構成を検討する際も、製品名だけで接続可否や権限の継承を決めません。連携先ごとの設定、契約、形式と更新の反映方法を確認します。ここで示すのは要求を整理する観点で、特定製品の同期方式や閲覧制御を検証済みとする説明ではありません。

権限の確認では、管理者が参照できる資料で答えられるかだけでなく、実際の利用者ごとの回答を試します。部署や役割を変えた場合、利用権限を外した場合、元資料を削除・更新した場合も確認対象にします。リンク先に閲覧制限があっても、回答文や要約に制限された内容が含まれていないかを見ます。出典を表示することと、その出典を利用者へ見せてよいことは別の確認です。

根拠がない、資料が矛盾している、価格や適用条件を確かめられないときは、推測で説明を埋めるより、確認が必要な点を明示して担当者へ渡せるようにします。利用者に求める追加情報も、回答に必要な範囲へ絞ります。認証情報や不要な個人情報を会話へ入力させずに済む経路を検討し、記録の閲覧者、保存や削除、外部サービスへ送る情報を担当部署と決めます。

検証用の質問には、通常のFAQだけでなく、表現を変えた質問、複数の条件を含む質問、資料の対象外の依頼、古い版と新しい版で答えが変わる質問を用意します。確認者が期待する回答と根拠、回答を保留する条件を記録し、設定を変えた後も同じ観点で比較します。共通の正解率や固定の質問件数を置かず、誤りが業務や利用者へ与える影響から対象を選びます。

有人への引継ぎと、承認後に実行する手続きを区別する

人への切替えは、ボタンや案内文が表示されるだけで完了したとは考えません。利用者が担当者へ連絡でき、担当側が用件と必要な情報を受け取れることを確認します。回答を繰り返してしまう、根拠がない、利用者が人の対応を希望する、許可外の依頼を受ける等の場面で、いつ切り替えるかを決めます。ボットの受付時間、担当者の対応時間、後段システムの稼働時間も分けて案内します。

GoogleのDialogflow CXのFulfillment説明では、Live agent handoffはAPIの呼出し側へ有人引継ぎを知らせる信号で、同サービス自身がその信号によってセッション状態を変更するものではないとしています。実際の引継ぎに必要な処理は、システムや連携側で扱います。機能名があることと、自社の担当窓口へ会話や処理情報が渡ることを同一視しないための例です。

引継ぎ先には、利用者の用件、確認できた事実、参照資料、実行済みの処理、未確認事項を分けて渡します。会話の要約に推測を混ぜず、必要なら元のやり取りへ戻れるようにします。担当者が受け取れない場合、受付時間外、混雑や障害の場合も試し、別の連絡方法と未処理の管理先を用意します。「有人へ転送した」という記録だけで、相手が受領し解決したと数えないようにします。

注文変更、返金、社内アカウントの操作などを行う構成では、回答と実行を別に管理します。対象を参照できる権限、変更できる権限、必要な承認、処理の完了確認を定めます。利用者に変更案を提示しただけなのか、承認を得たのか、実際に反映されたのかを区別します。応答が途切れて結果が分からない場合は、接続先で状態を確認し、同じ要求を重複して実行しない手順を用意します。

電話や複数チャネルを含む基盤の選定・費用比較は、AIコンタクトセンター・CCaaSの自動応答と有人対応の確認点でも整理しています。本記事で対象用件と回答・手続きの境界を決めた後に、どのチャネルで受付し、誰が後段の処理を受け持つかを検討する際に参照できます。チャットで確認した設定を、そのまま全電話基盤や全システムの共通仕様へ広げないようにします。

回答・解決・事業成果の指標と、運用を含めた費用で評価する

評価では、質問の件数、ボットが対象にした件数、回答した件数、解決を確認できた件数を分けます。利用者が会話を閉じたことだけを、正しい回答で解決した証拠にしません。再問合せ、訂正、有人への移行、結果不明や未回答も記録し、分母と集計期間を示します。製品の画面に同じ名前の率が出ても、対象範囲や集計の条件を揃えてから比較します。

IntercomのFin指標の説明は、関与した会話に対する解決率と、全サポート会話に対する自動化率を区別しています。また解決には確認されたものと推定によるものがあり、現行と旧定義の項目も分かれています。これは同社製品の指標定義で、全製品共通の業務上の解決率や、一般的な導入効果ではありません。自社で何を解決と数えるかを明記して評価します。

顧客対応は回答の正確さと引継ぎ、社内向けは情報への到達と担当者の負担、ECは購入に加えて粗利や取消し・返品等を確認する案が考えられます。比較する利用者や流入、商品、価格、対象期間が変われば、差のすべてをボットの効果とは断定できません。問い合わせ件数の減少と、準備・確認・修正を含む作業時間の減少、実際の現金支出の減少も区別します。

費用は、契約単位と利用量、モデルや検索・保存、接続の開発、資料整備、確認・有人対応、更新・監視を含めて見積もります。無料の試用枠や公開単価だけで本番の総費用を決めず、契約期間、利用上限、追加課金と停止・終了時の扱いを確認します。全社共通の月額、導入期間、自動解決率や費用回収を保証する目安は置きません。

フォームやメールへ引き継いだ後の問合せ取込み、分類、台帳と返信下書きは、renueのコマースエージェントで公開用途を確認できます。公開LPは下書きと人の承認、ラベル単位の自動返信を案内しています。ECの在庫・決済・返品の全面自動運営や、全チャネルの完成済みチャットボットとして案内するものではありません。接続先、権限、形式と料金・運用範囲は個別に確認します。

回答の確認画面や既存システムへの情報の受渡しを整える場合は、FDEの要件整理・設計・実装・運用支援で、業務フローとKPI、権限・API・形式・セキュリティ条件を基に対象を相談できます。特定製品の専門導入や全接続、法適合・正答率を一律に保証する案内にはしません。試行の結果と残る作業を確認し、資料の更新責任者、停止方法と担当者への引継ぎまで決めて対象を広げます。