この記事のポイント
旧称のVertex AI Conversationから現行のConversational Agentsまでの整理
PlaybooksとFlowsを組み合わせるハイブリッド会話設計
テキストと音声をまたぐ自己解決導線の構築基盤
リクエスト課金と音声秒課金の見積もり勘所
検索基盤や汎用エージェント基盤との使い分け

Microsoft MVP・AIパートナー。LinkX Japan株式会社 代表取締役。東京工業大学大学院にて自然言語処理・金融工学を研究。NHK放送技術研究所でAI・ブロックチェーンの研究開発に従事し、国際学会・ジャーナルでの発表多数。経営情報学会 優秀賞受賞。シンガポールでWeb3企業を創業後、現在は企業向けAI導入・DX推進を支援。
Vertex AI Conversationは、Google Cloudが会話型AIアプリや音声ボットを構築するために提供していた機能名です。2026年4月時点では単独の現行製品名というより、旧称として理解するほうが正確です。
現在の公式導線では、Vertex AI ConversationはVertex AI Agentsへの改称と、Dialogflow CXとの統合を経て、Conversational Agentsの文脈で整理する必要があります。本記事では、旧称から現在の位置づけ、主な機能、向いているユースケース、始め方、料金、導入事例までを公式一次情報ベースで解説します。
目次
Vertex AI Conversationの現在の位置づけ
Dialogflow CXとの統合でConversational Agentsへ集約
Vertex AI Conversationが向いているユースケース
Vertex AI Conversationと他サービスの違い
Microsoft Foundry Agent Serviceとの違い
Vertex AI Conversationとは
Vertex AI Conversationは、Google Cloudが2023年に一般提供した会話型AI構築機能の名称です。Google Cloud Blogでは、基盤モデルを使ったチャットボットや音声ボットを、Webサイトや文書をもとに短時間で構築できる機能として紹介されていました。ルールベースの対話制御と生成AIを組み合わせ、予約や購入のような業務アクションまで会話に載せられる点が特徴でした。
一言でいえば、Vertex AI Conversationは、Vertex AI上で顧客向け・社内向けの会話型AIを作るための旧称プロダクトです。検索寄りのVertex AI Searchに対して、こちらはチャットや音声対話を主役にした製品でした。
ただし、2026年4月時点でこの名称をそのまま現行製品名として理解するとズレます。現在は名称変更とコンソール統合が進んでいるため、旧称のまま記事を書くと、現行ドキュメントや料金ページと噛み合わなくなります。

Vertex AI Conversationの現在の位置づけ
Vertex AI Conversationを2026年時点の公式表現で読み替えるには、名称変更と統合の流れを押さえる必要があります。ここを最初に整理しておくと、現行ドキュメントを追いやすくなります。
2024年4月にVertex AI Agentsへ改称

Dialogflowのリリースノートでは、2024年4月30日にVertex AI Conversation has been renamed to Vertex AI Agents と明記されています。つまり、旧称のVertex AI Conversationは、2024年春の時点でVertex AI Agentsへ名称変更されました。
その後、同じリリースノートでは、旧Vertex AI Conversation配下だったdata stores、playbooks、agent appsの更新がVertex AI Agents名義で記録されるようになります。旧称で検索すると情報が古いように見えるのは、この改称が大きな理由です。
Dialogflow CXとの統合でConversational Agentsへ集約
現行のConversational Agentsの公式ドキュメントでは、一部製品や機能の名称変更と、generative playbook / flow機能の単一コンソールへの移行が進んでいると案内されています。
さらにConversational Agents console overviewでは、新しいコンソールがDialogflow CXとVertex AI Agent Builderコンソールの機能を含み、generative playbooks、generative data stores、deterministic flowsを1つの画面で扱うと説明されています。
要するに現在の実務上の理解は、旧Vertex AI ConversationはVertex AI Agentsへ改称されたうえで、Conversational Agents consoleへの統合と名称移行が進んでいるというものです。
新規導入を考えるなら、旧名称そのものではなく、現在のConversational AgentsとDialogflow CXの文脈で見るほうが正確です。
旧称キーワードをどう読み替えるか
旧称のVertex AI Conversationで探している読者が実際に知りたい内容は、大きく次の3つに分かれます。
- 会話型AIや音声ボットを作りたい
現在はConversational AgentsとDialogflow CXの機能を確認するのが近道です。
- 社内文書を根拠に回答するQ&Aを作りたい
現在はdata storesやQ&A Agentの導線を見るべきです。
- より広いAIエージェント基盤まで含めて見たい
その場合は会話特化の枠を超えるため、AIエージェント全体や他のエージェント基盤と比較したほうが判断しやすくなります。
つまり、旧称のVertex AI Conversationは今も概念的には通じますが、導入判断では現在の正式な製品配置へ読み替えることが必須です。
Vertex AI Conversationの主な機能

現在のConversational Agents系機能を見ると、旧Vertex AI Conversationの価値は「会話AIを作れる」こと自体ではなく、生成AI、ルールベース制御、検索接地、音声対話を組み合わせられる点にあります。代表的な要素を整理すると、次のとおりです。
| 機能 | できること | 向いている場面 |
|---|---|---|
| Playbooks | 自然言語指示で生成AIエージェントの振る舞いを定義 | 柔軟な自己解決や手順誘導 |
| Flows | 明示的な会話フローと状態遷移を設計 | 手続きが厳密な問い合わせや認証 |
| Data stores | Webサイト、文書、DBを根拠に回答生成 | FAQ、ナレッジ検索、社内Q&A |
| Text/Voice対応 | テキストと音声の両方で会話を処理 | チャットボット、音声ボット、IVR |
| テストと履歴 | Simulator、history、test casesで品質検証 | PoCから本番への改善運用 |
この表から分かるように、現行のVertex AI Conversation系機能は、完全生成AIでも完全ルールベースでもなく、その間を設計できるハイブリッド会話基盤です。
Playbooksで生成AIの振る舞いを定義する

Playbooksの公式ドキュメントでは、playbookをgenerative agentsの基本構成要素と説明しています。各playbookには目的、手順、会話例、パラメータを持たせることができ、外部サービスへの問い合わせや別playbookへの委譲、flowへの引き渡しも可能です。
この仕組みによって、単なるプロンプト1本ではなく、役割ごとに分けた対話ステップを設計できます。たとえば、本人確認、問い合わせ分類、ナレッジ回答、必要なら人間への引き継ぎという流れを、playbook単位で切り分ける使い方ができます。
一方で同じドキュメントでは、playbook機能はDialogflow CXのSLA対象外である点が明記されています。また、Playbooks overviewでは電話システムのDTMF入力に関する制約も案内されているため、音声やIVRの要件が厳密な場合はflow中心の設計も検討したほうが安全です。
Flowsで決定論的な会話を組み込む
Flowsの公式ドキュメントでは、flowを複数ターンにまたがる会話トピックと経路を定義する仕組みと説明しています。これは旧来のDialogflowが得意としてきたルールベースの強みを引き継ぐ部分です。
決まった質問順序、本人確認、支払い確認、注文変更など、「順番を守らないと危ない」業務ではflowが効きます。Generative AIだけで会話を回すより、状態遷移を明示できるので、再現性と監査性を担保しやすくなります。
つまり会話型AIで重要なのは、全部を生成AIに任せることではありません。どこを自由度高くし、どこを固定するかを分けられる点が、この系統の大きな価値です。
Data storesで根拠付き回答を返す
Data storesの公式ドキュメントでは、data storeはエンドユーザーの質問に対して自社データから答えを見つけるために使われ、回答には根拠リンクも返せると説明されています。データソースとしてはWebサイト、BigQuery、Cloud Storage、AlloyDB、Bigtable、Firestore、Cloud SQL、Spannerなどが案内されています。
このため、FAQやナレッジ検索を会話UIに載せたい企業には相性が良いです。検索結果をそのまま並べるのではなく、会話の中で要約しながら返せるため、単純な検索ボックスより自己解決率を上げやすくなります。
また、同じページでは最大5つの回答スニペットを返せることや、ACL付きデータストアでは閲覧権限に応じて応答を制御できることも説明されています。社内向けヘルプデスクや限定公開情報の案内では、この制御が実務上かなり重要です。
テキストと音声をまたぐ対話基盤
Conversational Agentsの公式ドキュメントでは、テキスト入力と音声入力の両方を扱え、テキストまたは音声で応答できると説明されています。さらに、2025年4月のGoogle Cloud Blogでは、HD voicesや自然な抑揚、評価機能、観測性の強化も案内されています。
このため、Webチャットだけでなく、電話や音声セルフサービスまで視野に入れる企業には適しています。単純なチャットアプリよりも、顧客対応やコンタクトセンター業務を前提にした設計要素が厚い点が特徴です。
Vertex AI Conversationが向いているユースケース

Vertex AI Conversation系機能は、汎用AIチャットを雑に作るためのものではありません。会話体験を業務導線に乗せたいケースで真価が出ます。
カスタマーサポートの自己解決導線
製品FAQ、配送状況、予約、注文変更、会員手続きのように、問い合わせの大半が一定パターンに収まる業務では特に向いています。自由な自然言語入力を受けつつ、必要な場面だけflowで順番を固定し、data storeで根拠付き回答を返せるためです。
特に、チャットだけでなく音声ボットも視野に入っている企業では、一般的な生成AIチャットより候補に上がりやすいです。問い合わせ件数が多く、人手対応のコストを減らしたい企業ほど効果が出やすくなります。
社内ヘルプデスクや業務ナレッジ窓口
社員向けの規程検索、業務手順案内、情シスFAQ、人事総務の問い合わせ窓口にも向いています。Data storesで文書やWebを根拠に回答しつつ、playbookやflowで不足情報を聞き返せるため、単なる検索UIより使い勝手を上げやすいです。
もし社内で「検索はあるが使われていない」「毎回同じ問い合わせがSlackやメールで飛んでくる」という状態なら、会話UIにする価値があります。検索よりも、問い返しや次のアクション提示まで必要な業務に強いからです。
ハイブリッド会話が必要な業務
Generative versus deterministicの公式ガイドでは、Dialogflow CXはfully generative、partly generative、deterministicを選び分けられると説明しています。つまり、自由会話と厳密制御のどちらか一方ではなく、その中間を設計できます。
この特性は、本人確認や約款確認のような固定手順と、製品説明やFAQのような自由回答が混ざる業務で特に有効です。金融、通信、旅行、ECサポートのような複合的な問い合わせに向いています。
向かないケース
反対に、次のようなケースでは別の選択肢のほうが素直です。
- 検索やレコメンドが主目的の場合
チャットや音声より検索体験が主役なら、会話基盤よりVertex AI Searchのほうが直線的です。
- マルチエージェントや業務自動化全体を設計したい場合
問い合わせ応答より、複数ツールをまたぐ自律処理が中心なら、より広いエージェント基盤を見たほうが判断しやすくなります。
- 小規模で単純な意図分類だけで十分な場合
複雑なgenerative要素や音声導線が不要なら、シンプルなボット構成でも足りることがあります。
要するに、Vertex AI Conversation系機能は「会話型の自己解決導線」を本気で設計したい企業向けです。単なるFAQ検索や単純チャットだけなら、もっと軽い構成も選択肢になります。
Vertex AI Conversationの始め方

現行の導線では、旧Vertex AI Conversationを直接探すより、Conversational AgentsとDialogflow CXの手順を追うことになります。最初は小さな業務シナリオでPoCするのが安全です。
最小構成の進め方
最初の検証は、次の4段階で進めると整理しやすくなります。
- まずは対象業務を1つに絞ります。公開FAQ、社内規程、人事問い合わせ、予約確認など、成功指標が明確なテーマを選びます。
- 次に、playbook中心にするか、flow中心にするかを決めます。柔軟な応答が主ならplaybook、手順固定が重要ならflowを優先します。
- 根拠が必要な業務なら、data storeを追加してWebサイトや文書、BigQueryなどを接続します。
- 最後に、Simulatorでテキストまたは音声の対話を試し、conversation historyやtest casesを使って品質を確認します。
この順番にすると、最初から全部入りの会話基盤を目指さずに済みます。PoCの成否は、機能の多さではなく、自己解決率や対応時間の改善につながるかで判断したほうがぶれません。
導入判断で詰まりやすい論点
導入判断で特に詰まりやすいのは、次の3点です。
- 柔軟さと再現性のどちらを優先するか
自由な会話を重視するほどplaybook寄りになり、厳密な業務手順を守るほどflow寄りになります。
- 検索基盤で十分か、会話基盤が必要か
検索結果を出せれば十分なのか、問い返しや本人確認、次アクション提示まで必要なのかで選ぶべき製品が変わります。
- 音声チャネルまで本当に必要か
チャットだけなら軽く始められますが、電話や音声導線まで入ると設計論点が増えます。
この3つを先に決めると、PoCが迷走しにくくなります。特に「検索」と「会話」を同じものとして扱うと、製品選定がズレやすいです。
Vertex AI Conversationの導入事例
現行の事例は、旧称のVertex AI Conversation単体というより、Conversational AgentsやCustomer Engagement Suiteの文脈で紹介されることが増えています。ここでは公式公開情報から、示唆の大きいものを3つ挙げます。
loveholidays
2025年4月のGoogle Cloud Blogでは、loveholidaysがConversational Agentsで構築したセルフサービスAIエージェントによって、顧客の55%が1分未満で回答を得られるようになったと紹介されています。さらに、多言語対応によって既存の人員体制のまま欧州市場へ拡張し、年間300万ポンドの運用コスト削減にもつながったとされています。
この事例から分かるのは、会話AIの価値が単なる自動応答ではなく、サポート速度と運用効率の両方に効くことです。問い合わせ量が多く、言語対応も必要な企業には特に参考になります。
YouTube
同じ記事では、YouTubeがConversational Agentsを活用して音声とSMSチャネルでの情報収集体験を改善し、Agent Assistと組み合わせることで平均処理時間を23%削減したと説明されています。さらに、キュー離脱も75%削減したとされています。
ここで重要なのは、会話AIが完全自動応答だけでなく、人間のオペレーターを支援する形でも効果を出している点です。セルフサービスと有人対応の中間にある運用改善でも価値が出ると分かります。
C1
2023年8月のGoogle Cloud Blogでは、C1がVertex AI Conversationを使って顧客対応と社内向けの両方で生成AIボットを構築し、コールハンドリング時間の短縮を確認していると紹介されています。また、短期間で構築・展開でき、顧客データとエンドユーザーデータを守りやすい点も評価されています。
この事例は、旧称のVertex AI Conversationが当初から「会話の柔軟さ」と「企業データ保護」の両立を訴求していたことを示しています。現在のConversational Agentsでも、その方向性は維持されています。
もし自社で試すなら、最初から全問い合わせを置き換えるのではなく、1つの高頻度業務に絞って自己解決率、平均処理時間、一次解決率を測る進め方が堅実です。会話AIの良し悪しは、デモの自然さよりKPIで見るほうが失敗しにくくなります。
Vertex AI Conversationの検証を業務導線まで進める
会話AIの先にある接続設計・運用管理を整理
Vertex AI Conversation系の会話AIを作れても、実運用では業務システム接続、権限設計、実行管理まで含めた設計が必要です。AI Agent Hubの資料で、Vertex AI Conversationの検証を業務成果につなぐ全体像をご確認ください。
Vertex AI Conversationと他サービスの違い

Vertex AI Conversation系機能を選ぶうえでは、「会話そのものを設計したいのか」「検索を主役にしたいのか」「より広い汎用エージェント基盤が欲しいのか」を切り分けると整理しやすくなります。
| 観点 | Vertex AI Conversation系 | Vertex AI Search | Microsoft Foundry Agent Service |
|---|---|---|---|
| 主な役割 | チャット/音声の会話型エージェント | 検索、要約、推薦、Q&A | 汎用エージェントの構築・公開・運用 |
| 中核機能 | Playbooks、Flows、Data stores | Search、answers、recommendations | Runtime、tools、publishing、identity |
| 向くケース | サポート、IVR、自己解決導線 | サイト内検索、文書検索、RAG検索 | 業務自動化、ツール実行、広い業務Agent |
| 入口 | Conversational Agents console | AI Applications / Discovery Engine API | Foundry portal / API / SDK |
この表から分かるとおり、Vertex AI Conversation系機能の強みは「会話導線」にあります。検索結果を返すだけでなく、問い返し、音声、フロー制御まで必要なケースで価値が出やすいです。
Vertex AI Searchとの違い
Vertex AI Searchの公式ドキュメントでは、検索と推薦体験の構築に主眼が置かれており、Webサイト、非構造化文書、構造化データに対する検索とRAGを提供すると説明されています。一方で、Vertex AI Conversation系は会話の継続、音声、手順制御、エージェント応答設計が主役です。
したがって、FAQや社内文書を探せれば十分なら検索基盤のほうが素直です。逆に、情報提示だけでなく会話の流れを作りたいなら、Vertex AI Conversation系のほうが適しています。
Microsoft Foundry Agent Serviceとの違い
Microsoft LearnのFoundry Agent Service概要では、Foundry Agent Serviceを、複数モデルとツール、公開導線、エージェントランタイムを備えた汎用エージェント基盤として説明しています。Web検索、ファイル検索、メモリ、コード実行、MCPサーバー、TeamsやMicrosoft 365 Copilotへの配布が前面に出ています。
そのため、Microsoft 365やEntra中心の企業で、会話だけでなく業務Agent全体を広く運用したいなら、Microsoft Foundry Agent Serviceのほうが自然な場合があります。反対に、Google Cloud上でテキスト/音声の会話導線を磨きたいなら、Vertex AI Conversation系のほうが用途に直結しやすいです。
Dialogflow ESとの違い
Dialogflow ESの公式ドキュメントは、会話UIを作る自然言語理解プラットフォームとして現在も提供されていますが、最新のConversational Agents系と比べると、生成AIベースのplaybooksや統合されたdata storesの位置づけは前面に出ていません。
このため、小規模で意図分類中心のボットならESでも足りますが、生成AIと決定論的フローを混ぜたハイブリッド設計を本格的にやりたいなら、現行のConversational Agents系を見るべきです。
Vertex AI Conversationの料金体系

現在の料金は旧称のVertex AI Conversationではなく、Conversational Agents pricingで確認するのが正確です。実務上は、FlowsとPlaybooksで単価が分かれる点が最も重要です。
基本の課金体系
2026年4月4日時点の公式価格ページでは、代表的な価格は次のとおりです。
| 項目 | 価格 | 補足 |
|---|---|---|
| FlowsのChat | 0.007ドル / 1リクエスト | 決定論的エージェント向け |
| PlaybooksのChat | 0.012ドル / 1リクエスト | 生成系機能を使う会話向け |
| FlowsのVoice | 0.001ドル / 1秒 | 音声秒課金 |
| PlaybooksのVoice | 0.002ドル / 1秒 | 生成系の音声会話向け |
| Data Store index storage | 月10GiBまで無料、その後は1GiBあたり5ドル / 月 | 生データ量ベース |
この表から分かるのは、生成要素を使うほどPlaybooks単価側で見る必要があることです。単にチャットを返すだけか、生成AIで柔軟な会話をさせるかで費用感が変わります。
ハイブリッド構成の料金の読み方
同じ価格ページでは、hybrid agentの課金ルールも明記されています。FlowからPlaybookやData Storeを呼ぶ場合は、そのターンだけPlaybooks課金になります。一方で、PlaybookがFlowを呼ぶ構成では、会話全体がPlaybooks課金として扱われます。
この違いは見落としやすいですが、実務では重要です。少しだけ生成AIを混ぜるつもりでも、呼び出し方によって総額が変わるため、PoCの段階で構成と課金を一緒に確認したほうが安全です。
料金で見落としやすい点

見落としやすいのは、次の3点です。
- 設計時リクエストは無料
価格ページでは、Visual builderの操作やリソース一覧取得などのdesign time requestsは無料とされています。
- 音声は秒単位で課金される
Voiceは会話ターンごとに、入力秒と出力秒の合計が課金対象になります。
- PlaybooksはSLA対象外
価格ではなく運用品質の論点ですが、playbook機能はSLA対象外である点を設計時に見落とさないほうがよいです。
要するに、会話型AIの料金は「1セッションいくら」では見積もりにくいです。どこまでをFlowで固定し、どこからをPlaybookで生成的に処理するかで費用が変わります。
Vertex AI Conversationの検証をPoCで終わらせないなら
Vertex AI Conversation系の会話AIは、デモ段階までは比較的早く作れます。ただし本番で成果を出すには、どの問い合わせを自動化するか、どこで人に引き継ぐか、どのシステムとどう接続するかまで詰める必要があります。
特に、チャットや音声の会話が成立しても、業務フローに接続されなければROIは見えません。会話設計だけでなく、権限、実行ログ、既存システム連携まで含めて設計できるかが定着の分かれ目です。
AI総合研究所のAI Agent Hub資料では、Vertex AI Conversation系の会話AIを前提に、業務システム連携、管理ダッシュボード、実行導線の整備をどう進めるかを整理しています。Vertex AI Conversationの検証を本番運用へつなぐ判断材料としてご確認ください。
AI総合研究所としては、問い合わせ導線を会話AIに置き換えたい企業ほど、最初に「高頻度で定型性の高い問い合わせ」から着手することを推奨します。いきなり全チャネルを自動化するより、成功パターンを1つ作るほうが本番展開しやすいです。
Vertex AI Conversationの検証を業務導線まで進める
会話AIの先にある接続設計・運用管理を整理
Vertex AI Conversation系の会話AIを作れても、実運用では業務システム接続、権限設計、実行管理まで含めた設計が必要です。AI Agent Hubの資料で、Vertex AI Conversationの検証を業務成果につなぐ全体像をご確認ください。
Vertex AI Conversationのまとめ
Vertex AI Conversationは、現在では旧称として理解すべきキーワードです。2026年4月時点で新規導入を検討するなら、Vertex AI Agentsへの改称と、Dialogflow CXとの統合を踏まえ、Conversational Agentsの文脈で機能と料金を確認する必要があります。
強みは、playbooks、flows、data storesを組み合わせて、テキスト/音声の会話導線を本番向けに設計できることです。検索だけでよいのか、会話まで必要か、汎用エージェント基盤まで見るべきかを切り分けながら、自社に合うレイヤーを選ぶのが現実的です。








