これは、Claude Code を使いこなす話ではない
Claude Code という存在が「なぜ成立しているか」を Google が丸ごと無料公開した話だ
それが Startup Technical Guide: AI Agents である
Google が本気で作った AI エージェントガイド
Google Cloud が公開したこのガイドはマジでヤバい。全 64 ページにわたって、AI エージェントの基礎概念からプロトタイプ、そして本番スケールまでの一気通貫なロードマップが詰め込まれている
よく分かってないが、まとめてみる
どんな話なの？
Claude Code を使って満足してる人へ。これは「AI エージェントを使う話」ではない
「AI エージェントを、プロダクトとして、労働力として、インフラとして作る話」である
例えば、Claude Code をどう使いこなすか、ではなく
Claude Code という存在をどういう設計思想で成立させているか、それを自分たちでも再現するならどうするか。その答えが、このガイドに書いてある
「今は、Claude Code が完成されていて、それを使いこなすほうが早いって風潮じゃね？」って思った人もいるだろう
しかし、これは 優劣ではなくレイヤーの違いの話なのである
今は Claude Code / Cursor / Devin / Antigravity みたいな 完成済みエージェントを使いこなす方が圧倒的に速い
理由はシンプルで
- 設計が要らない
- 評価も運用も考えなくていい
- 即、作業量が増える
- 学習コストが低い
個人開発者や小規模チームなら「使わない理由がない」フェーズ
なので今の風潮として「まずは Claude Code を使え」は、完全に正解
ただし、このガイドが立っている場所はそこじゃないんよ
この Google ガイドは「Claude Code がなぜ成立しているかの設計図」を説明している
今の多くの人は「エージェントを使って仕事を速くしたい」って思ってる
だが、Google が話しているのは「エージェントを社会インフラとしてどう作るか」
これを問うている
Claude Code が完成されているのは事実だけど万能ではない
- 自社 API に深く触れさせたい
- 業務ルールを厳密に守らせたい
- 監査ログが必須
- 誤動作を定量評価したい
- 顧客向けに提供したい
この瞬間に「使うだけ」では足りなくなる
そのとき初めて「あ、これ Claude Code 的なものを自分たちで作る側の話だな」になる
Google ガイドはその「詰む未来」を前提に書かれている
短期的には
Claude Code を使いこなす方が 100 倍速い
中期的には
Claude Code を部品として扱える人が強い
長期的には
Claude Code 的なエージェントを
自分たちの文脈で再構築できる人・組織が勝つ
今は「完成品を使え」
でも Google は「どうせ次は作る側になるだろ？」
という前提で、未来の設計書を先に配っている
ワイは、「最終的に勝ちたいならこれを読め」という Google のメッセージに思えた
…ってことで、その設計書、具体的に何が書いてあるのか見ていこうや
AI エージェントって結局何なのさ？
まず基本から押さえておこう。AI エージェントってのは、単なるチャットボットとは全然違うよ
一般的に、AI エージェントっていうのは、目標を与えられると、自律的にタスクを実行する AI システムなんよね
Google と Alphabet の CEO である Sundar Pichai は、公式の場でこう定義している。「AI エージェントとは、高度な AI モデルの知性とツールへのアクセスを組み合わせたシステムであり、ユーザーに代わってアクションを実行できる。ただし、ユーザーのコントロール下で」と
従来の LLM アプリケーションは、ユーザーからの入力を受けて出力を返すだけだった。でもエージェントは違う。自分で考えて、ツールを使って、複雑なタスクを自律的にこなしていく
具体的にいうと、エージェントには以下の主要コンポーネントがある
- モデル（推論エンジン）：Gemini などの LLM がエージェントの「脳」として機能する
- ツール：外部 API、データベース、ファイルシステムなどにアクセスする手段
- オーケストレーション：複数のステップを計画・実行する仕組み
- メモリ：過去の会話や状態を記憶して、文脈を維持する能力
エージェントの動作フローはこんな感じだ
- ユーザーがエージェントにプロンプトを送る
- モデルが必要なツールを選択し、リクエストをフォーマットする（Function Calling）
- エージェントフレームワークが選択されたツールを実行する
- モデルがツールの出力を解釈し、ユーザーへの応答を生成する
この「ツールを選んで実行する」ってところがめっちゃ重要で、これがあるからエージェントは複雑なタスクを段階的に処理できる
ReAct ループという思考パターン
エージェントの推論プロセスを理解するには、ReAct（Reasoning and Acting）というフレームワークを知っておく必要がある
ReAct は、エージェントが「考える」と「行動する」を交互に繰り返すパターン。具体的には以下の 3 つのステップをループする
Reason（推論）ステップでは、エージェントが現在のゴールと状態を評価して、次に何をすべきか論理的な仮説を立てる。「ユーザーは天気を知りたがってる。まず位置情報を確認して、それから天気 API を呼び出そう」みたいな感じだ
Act（行動）ステップでは、推論結果に基づいて適切なツールを選択し、必要なパラメータを抽出・フォーマットする。これが Function Calling。例えば「weather_api を呼び出す。パラメータは location=Tokyo」みたいに具体的なアクションに落とし込む
Observe（観察）ステップでは、ツールの実行結果を受け取って解釈する。「天気 API から『晴れ、25 度』というレスポンスが返ってきた」というように、外部からの情報を取り込むんよ
このループを繰り返すことで、エージェントは複雑なタスクを段階的に処理していく。一回のループで終わることもあれば、何十回もループすることもある。タスクの複雑さによって変わる
重要なのは、このループのどこかで失敗すると、最終的な出力も間違ったものになるってこと。だから AgentOps では、各ステップを個別に評価する仕組みが用意されている
モデル選択が成功のカギを握る
エージェントの「脳」となるモデルの選択は、めっちゃ重要な意思決定だ。Google のガイドでは「最も強力なモデルを選ぶのが正解ではない」と強調している
モデル選択のポイントは、capability（能力）、speed（速度）、cost（コスト）の 3 つのバランスを最適化すること。すべてのモデルはこの 3 つの軸で評価できて、ユースケースに応じて最も効率的なオプションを選ぶのが正解だ
モデルの能力が上がると、コストとレイテンシも上がる傾向がある。よくある失敗は、ユースケースが必要としない能力に過剰投資すること。これは無駄な支出と遅いパフォーマンスにつながる
Google のガイドでは、ユースケース別に推奨モデルが紹介されてる
初期プロトタイピングや大規模タスクには、軽量で低コストなモデルが推奨されている。翻訳や分類みたいな高ボリューム・低レイテンシのタスクには、コスト効率を重視したモデルを選ぶのがポイントだ
高ボリュームで高品質が求められるアプリケーションには、バランスの取れた中間レンジのモデルがいい。品質・コスト・速度のトレードオフをコントロールできる設計になってて、本番アプリケーションに向いてるんよ
複雑な多段階推論やフロンティアコード生成には、高性能な推論モデルを選ぶ。マルチモーダル理解と強力なエージェント・コーディング能力を持つモデルが、こういったタスクには適している
実際のシステムでは、単一のモデルに固定するのではなく、タスクに応じて複数のモデルを使い分けるのが理想的だ。堅牢な認知アーキテクチャでは、複数の専門エージェントがそれぞれ最適なモデルを選択する。重い処理は高性能モデル、軽い処理は軽量モデルって感じで、システム全体のコストとパフォーマンスを最適化できる
グラウンディングが信頼性のカギ
AI エージェントを語る上で絶対に外せないのが「グラウンディング」だ。これは、エージェントの応答を事実に基づかせるための仕組みなんよ
LLM だけだと、いわゆる「ハルシネーション」（事実と異なる内容を自信満々に答える現象）が起きることがある。でもグラウンディングを使えば、エージェントは外部のデータソースから最新の情報を取得して、それに基づいた正確な応答ができるようになる
グラウンディングには主に 2 つの方法がある
まず、Google Search との連携。これを使えば、エージェントはリアルタイムでウェブ上の情報を検索して、最新のデータに基づいた回答ができる。例えば「今日の東京の天気は？」みたいな質問にも正確に答えられるようになる
もう一つは、RAG（Retrieval-Augmented Generation）だ。これは企業の内部ドキュメントやナレッジベースをベクトルデータベースに格納して、関連する情報を検索・参照しながら応答を生成する手法。社内の FAQ やマニュアルを参照して回答するカスタマーサポートエージェントなんかに最適だね
RAG の仕組みを深掘りする
RAG はエンタープライズ向けエージェントで特に重要な技術だから、もう少し詳しく見ていこう
RAG の基本的な流れは以下の通り
まず、ドキュメントの準備。社内の PDF、Word ファイル、Web ページ、データベースなど、参照したい情報源を集める。これらをチャンク（小さな断片）に分割して、埋め込みモデルでベクトル化する
次に、ベクトルデータベースへの格納。ベクトル化されたチャンクを Vertex AI Vector Search や AlloyDB のようなベクトルデータベースに格納する。これによって、意味的に類似したコンテンツを高速に検索できるようになるんよ
そして、クエリ時の検索。ユーザーからの質問が来たら、その質問もベクトル化して、データベースから関連度の高いチャンクを検索する。通常は上位 5〜10 件のチャンクを取得する
最後に、コンテキスト付きの生成。取得したチャンクをプロンプトに含めて、LLM に回答を生成させる。「以下の情報を参考にして回答してください」みたいな形でコンテキストを渡す
RAG を使うと、以下のメリットがある
- 最新の情報に基づいた回答ができる（モデルの学習データに依存しない）
- 社内の機密情報を安全に活用できる（外部に送信しない）
- 回答の根拠を示せる（どのドキュメントから情報を取得したか追跡可能）
- ハルシネーションを大幅に減らせる
Google のガイドでは、Vertex AI Search を使った RAG の実装が推奨されてる。Vertex AI Search は、構造化データ・非構造化データの両方に対応してて、エンタープライズグレードのセキュリティと可観測性が組み込まれている
ツール設計のベストプラクティス
エージェントのツールは、外部世界との接点になるめっちゃ重要なコンポーネントだ。ツールの設計が悪いと、エージェント全体のパフォーマンスが下がる
Google のガイドで紹介されてるツール設計のベストプラクティスを見ていこう
まず、ツールの説明は明確かつ具体的に書くこと。モデルはツールの説明（docstring）を読んで、いつどのツールを使うか判断する。曖昧な説明だと、間違ったツールを選んだり、必要なツールを使わなかったりする
良い説明の例を挙げると
次に、パラメータの型と制約を明確にすること。エージェントは型情報を参考にして、正しい形式で引数を渡す。enum を使って選択肢を制限したり、バリデーションを追加したりすると、エラーを減らせる
エラーハンドリングも重要だ。ツールがエラーを返した場合、エージェントがそのエラーを理解して適切に対処できるように、分かりやすいエラーメッセージを返す必要がある
最後に、べき等性（idempotency）を考慮すること。同じツールを同じ引数で複数回呼び出しても、結果が変わらないように設計するのが理想的だ。エージェントは推論のリトライで同じツールを複数回呼ぶことがあるから、副作用の管理が重要になる
Google Cloud のエコシステムが充実しすぎ
Google Cloud は AI エージェント構築のために、めっちゃ充実したエコシステムを用意している。その中心にあるのが Vertex AI Platform
Vertex AI は、モデルのトレーニングからデプロイ、運用まで一貫して管理できる統合プラットフォームだ。Gemini をはじめとする最先端のモデルにアクセスできるし、ファインチューニングやプロンプトエンジニアリングのツールも揃ってる
そして、エージェント開発の中核となるのが ADK（Agent Development Kit）だ。これについては次のセクションで詳しく解説するけど、コードファーストなアプローチでエージェントを構築できるオープンソースのフレームワークなんよ
他にも以下のツールが用意されてる
- Gemini Code Assist：コーディング作業を効率化する AI アシスタント
- Colab Enterprise：データ分析や機械学習実験のための環境
- Vertex AI Search：エンタープライズ検索とベクトル検索の機能
- Google Agentspace：複数のエージェントを管理・スケーリングするプラットフォーム
これらのツールを組み合わせることで、アイデアからプロトタイプ、そして本番スケールまでスムーズに進められる
ADK（Agent Development Kit）でコードファースト開発
ADK は Google が Cloud NEXT で発表したオープンソースのフレームワークで、エージェント実装を体系化するための中核ツールとして位置づけられている
ADK の特徴は「コードファースト」なアプローチだ。GUI でポチポチ設定するのではなく、Python や TypeScript でエージェントのロジックを直接書いていく。これによって、エンジニアは細かいコントロールができるし、バージョン管理やテストもしやすくなる
ADK の主な特徴を挙げると
まず、モデル非依存だってこと。Gemini に最適化されてるけど、他の LLM も使える設計になってる。将来的にモデルを切り替えたくなっても、大きな変更なしに対応できる
次に、マルチエージェントシステムの設計が簡単ってこと。複数の専門エージェントを階層的に配置して、複雑なタスクを協調して処理させることができる。例えば、「リサーチエージェント」「執筆エージェント」「レビューエージェント」を組み合わせて、コンテンツ制作パイプラインを自動化するみたいなことができるんよ
さらに、開発者ツールが統合されてる。CLI と Developer UI が付属してて、エージェントの実行、ステップごとの検査、デバッグ、定義の可視化まで一通りできる。開発効率がめっちゃ上がるだろうね
言語サポートも充実してきてて、Python、TypeScript v0.2.0、Go v0.3.0 が利用可能だ。チームの技術スタックに合わせて選べるのはありがたいよね
ADK で実際にエージェントを作ってみる
ADK でエージェントを作る基本的なコードを見てみよう。Python での実装例だ
このコードのポイントは 3 つある
まず、@Tool デコレータでツールを定義してる。関数に docstring を付けると、それがツールの説明としてモデルに渡される。モデルはこの説明を読んで、どのツールをいつ使うか判断する
次に、Agent クラスでエージェントを定義してる。モデル、ツール、システムプロンプトを指定するだけで、基本的なエージェントが完成する。めっちゃシンプルだろ
最後に、agent.run() でエージェントを実行してる。内部では ReAct ループが回って、必要に応じてツールが呼び出されるんよ
マルチエージェントシステムの構築例
複数のエージェントを組み合わせた例も見てみよう
SequentialAgent は、エージェントを順番に実行するワークフローだ。research_agent の出力が analysis_agent の入力になり、その出力が writer_agent の入力になる
並列処理が必要な場合は ParallelAgent を使う。複数の独立したタスクを同時に実行して、結果を統合できる
LoopAgent を使えば、条件が満たされるまで処理を繰り返すこともできる。品質チェック → 修正 → 再チェックみたいなイテレーションに便利だね
Agent Starter Pack で爆速スタート
ADK でエージェントを作る方法は分かったけど、本番環境に持っていくには他にもいろいろ必要だ。CI/CD、テスト環境、モニタリング、ログ収集...これらを一から構築するのはめっちゃ大変
そこで Google が用意してくれたのが Agent Starter Pack だ。GitHub で公開されてて、本番グレードのエージェントを数分で立ち上げられるテンプレート集なんよ
Agent Starter Pack に含まれてるものは以下の通り
- 本番対応のエージェントテンプレート
- pytest ベースのテスト環境（tests/unit/ と tests/integration/）
- GitHub Actions または Cloud Build での CI/CD パイプライン
- OpenTelemetry による可観測性スタック
- BigQuery へのログ転送設定
- Looker Studio ダッシュボードテンプレート
- Vertex AI Agent Engine へのデプロイスクリプト
使い方はめっちゃ簡単で、リポジトリをクローンして、いくつかの設定を変更するだけ。make test でテストを実行して、make deploy でデプロイできる
特に嬉しいのは、AgentOps の 4 層評価フレームワークがすでに組み込まれてること。tests/unit/ でコンポーネントテスト、tests/integration/ で軌跡評価、本番環境でシステムレベルモニタリングが動く。評価の仕組みを一から作る必要がない
Google のガイドでも「プロトタイプから本番へ移行する際は Agent Starter Pack を使え」と強く推奨されてる
ADK でエージェントを定義する基本ステップ
実際に ADK でエージェントを構築する流れを見ていこう
まず、エージェントの役割と目標を明確にする。「このエージェントは何をするのか？」「どんな問題を解決するのか？」をはっきりさせることがスタート地点だ
次に、必要なツールを設計する。エージェントが外部と対話するための「手足」を定義する。例えば、データベースへのクエリ、API の呼び出し、ファイルの読み書きなど、タスクに必要な操作をツールとして実装するんよ
そして、オーケストレーションのロジックを組む。単一のエージェントで完結するのか、複数のエージェントが協調するのか、どんな順序でタスクを実行するのかを決める。ADK には SequentialAgent、ParallelAgent、LoopAgent といったワークフローエージェントも用意されてて、構造化されたプロセスを簡単に実装できる
最後に、メモリとコンテキスト管理を設定する。会話履歴をどこまで保持するか、長期記憶をどう扱うかを決める。Google のガイドでは「Memory Distillation（記憶の蒸留）」という高度なテクニックも紹介されてて、重要な情報を効率的に保持する方法が解説されている
AgentOps で本番環境の信頼性を確保
ここまでは「エージェントをどう作るか」の話だったけど、本当に重要なのは「どう運用するか」だ。Google はこれを「AgentOps」と呼んでる
AgentOps は、DevOps、MLOps、DataOps の原則を AI エージェントの構築・デプロイ・管理に適用した運用方法論だ。非決定的な LLM ベースのシステムを本番環境で安全に運用するための、体系的で自動化された再現可能なフレームワークを提供してくれる
Google のガイドによると、多くのエージェントが本番で失敗する原因は、モデルの性能ではない。「退屈な」運用作業をサボるからだ。AgentOps はその「退屈だけど重要な作業」をフレームワーク化してくれる
堅牢な AgentOps 戦略は開発プロセスを体系化して、ツール、推論能力、基盤モデル全体の信頼性、安全性、パフォーマンスを向上させる継続的なフィードバックループを提供するんよ
AgentOps の 4 層評価フレームワーク
非決定的なエージェントシステムの評価は、現代ソフトウェアエンジニアリングで最も複雑な課題の一つだ。従来のテストは語彙的な正確さ（コードが動くかどうか）に焦点を当てるけど、エージェント評価は 2 つのより難しい問題に対処する必要がある
一つは意味的正確性。エージェントがユーザーの意図を理解して、役立つ回答を提供できてるか？ってこと
もう一つは推論的正確性。エージェントが論理的で効率的なパスを辿って結論に至ったか？ってこと
これらを評価するために、Google は 4 層の評価フレームワークを提案している
Layer 1：コンポーネントレベル評価（決定的ユニットテスト）
この層は、予測可能な非 LLM コンポーネントに焦点を当てる。目的は個々のビルディングブロックの語彙的正確性を検証して、エージェントの失敗が単純なバグに起因しないことを確認することだ
テスト対象は以下の 3 つ
- ツール：有効な入力、無効な入力、エッジケース入力での期待動作
- データ処理：パースとシリアライズ関数の堅牢性
- API 統合：成功、エラー、タイムアウト条件の処理
実装面では、ADK がエージェントのツールを Python 関数（または Java メソッド）として定義するから、これらの関数がコンポーネントレベルテストの直接の対象になる。Agent Starter Pack は標準的な pytest 環境を含むテストインフラを提供してて、tests/unit/ ディレクトリにユニットテストを書いて make test コマンドで実行できる
Layer 2：軌跡評価（手続き的正確性）
これはエージェントの推論プロセスを評価する最も重要な層だ。「軌跡」とは、タスクを完了するためにエージェントが取る Reason、Act、Observe ステップの完全なシーケンスのことだね
目的は ReAct サイクル内の推論正確性を検証すること
テスト対象は以下の 3 つ
- Reason ステップ：エージェントがゴールと現状を正しく評価して、次のステップの論理的仮説を形成できてるか？
- Act ステップ：正しいツールを選択して、そのツールの引数を正しく抽出・フォーマットできてるか？（Tool Selection と Parameter Generation）
- Observe ステップ：ツールの出力を正しく統合して、次の Reason ステップに反映できてるか？
実装面では、ADK のコアランタイムがエージェントの ReAct ループを実行して、Google Cloud Trace と直接統合する。これによって開発者は軌跡全体を可視化して、ツールの入出力を検査して、モデルの思考連鎖をデバッグできる
Agent Starter Pack は軌跡評価を自動化・スケール化してくれる。tests/integration/ ディレクトリに「ゴールデンセット」（期待される ReAct 軌跡を持つプロンプト集）を作成して、自動化された CI/CD パイプラインがすべてのプルリクエストでこれらのテストを実行する。リグレッションを防ぐために、めっちゃ重要な仕組みだね
Layer 3：アウトカム評価（意味的正確性）
この層は、ReAct ループが終了した後の最終的なユーザー向け応答を評価する
目的は最終回答の意味的正確性、事実的正確性、全体的な品質を検証すること
テスト対象は以下の 3 つ
- 事実精度とグラウンディング：回答が Observe ステップで収集した情報に基づいて正確で検証可能か？
- 有用性とトーン：応答がユーザーのニーズに適切なスタイルで完全に対応してるか？
- 完全性：応答に必要な情報がすべて含まれてるか？
実装面では、ADK のツールセットが事実精度検証のカギになる。開発者は専用のツールを作成するか、API を使ってグラウンディング検証ができる。Act ステップ中に呼び出されるこれらのツールは、エージェントの最終回答が取得したコンテキストに裏付けられてるかをプログラム的にチェックして、ハルシネーションに対する定量的な指標を提供する
Agent Starter Pack は Vertex AI の Gen AI 評価サービスと統合してて、LLM-as-judge スコアリングを提供する。組み込みの UI プレイグラウンドには、人間の評価を BigQuery に直接記録するフィードバック機構も含まれてて、高精度な HITL（Human-in-the-Loop）評価ができるようになってるんよ
Layer 4：システムレベルモニタリング（本番環境）
評価はデプロイで終わりではない。エージェントのライブパフォーマンスを継続的に監視することが超重要だ
目的は実環境でのパフォーマンスを追跡して、運用障害や行動のドリフトを検出すること
モニタリング対象は以下の 3 つ
- ツール失敗率、ユーザーフィードバックスコア
- 軌跡メトリクス（例：タスクあたりの ReAct サイクル数）
- エンドツーエンドのレイテンシ
実装面では、本番環境で動作する ADK エージェントが運用データの源になる。すべてのユーザーインタラクションでイベントとトレースを発行する
Agent Starter Pack は本番グレードの可観測性スタックをすぐに使える形で提供してる。OpenTelemetry を自動設定して、BigQuery への Log Router を構成して、Looker Studio ダッシュボードのテンプレートも用意されてる。チームは追加設定なしで、すぐにエージェントのパフォーマンスを追跡して、トレンドを分析して、実データに基づいて問題をデバッグできるんよね
この包括的で実践的なエージェント評価の方法論は、堅牢な AgentOps 戦略の具体的な実装だ。非公式な「バイブテスト」から、体系的で自動化された再現可能なプロセスへとチームを移行させる。評価をコンポーネント、軌跡、アウトカム、システムレベルのモニタリングに分解することで、AgentOps のコアドメインに直接対応できる
セキュリティとガバナンスを忘れずに
AI エージェントは強力だけど、それだけにセキュリティとガバナンスが超重要だ。特にエンタープライズ環境では、ここを軽視すると大問題になる可能性がある
Google のガイドでは、以下のポイントが強調されてる
まず、アクセス制御。エージェントがアクセスできるデータやシステムを最小限に制限する。「最小権限の原則」をエージェントにも適用するってことだね。例えば、カスタマーサポートエージェントには顧客情報の読み取り権限だけを与えて、削除や変更はできないようにする
次に、監査ログ。エージェントのすべての行動を記録して、後から検証できるようにする。「いつ、誰の指示で、何をしたか」を追跡できることが、コンプライアンス上も重要なんよ
そして、入力検証。ユーザーからの入力や外部データを信頼しないこと。プロンプトインジェクション攻撃みたいな悪意あるリクエストを検知・ブロックする仕組みが必要だ
最後に、出力フィルタリング。エージェントの応答に機密情報や不適切な内容が含まれてないかチェックする。意図せず社内情報を漏らしたり、差別的な発言をしたりするリスクを軽減する
これらのセキュリティ対策は、開発の最初から組み込んでおくのがベストだ。後から追加しようとすると、アーキテクチャの変更が必要になって大変なことになるからね
マルチエージェント設計の考え方
複雑なタスクを処理するには、単一のエージェントではなく、複数のエージェントが協調するマルチエージェントシステムが効果的だ
マルチエージェントの基本的なパターンはいくつかある
階層型アーキテクチャでは、「オーケストレーター」エージェントが全体を統括して、専門エージェントにタスクを委任する。例えば、ユーザーからの複雑なリクエストをオーケストレーターが受け取り、「検索エージェント」「分析エージェント」「要約エージェント」にそれぞれサブタスクを割り当てるみたいな感じだ
並列型アーキテクチャでは、独立したエージェントが同時に動いて、それぞれの結果を最後に統合する。処理時間を短縮できるけど、結果の一貫性を保つのが課題になる
パイプライン型アーキテクチャでは、エージェントが順番に処理をして、前のエージェントの出力が次のエージェントの入力になる。品質管理がしやすいけど、どこかで詰まると全体が止まるリスクがある
どのパターンを選ぶかは、タスクの性質とトレードオフの判断によるんよ。Google のガイドでは、コストと性能のバランスを最適化するための考え方も詳しく解説されてる
デプロイの選択肢
ADK で作ったエージェントをどこにデプロイするか、いくつかの選択肢がある
Google が推奨してるのは Vertex AI Agent Engine Runtime だ。これは AI エージェント専用に設計されたフルマネージドサービスで、スケーリングやバージョン管理、モニタリングを自動でやってくれる。運用の手間を最小限にしたいなら、これが一番楽だね
もう少し自由度が欲しいなら、Cloud Run や GKE にコンテナとしてデプロイする方法もある。既存のインフラに組み込みたい場合や、カスタムの設定が必要な場合はこっちが向いてるかもしれない
オンプレミス環境や他のクラウドプロバイダーでも動かせるのが ADK の強みだ。コンテナ化さえすれば、基本的にどこでも動くからね
どの方法を選ぶにしても、AgentOps の原則を守って、テスト → ステージング → 本番という段階的なデプロイを心がけることが大事
Google Agentspace でエージェントを組織全体に展開
複数のエージェントを組織全体で管理・運用するなら、Google Agentspace を検討する価値がある
Agentspace は、エージェントのワークフォースを一元管理するためのプラットフォーム。複数のエージェントを登録して、ユーザーがそれらにアクセスできるようにするハブの役割を果たすんよね
Agentspace の主な機能は以下の通り
エージェントカタログ機能では、組織内で利用可能なエージェントを一覧表示できる。ユーザーは必要なエージェントを簡単に見つけて、すぐに使い始められる
アクセス制御機能では、誰がどのエージェントを使えるかを細かく設定できる。部署ごと、役職ごと、プロジェクトごとにアクセス権を管理できるから、セキュリティとコンプライアンスを維持しながらエージェントを展開できる
統合検索機能では、複数のエージェントを横断して検索できる。ユーザーは「どのエージェントに聞けばいいか」を考えずに、Agentspace に質問するだけで適切なエージェントにルーティングされるんよ
分析ダッシュボード機能では、エージェントの利用状況、パフォーマンス、コストを可視化できる。どのエージェントがよく使われてるか、どこにボトルネックがあるかを把握して、改善につなげられる
Agentspace は特にエンタープライズ環境で威力を発揮する。10 個、100 個とエージェントが増えていくと、管理が複雑になるけど、Agentspace があれば一元的にコントロールできる
コスト最適化の実践的なヒント
AI エージェントの運用コストは、主に LLM の API 呼び出しに依存する。適切に最適化しないと、思わぬ高額請求が来ることもある
Google のガイドで紹介されてるコスト最適化のヒントを見ていこう
まず、モデルの使い分けを徹底すること。これは先ほども触れたけど、めっちゃ重要だ。すべてのタスクに Gemini 3 Pro を使う必要はない。ルーティングやシンプルな判断には Flash-Lite、通常のタスクには Flash、複雑な推論だけ Pro という使い分けで、コストを大幅に削減できる
次に、キャッシュを活用すること。同じような質問に対して毎回 LLM を呼び出す必要はない。よくある質問の回答をキャッシュしたり、検索結果をキャッシュしたりすることで、API 呼び出し回数を減らせるんよ
プロンプトの最適化も効果的だ。長すぎるプロンプトは、入力トークン数を増やしてコストを上げる。必要な情報だけを含めた簡潔なプロンプトを心がけると、レスポンスも速くなって一石二鳥だね
バッチ処理も検討する価値がある。リアルタイム性が必要ないタスクは、まとめて処理することでコストを抑えられることがある。Gemini API にはバッチ処理用のエンドポイントがあって、通常より安い料金で利用できる
最後に、使用量のモニタリングを徹底すること。Agent Starter Pack には BigQuery へのログ転送が組み込まれてるから、どのエージェントがどれだけコストを使ってるかを追跡できる。異常なコスト上昇を早期に検知して、対策を打てるようにしておくのが大事だね
よくある失敗パターンと対策
Google のガイドやコミュニティのフィードバックを基に、エージェント開発でよくある失敗パターンをまとめてみた
失敗パターン 1 は「いきなり複雑なシステムを作ろうとする」こと。最初からマルチエージェント、RAG、複数ツールを組み合わせた巨大システムを作ろうとして、何が問題なのか分からなくなるパターンだ。対策は、まず単一エージェント・単一ツールで動作確認して、徐々に複雑にしていくこと
失敗パターン 2 は「評価を後回しにする」こと。とりあえず動くものを作って、評価は後でやろうとするパターン。でも後から評価の仕組みを入れるのはめっちゃ大変で、結局やらないまま本番に出して問題が起きる。対策は、Agent Starter Pack を使って最初から評価の仕組みを組み込むこと
失敗パターン 3 は「プロンプトに頼りすぎる」こと。システムプロンプトを長々と書いて、エージェントの動作を制御しようとするパターン。でもプロンプトだけでは限界があるし、メンテナンスも大変。対策は、ツールの設計とオーケストレーションのロジックで動作を制御すること
失敗パターン 4 は「エラーハンドリングを軽視する」こと。正常系だけ作って、エラー時の動作を考えてないパターン。本番では様々なエッジケースが発生するから、エージェントがハングしたり、無限ループしたりする。対策は、タイムアウト、リトライ上限、フォールバック応答を設定すること
失敗パターン 5 は「セキュリティを後付けにする」こと。機能を作り込んでから、最後にセキュリティ対策を追加しようとするパターン。でもアーキテクチャに深く関わる部分は、後から変更するのが難しい。対策は、設計段階からセキュリティを考慮すること
これらの失敗パターンを知っておくだけで、だいぶ時間と労力を節約できるはずだ
実践的に始めるためのステップ
ここまで読んで「で、実際に何から始めればいいの？」って思ってる人もいるだろう。Google のガイドに基づいて、実践的なステップを整理してみた
ステップ 1 はユースケースの特定だ。エージェントで解決したい具体的な課題を明確にする。「カスタマーサポートの自動化」「社内ナレッジの検索」「データ分析の補助」など、まずは 1 つに絞るのがコツだね
ステップ 2 は小さく始めること。いきなり複雑なマルチエージェントシステムを作ろうとしない方がいい。単一エージェント、単一ツールから始めて、徐々に機能を追加していく。Google の Agent Starter Pack を使えば、テンプレートから素早くプロトタイプを作れる
ステップ 3 は評価の設計だ。エージェントの成功をどう測るか、最初から決めておく。「応答の正確性」「処理時間」「ユーザー満足度」など、定量的な指標を設定しておくと、改善のサイクルを回しやすいんよ
ステップ 4 は段階的なスケーリングだ。プロトタイプで動作確認ができたら、徐々にユーザーを増やしていく。いきなり全社展開するのではなく、特定のチームやユースケースから始めて、フィードバックを集めながら改善していくのが安全なアプローチだね
ステップ 5 は継続的な改善だ。本番デプロイしたら終わりではない。AgentOps のモニタリングで得られたインサイトを基に、プロンプトの調整、ツールの改善、モデルの更新を継続的に行っていく
2025 年のエージェント開発トレンド
Google のガイドやその他のソースを総合すると、2025 年の AI エージェント開発には 3 つの大きなトレンドがある
1 つ目は「エージェントが仕事を持った」ってこと。実験的なパイロットから、実際のビジネスプロセスへの広範な導入が進んでる。AI エージェントはもはや「面白いデモ」ではなく、「実際に価値を生む労働力」として認識されるようになってきた
2 つ目は「評価がアーキテクチャになった」ってこと。エージェントの評価を後付けでやるのではなく、設計段階から組み込むのが当たり前になってきてる。AgentOps の 4 層フレームワークみたいに、評価可能性を前提としたアーキテクチャが求められるようになったんよね
3 つ目は「信頼がボトルネックになった」ってこと。技術的には動くエージェントを作れても、それを本番環境で使うかどうかはガバナンスの問題になってる。セキュリティ、コンプライアンス、説明責任をクリアできないと、どんなに優秀なエージェントも採用されない
終わりに
このガイドの何がすごいかっていうと、単なる概念説明ではなく、Gemini を活用したスタートアップ向けの実践的な内容になってるってこと
Google Cloud の「Startup Technical Guide: AI Agents」は、AI エージェント開発の決定版ガイドといっていいレベルの内容だった
このガイドの価値は、単なる技術解説ではなく、アイデアからプロトタイプ、そして本番スケールまでの実践的なロードマップを提供してるところにある
特に重要なポイントをまとめると
- AI エージェントは単なるチャットボットではなく、ツールを使って自律的にタスクを遂行するシステムだ
- グラウンディング（Google Search や RAG）で応答の信頼性を高めることが重要
- ADK を使えばコードファーストなアプローチでエージェントを構築できる
- AgentOps の 4 層評価フレームワークで本番環境の信頼性を確保する
- セキュリティとガバナンスは開発の最初から組み込む
少なくとも Google のガイドを見る限り、2025 年はまさに「エージェントの年」になってて、早めに始めた企業が大きなアドバンテージを得てるんよ。Google Cloud のエコシステムは、その第一歩を踏み出すのに最適な環境を提供してくれてる
興味があったら、まずは公式ガイドをダウンロードして読んでみることをオススメする
