このドキュメントでは、 Google Cloudでマルチテナント エージェント型 AI システムを設計してデプロイする際に役立つリファレンス アーキテクチャについて説明します。組織で生成 AI のデプロイを拡大するにつれて、さまざまなビジネス ユニットで、独自のツールにアクセスし、特定の運用ルールに従い、センシティブ データを処理する専用の AI エージェントが必要になります。事業部門が組織内に断片化したアプリケーション サイロを開発すると、運用オーバーヘッドの増加、ガバナンスの重大なギャップ、データ漏洩のリスクが生じる可能性があります。このアーキテクチャは、分散型チームに自律型 AI 機能を付与しながら、統一されたセキュリティとコンプライアンスを維持できる一元化されたシステムを構築する方法を示しています。
このドキュメントは、クラウドでエンタープライズ グレードのマルチエージェント システムを構築して管理するアーキテクト、デベロッパー、管理者を対象としています。このドキュメントは、AI、ML、LLM のコンセプトとエージェント型 AI の基本的な知識があることを前提としています。
このドキュメントのデプロイ セクションでは、マルチテナント エージェント型 AI システムの構築とデプロイに役立つ実装戦略について説明します。
アーキテクチャ
次の図は、ハブアンドスポーク モデルに従うマルチテナント エージェント AI システムのアーキテクチャを示しています。ハブアンドスポーク モデルは、中央環境（ハブ）が複数の分離された環境（スポーク）に接続されるネットワーク設計です。
このアーキテクチャは、次のコンポーネントで構成されています。
| コンポーネント | 説明 |
|---|---|
| VPC Service Controls | このアーキテクチャでは、VPC Service Controls を使用して、組織レベルでサービス境界を構成します。このサービス境界は厳格なセキュリティ境界を提供し、データの引き出しを防ぎます。 |
| ルーティング ハブ |
ルーティング ハブは、アーキテクチャの中心的な上り（内向き）ポイントとして機能し、次のコンポーネントが含まれています。
|
| 一元管理されたガバナンスとセキュリティのハブ |
中央ガバナンスとセキュリティ ハブは、プラットフォーム全体に一元化された Identity and Access Management（IAM）、ロギング、モニタリング、セキュリティを提供する専用の Google Cloud プロジェクトです。このハブには次のコンポーネントが含まれています。
|
| テナント プロジェクト |
各テナント プロジェクトは、各ビジネス ユニット専用の Google Cloud プロジェクトです。個々のテナント プロジェクトは、次のコンポーネントを含む分離された環境です。
|
エージェント フロー
上記のアーキテクチャのマルチテナント システムの例には、次のフローがあります。
- ユーザーのリクエストは外部アプリケーション ロードバランサを介して転送されます。ルーティング ハブ内では、認証された安全なトラフィックのみがフロントエンド ポータルに到達するように、次のチェックが完了します。
- Cloud Armor は、セキュリティ ポリシーを適用して、初期のレイヤ 4 ネットワーク プロトコル ベースの分散型サービス拒否（DDoS）攻撃を吸収します。Cloud Armor はリクエストを検査し、SQL インジェクション（SQLi）、クロスサイト スクリプティング（XSS）、既知のボット シグネチャなどの悪意のあるトラフィックをフィルタします。
- Model Armor はペイロードをインターセプトし、プロンプト インジェクション攻撃や悪意のある意図を検出して拒否します。
- これらのレイヤのいずれかで脅威または不正アクセスが検出されると、ロードバランサはネットワーク エッジでリクエストをドロップします。
- セキュリティ レイヤで脅威が検出されず、ユーザーのアクセスが検証されると、ロードバランサはトラフィックをバックエンド サービスに転送します。
- リクエストがすべてのチェックに合格すると、ロードバランサはリクエストをフロントエンド プラットフォームに転送します。フロントエンド プラットフォームは次のアクションを実行します。
- ユーザーのビジネス ユニットやテナント ID などのユーザー ID を抽出します。
- IAP を使用して、ユーザーの企業 ID とデバイスの健全性を検証します。
- 動的に維持されるレジストリを使用して、正しいターゲット テナントを特定します。
- フロントエンド ポータルはリクエストをテナントに転送します。エージェントが他のテナント プロジェクトや承認されていない Google Cloudサービスにアクセスできないようにするため、Agent Runtime はプリンシパル アクセス境界ポリシーを使用して、エージェントがアクセスできるリソースを制限します。
- Model Armor は、Sensitive Data Protection を使用して、個人情報（PII）や制限付きコンテンツを検査し、動的にマスクします。Model Armor は、リクエストから不正なプロンプト インジェクションがないか追加のチェックを行い、エージェントが安全なデータのみを処理するようにします。
Gemini は、レスポンスを生成するために次のタスクを実行します。
- ユーザーの意図を理解するために、最初の推論パスを実行します。
- Gemini が特定の事実が不足していると判断した場合、テナントの特定のデータツールを呼び出すプランを生成します。
- ユーザーにデータリソースへのアクセス権があるかどうかを確認するために、エージェントはユーザーの ID と IAM ロール バインディングを検証します。
- コンテキストを取得するために、エージェントは MCP サーバーを介してテナント データストアにツール呼び出しを実行します。
- エージェントは、内部ロジックと新しく取得したテナント固有の事実を組み合わせて、グラウンディングされたレスポンスを作成します。
Gemini が追加の事実を必要としない場合、Gemini はレスポンスを生成し、そのレスポンスを Model Armor に送信します。
Model Armor は、個人情報（PII）または制限付きコンテンツを検査して動的にマスクし、サニタイズされたレスポンスをテナント エージェントに送信します。この最終検査により、出力に機密データが漏洩しないようにします。
レスポンスは、テナント エージェントからフロントエンド プラットフォーム、ロードバランサを経由してユーザーに返送されます。
使用するプロダクト
このリファレンス アーキテクチャでは、サーバーレス性、スケーラビリティ、セキュリティ機能に基づいて選択された次の Google Cloud プロダクトとオープンソース プロダクトおよびツールを使用します。
- VPC Service Controls: Google Cloud リソースのデータ引き出しのリスクを最小限に抑えるマネージド ネットワーキング機能。
- Cloud Load Balancing: 高パフォーマンスでスケーラブルなグローバル ロードバランサとリージョン ロードバランサのポートフォリオ。
- Google Cloud Armor: ウェブ アプリケーション ファイアウォール（WAF）ルールを提供し、DDoS 攻撃やアプリケーション攻撃から保護するネットワーク セキュリティ サービス。
- Model Armor: プロンプト インジェクション、センシティブ データの漏洩、有害なコンテンツから生成 AI とエージェント型 AI のリソースを保護するサービス。
- Identity-Aware Proxy（IAP）: アプリケーションと仮想マシンにゼロトラスト アクセスモデルを適用できるサービス。
- Identity and Access Management（IAM）: Google Cloud リソースに対する権限を作成して管理できるシステム。
- Cloud Run: Google のスケーラブルなインフラストラクチャ上でコンテナを直接実行できるマネージド コンピューティング プラットフォーム。
- Gemini Enterprise Agent Platform: エンタープライズ グレードの AI エージェントを構築、スケーリング、管理、最適化できる包括的なプラットフォーム。
- Gemini: Google が開発したマルチモーダル AI モデルのファミリー。
- Model Context Protocol（MCP）: AI アプリケーションを外部システムに接続するためのオープンソース規格。
- Cloud Logging: ストレージ、検索、分析、アラート機能を備えたリアルタイムのログ管理システム。
ユースケース
マルチテナント エージェント型 AI システムは、単一のアプリケーションを超えて生成 AI のデプロイをスケーリングしたい企業組織に適しています。このアーキテクチャに適したユースケースを特定するには、ビジネス プロセスを分析し、独自のツールやセンシティブ データにアクセスする独自の専門的な AI エージェントを必要とするさまざまなチームを特定します。このアプローチにより、分散型チームに自律型 AI 機能を付与しながら、統一されたセキュリティと企業コンプライアンスを維持できます。
マルチテナント エージェント型 AI システムのユースケースの例を次に示します。
全社的なカスタマー サービス
このリファレンス アーキテクチャを適応させて、異なる事業部門全体で AI を活用したカスタマー サービスを提供できます。たとえば、家電部門と家庭用品部門をサポートするために、家電エージェントと家庭用品エージェントを別々のテナント プロジェクトに 2 つの別々のエージェントとしてデプロイします。これらの専門的な AI エージェントは、独自の技術仕様、保証、返品ポリシーにアクセスして、部門固有のサポートに関する問い合わせを処理するインテリジェント アシスタントとして機能します。この自動化により、人間のサポートチームはより複雑な顧客のエスカレーションに集中できます。
このユースケースでは、このアーキテクチャには次のメリットがあります。
- 厳格なデータ分離: マルチテナント設計により、各部門のサポート知識が厳格に分離されます。PAB ポリシーは、一方のテナントのエージェント ID が他方のテナントのデータにアクセスできないようにするためのガードレールを提供します。
- 専門エージェントの知識: 各エージェントは分離されたテナント プロジェクトに存在するため、エージェントは部門固有のデータストアからのみコンテキストを取得します。このターゲットを絞った取得により、高い精度が確保され、エージェントが異なるビジネス ユニットのポリシーを混同するのを防ぐことができます。
- クロスドメイン リスクの軽減: このアーキテクチャは、ビジネス ユニット間のデータ漏洩のリスクを排除するのに役立ちます。エージェント ID が侵害されても、エージェントは承認されていない Google Cloud リソースにアクセスできません。
このアーキテクチャは、複数の異なるブランドや事業部門を管理し、厳格なデータ主権を必要とする大規模な小売組織や企業に最適です。
代替案を設計する
このセクションでは、 Google Cloudのマルチテナント エージェント型 AI デプロイで検討できる代替の設計アプローチについて説明します。
プライベート アクセスのデプロイ
このドキュメントで説明するアーキテクチャでは、ユーザーは、一元的に公開された外部アプリケーション ロードバランサを介して、公共のインターネット経由でマルチテナント エージェント型 AI システムにアクセスします。組織で公共のインターネットからアクセスできないシステムが必要な場合は、次のいずれかのプライベート アクセス戦略を使用するようにアーキテクチャを調整できます。
エッジ セキュリティ ポリシーを使用してトラフィックをブロックする
組織の確認済み企業 IP アドレスからのトラフィックのみを許可するには、他のトラフィックをすべて拒否するように Cloud Armor セキュリティ ポリシーを構成します。この優先度の高いセキュリティ ルールは、ネットワーク エッジで不正なリクエストをすべてブロックします。セキュリティを強化するには、IAP を使用して有効な企業 ID セッションを必須にしたり、すべてのユーザーに IAM 権限を構成したりできます。
このアプローチでは、Cloud Armor エッジ セキュリティ ポリシーを利用して、DDoS 緩和や WAF フィルタリング（SQLi や XSS など）をオフロードし、ゼロトラスト エクスペリエンスを実現できます。ただし、外部アプリケーション ロードバランサのフロントエンド IP アドレスはパブリックのままであり、一部の組織のコンプライアンス要件を満たしていない可能性があります。
内部アプリケーション ロードバランサを介してトラフィックをルーティングする
このドキュメントのアーキテクチャでは、外部アプリケーション ロードバランサを使用します。外部アプリケーション ロードバランサは、内部ロードバランサと比較して、堅牢な Cloud Armor ポリシー、より高度なセキュリティ機能、運用上の複雑さの軽減を実現します。ただし、外部ロードバランサを使用すると、トラフィックは公共のインターネットを通過します。
トラフィックを完全にプライベート Google ネットワーク内に維持するには、内部アプリケーション ロードバランサを使用します。内部アプリケーション ロードバランサを使用すると、ID 確認に IAP を使用できます。グローバル外部アプリケーション ロードバランサは、エッジレイヤで IAP ポリシーを評価します。一方、内部アプリケーション ロードバランサは、内部ネットワーク レイヤでポリシーを評価します。トラフィックが公共のインターネットを通過しないため、内部アプリケーション ロードバランサを使用すると、厳格なデータ主権とパブリック IP アドレスなしの要件を満たすことができます。
レイテンシを低く維持し、リージョンのデータ所在地の要件を遵守するには、各プライマリ リージョンにリージョン内部アプリケーション ロードバランサをデプロイします。リージョン内部アプリケーション ロードバランサを使用すると、オンプレミス環境からのトラフィックを Cloud Interconnect または Cloud VPN 経由でロードバランサの内部 IP アドレスに直接転送できます。リージョン内部アプリケーション ロードバランサは、内部 WAF 保護用のリージョン Cloud Armor をサポートします。ただし、外部アプリケーション ロードバランサと比較して、リージョン内部アプリケーション ロードバランサは、サポートする Cloud Armor セキュリティ ポリシーのセットが限られており、高度なセキュリティ機能がなく、運用上の複雑さが増します。
レイテンシをさらに最小限に抑え、障害復旧の要件を満たす高可用性を確保するには、クロスリージョン内部アプリケーション ロードバランサをデプロイします。クロスリージョン内部アプリケーション ロードバランサでは、Cloud DNS と位置情報ルーティング ポリシーを使用して、ユーザーに最も近いGoogle Cloud リージョンのクロスリージョン内部アプリケーション ロードバランサにアプリケーションの内部 URL を解決します。ただし、リージョン間の構成では Cloud Armor の統合はサポートされていません。
コンピューティング インフラストラクチャ
管理が容易で運用オーバーヘッドが少ないサーバーレス ファーストのアプローチを優先するため、このドキュメントのアーキテクチャでは、コンピューティング インフラストラクチャに Cloud Run を使用しています。GKE クラスタでコンテナ化されたアプリケーションを実行することもできます。Google Kubernetes Engine（GKE）は、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するコンテナ オーケストレーション エンジンです。GKE は、内部アプリケーション ロードバランサと外部アプリケーション ロードバランサの両方を完全にサポートしています。 Google Cloudのワークロードに適したコンピューティング サービスの選択方法については、Google Cloudでのアプリケーションのホスティングをご覧ください。
Model Context Protocol（MCP）サーバー
エージェント システムのコンポーネントが相互に作用できるようにするには、明確な通信プロトコルを確立する必要があります。MCP は、エージェントが必要なツール、データ、その他のサービスにアクセスして使用するための標準化されたインターフェースを提供するオープン プロトコルです。
テナント エージェントをデータストアに接続するには、アプリケーションの要件を考慮して、次の MCP サーバーのデプロイ オプションから選択します。ローカル MCP デプロイと共有 MCP デプロイのどちらかを選択する場合は、データの分離と運用効率のトレードオフを考慮してください。
ローカル MCP サーバー: ローカル MCP サーバーまたはテナント固有の MCP サーバーは、各テナント プロジェクト内にデプロイされ、そのビジネス ユニットに固有のデータストアとツールへのアクセスをエージェントに提供する MCP サーバーです。
ローカル MCP サーバーの主な機能と考慮事項は次のとおりです。
- ネットワーク: プロジェクト レベルの VPC Service Controls 境界と PAB ポリシーにより、固有のセキュリティと分離が提供され、テナント間のアクセスを確実に防止できます。
- 管理: 個々のデベロッパー チームと運用チームがテナント プロジェクトを個別に管理します。この分離により、各ビジネス ユニットに自律性が提供されます。
- セキュリティ: テナント プロジェクトの固定 IAM 境界により、横方向のリスク サーフェスを最小限に抑えることができ、複雑な ID マッピングは必要ありません。
ローカル MCP サーバーは最大限の分離を提供し、機密性の高いデータや規制対象のデータへのアクセスを処理できます。ただし、複数のローカル MCP サーバーをデプロイすると、運用負荷が増加します。機密情報が含まれる可能性のあるデータストアへのアクセスを制限する必要があるアプリケーションには、ローカル MCP サーバーをおすすめします。
共有 MCP サーバー: 共有 MCP サーバー（グローバル MCP サーバー）は、共有サービス プロジェクトにデプロイする MCP サーバーです。共有 MCP サーバーは、複数のテナントで共通のツールとシステムへのアクセスを提供します。
共有 MCP サーバーの主な機能と考慮事項は次のとおりです。
- ネットワーク: トラフィックがパブリック インターネットを通過しないように、共有 MCP サーバーには Private Service Connect や VPC ネットワーク ピアリングなどのプライベート接続が必要です。
- 管理: 一元化された運用チームが、システム全体の導入を管理します。この統合管理により、運用効率が最適化され、複数のテナント間でローカル実装を複製する必要がなくなります。
- セキュリティ: エンドユーザーの ID をテナント プロジェクトのエージェントから共有 MCP サーバーに安全に伝播します。ユーザーが許可されたデータのみにアクセスまたは変更できるように、共有 MCP サーバーは伝播されたユーザー ID を使用して、バックエンド システムにきめ細かいアクセス制御を適用します。
共有 MCP サーバーは、一般的なツールの管理を一元化し、重複を減らして運用効率を最適化します。共有 MCP サーバーは管理オーバーヘッドを削減しますが、安全なアクセスを維持するには、堅牢な ID 伝播と認可ロジックが必要です。経費報告ツール、人事（HR）システム、全社的なナレッジベース、出勤管理者など、一般的な企業システムやツールとのやり取りには、共有 MCP サーバーをおすすめします。
このアーキテクチャでは、MCP サーバーを使用して、テナント エージェントとデータストア間の接続を標準化します。ワークロードの要件に応じて、他のタイプのエージェント ツールを使用して、エージェントを特定の外部 API やシステムに接続することもできます。エージェント ツールのインタラクションの詳細については、エージェント ツールをご覧ください。
設計上の考慮事項
以降のセクションでは、このリファレンス アーキテクチャを使用して、セキュリティ、信頼性、費用、パフォーマンスに関する特定の要件を満たすトポロジを開発する際に考慮すべき設計要素、ベスト プラクティス、推奨事項について説明します。このセクションのガイダンスはすべてを網羅しているわけではありません。ワークロードの要件と、使用するプロダクトや機能によっては、考慮すべき追加の設計要素やトレードオフが存在する可能性があります。
セキュリティ、プライバシー、コンプライアンス
このセクションでは、ワークロードのセキュリティ、プライバシー、コンプライアンスの要件を満たす Google Cloud のトポロジを設計するための設計上の考慮事項と推奨事項について説明します。
| コンポーネント | 設計上の考慮事項と推奨事項 |
|---|---|
| Virtual Private Cloud（VPC） | テナントの分離: このアーキテクチャでは、各テナントを専用の Google Cloud プロジェクトにデプロイします。厳格なセキュリティ境界を作成するには、テナント プロジェクト レベルの分離と、組織レベルの PAB ポリシーおよび VPC Service Controls を組み合わせます。 |
| IAM | アクセス制御: 最小権限の原則を実装するには、ペルソナベースのアクセスモデルを使用します。たとえば、カスタム IAM ロールを定義して、あるテナントでエージェントを構築するデベロッパーが別のテナントのデータにアクセスできないようにすることができます。 |
| Cloud Armor |
エッジと内部の WAF 保護: Cloud Armor は、DDoS 攻撃やウェブの脆弱性からフロントエンド ポータルを保護するためのセキュリティと WAF 保護を提供します。グローバル外部アプリケーション ロードバランサは、ボット管理や Google Cloud Armor Adaptive Protection などの高度なエッジ機能のフルパッケージをサポートしています。 リージョン内部アプリケーション ロードバランサをデプロイすると、Cloud Armor は制限された一連の標準 WAF ポリシーで動作します。制限付きポリシー セットは、内部ネットワーク境界に合わせて調整されており、SQLi や XSS 保護などのポリシーが含まれています。詳細については、Cloud Armor と他の Google プロダクトの統合をご覧ください。 |
| Agent Platform | 共有モデル エンドポイント: 共有モデル エンドポイントの不正使用を防ぎ、公平な使用を確保するには、次のいずれかの方法を実装します。
|
| Cloud Run | コンテンツ レンダリング: フロントエンド ポータルのセキュリティ体制を強化するには、クライアントサイド レンダリング（CSR）よりもサーバーサイド レンダリング（SSR）を優先します。CSR と比較して、SSR には次の特典があります。
|
| Security Command Center | 一元化されたセキュリティ モニタリング: 脅威をモニタリングし、多要素認証（MFA）やデータ暗号化などのセキュリティ ポリシーを適用するには、Security Command Center のツールを使用します。 |
その他のセキュリティに関する推奨事項
信頼性
このセクションでは、 Google Cloudのデプロイ用に信頼性の高いインフラストラクチャを構築して運用するための設計上の考慮事項と推奨事項について説明します。
| コンポーネント | 設計上の考慮事項と推奨事項 |
|---|---|
| Cloud Load Balancing | グローバル ルーティング: グローバル外部アプリケーション ロードバランサは、単一の エニーキャスト IP アドレスを提供し、ユーザー トラフィックを地理的に最も近い Google エッジに自動的に転送します。この構成により、エッジ Secure Sockets Layer（SSL）終端処理によってレイテンシが短縮されます。また、リージョンで停止が発生した場合でも、トラフィックを正常なリージョン バックエンドにインテリジェントに再ルーティングするため、高可用性が確保されます。 |
| テナント | フォールト トレランス: エージェント レベルの障害を許容または処理するには、分離されたテナント プロジェクトにエージェントをデプロイします。この分離により、運用上の問題やセキュリティ インシデントが単一のビジネス ユニット内に留まり、他のリソースやビジネス ユニットに影響を与えないようにします。 |
| Agent Platform | 容量計画: モデルへのリクエスト数が割り当てられた容量を超えると、モデルはエラーコード 429 を返します。ビジネス クリティカルで常に高いスループットを必要とするワークロードの場合は、プロビジョンド スループットを使用してスループットを予約できます。 |
| エージェント ランタイム |
サーバーレスのスケーラビリティ: Agent Runtime にデプロイされたエージェントは、需要に基づいて個別にスケーリングされます。1 つのテナントでの使用量が急増しても、コンピューティング リソースが枯渇したり、別のテナント プロジェクトのエージェントの可用性に影響したりすることはありません。 エラー処理: エラーコード 429 のレート制限などの一時的なエラーを処理するために、エージェント オーケストレーション ロジックは指数バックオフを使用します。コンテキストの期限が切れると、エージェントは正常なシャットダウンを実行し、部分的な進行状況をユーザーに報告します。たとえば、ツール呼び出しの遅延、サードパーティ API のレイテンシ、大規模なデータセットの処理、コンピューティング負荷の高い処理などが原因で、コンテキストの期限が切れることがあります。 |
AI ワークロードと ML ワークロードに固有の信頼性の原則と推奨事項については、Well-Architected Framework の AI と ML の視点: 信頼性をご覧ください。
運用効率
このセクションでは、このリファレンス アーキテクチャを使用して、効率的に運用できる Google Cloud トポロジを設計する際に考慮すべき要素について説明します。
| コンポーネント | 設計上の考慮事項と推奨事項 |
|---|---|
| Google Cloud Observability | 一元化されたモニタリング: ロギングとモニタリングを使用すると、プラットフォーム全体の健全性とパフォーマンスをモニタリングできます。アラートを設定すると、センシティブ データへのアクセスを許可せずに、問題を事前に検出してトラブルシューティングできます。 |
| アーキテクチャのすべてのプロダクト | 標準化されたデプロイ: 標準化されたテナント アーキテクチャ パターン内で Agent Platform を使用すると、新しいテナントをオンボーディングするときに一貫したベースラインを確立できます。運用負荷を軽減するには、Terraform などの Infrastructure as Code（IaC）ツールを使用してデプロイ プロセスを自動化します。マルチテナント エージェント AI システムの構築とデプロイに使用できる Terraform コードについては、このドキュメントのデプロイをご覧ください。 |
AI ワークロードと ML ワークロードに固有のオペレーショナル エクセレンスの原則と推奨事項については、Well-Architected Framework の AI と ML の視点: 運用の卓越性をご覧ください。
費用の最適化
このセクションでは、このリファレンス アーキテクチャを使用して構築した Google Cloud トポロジの設定と運用の費用を最適化するためのガイダンスを示します。
| コンポーネント | 設計上の考慮事項と推奨事項 |
|---|---|
| Agent Platform |
トークンの消費量: 費用を管理し、AI モデルがコンテキスト ウィンドウを超えないようにするには、次の戦略を使用して AI モデルのコンテキストを管理します。
モデル エンドポイント: API の割り当てとリソース使用率を管理するには、専用構成または共有構成のいずれかで Agent Platform エンドポイントをデプロイします。
Agent Platform の費用については、Agent Platform での AI モデルの構築とデプロイの費用をご覧ください。 |
| Cloud Run | 計測: 計測を使用すると、パフォーマンスのモニタリング、問題のトラブルシューティング、各テナントのリソース使用量の追跡を行うことができます。リクエストごとにテナントを識別するには、IAP が提供するコンテキストからユーザー ID を抽出します。アプリケーションを計測可能にする方法については、計測方法を選択するをご覧ください。 |
| Model Armor | 一元化されたプロンプト フィルタリング: 厳格なガバナンスとゼロトラストの姿勢を適用するために、このアーキテクチャでは、ルーティング ハブと各テナント プロジェクトの 2 つのレイヤに Model Armor をデプロイします。この 2 層アプローチはデータ主権の確保に役立ちますが、レイテンシと運用コストが増加します。費用とシステムの複雑さを軽減するため、Model Armor をルーティング ハブにのみデプロイして、すべてのプロンプトとレスポンスをフィルタします。 |
| アーキテクチャのすべてのプロダクト |
共有インフラストラクチャ: フロントエンド ポータル、中央ガバナンスとセキュリティ ハブ、Agent Platform などの共有コア インフラストラクチャ コンポーネントを使用すると、エージェントごとに個別のカスタム スタックを構築する場合と比較して、コストを削減できます。 プラットフォームのオーバーヘッド: 中央のガバナンスとセキュリティ ハブの共有費用を分配するには、追跡機能と使用パターンに合った割り当てモデルを使用します。次のいずれかの費用配分モデルを使用することをおすすめします。
共有サービスの費用を割り当てる方法の詳細については、Cloud FinOps: 共有サービスの費用割り当てをご覧ください。 一元的な費用管理: エージェント型 AI システムの総所有コスト（TCO）を正確に追跡し、費用を個々のビジネス ユニットに割り当てるには、ラベルと Cloud Billing エクスポート データを使用します。費用意識を高めるためにラベルを使用する方法については、費用意識の文化を育むをご覧ください。 |
Google Cloud リソースの費用を見積もるには、Google Cloud の料金計算ツールを使用します。
AI ワークロードと ML ワークロードに固有の費用最適化の原則と推奨事項については、Well-Architected Framework の AI と ML の視点: 費用の最適化をご覧ください。
デプロイ
このリファレンス アーキテクチャをデプロイするには、GitHub で入手できるマルチテナント エージェント AI Terraform の例を使用します。
次のステップ
- Agent Platform で ADK と Agents CLI を使用してエージェントを構築する方法の詳細を確認する。
- Agent Platform リモート MCP サーバーを使用する方法を確認する。
- VPC Service Controls の有効化に関するベスト プラクティスを確認する。
- Agent Runtime でデプロイされたエージェントを管理する方法を学習する。
- スケーリングと高トラフィックのベスト プラクティスを確認する。
- ジャストインタイム昇格戦略を実装するには、Privileged Access Manager の使用方法を確認します。
- Google Cloudの AI ワークロードと ML ワークロードに固有のアーキテクチャ原則と推奨事項の概要について、Well-Architected Framework の AI と ML の視点を確認する。
- Cloud アーキテクチャ センターで、リファレンス アーキテクチャ、図、ベスト プラクティスを確認する。
寄稿者
著者:
- Shivank Awasthi | フィールド ソリューション アーキテクト
- Utkarsh Bhardwaj | テクニカル ソリューション コンサルタント、エージェント型 AI、AI アプリ、クラウド プラットフォーム、インフラストラクチャ
その他の寄稿者:
- Adrian Corona | セキュリティ担当グローバル サービス デリバリー マネージャー
- Agnieszka Kołkiewicz | GSD AI マネージャー
- Anmol Sachdeva | 広告ソリューション エンジニア、グローバル ビジネス
- Ashish Agarwal | EMEA 北部担当リード、グローバル サービス デリバリー
- Ashmita Kapoor | JAPAC GenAI FSA、Applied AI CE マネージャー
- Ashutosh Gupta | グローバル サービス デリバリー担当ディレクター
- Aspen Sherrill | クラウド セキュリティ アーキテクト
- Chinmay Deshpande | クラウド移行コンサルタント、インフラストラクチャ
- EMEA South Infra、Data、AI、GDC Delivery Lead | Gaurav Taneja
- Ishmeet Mehta | 北米プラットフォーム スペシャリスト、アプリ CE
- Joanna Nowek | AI Transformation Consultant
- Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー
- Mark Schlagenhauf | テクニカル ライター、ネットワーキング
- Matthias Ziener | グローバル サービス デリバリー担当マネージャー
- Olu Akinrolabu | セキュリティ クラウド コンサルタント
- Paweł Tokarski | EMEA South Infra、Data、AI、GDC Delivery Lead
- Paweł Glica | Core EMEA Practise Lead
- Prabha Arya | 戦略的クラウド エンジニア
- Samantha He | テクニカル ライター
- Suchit Puri | グローバル AI プラクティス リード
- delta AI 担当ディレクター | Thomas Cliett
- Valentín Huerta | AI エンジニア