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

Last reviewed 2026-04-21 UTC

このドキュメントでは、 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 フレームワークを使用することもできます。Genkit は、ADK が提供する高レベルの抽象化なしで、エージェント ロジックをきめ細かく制御できるプリミティブを提供します。ただし、ADK などの専用のエージェント フレームワークは、エージェント アプリケーションの開発に特化したツールを提供します。

エージェント ツール

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

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

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

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

組み込みツール

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

MCP

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

MCP は、標準のハードウェア ポートでさまざまな周辺機器をデバイスに接続できるのと同様に、エージェントのコア推論ロジックをツールの特定の実装から切り離します。

MCP には次の利点があります。

  • 事前構築済みのコネクタを提供することで、ツールの統合を簡素化します。MCP サーバーにツールを追加すると、エージェントは追加の構成なしでツールを検出します。
  • カスタム統合を構築するための一貫した方法を提供します。
  • 柔軟性を提供し、さまざまなモデルやツール間の相互運用性を促進します。

次の方法を使用して、エージェント型 AI システム内に MCP サーバーを実装できます。

  • Google Cloud MCP サーバー: Google サービスと Google Cloud サービスに接続するには、Google がフルマネージドで提供するリモート MCP サーバーに接続します。これらのサーバーは、使用するすべての Google サービスと Google Cloud サービスにわたって統一されたレイヤを提供することで、既存のインフラストラクチャを強化します。これらのサーバーは、ステートレス スケーリングと Identity and Access Management（IAM）および Cloud Audit Logs との統合を提供します。Google Cloud MCP サーバーのリストについては、サポート対象プロダクトをご覧ください。
  • リモート MCP サーバー: 外部 API に接続するには、サードパーティによってホストおよび管理されているリモート MCP サーバーに接続します。
  • 自己ホスト型 MCP サーバー: 独自のエージェント ロジックとカスタムツールを実装するには、独自の MCP サーバーをホストします。エージェントに公開する独自の API やサードパーティ製 API を完全に制御できます。独自のカスタム MCP サーバーをホストするには、Cloud Run または Google Kubernetes Engine（GKE）にコンテナ化されたアプリケーションとしてデプロイします。

API 管理プラットフォーム

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

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

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

カスタム関数ツール

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

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

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

ツールの肥大化

ツールの肥大化は、AI モデルのシステム プロンプトでツール定義を過剰に指定した場合に発生します。モデルのコンテキスト ウィンドウに過剰な数のツール、複雑なパラメータ、詳細な説明が含まれていると、モデルが過負荷になる可能性があります。

AI エージェントにツールが過剰に割り当てられていると、次の問題が発生する可能性があります。

  • 精度の低下: 無関係なトークンによって、モデルの注意がコンテキスト ウィンドウ全体に分散されます。モデルの注意が分散されると、モデルがノイズから正しいツールを正確に区別することが難しくなります。
  • 費用とレイテンシの増加: 1 つのユーザー リクエストで、複数の非表示の推論ループとツール実行がトリガーされる可能性があります。ループと実行の数が増加すると、コストとツールの応答時間も増加します。

ツールの肥大化を軽減するには、次の戦略を実装します。

  • ツールの複雑さを制限する: 簡潔なツール定義を作成するための推奨事項は次のとおりです。
    • 複雑なネストされたオブジェクトではなく、プリミティブ データ型を使用します。
    • ツールを 5 個未満のパラメータに制限します。
    • 自由形式の文字列の代わりに enums を使用して、モデルの決定パスを制約します。
  • 粒度の細かいツールセットを提供する: モノリシック サーバーを、特定のユーザー ジャーニーに基づく粒度の細かい、焦点を絞ったツールセットに分解します。たとえば、大規模な Cloud SQL サーバーを、DevOps エージェント用の管理者ツールセットとアプリ エージェント用のデータ ツールセットに分離できます。
  • 設定モードの切り替えを実装する: 関連するコンテキストと機能を事前にすべて読み込むのではなく、必要な場合にのみ動的にロック解除するシステムを設計します。プログレッシブ ディスクロージャー アプローチを実装するには、次の戦略を使用します。
    • 検索ツールのパターン: トークンの消費量を減らすには、単一の検索ツールを使用して関連するツールスキーマのみを動的に読み込むエージェントを実装します。
    • エージェントのスキル: エージェントのスキルは、手順、スクリプト、その他のリソースを段階的に検出できる標準形式です。コンテキストの肥大化を最小限に抑えるには、必要な場合にのみ追加のコンテキストを取得するようにエージェントに指示するエージェント スキルを定義します。
    • マルチエージェント委任: エージェントのコンテキスト ウィンドウを縮小するには、コーディネーター エージェントを使用して特定のタスクを専門のサブエージェントに委任するマルチエージェント システムを実装します。このアプローチにより、関連するツールのみが読み込まれ、コーディネーター エージェントのコンテキスト ウィンドウが簡潔に保たれます。

これらの戦略は相互に排他的ではなく、アーキテクチャとワークロードの要件に基づいて組み合わせる必要があります。

エージェントのメモリ

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

短期記憶

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

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

ADK を使用して短期記憶を実装するためのオプションは次のとおりです。

  • インメモリ ストレージ: 開発、テスト、単一インスタンスで実行されるシンプルなアプリケーションでは、セッション状態をアプリケーションのメモリに直接保存できます。エージェントは、辞書やオブジェクトなどのデータ構造を使用して、Key-Value ペアのリストを保存し、セッション全体でこれらの値を更新します。ただし、インメモリ ストレージを使用する場合、セッション状態は永続的ではありません。アプリケーションが再起動すると、すべての会話履歴が失われます。

  • 外部状態管理: スケーラビリティと信頼性を必要とする本番環境アプリケーションの場合は、ステートレス エージェント アプリケーションを構築し、外部ストレージ サービスでセッション状態を管理することをおすすめします。このアーキテクチャでは、エージェント アプリケーションがリクエストを受信するたびに、外部ストアから現在の会話の状態を取得し、新しいターンを処理してから、更新された状態をストアに保存します。この設計により、どのインスタンスでもユーザーのリクエストを処理できるため、アプリケーションを水平方向にスケーリングできます。外部状態管理の一般的な選択肢には、Memorystore for Redis、Firestore、Vertex AI Agent Engine セッションなどがあります。

    ADK を使用する場合、DatabaseSessionService には Cloud SQL などのリレーショナル データベースが必要です。

長期記憶

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

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

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

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

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

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

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

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

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

AI モデル

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

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

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

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

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

モデル ランタイム

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

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

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

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

以降のセクションでは、上記のモデル ランタイムの概要（主な機能や設計上の考慮事項など）について説明します。このドキュメントでは、Vertex AI、Cloud Run、Google Kubernetes Engine（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 セッション
    長期記憶 メモリバンク
    データベースの検索と取得
  • スケーラビリティ: エージェント ワークロードの需要に合わせて自動的にスケーリングされるため、手動構成は不要です。
  • オブザーバビリティ: 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 は最大限の制御と柔軟性を提供するため、複雑なステートフル エージェントを実行できます。ただし、この制御により、運用上のオーバーヘッドと複雑さが大幅に増大します。ノードプール、ネットワーキング、スケーリング ポリシーなど、Kubernetes クラスタを構成して管理する必要があります。これには、サーバーレス プラットフォームよりも多くの専門知識と開発作業が必要です。

次のステップ

寄稿者

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

その他の寄稿者:

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