▼ この記事の内容
チャットボットツールは、製品名やAIの有無だけで並べず、どの利用者のどの質問に答え、根拠が足りないときに誰へ渡すかを同じ条件で確かめます。問い合わせ、社内窓口、営業支援では、必要な権限と完了の定義が異なります。
この記事では、候補を順位付けするのではなく、用途別の架空試験票で比べる手順を示します。代表製品の記載は公式資料で確認できた範囲にとどめ、料金、全プラン、個別設定は未確認として扱います。
チャットボットツール比較は用途と完了条件から始める
問い合わせ対応と手続き実行を分ける
問い合わせに回答できることと、申請、返金、契約変更のような手続きを完了できることは別に扱います。前者では回答の根拠と引き継ぎ先を、後者では本人確認や承認などの実行条件を確認します。
たとえば返金条件を案内する試験では、回答文が正しいかだけで合格にしません。実行の受付先、必要書類、権限のない利用者への扱いまで記録し、候補ごとの差を残します。
この分け方は、候補ごとの回答と手続きの結果を別々に確認するために使います。試験票だけで実運用の解決率や自動化の効果を確定するものではありません。
最初に決めるのは、利用者が回答を得た時点を完了とするのか、担当者が手続きを引き受けた時点を完了とするのかです。完了条件を先に書くと、候補ごとに異なる機能名へ比較が流れにくくなります。
用途ごとに必要な確認項目を変える
Web問い合わせでは、質問の種類、受付時間、担当への引き継ぎを確認します。社内窓口では、参照する資料の版、利用者の権限、回答できない場合の案内を確認します。
営業支援では、条件を聞き取る質問、記録先、担当者が次に確認する情報を分けます。同じチャット画面でも、利用者、根拠、引継ぎ先を用途別に記入すると、必要な設定を見落としにくくなります。
以下の試験票は説明用の架空例であり、実製品の出力や精度検証ではありません。自社の用語、担当、許可資料に置き換えて使います。
一つの用途で使えた質問を、別の用途へそのまま流用しないことも重要です。社内規程と営業条件では、閲覧権限や確認者が異なるためです。
方式・情報源・チャネルを分けて比較する
ルール型と生成・検索の併用条件を確認する
IBMの公式解説では、メニューまたはボタン型をスクリプト化された選択で進む方式として説明し、複数の方式を組み合わせるハイブリッド型にも触れています。方式名だけで用途に合うかを決めず、どの質問をどの根拠で扱うかを確認します。
定型の受付条件は、選択肢と分岐で確認しやすい場合があります。一方で資料を参照する回答では、参照範囲、更新方法、権限を別に確認する必要があります。
チャット、Webフォーム、社内ツールなどのチャネルも、方式とは別の軸です。利用者が質問する場所と、回答後に引き継ぐ担当を試験票に並べます。
参考：6 types of chatbots and how to choose the right one for your business｜IBM
代表製品は確認済み仕様と未確認事項を併記する
次の表は用途の候補を考えるための確認範囲であり、製品の順位表ではありません。公式説明に記載がない機能は、搭載されていないと決めつけず、提供元への質問として残します。
製品例 公式資料で確認した範囲 選定時に個別確認すること HubSpot 質問・応答列、担当への引き継ぎ、ミーティング・チケット用途 契約条件、対象チャネル、設定範囲 Intercom ワークフロー、有人引き継ぎ、対象チャネル・受付時間の設定 引き継ぎ後の運用、料金、個別設定 Copilot Studio SharePoint参照時の認証と権限範囲の例 ライセンス、接続方式、更新反映
候補を短く絞った後は、同じ質問、同じ許可資料、同じ引き継ぎ条件で試します。無料で使える範囲や全プランへの提供は、ここで確認した資料だけでは判断しません。
参考：Create a rule-based chatbot｜HubSpot
参考：Use Fin AI Agent in Workflows｜Intercom
参考：Use SharePoint content for generative answers｜Microsoft Learn
用途別の架空試験票で候補を試す
受付の定型分岐を試験票に落とし込む
Web問い合わせでは、質問、利用者、許可する根拠、期待する扱い、実際の出力、引き継ぎ先を一行ずつ記入します。料金や契約条件のように変更されうる情報は、資料の確認者も記録します。
次の記録は説明用の架空例です。製品の実出力や性能比較ではありません。候補を試すときは、同じ質問と許可資料を用意し、期待する対応と実際の出力を分けて記録します。
| 用途・質問 | 許可資料と利用者 | 期待する対応 | 架空の観察記録 | 次に確認すること |
|---|---|---|---|---|
| Web受付：「利用料金と個別値引きを知りたい」 | 公開料金案内 v2。未ログインの訪問者。 | 公開条件を案内し、資料にない個別値引きは担当へ渡す。 | 公開条件の案内は一致。値引きは回答せず問い合わせを受け付けた。担当の受入は未確認。 | 受付通知だけで完了にせず、担当者が依頼を受け取ったかを確かめる。 |
| 社内窓口：「9月以降の申請は誰が承認するか」 | 全社員向け規程 v2。一般社員。旧版 v1 は適用期間終了。 | v2の承認者を案内し、部署限定の補足は開示しない。 | 引用はv2だが、回答はv1の承認者だった。 | 資料の差し替えだけで済ませず、回答文と根拠を照合して再試行する。 |
| 営業受付：「導入日までに間に合うか」 | 公開導入案内。訪問者の希望日と対象範囲は不明。 | 希望日と対象範囲を質問し、確約は担当者の確認へ渡す。 | 希望日を質問したが返答はまだない。担当への確約依頼も未作成。 | 条件不足による回答待ちとして残す。失敗や対応完了と同じ欄に集計しない。 |
回答文が正しくても、申請や問い合わせの受入が確認できたとは限りません。各行に確認日時、試した利用者、実出力の保存先、次の担当を追記すると、再試行でも条件をそろえられます。
これは説明用の架空例です。実際の料金、対応時間、担当体制を示すものではありません。候補ごとの回答を同じ欄へ残し、後から判断の根拠を見直せるようにします。
社内規程と営業条件で権限・不足情報を試す
Copilot StudioのMicrosoft公式資料には、SharePointコンテンツを利用者の認証と権限範囲で参照する例があります。社内規程を扱う試験では、資料名だけでなく、版、閲覧できる役割、更新担当を確認します。
営業支援の試験では、質問で得られなかった条件を担当へ渡せるかを確認します。生成回答の内容を評価するときの観点は、生成回答を評価する観点も参照してください。
営業AI・営業DX チャットボット比較｜製品名より先に見る5つの選定軸
権限がない資料を参照できるか、または不足情報を補えるかは、公開資料だけでは決めません。試験時の利用者と参照を許可する文書をそろえ、判断できなかった点を追加確認欄に残します。
参考：Use SharePoint content for generative answers｜Microsoft Learn
更新・有人対応・費用の運用条件を比較する
資料差し替えと担当不在を試験に含める
Intercomの公式ヘルプには、ワークフローでのFin AI Agent利用、有人引き継ぎ、対象チャネルや受付時間の設定に関する説明があります。候補比較では、更新した資料の扱いと、受付時間外に担当がいない場合の案内を試験に含めます。
資料を差し替えた直後の回答、回答できないときの表示、引き継ぎ先の受け入れ状態は別々に確認します。担当へ渡す設定があることだけから、回答の範囲や解決状況を推測しません。
更新担当が複数いるなら、誰がどの資料の版を確認するかも試験票に記します。回答が古いかもしれない場面で、利用者へどのように案内するかを候補ごとに比べます。
参考：Use Fin AI Agent in Workflows｜Intercom
初期・従量・保守・再試行の費用を同期間で比べる
費用は初期費用、利用量に応じる費用、保守や設定変更に関わる費用、試験をやり直す担当工数を同じ期間で並べます。未確認の費用をゼロとして合計すると、候補間の比較条件が崩れます。
| 費用・作業 | 同じ条件で確認する単位 | 初期・継続 | 金額・工数が不明な場合 |
|---|---|---|---|
| 設定と資料整備 | 対象資料数、接続先、権限の種類 | 初期。追加時の作業も別記。 | 設定担当と見積先を記録する。 |
| サービス利用 | 契約期間、利用者数、会話や回答など実際の課金単位 | 継続 | 対象プランの条件を確認する。未確認をゼロとしない。 |
| 資料更新と再試行 | 更新頻度、代表質問数、担当作業時間 | 継続 | 更新担当・評価担当に作業範囲を確認する。 |
| 有人引き継ぎ | 対応時間帯、受付件数、担当の対応時間 | 継続 | 運用責任者に受付と受入の範囲を確認する。 |
| 変更・解約時の作業 | 資料・ログの出力範囲、保存期限、移行作業 | 変更・終了時 | 契約条件と出力方法を確認する。 |
比較表には、確認済み、要見積、未確認を区別して記します。金額の大小だけでなく、誰が資料を更新し、試験を再実行するかまで含めて稟議の前提をそろえます。
試験の合否と問い合わせ解決を分けて評価する
回答評価と顧客の問題解決を混同しない
MicrosoftのCopilot Studioの評価方法の説明では、関連性、根拠との整合、網羅性、回答を試みたかを含むGeneral qualityと、意味比較、完全一致などを区別しています。これは当該製品の評価機能に関する説明であり、すべての製品の共通仕様ではありません。
候補を試す際は、回答が根拠に沿うかという評価と、利用者が担当者から必要な手続きを受けられたかという解決確認を分けます。前者が合格でも、後者が確認できない状態は別に記録します。
比較結果には、回答合格、引き継ぎ確認、未回答、追跡未完了を混ぜずに残します。少数の試行や一時点の結果だけで、実運用の成果を断定しません。
参考：Choose evaluation methods｜Microsoft Learn
導入前の質問で未確認事項を残す
最終候補には、誰が何を確認するかを質問として残します。たとえば、資料の更新責任者、利用者の権限、受付時間外の案内、有人引き継ぎの受け入れ担当、費用の見積条件、ログの確認者です。
回答が得られなかった項目を、都合よく候補の弱点やゼロ費用へ置き換えないでください。確認日と確認者を記し、導入判断の前に追加確認する項目として扱います。
用途別の試験票は、候補を選んだ後にも見直せます。実際の利用者、許可資料、引き継ぎ先が変わったときは、同じ質問を改めて確認します。
まとめ
チャットボットツールの比較では、方式や製品名より先に、用途、回答の根拠、権限、回答できないときの扱い、引き継ぎ先を決めます。代表製品の公開資料は確認範囲の出発点にとどめ、実際の契約条件や設定は候補ごとに確認しましょう。
