エージェント AI アーキテクチャ コンポーネントを選択する

このドキュメントでは、 Google Cloudでエージェント AI アプリケーションのアーキテクチャ コンポーネントを選択する際に役立つガイダンスを提供します。ニーズに最適な適切なプロダクトまたはサービスを選択するために、アプリケーションとワークロードの特性を評価する方法について説明します。エージェント AI アーキテクチャを設計するプロセスは反復的です。ワークロードの特性の変化、要件の進化、新しい Google Cloud プロダクトと機能の利用可能化に応じて、アーキテクチャを定期的に再評価する必要があります。

AI エージェントは、自律的な意思決定や複雑なマルチステップ ワークフロー管理を必要とする可能性のある、オープンエンドの問題を解決するアプリケーションに効果的です。エージェントは、外部データを使用して問題をリアルタイムで解決し、知識集約型のタスクを自動化することに優れています。これらの機能により、エージェントは AI モデルの支援機能や生成機能よりもビジネス価値を高めることができます。

AI エージェントは、事前に定義された手順で決定論的な問題に使用できます。ただし、他のアプローチの方が効率的で費用対効果が高い場合があります。たとえば、ドキュメントの要約、テキストの翻訳、顧客フィードバックの分類などのタスクには、エージェント ワークフローは必要ありません。

エージェントレス AI ソリューションについては、次のリソースをご覧ください。

エージェント アーキテクチャの概要

エージェントは、入力を処理し、利用可能なツールで推論を行い、決定に基づいてアクションを実行することで目標を達成するアプリケーションです。エージェントは、AI モデルをコア推論エンジンとして使用して、複雑なタスクを自動化します。エージェントは、AI モデルが外部システムやデータソースとやり取りできるようにする一連のツールを使用します。エージェントは、メモリ システムを使用してコンテキストを維持し、インタラクションから学習できます。エージェント アーキテクチャの目標は、ユーザーの意図を理解し、複数のステップからなる計画を作成し、利用可能なツールを使用してその計画を実行できる自律型システムを作成することです。

次の図は、エージェント システムのアーキテクチャ コンポーネントの概要を示しています。

エージェント システムのアーキテクチャ コンポーネント。

エージェント システム アーキテクチャには、次のコンポーネントが含まれています。

  • フロントエンド フレームワーク: アプリケーションのユーザー インターフェース（UI）を構築するために使用する、事前構築済みのコンポーネント、ライブラリ、ツールのコレクション。
  • エージェント開発フレームワーク: エージェントのロジックを構築して構造化するために使用するフレームワークとライブラリ。
  • エージェント ツール: データを取得し、アクションまたはトランザクションを実行する API、サービス、関数などのツールのコレクション。
  • エージェントのメモリ: エージェントが情報の保存と呼び出しに使用するシステム。
  • エージェント設計パターン: エージェント アプリケーションを構築するための一般的なアーキテクチャ アプローチ。
  • エージェント ランタイム: エージェントのアプリケーション ロジックが実行されるコンピューティング環境。
  • AI モデル: エージェントの意思決定機能を強化するコア推論エンジン。
  • モデル ランタイム: AI モデルをホストして提供するインフラストラクチャ。

以降のセクションでは、アーキテクチャの構築方法を決定するうえで役立つように、コンポーネントの詳細な分析について説明します。選択するコンポーネントは、エージェントのパフォーマンス、スケーラビリティ、費用、セキュリティに影響します。このドキュメントでは、エージェントのコア推論ロジックと実行ロジックのビルドとデプロイに使用する重要なアーキテクチャ コンポーネントに焦点を当てています。責任ある AI の安全フレームワークやエージェント ID 管理などのトピックは、このドキュメントの対象外とします。

フロントエンド フレームワーク

フロントエンド フレームワークは、エージェント アプリケーションの UI を構築するために使用する事前構築済みのコンポーネント、ライブラリ、ツールのコレクションです。選択したフロントエンド フレームワークによって、バックエンドの要件が定義されます。内部デモ用のシンプルなインターフェースでは同期 HTTP API のみが求められる場合がありますが、本番環境グレードのアプリケーションでは、ストリーミング プロトコルと堅牢な状態管理をサポートするバックエンドが必要です。

次のカテゴリのフレームワークを検討してください。

  • プロトタイピングと内部ツール フレームワーク: 迅速な開発、内部デモ、コンセプト実証アプリケーションには、デベロッパー エクスペリエンスと速度を優先するフレームワークを選択します。これらのフレームワークは通常、リクエスト / レスポンス モデルと呼ばれるシンプルで同期型のモデルを優先します。リクエスト / レスポンス モデルを使用すると、本番環境のフレームワークと比較して、最小限のコードとシンプルなバックエンドで機能的な UI を構築できます。このアプローチは、エージェント ロジックとツール統合を迅速にテストするのに最適ですが、リアルタイムのインタラクションを必要とするスケーラビリティの高い一般公開アプリケーションには適していない可能性があります。このカテゴリの一般的なフレームワークには、Mesop や Gradio などがあります。
  • 本番環境フレームワーク: 外部ユーザー向けの拡張性、応答性、機能豊富なアプリケーションの場合は、カスタム コンポーネントを可能にするフレームワークを選択します。これらのフレームワークでは、最新のユーザー エクスペリエンスをサポートできるバックエンド アーキテクチャが必要です。本番環境のフレームワークには、ストリーミング プロトコルのサポート、ステートレス API 設計、複数のユーザー セッションにわたって会話の状態を管理するための堅牢な外部化されたメモリ システムが含まれている必要があります。本番環境アプリケーションの一般的なフレームワークには、Streamlit、React、Flutter AI ツールキットなどがあります。

これらのフレームワークと AI エージェント間の通信を管理するには、エージェントとユーザーのインタラクション（AG-UI）プロトコルを使用します。AG-UI は、バックエンド AI エージェントがフロントエンド フレームワークとやり取りできるようにするオープン プロトコルです。AG-UI は、エージェントのレスポンスのレンダリング、アプリケーションの状態の更新、クライアントサイドのアクションのトリガーを行うタイミングをフロントエンド フレームワークに伝えます。インタラクティブな AI アプリケーションを構築するには、AG-UI と Agent Development Kit（ADK）を組み合わせます。ADK については、次のセクション「エージェント開発フレームワーク」をご覧ください。

エージェント開発フレームワーク

エージェント開発フレームワークは、エージェント AI アプリケーションの構築、テスト、デプロイのプロセスを簡素化するライブラリです。これらの開発ツールは、推論ループ、メモリ、ツール統合など、エージェントのコア機能の事前構築済みコンポーネントと抽象化を提供します。

Google Cloudでのエージェント開発を加速するには、ADK を使用することをおすすめします。ADK は、シンプルなタスクから複雑なマルチエージェント システムまで、ワークフローの構築とオーケストレーションのための高レベルの抽象化を提供する、オープンソースのモジュール型フレームワークです。

ADK は Gemini モデルと Google Cloud向けに最適化されていますが、他のフレームワークとの互換性を考慮して構築されています。ADK は他の AI モデルとランタイムをサポートしているため、任意のモデルまたはデプロイ方法で使用できます。マルチエージェント システムの場合、ADK は、共有セッション状態によるインタラクション、エージェント間でタスクをルーティングするモデル駆動型委任、1 つのエージェントが別のエージェントを関数またはツールとして呼び出す明示的な呼び出しをサポートしています。

ADK には、さまざまな業界のユースケースを示す Python、Java、Go のサンプルコードが用意されており、すぐに使い始めることができます。これらのサンプルの多くは会話フローをハイライトしていますが、ADK はバックエンド タスクを実行する自律型エージェントの構築にも適しています。このような非インタラクティブなユースケースでは、単一の自己完結型リクエストの処理に優れ、堅牢なエラー処理を実装するエージェント設計パターンを選択します。

Genkit などの汎用 AI フレームワークを使用することもできますが、ADK を使用することをおすすめします。Genkit は、独自のエージェント アーキテクチャの開発に使用できるプリミティブを提供します。ただし、ADK などの専用のエージェント フレームワークでは、より専門的なツールが提供されます。

エージェント ツール

エージェントがツールを通じて外部システムとやり取りできる能力は、エージェントの有効性を定義します。エージェント ツールは、AI モデルで使用できる関数または API であり、エージェントはこれを使用して出力を強化し、タスクの自動化を可能にします。AI エージェントを外部システムに接続すると、ツールによってエージェントが単純なテキスト生成ツールから、複雑なマルチステップのタスクを自動化できるシステムに変換されます。

ツール操作を有効にするには、次のツール使用パターンから選択します。

ユースケース ツールの使用パターン
ウェブ検索の完了、計算の実行、コードの実行などの一般的なタスクを実行する必要があり、初期開発を加速したい。 組み込みツール
相互運用可能で再利用可能なツールを必要とするモジュラー システムまたはマルチエージェント システムを構築する。 Model Context Protocol（MCP）
エンタープライズ規模で多数の API ベースのツールを管理、保護、モニタリングする必要がある。 API 管理プラットフォーム
MCP サーバーのない特定の内部 API またはサードパーティ API と統合する必要がある。 カスタム関数ツール

エージェントのツールを選択する際は、機能と運用の信頼性を評価します。オブザーバビリティが高く、デバッグが容易で、堅牢なエラー処理を含むツールを優先します。これらの機能により、アクションを追跡し、障害を迅速に解決できます。また、割り当てられたタスクを正常に完了するために適切なツールを選択するエージェントの能力を評価します。

組み込みツール

ADK には、エージェントのランタイムに直接統合されたいくつかの組み込みツールが用意されています。これらのツールは、外部通信プロトコルを構成せずに関数として呼び出すことができます。これらのツールは、ウェブからリアルタイム情報にアクセスする、安全な環境でコードをプログラムで実行する、プライベート エンタープライズ データから情報を取得して RAG を実装する、クラウド データベース内の構造化データとやり取りするなど、一般的な機能を提供します。組み込みツールは、作成したカスタムツールと連携して動作します。

MCP

エージェント システムのコンポーネントが相互に作用できるようにするには、明確な通信プロトコルを確立する必要があります。 MCP は、エージェントが必要なツール、データ、その他のサービスにアクセスして使用するための標準化されたインターフェースを提供するオープン プロトコルです。

MCP は、標準のハードウェア ポートでさまざまな周辺機器をデバイスに接続できるのと同様に、エージェントのコア推論ロジックをツールの特定の実装から切り離します。MCP は、事前構築済みのコネクタのリストとカスタム統合を構築する一貫した方法を提供するため、ツール統合を簡素化します。ツールを統合できる柔軟性により、さまざまなモデルやツール間の相互運用性が向上します。

リモート MCP サーバーが利用可能な場合は、それに接続できます。また、独自の MCP サーバーをホストすることもできます。独自の MCP サーバーをホストする場合、エージェントに独自の API またはサードパーティ API を公開する方法を完全に制御できます。独自のカスタム MCP サーバーをホストするには、Cloud Run または GKE にコンテナ化されたアプリケーションとしてデプロイします。

API 管理プラットフォーム

API 管理プラットフォームは、API を介して内部サービスまたは外部サービスを保護、モニタリング、制御できる一元化されたシステムです。API 管理プラットフォームは、組織のすべての API をカタログ化する一元化された場所を提供し、データの公開方法を簡素化し、使用状況のモニタリングを通じてオブザーバビリティを提供します。

Google Cloudでエージェントの API ベースのツールをエンタープライズ規模で管理するには、Apigee API Hub を使用することをおすすめします。API Hub を使用すると、エージェントは直接 HTTP 呼び出し、事前構築済みのコネクタ、ハブに登録されたカスタム API、または Google Cloud データソースへの直接アクセスを通じて、データに即座に接続できます。このアプローチにより、エージェントはカスタム データ読み込みパイプラインや統合パイプラインを構築する複雑さを伴うことなく、必要な情報にすぐにアクセスできます。

API 管理プラットフォームと MCP などの通信プロトコルは、異なるアーキテクチャ上の問題を解決します。通信プロトコルは、エージェントとツール間のインタラクション形式を標準化します。これにより、コンポーネントの再利用と交換が可能になります。一方、API 管理プラットフォームは API エンドポイントのライフサイクルとセキュリティを管理し、認証、レート制限、モニタリングなどのタスクを処理します。これらのパターンは補完的です。たとえば、エージェントは MCP を使用してツールと通信できます。このツールは、API Hub が管理および保護する安全な API エンドポイントにすることができます。

カスタム関数ツール

関数ツールを使用すると、エージェントは新しい機能を利用できます。カスタム関数ツールを作成して、外部 API や独自のビジネス システムとの統合など、エージェントに特殊な機能を提供できます。カスタム関数ツールを作成することは、組み込みツールで提供できる機能を超えてエージェントの機能を拡張する最も一般的なパターンです。

カスタム関数ツールを作成するには、任意のプログラミング言語で関数を作成し、その目的、パラメータ、戻り値について明確な自然言語の説明を提供します。エージェントのモデルは、この説明を使用して、ツールが必要なタイミング、提供する入力、出力を解釈してユーザーのリクエストを完了する方法を推論します。

エージェントをツールとして使用する関数を実装するカスタム関数ツールを作成することもできます。エージェントをツールとして使用する関数は、別のエージェントが呼び出すことができる呼び出し可能な関数として 1 つのエージェントを公開します。この手法を使用すると、エージェントが専門タスクを他の専門エージェントに調整して委任できる、複雑なマルチエージェント システムを構築できます。エージェント設計パターンとマルチエージェント オーケストレーションの調整の詳細については、このドキュメントの後半のエージェント設計パターンに関するセクションをご覧ください。

エージェントのメモリ

エージェントが過去のやり取りを記憶できることは、一貫性のある有用な会話エクスペリエンスを提供するために不可欠です。ステートフルでコンテキスト認識型のエージェントを作成するには、短期メモリと長期メモリのメカニズムを実装する必要があります。以降のセクションでは、エージェントの短期記憶と長期記憶の両方を実装するために使用できる設計上の選択肢と Google Cloudサービスについて説明します。

短期記憶

短期記憶により、エージェントは 1 回の継続的な会話内でコンテキストを維持できます。短期記憶を実装するには、セッションとその関連付けられた状態の両方を管理する必要があります。

  • セッション: セッションは、ユーザーとエージェント間の会話スレッドです。最初のやり取りから会話の終了までを指します。
  • 状態: 状態は、エージェントが特定のセッション内で使用および収集するデータです。収集される状態データには、ユーザーとエージェントがやり取りしたメッセージの履歴、ツール呼び出しの結果、会話のコンテキストを理解するためにエージェントが必要とするその他の変数が含まれます。

ADK で短期記憶を実装するには、次のオプションがあります。

  • インメモリ ストレージ: 開発、テスト、または単一インスタンスで実行されるシンプルなアプリケーションの場合は、セッション状態をアプリケーションのメモリに直接保存できます。エージェントは、辞書やオブジェクトなどのデータ構造を使用して、Key-Value ペアのリストを保存し、セッション全体でこれらの値を更新します。ただし、インメモリ ストレージを使用する場合、セッション状態は永続的ではありません。アプリケーションを再起動すると、すべての会話履歴が失われます。
  • 外部状態管理: スケーラビリティと信頼性を必要とする本番環境アプリケーションの場合は、ステートレス エージェント アプリケーションを構築し、外部ストレージ サービスでセッション状態を管理することをおすすめします。このアーキテクチャでは、エージェント アプリケーションがリクエストを受信するたびに、外部ストアから現在の会話の状態を取得し、新しいターンを処理してから、更新された状態をストアに保存します。この設計により、どのインスタンスでもユーザーのリクエストを処理できるため、アプリケーションを水平方向にスケーリングできます。外部状態管理の一般的な選択肢には、Memorystore for Redis、Firestore、Vertex AI Agent Engine セッションなどがあります。

長期記憶

長期記憶は、個々のユーザーのすべての会話にわたって存在する永続的なナレッジベースをエージェントに提供します。長期記憶により、エージェントは外部情報を取得して使用し、過去のやり取りから学習して、より正確で関連性の高い回答を提供できます。

ADK で長期記憶を実装するオプションは次のとおりです。

  • インメモリストレージ: 開発とテストでは、セッション状態をアプリケーションのメモリに直接保存できます。この方法は実装が簡単ですが、永続的ではありません。アプリケーションが再起動すると、会話履歴は失われます。通常、このパターンは、テスト用の ADK に含まれている InMemoryMemoryService などの開発フレームワーク内のインメモリ プロバイダを使用して実装します。
  • 外部ストレージ: 本番環境アプリケーションの場合は、外部の永続ストレージ サービスでエージェントのナレッジベースを管理します。外部ストレージ サービスにより、エージェントの知識が永続的でスケーラブルになり、複数のアプリケーション インスタンスからアクセスできるようになります。 Google Cloudの任意のエージェント ランタイムで長期保存に Memory Bank を使用します。

エージェントの設計パターン

エージェント設計パターンは、エージェント アプリケーションを構築するための一般的なアーキテクチャ アプローチです。これらのパターンは、システムのコンポーネントの整理、AI モデルの統合、単一のエージェントまたは複数のエージェントのオーケストレーションを行ってワークフローを実現するための明確なフレームワークを提供します。ワークフローに最適なアプローチを判断するには、タスクの複雑さとワークフロー、レイテンシ、パフォーマンス、費用の要件を考慮する必要があります。

単一エージェント システムは、1 つのモデルの推論機能に依存して、ユーザーのリクエストを解釈し、一連のステップを計画し、使用するツールを決定します。このアプローチは、アーキテクチャの複雑さを追加する前に、コアロジック、プロンプト、ツール定義の改善に集中できる効果的な出発点となります。ただし、タスクとツールの複雑さが増すにつれて、単一のエージェントのパフォーマンスが低下する可能性があります。

複雑な問題の場合、マルチエージェント システムは、単一のエージェントでは簡単に管理できない目標を達成するために、複数の特殊なエージェントをオーケストレートします。このモジュール設計により、システムの拡張性、信頼性、保守性が向上します。ただし、単一エージェント システムと比較して、評価、セキュリティ、費用の考慮事項が増えます。

マルチエージェント システムを開発する場合は、各専門エージェントに正確なアクセス制御を実装し、エージェント間の信頼性の高い通信を確保するための堅牢なオーケストレーション システムを設計し、複数のエージェントを実行する計算オーバーヘッドによる運用コストの増加を管理する必要があります。エージェント間の通信を容易にするには、ADK で Agent2Agent（A2A）プロトコルを使用します。A2A は、基盤となるテクノロジーに関係なく、AI エージェントがさまざまなプラットフォームやフレームワーク間で通信して連携できるようにするオープン スタンダード プロトコルです。

一般的なエージェント設計パターンと、ワークロード要件に基づいてパターンを選択する方法については、エージェントベースの AI システムの設計パターンを選択するをご覧ください。

AI モデル

エージェント アプリケーションは、モデルの推論機能と理解機能に依存して、プライマリ タスク オーケストレーターとして機能します。このコア エージェント ロールには、Gemini Pro を使用することをおすすめします。

Gemini などの Google モデルは、マネージド API を介して最新かつ最も高性能な独自のモデルへのアクセスを提供します。このアプローチは、運用上のオーバーヘッドを最小限に抑える場合に最適です。一方、オープンでセルフホスト型のモデルは、独自のデータでファインチューニングを行う場合に必要となる詳細な制御を提供します。セキュリティとデータ所在地に関する厳格な要件があるワークロードでは、モデルを独自のネットワーク内で実行できるセルフホスト モデルも必要になります。

エージェントのパフォーマンスを向上させるには、モデルの推論機能を調整します。最新の Gemini Pro モデルと Gemini Flash モデルなどのモデルには、推論と多段階の計画を改善する思考プロセスが組み込まれています。デバッグと改善のために、モデルの思考の要約（内部思考の合成バージョン）を確認して、推論のパスを把握できます。タスクの複雑さに基づいて思考予算（思考トークンの数）を調整することで、モデルの推論能力を制御できます。思考予算が大きいほど、モデルは回答を提供する前に、より詳細な推論と計画を実行できます。思考予算を増やすと、回答の質が向上する可能性がありますが、レイテンシとコストも増加する可能性があります。

パフォーマンスと費用を最適化するには、モデル ルーティングを実装して、タスクの複雑さ、費用、レイテンシの要件に基づいて、各タスクに最適なモデルを動的に選択します。たとえば、コード生成やテキスト分類などの構造化されたタスクについては、単純なリクエストを小規模言語モデル（SLM）に転送し、複雑な推論についてはより強力で高価なモデルを予約できます。エージェント アプリケーションでモデル ルーティングを実装すると、高いパフォーマンスを維持しながら費用対効果の高いシステムを構築できます。

Google Cloud は、エージェント アーキテクチャで使用できる Google モデル、パートナー モデル、オープンモデルの幅広い選択肢へのアクセスを提供します。利用可能なモデルとニーズに合ったモデルの選択方法の詳細については、Vertex AI の Model Garden をご覧ください。

モデル ランタイム

モデル ランタイムは、AI モデルをホストして提供し、その推論機能をエージェントで使用できるようにする環境です。

モデル ランタイムを選択する

AI モデルをホストする際に最適なランタイムを選択するには、次のガイダンスを使用します。

ユースケース モデル ランタイム
Gemini モデル、パートナー モデル、オープンモデル、カスタムモデルをエンタープライズ グレードのセキュリティ、スケーリング、生成 AI ツールで提供するには、フルマネージド API が必要です。 Vertex AI
オープンまたはカスタムのコンテナ化されたモデルをデプロイし、トラフィックの変動に対してサーバーレスのシンプルさと費用対効果を優先する必要があります。 Cloud Run
専用のハードウェアでオープンまたはカスタムのコンテナ化されたモデルを実行する場合や、複雑なセキュリティとネットワーキングの要件を満たす場合は、インフラストラクチャを最大限に制御する必要があります。 GKE

以降のセクションでは、上記のモデル ランタイムの概要（主な機能や設計上の考慮事項など）について説明します。このドキュメントでは、Vertex AI、Cloud Run、GKE について説明します。ただし、 Google Cloud には、モデル ランタイムで検討できる他のサービスがあります。

  • Gemini API: Gemini API は、複雑なエージェント システムで必要となることが多いエンタープライズ ガバナンス機能を使用せずに、Gemini モデルに迅速かつ直接的にアクセスする必要があるデベロッパー向けに設計されています。
  • Compute Engine: Compute Engine は、レガシー アプリケーションに適した Infrastructure as a Service（IaaS）プロダクトです。最新のコンテナベースのランタイムと比較して、運用上のオーバーヘッドが大幅に増加します。

モデル ランタイムのすべてのサービス オプションを区別する機能の詳細については、モデル ホスティング インフラストラクチャをご覧ください。

Vertex AI

Vertex AI は、AI モデルをホストするフルマネージドのサーバーレス環境を提供します。安全でスケーラブルな API を介して、Google モデル、パートナー モデル、オープンモデルをサービングしてファインチューニングできます。このアプローチでは、すべてのインフラストラクチャ管理が抽象化されるため、モデル インテリジェンスをアプリケーションに統合することに集中できます。

Vertex AI をモデル ランタイムとして使用する場合の主な機能と考慮事項は次のとおりです。

  • インフラストラクチャ制御: モデル用のフルマネージド API。基盤となるインフラストラクチャは Google が管理します。
  • セキュリティ: 管理対象のセキュリティのデフォルトと標準のコンプライアンス認証でニーズを満たせる。プロンプトとレスポンスの保護を提供し、責任ある AI の取り組みを確実にするには、Model Armor を Vertex AI に統合します。
  • モデルの可用性: マネージド API を介して、最新の Gemini モデルを含む幅広いモデルにアクセスできます。
  • 費用: アプリケーションのトラフィックに応じてスケーリングする従量課金制モデル。詳細については、Vertex AI での AI モデルの構築とデプロイの費用をご覧ください。

Cloud Run

Cloud Run は、カスタム コンテナ内でモデルをホストするサーバーレス ランタイムを提供します。Cloud Run は、Vertex AI のフルマネージドのシンプルさと GKE のインフラストラクチャの深い制御のバランスを提供します。このアプローチは、サーバーやクラスタを管理せずにコンテナ化された環境でモデルを実行する柔軟性が必要な場合に最適です。

Cloud Run をモデル ランタイムとして使用する場合の主な機能と考慮事項は次のとおりです。

  • インフラストラクチャの制御: カスタム コンテナで任意のモデルを実行します。これにより、ソフトウェア環境を完全に制御できます。基盤となるサーバーレス インフラストラクチャはプラットフォームによって管理されます。
  • セキュリティ: エフェメラルで分離されたコンピューティング インスタンスを介してセキュリティを提供し、ダイレクト VPC 下り（外向き）またはサーバーレス VPC アクセス コネクタを使用して、プライベート リソースへの安全な接続を可能にします。詳細については、プライベート ネットワーキングと Cloud Run をご覧ください。
  • モデルの可用性: Gemma などのオープンモデルを提供するか、独自のカスタムモデルを提供します。Cloud Run で Gemini モデルをホストまたは提供することはできません。
  • 費用: ゼロにスケーリングする従量課金制のリクエスト ベースの料金モデルを採用しているため、トラフィックが断続的または変動するモデルでは費用対効果が高くなります。詳細については、Cloud Run の料金をご覧ください。

GKE

GKE は、AI モデルのホスティングに最大限の制御と柔軟性を提供します。このアプローチを使用するには、構成して管理する GKE クラスタ上のコンテナでモデルを実行します。GKE は、専用のハードウェアでモデルを実行する必要がある場合、最小限のレイテンシでアプリケーションとモデルをコロケーションする必要がある場合、またはサービング環境のあらゆる側面をきめ細かく制御する必要がある場合に最適な選択肢です。

GKE をモデル ランタイムとして使用する場合、主な機能と考慮事項は次のとおりです。

  • インフラストラクチャの制御: ノード構成、専用マシン アクセラレータ、特定のモデル サービング ソフトウェアなど、サービング環境全体をきめ細かく制御できます。
  • セキュリティ: モデルをネットワーク内で完全に実行し、きめ細かい Kubernetes セキュリティ ポリシーを適用できるため、最高レベルのセキュリティとデータ分離を実現します。GKE クラスタとの間のトラフィックをスクリーニングし、AI モデルとのすべてのやり取りを保護するには、Model Armor を GKE と統合します。
  • モデルの可用性: Gemma などのオープンモデルを提供するか、独自のカスタムモデルを提供します。GKE で Gemini モデルをホストまたは提供することはできません。
  • 費用: 使用する基盤となるコンピューティング リソースとクラスタ リソースに基づく費用モデルを備えています。これにより、確約利用割引（CUD）を使用する場合に、予測可能で大容量のワークロードに対して高度に最適化されます。詳細については、Google Kubernetes Engine の料金をご覧ください。

エージェント ランタイム

エージェント アプリケーションをホストしてデプロイするには、エージェント ランタイムを選択する必要があります。このサービスは、アプリケーション コード（エージェント開発フレームワークを使用するときに作成するビジネス ロジックとオーケストレーション）を実行します。このランタイムから、アプリケーションは選択したモデル ランタイムがホストして管理するモデルに API 呼び出しを行います。

エージェント ランタイムを選択する

AI エージェントをホストするときにランタイムを選択する際は、次のガイダンスを使用します。

ユースケース エージェント ランタイム
アプリケーションは Python エージェントであり、運用上のオーバーヘッドを最小限に抑えたフルマネージド エクスペリエンスが必要です。 Vertex AI Agent Engine
アプリケーションがコンテナ化されており、言語の柔軟性を備えたサーバーレスのイベント ドリブン スケーリングが必要です。 Cloud Run
アプリケーションがコンテナ化されており、複雑なステートフル要件があり、きめ細かいインフラストラクチャ構成が必要な場合。 GKE

Cloud Run または GKE でアプリケーションをすでに管理している場合は、エージェント ワークロードに同じプラットフォームを使用することで、開発を加速し、長期的な運用を簡素化できます。

以降のセクションでは、各エージェント ランタイムの概要について、主な機能と設計上の考慮事項を含めて説明します。

Vertex AI Agent Engine

Vertex AI Agent Engine は、エージェント アプリケーションのデプロイ、運用、スケーリングに使用できるフルマネージド型のオピニオン ランタイムです。Vertex AI Agent Engine は基盤となるインフラストラクチャを抽象化するため、運用ではなくエージェントのロジックに集中できます。

Vertex AI Agent Engine の機能と考慮事項は次のとおりです。

  • プログラミング言語とフレームワークの柔軟性: サポートされているフレームワークを使用して、Python でエージェントを開発します。
  • 通信プロトコル: MCP と A2A を使用するエージェントとツールをオーケストレートします。Vertex AI Agent Engine は、これらのコンポーネントのランタイムを効率的に管理しますが、カスタム MCP サーバーのホスティングはサポートしていません。
  • メモリ: 組み込みのマネージド メモリ機能を提供します。これにより、コア エージェントのメモリ用に外部データベースを構成する必要がなくなります。
    要件 使用可能なオプション
    短期記憶 Vertex AI Agent Engine セッション
    長期記憶 Memory Bank
    データベースの検索と取得
  • スケーラビリティ: エージェント ワークロードの需要に合わせて自動的にスケーリングされるため、手動構成の必要がなくなります。Vertex AI Agent Engine は Cloud Run 上に構築されており、Cloud Run の組み込みインスタンス スケーリングを使用してこの自動スケーリングを実現しています。
  • オブザーバビリティ: Google Cloud Observability サービスを通じて、ロギング、モニタリング、トレースの統合を提供します。
  • セキュリティ: 次のエンタープライズ レベルの信頼性、スケーラビリティ、コンプライアンスを提供します。

    Vertex AI Agent Engine のセキュリティ機能については、エンタープライズ セキュリティをご覧ください。

Vertex AI Agent Engine は、エージェントの運用時にライフサイクルやコンテキスト管理などの複雑な側面を処理する専用のマネージド環境を提供するため、本番環境への移行を加速します。Vertex AI Agent Engine は、コンピューティング環境の広範なカスタマイズが必要なユースケースや、Python 以外のプログラミング言語が必要なユースケースには適していません。プライベート依存関係管理に厳しいセキュリティ要件があるワークロードの場合、Cloud Run と GKE は、より直接的な IAM ベースの構成パスを提供します。

Cloud Run

Cloud Run は、ステートレス コンテナでエージェント アプリケーション コードを実行できるフルマネージドのサーバーレス プラットフォームです。Cloud Run は、基盤となるインフラストラクチャを管理することなく、エージェント アプリケーション全体、個々のコンポーネント、カスタムツールをスケーラブルな HTTP エンドポイントとしてデプロイする場合に最適です。

Cloud Run の機能と考慮事項は次のとおりです。

Cloud Run は、インフラストラクチャ管理が不要になるため、運用が大幅に簡素化され、費用対効果が高くなります。ただし、Cloud Run のステートレスな性質により、マルチステップ ワークフロー全体でコンテキストを管理するには、ストレージ サービスを使用する必要があります。また、Cloud Run サービスのリクエスト タイムアウトの最大値は 1 時間です。これにより、長時間実行されるエージェント タスクが制約される可能性があります。

GKE

Google Kubernetes Engine（GKE）は、エージェント アプリケーションのアーキテクチャとインフラストラクチャをきめ細かく制御できるマネージド コンテナ オーケストレーション サービスです。GKE は、堅牢な本番環境グレードの機能を必要とする複雑なエージェント システムに適しています。また、すでに GKE をご利用のお客様が、既存のアプリケーションの上にエージェント ワークフローを実装する場合にも適しています。

GKE で使用できる機能と考慮事項は次のとおりです。

  • プログラミング言語とフレームワークの柔軟性: アプリケーションをコンテナにパッケージ化するときに、任意のプログラミング言語と任意のフレームワークでエージェントを開発できます。
  • 通信プロトコル: MCP と A2A を使用するエージェントとツールをオーケストレートします。MCP クライアントとサーバーをコンテナとしてパッケージ化する場合は、GKE でホストします。
  • メモリ: GKE Pod はエフェメラルです。ただし、クラスタ内リソースを使用するか、外部サービスに接続することで、永続メモリを使用してステートフル エージェントを構築できます。
    要件 使用可能なオプション
    短期記憶
    長期記憶
    データベースの検索と取得
  • スケーラビリティ: GKE クラスタは、ワークロードの要件を満たすようにノードプールを自動的にプロビジョニングしてスケーリングします。
  • オブザーバビリティ: Google Cloud Observability を使用して、クラスタ、ノード、Pod レベルで統合されたロギング、モニタリング、トレースを提供します。構成済みのサードパーティ指標とユーザー定義指標を収集して Cloud Monitoring に送信するには、Google Cloud Managed Service for Prometheus を使用することもできます。詳細については、GKE オブザーバビリティの概要をご覧ください。
  • セキュリティ: エージェントに対するきめ細かいセキュリティ管理を提供します。

GKE は最大限の制御と柔軟性を提供するため、複雑なステートフル エージェントを実行できます。ただし、この制御には運用上のオーバーヘッドと複雑さが伴います。ノードプール、ネットワーキング、スケーリング ポリシーなど、Kubernetes クラスタを構成して管理する必要があります。これには、サーバーレス プラットフォームよりも多くの専門知識と開発作業が必要です。

次のステップ

寄稿者

著者: Samantha He | テクニカル ライター

その他の寄稿者:

  • Amina Mansour | Cloud Platform 評価チームの責任者
  • Amit Maraj | デベロッパー リレーションズ エンジニア
  • Casey West | アーキテクチャ アドボケイト、 Google Cloud
  • Jack Wotherspoon | デベロッパー アドボケイト
  • スタッフ テクニカル ライター | Joe Fernandez
  • Joe Shirey | Cloud デベロッパー リレーション マネージャー
  • Karl Weinmeister | クラウド プロダクト デベロッパー リレーションズ担当ディレクター
  • Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー
  • Lisa Shen | シニア アウトバウンド プロダクト マネージャー、 Google Cloud
  • Mandy Grover | アーキテクチャ センター責任者
  • Megan O'Keefe | デベロッパー アドボケイト
  • Olivier Bourgeois | デベロッパー リレーションズ エンジニア
  • Polong Lin | デベロッパー リレーションズ エンジニアリング マネージャー
  • Shir Meir Lador | デベロッパー リレーションズ エンジニアリング マネージャー
  • Vlad Kolesnikov | デベロッパー リレーションズ エンジニア