Dialogflowとは？ES/CXの違いと使い方をやさしく解説

AIチャットボットを導入したいと考えたとき、最初に名前が挙がるのがGoogleの「Dialogflow」です。しかし、生成AIが当たり前になった今、「ChatGPTだけではダメなのか」「ESとCXの違いがよく分からない」「Vertex AIとどう関わるのか」など、導入判断で迷いやすいポイントも増えています。

この記事では、Dialogflowの全体像からES/CXの仕組みと違い、ChatGPTやClaudeなどLLMとの使い分け、使い方の流れ、チャネル連携までを一通り整理します。読み終えるころには、自分の業務でDialogflowを使うべきかどうか、ESとCXのどちらを選ぶか、そしてどこから着手するかを判断できる状態を目指します。

監修者プロフィール

森下浩志

日本最大級のAI情報プラットフォーム「romptn ai」編集長。著書に「0からはじめるStable Diffusion」「0からはじめるStable Diffusion モデル・拡張機能集編」など、AmazonベストセラーのAI関連書籍を多数執筆。AIにおける情報の非対称性を解消するための社内研修や出張講義も行う。

Dialogflowとは

Dialogflowは、Googleが提供する対話型AI開発プラットフォームです。自然言語処理（NLU）を用いてユーザーの発話意図を理解し、FAQ対応・予約受付・問い合わせの一次切り分けなど、業務に合わせたチャットボットやバーチャルエージェントを構築できます。

2025年時点では、Dialogflowを次の3レイヤーで理解すると整理しやすくなります。

• Dialogflow ES：シンプルなFAQや単発回答向けの基本版
• Dialogflow CX：複雑な会話フローを視覚的に設計できる上位版
• Vertex AIエージェントなどの生成AI連携：意図理解はDialogflow、回答生成はLLMに任せるハイブリッド構成

特にDialogflow CXは会話を「フロー（流れ）」として扱えるため、予約や申し込みなど分岐が多い業務で採用されることが増えています。一方ESは、小規模なFAQや1問1答の問い合わせ、PoC的な小さなチャットボットに向いています。

Dialogflowが選ばれる主な理由

• ブラウザ上の管理画面からノーコードで構築でき、ビジネス部門でも扱いやすい
• Web・LINE・電話（コンタクトセンター）など主要チャネルと連携しやすい
• Googleの自然言語処理により、言い回しの違いや表現のゆれにも比較的強い
• よくある問い合わせの一部から始めて、段階的に拡張しやすい構造になっている

Dialogflow ESとCXの仕組みと違い

Dialogflowはどちらもユーザーの発話を理解するNLUを備えていますが、「会話をどう構造化するか」の考え方がESとCXで異なります。この違いを押さえると、どちらを選ぶべきかが見えやすくなります。

Dialogflow ESの基本：インテント中心のシンプル設計

Dialogflow ESでは、会話を「インテント（意図）」ごとに管理します。たとえば「注文したい」「予約したい」「キャンセルしたい」などの意図ごとにインテントを作り、想定される発話パターンを学習させていきます。

• インテント：ユーザーの意図を表す単位（例：「返品したい」「店舗を探したい」）
• エンティティ：日付、商品名、人数、店舗名など、インテントに付随する情報
• コンテキスト：会話の前後関係を保持する仕組みで、「さっきの注文」のような流れを表現できる

FAQや単発の問い合わせが中心であれば、インテントと応答のセットを増やしていくだけである程度の性能が出るため、ESで十分なことも多くあります。

Dialogflow CXの基本：フローで会話全体をコントロール

Dialogflow CXでは、インテントに加えて「フロー」「ページ」「ルート」といった概念を使い、会話全体をストーリーとして設計します。ユーザーとのやり取りを「一連の手続き」として管理できるのが特徴です。

• フロー：会話全体の大きな流れ（例：予約フロー、問い合わせフローなど）
• ページ：各ステップに相当する画面のような単位（例：希望日時を確認するページ）
• ルート：条件に応じて次のページや別フローへ遷移させるルール
• フォーム：ユーザーから必要な情報（日時、人数など）を漏れなく取得するための仕組み

予約・申し込み・見積もりなど、途中で条件分岐が入りやすいシナリオでは、CXのフロー設計が圧倒的に有利です。「希望日時によって別のルートに分岐させる」「途中から人間オペレーターに切り替える」などの設計も視覚的に行えます。

ESとCXの選び方の目安

どちらを選ぶべきかは、業務内容と将来の拡張性で判断します。

• ESが向くケース：FAQが中心、会話の分岐が少ない、PoCとして小さく始めたい、運用をビジネス部門中心で行いたい
• CXが向くケース：予約・申し込みなどステップが多い手続き系、条件分岐や「戻る」「やり直し」が多い業務、複数チャネルを統合したい、生成AI連携まで見据えた基盤づくりをしたい

また、最近は「ESで立ち上げたボットを、拡張段階でCXに移行する」ケースも増えています。中長期的に大規模運用を考えるなら、最初からCXを前提に設計しておく選択肢も検討する価値があります。

ChatGPT/ClaudeなどLLMとDialogflowの使い分け

生成AIが普及した今、「ChatGPTだけでチャットボットを作ってはいけないのか？」という疑問は多くの担当者が抱きます。この問いに答えるには、LLM単体の特徴とDialogflowの役割を切り分けて考えるのが近道です。

LLM単体の強みと弱み

ChatGPTやClaudeなどのLLMは、次のような強みを持ちます。

• 自然な文章生成が得意で、人間に近い表現で回答できる
• 曖昧な質問や想定外の聞き方にも柔軟に対応しやすい
• 幅広いトピックにまたがる知識を持ち、煩雑な情報の要約もできる

一方で、業務用途では次のような弱みも無視できません。

• 会話の中で「今どのステップにいるか」を厳密に管理し続けるのが苦手
• 本人確認や約款同意など、順番を守る必要がある処理を任せると事故につながりやすい
• ガードレールを適切に設計しないと、誤情報や想定外の回答が混じるリスクがある

Dialogflowの役割と強み

Dialogflowは、LLMとは違うレイヤーで価値を発揮します。

• 会話の流れをフローとして定義し、「どの順番で何を聞くか」を厳密に制御できる
• 一定の条件を満たすまでは次のステップに進ませないなど、手続きの整合性を担保できる
• Web・LINE・電話など複数チャネルとの連携を前提に設計されている

そのため、「ルールが決まった業務フローの制御はDialogflow」「柔軟な文章生成や要約はLLM」という分担にするのが、現実的な設計になりやすいです。

典型的なハイブリッド構成のイメージ

実務でよく採用されるハイブリッド構成は、次のような流れになります。

• ユーザーの発話がDialogflowに送信され、インテントやエンティティを判定する
• Dialogflow CXのフロー・ページが「今どのステップか」「次に何を聞くか」を決める
• 自由度の高い回答が必要な場面だけ、Webhook経由でChatGPTやClaudeなどのLLMを呼び出す
• LLMの出力を必要に応じて整形し、Dialogflowからユーザーへ返す

すべてをLLMに任せるのではなく、「どの場面をLLMに任せ、どの場面をDialogflowで固定するか」を設計することで、柔軟さと安全性のバランスを取りやすくなります。

Dialogflowの使い方：最小チャットボット構築のステップ

ここでは、細かい操作手順ではなく「どのような流れで最小チャットボットを作るか」という全体像を押さえます。まずはESでFAQボットを作るケースをイメージすると分かりやすいです。

プロジェクトを作成する

まず、Google Cloud Platform（GCP）上でプロジェクトを作成し、Dialogflow ESまたはCXを有効化します。組織として既にGCPを利用している場合は、既存プロジェクトに紐づけることも多いです。権限管理や課金の単位もここで決まるため、後の運用をイメージしながらプロジェクトを切っておくとスムーズです。

自動化したい問い合わせとインテント／フローを整理する

次に、「どの問い合わせを自動化したいか」を洗い出し、必要なインテントやフローを設計します。最初からすべてを自動化しようとせず、次の条件を満たすテーマから始めると失敗しにくくなります。

• 問い合わせ件数が多い
• 回答がある程度パターン化されている
• 自動化しても業務上のリスクが低い

トレーニングフレーズを設定する

各インテントに対して、ユーザーが実際に入力しそうな発話（トレーニングフレーズ）を複数登録します。「返品したい」「商品を返したい」「間違って買ったので返金したい」など、同じ意味でも表現を変えて10〜20パターン程度入れておくと、意図理解の精度が安定しやすくなります。過去の問い合わせログがあれば、それを元に作ると現実的なボットになります。

応答と遷移（ルート）を設計する

• Dialogflow ESの場合：各インテントにテキスト応答を設定し、必要に応じてコンテキストで前後関係を管理します。
• Dialogflow CXの場合：ページごとの応答に加え、ルートで「どの条件なら次のページに進むか」「どの条件なら別フローに切り替えるか」を定義します。フォームを使えば、必要な情報を漏れなく取得できます。

この段階で、「どのタイミングで人間オペレーターに切り替えるか」「どこまでを完全自動にするか」といった境界も合わせて決めておくと、運用開始後の混乱を防ぎやすくなります。

テストと改善を繰り返す

Dialogflowコンソールのシミュレーターを使って、実際にユーザーとして対話しながら動作を確認します。想定していなかった言い回しや、うまく認識できない発話が見つかったら、そのままトレーニングフレーズに追加していきます。運用開始後もログを定期的に見ながら、「意図が誤判定されている例」「回答が不足している例」を洗い出し、少しずつ改善していくのが成功パターンです。

主な活用シーンとチャネル連携

Dialogflowは特定の業界に限らず、さまざまな領域で採用されています。ここでは代表的な活用シーンとチャネル連携のイメージを整理します。

Webチャットでの活用

• ECサイトの商品案内、在庫確認、配送状況の案内
• カスタマーサポートの一次受けとして、よくある質問に自動応答
• 営業時間外の問い合わせに対する自動応答や受付

Webチャットでは、自社サイトに埋め込むチャットウィジェットやサードパーティ製のチャットツールと組み合わせて利用するケースが一般的です。

LINE連携での活用

• 飲食店や美容サロンの予約・キャンセル受付
• 会員向けのサポート窓口（ポイント照会、登録情報の確認など）
• キャンペーン案内やクーポン配布と、問い合わせ対応を一元化

LINE連携では、Messaging APIとDialogflowを組み合わせることで、ユーザーは普段使い慣れたLINE上で問い合わせや手続きを完結できます。友だち追加後すぐに使えるため、利用ハードルが低いのも特徴です。

電話・コンタクトセンターでの活用

• IVR（自動音声応答）の高度化・自動化
• 問い合わせ内容の一次切り分けと担当部署への適切な転送
• オペレーター不足対策として、よくある問い合わせをボイスボットで代替

音声認識エンジンと組み合わせることで、電話での会話もDialogflowで処理できます。混雑時に待ち時間を減らしたい場合や、夜間・休日の一次対応を自動化したい場合に特に効果的です。

社内問い合わせボットとしての活用

• PCトラブルやアカウント関連の一次対応（情シス向け）
• 勤怠・経費・福利厚生などに関するルール案内（人事・総務向け）
• 社内ポータルや社内FAQへのナビゲーション

社内問い合わせは「よくある質問が繰り返される」領域の代表例です。Dialogflowで一次回答を自動化することで、担当者の工数を削減しながら、従業員のストレスも下げることができます。

連携に必要な主な仕組み

• Fulfillment（Webhook）：外部システムやAPIと連携するための仕組み。会員情報照会や予約システムとの連携などを担う。
• フロントエンド・ホスティング：Firebase Hostingや自社Webアプリと組み合わせて、Webサイト上にチャットUIを提供する。
• メッセージングAPI：LINEなどメッセージングプラットフォームとの接続に利用する。

よくある質問（FAQ）

Dialogflow ESとCX、どちらを選べばよいですか？

FAQ中心で会話の分岐が少ない場合はES、予約や申し込みなど手続き系でステップや条件分岐が多い場合はCXが適しています。迷う場合は、まずESでPoCを行い、その後の拡張性や運用の手応えを見たうえでCXを検討する方法もあります。

ChatGPTだけでチャットボットを作るのは難しいですか？

単純なQ&Aボットであれば、ChatGPTだけでも実現可能です。ただし、本人確認や予約変更など「順番や条件を厳密に守る必要があるフロー」を含む場合は、Dialogflowなどでフローを制御し、LLMは回答生成に特化させた方が安全です。

費用はどれくらいかかりますか？

Dialogflow自体は利用量に応じた課金モデルで、小規模なPoCであれば比較的低コストで始められます。ただし、GCPの他サービスや通話料金、LLMのAPI利用料なども含めて設計する必要があるため、導入前に大まかなトラフィックを想定して試算しておくことをおすすめします。

生成AIとの連携は難しいですか？

技術的には、Webhookを使ってDialogflowから外部のLLM API（ChatGPT、Claude、Vertex AIなど）を呼び出す構成が一般的です。クラウド開発に慣れたエンジニアがいれば、大きなハードルなく連携できますが、プロンプト設計やガードレール設計など、運用面での工夫は必要になります。

PoCはどの範囲から始めるのがよいですか？

問い合わせ数が多く、回答が定型的で、自動化してもリスクが低い領域から始めるのがおすすめです。例えば「営業時間・アクセス」「パスワードリセット手順」「よくある管理ルール」などです。いきなりすべてを自動化しようとせず、小さな成功体験を積み重ねる方が結果的にスムーズに展開できます。

既存の問い合わせフォームやコールセンターと共存できますか？

多くの場合、既存チャネルを置き換えるのではなく、「最初の入り口としてDialogflowを追加する」形で共存させます。まずはよくある質問や簡単な手続きをボットに任せ、複雑な案件やクレーム対応は従来のチャネルに引き継ぐ形が現実的です。

まとめ

• DialogflowはGoogleの対話型AI基盤で、ESとCXという2つのタイプに加え、Vertex AIなどとの連携によるハイブリッド構成も視野に入れられる
• ESはシンプルなFAQや単発回答に向き、CXは予約・申し込みなど分岐の多い複雑なフローに適している
• ChatGPTやClaudeなどLLMとは競合ではなく、「フロー制御はDialogflow」「柔軟な文章生成はLLM」という役割分担が現実的な最適解になりやすい
• 導入ステップは「プロジェクト作成 → インテント／フロー整理 → トレーニングフレーズ設定 → 応答・遷移設計 → テストと改善」という流れで押さえると迷いにくい
• Web、LINE、電話、社内チャットなど多様なチャネルと連携でき、問い合わせ削減と対応品質向上の両方に貢献しうる

生成AIが普及した今でも、会話フローを正確に制御し、業務プロセスを安全に自動化する基盤としてDialogflowの価値は大きく残り続けます。まずはリスクの低い領域から小さく試し、ログを見ながら少しずつ改善していくことで、自社に合ったチャットボット基盤の形が見えてくるはずです。