対話型AIプラットフォーム7選を比較：料金・有人引き継ぎ・権限制御【2026年】

対話型AIプラットフォームは、公開後に誰がエージェントの運用を担うかで選びます。既存のコンタクトセンターに導入するならCognigy、自社でコードを管理するチームならRasa、クラウドエンジニアリングチームならGoogle Conversational Agentsが候補です。本記事で比較する7製品には、共通して確認すべき問いがあります。エージェントの処理を止め、人に引き継ぐ必要が生じたとき、実際に何が起きるのでしょうか。

料金、課金単位の定義、製品の機能は、2026年10月27日に各社の公開ページで確認しました。 本記事は公開されている機能と導入要件を比較したもので、実機による信頼性テストではありません。顧客対応エージェントの構築に使うプラットフォームを、自社で担う必要がある作業も含めて評価しています。

エンジニアリングに割けるリソースが限られた小規模なサポート組織では、会話設計を共同で進めたいなら**Voiceflow、チャットを中心に構築し、公開された導入価格から検討したいならBotpressから始めるとよいでしょう。Microsoft製品を中心に運用する組織では、Microsoft Copilot Studioを最初に評価する価値があります。顧客対応の自動化に加え、有人担当者の支援やサービス品質管理まで対象とする企業には、Kore.ai**も候補になります。

対話型AIプラットフォーム比較一覧

以下の最低料金は、それぞれ異なる処理単位に対する価格です。リクエスト、Copilot Credit、会話は同じ単位ではありません。また、ライセンスが無料でも、エージェントの稼働に必要なサービスがすべて含まれるとは限りません。

上表のGoogleの料金は、Conversational AgentsのFlows/Playbooks料金表に基づきます。以前の製品紹介URLは現在、独立した製品ページと料金ページを持つCustomer Experience Agent Studioに転送されます。一方の製品の公表価格を、もう一方の導入費用として扱わないでください。

対話型AIプラットフォームとは何ですか？

対話型AIプラットフォームとは、質問への回答、業務プロセスの実行、接続先システムの呼び出しを伴う顧客との会話を設計し、公開・運用するためのソフトウェアです。プラットフォームがエージェントの動作環境を提供し、自社は知識、権限、ポリシー、有人対応への引き継ぎ先を用意します。

実用的なプラットフォームは、言語を解釈・生成する大規模言語モデル、つまりLLMと、決められた順序で進める必要がある処理のフローを組み合わせます。住所変更、請求への異議申し立て、アカウント情報の照会では、このフローが重要になります。自然な会話は顧客が用件を伝える助けとなり、明示的なロジックが依頼された操作を許可できるかどうかを判断します。

注文に関する問い合わせを考えてみましょう。エージェントには、利用を認められた配送情報、本人確認の手段、注文システムとの接続、変更を許可する範囲のルール、例外対応が必要な場合の有人窓口が必要です。流暢に回答できるだけでは、この一連の対応は完了しません。

そのため、選定時にはチャット画面以外も確認する必要があります。

• 会話設計： LLMへの指示と、動作を予測できるフロー、条件分岐、処理できない場合の応答を組み合わせられるか。
• チャネル： Webサイトのチャット、メッセージング、音声の各チャネルで、必要な機能が使えるか。
• アクションとナレッジ： 承認済みの文書や業務システムに、適切な権限で接続できるか。
• 有人対応への引き継ぎ： 担当者が待機するサポートシステムへ、必要な文脈とともに会話を渡せるか。
• 分析と評価： 会話がどこで失敗し、どのアクションが実行され、リリース後に何が変わったかを確認できるか。
• ガードレール： 情報へのアクセス、ツール利用、コンテンツ、公開を制御できるか。プロンプトの外側でも業務ルールを適用できるか。

そのまま使えるアシスタントを探している場合は、AIチャットボットのおすすめ比較を参照してください。既存のヘルプデスク内で動作するパッケージ型エージェントについては、AIカスタマーサービスツールの比較が参考になります。本記事で扱うのは、自社の顧客向け会話システムをどう構築し、維持するかという選択です。

対話型AIと生成AIは何が違いますか？

対話型AIは、会話の中で相手を理解して応答するという、やり取りの形を指します。一方、生成AIは、言語などのコンテンツを生み出す能力を指し、多くの対話システムの中で使われています。対話型エージェントでは、生成した返答、定型応答、決められたルールに従う業務ロジックを組み合わせられます。

サポート責任者にとって、この違いは実務で捉えると明確です。「荷物が前の住所に届いてしまった」という発言の意味はモデルに理解させます。住所をまだ変更できるかどうかは、認証を伴うワークフローで判断します。意味を推測できることと、会話に出てきたアカウントを自由に変更できることを混同してはいけません。

3つのタイプを、運用の担い手で分ける

企業向けコンタクトセンタープラットフォームは、サービス運用を軸にエージェント構築機能をまとめた製品です。CognigyとKore.aiが該当します。振り分け、電話、有人チーム、運用監督が選定の中心になる場合に検討します。コンタクトセンターとは、顧客からの電話やメッセージを扱う組織とソフトウェアです。AIプラットフォームは、それを置き換えるのではなく、接続して使う場合もあります。

開発者向けフレームワークとホスト型ビルダーは、設計を自社で担う範囲が広いタイプです。Rasaはコードを中心とするフレームワークです。同じグループでも、VoiceflowとBotpressはホスト型のビジュアルビルダーに当たります。インフラの管理、画面上での編集、独自のシステム連携を、どこまで自社で担うかが製品ごとに異なります。

クラウド事業者のビルダーは、すでにクラウドサービスを運用できる組織に向いています。本記事ではGoogle Conversational AgentsとMicrosoft Copilot Studioが該当します。既存のID管理、システム連携、管理体制との相性は、会話エディターの細かな機能差より重要になることがあります。

企業向けの対話型AIには何が必要ですか？

判断の基準は、顧客対応の全工程で責任者を決められるかどうかです。変更の承認、連携の保守、引き継ぎ先の要員配置、障害の調査を誰かが担う必要があります。「エンタープライズ」と名の付く製品を買っても、これらの役割が自動的に決まるわけではありません。

多国籍のサポート組織なら、変更した返金ポリシーを誰が公開できるのか、地域別の対応キューをどう選ぶのか、引き継ぎ先のプラットフォームが停止したらどうするのかを確認します。小規模企業にも同じ問いは当てはまりますが、より軽量なビルダーで十分な場合があります。従業員数だけでなく、組織の複雑さを基準に選ぶほうが実態に合います。

比較・選定の基準

本記事では、LLMとフローを組み合わせたエージェントの構築、有人対応への引き継ぎ、アクションの制限、必要なチャネルの運用、課金単位の把握について、公表された情報を根拠に推奨しています。各プラットフォームの公式料金ページ、製品ページ、ドキュメントを確認しました。

ベンダーが示す自動対応完結率を、そのまま自社の予測値にはしていません。自動対応完結とは、会話が自動化の範囲にとどまったことを意味し、顧客の問題が解決したことまでは示しません。慎重な取り扱いが必要な依頼では、人に適切に引き継ぐことが正しい結果になり得ます。

本比較で特に重視するのが、引き継ぎの実装責任です。Cognigyはコネクターと引き継ぎ用ノードを文書化しています。Googleは連携側で処理する必要があるシグナルを提供します。Rasaは自社で実装すべきパターンを示しています。Voiceflowは有人担当者の応答をリアルタイムに中継する接続と、チケット作成を区別しています。Botpressは新規ワークスペースで引き継ぎ先が変わったことを説明しています。「有人引き継ぎ対応」というチェック欄だけでは見えない作業が、これらの違いから分かります。

今回取り上げる対話型AI企業の範囲

今回の7社で、企業向けサービスプラットフォーム、自社開発を前提とした製品、クラウド上の構築環境をカバーしています。個人用アシスタント、動画アバター、パッケージ型のヘルプデスクエージェントまで対象を広げてはいません。紹介順は、まず3つのタイプそれぞれで有力な候補を挙げ、その後に特定の運用体制に強い選択肢を並べています。

以下の適性評価は、編集上の推奨です。公開情報で連携への対応を確認できれば候補には入れられますが、顧客対応が最後まで機能するかは、実際に使うチャネルでパイロットを行わなければ分かりません。

7つの対話型AIプラットフォームを詳しく比較

1. Cognigy：既存のコンタクトセンターへの導入に

NiCE Cognigyのブランドで展開する**Cognigy**は、既存のコンタクトセンターを中心に顧客対応エージェントを構築する企業向けプラットフォームです。音声、チャット、接続先システム、有人エスカレーションの連携が難所となるサポート組織では、最初の候補になります。公開されているプラットフォームは、LLMの推論に、定義済みの処理手順、評価、運用監督、会話分析を組み合わせています。導入の前提は明確です。この幅広さを活用できるだけのサービス運用体制が必要です。

向いている組織： コンタクトセンターの責任者と導入チームがいる、既存のサポート組織。
特徴： エージェント構築を、有人対応への引き継ぎと継続的なサービス運用につなげられます。
料金： 個別見積もりのみ。現在のプラットフォームページでは、数値による公開料金を確認できませんでした。
無料トライアル： デモは提供されています。トライアルの有無と条件はベンダーへの確認が必要です。

有人対応への引き継ぎの仕組み

Cognigyのドキュメントには、対応するコンタクトセンターとエージェントを接続するHandover Providersが記載されています。フロー内のHandover to Human Agentノードで、有人対応への引き継ぎを開始します。これには適切なコネクターに加え、引き継ぎに対応したエンドポイント、つまり実際のチャネル接続が必要です。対応エンドポイントの一覧には、Voice GatewayとWebchatが含まれています。担当者の対応可否、引き継ぎの状態、引き継ぎの終了を扱うノードも文書化されています。Cognigyの引き継ぎドキュメント

航空会社のサポートチームなら、運航の乱れで影響を受けた予約が、乗客のそれまでの状況とともに、担当者が待機する正しいキューへ届くデモが役立ちます。導入担当者には、受け取る担当者側の画面も見せてもらいます。その後、キューを利用不可にして試します。正常時に転送できること以上に、失敗時の動作が明確で、復旧できることが重要です。

Cognigy独自のLive Agentは、デジタルチャネルの会話に対応する有人担当者向けワークスペースを提供し、顧客の文脈や運用指標も扱います。すでに利用しているコンタクトセンターへのAI接続とは、別の範囲として見積もりを確認してください。製品群に有人対応用のワークスペースが含まれていても、それが見積もりの対象に入っているとは限りません。Cognigy Live Agent

エージェントの操作権限をどう制限するか

Cognigyは、パラメーターと実行条件を定義したツールや、LLM主導のやり取りと構造化フローを切り替える機能を説明しています。エージェント型AIのプラットフォームには、コンテンツモデレーションとジェイルブレイク防止フィルターも挙げられています。これらは別々の層として使います。コンテンツのフィルタリングはモデルの発言内容を扱い、実行条件はアクションを実行してよいかを扱います。Cognigyのエージェント制御機能

先ほどの予約トラブルなら、モデルが顧客の希望を解釈し、航空券を変更する前にルールで運賃条件を確認する構成にできます。受け入れテストでは、説得するような言い回しで禁止された変更を試してください。求める結果は、操作の拒否または有人対応への引き継ぎと、その理由を理解できる記録です。

選び方： できるだけ軽量なビルダーを導入することより、既存のコンタクトセンター運用を維持することが重要ならCognigyが向いています。用途が限られたWebサイトのFAQだけで、導入やサービス運用の責任者もいない場合には適しません。

最初の評価は、有人対応への引き継ぎから

以下はCognigyの文書化された制御機能を使うパイロットの提案です。本記事で実施したテストではありません。

1. 1

   引き継ぎ先のサービスを設定する

   Deploy > Handover Providersでコンタクトセンターへの接続を設定します。残りの対応フローを設計する前に、選んだエンドポイントが引き継ぎに対応していることを確認してください。

2. 2

   引き継ぎの条件を明確にする

   テスト用フローにHandover to Human Agentノードを追加します。最初のトリガーは、顧客が担当者との会話を直接求める発言にすると、同じ転送を再現しやすくなります。

3. 3

   対応可否と引き継ぎ状態を確認する

   文書化された対応可否と状態の制御を使い、キューで待機中の会話と、人が受け付けた会話を区別します。誰も受け付けられない場合、顧客に何を表示するかも決めておきます。

4. 4

   担当者との会話まで確認する

   同僚に引き継ぎを受けてもらい、サポートシステムから返信してもらいます。文脈の受け渡し、顧客からの返信、終了時の動作を確認します。パイロットを広げる前に、引き継ぎ先のサービスが利用できない状態でも繰り返してください。

2. Rasa：コードと実装を自社で管理するチームに

**Rasa**は、会話の振る舞いを自社製品の一部として設計し、実装を明確に制御したい開発チーム向けの選択肢です。Conversational AI with Language Modelsの略であるCALMというアプローチで、言語の解釈と構造化された業務フローを分離します。「この文書に基づいて答える」だけでは足りないポリシーがあり、バックエンドエンジニアもいるプロダクトチームには魅力的です。一方、同じ理由から、エンジニアの支援を受けられないサポート責任者が手軽に導入する用途には向きません。

向いている組織： システム連携、デプロイ、会話ロジックを保守できる技術系のプロダクトチーム。
特徴： CALMが、モデルによる解釈とタスクを実行するフローを分離します。
料金： Free Developer Editionでは、企業あたり1体のボットと月間最大1,000件の社外向け会話が認められます。Enterpriseは個別見積もりのみです。
無料トライアル： 利用上限の範囲内で、ローカル環境や本番環境に使える無料ライセンスがあります。

フレームワークが担う範囲

CALMでは、LLMがメッセージを解釈してコマンドを生成します。対話マネージャーはそのコマンドを使い、フローを進めたり、バックエンド連携を呼び出したり、会話の変化を処理したりします。応答は標準ではテンプレートに基づき、任意で言い換え用コンポーネントを使えます。この分離により、開発者は業務手順を直接記述できます。Rasa CALMのドキュメント

配送変更を受け付ける定期購入サービスを考えてみましょう。顧客は住所変更の途中で配達日について質問し、その後で元の依頼に戻るかもしれません。こうした柔軟な会話を支えつつ、実際のアカウント更新には製品の他の機能と同じ確認手順を適用することが設計の課題です。自由な文章で答える過程で、その確認がいつの間にか省略されてはいけません。

Rasaの現在のドキュメントは、Rasa ProとStudioを、新しいオーケストレーターのMantleや早期アクセス段階のエージェント構築インターフェースと区別しています。本記事で推奨しているのは、文書化されたPro/CALMのアプローチです。提案される構成がどのランタイムとインターフェースを使うのかを確認してください。Rasaという名前の下にあるすべての機能を、同じリリースや利用権の対象として扱うことはできません。Rasaドキュメントの対象範囲

有人引き継ぎとアクション制限の仕組み

Rasaの有人引き継ぎは、標準のままではアシスタントが対応できないことをユーザーに伝えます。実際に転送するには、pattern_human_handoffを上書きし、カスタムアクションを実装する必要があります。この違いは大きく、フレームワークが提供するのは会話のパターンであり、引き継ぎ先サービスへの接続は自社のアプリケーションが担います。Rasaの有人引き継ぎパターン

実装では、顧客の識別情報と関連する会話履歴を渡し、自動応答を一時停止し、サポートサービスが転送を受け付けない場合に復旧できるようにします。この連携には、担当エンジニアを明確に置いてください。「フローに引き継ぎ処理がある」だけでは、受け入れ判断の根拠として不十分です。

Rasaは、フローを開始できる条件を定めるflow guardsにも対応しています。ただしドキュメントには、リンクされたフロー、呼び出されたフロー、自然言語理解（NLU）のトリガーに関する例外が記載されています。ガードは会話の制御として扱い、バックエンドのアクションでも改めて認可を行います。アカウント情報を扱う場合、どの会話経路から到達したかにかかわらず、サーバー側でアクセス権を確認すべきです。Rasaのflow guardsの例外

自社で担う作業と費用

Rasaの料金ページには、セルフマネージドとマネージドサービスのデプロイ方式が掲載されています。また、AudioCodesの音声コネクターは追加購入とされています。デプロイ、モデル利用、電話機能は、ライセンスと分けて範囲と費用を確認する必要があります。無料版はアーキテクチャを検証するのに役立ちますが、稼働に必要なものがすべて無料という意味ではありません。

選び方： 顧客対応のワークフローを、継続して保守するソフトウェアとして開発チームが管理したいならRasaが向いています。サポート部門がインフラ作業を抑えて小規模なエージェントを公開・調整することを急ぐなら、ホスト型ビルダーを選びます。

3. Google Conversational Agents：クラウドエンジニアリングチームに

**Google Conversational Agents**は、Dialogflow CXとも呼ばれる決定論的なFlowsと、生成型のPlaybooksを組み合わせたクラウド上のビルダーです。開発者が顧客向けアプリケーションを管理し、言語モデルによる会話と、手順を定めた処理を併用したい場合に向いています。対応のどの部分を生成AIに任せ、どこを明示的な手順に従わせるかを決めたい場合に、特に役立ちます。ただし、エージェントのエンジンを導入しただけで、有人サポートの仕組みまで完成するわけではありません。

向いている組織： 独自のチャット・音声による顧客対応を構築するクラウドエンジニアリングチーム。
特徴： FlowsとPlaybooksで、会話に異なる形の制御を適用できます。
料金： チャットはFlowsが$0.007/リクエスト、Playbooksが$0.012/リクエスト。Flowsの音声は音声1秒あたり$0.001からです。Playbooksとハイブリッド構成には、それぞれ異なる課金ルールがあります。
無料トライアル： 新規ユーザー向けにFlowsとPlaybooksのクレジットが提供されています。

どの製品を評価しているかを明確にする

現在の製品紹介ページへのアクセス先は、Gemini Enterprise for Customer ExperienceのCX Agent Studioにつながります。Flows/Playbooksの料金ページは、別の料金表として引き続き公開されています。この節で評価するのは、ドキュメントに記載されたConversational Agentsのシステムです。そのリクエスト単価をCX Agent Studioの費用見積もりには使っていません。現在のCX Agent Studioのページ

この区別は調達の場で重要になります。ベンダーや導入担当者には、提案に含むコンソール、ランタイム、課金メーターを明記してもらってください。「Googleの対話型AI」だけでは範囲が広すぎて、請求書と照合したり、機能デモを再現したりできません。

Playbookは、情報の提供、外部サービスへの問い合わせ、フローや別のPlaybookへの処理の委譲に使えます。小売企業なら、言語生成で曖昧な配送トラブルを理解した後、本人確認と注文確認の手順が決まったプロセスに進められます。会話のすべてを台本どおり、あるいはすべてを生成型にしようとするのではなく、業務上の操作をどこで行うかを軸に境界を決めます。Google Playbooks

有人引き継ぎとアクション制限の仕組み

Googleのlive agent handoffレスポンスは、会話を人に移す必要があることを呼び出し元に知らせます。ドキュメントには、このシグナル自体はセッションの状態を変えず、転送は自社のシステムや連携機能で実行する必要があると明記されています。電話の転送を行うフルフィルメントは別の仕組みで、Phone Gatewayへの対応と、連携ごとの制約があります。Googleのフルフィルメントに関するドキュメント

Webエージェントでは、開発者がエスカレーションを実際の有人キューに接続し、その後のメッセージを制御する必要があるということです。これを行わないと、分析イベントには「引き継ぎ」と記録されても、顧客はまだ誰とも話せない状態になります。パイロットでは、顧客側と担当者側の画面を同時に確認してください。

Googleのエージェント設定には、禁止フレーズ、コンテンツ安全性フィルター、任意のプロンプトセキュリティチェックがあります。これらは有用な制御ですが、文書化されたセキュリティチェックは悪意ある入力の検出を試みるものであり、エージェントが意図しない方向に誘導されないという保証ではありません。機密性の高い操作は認可を行うバックエンド関数に置き、各Playbookから利用できるツールを意図的に絞ります。Googleのエージェント設定

音声対応で早めに確認すべき制約

Playbooksのドキュメントには、電話のキーを押したときに出る信号音であるDTMFには対応しないと記載されています。発信者がアカウント番号をキー入力する必要がある場合や、音声入力の代わりにキーパッドを使う必要がある場合は、会話の経路を決める前にフローと電話連携の設計を確認してください。自然な音声で話せることと、キー入力を処理できることは別の要件です。

選び方： 周辺アプリケーション、システム連携、課金分析までクラウドチームが管理するならGoogleが向いています。有人対応まで整ったサポート体制を手早く手に入れる方法としては適しません。設計を自社で選び、その構成を維持できる場合にこそ魅力があります。

4. Microsoft Copilot Studio：Microsoft中心の運用体制に

**Microsoft Copilot Studio**は、Microsoftの業務システムとPower Platformをすでに管理している組織に合う、ローコードのエージェントビルダーです。データへのアクセスやシステム連携を管理する担当者が、その環境で日常的に業務を行っているなら、最初に評価する価値があります。顧客対応に使う場合は、単体製品と顧客対応システムとの連携を評価してください。社内でMicrosoft 365のエージェントを使うことと、社外顧客向けにエージェントを公開することでは、調達上の判断が異なります。

向いている組織： 管理者がいて、顧客対応の引き継ぎ先も決まっているMicrosoft中心の組織。
特徴： 既存のPower Platformの管理モデルで、エージェント構築を統制できます。
料金： 従量課金はCopilot Creditあたり$0.01からです。Azureサブスクリプションが必要で、実際のクレジット消費量に応じて課金されます。
無料トライアル： ありますが、トライアルライセンスでは公開できません。

社外顧客向けではライセンスの範囲が変わる

Microsoftの料金ページは、Microsoft 365 Copilotに含まれる機能と、社外向けチャネルに使う単体のCopilot Studioを区別しています。そのため、顧客向けエージェントには、同僚が業務で使う社内アシスタントとは異なるライセンスが必要になる場合があります。既存のサブスクリプションを予算の前提にする前に、実際の利用者、チャネル、接続先サービスを明確にしてください。Copilot Studioの製品とライセンスの対象範囲

Copilot Creditsは利用量の単位です。アクションや応答の種類によって消費量が異なるため、クレジットを顧客数、会話数、解決件数と同一視することはできません。アクセス数に一律のクレジット単価を掛けるのではなく、連携アクションも含む予定の対応フローに基づいて、利用量を見積もってもらいます。

有人引き継ぎとアクション制限の仕組み

Microsoftは、企業のWebサイト、ファイル、ナレッジベースなどを根拠に応答し、顧客対応システムに引き継ぐ生成型エージェントを文書化しています。引き継ぎ先として、Dynamics 365 Customer Service、ServiceNow、Salesforce、LivePerson、Genesysが挙げられています。文書化された顧客対応の引き継ぎ機能は、これらのエージェントに使われるランタイムであるstandard harnessを対象としています。顧客対応と有人引き継ぎ

すでにDynamicsで顧客からの問い合わせを受け付ける運用チームなら、よくある問い合わせを既存のサービスワークフローにエスカレーションするパイロットが自然です。引き継ぎ先の担当者が、どの本人確認情報と会話の文脈を受け取れるかを確認します。すべてのチャネルや別のランタイムでも、同じ引き継ぎ動作が使えると推測してはいけません。

Copilot Studioのデータポリシーでは、ツールとして使うコネクターのブロック、WebサービスへのHTTP接続の制限、認証の必須化、公開チャネルの制限が可能です。管理者はイベントトリガーも制限できます。エージェントの口調だけでなく、システムへのアクセスを統制するため、実効性のある制御ポイントになります。Microsoftのデータポリシー

最初に行うとよいのは、接続先のうち顧客レコードを変更できるシステムの洗い出しです。エージェントには、割り当てた仕事に必要な操作だけを許可します。そのうえで、ユーザーが明確に要求しても、管理者の制限によって不要な操作が公開済みの環境でブロックされることを確認してください。

音声対応は個別に受け入れテストを行う

Microsoftは、基本的な音声エージェントとリアルタイム音声エージェントに加え、音声入力、キーパッド入力、コンテキスト変数、通話転送を文書化しています。音声チャネルには電話番号が必要で、Azure Communication Servicesを通じて番号を取得または接続できます。Webエージェントが動けば音声も動くと考えず、個別のチャネル実装として検証してください。Copilot Studioの音声機能概要

選び方： 既存のMicrosoftの管理体制によって運用負担を抑えられるなら、Copilot Studioが向いています。社外公開、引き継ぎ先のサポートシステム、利用量に応じた消費を確認せず、「Microsoftにはすでに料金を払っている」という理由だけで選ぶのは避けましょう。

5. Voiceflow：小規模なプロダクト・CXチームに

**Voiceflow**は、プレイブック、ビジュアルワークフロー、連携ツールを使い、顧客との会話をチームで設計できるホスト型ビルダーです。技術的な接続を担当できる人がいる小規模なプロダクトチームや、カスタマーエクスペリエンス（CX）チームにとって、本比較では最も有力な出発点になります。サポートの運用担当者やデザイナーが会話そのものを頻繁に見直す必要がある場合に向いています。ただし、有人対応のキューを管理するのは、引き継ぎ先のサポートプラットフォームです。

向いている組織： 独自のチャット・音声対応を構築する、小規模な部門横断チーム。
特徴： 自然言語で書くプレイブックと、決められた手順を画面上で組むワークフローを併用できます。
料金： 企業向けは個別見積もりのみです。プラン料金、任意のアドオン、クレジットに基づく利用料を組み合わせて課金されます。
無料トライアル： 公開されている代理店・パートナー向けの案内では、クレジットカード不要のトライアルが紹介されています。自社が利用できる申込経路を確認してください。

チームで設計できる範囲

Voiceflowは、自然言語の指示で記述するプレイブック、ビジュアルワークフロー、関数やAPI（他のソフトウェアとの接続）、Model Context Protocol（MCP）ツールによる開発者向け拡張機能を説明しています。MCPは、エージェントにツールを提供するための標準です。電話、Webチャット、SMSにも対応していますが、各チャネルの機能は個別に確認する必要があります。Voiceflowの製品情報

定期購入型の小売サービスなら、サポート部門が配送の例外をどう説明するかを定め、エンジニアが権限確認を伴う注文照会を実装できます。ワークフローでは、どこで有人対応に引き継ぐかを両者が把握できるようにします。ポリシー変更に合わせて会話を変える必要がある場合に有用ですが、それを理由にすべての編集者へバックエンドのアクセス権を変更する権限を与えるべきではありません。

Voiceflowの現在の公開料金ページでは、企業向けに見積もりを求める形になっています。過去のサブスクリプション料金を調達の基準に使うべきではありません。同じ提案書に、プラン料金、含まれる利用量、超過時の扱い、必要な連携機能の利用権を記載してもらいます。予定するチャネルとサポート接続が見積もりに明記されていれば、ホスト型ビルダーを評価しやすくなります。

有人引き継ぎとアクション制限の仕組み

Voiceflowは、Genesys、UJET、Kustomer、Dixa、Zendeskとのネイティブなリアルタイム引き継ぎ接続を文書化しています。他のサポートシステムには、自社でホストするサービスを介したCustom Handoffを使えます。この方法には開発者が必要で、対象機能が利用可能であることも条件です。担当者の対応可否と割り当てはサポートシステムが管理し、Voiceflowのフローは引き継ぐタイミングと失敗時の動作を管理します。Voiceflowの引き継ぎ概要

小規模なチームで特に押さえたいのは、チケットを作ることと、有人担当者の返信を顧客へリアルタイムに届けることは別だという点です。 「担当者がこのチャットに参加します」と案内するなら、契約前に返信が届く経路まで実演してもらいます。「後ほどご連絡します」という対応なら、会話でもそう明確に伝えます。

引き継ぐ文脈には、会話記録の全文、カスタム変数、何も渡さない設定を選べます。カスタム値を設定しても、自動で要約が作られるわけではありません。渡したい内容をあらかじめ用意する必要があります。復帰時と失敗時の経路を両方設定し、エディター内だけでなく、公開済みのチャネルでもテストしてください。Voiceflowの引き継ぎ設定

電話では、電話番号やインターネット電話の宛先であるSIPアドレスへ転送するために、別のCall forwardステップが用意されています。デジタルチャネルの引き継ぎ接続と通話転送を、同じ実装だと考えないでください。

Voiceflowは、全体に適用する指示とガードレールに、決定論的なワークフロー、評価、開発から本番までのホスト環境を組み合わせています。必須の業務手順はワークフローで実行し、バックエンドのアクションも独立して制限します。よく書かれたプレイブックで返金のタイミングを説明できても、その顧客と注文が返金の対象になるかは、返金サービス側で判断すべきです。

選び方： チームで会話設計を進めることが課題なら、Voiceflowが向いています。完全に自社でホストできるランタイムや、営業担当と話す前に確認できる企業向け公開価格が決め手なら、別の選択肢を優先します。

6. Botpress：チャットから始める小規模チームに

**Botpress**は、ビジュアルなStudio、連携ツール、Botpress Deskという有人サポート製品を備えたホスト型のエージェント構築プラットフォームです。独自のチャットエージェントを作り、どのようにアクションを選ぶかを調べたい小規模組織にとって、実用的な出発点になります。現在の料金体系では、個別見積もりのみの製品よりも導入時の費用を把握しやすくなっています。一方、公開プラン比較では音声チャネルがEnterpriseに含まれるため、電話を中心とするプロジェクトの第一候補としては弱くなります。

向いている組織： 技術的な支援を受けながら、Webやメッセージング向けのエージェントを作る小規模チーム。
特徴： ビジュアルワークフローで自律型ノードを設定でき、ツールの利用状況も確認できます。
料金： Freeには100件の会話が含まれます。Plusは年払いで月額$150からで、月間250件の会話を含みます。利用枠と有料の追加購入ルールがあります。
無料トライアル： Freeプランがあります。追加購入や超過利用はありません。

現在の課金単位を確認する

Botpressは現在、会話単位のプランを公開しています。料金ページでは、請求月内に顧客が少なくとも2件のメッセージを送信した時点で、AIのみの会話も、人が対応に加わった会話も計上されます。月をまたぐ会話は、両方の月で計上される場合があります。したがって、人に引き継いだからといって、そのやり取りが課金対象から外れるわけではありません。

同ページには、有料の会話パックを自動購入する仕組みと、会話の自動チャージを無効にできないことも記載されています。AIの利用量には、別の利用枠とチャージの仕組みがあります。公開Webサイトにつなぐ前に、予算責任者にこれらのルールを確認してもらってください。導入価格が低いことに意味があるのは、アクセスが増えたときに何が起きるかを運用側が理解している場合です。

小規模チームのパイロットには、注文状況の確認や製品サポートに範囲を絞り、明示的な引き継ぎ経路を備えたエージェントが適しています。実際のWebサイトのチャネルと、実際に使うナレッジソースで検証します。プレビューで見事な会話ができても、サポートの同僚が実際の案件を受け取れるか、利用量のモデルが自社のアクセス傾向に合うかは分かりません。

有人引き継ぎとアクション制限の仕組み

Botpressのドキュメントでは、新規ワークスペースのHuman Handoffの接続先としてBotpress Deskが案内されています。既存のワークスペースでは、従来のHuman-in-the-Loop連携を引き続き使える場合がありますが、そちらには独自の設定とプラン要件があります。古い設定ガイドに従う前に、自分のアカウントにどちらの方式が適用されるか確認してください。Botpressの有人引き継ぎドキュメント

調達時には、一連の対応を通して実演してもらう必要があります。顧客が助けを求め、予定した有人ワークスペースに案件が届き、担当者が返信し、設定した方針に従って自動対応が再開または終了するところまで確認します。従来のドキュメントにある「Resume Chatbot」アクションが、新しいDeskのすべてのワークフローに当てはまると考えてはいけません。

Autonomous Nodeではモデルが応答とツールを選び、標準ノードではカードを順番に実行します。自律型ノードには、ツール、ナレッジベース、ワークフロー、終了条件を設定できます。変数へのアクセスは明示的に許可する必要があり、書き込み権限は別に設定します。Inspectウィンドウでは、利用可能なツールや繰り返しの実行を確認できます。Botpress Autonomous Node

これらの設定は、有用な制御ポイントになります。注文照会なら、照会操作と必要な変数だけを公開します。エージェントが便利に使うかもしれないという理由で、顧客レコード全般を変更できるツールまで渡してはいけません。必須の検証は、構造化した処理経路と、実際に変更を行うバックエンドサービスに置きます。

小規模チームへの推奨が当てはまらない場合

公開プラン表で音声チャネルがどのプランに置かれているかは、重要な境界です。Webサイト用のエージェントとしてBotpressを選ぶ小規模チームは、同じ導入プランで将来の電話エージェントにも対応できると考えないでください。電話対応が主な要件なら、その範囲を明示的に含むプラットフォームと見積もりから検討し、音声AIエージェント向けプラットフォームの比較で、より専門的な候補を確認してください。

選び方： 用途を絞ったチャットを構築し、公開された導入条件と、確認しやすいワークフロー制御を求めるならBotpressが向いています。電話中心の構成を安く作れるという前提では選ばず、予測しにくいアクセスにエージェントを公開する前に、自動追加購入の仕組みを確認します。

7. Kore.ai：サービス業務全体の変革を進める企業に

**Kore.ai**は、顧客対応エージェント、有人担当者の支援、サービス品質管理までプロジェクトに含む企業向けの選択肢です。現在のAI for Serviceは、音声・デジタルエージェント、Agent Assistance、Quality Management、AIを前提にしたコンタクトセンターをカバーしています。これらの機能を共通の導入計画で検討する必要がある場合に候補へ入れます。Webサイト上の限られた質問に答えるだけの目的で、広範な取り組みを購入する必要はありません。

向いている組織： 顧客対応の自動化、有人担当者の支援、品質管理業務を連携させる企業。
特徴： サービスの自動化と有人対応の運用を、一体で評価できます。
料金： 個別見積もりのみ。現在のAI for Serviceのページでは、数値による公開料金を確認できませんでした。
無料トライアル： デモは提供されています。セルフサービスで申し込めるトライアルの公開条件は確認できませんでした。

幅広い機能が役立つ理由

よくある問い合わせと難しい例外対応があり、別の品質管理チームが両方の対応を評価するサービス組織を考えてみましょう。エージェントビルダーの購入で対応できるのは、その業務の一部だけです。より大きな判断は、自動化した部分と人が担う部分を一貫したポリシーで運用し、問題が起きたときの責任を明確にできるかどうかです。

Kore.aiのサービス紹介ページでは、十分な文脈を伴う引き継ぎ、バックエンド接続、担当者支援用のプレイブック、独自の評価基準が説明されています。また、LLMの外側にあるエンジンレベルでのポリシー適用と、エージェントのアクションの追跡も説明されています。これらはデモで検証すべきベンダー公表の機能であり、正しく動作することを独立した測定で保証したものではありません。

そのため、Kore.aiを候補に入れる意義は組織面にあります。サポート責任者、連携の責任者、品質管理の責任者が、共通のサービス設計を評価できます。チャットボットだけの魅力的なデモでは、プラットフォーム全体が各部門の要件を満たすかどうかは分かりません。

有人引き継ぎとアクション制限の仕組み

Kore.aiは文脈を伴う有人引き継ぎを説明していますが、実装範囲は実際の受け入れ先システムとチャネルに合わせて定める必要があります。顧客の依頼、本人確認の状態、試みたアクション、エスカレーションの理由が、担当者のデスクトップにまとまって届くところを実演してもらいます。その後、担当者が案件を開き直したり、状況を再構成したりせずに返信できるかを確認します。

音声とデジタルチャネルの引き継ぎは、別々に受け入れ判断を行います。チャットで正常に引き継げても、電話の転送時に必要な文脈が保持されるとは限りません。また、通話がつながっても、担当者に顧客の履歴が届いたとは限りません。両方のチャネルを購入するなら、これら両方の確認をデモの要件に入れます。

アクションの制限では、言語モデルの外側でポリシーが適用されるところを示してもらいます。アカウント認証と、承認された利用条件の確認が必要なサービス変更などが適した例です。同じ禁止操作を、別の会話経路からも試してもらってください。必要なのは、操作が一貫して拒否され、運用チームが理解できる記録が残るという証拠です。

調達条件を具体的にする

見積もりには、購入する構成要素、消費量の単位、含まれる環境、導入作業、サポートの責任範囲を明記してもらいます。音声とデジタルの利用量をどう扱うかも必要です。この範囲が定まらなければ、「Kore.aiの料金」を単一の金額として比較することはできません。別のモジュールの過去の価格を流用すれば、誤解を招きます。

公開後に誰がポリシーを保守するのかも確認します。例外が起きるたびにベンダーへの新たな依頼が必要な方式は、厳密に管理するサービス運営では許容できるかもしれませんが、運用上の選択として明確にしておく必要があります。社内の運用担当者がポリシーを編集するなら、実際に使う想定の権限で、レビューから公開までの手順を実演してもらいます。

選び方： エージェントビルダーに加え、サービスの運用体制も含めて導入する組織にはKore.aiが向いています。既存のコンタクトセンターにエージェントを追加することが中心なら、まずCognigyを候補に置きます。そのうえで、実際のコネクター、制御、運用のデモを通じて両者を選び分けます。

会話型AIの違いが見える具体例

プラットフォームを比べる際は、例外を含む顧客対応を試してください。単純なFAQへの回答だけでは、本人確認の状態を維持できるか、ポリシーを守れるか、人を対応に参加させられるかは、ほとんど分かりません。

注文した商品が破損して届いた場合。 エージェントはポリシーを説明し、注文情報を取得できます。依頼された例外対応に人の承認が必要なら、関連する文脈とともに引き継ぎ、交換がすでに承認されたかのように伝えてはいけません。自動応答だけでなく、受け取った担当者がそのまま対応を続けられるかを評価します。

顧客が別のアカウントの情報を求めた場合。 正しい結果を左右するのは、接続先システムの認可です。「プライバシーを守る」というプロンプトは有用な指針ですが、アカウント照会側で、顧客に権限のないアクセスを拒否する必要があります。会話の途中でアカウント識別子を変え、バックエンドが何を返すか確認してください。

有人キューの受付時間外に、電話の相手が担当者への転送を求めた場合。 実際に運用している折り返し連絡、今後の対応を明確に伝えたうえでのチケット発行、別の有人窓口など、実態に合った代替経路が必要です。完了できないリアルタイム転送を案内してはいけません。音声では、発話への割り込み、キーパッドの要件、転送の動作も個別に確認する必要があります。

分析も、こうした対応の流れに沿って行うと役立ちます。依頼された操作が完了したか、人が引き継ぎを受け付けたか、顧客が同じ問題で再度問い合わせたかを測定します。成功した会話だけでなく、失敗した会話や途中で離脱した会話も確認してください。

ベンダーの「解決済み」や「自動対応完結」というラベルは、その定義を確認する必要があります。自社が求める成果は、条件を満たした配送変更の完了、慎重な取り扱いが必要な依頼の安全な引き継ぎ、あるいは実行できない操作について顧客に正しく伝えることかもしれません。ダッシュボードを比較する前に、何を成果とするか合意します。

チームに合う対話型AIプラットフォームの選び方

技術者が個人で構築する場合や、小規模なサポートチームがチャットから始める場合は、まずBotpressを選びます。 導入条件が公開されており、自律型ノード、ツール、構造化ワークフローの関係を確認しやすいためです。電話が主なチャネルの場合や、利用枠の自動追加購入が自社の予算管理に合わない場合は、この推奨を見直します。

デザイナーと運用担当者がいて、エンジニアの協力も得られる小規模なプロダクト・CXチームなら、まずVoiceflowを選びます。 理由は、会話設計を共同で進められることです。ホスト型ビルダーの利便性より、ランタイムとコードを自社で管理する必要性が高まったら、Rasaを検討します。

資金があり、バックエンドの開発力を持つプロダクトチームなら、開発者向けフレームワークの候補としてRasaを選びます。 エージェントを継続的に保守する製品ソフトウェアとして扱う企業に合います。選択を変える条件は、運用の責任体制です。デプロイや引き継ぎ連携を保守する人がいないなら、ホスト型の製品を選ぶか、マネージドな導入支援の範囲を決めます。

中堅企業のクラウドエンジニアリングチームなら、クラウド型ビルダーの候補としてGoogle Conversational Agentsを選びます。 周辺アプリケーションを自社で管理したいと考え、有人引き継ぎも実装できることが前提です。Microsoft中心の組織で、Power Platformの管理体制と適切な引き継ぎ先サービスがすでにあるなら、Copilot Studioを選びます。

既存のコンタクトセンターなら、企業向けプラットフォームの第一候補はCognigyです。 エスカレーション、チャネル連携、継続的なサービス運用を優先します。プロジェクトに有人担当者の支援や品質管理のプロセスも含む場合は、最終評価にKore.aiを加えます。選ぶべきなのは、自社の対応フロー全体を実演し、実装の責任範囲を最も明確にできるベンダーです。

これらの推奨は、チームの体制に基づくもので、最低従業員数を定めるものではありません。小さな技術チームが高度なフレームワークを運用できる一方、大企業でも単純な連携の責任者が決まっていないことがあります。

避けたい選び方

用途が限られたFAQで、導入責任者もいないなら、CognigyやKore.aiは避けます。 幅広い機能が役立つのは、複数のサービス業務を連携させる必要がある場合です。小規模な導入に、理由もなく大規模な取り組みの調達・保守負担を持ち込むべきではありません。

「無料」だけを理由にRasaを選ぶのは避けます。 無料ライセンスを得ても、有人サポートへの接続構築、アクションの保守、ランタイムの運用を担う人は決まりません。

引き継ぎレスポンス自体が担当者につないでくれると期待するなら、Google Conversational Agentsは避けます。 ドキュメント上、その処理は連携側が担います。

Botpressを低価格の電話対応パッケージだと思い込んだり、MicrosoftのどのサブスクリプションにもCopilot Studioの利用権が含まれると思い込んだりして選ぶのは避けます。 必要なチャネルと社外顧客向けの利用範囲が、購入する製品に含まれている必要があります。

チケット作成をリアルタイムの有人引き継ぎと同じ扱いにするVoiceflowの提案は避けます。 どちらも有用ですが、顧客への案内は連携が実現する動作に合わせなければなりません。

法人向け対話型AIは、契約前に何を検証すべきですか？

範囲を絞った顧客対応フローと、それを受け取る有人チームから始めます。パイロットの目的は、見栄えのよい会話ログを作ることではなく、各失敗に誰が責任を持つかを明らかにすることです。

モデルを業務システムにつなぐ前に、許可する操作を書き出します。注文に関する問い合わせなら、最初のバージョンでは状況の読み取りとポリシーの説明までを認め、例外の承認は人が担う構成が考えられます。最初は権限を絞ることで、受け入れ基準を確認しやすくなります。

プロンプトインジェクションとは、モデルが接する入力を通じて、その動作を別の方向に誘導しようとするものです。顧客のメッセージ、文書、ツールの結果は、いずれも情報と指示の境界を曖昧にし得ます。プロンプトインジェクションの解説では、モデルが誤った指示に従ってしまった場合でも、接続先のアプリケーションでモデルにできることを制限しなければならない理由を説明しています。

パイロットの受け入れ項目は、次のように絞ると実用的です。

1. 必要な処理が成功すること。 エージェントが想定した情報源から回答するか、許可された操作を完了し、その結果が業務システムに記録されます。
2. 禁止された処理ができないこと。 権限のない依頼では、データを変更したり、他の顧客の情報を開示したりできません。
3. 有人対応までつながること。 想定したサポートシステムで、担当者が会話、文脈、顧客からの返信を受け取れます。
4. 失敗時にも次へ進めること。 キューが利用できない、ツールが壊れている、情報源が見つからない場合に、明確な復旧案内と、実際の運用で実行できる次の手順が示されます。
5. 責任者が運用できること。 指名された担当者がログを確認し、該当するポリシーを変更し、承認済みの更新を公開し、選定したデプロイ手順で問題のある変更から復旧できます。

候補に残した各ベンダーには、同じ対応フローで見積もりを出してもらい、課金単位を明示してもらいます。導入サービス、電話、モデル利用、サポートプラットフォームの料金がかかる場合は、それぞれ見える形にします。一見安いプラットフォームでも、自社の作業量が増えることがあります。高い見積もりにも、不要な作業が含まれているかもしれません。どちらも表面的な単価だけでは判断できません。

週明けに始めること： サポート責任者と連携の責任者で共通のエスカレーションシナリオを書き、選んだプラットフォームのタイプで最有力の候補に通し、実際に同僚が案件を受け取る様子を確認します。エージェントの権限を広げる前に、これを行ってください。

よくある質問

AIチャットボットの作り方は？

まず、顧客のどの用件に対応するか、利用を認めるナレッジソースは何か、エージェントにどの操作を許可するかを明確にします。会話用のランタイムを選び、実際のチャネルに接続し、認可を伴うバックエンド操作と有人対応の代替経路を実装したうえで、成功時と失敗時の両方を評価します。言語モデルが担うのは会話の一部であり、その周囲の運用基盤はプラットフォームと自社のアプリケーションが担います。

無料で自分のAIチャットボットを作れますか？

Rasaには利用上限付きの無料開発者ライセンスがあり、Botpressには制限付きのFreeプランがあります。初期評価には使えますが、適用される上限や必要な外部サービスは異なります。導入全体を無料と判断する前に、モデル利用、ホスティング、電話、引き継ぎ先のサポートシステムを確認してください。Microsoft Copilot Studioのトライアルは評価用で、公開は認められていません。

AIチャットボットを使うメリットは何ですか？

よく使う情報を見つけやすくし、人が対応に入る前に情報を集め、許可された作業を一貫して実行する助けになります。その効果は、背後にあるナレッジ、連携、サービスのプロセス次第です。ベンダーの自動化率がそのまま自社にも当てはまると考えず、タスクの完了、顧客の負担、再問い合わせを自社のパイロットで測定してください。

範囲を絞ったパイロットを、実際に運用できるカスタマーサポートシステムへ発展させたい場合は、AIカスタマーサービス導入支援サービスをご覧ください。