DX開発事業部 フルスタックセクションの田村です。
Google Cloud Next ’25 現地参加2日目のイベントレポートをお届けいたします。
セッション情報
セッションタイトル:Control vs autonomy: Tradeoffs in designing AI agents
概要:
AIエージェントの構築を計画しているが、何から始めたらよいかわからない?本セッションでは、開発者と非開発者の両方にエージェント設計の実践的なガイドを提供します。主な設計上のトレードオフ、ベストプラクティス、ユースケース、データ、チームと適切なツールやテクニックのマッチング方法について説明します。
AIエージェント構築の課題
エージェント開発の現場がいかに複雑になっているか、またそれを本番環境で運用することの難しさが強調されていました。
開発が難しい理由
エージェント構築では具体的に以下の課題があるとされています。
- 人の介在が必要
- 複数APIやデータソースとの接続が必要
- 構造化された出力フォーマットの整備が難しい
- 結果の一貫性を保つのが難しい
- フレームワークの乱立と相互運用性の問題
- マルチエージェント構成の複雑さ
- コストとスケーラビリティの課題
開発中には良いAIエージェントを作ったつもりでも実運用に乗せると期待通りに動かないケースがあったり、LangGraphやAutoGenなど開発ツールが乱立しており共存や使い分けが難しくなっている状況があると思います。
本番運用が難しい理由
- ツールのガバナンスモデルが必要
- セキュリティ要件の高度化
- セッションごとの詳細な分析が求められる
- ワークフローが絡み合い可視化が難しい
- 突然挙動が変わるエージェントのデバッグ
- トレースによる可視化と監視が必要
- エージェントOps / RAGOps / LLMOpsなどの運用設計
- スキルセットの不足(専門スキルの必要性)
- コスト把握とチャージバック管理の難しさ
エージェント開発はもはやコードを書くだけの話ではなく、データ統合・トレーサビリティ・セキュリティ・運用体制など多角的な観点から取り組んでいく必要があると思います。
特に企業での導入を考える場合は、「AgentOps」や「LLMOps」といったこれまでのシステム運用では考慮が必要なかった監視項目への対応が求められます。
そのため、ただ「開発」するだけではなく「運用〜評価」までを見据えてエージェントライフサイクル全体へアプローチする必要があります。
マルチエージェントアーキテクチャ
このアーキテクチャ図はまだ「エージェント」という言葉が一般的でなかった2023年当時に、将来的なマルチエージェント構成を見越して設計された「自然言語からSQLの生成・実行・検証・可視化までを担うパイプライン」とのことです。
エンタープライズ運用では「SQLの正確性」や「複数のデータソースへの対応」が不可欠ですが、こうした要件に対して「ひとつのLLMにすべてを任せる」のではなく、「タスクごとに責務を分離する」構成が効果を発揮したようです。
今でこそエージェントが検証や再試行のループまで担ってくれますが、このような責務分離によって正確性・再現性を確保するアーキテクチャこそがエージェントという考え方の本質にあるのだと思いました。
こちらはGitHubリポジトリに公開されておりますのでご参照ください。
Google Agentspaceによるエージェント活用パターン
エンタープライズ向けに提供されるエージェントの使い方として、3つの抽象化レイヤーが紹介されていました。
Default Agentspace:汎用的な質問対応
Agentspaceにあらかじめ組み込まれている、検索・生産性支援用のデフォルトエージェントです。Slackで質問すると返してくれるような、いわば社内用のGeminiアプリのような存在となっています。
一般的な内容や検索は行うことができますが、内容によっては特化型エージェントを構築して質問をした方が精度が高い可能性があります。
Google製の特化エージェント:用途別に最適化されたプリセット
Googleが用意している事前構築済みのスペシャリストエージェントでたとえば以下のような特定タスクに特化しています。
- 研究支援
- データ分析
- 会議準備
- 金融分析(FSI Agent)
- 営業支援
- クリエイティブ業務サポート など
Google WorkspaceのGeminiで提供されている「Deep Research」機能がこれにあたります。
調査したいトピックを渡すと、インターネット上の情報やモデルの学習データを使ってAIエージェントが調査レポートを作成してくれます。
カスタムエージェント:ニーズに合わせて自由に構築
ユーザー自身や社内管理者がGoogle Cloudや外部プラットフォーム上で独自に構築したカスタムエージェントです。
社内ニーズに合わせて柔軟に作れる上に、マーケットプレイスで買うことも可能です。
これもGoogle WorkspaceのGeminiでいう「Gem」機能と言ったところでしょうか。
ユーザー自身が指示を与えてカスタマイズされたエージェントを作ることができます。
GoogleのAIエージェント技術スタック
AIエージェントを構築するための技術スタックとして以下のサービスが紹介されていました。
- Agent Gardenでサンプルから構築をスタート
- Google ADKでエージェントの内部ロジックや連携構成を定義
- Agent Engineでモニタリング・セッション管理・スケール運用まで対応
Agent Garden — はじめの一歩に最適
- GUIベースでサンプルやテンプレートを使って簡単にエージェントを構築
- 開発経験が少ないユーザーでも扱いやすい
- ノーコード/ローコードに対応
Google Agent Development Kit(ADK)— 本格開発向けのOSS SDK
- マルチエージェント構成の設計・テスト・開発が可能
- エージェントのオーケストレーションやツール呼び出しの定義ができる
- Vertex AIとの高い親和性
Agent Engine — フルマネージドで安心の本番環境
機能 | 説明 |
---|---|
Monitoring & Logging | ログや動作状況を収集・可視化。トラブル時も安心 |
Session Management | 会話の履歴やステート管理を自動で実施 |
Example Store | 一貫性のある出力を実現するための事例ストア |
Evaluation | 出力の品質や精度を継続的に評価 |
Long-term Memory | 長期的な状態保持。文脈を跨いだ判断や回答に役立つ |
Agentic Autorater | 自動評価機能(開発中)で継続的な品質改善を実現 |
エージェントの開発のライフサイクル
AIエージェントを「構築 → 接続 → 利用・配布」するまでの一連のライフサイクルを体系化して紹介されていました。
開発のライフサイクルは大きく3つのフェーズに分かれており、それぞれのフェーズでGoogleのサービスやOSSを組み合わせて活用できます。
Build Agents(エージェントを構築)
- Google Agentspace 内でのノーコード開発
- Google Agent Development Kit(ADK)+ Agent Engine によるローコード/フルコード開発
- オープンエコシステム(例:LangGraph, CrewAI, Autogen, Genkit など)に対応
- Agent2Agent プロトコル(A2A) によりマルチエージェント連携が可能
Discover and Connect Agents(発見して接続)
- Vertex AI Agent Garden によるエージェントテンプレートやサンプルの公開・利用
- Cloud Marketplace / Agent Gallery からの接続
- 「My Agents on Agentspace」による社内公開
Use and Distribute Agents(利用して配布)
- Google Agentspace を、社内ユーザーに向けた一元管理ハブとして利用可能
- データとエージェントを集中管理し、パーソナライズ提供
- 他の社内外のアプリケーションやインターフェースとの連携も可能
これまでのように「ただ作って終わり」ではなく、開発者から業務ユーザーまですべての層がエージェントを活用しやすい、いわゆる循環型のエコシステムが形成されつつあるのだと感じました。
どのサービスでAIエージェントを作るべきか
ターゲット | オプション | 特徴 |
---|---|---|
Business User | Agentspace | 社内向けの業務効率化を目的としたノーコードUI |
Business User | Conversational Agents | カスタマーサポート向けのUIエージェント構築。自然言語UIに特化 |
Developer (GUI) | ADK on Agent Engine | Google公式SDKを使ってローコードで構築。マネージド実行環境でデプロイ可能 |
Developer (Code) | Any OSS Framework on Agent Engine | LangGraphやCrewAIなど任意のOSSで構築可能。Agent Engineでスケーラブルに実行 |
Developer (DIY) | Gemini + Cloud Run | GeminiのFunction Callingを活用した完全セルフホスティング構成 |
基本的な選定方針としては次のように分けられるかと思います。
- ノーコードで社内業務改善 → Agentspace
- チャットボットやカスタマー向けUIをノーコードで作成 → Conversational Agents
- 自分でしっかり設計 → ADK or OSSフレームワーク
- Cloud Runを使って完全に自由に構築 → Gemini + Cloud Run
個人的に刺さったポイント
エンタープライズ視点で「実装と運用の現実」がしっかり語られていたのが印象的で、特に「複数フレームワークの共存」や「検証・ログ・セッション設計の重要性」はこれからのAIエージェントの開発で意識しておくべきポイントだと思いました。
Google CloudではAIエージェントの開発ライフサイクルが整いつつあり、各種サービスを組み合わせながら活用できるのは大きなメリットと思います。
またどのGoogle Cloudサービスを使ってAIエージェントを構築するべきかを示されていて、導入検討の参考になるセッションでした。
最後に
今回のセッションを通じて、単なるプロンプト改良ではなく「継続運用できる構成」や「社内展開・他エージェントとの接続」、「発見・再利用のしやすさ」という本質的なサービスの価値にフォーカスが移っていると感じました。
今後は、自社でもエージェントを配布・活用できる設計を意識し、段階的に取り組みを進めていきたいと思います。