Dialogflow (Conversational Agents)

解決する課題

• 問い合わせ対応や予約受付などを、人手を介さず自然言語で会話するボットに任せたい
• Web チャット・モバイル・電話 (IVR)・スマートスピーカーなど複数チャネルに同じ会話ロジックを配信したい
• ユーザー発話から意図 (やりたいこと) と必要な情報 (パラメータ) を自動で抽出し、業務システムへつなぎたい
• ルールベースの分岐だけでなく、生成 AI による柔軟な応答や FAQ 自動回答を組み合わせたい
• 音声認識・音声合成を含む電話自動応答 (コールセンター自動化) を構築したい

主要概念と用語

• Dialogflow ES (Essentials): 従来型のエディション。インテントとエンティティを中心に比較的シンプルなボットを素早く作れる
• Dialogflow CX: 上位エディション。フローとステート (状態遷移) で複雑な会話を視覚的に設計でき、大規模・多段階の会話に向く。現在は Conversational Agents として位置づけられる
• インテント (Intent): ユーザーの発話が表す「意図」。訓練フレーズ (例文) を登録すると、未知の言い回しでも近い意図に分類される
• エンティティ (Entity): 発話から抽出するパラメータの型。日付・数値・都市名などのシステム定義型と、独自に定義するカスタム型がある
• フルフィルメント (Fulfillment): 抽出した意図やパラメータを使って外部処理を呼び出す仕組み。Webhook で自社 API や Cloud Functions を実行し、動的な応答を返す
• フロー / ページ / ステートハンドラ (CX): CX で会話を区切る単位。フローは大きな話題、ページは個々の対話状態、ステートハンドラが遷移条件を表す
• Data Store / 生成エージェント: ドキュメントや FAQ を取り込み、生成 AI で根拠付き回答を生成する機能。RAG 的にナレッジから応答を作る
• エージェント (Agent): ボット全体を指す最上位の単位。インテントやフロー、設定をまとめて持つ

仕様・制限・クォータ

• テキストと音声の両方に対応し、音声では内部で音声認識 (STT) と音声合成 (TTS) を組み合わせる
• 多言語に対応し、1 つのエージェントで複数言語を扱える。言語ごとに訓練フレーズを用意する
• 配信チャネルが豊富で、Web/モバイル向け SDK、各種メッセージング連携、電話ゲートウェイ (Phone Gateway / CCAI 連携) などに接続できる
• リクエスト数や同時セッション、エンティティ・インテント数などにクォータや上限があり、エディション (ES / CX) でも異なる。具体的な数値は変動するためドキュメントで都度確認する
• フルフィルメントの Webhook にはタイムアウトがあり、長時間処理は非同期化や事前キャッシュで回避する必要がある

内部の仕組み

Dialogflow の中核は自然言語理解 (NLU) です。ユーザー発話を受け取ると、登録された訓練フレーズをもとに最も近いインテントへ分類し、同時に発話中からエンティティ (パラメータ) を抽出します。音声入力の場合は、先に音声認識でテキスト化し、出力時には音声合成で読み上げます。

ES では「インテント分類 → パラメータ収集 → 応答」という比較的フラットな流れで会話が進みます。CX では会話をフローとページのステートマシンとして表現し、現在のページに紐づくステートハンドラが遷移条件を評価して次のページへ移ります。これにより、確認・再入力・分岐といった複雑な対話を見通しよく管理できます。

意図やパラメータが揃うとフルフィルメントが起動し、Webhook 経由で外部システムを呼び出して動的な応答を組み立てます。さらに生成エージェント機能では、取り込んだ Data Store のドキュメントを根拠に、生成 AI が自然な回答を作ります。

設計パターン / ベストプラクティス

• 単純な FAQ や小規模ボットは ES、多段階で分岐が多い業務会話や生成 AI 統合は CX と、規模で使い分ける
• 訓練フレーズは多様な言い回しを十分に登録し、似すぎたインテント同士を作らない (誤分類の原因)
• パラメータ収集は必須スロットの再質問 (リプロンプト) を設計し、ユーザーが情報を埋めるまで会話を保持する
• フルフィルメントは Cloud Functions / Cloud Run などサーバーレスで受け、外部 API の遅延に備えてタイムアウトとフォールバック応答を用意する
• ナレッジ回答は生成エージェントと Data Store を使い、回答の根拠をドキュメントに限定してハルシネーションを抑える
• 公開前に会話テストとリグレッション確認を行い、想定外発話のフォールバック (デフォルト応答) を整える

運用・監視

• Cloud Logging に会話ログを出力し、どのインテントにマッチしたか、フォールバックが多発していないかを継続的に確認する
• Cloud Monitoring でリクエスト数・レイテンシ・エラー率を監視し、Webhook の失敗やタイムアウトを早期に検知する
• フォールバック率や未解決会話を分析し、訓練フレーズの追加・インテント見直しで継続的に精度を改善する
• エージェントはバージョン管理と環境分離 (開発/本番) を行い、検証済みのものだけを本番にデプロイする
• 音声ボットでは音声認識の誤りが体験に直結するため、認識結果のログを見て用語辞書や言い回しを調整する

コスト

セキュリティ

• IAM でエージェントの編集・実行権限を最小化し、開発者と運用者のロールを分離する
• 会話には個人情報が含まれやすいため、ログの保持期間やマスキングを設計し、不要な機微データを残さない
• 保存データは既定で暗号化され、要件に応じて CMEK (顧客管理鍵, Cloud KMS) を適用できる
• Webhook は HTTPS と認証 (トークンやサービス間認証) で保護し、なりすましリクエストを拒否する
• 機微情報を扱う場合は VPC Service Controls でデータ境界を設け、外部への持ち出し経路を制限する

Well-Architected の観点

• 運用上の優秀性: GUI で会話フローを視覚的に設計・テストでき、バージョンと環境分離、ログ/監視を組み合わせて継続的に改善できる。フォールバック分析から訓練フレーズを足す改善サイクルを回しやすい
• 信頼性: フルフィルメントのタイムアウトや外部 API 障害に備えたフォールバック応答を設計し、会話が途切れない作りにすることが重要

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# 1) API を有効化（CX = Conversational Agents）
gcloud services enable dialogflow.googleapis.com \
  --project=MY_PROJECT

# 2) CX エージェントを作成（リージョンと表示名を指定）
gcloud alpha dialogflow cx agents create \
  --project=MY_PROJECT \
  --location=asia-northeast1 \
  --display-name="support-bot" \
  --default-language-code="ja" \
  --time-zone="Asia/Tokyo"

# 3) 作成したエージェント一覧を確認
gcloud alpha dialogflow cx agents list \
  --project=MY_PROJECT \
  --location=asia-northeast1

# 4) フルフィルメント用の Webhook を Cloud Functions で受ける例（デプロイ）
gcloud functions deploy dialogflow-webhook \
  --runtime=nodejs20 \
  --trigger-http \
  --no-allow-unauthenticated \
  --region=asia-northeast1