Botpress vs Dialogflow ES vs Dialogflow CX 2022年【前編

DialogflowとBotpressを比較するのは大変なことで、時間の無駄です。どちらのチャットボット作成エコシステムも、数え切れないほどの機能と異なるやり方を備えているため、この業界の人々にとっても、一対一で比較するのは厄介なことです。もし、次のプロジェクトでこの2つのどちらかを選ぶとしたら、要件によってどちらかを選ばざるを得ない本当の要因が1つだけあります（Botpress はSaaSではなく、Dialogflowはホスト型です）。ほとんどの場合、どちらの選択肢も正当なものですが、好みがあるかもしれません。

DialogflowやBotpress を使ってボットを構築することがどのようなものかを理解していただくために、重要なポイントをリストアップし、スクリーンショットを撮影しました。ここでは、プラットフォームの一般的な使いやすさ、新しいチームメンバーとのオンボーディングと作業、一般的なアクションの実行とスケールでの管理に焦点を当てました。

Dialogflowを導入するということは、GoogleCloud Platformに投資するということなので、Dialogflow ES（エッセンシャル）とCX（カスタマーエクスペリエンス）を一緒にしました。また、公正を期すため、Botpress Enterpriseと比較し、有償ソリューションとの比較であることを確認します。

TLDR

純粋なFAQスタイルのボットであれば、Dialogflow ESで十分です！機能とデータを完全にコントロールするには、Botpress Enterpriseにアクセスしてセルフホストする必要があります。それ以外では、Dialogflow CXとBotpress 、ほとんどのプロジェクトに対応できます。Dialogflow CXは全体的に若干機能が多く、googleのように洗練されており、Botpress は理解しやすく、作業しやすい。価格については、Dialogflowはメッセージごとの価格設定（CXはESよりはるかに高い）であり、Botpressの価格モデルはよりサービス指向であるため、比較するのは難しい。

相違点の比較表

‍

完全比較

‍

ボタンと選択肢の追加

ボタン、選択肢、提案は、ユーザーが選択肢の内容を知ることができ、欲しいものを選びやすくしてくれるからだ。電話でも、選択肢はユーザーがメニューをナビゲートするのに役立つ。ボタンに対応していない他のテキストベースのプラットフォームでは、ショートサンドを使うことで簡単に答えることができます。

ダイアログフローES

• Dialogflow ESのデフォルトのレスポンスタイプにはボタンらしきものはありません！

• Slackのようなボタンのような機能をサポートするプラットフォームを選択すると、それに対応するレスポンスタイプが表示されます。Slackには、デフォルト（プラットフォームなし）のオプションにはない、画像、カード、クイック返信があります。

• クイック返信とカードは、Slackにボタンを追加する簡単な方法です。

• チャットエミュレータでは、プラットフォーム固有のプレビューが表示されます。Dialogflow自体にこれがあると便利です。

• リンクやテキストを簡単に追加できます。クイック返信の値はテキストと同じです。値は自然言語理解の意図検出に使用されます。

• 返答には2つの方法がある。1つ目は、カード/クイック返信で使用されるものと同様のトレーニングフレーズでインテントを作成することです。Dialogflowはこれをキャッチし、ユーザーをレスポンスに送ります。

• 2つ目の方法は、フルフィルメントを使うことだ。具体的には、フルフィルメントのウェブフックは、コードでレスポンスを処理することを意味する。

• 残念ながら、すべてのフルフィルメントを処理するには、別のページに移動する必要があります。

1 / 8

この時点では、カスタム・ロジックを処理するために、グーグルcloud 関数を使用するか、独自のサーバーを使用する必要があります。統合されたコードエディターもあるが、かなり限定的だ。1つか2つのアクションのピンチには使えるだろうが、ここにコード全体を置きたくはないだろう。

ウェブを含む複数のプラットフォームへの対応を考えている場合は、それぞれのタイプに対応したレスポンスを作成する必要がある。良い点は、このほうが壊れにくいということです。その一方で、より多くの作業を繰り返すことになります。プラットフォーム固有のプレビューは、テストに最適です。インテントからインテントへ移動して、ボタンをクリックしたときに実際に何が行われるかを確認するのは困難です。レスポンスがコードを処理する場合、何が起こっているのか、大まかな見通しを立てるだけでも難しい。

ダイアログフローCX

Dialogflow CXは、ボタンを同じように扱うと同時に、異なるボタンも扱います。

• ページでは、フルフィルメントを編集する必要がある。このページ内で起こるアクション（会話におけるユーザーの位置づけ）と考えてください。

• ダイアログオプションを追加するメニューです。テキストは簡単ですが、ボタンについては明確なオプションがありません。

• カスタムペイロード」オプションは、ボタンを追加したい場合に必要なものです。あまり直感的ではありません。

• 例えば、これはボタン／チップを追加する方法です。ドキュメントをナビゲートする必要があります。

• テストエージェントボタンをクリックして試してみると、このようになる。ボタンもなく、異なるプラットフォームでボタンがどのように見えるかを見る方法もない。あまり役に立たない！

• フローをテストするには、管理→統合→Dialogflowメッセンジャーの接続ボタンをクリックします。

• 有効にし、完了をクリック

• 微妙な "Try it now "ボタンをクリックし、右下のチャットバブルを開いてクエリーを試す。もっと手軽に試したい場合は、htmlファイルを作って、そこにコードを追加する必要があるようだ。

1 / 8

うまく解決できるといいですね！UIはこのことを明らかにしていません。答えを検索すると、コードベースのソリューションやDialogflow ESの結果が得られます。リッチレスポンスは強力ですが、何らかの理由で適切なGUIの扱いを受けていません。これはコーディングベースのソリューションであり、GUIで扱うことを余儀なくされます。最後に、これをエミュレータでテストしても、Dialogflow ESのように異なるプラットフォームでどのように見えるか、あるいはウェブチャットでどのように見えるかはわかりません。

Botpress v12

• 左のメニューハンドから、選択肢のアイコンをドラッグ＆ドロップする。

• 質問は再利用できるので、セレクタがある。

• 質問と回答を選ぶフリーテキストを無効にする。もちろん、これはフリーテキストを許可しているプラットフォームでのみ機能します。

• 質問と回答のペアを作成または選択すると、このように表示されます。

• アドバンスセクションでは、ユーザーが一致しない答えを書いた場合、設定した回数だけプロンプトを表示することができます。

• フローエディターでは、選択肢の結果を簡単に視覚化し、処理することができます。失敗時とは、ユーザーが不正解の最大数に達した場合のことです。

• ユーザーに選択を強要せず、単に提案を与えたい場合は、最大リトライ回数を0に設定し、「失敗時」をトリガーする「User_failed_input」要素でユーザーの入力を検出します。

1 / 7

全体的に、必要な選択をすることは、Botpress 、やり方が分かれば簡単で、視覚化しやすい。提案の提供は直感的ではなく、チョイススキルの機能を無計画に使っているように感じられます。ボタンがクロスプラットフォームであることは、複数のプラットフォームをサポートすることを計画している場合、時間の節約になります。

比較

Botpress はここではやや直感的ではありません。候補を表示したい場合でも、選択肢スキルを使う必要があるからです。利点は検証です。ユーザーに選択肢の1つに答えるよう強制することができます。選択肢スキルからサジェスト機能を分離すれば、より簡単になるかもしれません。Dialogflow ESは多少簡単です。問題は、すべてのサポートプラットフォーム用のボタン機能がないことです。試すにはプラットフォーム別のタブを開く必要がある。見つけるのは中々難しい。Dialogflow CXは、ボタンを追加するGUIベースの方法がなく、ここでは負け組だ。すべてがコードで実現できるわけではなく、なぜこのような方法をとったのか、ちょっと理解しにくい。Botpress 、Dialogflow ESともにボタンの追加方法をもっと明確にすることは可能だが、Botpress は便利なクロスプラットフォームのボタンとバリデーションを提供し、Dialogflow ESはサジェスト機能をもっと簡単にする。

ボタン押下の流れを可視化

Botpress ここでケーキを取る。ボタンがクリックされた後に何が起こるかを簡単に見ることができるからだ。Dialogflowのボタンは便利なリンク機能を提供するが、会話の流れという点では視覚化するのが難しい。Dialogflow ESにはDialogflow CXやBotpress のような視覚的な流れがないので、それも難しい。

ボタンのテスト

Botpress Botpress 、すべてが似ていると仮定しているため、1つの一般的なビューのみを表示し、Dialogflowはすべてが異なっていると仮定し、各バージョンを個別に表示します。なぜかDialogflow CXでは、デフォルトのエミュレータではどちらも表示されず、代わりにデータが表示されるようになっているようです。これは、単一のプラットフォームで開発する場合にも、複数のプラットフォームで開発する場合にも、非常に不便です。これは、CXがESの単なるアップグレード版ではないことの一例です。

自然言語理解能力

チャットボットメーカーのソリューションは、業界をリードするNLU（自然言語理解）を誇ることが多い。NLUを使おうと思っているなら、NLUについて2つの質問がある。X言語をサポートしているか、そしてどの程度サポートしているか？

NLUには一般的に2つの問題がある。エンジンが検出すべきでないものを検出してしまう（偽陽性）か、検出すべきものを検出しない（偽陰性）かだ。実際には、この2つの問題の解決策は、機械学習エンジンに多くの例と反例を与えることである。両方のエンジンが同じようなベンチマークを持っている場合、その違いは、精度の低いエンジンが同じように精度を上げるためには、エッジケースをカバーするために例文をもう少し増やす必要があるということだろう。あなたが解析しようとしているトピックによっては、そうでない場合もあります。

Botpress オープンソースは、ローカルで使用する場合、Dialogflowよりも少ない言語エンジンを提供します（箱から出して12）。12言語以外の言語を使用したい場合は、FastTextモデル（Facebook Open Source、言語リストはこちら）をNLUに使用することもできます。Googleがデータをホスティングしても構わないのであれば、DialogflowエンジンをNLUに使うこともできる。どちらか一方ではありません。どちらのプラットフォームも常に改良を続けている。Botpress 、DialogflowをNLUに使うことができるので、Botpress NLUにできてDialogflow NLUにできないことは何か、というのが公正な比較になる。

、ヘブライ語やアラビア語のサポートを期待される場合は、現時点ではDialogflow ESはこれらの言語をサポートしていませんのでご注意ください。

文の要素を認識する

通常、自然言語理解は、インテント検出とエンティティ認識の2つの要素に分けられる。インテントは文章、エンティティは理解したい文章の一部と考えることができる。日付、時間、場所はエンティティである。

6月11日に東京からニューヨークへ行く航空券を探してください。インテントは航空券を購入することであり、文そのものは発話と呼ばれる。インテントは通常、機械学習エンジンに供給するために多くの発話を持つ。東京、ニューヨーク、6月11日はすべてエンティティである。この文型は飛行機のチケット以外には使えないので、チケットはエンティティではない。しかし、「何かを購入する」という意図があれば、エンティティとして持つことができる。何を抜き出すかはあなた次第だ！

DialogflowとBotpress は、ユーザーエクスペリエンスの変更と既製のオプションで、多かれ少なかれ同じような機能を持っています。

ダイアログフローES

Dialogflow ESでエンティティを作成するには、最初にエンティティを割り当てるか、発話を書いた後にエンティティを追加します。

• インテントの発話からエンティティを作成するには、必要な部分（この場合は#14147）をハイライトするだけで、ポップアップが表示されます。

• デフォルトのオプションがたくさんある。

• 検索しても何も出てこないときは、新規作成ボタンが便利だ。

• "自動拡張を許可する "ことで、ユーザーは "apple, pears, bananas "のように書くことができ、NLUは "oranges "にもマッチさせることができる。

• エンティティを定義し、発話を作成すると、Dialogflowは自動的に内容にタグを付けます。この場合、自動タグ付けは少し大げさでしたが、タグを追加するよりも削除する方が簡単なので、問題はありません。

1 / 5

ダイアログフローCX

• 興味深いことに、Dialogflow CXはエンティティに関してはDialogflow ESに従わない。新規エンティティボタンがないので、エンティティを追加するには他の場所に行く必要があります。

• その代わり、インテンションページの下部にはこのように表示される。"Isリスト "は、一連の値（リンゴ、ナシ、バナナ）を入れることができ、"Redact in log "は、開発者がクレジットカード番号のような機密情報をログに隠すためのものです。

• Dialogflow CXのエンティティページでは、エンティティを作成することができます。これは基本的にDialogflow ESと同じですが、順序が異なります。主な例外はadvancedにある "Redact in log "オプションです。

• これはDialogflow CX独自のものです。

1 / 4

あいまいなマッチングと自動的に追加されるエンティティは、誤検出の問題を引き起こす。たとえば、リンゴ、ナシ、メロンなどの丸い果物を検出して、そのオプションを選択すると、丸くないにもかか わらずバナナも一致します。すべての丸くない果物の名前を挙げることは現実的ではありませんが、そのような場合は、エンティティ除外を使用することができます。しかし、丸くない果物をすべて挙げるのは現実的ではありません。

Botpress v12

• Botpress 、エンティティの作成は非常に簡単だが、その場で行うわけではない。

• 何かをハイライトしても、Dialogflow ESのように新しいタグを作成するオプションはありません。少なくとも、キーボードの数字（この場合は0）を押すことで、すべてのタグを素早く作成することができます。

• タグを付けたい場合は、まずスロットを作成する必要があります。これはダイアログフローとは異なります。

1 / 3

比較

エンティティは誰にとっても抽象的なものであり、インテントほど直感的なコンセプトのプラットフォームはない。ユーザーは自分で検索するか、ドキュメントやチュートリアルで発見する必要があります。これは、多くの場合、開発者を必要とする作業です。なぜなら、注文番号のようなカスタムエンティティの多くは、正規表現を必要とするからです。

Dialogflowのファジィ・マッチングは、並べ替えられた単語もファジィ・マッチングさせるので、少し強力に思えるが、単語を並べ替えることができる言語でない限り、これはあまり役に立たないようだ。

DialogflowとBotpress の本当の違いは自動展開です。同義語のリストを提供しても、Dialogflowは理解することができます。リンゴ、ナシ、バナナという買い物リストと、「マンゴーを買いたい」という文があった場合、Botpress では正しく検出されませんが、Dialogflow では検出されます。例外を追加することで解決できますが、その分作業が増えます。また、過剰検出の危険性があるという新たな問題も生じます。Dialogflow CXの例外フィールドは、これを処理するように設計されています。全体として、このオプションはダイアログフローに有利です。

一般的なユーザーにとっては、Dialogflow ESの方が、デフォルトのオプションが多く、自動拡張が可能で、タグ付けも便利である。

Dialogflow CXでは、エンティティの文中リストで勝負する。これはBotpress でも可能だが、かなり複雑だ。また、Dialogflow CX はログから情報を隠蔽する機能を備えており、これはユースケースによっ て重要かどうかは異なるが、Botpress を完全に制御できるため、Dialogflow ES に勝っ ているに過ぎない。

Dialogflowでは、エンティティは自動的にタグ付けされ、区別したい場合はユーザーが名前を修正することができます。これは直感的であると同時に、あまり直感的でないような気もするが、使い始めの人にとっては、心配事が一つ減る。Botpress では、ユーザーが発話にタグを付ける前に、まずエンティティを作成する必要がある。

プロダクション・レディの展開chatbots

Botpress は自分でホスティングする必要があり、Dialogflow はすでにホスティングされている、と言うこともできますが、それは正しいイメージではありません。実際には、Botpress Enterpriseがホスティングサービスを提供しており、Dialogflowのデプロイが必要になるでしょう。なぜか？Dialogflowはcloud から完全に実行することができますが、カスタム機能を追加したい場合、その機能をGoogleCloud または他の場所にデプロイする必要があります。

ダイアログフローES

リモートデータベースから注文情報を取得するようなカスタム機能を追加しない限り、コードのデプロイは必要ありませんが、ボットバージョンのデプロイは必要です（すべてcloud ）。

• デプロイする準備ができたら、「設定」から「バージョンの公開」をクリックします。

• 初回リリースやv1.0など、名前をつけてください。

• あなたの環境を "Production "と呼ぶことができます。Cloud Function fulfilmentオプションはWebhookと同じですが、GoogleCloud と統合されています。

• Integrationsページで、必要な統合を選択し、作成した環境を選択します。これで完了です！

1 / 4

カスタム・コードをデプロイするために、他のプラットフォームを選択することもできるが、すべてのドキュメントはGoogleCloudのサーバーレス機能を使用するよう指示している。このapiを使ってコードをデプロイすることになる。

実際には、ボットが少しでも複雑であればAPIにアクセスすることになり、その際にはカスタムコードが必要になります。これは簡単ですが（コマンド一つでコードをアップロードできます）、コードを変更する前にユーザビリティテストを行いたい場合は、Dialogflow ESでエージェントのコピーを作成してテストする必要があります。これを回避する簡単な方法はありません。

ダイアログフローCS

これはDialogflow ESとよく似ている。

• まず環境用のバージョンを作成する必要がある。

• Dialogflow CX はバージョン作成後、Dialogflow ES とほぼ同じ構成になります。環境（ここではProduction）を作成し、Integrationsに移動します。

• Integrationsページで、デプロイするプロダクションを選択することができます。Dialogflow ESのように、カスタムコードをデプロイするために、他のプラットフォームを選択することができますが、すべてのドキュメントは、GoogleCloudのサーバーレス機能を使用することを指します。

• これがDialogflow CXでのファンクションとの連携方法です。Dialogflow ESのようにGoogleCloud Functionsへのショートカットはありませんが、すべて同じように使用できます。

Botpress v12

Botpress のデプロイは通常、データの所有権を維持するためにユーザーによって行われるが、Botpress はニーズに応じてホスティングを行ったり、ホスティングのお手伝いをすることができる。この記事を書いている時点では、セルフサービスのホスティング機能はありません。カスタム機能はBotpress インスタンスにアタッチされるため、Dialogflowよりもデプロイの複雑さが多少軽減される。スケーラブルなデプロイのためには、ホスティングソフトウェアに精通したソフトウェアエンジニアが必要か、Botpress エンタープライズサービスを利用する必要があります。

Botpress Enterpriseには、ボットを特定してドラフトから本番稼動に移行できるパイプラインが含まれていますが、これには本番稼動可能なインスタンスをすでにホストしている必要があります。

• Botpress には、配備を容易にするための本番用チェックリストが用意されている。

• 関数はBotpress 、すべてを一緒にテストすることができ、すべてをレビュー、そして本番へと移行することができる。

インテグレーションとの接続については、ドキュメントに従う必要があります。ほとんどの作業は設定ファイルで行われるため、開発者が対応するか、Botpress Enterprise Servicesが必要です。

比較

カスタムコードを必要としないのであれば、Dialogflow ESに勝るものはありません。直感的で素早い。関数をデプロイする必要がある場合、余計な手順が増えてしまいます。Dialogflow CXは本番環境にデプロイするのが若干難しく（1つ余計なステップがあり、エラーメッセージもあまり目立たない）、カスタムコードに関しても同じ問題がある。GoogleCloud Platformを使用する利点は、cloud 関数を使用する可能性が高いことです。Google関数は最も安価なホスティング方法ではありませんが、非常にスケーラブルな関数を持つ最も簡単な方法です。

Dialogflowの関数をデプロイするプロセスは、新しい関数を作成し、それをホストし、リンクを取得し、Dialogflowのウェブフック/フルフィルメントで更新し、新しいバージョンをテストして動作することを確認し、動作する場合は新しいバージョンをデプロイします。しかし、会話ロジックに合わせて頻繁にコードを更新するのであれば、余計に複雑なレイヤーを追加することになります。Botpress では、コードと会話ロジックは同じ世界に住んでいるので、更新、テスト、デプロイははるかに簡単です。欠点は、開発者がNodejsを使わなければならないことで、慣れていない場合、以前使っていたものによっては学習曲線が必要になる。ただし、ライブラリーが1つしかないため、理論的にはドキュメントがより最新になるはずだ。

カスタムコードがなければ、Botpress 、このカテゴリーでは最悪だろう。実際に何かをホストしなければならないのだから。Botpress はデプロイメントサービスを提供しているので、技術的には何もする必要はありませんが、セルフサービスモデルほど便利ではありません。カスタムコードはDialogflowの利点を否定します。

自分でホスティングする場合、スケーリングの管理という問題がある。もちろん、もしあなたのプロジェクトが外部のサービスを含めることができないのであれば、Botpress 。Botpress にはオープンソース版のデプロイメントに関するドキュメントがあるが、Dialogflowを使った場合のような完全な自動スケーリングアーキテクチャではない。

今回はここまでです。Botpress vs Dialogflow ES vs Dialogflow CXの パート2です。