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

Last reviewed 2026-04-21 UTC

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

これらのフレームワークと AI エージェント間の通信を管理するには、Agent-User Interaction（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、Gemini Enterprise Agent Platform Sessions などがあります。

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

長期記憶

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

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

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

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

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

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

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

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

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

AI モデル

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

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

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

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

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

モデル ランタイム

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

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

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

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

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

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

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

Agent Platform

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

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

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

Cloud Run

Cloud Run は、カスタム コンテナ内でモデルをホストするサーバーレス ランタイムを提供します。Cloud Run は、Agent Platform のフルマネージドのシンプルさと、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 の料金をご覧ください。

エージェント ランタイム

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

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

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

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

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

以降のセクションでは、主な機能や設計上の考慮事項など、各 Agent Runtime の概要について説明します。

Agent Runtime

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

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

  • プログラミング言語とフレームワークの柔軟性: サポートされているフレームワークを使用して、Python でエージェントを開発します。
  • 通信プロトコル: MCP と A2A を使用するエージェントとツールをオーケストレートします。Agent Runtime は、これらのコンポーネントのランタイムを効率的に管理しますが、カスタム MCP サーバーのホスティングはサポートしていません。

  • メモリ: 組み込みのマネージド メモリ機能を提供します。これにより、コア エージェント メモリ用に外部データベースを構成する必要がなくなります。

  • スケーラビリティ: エージェント ワークロードの需要に合わせて自動スケーリングされるため、手動構成が不要になります。
  • オブザーバビリティ: Google Cloud Observability サービスを介して、統合されたロギング、モニタリング、トレースを提供します。
  • セキュリティ: 次のようなエンタープライズ レベルの信頼性、スケーラビリティ、コンプライアンスを提供します。

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

Agent Runtime は、ライフサイクルやコンテキスト管理など、エージェントの運用時に発生する多くの複雑な側面を処理する専用のマネージド環境を提供するため、本番環境への移行を加速します。Agent Runtime は、コンピューティング環境の大幅なカスタマイズが必要なユースケースや、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 | グローバル デベロッパー リレーションズおよび戦略的コンテンツ担当、技術責任者
  • Amit Maraj | デベロッパー リレーションズ エンジニア
  • Casey West | アーキテクチャ アドボケイト、 Google Cloud
  • Jack Wotherspoon | デベロッパー アドボケイト
  • Joe Fernandez | スタッフ テクニカル ライター
  • Joe Shirey | Cloud デベロッパー リレーションズ マネージャー
  • Karl Weinmeister | Cloud プロダクト デベロッパー リレーションズ担当ディレクター
  • Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー
  • Kurtis Van Gent | スタッフ ソフトウェア エンジニア
  • Lisa Shen | シニア アウトバウンド プロダクト マネージャー、 Google Cloud
  • Mandy Grover | アーキテクチャ センター責任者
  • Megan O'Keefe | デベロッパー アドボケイト
  • Olivier Bourgeois | デベロッパーリレーションズ エンジニア
  • Polong Lin | デベロッパー リレーションズ エンジニアリング マネージャー
  • Ryan Pei | Google Cloud、プロダクト マネージャー
  • Shir Meir Lador | デベロッパー リレーションズ エンジニアリング マネージャー
  • Vlad Kolesnikov | デベロッパー リレーションズ エンジニア