Botpress 2022年のv12 vs Dialogflow ES vs Dialogflow CX【後編

Botpress vs Dialogflowの徹底比較の後編です。前編はこちら。

既存の統合を利用する

どのような統合が可能で、統合はどの程度簡単ですか？コンテンツは統合ごとですか、それともタイプごとですか？

既存の統合は、何かを100回繰り返すときに時間を節約する鍵となる。

ダイアログフローES

以下は、Dialogflow ESのUIからの統合です：

• Dialogflow Phone Gateway BETA
• アバヤ
• シグナルワイヤー
• ヴォキシンプラント
• オーディオコード
• Twilio
• テレフォニー
• ジェネシスCloud
• Twilio
• ウェブデモ
• ダイアログフローメッセンジャーBETA
• フェイスブックからのメッセンジャー
• フェイスブックのワークプレイス BETA
• Slack
• Telegram
• LINE
• キク
• スカイプ
• スパーク
• Twilio IPメッセージング
• Twilio（テキストメッセージング）
• ツイッター
• Viber

かなりのリストだ！

Facebookメッセンジャーを追加すると、指示、詳細情報へのリンク、環境に関する情報、適切なトークンが表示されます。

ダイアログフローCX

以下はUIから見たDialogflow CXである：

• アバヤ
• ヴォキシンプラント
• オーディオコード
• ダイアログフローメッセンジャー
• Facebook Messenger
• LINE

見た目があまりに似ていなければ、Dialogflow CXは前作と名前の半分を共有していると思われても仕方がないが、ウェブベースのテキスト統合機能は2つしかない！

Dialogflow ESでうまくいったことを再利用し、Dialogflow CXはFacebook Messengerを簡単に追加できるようにした。なぜもっと再利用しなかったのか不思議でならない。

Botpress v12

Botpress には、UIからアクセスできる統合機能はあまり付属していません。いくつかの設定ファイルを変更し、ドキュメントを読む必要がある。

モジュールのページでは、唯一の参照はウェブチャンネルです。これは、Botpress Studioでボットを開発するときに、エミュレータにも便利に使用されます。

ドキュメントのページには、これらのチャンネルがリストアップされている：

• ウェブサイトの埋め込み
• コンバースAPI
• Facebook Messenger
• Telegram
• Microsoft Teams
• Twilio
• Slack
• スモーチ（サンシャイン・カンバセーションズ）
• Vonage

数で言えば、Dialogflow CXより少ないが、人気のあるテキストベースのプラットフォームがいくつも用意されている。

メッセージング・チャンネルを有効にするには設定ファイルを変更する必要があるが、ドキュメントの説明は詳しい。

Facebook Messengerの統合には、設定ファイルの変更が必要です。これは技術者でなくても簡単にできるだろう。

ウェブチャットの埋め込みURLを取得するには、ドキュメントを開き、自分でURLを作成する必要があります。

比較

Dialogflow ES は Dialogflow CX やBotpress よりも多くの統合機能を備えています。Botpressの UI には webchat しか記 載されていませんが、Dialogflow CX と同程度の数の統合機能をサポートしています。webchat チャネルは設定が不要であるため、テストが圧倒的に容易である（Botpress ではドキュメントを参照する必要があるが、Dialogflow CX では不要）。しかし、Botpress は Dialogflow CX よりも一般的なテキストベースの統合をサポートしています。Botpress は Dialogflow CX よりも優れています。その理由は、基本的なサービスとの統合が欠けているよりも、多少複雑な統合があった方が良いからです。

会話全体の視覚化

ボットはどのように組織化され、チームメンバーへのオンボーディングはどの程度容易か？あなたのチームは、このプラットフォームでの作業や共同作業を楽しめるだろうか、それともフラストレーションを感じるだろうか？この点で、3つのプラットフォームは互いに驚くほど異なっている。

ダイアログフローES

Dialogflow ESではすべてがフラットです。フローエディターはありません。つまり、ユーザーを別のインテントからあるインテントに送りたい場合、視覚化するのが難しいということです。コンテキストを使う必要があります。

• 1つのリストがすべてを支配する

• 会話の流れをコントロールしたいのであれば、インテントに出力コンテキストを追加して、ユーザーの行き先をコントロールする必要がある。

• 払い戻しオーダーインテントに、同じコンテキストを入力として追加する。他のすべてのオプションについても同じようにします。

• インテント一覧で、add follow-up インテントをクリックすると、デフォルトのコンテキストを持つインテントが作成されます。しかし、ネストしたインテントをどのように並べ替えるのでしょうか?

1 / 4

さらに複雑なインテント（フォローアップインテント）を追加すると、すぐに追跡が困難になることがわかります。ビジュアルフローエディタがないことがこの原因であり、Dialogflow ESの最も大きな欠点である（そしてDialogflow CXの開発に拍車をかけたと思われる）。

ダイアログフローCX

Dialogflow CXにはフローエディターがあるが、どちらかというとフロービジュアライザーに近い。フローを見ることはできますが、外観を変更するためには、多くのメニューを操作し、フォームに入力してフローを作成する必要があります。

• 各ページはノードのようなもので、会話における場所を表している。このページには選択肢と2つのボタンがあります。

• 払い戻し注文のようなページをクリックすると、そのページが開き、他のページが閉じます。隣のページを見ることができます。

• ビジュアライザーは一度に1つのフロー（ページのグループ）を表示し、左側にはすべてのページを見ることができます。

• スタートページは、すべての機能を盛り込むのに良い場所だ。ルートは、その意味（ユーザーを異なるページやフローに送る）において、とても理にかなっています。

1 / 4

ページが入力されたときに何かが起こるようにする簡単な方法はありません（スタートのように）。代わりに、そのようなアクションはルートがトリガーされたときに発生しなければなりません。例えば、アナリティクスプラットフォームで利用状況を追跡するために、会話の最初にトラッキングピクセルを追加したいとします。各ルートとイベントハンドラにウェブフック（カスタムコードの実装）として追加する必要があります。

イベントハンドラは、ユーザーがテキストやデフォルトのレスポンスなしで投稿したようなケースを処理する注目すべきルートです。

会話の流れについていけないのは、2つの理由がある。一つ目は、トップダウンのロジックがないこと。複数のルートが同時にトリガーされる可能性があるため、会話に単一の位置はありません。二つ目の理由は、Dialogflowがルート/イベントハンドラをフロー先のページに視覚的にリンクさせず、その代わりにページを全体として扱っていることです。

フローUIは、インラインで何かを動かしたり編集したりすることができないので、エディターというよりビジュアライゼーションのように感じられる。コントロールが効かないので、最初は多少もどかしく感じるかもしれないが、そのうち慣れるだろう。

Botpress v12

視覚化は、Botpress が真に輝く分野のひとつである！ビジュアルフローエディターとフローロジックは直感的でわかりやすい。すべてが非常にキビキビしているのも悪くない。

• このビジュアル・フロー・エディターには秘密がない。進行していることはすべて表示される。すべてのトランジションは別のノードに接続します。

• ユーザーを次にどこに送るかを決定するロジックの作成と更新は簡単です。

• ノードをクリックすると、ノード・インスペクタがポップアップし、タイトル・エディタと3つのタブが表示されます。

• ノード間を結ぶ線が乱雑になる場合は、フローを複数のフローに分割することができる。こうすることで、線の量を管理しやすくすることができる。

• 意図と実体のページは期待通りのものだ。

• 統合されたQ＆A機能は素晴らしい。会話の流れ全体を見る必要のない投稿者を追加し、会話の他の部分を壊すことなく投稿してもらうことができます。

1 / 6

Botpressのフローエディターは、レスポンスがよく、透明性があり、時系列で、わかりやすい。Q&A機能は、多くのトレーニングなしに人々に貢献してもらうのに素晴らしい。

比較︓比較

Dialogflow ESには、会話を視覚化する簡単な方法があります。複雑な会話は優先されないようで、会話ロジックの "コンテキスト "はインテント一覧ページに表示されません。FAQであれば、それはまったく正当なことだが、それ以上のものについては、何が起こっているのかを把握するのは難しいだろう。

Dialogflow CXにはフロービジュアライザーという機能があります。右側のメニューからフォームを入力・更新し、保存することで、フローを編集することができます。Dialogflow ESと比較すると、ユーザーが会話のロジックを視覚化する上で飛躍的に優れています。残念なのは、各ルートがどこにつながっているかを表示する代わりに、フローエディターがページ（またはノード）全体を1つの大きなノードとして扱い、他のノードへの接続をすべて統合してしまうため、どのルートがどこにつながっているのかがわかりにくくなっていることです。また、マルチマッチングや複数のルートが同時にトリガーされることもあるので、注意が必要だ。UIはまた、インテントがオプションであることや、複数のマッチがどのように処理されるかを示すのが下手だ。一般的に言って、多くのことが必要以上に複雑に感じられる。Dialogflow CXに慣れ親しんだ人であれば、さほど問題に遭遇することはないでしょうが、技術的に未熟なチームメンバーへのオンボーディングには時間がかかるでしょう。

Botpress には適切なフローエディターがあります。ノード（Dialogflow CXのページに相当）をフロー内で移動させ、ドラッグ＆ドロッ プでつなげることができます。

Botpress のノードは、時系列に「開始」「応答後」「遷移」の3つのステージがあります。Dialogflow CXでは、ルート指向のサイロが隠されていますが、アクセス可能です。つまり、ノードはユーザーをどこに送るかによって異なることを行い、そのすべてが一目で何を行うかわからない。Botpressのアプローチの利点は、起こることすべてとロジックを見ることができることです。ウェルカムメッセージの表示などは、フローそのものに表示されます。Q&A 機能を使えば、技術者でない人でもすぐにチャットボットに参加させることができます。Dialogflow CXの中にミニDialogflow ESページがあるようなものです。

スケーリングの容易さ

スケーリングには2種類ある。膨大なトラフィックを処理するためにスケーリングできるボットと、膨大な会話フローを処理するためにスケーリングできる複雑なボットだ。

Diaglogflow ESとCX、またはBotpress - プロジェクトが会話AIプラットフォームを含み、機能が会話に直接関係するのであれば、スケーリングを心配する必要はありません。Botpress EnterpriseとDialogflow ESとCXの基本バージョンはすべてオートスケーリングで、膨大なトラフィックを処理することができます。カスタマーコードについては、Dialogflowはcloud 関数（これは非常に信頼性が高い）を呼び出すことができ、Botpress はベースアプリケーション内でそれを処理します（したがって、再び、自動スケーリング）。

非常に複雑なボットの管理については、会話全体の可視化について前のセクションを参照してください。Dialogflow CXもBotpress も大きな会話フローに対応できるはずだ。ビジュアル面では Dialogflow CX の方が優れており、Botpress はよりわかりやすく、すっきりとしたインターフェイスとなっている。全てのプラットフォームはユーザーロールマネジメントをサポートしており、各メンバーに異なるロールを設定することができる。

ボットメモリからの保存と抽出（注文番号など）

メモリは、自明でないアプリにとって必要条件である。他のサービスから情報を取得し、それをユーザーに表示することは、おそらく最も一般的なユースケースだろう。他のケースとしては、質問に対するユーザーの回答を記憶しておき、後でそれを考慮に入れることができるようにすることなどがある。

ダイアログフローES

フローエディターがなければ、ボットメモリはDialogflow ESの基本ではありません。UIでは、パラメータに基づいてインテントを表示したりしなかったりすることはできません。このようなロジックを使用したい場合は、コードを使用する必要があります。

• インテント・エディターでは、"変数 "を設定する（エンティティを使用する）非常に便利な方法があるが、それを使ってフィルタリングする方法はない！

• 一度しか起こらないことにコンテクストを使うこともできるが、二項対立でないロジックについて話しているときには、この方法は使えない。

1 / 2

Dialogflow ESでメモリを管理したい場合、コードを書く必要があります。Dialogflow ESのライブラリは役に立ちますが、すべてのフローロジックに対してコードを書く必要がある場合、他のプラットフォームがネイティブに統合しているものに対して多くのコードを書くことになります。この場合、Dialogflow ESをNLUのためだけに使うことになり、それは他のプラットフォームでも可能です。

ダイアログフローCX

ボットメモリの保存と読み出しは、パラメータを使って行う。

• Dialogflow CXで最初のルートを作成するとき、「Parameter」という単語を目にすると思います。パラメータには特別な書式が必要なので、構文参照へのリンクを必ずクリックしてください。

• 何のコードも使わずに、セッションごとに一度だけ挨拶をする例。変数 "greeted "へのアクセス方法が、保存方法と異なることに注目してください。

1 / 2

パラメータ・プリセットは、ウェブフック（カスタムコード）を呼び出す前に行われるため、プリセットと呼ばれています。

構文を理解するのに少し時間がかかる。この機能を使うにはドキュメントを読む必要がある。残念なことに、どんな変数が使えるかを示すオートコンプリート／サジェスチョン・インターフェースはない。

パラメータ/変数を変更する最後の方法は、カスタムコード/ウェブフックを使用することです。この場合、このドキュメントを読み、おそらくDialogflow CXライブラリをロードしてAPIを利用する必要があります。レスポンスを送信する際、session_info.parameters プロパティに新しいパラメータを設定することができます。Webhookでパラメータを変更する例を見つけるのは大変です。

Botpress v12

メモリーのアクセスや設定は、Botpress の「変数」を使って行われる。

• ノードインスペクタで、新しいアクションを作成すると、このプロンプトが表示されます。

• Execute code "オプションで "Set Variable "アクションを選択すると、3つのテキスト入力が表示される。typeは変数が存在する期間を決定します。nameは変数の名前、valueは代入したい値です。

• 変数を設定したら、トランジション（別のノード／フローへのリンク）を作成し、図のように条件として設定することができる。

• あるいは、このように表示することもできる。

• コードエディターから3行のコード。開発者はすべての変数タイプにアクセスでき、状態を直接読み込んだり更新したりできる。そして、フロー内でこれらを呼び出すことができる。

1 / 5

比較

Botpress'スーパーパワーは、ユーザーメモリにアクセスし、更新できるアプリ内コードエディタを持つことです。これは、あなたの反復プロセスを大幅に簡素化します。

これは、プラットフォームを問わず、直感的に理解できるほど簡単なことではありません。Dialogflow CX とBotpress では、まず最初に目にするのは式の評価であり、情報の代入ではありません。Botpress はグラフィカルな変数挿入機能を備えているため、Dialogflow CX よりも若干先行しています。

Dialogflowのこの命名法は、開発者にとってはちょっと驚きです。パラメータは変数であり、実行時に変更することができます。Webhookは単なるシグナリングではなく、リモートデータをパラメータに設定するためのものです。

Dialogflow ESは、よりシンプルなchatbots 。

価格

これは、このカテゴリーの中で最も話しやすく、比較しにくいものだ。以下は、3つのオプションの価格ページである：

ダイアログフローES

https://cloud.google.com/dialogflow/pricing#es-agent

ダイアログフローCX

https://cloud.google.com/dialogflow/pricing#cx-agent-2021-09

Botpress

https://botpress.com/pricing

比較

Dialogflow CXはDialogflow ESよりはるかに高価であるが、これは両者の主な違いがビジュアルフ ローエディターの追加であるためである。Botpress同じくビジュアル・フロー・エディターを搭載しているDialogflow ESはセルフサービス・モデルではないので、価格についてはDialogflow ESに問い合わせる必要がある。ベースとなるBotpress オープンソースアプリケーションは無料で、エンタープライズ機能のアンロックとサポートを受けるために支払うことができる。メッセージごとにお金を払いたくなく、自分でホスティングできるのが嬉しいなら、Botpress 。

結論

純粋なFAQスタイルのボットを素早く構築したいのであれば、Dialogflow ESが最適でしょう。カスタムコードを必要とせず、少人数のチームで、オンプレミスや初歩的な会話フローにこだわらないのであれば、勝るものはありません。優れた統合機能を持ち、Googleによってすでにホストされており、優れたNLUを持ち、わかりやすいインターフェースを持っている。それ以外のことなら、もっと良い選択肢がある。

Dialogflow CXは、Dialogflow ESの多くのコンセプトをベースに、フローエディターやリスト認識などのNLU機能など、スケーリング機能を追加している。しかし、ほとんどの統合は顧客自身が行うことを想定している。もし複雑なアプリケーションを持っていて、Googleの製品を使いたいのであれば、これで十分だろう。

Botpress は2つのDialogflowの中間に位置し、Saasではなくオープンソースソフトウェアである。機能的にはDialogflow CXに似ているが、Dialogflow ESに見られるようなシンプルさがある。Dialogflow CXが持っていてBotpress にない機能や洗練された点はあちこちにありますが、ほぼ同等です。何かを変更する必要があれば、完全にコントロールすることができます。それはさておき、Botpress のインターフェイスがすっきりしていてわかりやすいことが、Botpress を選ぶ最大の理由です。

Botpress アプリにコード・エディターが含まれることは、あまり意味がないように思えるかもしれないが、多くの変更にはフロー内での更新が必要であり、この2つを近づけることは非常に理にかなっている。変数の読み取りと更新はよりアクセスしやすくなり、毎回コードを再デプロイすることなく、2つを更新してテストすることができる。

DialogflowsとBotpress の違いとなる可能性があるのは、デプロイメントである。データ管理上、すべてをオンプレに置きたいのであれば、DialogflowsはGoogleがホスティングするSaaSであることを覚えておいてほしい。もう一つはデプロイとメンテナンスの容易さである。Dialogflowでは、情報の取得や更新のためのカスタムコードは別のフローで処理する必要があるが、おそらくGoogleCloud 関数で処理することになるだろう。Dialogflowはデプロイしやすいが、自分で追加したコードは自分でデプロイする必要があり、コードとロジックを1つの便利なワークフローにバンドルするBotpress 。どのソリューションも自動スケーリングに対応しており、どのような負荷がかかっても対処できるはずです。

実際の使用量はチャットボットによって異なるため、価格設定は比較が難しい。Dialogflowは最もわかりやすい価格体系で、リクエストごとの価格モデルとなっています。CXはESよりも1リクエストあたりの料金が桁違いに高い。最後に、Botpress エンタープライズの価格設定は、お客様のニーズに合わせてカスタマイズされます。メッセージごとに料金を支払いたくな い場合は、Botpress 。一般的に言って、業界調査によると、chatbots は通常、かなり収益性の高いプロジェクトであり、すべての価格モデルはそれを反映したものであることが予想されます。

Botpress 。私たちの営業チームは、あなたと話し、あなたの次のプロジェクトのニーズを把握するのが大好きです。また、Botpress はオープンソースですので、ご自身で お試し いただくことも可能です。