マルチテナント エージェント型 AI システム

Last reviewed 2026-10-16 UTC

このドキュメントでは、 Google Cloudでマルチテナント エージェント型 AI システムを設計してデプロイする際に役立つリファレンス アーキテクチャについて説明します。組織が生成 AI のデプロイを拡大するにつれて、さまざまなビジネス ユニットが、独自のツールにアクセスし、特定の運用ルールに従い、機密データを処理する、専用の AI エージェントを必要とするようになります。ビジネス ユニットが組織内で断片化されたアプリケーション サイロを開発すると、運用上のオーバーヘッドが高くなり、ガバナンスに重大なギャップが生じ、データ漏洩のリスクが生じる可能性があります。このアーキテクチャでは、統合されたセキュリティとコンプライアンスを維持しながら、自律型 AI 機能を備えた分散型チームを強化できる一元化されたシステムを構築する方法について説明します。

このドキュメントは、クラウドでエンタープライズ グレードのマルチエージェント システムを構築して管理するアーキテクト、デベロッパー、管理者を対象としています。このドキュメントは、AI、ML、LLM のコンセプト、エージェント型 AI に関する基本的な知識があることを前提としています。

このドキュメントのデプロイ セクションでは、マルチテナント エージェント型 AI システムの構築とデプロイに役立つ実装戦略について説明します。

アーキテクチャ

次の図は、ハブアンドスポーク モデルに従ったマルチテナント エージェント AI システムのアーキテクチャを示しています。ハブアンドスポーク モデルは、ハブと呼ばれる中央環境が、スポークと呼ばれる複数の分離された環境に接続するネットワーク設計です。

マルチテナント エージェント型 AI システムを示すアーキテクチャ。

このアーキテクチャは、次のコンポーネントで構成されています。

VPC Service Controls
このアーキテクチャでは、VPC Service Controls を使用して、組織レベルでサービス境界を構成します。このサービス境界は厳格なセキュリティ境界を提供し、データの引き出しを防ぐのに役立ちます。
ルーティング ハブ

ルーティング ハブは、アーキテクチャの中心的な上り（内向き）ポイントとして機能し、次のコンポーネントが含まれています。

  • 外部アプリケーション ロードバランサ: 外部ユーザーまたは内部ユーザーの一元的な上り（内向き）ポイントとして機能します。ロードバランサは、認証された安全なトラフィックのみがフロントエンド ポータルに到達するようにします。
  • Google Cloud Armor と Model Armor: ロードバランサは Cloud Armor と Model Armor を統合して、ネットワーク エッジで悪意のあるプロンプトを検査してスクラブします。ルーティング ハブは、外部アプリケーション ロードバランサで Service Extensions を使用して、Model Armor をリクエスト フローに直接統合します。
  • Identity-Aware Proxy（IAP）: ゼロトラスト モデルを適用して、リクエストがアプリケーションに到達する前にユーザー ID とコンテキストを検証します。
  • フロントエンド ポータル: リクエストを適切な分離されたテナント プロジェクトにルーティングするルーティング エンジンとして機能するサーバーレス Cloud Run アプリケーション。
一元化されたガバナンスとセキュリティ ハブ

一元的なガバナンスとセキュリティ ハブは、プラットフォーム全体に一元的な Identity and Access Management（IAM）、ロギング、モニタリング、セキュリティを提供する専用の Google Cloudプロジェクトです。このハブには、次のコンポーネントが含まれています。

  • Security Command Center: マルチテナント エージェント型 AI システム全体をモニタリングしてセキュリティ リスクを検出するサービス。
  • IAM: 共有ハブとテナント プロジェクト全体で ID と権限を管理するアクセス制御フレームワーク。このコンポーネントは、すべての人間とマシンの ID を一元的に管理します。
  • Cloud Logging: 共有ハブと分離されたテナント プロジェクトのログを中央のガバナンスとセキュリティ ハブに集約するシステム。
テナント プロジェクト

各テナント プロジェクトは、各ビジネス ユニット専用の Google Cloud プロジェクトです。個々のテナント プロジェクトは、次のコンポーネントを含む分離された環境です。

  • プリンシパル アクセス境界ポリシー（PAB ポリシー）: PAB ポリシーは、異なるビジネス ユニット間で内部のハードな分離を提供し、プリンシパルが承認された境界内のリソースにのみアクセスできるようにします。
  • Gemini Enterprise Agent Platform の Agent Runtime: 特定のビジネス ユニット エージェントをホストし、Agent Development Kit（ADK）を使用して構築したカスタム オーケストレーション コードを実行するランタイム。
  • Model Armor: 悪意のあるプロンプトとレスポンスを検査してフィルタリングするマネージド セキュリティ サービス。プロンプト インジェクション攻撃などの脅威から、テナントのエージェントとコンピューティング リソースを保護します。
  • Model Context Protocol（MCP）サーバー: MCP サーバーは、テナント エージェントとテナント データストア間のアクセスを容易にします。
  • テナント データストア: 特定のビジネス ユニットのデータを保存する専用のデータ リポジトリ（BigQuery や AlloyDB for PostgreSQL など）。エージェントは、検索拡張生成（RAG）を実行して、データストアのコンテキストに基づいてより正確なレスポンスを生成します。厳格なデータ主権を維持するため、このデータにアクセスできるのはテナント エージェントのみです。
  • Gemini モデル: 推論サービングの場合、このサンプル アーキテクチャのエージェントは、Gemini Enterprise Agent Platform で最新の Gemini モデルを使用します。

エージェント フロー

上記のアーキテクチャのマルチテナント システムの例では、次のフローがあります。

  1. ユーザーのリクエストは、外部アプリケーション ロードバランサを介してルーティングされます。ルーティング ハブ内では、認証された安全なトラフィックのみがフロントエンド ポータルに到達するように、次のチェックが完了しています。
    1. Cloud Armor は、セキュリティ ポリシーを適用して、最初のレイヤ 4 ネットワーキング プロトコルベースの分散型サービス拒否（DDoS）攻撃を吸収します。Cloud Armor はリクエストを検査し、SQL インジェクション（SQLi）、クロスサイト スクリプティング（XSS）、既知の bot シグネチャなどの悪意のあるトラフィックをフィルタします。
    2. Model Armor はペイロードをインターセプトして、プロンプト インジェクション攻撃や悪意のある意図を検出して拒否します。
    3. これらのレイヤのいずれかが脅威または不正アクセスを検出すると、ロードバランサはネットワーク エッジでリクエストをドロップします。
    4. セキュリティ レイヤで脅威が検出されず、ユーザーのアクセスが検証されると、ロードバランサはトラフィックをバックエンド サービスにルーティングします。
  2. リクエストがすべてのチェックに合格すると、ロードバランサはリクエストをフロントエンド プラットフォームにルーティングします。フロントエンド プラットフォームは次のアクションを実行します。
    1. ユーザーのビジネス ユニットやテナント ID などのユーザーの ID を抽出します。
    2. IAP を使用して、ユーザーの企業 ID とデバイスの状態を確認します。
    3. 動的に管理されるレジストリを使用して、正しいターゲット テナントを識別します。
  3. フロントエンド ポータルは、リクエストをテナントに転送します。エージェントが他のテナント プロジェクトや認可されていない Google Cloudサービスにアクセスできないように、Agent Runtime はプリンシパル アクセス境界ポリシーを使用して、エージェントがアクセスできるリソースを制限します。
  4. Model Armor は、Sensitive Data Protection を使用して、個人を特定できる情報（PII）や制限されているコンテンツを検査し、動的にマスクします。Model Armor は、リクエストから悪意のあるプロンプト インジェクションがないか追加のチェックを行い、エージェントが安全なデータのみを処理するようにします。

  5. Gemini は次のタスクを実行してレスポンスを生成します。

    1. 最初の推論パスを実行して、ユーザーの意図を理解します。
    2. Gemini が特定の事実が不足していると判断すると、テナントの特定のデータツールを呼び出すプランを生成します。
      1. ユーザーにデータリソースへのアクセス権があるかどうかを確認するため、エージェントはユーザーの ID と IAM ロール バインディングを確認します。
      2. コンテキストを取得するために、エージェントは MCP サーバーを介してテナント データストアにツール呼び出しを実行します。
      3. エージェントは、内部ロジックと、新しく取得したテナント固有の事実を組み合わせて、グラウンディングされたレスポンスを作成します。

    Gemini が追加の事実を必要としない場合は、レスポンスを生成して Model Armor に送信します。

  6. Model Armor は、PII や制限付きコンテンツを検査して動的にマスクし、サニタイズされたレスポンスをテナント エージェントに送信します。この最終検査により、出力に機密データが漏洩しないようにできます。

  7. レスポンスは、テナント エージェントからフロントエンド プラットフォーム、ロードバランサを介してユーザーにルーティングされます。

使用するプロダクト

このリファレンス アーキテクチャでは、サーバーレスの性質、スケーラビリティ、セキュリティ機能を考慮して、次の 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 エージェントは、独自の技術仕様、保証、返品に関するポリシーにアクセスして、部門固有のサポートに関する問い合わせに対応するインテリジェントなアシスタントとして機能します。この自動化により、人間のサポートチームはより複雑な顧客のエスカレーションに集中できます。

このユースケースでは、このアーキテクチャに次のメリットがあります。

  • 厳格なデータ分離: マルチテナント設計により、各部門のサポート ナレッジが厳格に分離されます。プリンシパル アクセス境界ポリシーは、あるテナントの Agent Identity が別のテナントのデータにアクセスできないようにするガードレールを提供します。
  • 専門的なエージェントの知識: 各エージェントは分離されたテナント プロジェクトに存在するため、エージェントは部門固有のデータストアからのみコンテキストを取得します。このターゲットを絞った取得により、精度が向上し、エージェントが異なるビジネス ユニットのポリシーを混同するのを防ぐことができます。
  • クロスドメイン リスクの低減: このアーキテクチャは、ビジネス ユニット間でデータが漏洩するリスクを排除するのに役立ちます。エージェント ID が侵害された場合でも、エージェントは認可されていない Google Cloud リソースにアクセスできません。

このアーキテクチャは、複数の異なるブランドやビジネス ユニットを管理し、厳格なデータ主権を必要とする大規模な小売組織や企業に最適です。

代替案を設計する

このセクションでは、 Google Cloudのマルチテナント エージェント型 AI デプロイで検討できる代替の設計アプローチについて説明します。

プライベート アクセスのデプロイ

このドキュメントで説明するアーキテクチャでは、ユーザーは、一元的に公開された外部アプリケーション ロードバランサを介して、公共のインターネット経由でマルチテナント エージェント型 AI システムにアクセスします。組織で公共のインターネットからアクセスできないシステムが必要な場合は、次のいずれかのプライベート アクセス戦略を使用するようにアーキテクチャを適応させることができます。

エッジ セキュリティ ポリシーを使用してトラフィックをブロックする

組織の検証済みの企業 IP アドレスからのトラフィックのみを許可するには、他のトラフィックを拒否するように Cloud Armor セキュリティ ポリシーを構成します。この優先度の高いセキュリティ ルールは、ネットワーク エッジですべての不正なリクエストをブロックします。セキュリティを強化するには、IAP を使用して有効な企業 ID セッションを要求し、すべてのユーザーに IAM 権限を構成します。

このアプローチでは、Cloud Armor エッジ セキュリティ ポリシーを利用して、DDoS 緩和策と WAF フィルタリング（SQLi や XSS など）をオフロードし、ゼロトラスト エクスペリエンスを提供できます。ただし、外部アプリケーション ロードバランサのフロントエンド IP アドレスは公開されたままであり、一部の組織のコンプライアンス要件を満たしていない可能性があります。

内部アプリケーション ロードバランサを介してトラフィックをルーティングする

このドキュメントのアーキテクチャでは、外部アプリケーション ロードバランサを使用します。これにより、内部ロードバランサと比較して、堅牢な Cloud Armor ポリシー、より高度なセキュリティ機能、運用の複雑さの軽減が実現します。ただし、外部ロードバランサを使用すると、トラフィックが公共のインターネットを通過することになります。

トラフィックを Google のプライベート ネットワーク内に完全に維持するには、内部アプリケーション ロードバランサを使用します。内部アプリケーション ロードバランサを使用すると、本人確認に IAP がサポートされます。グローバル外部アプリケーション ロードバランサは、エッジレイヤで IAP ポリシーを評価します。一方、内部アプリケーション ロードバランサは、内部ネットワーク レイヤでポリシーを評価します。トラフィックが公共のインターネットを通過しないため、内部アプリケーション ロードバランサを使用すると、厳格なデータ主権とゼロパブリック IP アドレスの要件を満たすことができます。

低レイテンシを維持し、リージョンのデータ所在地の要件を遵守するには、各プライマリ リージョンにリージョン内部アプリケーション ロードバランサをデプロイします。リージョン内部アプリケーション ロードバランサを使用すると、Cloud Interconnect または Cloud VPN を介してオンプレミス環境からロードバランサの内部 IP アドレスにトラフィックを直接ルーティングできます。リージョン内部アプリケーション ロードバランサは、内部 WAF 保護用のリージョン Cloud Armor をサポートしています。ただし、外部アプリケーション ロードバランサと比較すると、リージョン内部アプリケーション ロードバランサは、サポートする Cloud Armor セキュリティ ポリシーのセットが限られており、高度なセキュリティ機能がなく、運用の複雑さが増します。

レイテンシをさらに短縮し、障害復旧要件を満たす高可用性を確保するには、クロスリージョン内部アプリケーション ロードバランサをデプロイします。クロスリージョン内部アプリケーション ロードバランサでは、Cloud DNS と位置情報ルーティング ポリシーを使用して、アプリケーションの内部 URL を、ユーザーに最も近いGoogle Cloud リージョンのクロスリージョン内部アプリケーション ロードバランサに解決します。ただし、クロスリージョン構成では Cloud Armor の統合はサポートされていません。

コンピューティング インフラストラクチャ

管理が容易で運用オーバーヘッドが少ないサーバーレス ファーストのアプローチを優先するため、このドキュメントのアーキテクチャでは、コンピューティング インフラストラクチャに Cloud Run を使用しています。GKE クラスタでコンテナ化されたアプリケーションを実行することもできます。Google Kubernetes Engine（GKE）は、コンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するコンテナ オーケストレーション エンジンです。GKE は、内部と外部の両方のアプリケーション ロードバランサを完全にサポートしています。 Google Cloudのワークロードに適したコンピューティング サービスを選択する方法については、Google Cloudでのアプリケーションのホスティングをご覧ください。

ローカル MCP サーバーと共有 MCP サーバー

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

テナント エージェントをデータストアに接続するには、アプリケーションの要件を考慮して、次の MCP サーバーのデプロイ オプションから選択します。ローカル MCP デプロイと共有 MCP デプロイのどちらかを選択する場合は、データ分離と運用効率のトレードオフを考慮してください。

  • ローカル MCP サーバー: ローカル MCP サーバー（またはテナント固有の MCP サーバー）は、各テナント プロジェクト内にデプロイする MCP サーバーです。このサーバーは、そのビジネス ユニットに固有のデータストアとツールへのアクセスをエージェントに提供します。

    ローカル MCP サーバーの主な機能と考慮事項は次のとおりです。

    • ネットワーク: プロジェクト レベルの VPC Service Controls 境界とプリンシパル アクセス境界ポリシーにより、固有のセキュリティと分離が実現され、テナント間のアクセスを防止できます。
    • 管理: 個々のデベロッパー チームと運用チームがテナント プロジェクトを個別に管理します。この分離により、各ビジネス ユニットに自律性が提供されます。
    • セキュリティ: テナント プロジェクトの固定された IAM 境界により、横方向のリスク サーフェスを最小限に抑えることができます。また、複雑な ID マッピングは必要ありません。

    ローカル MCP サーバーは、最大限の分離を実現し、機密性の高いデータや規制対象のデータへのアクセスを処理できます。ただし、複数のローカル MCP サーバーをデプロイすると、運用負荷が増加します。機密情報を含む可能性のあるデータストアへのアクセスを制限する必要があるアプリケーションには、ローカル MCP サーバーをおすすめします。

  • 共有 MCP サーバー: 共有 MCP サーバー（グローバル MCP サーバー）は、共有サービス プロジェクトにデプロイする MCP サーバーです。共有 MCP サーバーは、複数のテナントに共通するツールやシステムへのアクセスを提供します。

    共有 MCP サーバーの主な機能と考慮事項は次のとおりです。

    • ネットワーク: トラフィックが公共のインターネットを通過しないように、共有 MCP サーバーには Private Service Connect や VPC ネットワーク ピアリングなどのプライベート接続が必要です。
    • 管理: 一元化された運用チームがシステム全体の実装を管理します。この統合管理により、運用効率が最適化され、複数のテナント間でローカル実装を複製する必要がなくなります。
    • セキュリティ: テナント プロジェクトのエージェントから共有 MCP サーバーにエンドユーザー ID を安全に伝播します。ユーザーがアクセスまたは変更できるデータを、許可されたデータのみに制限するため、共有 MCP サーバーは、伝播されたユーザー ID を使用して、バックエンド システムできめ細かいアクセス制御を適用します。

    共有 MCP サーバーは、一般的なツールの管理を一元化することで、重複を減らし、運用効率を最適化します。共有 MCP サーバーは管理オーバーヘッドを削減しますが、安全なアクセスを維持するには、堅牢な ID 伝播と認可ロジックが必要です。共有 MCP サーバーは、経費報告ツール、人事（HR）システム、全社的なナレッジベース、勤怠管理システムなど、一般的な企業システムやツールとのやり取りにおすすめです。

このアーキテクチャでは、MCP サーバーを使用して、テナント エージェントとデータストア間の接続を標準化します。ワークロードの要件によっては、他のタイプのエージェント ツールを使用して、エージェントを特定の外部 API やシステムに接続することもできます。エージェント ツールのインタラクションの詳細については、エージェント ツールをご覧ください。

設計上の考慮事項

以下のセクションでは、このリファレンス アーキテクチャを使用して、セキュリティ、信頼性、費用、パフォーマンスに関する特定の要件を満たすトポロジを開発する際に考慮すべき設計要素、ベスト プラクティス、推奨事項について説明します。このセクションのガイダンスはすべてを網羅しているわけではありません。ワークロードの要件と、使用するプロダクトや機能によっては、考慮すべき追加の設計要素やトレードオフが存在する可能性があります。

セキュリティ、プライバシー、コンプライアンス

このセクションでは、ワークロードのセキュリティ、プライバシー、コンプライアンスの要件を満たす Google Cloud のトポロジを設計するための設計上の考慮事項と推奨事項について説明します。

エージェントのセキュリティに関する考慮事項

AI エージェントは、従来の決定論的なセキュリティ対策では適切に軽減できない、特有の重大なセキュリティ リスクをもたらします。Google は、決定論的なセキュリティ管理の強みと、動的な推論ベースの防御を組み合わせた、安全な AI エージェントのアプローチを推奨しています。このアプローチは、人間による監視、慎重に定義されたエージェントの自律性、オブザーバビリティという 3 つの基本原則に基づいています。これらの基本原則に沿った具体的な推奨事項は次のとおりです。

  • 人間の監視: エージェント型 AI システムは、失敗したり、想定どおりに動作しなかったりすることがあります。たとえば、モデルが不正確なコンテンツを生成したり、エージェントが不適切なツールを選択したりする可能性があります。ビジネス クリティカルなエージェント型 AI システムでは、人間参加型のフローを組み込んで、人間の監督者がエージェントをモニタリング、オーバーライド、一時停止できるようにします。たとえば、人間のユーザーは、エージェントの出力を確認し、出力を承認または拒否して、エラーの修正や戦略的な意思決定を行うためのガイダンスを提供できます。このアプローチでは、エージェント型 AI システムの効率性と、人間のユーザーの批判的思考とドメイン専門知識を組み合わせます。
  • エージェント ID と最小権限アクセス:
    • Agent Identity を使用して、各エージェントにワークロードにバインドされた SPIFFE ベースの ID を提供します。Agent Identity は、エージェントを Agent Runtime または Cloud Run にデプロイするときに使用できます。
    • IAM アクセス ポリシーと IAM を使用した Agent Platform のアクセス制御を使用して、エージェントごとの権限を構成します。各エージェントには、タスクの実行、ツールや他のエージェントとの通信に必要な権限のみを付与します。各エージェントをさらに分離し、セキュリティ侵害による潜在的な影響を制限するには、プリンシパル アクセス境界ポリシーをエージェント ID にバインドします。
    • エージェントが外部ツールまたはサードパーティ API に対する認証を行う必要がある場合は、Agent Identity Auth Manager を使用します。このアプローチでは、エージェント コードやプロンプトに認証情報を埋め込む必要がなく、OAuth トークンと API キーを一元管理できます。

  • 上り（内向き）と下り（外向き）のトラフィック ガバナンス: エージェント トラフィックを Agent Gateway 経由でルーティングし、上り（内向き）と下り（外向き）の両方の境界でランタイム セキュリティ ポリシーを適用します。Agent Gateway をサポートする Agent Runtime プラットフォームについては、サポートされている Agent Runtimeをご覧ください。

    • クライアントからエージェントへ（内向き）: Agent Runtime の前に Agent Gateway をデプロイします。ゲートウェイは、Model Armor を使用して、呼び出し元を認証し、インバウンド プロンプトをリアルタイムで検査します。

    • エージェントから任意の宛先へ（外向き）:

      • 外向きモードの Agent Gateway を介して、アウトバウンドのエージェント間（A2A）リクエストとエージェントからツール（MCP）へのリクエストをルーティングします。
      • IAM アクセス ポリシーと IAP を使用して、デフォルト拒否のアクセス ポリシーを適用します。
      • ターゲット エージェントとツールが Agent Registry に登録されていることを確認します。
      • Model Armor を使用して、アウトバウンド ツールの呼び出しとレスポンスを検査し、データ引き出し、間接的なプロンプト インジェクション、ツールの不正使用を防止します。

  • モニタリング: 包括的なトレース機能を使用して、エージェントの動作をモニタリングします。これにより、推論プロセス、ツールの選択、実行パスなど、エージェントが実行するすべてのアクションを可視化できます。詳細については、Agent Runtime でのエージェントのロギングと ADK でのロギングをご覧ください。

AI エージェントの保護の詳細については、AI エージェントの安全性とセキュリティをご覧ください。

Virtual Private Cloud（VPC）のセキュリティに関する考慮事項

このアーキテクチャでは、各テナントを専用のGoogle Cloud プロジェクトにデプロイします。厳格なセキュリティ境界を作成するには、テナント プロジェクト レベルの分離と、組織レベルのプリンシパル アクセス境界ポリシーおよび VPC Service Controls を組み合わせます。

IAM セキュリティに関する考慮事項

最小権限の原則を実装するには、ペルソナベースのアクセスモデルを使用します。たとえば、カスタム IAM ロールを定義して、あるテナントでエージェントを構築するデベロッパーが別のテナントのデータにアクセスできないようにできます。

Cloud Armor のセキュリティに関する考慮事項

Cloud Armor は、フロントエンド ポータルを DDoS 攻撃やウェブの脆弱性から保護するセキュリティと WAF 保護を提供します。グローバル外部アプリケーション ロードバランサは、bot 管理や Google Cloud Armor 適応型保護など、高度なエッジ機能のフルスイートをサポートしています。

リージョン内部アプリケーション ロードバランサをデプロイすると、Cloud Armor は制限された標準 WAF ポリシーのセットで動作します。制限付きのポリシーセットは、内部ネットワーク境界に合わせて調整されており、SQLi や XSS 保護などのポリシーが含まれています。詳細については、Cloud Armor と他の Google プロダクトの統合をご覧ください。

Agent Platform のセキュリティに関する考慮事項

Agent Platform の構成と使用がセキュリティ要件を満たすようにするには、次の推奨事項を考慮してください。

  • 責任の共有: セキュリティは責任の共有です。Agent Platform は基盤となるインフラストラクチャを保護し、データ、コード、モデルを保護するためのツールとセキュリティ管理を提供します。サービスを適切に構成し、アクセス制御を管理して、アプリケーションを保護することは、お客様の責任で行っていただきます。詳細については、Agent Platform の責任の共有をご覧ください。
  • セキュリティ管理: Agent Platform は、データ所在地、顧客管理の暗号鍵（CMEK）、VPC Service Controls を使用したネットワーク セキュリティ、アクセスの透明性の要件を満たすために使用できる Google Cloud セキュリティ管理をサポートしています。詳細については、以下のドキュメントをご覧ください。
  • 安全性: AI モデルは、悪意のあるプロンプトに応じて有害な回答を生成することがあります。
    • 安全性を強化し、エージェント型 AI システムの不正使用の可能性を軽減するには、有害な入力やレスポンスに対するバリアとして機能するようにコンテンツ フィルタを構成します。詳細については、安全フィルタとコンテンツ フィルタをご覧ください。
    • 推論リクエスト、エージェント プロンプト、ツール呼び出し、レスポンスを検査して、プロンプト インジェクションや有害なコンテンツなどの脅威をサニタイズするには、直接モデル API 呼び出しに Model Armor を使用し、Agent Gateway を介してルーティングされるリクエストに を使用します。Model Armor を使用すると、悪意のある入力の防止、コンテンツの安全性の検証、機密データの保護、コンプライアンスの維持、安全性とセキュリティ ポリシーの一貫した適用が可能になります。
  • モデルへのアクセス: 組織のポリシーを設定して、 Google Cloud プロジェクトで使用できる AI モデルのタイプとバージョンを制限できます。詳細については、Model Garden モデルへのアクセスを制御するをご覧ください。
  • データ保護: プロンプトとレスポンス、ログデータ内の機密データを検出して匿名化するには、Cloud Data Loss Prevention API を使用します。詳細については、AI アプリでの機密データの保護をご覧ください。

  • 共有モデル エンドポイント: 共有モデル エンドポイントの不正使用を防止し、公平な使用を確保するには、次のいずれかの戦略を実装します。

    • テナントレベルのレート制限: リクエストが共有エンドポイントに到達する前に、各テナントのフロントエンド ポータルで割り当てを適用します。割り当てを適用するには、次の操作を行います。

      1. IAP コンテキストからテナント ID を抽出します。
      2. Memorystore for Redis などの外部ストアを使用して、各テナントの事前定義された上限に対する使用量を追跡します。
      3. 上限を超えるテナントからのリクエストを拒否する。

    • API Gateway: API キーと使用量プランを使用してテナントごとの割り当てを適用するには、共有エンドポイントの前に API Gateway を実装します。

MCP のセキュリティに関する考慮事項

MCP の実装がセキュリティ要件を満たすように、次の推奨事項を検討してください。

  • ツールの登録と検出: MCP サーバーとツールを Agent Registry に登録して、エージェントがインベントリに登録され、管理者が承認した MCP エンドポイントにのみ接続するようにします。
  • アクセス制御とトラフィック検査: エージェントから MCP へのトラフィックを Agent-to-Anywhere（外向き）モードの Agent Gateway 経由でルーティングし、IAP と IAM アクセス ポリシーを使用して MCP サーバー（Cloud Run でホストされている MCP サーバーなど）を保護します。Agent Gateway で Model Armor またはセマンティック ガバナンス ポリシーを構成して、MCP ツールの入出力を検査し、機密データの漏洩や間接的なプロンプト インジェクションを検出します。
  • 一般的な MCP セキュリティ: MCP を使用するようにエージェントを構成する場合は、外部データとツールへのアクセスが認可されていることを確認し、暗号化などのプライバシー管理を実装します。また、機密データを保護するフィルタを適用し、エージェントのインタラクションをモニタリングします。詳細については、MCP とセキュリティをご覧ください。

Cloud Run のセキュリティに関する考慮事項

フロントエンド ポータルのセキュリティ ポスチャーを強化するには、クライアントサイド レンダリング（CSR）よりもサーバーサイド レンダリング（SSR）を優先します。CSR と比較すると、SSR には次のようなメリットがあります。

  • 制御されたGoogle Cloud 環境内でアプリケーション ロジックを実行し、シークレットを管理します。
  • クライアントサイドの攻撃対象領域を減らし、ユーザーの信頼できないブラウザへの機密データの漏洩を防ぐ。
  • 必要な HTML のみをクライアントに送信することで、データの露出を制限します。
  • クロスサイト スクリプティング（XSS）攻撃から保護するための一元化された出力エンコードを提供します。

Security Command Center のセキュリティに関する考慮事項

脅威をモニタリングし、多要素認証（MFA）やデータ暗号化などのセキュリティ ポリシーを適用するには、Security Command Center のツールを使用します。

セキュリティに関するその他の推奨事項

信頼性

このセクションでは、 Google Cloudのデプロイ用に信頼性の高いインフラストラクチャを構築して運用するための設計上の考慮事項と推奨事項について説明します。

Cloud Load Balancing の信頼性に関する考慮事項

グローバル外部アプリケーション ロードバランサは、単一のエニーキャスト IP アドレスを提供します。このアドレスは、ユーザー トラフィックを地理的に最も近い Google エッジに自動的にルーティングします。この構成では、エッジの セキュア ソケット レイヤ（SSL）終端によりレイテンシが短縮されます。また、リージョンで障害が発生した場合でも、トラフィックを正常なリージョン バックエンドにインテリジェントに再ルーティングするため、高可用性を確保できます。

テナントの信頼性に関する考慮事項

エージェント レベルの障害を許容または処理するには、分離されたテナント プロジェクトにエージェントをデプロイします。この分離により、運用上の問題やセキュリティ インシデントが 1 つのビジネス ユニット内に留まり、他のリソースやビジネス ユニットに影響しないようにできます。

Agent Platform の信頼性に関する考慮事項

モデルへのリクエスト数が割り当てられた容量を超えると、モデルはエラーコード 429 を返します。ビジネス クリティカルで常に高いスループットを必要とするワークロードの場合は、プロビジョンド スループットを使用してスループットを予約できます。

Agent Runtime の信頼性に関する考慮事項

Agent Runtime の構成と使用が信頼性要件を満たすようにするには、次の推奨事項を考慮してください。

  • サーバーレスのスケーラビリティ: Agent Runtime にデプロイされたエージェントは、需要に基づいて個別にスケーリングされます。1 つのテナントで使用量が急増しても、コンピューティング リソースが枯渇したり、別のテナント プロジェクトのエージェントの可用性に影響したりすることはありません。
  • エラー処理: エラーコード 429 のレート制限などの一時的なエラーを処理するために、エージェント オーケストレーション ロジックは指数バックオフを使用します。コンテキストの期限を超過すると、エージェントは正常なシャットダウンを実行し、部分的な進捗状況をユーザーに報告します。たとえば、ツールの呼び出しが遅い、サードパーティ API のレイテンシ、大規模なデータセットの処理、コンピューティング負荷の高い処理などにより、コンテキストの期限を超過することがあります。

AI ワークロードと ML ワークロードに固有の信頼性の原則と推奨事項については、Well-Architected Framework の AI と ML の視点: 信頼性をご覧ください。

運用効率

このセクションでは、このリファレンス アーキテクチャを使用して、効率的に運用できる Google Cloud トポロジを設計する際に考慮すべき要素について説明します。

Google Cloud Observability に関する考慮事項

Logging と Cloud Monitoring を使用すると、プラットフォーム全体の健全性とパフォーマンスをモニタリングできます。アラートを設定して、機密データへのアクセスを許可することなく、問題をプロアクティブに検出してトラブルシューティングできます。

アーキテクチャのすべてのプロダクトに関する運用効率の考慮事項

標準化されたテナント アーキテクチャ パターン内で Agent Platform を使用すると、新しいテナントをオンボーディングするときに一貫したベースラインを確立できます。運用上の負担を軽減するには、Terraform などの Infrastructure as Code（IaC）ツールを使用してデプロイ プロセスを自動化します。マルチテナント エージェント型 AI システムの構築とデプロイに使用できる Terraform コードについては、このドキュメントのデプロイセクションをご覧ください。

AI ワークロードと ML ワークロードに固有のオペレーショナル エクセレンスの原則と推奨事項については、Well-Architected Framework の AI と ML の視点: 運用の卓越性をご覧ください。

費用の最適化

このセクションでは、このリファレンス アーキテクチャを使用して構築した Google Cloud トポロジの設定と運用の費用を最適化するためのガイダンスを示します。

Agent Platform の費用に関する考慮事項

Agent Platform の構成と使用量が費用の要件を満たすようにするには、次の推奨事項を検討してください。

  • トークンの消費: 費用を管理し、AI モデルがコンテキスト ウィンドウを超えないようにするには、次の戦略を使用して AI モデルのコンテキストを管理します。
    • コンテキストの要約: セッションの会話全体をコンテキストとして保存するのではなく、AI モデルを使用して、古い会話や重要度の低い情報を要約します。
    • 出力を削除する: ツール出力または取得されたコンテキストの関連性の低い部分や冗長な部分を特定して削除します。たとえば、データから列名のみが必要な場合は、データベース スキーマのフェッチから過剰なメタデータを削除できます。この戦略では、ヒューリスティック、フィルタリング、または小規模言語モデル（SLM）を使用して最も重要な情報を抽出するカスタム ロジックが必要です。
    • 最大トークン上限: 無限ループを防止し、費用を管理するために、セッションの最大トークン上限を適用します。

  • モデル エンドポイント: API の割り当てとリソース使用率を管理するには、Agent Platform エンドポイントを専用構成または共有構成のいずれかでデプロイします。

    • 専用エンドポイント: 各テナント プロジェクト内にエンドポイントをデプロイすると、固有の割り当て分離が提供されます。各テナントの使用量は、独自のプロジェクト割り当てにカウントされるため、テナント間の影響を防ぐことができます。共有エンドポイントと比較すると、専用エンドポイントでは割り当て管理が簡単になります。ただし、専用エンドポイントを使用すると、共有エンドポイントの潜在的なコスト削減を活用できなくなります。
    • 共有エンドポイント: 費用を最適化するために、中央のガバナンスとセキュリティ ハブで共有エンドポイントをホストできます。すべてのテナントが同じ割り当てプールを共有するため、悪意のある攻撃を防ぐには、API Gateway でテナントレベルのレート制限や割り当ての適用などの緩和戦略を実装する必要があります。専用エンドポイントと比較すると、共有エンドポイントの方が費用対効果に優れています。ただし、共有エンドポイントには追加のエンジニアリング作業が必要であり、レイテンシと管理オーバーヘッドが発生する可能性があります。

    Agent Platform の費用の詳細については、Agent Platform での AI モデルの構築とデプロイの費用をご覧ください。

Cloud Run の費用に関する考慮事項

計測により、パフォーマンスのモニタリング、問題のトラブルシューティング、各テナントのリソース使用量の追跡を行うことができます。各リクエストのテナントを識別するには、IAP が提供するコンテキストからユーザー ID を抽出します。アプリケーションを計測可能にする方法については、計測方法を選択するをご覧ください。

Model Armor の費用に関する考慮事項

厳格なガバナンスとゼロトラスト ポスチャーを適用するため、このアーキテクチャでは、ルーティング ハブと各テナント プロジェクトの 2 つのレイヤに Model Armor をデプロイします。この 2 層アプローチは、データ主権の確保に役立ちますが、レイテンシと運用コストが増加します。費用とシステムの複雑さを軽減するには、ルーティング ハブにのみ Model Armor をデプロイして、すべてのプロンプトとレスポンスをフィルタします。

アーキテクチャのすべてのプロダクトに関する費用の考慮事項

アーキテクチャが費用の要件を満たすようにするには、次の一般的な推奨事項を検討してください。

  • 共有インフラストラクチャ: フロントエンド ポータル、中央ガバナンスとセキュリティ ハブ、Agent Platform などの共有コア インフラストラクチャ コンポーネントを使用すると、エージェントごとに個別のカスタム スタックを構築する場合と比較して、費用を削減できます。

  • プラットフォームのオーバーヘッド: 一元化されたガバナンスとセキュリティ ハブの共有費用を配分するには、トラッキング機能と使用パターンに合った配分モデルを使用します。次のいずれかの費用配分モデルを使用することをおすすめします。

    • 均等分割割り当て: 均等分割モデルでは、共有費用がすべてのテナントに均等に割り当てられます。このモデルは、プラットフォームがベースライン ユーティリティである場合や、詳細なトラッキングのオーバーヘッドが費用対効果を上回る場合に使用します。
    • 比例配分: 比例モデル（チャージバック プロセス）では、各テナントが負担する直接費用の割合に基づいて共有費用が配分されます。このモデルは、テナントの使用量が大幅に変動し、Resource Manager のラベルやログ解析などの堅牢なテレメトリーを使用して費用を正確に割り当てることができる場合に使用します。
    • 固定割り当て: 固定モデルまたは階層型モデルでは、ビジネスで定義された係数に基づいて共有費用が割り当てられます。このモデルは、テナントに異なるサービスレベル契約（SLA）が必要な場合に使用します。固定モデルの割り当てでは、標準の共有機能に対してプレミアム専用機能に固定料金を請求できます。

    共有サービスの費用を割り当てる方法については、Cloud FinOps: 共有サービスの費用割り当てをご覧ください。

  • 一元化された費用管理: エージェント型 AI システムの総所有コスト（TCO）を正確に追跡し、個々のビジネス ユニットに費用を割り当てるには、ラベルと Cloud Billing のエクスポート データを使用します。ラベルを使用して費用を把握する方法については、費用意識の文化を育むをご覧ください。

Google Cloud リソースの費用を見積もるには、Google Cloud の料金計算ツールを使用します。

AI ワークロードと ML ワークロードに固有の費用最適化の原則と推奨事項については、Well-Architected Framework の AI と ML の視点: 費用の最適化をご覧ください。

デプロイ

このリファレンス アーキテクチャをデプロイするには、GitHub で入手できるマルチテナント エージェント型 AI Terraform の例を使用します。

次のステップ

寄稿者

著者:

  • Shivank Awasthi | フィールド ソリューション アーキテクト
  • Utkarsh Bhardwaj | テクニカル ソリューション コンサルタント、エージェント型 AI、アプリ、クラウド プラットフォーム、インフラストラクチャ

その他の寄稿者:

  • Adrian Corona | セキュリティ、グローバル サービス デリバリー、マネージャー
  • Agnieszka Kołkiewicz | GSD AI マネージャー
  • Anmol Sachdeva | 広告ソリューション エンジニア、グローバル ビジネス
  • Ashish Agarwal | EMEA 北部リード、グローバル サービス デリバリー
  • Ashmita Kapoor | JAPAC 生成 AI FSA、Applied AI CE マネージャー
  • Ashutosh Gupta | グローバル サービス デリバリー担当ディレクター
  • Aspen Sherrill | クラウド セキュリティ アーキテクト
  • Chinmay Deshpande | クラウド移行コンサルタント、インフラストラクチャ
  • Gaurav Taneja | EMEA 南部インフラストラクチャ、データ、AI、GDC デリバリー リード
  • Ishmeet Mehta | 北米プラットフォーム スペシャリスト、アプリ CE
  • Joanna Nowek | AI Transformation コンサルタント
  • Kumar Dhanagopal | クロス プロダクト ソリューション デベロッパー
  • Mark Schlagenhauf | テクニカル ライター、ネットワーキング
  • Matthias Ziener | グローバル サービス デリバリー担当マネージャー
  • Olu Akinrolabu | セキュリティ クラウド コンサルタント
  • Paweł Tokarski | EMEA 南部インフラストラクチャ、データ、AI、GDC デリバリー リード
  • Paweł Glica | Core EMEA プラクティス リード
  • Prabha Arya | 戦略的クラウド エンジニア
  • Samantha He | テクニカル ライター
  • Suchit Puri | グローバル AI プラクティス リード
  • Thomas Cliett | delta AI、ディレクター
  • Valentín Huerta | AI エンジニア