このドキュメントでは、 Google Cloudで堅牢なマルチエージェント AI システムを設計する際に役立つリファレンス アーキテクチャについて説明します。マルチエージェント AI システムは、複雑で動的なプロセスを複数の専門 AI エージェントが共同で実行する個別のタスクに分割することで、プロセスを最適化します。
このドキュメントは、クラウドで AI インフラストラクチャとアプリケーションを構築して管理するアーキテクト、デベロッパー、管理者を対象としています。このドキュメントは、AI エージェントとモデルに関する基本的な知識があることを前提としています。このドキュメントでは、AI エージェントの設計とコーディングに関する具体的なガイダンスは提供していません。
アーキテクチャ
次の図は、 Google Cloudにデプロイされたマルチエージェント AI システムの例のアーキテクチャを示しています。
アーキテクチャ コンポーネント
前のセクションのサンプル アーキテクチャには、次のコンポーネントが含まれています。
| コンポーネント | 説明 |
|---|---|
| フロントエンド | ユーザーは、サーバーレスの Cloud Run サービスとして実行されるチャット インターフェースなどのフロントエンドを介して、マルチエージェント システムとやり取りします。 |
| エージェント | この例では、コーディネーター エージェントがエージェント AI システムを制御します。コーディネーター エージェントは、適切なサブエージェントを呼び出してエージェント フローをトリガーします。エージェントは Agent2Agent（A2A）プロトコルを使用して相互に通信できます。これにより、プログラミング言語やランタイムに関係なく、エージェント間の相互運用が可能になります。このアーキテクチャの例は、シーケンシャル パターンと反復的な改善パターンを示しています。この例のサブエージェントの詳細については、エージェント フローのセクションをご覧ください。 |
| エージェントのランタイム | AI エージェントは、サーバーレスの Cloud Run サービス、Google Kubernetes Engine（GKE）上のコンテナ化されたアプリ、または Vertex AI Agent Engine にデプロイできます。 |
| ADK | エージェント開発キット（ADK）は、エージェントの開発、テスト、デプロイを行うためのツールとフレームワークを提供します。ADK はエージェント作成の複雑さを抽象化し、AI デベロッパーがエージェントのロジックと機能に集中できるようにします。 |
| AI モデルとモデル ランタイム | 推論サービングの場合、このアーキテクチャ例のエージェントは Vertex AI の AI モデルを使用します。このアーキテクチャでは、使用する AI モデルの代替ランタイムとして Cloud Run と GKE が示されています。 |
| Model Armor | Model Armor を使用すると、Vertex AI と GKE にデプロイされたモデルの入力とレスポンスを検査してサニタイズできます。詳細については、 Google Cloud サービスとの Model Armor の統合をご覧ください。 |
| MCP クライアント、サーバー、ツール | Model Context Protocol（MCP）は、エージェントとツールの間のやり取りを標準化することで、ツールへのアクセスを容易にします。エージェントとツールのペアごとに、MCP クライアントは MCP サーバーにリクエストを送信します。このサーバーを介して、エージェントはデータベース、ファイル システム、API などのツールにアクセスします。 |
エージェント フロー
上記のアーキテクチャのマルチエージェント システムの例には、次のフローがあります。
- ユーザーが、サーバーレスの Cloud Run サービスとして実行されるチャット インターフェースなどのフロントエンドを介してプロンプトを入力します。
- フロントエンドは、プロンプトをコーディネーター エージェントに転送します。
コーディネーター エージェントは、プロンプトで表現されたインテントに基づいて、次のいずれかのエージェント フローを開始します。
- Sequential:
- task-A サブエージェントがタスクを実行します。
- タスク A サブエージェントがタスク A.1 サブエージェントを呼び出します。
反復的な改良:
- task-B サブエージェントがタスクを実行します。
- 品質評価サブエージェントは、タスク B サブエージェントの出力を確認します。
- 出力が不十分な場合、品質評価者はプロンプト エンハンサー サブエージェントを呼び出してプロンプトを調整します。
- タスク B サブエージェントは、拡張プロンプトを使用してタスクを再度実行します。
このサイクルは、出力が満足のいくものになるか、最大イテレーション回数に達するまで続きます。
このアーキテクチャの例には、必要に応じて人間がエージェント フローに介入できるようにする人間参加型パスが含まれています。
- Sequential:
タスク A.1 サブエージェントと品質評価サブエージェントは、レスポンス ジェネレータ サブエージェントを個別に呼び出します。
レスポンス ジェネレータ サブエージェントはレスポンスを生成し、検証とグラウンディング チェックを実行してから、コーディネーター エージェントを介して最終的なレスポンスをユーザーに送信します。
使用するプロダクトとツール
このリファレンス アーキテクチャでは、次の Google Cloud プロダクトとサードパーティ プロダクトおよびツールを使用します。
- Cloud Run: Google のスケーラブルなインフラストラクチャ上でコンテナを直接実行できるマネージド コンピューティング プラットフォーム。
- Vertex AI: ML モデルと AI アプリケーションのトレーニングとデプロイを行い、AI を活用したアプリケーションで使用する LLM をカスタマイズできる ML プラットフォーム。
- Google Kubernetes Engine（GKE）: Google のインフラストラクチャを使用して、コンテナ化されたアプリケーションを大規模にデプロイして運用するために使用できる Kubernetes サービス。
- Model Armor: プロンプト インジェクション、センシティブ データの漏洩、有害なコンテンツから生成 AI とエージェント AI のリソースを保護するサービス。
- Agent Development Kit（ADK）: AI エージェントの開発、テスト、デプロイを行うためのツールとライブラリのセット。
- Agent2Agent（A2A）プロトコル: プログラミング言語やランタイムに関係なく、エージェント間の通信と相互運用性を実現するオープン プロトコル。
- Model Context Protocol（MCP）: AI アプリケーションを外部システムに接続するためのオープンソース標準。
ユースケース
マルチエージェント AI システムは、ビジネス目標を達成するために複数の専門的なスキルセットにわたるコラボレーションと調整が必要な複雑なユースケースに適しています。マルチエージェント AI システムに適したユースケースを特定するには、ビジネス プロセスを分析し、AI で強化できる特定のタスクを特定します。コスト削減や処理の高速化など、具体的なビジネス成果に焦点を当てます。このアプローチにより、AI への投資をビジネス価値に合わせることができます。
マルチエージェント AI システムのユースケースの例を次に示します。
ファイナンシャル アドバイザー
パーソナライズされた株式取引のおすすめを提供し、取引を実行します。次の図は、このユースケースのエージェント フローの例を示しています。この例では、順次パターンを使用しています。
図は次のフローを示しています。
- データ取得エージェントは、信頼できるソースからリアルタイムの株価と過去の株価、企業の財務報告書、その他の関連データを取得します。
- 財務アナライザー エージェントは、適切な分析手法とグラフ作成手法をデータに適用し、価格変動パターンを特定して予測を行います。
- 株価推奨エージェントは、分析とグラフを使用して、ユーザーのリスク プロファイルと投資目標に基づいて、特定の株の売買に関するパーソナライズされた推奨事項を生成します。
- 取引執行エージェントは、ユーザーに代わって株を売買します。
リサーチ アシスタント
調査計画を作成し、情報を収集して調査を評価、改善し、レポートを作成します。次の図は、このユースケースのエージェント フローの例を示しています。この例のメインフローでは、シーケンシャル パターンを使用しています。この例には、反復的な絞り込みパターンも含まれています。
図は次のフローを示しています。
- プランナー エージェントが詳細な調査計画を作成します。
リサーチャー エージェントは次のタスクを実行します。
- 調査計画を使用して、適切な内部データソースと外部データソースを特定します。
- 必要なデータを収集して分析します。
- 調査の概要を準備し、評価エージェントに提供します。
研究エージェントは、評価エージェントが研究を承認するまでこれらのタスクを繰り返します。
レポート作成エージェントが最終的な調査レポートを作成します。
サプライ チェーン オプティマイザー
在庫の最適化、配送の追跡、サプライ チェーン パートナーとのコミュニケーションを行います。次の図は、このユースケースのエージェント フローの例を示しています。この例では、順次パターンを使用しています。
倉庫管理エージェントは、在庫、需要予測、サプライヤーのリードタイムに基づいて再入荷注文を作成し、最適な在庫レベルを確保します。
- エージェントは配送追跡エージェントとやり取りして、配送を追跡します。
- エージェントはサプライヤー コミュニケーター エージェントとやり取りして、注文の変更をサプライヤーに通知します。
配送追跡エージェントは、サプライヤーの物流プラットフォームと運送業者のシステムを統合することで、注文のタイムリーで効率的な処理を保証します。
サプライヤー コミュニケーター エージェントは、システム内の他のエージェントに代わって外部サプライヤーと通信します。
設計上の考慮事項
このセクションでは、このリファレンス アーキテクチャを使用して、セキュリティ、信頼性、費用、パフォーマンスに関する特定の要件を満たすトポロジを開発する際に考慮すべき設計要素、ベスト プラクティス、推奨事項について説明します。
このセクションのガイダンスはすべてを網羅しているわけではありません。ワークロードの要件と、使用する Google Cloud およびサードパーティのプロダクトや機能によっては、考慮すべき追加の設計要素やトレードオフが存在する可能性があります。
システム設計
このセクションでは、デプロイに使用する Google Cloud リージョンの選択と、適切な Google Cloud プロダクトとツールの選択に役立つガイダンスを示します。
リージョンの選択
AI アプリケーションの Google Cloud リージョンを選択する場合は、次の要素を考慮してください。
- 各リージョンでの Google Cloud サービスの可用性。
- エンドユーザーのレイテンシ要件。
- Google Cloud リソースの費用。
- 規制要件
アプリケーションに適した Google Cloud ロケーションを選択するには、次のツールを使用します。
- Google Cloud リージョン選択ツール: 温室効果ガス排出量、費用、レイテンシなどの要因に基づいて、アプリケーションとデータに最適な Google Cloudリージョンを選択するためのインタラクティブなウェブベースのツール。
- Cloud Location Finder API: Google Cloud、Google Distributed Cloud、その他のクラウド プロバイダのデプロイ ロケーションをプログラムで検索する方法を提供するパブリック API。
エージェントの設計
このセクションでは、AI エージェントの設計に関する一般的な推奨事項について説明します。エージェントのコードとロジックの作成に関する詳細なガイダンスは、このドキュメントの範囲外です。
| デザインの焦点 | 推奨事項 |
|---|---|
| エージェントの定義と設計 |
|
| エージェントとのやり取り |
|
| コンテキスト、ツール、データ |
|
セキュリティ
このセクションでは、ワークロードのセキュリティ要件を満たす Google Cloud のトポロジを設計するための設計上の考慮事項と推奨事項について説明します。
| コンポーネント | 設計上の考慮事項と推奨事項 |
|---|---|
| エージェント |
AI エージェントは、従来の決定論的なセキュリティ対策では十分に軽減できない、特有の重大なセキュリティ リスクをもたらします。Google は、決定論的なセキュリティ制御と動的な推論ベースの防御の強みを組み合わせたアプローチを推奨しています。このアプローチは、人間の監視、慎重に定義されたエージェントの自律性、オブザーバビリティという 3 つの基本原則に基づいています。以下に、これらの基本原則に沿った具体的な推奨事項を示します。 人間による監督: エージェント AI システムは、失敗したり、期待どおりに動作しないことがあります。たとえば、モデルが不正確なコンテンツを生成したり、エージェントが不適切なツールを選択したりする可能性があります。ビジネスに不可欠なエージェント AI システムでは、human-in-the-loopフローを組み込んで、人間の監督者がエージェントをリアルタイムでモニタリング、オーバーライド、一時停止できるようにします。たとえば、人間のユーザーはエージェントの出力を確認し、出力を承認または拒否して、エラーを修正したり、戦略的な意思決定を行ったりするためのガイダンスを提供できます。このアプローチでは、エージェント AI システムの効率性と、人間のユーザーの批判的思考とドメインの専門知識を組み合わせます。 エージェントのアクセス制御: Identity and Access Management（IAM）コントロールを使用して、エージェントの権限を構成します。各エージェントには、タスクの実行とツールや他のエージェントとの通信に必要な権限のみを付与します。このアプローチにより、侵害されたエージェントがシステム内の他の部分にアクセスできる範囲が制限されるため、セキュリティ侵害の潜在的な影響を最小限に抑えることができます。詳細については、エージェントの ID と権限を設定するとデプロイされたエージェントのアクセスを管理するをご覧ください。 モニタリング: エージェントの動作をモニタリングします。包括的なトレース機能を使用して、エージェントが実行するすべてのアクション（推論プロセス、ツールの選択、実行パスなど）を可視化します。詳細については、Vertex AI Agent Engine でのエージェントのロギングと ADK でのロギングをご覧ください。 AI エージェントの保護の詳細については、AI エージェントの安全性とセキュリティをご覧ください。 |
| Vertex AI |
共有責任: セキュリティは共有責任です。Vertex AI は基盤となるインフラストラクチャを保護し、データ、コード、モデルを保護するためのツールとセキュリティ管理を提供します。サービスを適切に構成し、アクセス制御を管理し、アプリケーションを保護する責任はお客様にあります。詳細については、 Vertex AI の共有責任をご覧ください。 セキュリティ管理: Vertex AI は、データ所在地、顧客管理の暗号鍵（CMEK）、VPC Service Controls を使用したネットワーク セキュリティ、アクセスの透明性の要件を満たすために使用できる Google Cloud セキュリティ管理をサポートしています。詳細については、次のドキュメントをご覧ください。 安全性: AI モデルは、有害なレスポンスを生成する可能性があります。悪意のあるプロンプトに応答することもあります。
モデルへのアクセス: 組織のポリシーを設定して、 Google Cloud プロジェクトで使用できる AI モデルのタイプとバージョンを制限できます。詳細については、Model Garden モデルへのアクセスを制御するをご覧ください。 データ保護: プロンプトとレスポンス、ログデータ内の機密データを検出して匿名化するには、Cloud Data Loss Prevention API を使用します。詳細については、AI アプリでの機密データの保護をご覧ください。 |
| MCP | MCP とセキュリティをご覧ください。 |
| A2A |
トランスポート セキュリティ: A2A プロトコルでは、本番環境のすべての A2A 通信に HTTPS を使用することが義務付けられており、Transport Layer Security（TLS）バージョン 1.2 以降を使用することが推奨されています。 認証: A2A プロトコルは、HTTP ヘッダーなどの標準的なウェブ メカニズムや、OAuth2 や OpenID Connect などの標準に認証を委任します。各エージェントは、エージェントカードで認証要件をアドバタイズします。詳細については、A2A 認証をご覧ください。 |
| Cloud Run |
上り（内向き）セキュリティ（フロントエンド サービスの場合）: アプリケーションへのアクセスを制御するには、フロントエンド Cloud Run サービスのデフォルトの ユーザー認証: フロントエンドの Cloud Run サービスへのユーザー アクセスを認証するには、Identity-Aware Proxy（IAP）を使用します。ユーザーが IAP で保護されたリソースにアクセスしようとすると、IAP が認証と認可のチェックを行います。詳細については、Cloud Run 用に IAP を有効にするをご覧ください。 コンテナ イメージのセキュリティ: 承認済みのコンテナ イメージのみが Cloud Run にデプロイされるようにするには、 Binary Authorization を使用します。コンテナ イメージのセキュリティ リスクを特定して軽減するには、Artifact Analysis を使用して脆弱性スキャンを自動的に実行します。詳細については、コンテナ スキャンの概要をご覧ください。 データ所在地: Cloud Run は、データ所在地の要件を満たすのに役立ちます。Cloud Run functions は、選択したリージョン内で実行されます。 コンテナ セキュリティの詳細については、Cloud Run の一般的な開発のヒントをご覧ください。 |
| アーキテクチャのすべてのプロダクト |
データの暗号化: デフォルトでは、 Google Cloudは Google-owned and Google-managed encryption keysを使用して保存データを暗号化します。ユーザーが制御する暗号鍵を使用してエージェントのデータを保護するには、Cloud KMS で作成および管理する CMEK を使用します。 Google Cloud Cloud KMS と互換性のあるサービスについては、互換性のあるサービスをご覧ください。 データの引き出しのリスクを軽減する: データの引き出しのリスクを軽減するには、インフラストラクチャの周囲に VPC Service Controls 境界を作成します。VPC Service Controls は、このリファレンス アーキテクチャで使用されるすべての Google Cloud サービスをサポートしています。 アクセス制御: トポロジ内のリソースの権限を構成する場合は、最小権限の原則に従います。 デプロイ後の最適化: Google Cloudにアプリケーションをデプロイしたら、Active Assist のおすすめハブを使用して、セキュリティをさらに最適化するための推奨事項を取得します。推奨事項を確認し、環境に応じて適用します。詳細については、おすすめハブで推奨事項を確認するをご覧ください。 クラウド環境のセキュリティ: Security Command Center のツールを使用して、脆弱性を検出し、脅威を特定して軽減し、セキュリティ ポスチャーを定義してデプロイし、データをエクスポートして詳細な分析を行います。 |
その他のセキュリティに関する推奨事項
信頼性
このセクションでは、 Google Cloudのデプロイ用に信頼性の高いインフラストラクチャを構築して運用するための設計上の考慮事項と推奨事項について説明します。
| コンポーネント | 設計上の考慮事項と推奨事項 |
|---|---|
| エージェント |
フォールト トレランス: エージェント レベルの障害を許容または処理するようにエージェント システムを設計します。可能であれば、エージェントが独立して動作できる分散型アプローチを使用します。 障害をシミュレートする: エージェント AI システムを本番環境にデプロイする前に、本番環境をシミュレートして検証します。エージェント間の調整に関する問題や予期しない動作を特定して修正します。 エラー処理: エラーの診断とトラブルシューティングを可能にするため、ロギング、例外処理、再試行メカニズムを実装します。 |
| Vertex AI |
割り当て管理: Vertex AI は、Gemini モデルの動的共有割り当て（DSQ）をサポートしています。DSQ は従量課金制リクエストを柔軟に管理するのに役立ち、割り当てを手動で管理したり、割り当ての増加をリクエストしたりする必要がなくなります。DSQ は、特定のモデルとリージョンで使用可能なリソースをアクティブな顧客間で動的に割り当てます。DSQ では、個々の顧客に事前定義された割り当て上限はありません。 容量計画: モデルへのリクエスト数が割り当てられた容量を超えると、エラーコード 429 が返されます。ビジネス クリティカルで、常に高いスループットを必要とするワークロードの場合は、プロビジョンド スループットを使用してスループットを予約できます。 モデル エンドポイントの可用性: 複数のリージョンまたは国でデータを共有できる場合は、モデルにグローバル エンドポイントを使用できます。 |
| Cloud Run | インフラストラクチャの停止に対する堅牢性: Cloud Run はリージョン サービスです。データはリージョン内の複数のゾーンに同期的に保存され、トラフィックはゾーン間で自動的にロードバランスされます。ゾーンが停止しても、Cloud Run は引き続き実行され、データは失われません。リージョンが停止した場合、Google が問題を解決するまでサービスは実行を停止します。 |
| アーキテクチャのすべてのプロダクト | デプロイ後の最適化: Google Cloudにアプリケーションをデプロイしたら、Active Assist のおすすめハブを使用して、信頼性をさらに最適化するための推奨事項を取得します。推奨事項を確認し、環境に応じて適用します。詳細については、おすすめハブで推奨事項を確認するをご覧ください。 |
AI ワークロードと ML ワークロードに固有の信頼性の原則と推奨事項については、Well-Architected Framework の AI と ML の視点: 信頼性をご覧ください。
運用
このセクションでは、このリファレンス アーキテクチャを使用して、効率的に運用できる Google Cloud トポロジを設計する際に考慮すべき要素について説明します。
| コンポーネント | 設計上の考慮事項と推奨事項 |
|---|---|
| Vertex AI |
ログを使用したモニタリング: デフォルトでは、 継続的評価: エージェントの出力と、エージェントが出力を生成するためにたどった軌跡またはステップの定性的な評価を定期的に実施します。エージェントの評価を実装するには、Gen AI Evaluation Service または ADK がサポートする評価方法を使用します。 |
| MCP |
データベース ツール: AI エージェントのデータベース ツールを効率的に管理し、エージェントが接続プーリングや認証などの複雑な処理を安全に行えるようにするには、データベース向け MCP ツールボックスを使用します。データベース ツールを保存して更新するための一元的な場所を提供します。エージェント間でツールを共有し、エージェントを再デプロイせずにツールを更新できます。このツールボックスには、AlloyDB for PostgreSQL などの Google Cloudデータベースや、MongoDB などのサードパーティ データベース用のさまざまなツールが含まれています。 生成 AI モデル: AI エージェントが Imagen や Veo などの Google 生成 AI モデルを使用できるようにするには、生成メディア API 用の MCP サーバー Google Cloudを使用します。 Google のセキュリティ プロダクトとツール: AI エージェントが Google Security Operations、Google Threat Intelligence、Security Command Center などの Google のセキュリティ プロダクトとツールにアクセスできるようにするには、Google のセキュリティ プロダクト用の MCP サーバーを使用します。 |
| アーキテクチャのすべての Google Cloud プロダクト | トレース: Cloud Trace を使用して、トレースデータを継続的に収集して分析します。トレースデータを使用すると、複雑なエージェント ワークフロー内のエラーを迅速に特定して診断できます。Trace エクスプローラ ツールの可視化により、詳細な分析を行うことができます。詳細については、エージェントをトレースするをご覧ください。 |
AI ワークロードと ML ワークロードに固有のオペレーショナル エクセレンスの原則と推奨事項については、Well-Architected Framework の AI と ML の視点: 運用の卓越性をご覧ください。
費用の最適化
このセクションでは、このリファレンス アーキテクチャを使用して構築した Google Cloud トポロジの設定と運用の費用を最適化するためのガイダンスを示します。
| コンポーネント | 設計上の考慮事項と推奨事項> |
|---|---|
| Vertex AI |
費用分析と管理: Vertex AI の費用を分析して管理するには、秒間クエリ数（QPS）と秒間トークン数（TPS）のベースライン指標を作成することをおすすめします。デプロイ後にこれらの指標をモニタリングします。ベースラインは、容量計画にも役立ちます。たとえば、ベースラインは、プロビジョニングされたスループットが必要になるタイミングを判断するのに役立ちます。 モデルの選択: AI アプリケーション用に選択したモデルは、費用とパフォーマンスの両方に直接影響します。特定のユースケースでパフォーマンスと費用の最適なバランスを実現するモデルを特定するには、モデルを繰り返しテストします。最も費用対効果の高いモデルから始めて、徐々に強力なオプションに移行することをおすすめします。 費用対効果の高いプロンプト: プロンプト（入力）と生成されたレスポンス（出力）の長さは、パフォーマンスと費用に直接影響します。短く、直接的で、十分なコンテキストを提供するプロンプトを作成します。モデルから簡潔なレスポンスを取得するようにプロンプトを設計します。たとえば、「2 文で要約して」や「3 つの要点をリストアップして」などのフレーズを含めます。詳細については、プロンプト設計のベスト プラクティスをご覧ください。 コンテキスト キャッシュ保存: 入力トークン数が多い繰り返しコンテンツを含むリクエストの費用を削減するには、コンテキスト キャッシュ保存を使用します。 バッチ リクエスト: 関連する場合は、バッチ予測を検討します。バッチ リクエストは、標準リクエストよりも費用が低くなります。 |
| Cloud Run |
リソース割り当て: Cloud Run サービスを作成するときに、割り当てるメモリと CPU の量を指定できます。デフォルトの CPU とメモリの割り当てから始めます。リソースの使用量と費用を継続的にモニタリングし、必要に応じて割り当てを調整します。詳細については、次のドキュメントをご覧ください。 レートの最適化: CPU とメモリの要件を予測できる場合は、確約利用割引（CUD）を利用して費用を節約できます。 |
| アーキテクチャのすべてのプロダクト | デプロイ後の最適化: Google Cloudにアプリケーションをデプロイしたら、Active Assist のおすすめハブを使用して、費用をさらに最適化するための推奨事項を取得します。推奨事項を確認し、環境に応じて適用します。詳細については、おすすめハブで推奨事項を確認するをご覧ください。 |
Google Cloud リソースの費用を見積もるには、Google Cloud の料金計算ツールを使用します。
AI ワークロードと ML ワークロードに固有の費用最適化の原則と推奨事項については、Well-Architected Framework の AI と ML の視点: 費用の最適化をご覧ください。
パフォーマンスの最適化
このセクションでは、ワークロードのパフォーマンス要件を満たす Google Cloud のトポロジを設計するための設計上の考慮事項と推奨事項について説明します。
| コンポーネント | 設計上の考慮事項と推奨事項 |
|---|---|
| エージェント |
モデルの選択: エージェント AI システムのモデルを選択する際は、エージェントが実行する必要があるタスクに必要な機能を考慮してください。 プロンプトの最適化: プロンプトのパフォーマンスを大規模に迅速に改善して最適化し、手動で書き直す必要性をなくすには、Vertex AI プロンプト オプティマイザーを使用します。オプティマイザーを使用すると、さまざまなモデルでプロンプトを効率的に調整できます。 |
| Vertex AI |
モデルの選択: AI アプリケーション用に選択したモデルは、費用とパフォーマンスの両方に直接影響します。特定のユースケースでパフォーマンスと費用の最適なバランスを実現するモデルを特定するには、モデルを繰り返しテストします。最も費用対効果の高いモデルから始めて、徐々に強力なオプションに移行することをおすすめします。 プロンプト エンジニアリング: プロンプト（入力）と生成されたレスポンス（出力）の長さは、パフォーマンスと費用に直接影響します。短く、直接的で、十分なコンテキストを提供するプロンプトを作成します。モデルから簡潔なレスポンスを取得するようにプロンプトを設計します。たとえば、「2 文で要約して」や「3 つの要点をリストアップして」などのフレーズを含めます。詳細については、プロンプト設計のベスト プラクティスをご覧ください。 コンテキスト キャッシュ保存: 入力トークン数が多い繰り返しコンテンツを含むリクエストのレイテンシを短縮するには、コンテキスト キャッシュ保存を使用します。 |
| Cloud Run |
リソース割り当て: パフォーマンス要件に応じて、Cloud Run サービスに割り当てるメモリと CPU を構成します。詳細については、次のドキュメントをご覧ください。 パフォーマンスの最適化に関するガイダンスについては、Cloud Run の一般的な開発のヒントをご覧ください。 |
| アーキテクチャのすべてのプロダクト | デプロイ後の最適化: Google Cloudにアプリケーションをデプロイしたら、Active Assist のおすすめハブを使用して、パフォーマンスをさらに最適化するための推奨事項を取得します。推奨事項を確認し、環境に応じて適用します。詳細については、おすすめハブで推奨事項を確認するをご覧ください。 |
AI ワークロードと ML ワークロードに固有のパフォーマンス最適化の原則と推奨事項については、Well-Architected Framework の AI と ML の視点: パフォーマンスの最適化をご覧ください。
デプロイ
マルチエージェント AI システムを構築してデプロイする方法については、次のコードサンプルをご覧ください。これらのコードサンプルは、学習とテストの出発点として完全に機能します。本番環境で最適な運用を行うには、特定のビジネス要件と技術要件に基づいてコードをカスタマイズする必要があります。
- ファイナンシャル アドバイザー: 株式市場のデータを分析し、取引戦略を作成し、実行計画を定義し、リスクを評価します。
- 研究アシスタント: 研究を計画して実施し、調査結果を評価して、研究レポートを作成します。
- 保険代理店: メンバーシップの作成、ロードサービス、保険金請求の処理を行います。
- 検索オプティマイザー: 検索キーワードを見つけ、ウェブページを分析し、検索を最適化するための提案を行います。
- データ アナライザー: データの取得、複雑な操作の実行、可視化の生成、ML タスクの実行を行います。
- ウェブ マーケティング エージェント: ドメイン名の選択、ウェブサイトのデザイン、キャンペーンの作成、コンテンツの制作を行います。
- Airbnb プランナー（A2A と MCP を使用）: 指定された場所と時間で Airbnb のリスティングを検索し、天気情報を取得します。
ADK と MCP サーバーを組み合わせて使用するためのコードサンプルについては、MCP ツールをご覧ください。
次のステップ
- Agent Garden でサンプル エージェントとツールを確認する。
- Agent Development Kit（ADK）を使用してエージェントを構築する。
- エージェントを Google Cloudにデプロイします。
- Cloud Run で A2A エージェントをホストする。
- Cloud Run で MCP サーバーをホストする。
- Google Cloudの AI ワークロードと ML ワークロードに固有のアーキテクチャ原則と推奨事項の概要について、Well-Architected Framework の AI と ML の視点を確認する。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
協力者
著者: Kumar Dhanagopal | クロスプロダクト ソリューション デベロッパー
その他の寄稿者:
- Alan Blount | プロダクト マネージャー
- Filipe Gracio, PhD | カスタマー エンジニア兼 AI / ML スペシャリスト
- Holt Skinner | デベロッパー アドボケイト
- Jack Wotherspoon | デベロッパー アドボケイト
- Joe Shirey | クラウド デベロッパー リレーションズ マネージャー
- Megan O'Keefe | デベロッパー アドボケイト
- Samantha He | テクニカル ライター
- Shir Meir Lador | デベロッパー リレーションズ エンジニアリング マネージャー
- Victor Dantas | 生成 AI フィールド ソリューション アーキテクト
- Vlad Kolesnikov | デベロッパー リレーションズ エンジニア