2025.09.22

GoogleCloudの次世代の対話型 AIプラットフォーム(Dialogflow CX)解説

はじめに

こんにちは、次世代システム研究室のK.X.Dです。
今回、Google Cloud が提供する次世代の対話型 AI プラットフォーム Dialogflow CX について調査しました。
従来の Dialogflow ES (Essentials Edition) と比べ、より大規模で複雑な会話設計に対応できる機能を備えています。
GUI ベースで直感的にフロー管理やシナリオ設計が行えるため、エンタープライズ規模のチャットボットや音声ボットの開発に最適です。

1. Dialogflow CXとDialogflow ES (Essentials Edition)の比較

項目 Dialogflow ES (Essentials Edition) Dialogflow CX
提供開始 旧世代(従来版) 次世代版(エンタープライズ向け)
会話設計モデル インテント中心のシンプル設計 ステートマシン型(フロー & ページベース)※
規模感 小〜中規模のボットに適する 大規模・複雑な会話設計に対応
フロー管理 GUI なし(インテント単位で管理) GUI あり(フローチャート形式で視覚的に管理)
マルチターン会話 制御が難しい(コンテキストで対応) ページ遷移で直感的に制御可能
マルチフロー対応 単一エージェント内で制約あり 複数フローを定義可能(ユースケースごとに分割)
バージョン管理 限定的 バージョン/環境を正式サポート(テスト・本番切替容易)
マルチチャネル Web・モバイル・メッセージング Web・モバイル・メッセージング + CCAI(電話IVRなど)
学習モデル 機械学習ベースの NLU 改良された NLU + 明示的な遷移設計
開発体験 比較的シンプル、学習コスト低め 初期学習コストは高めだが大規模設計に強い
主な利用ケース FAQ ボット、小規模チャット対応 エンタープライズ向けカスタマーサポート、予約、コールセンター連携
料金体系 セッションベース、比較的安価 使用量ベース、ES より高めだが高機能

※ステートマシン型とは
システムやプログラムの動作を 「状態(State)」と「遷移(Transition)」 で表す考え方です。
– 状態(State)
いまシステムが置かれている状況(例:ログイン前/ログイン後、予約中/支払い完了など)
– 遷移(Transition)
ユーザーの入力やイベントによって状態が変わること(例:ログインボタンを押す → 状態が「ログイン前」から「ログイン後」に変化)

イメージ

チケット予約システムの場合
- 状態
   - 開始
   - 座席選択中
   - 支払い中
   - 完了
- 遷移
   - 「座席を選ぶ」 → 開始 → 座席選択中
   - 「支払いに進む」 → 座席選択中 → 支払い中
   - 「決済成功」 → 支払い中 → 完了

2. Dialogflow CXのコンセプト

下記のようなコンセプトであります。

  • Flows
    • “状態(ページ)×遷移”の設計なので、フローは会話を作成する
  • PlayBooks
    • 自然言語により、フロー会話設計する
  • Datastores
    • Datastoresツールにより、ユーザーの質問に対する回答を検索する
    • Faqsなどのチャットボットエージェント実装向け

3. Flows

3.1 役割

会話全体を大きな目的ごとに分割する“上位コンテナ”。各フローの中に複数のページ(状態)を配置し、ページ間・フロー間をトランジションでつなぐ。

3.2 使いどころ

  • 責務がはっきり分かれる領域を分割(予約/請求/本人確認 など)

  • チャネルや言語で分割(Web/音声、日/英 など)

  • 失敗時のリカバリや例外対応を独立(フォールバック専用フロー)

3.3 要素

Agents 会話型エージェント全体
Flows 会話を大目的ごとに区切る単位。フローごとに入口・出口・共通ルールを持てます。
スタートページ / エントリーフルフィルメント (Start Page / Entry Fulfillment) フローに入った直後の処理や挨拶、初期化を定義(例:案内メッセージ、セッション値の初期化)。
ページ (Page) 「状態」を表す最小単位。各ページで入力の収集、ガード(条件)、応答、遷移を定義
フォーム / パラメータ(スロット)(Form / Parameters, Slot Filling) ページで“必要情報”を段階的に聞き取り、必須/任意、再質問プロンプト、デフォルト値などを設定。
ルート(遷移)(Routes) ページで“必要情報”を段階的に聞き取り、必須/任意、再質問プロンプト、デフォルト値などを設定。
ルートグループ (Route Group) 複数ページで再利用する遷移セット。共通のガード・応答・遷移を一括管理。
Webhook 外部APIを呼び出して検証・検索・更新を行い、その結果で応答や遷移を制御。
イベントハンドラ (Event Handlers) No-Match(意図不一致)、No-Input(無入力)、エラー/タイムアウト等の例外イベントに対する処理。
フルフィルメント (Fulfillment) 応答メッセージ、Webhook 呼び出し (Webhook Call)、パラメータ設定 (Set Parameters) など“実行アクション”の塊
Webhook(外部連携)(Webhook) 外部APIを呼び出して検証・検索・更新を行い、その結果で応答や遷移を制御。
セッション / フロー / ページ パラメータ (Session/Flow/Page Parameters) 値のスコープを管理。セッション全体/そのフロー内/そのページ内のいずれで参照・更新するかを使い分け。
応答メッセージ (Responses) テキスト、リッチメッセージ、TTS 用テキスト、カスタムペイロード(チャネル別UI)等。
フォールバック (Fallback) 一定回数の No-Match/No-Input 後のまとめ直し、意図の絞り込み、人間エスカレーション(Handoff)への分岐など。

3.4 事例解説

上記のフローで、「StartPage ⇨ NewOrder -> Order Confirmation」経路をユーザーの注文会話フローを解説したいと思います。

  1. ユーザーは商品注文
  2. エージェントが注文案内する
  3. ユーザーは注文案内により、注文内容を決める
  4. エージェントが注文を承る

参考:https://cloud.google.com/dialogflow/cx/docs/quick/build-agent?hl=ja

Start Page

  •  構成
    • order.new Routes
        • Intent Routes
            • order.newで遷移条件を定義する
            • Training Phrasesに合致した場合、Routeが有効する

       

      •  Transition
        • Routeが有効した場合、遷移ページを定義する
        • New order Pageに遷移する

NewOrder

  • 構成
    • Fulfillment
      • エージェントの最初レスポンスを定義する
    • パラメータ
      • ユーザーの注文商品情報を収集データを定義する
        • Color
          • ユーザーの注文商品のカラーを格納するペラメータ
          • システムのEntity Typesの@sys.color型を定義する
          • Agent response:What color you like?
            • 商品カラーを収集するためのエージェント会話内容を定義する
        • Size
          • ユーザーの注文商品のサイズを格納するペラメータ
          • カスタムのEntity Typesの@sizeで型を定義する
          • Synonyms定義により、ユーザーの該当レスポンスにより正しくSize値設定できる
          • Agent response:ご希望のサイズは?
            • 商品サイズ情報を収集するためのエージェント会話内容を定義する
    • Routes
      • Condition Routes
        • 条件:$page.params.status = “Final”
          • パラメータ収集できましたら、Routesに有効する
        • Transition
          • Routesが有効にした場合、Order Confirmationページに遷移する
      • Condition Routes
        • 条件:true
          • 常にRoutesを有効にする
        • Agent response:I’d like to collect a bit more information from you
          • Routesを有効した場合、ユーザーに返事する内容を定義する

Order Confirmation

  •  構成
    • Fulfillment
      • エージェントの最初レスポンスを定義する
    • Routes
      • 条件:true
        • 最初のページ遷移の際に常にRoutesを有効にする
      • Agent response:End Session
        • Routesを有効した場合、ユーザーに返事する内容を定義する

こちらは最後のページですので、ページの処理が完了しましたら、フローが完了します。

結果:

4. PlayBooks

4.1 役割

人がマニュアルで行ってきた手順(一次切り分け・確認・実行・記録)を、Dialogflow CX の会話フローとして標準化・自動化する

4.2 使いどころ

Flowsと同じ用途で実現できますが、会話のフローは自然言語で定義します。
フローがはっきりルールであった場合は、Flowsの方によく使います。

4.3 要素

項目 何を定義するか(役割) 代表的な内容・例 実装上のポイント
名称 (Name) プレイブックのわかりやすい名前。LLM/開発者がタスクを把握しやすくする。 例)「配送状況の案内」「支払い方法の変更」 自然言語で具体名に。後続のログ検索・可観測性にも効く。
目標 (Goals) そのプレイブックで「達成すべきこと」の要約。 例)「注文番号を確認し、配送状況を回答する」 ゴールが曖昧だと LLM の行動がぶれる。副作用(更新系)は明示。
指示 (Instructions) ゴール達成のためのプロセス手順(実行方針)。 例)1) 注文番号の取得→ 2) API で配送検索→ 3) 到着予定を回答→ 4) 見つからない時は追質問 具体的・段階的に。禁止事項/優先度/言語方針もここで宣言。
例 (Examples) サンプル対話(Few-shot)。発話とエージェントのアクション例。 例)ユーザー:「荷物どこ?」→ Bot:「注文番号は?」→ …(API 呼び出し)→ 回答 Few-shot は LLM 品質に直結。多言語対応時は各言語の例を用意する。
パラメータ (Parameters) 会話で保持・受け渡しする値(ユーザー入力/システム情報/アクション結果)。 例)order_id(入力取得)、eta(API 結果)、need_escalation(判定) Routine Playbook は開始時にセッション値を読み、終了時に書き戻せる/出力(write/return)パラメータで他フロー・他プレイブックへ結果を渡す。

4.4 事例解説

転職サポートのエージェントを定義してみます。

  • Playbook Name
    • New Job Search Guide
  • Goal
    • To assist users in finding a new job by providing guidance on self-assessment, resume building, and effective job searching strategies.
  • Instructions
    • - - Initial Greeting and Goal Setting:
      - - Greet the user and ask about their job search goals (e.g., type of job, industry, location).
      - - Self-Assessment:
      - - Guide the user to identify their skills, interests, and values.
      - - Suggest tools or questionnaires for self-assessment (e.g., career aptitude tests).
      - - Resume Preparation:
      - - Provide tips for creating an effective resume.
      - - Suggest resume templates and examples.
      - - Offer advice on tailoring the resume to specific job applications.
      - - Job Board Navigation:
      - - List popular job boards (e.g., LinkedIn, Indeed, Glassdoor).
      - - Explain how to use search filters effectively.
      - - Advise on setting up job alerts.
      - - Networking:
      - - Highlight the importance of networking.
      - - Suggest ways to connect with professionals in their field (e.g., LinkedIn, industry events).
      - - Next Steps:
      - - Summarize the key steps discussed and encourage the user to take action.
      - - Offer to provide additional resources or support as needed

結果
PlayBooksで、細かくフロー遷移を設定しなくても、自然言語でエージェントの挙動を定義できる

5. Datastores

5.1 役割

FAQ、手順書、ナレッジ記事、Web/ドキュメントなどの知識を検索・参照して、対話中に根拠ある回答を返すための“知識ベース連携”仕組みです。

5.2 使いどころ

  • FAQの大量カバー(長文・更新頻度が高い情報)

  • 手順書・規程の参照(社内ポータルやPDF、ヘルプセンター)

  • 用語集・商品情報の即時検索(最新版への自動追従)

5.3 要素

データストアツールとしてエージェントへの組み込みします。

Web サイト(ドメイン確認必須、最大 200,000 ページのインデックス制限)、BigQuery / Cloud Storage / AlloyDB / Bigtable / Firestore / Cloud SQL / Spanner ほか(追加の制限付きソースもあり)のいろいろソースからデータインポート可能です。
(※参照:https://cloud.google.com/dialogflow/cx/docs/concept/data-store?hl=ja)

インポート形式
– FAQ(構造化):CSV で Q/A を取り込み(title/url 任意)。
Google Cloud
– 非構造化:HTML / PDF / TXT / CSV(テキスト最大 2.5MB 等の制限)。
Google Cloud
– メタデータ付き:JSON Lines で Cloud Storage の URI を参照(タイトル/URL などを付与)。

6. 展開

6.1 Webhook

エージェントはユーザーの回答により収集した情報をWebhook経由で、アプリケーションにレコードとして登録できる

参考:https://cloud.google.com/dialogflow/cx/docs/quick/webhook?hl=ja

 

6.2 生成AI

Generator定義して、Googleの生成AIモーデルでユーザーの回答内容によりレスポンス生成設定も可能です。
参考:https://cloud.google.com/dialogflow/cx/docs/concept/generators?ja=en

Generator設定画面

下記のようなプロンプトで、生成AIの回答で人間へのエスカレーション案内できる
参考:https://cloud.google.com/dialogflow/cx/docs/concept/generators?hl=ja#escalation_to_a_human_agent

# Instructions:

You are a polite customer service agent that handles requests
from users to speak with an operator.

Based on the $last-user-utterance,
respond to the user appropriately about their request to speak with an operator.
Always be polite and assure the user that you
will do your best to help their situation.

Do not ask the user any questions.
Do not ask the user if there is anything you can do to help them.

# Answer:

 

6.3 PlayBooksの遷移定義

PlayBooksで定義するエージェントも自然言語により、Flowsで定義するエージェントと同じで回答フロー遷移で、細かく複数のPlayBooksを役割分割可能

- greet the customer and ask them how you can help.
    - If the customer wants to book flights, route them to ${PLAYBOOK: flight_booking}.
    - If the customer wants to book hotels, route them to  ${PLAYBOOK: hotel_booking}.
    - If the customer wants to know trending attractions, use the ${TOOL: attraction_tool} to show them the list.
- help the customer to pay for their booking by routing them to ${FLOW: make_payment}.

参考:https://cloud.google.com/dialogflow/cx/docs/concept/playbook/instruction?hl=ja

7. まとめ

「DxDialog Flow(Dialogflow CX)」は、ステートマシン型で会話をフロー/ページ/ルートに分解し、複雑な対話を見通し良く設計・運用できる基盤です。
Playbooks、Flowsで業務手順を標準化し、Data Storeで社内外ナレッジを根拠付きに検索・回答、フォールバックや人間へのエスカレーションも一貫制御できます。
Webhookや各種API連携、環境・バージョン管理、テストと分析を備え、Web/音声など複数チャネルへ容易に展開可能。結果として、開発効率・自己解決率・ガバナンスを同時に高める、エンタープライズ向けの対話AIプラットフォームです。


宣伝

次世代システム研究室では、アプリケーション開発や設計を行うアーキテクトを募集しています。アプリケーション開発者の方、次世代システム研究室にご興味を持って頂ける方がいらっしゃいましたら、募集職種一覧 からご応募をお願いします。
皆さんのご応募をお待ちしています。

  • Twitter
  • Facebook
  • はてなブックマークに追加

グループ研究開発本部の最新情報をTwitterで配信中です。ぜひフォローください。

 
  • AI研究開発室
  • 大阪研究開発グループ

関連記事