概要

Model Armor は、 Google Cloud サービスと統合して、 AI と大規模言語モデル(LLM)のインタラクションを保護します。Model Armor は、ポリシー違反の可能性を特定して報告し、セキュリティ評価に基づいてアクションを積極的にブロックできます。

サポートされているモダリティ

Model Armor でスキャンしてサニタイズできるモダリティは、サービスへのアクセス方法によって異なります。

  • 直接 REST API: Model Armor REST API は、テキスト、ドキュメント、 および画像など、すべての モダリティをサポートしています。詳細については、 プロンプトとレスポンスをサニタイズするをご覧ください。
  • 他のサービスとの統合: Model Armor と他の サービスとの統合では、 Gemini Enterprise との統合のみが ドキュメントをサポートしています。 Google Cloud 他のすべての統合では、テキストのみがスキャンされ、サニタイズされます。

サポートされているドキュメント タイプとサイズ上限の詳細については、 ドキュメントのスクリーニングをご覧ください。

サポート対象のサービス

このセクションでは、 Google Cloud Model Armor と統合できる サービスについて説明します。

Agent Gateway

Model Armor を Agent Gateway と統合して、ゲートウェイで管理されるすべてのエージェントとの間で送受信されるトラフィックにセキュリティ ポリシーを適用します。この統合により、悪意のあるコンテンツや非準拠のコンテンツをインラインで検査してブロックできます。この統合は、アプリケーション コードを変更することなく、ワークフローのセキュリティと組織の安全ガイドラインの遵守を改善することを目的としています。この保護は、エグレス(エージェントから)パスとイングレス(エージェントへ)パスの両方でサポートされているプロトコルに適用されます。詳細については、Agent Gateway と統合するをご覧ください。

Apigee

Model Armor と Apigee の統合により、Apigee API ゲートウェイ レイヤ内で Model Armor の AI 保護機能を直接使用できます。Apigee API プロキシ内で特定の Model Armor ポリシーを構成します。API 呼び出しがこれらのポリシーを持つ Apigee プロキシを通過すると、Apigee はプロンプトとレスポンスを Model Armor サービスに送信して検査します。詳細については、 Apigee と統合するをご覧ください。

Gemini Enterprise

Model Armor は、 テンプレートを使用して Gemini Enterprise と直接統合できます。Gemini Enterprise は、ユーザーとエージェント間のやり取りと基盤となる LLM を Model Armor を介してルーティングします。つまり、ユーザーやエージェントからのプロンプトと、LLM によって生成されたレスポンスは、ユーザーに提示される前に Model Armor によって検査されます。詳細については、Gemini Enterprise と統合するをご覧ください。

サポートされているモダリティに記載されているモダリティに加えて、 Model Armor と Gemini Enterprise の統合 ではドキュメントもサポートされています。ただし、ドキュメントに埋め込まれた画像はスクリーニングされません。

Google と Google Cloud MCP サーバー

Model Armor を構成すると、データを保護し、 Model Context Protocol(MCP)ツールとサーバーを公開する Google Cloud サービスにリクエストを送信する際に、コンテンツを保護できます。Model Armor は、MCP ツール呼び出しとレスポンスをサニタイズすることで、エージェント AI アプリケーションを保護します。 フロア設定を使用します。このプロセスにより、プロンプト インジェクションや機密情報の開示などのリスクを軽減できます。詳細については、Google と MCP サーバーを統合するをご覧ください。 Google Cloud

Service Extensions

Model Armor は、 Google Cloud ネットワーク サービス を介して Service Extensions と統合できます。Service Extensions を使用すると、 サービスまたはユーザー管理のサービスを Google Cloud 統合してトラフィックを 処理できます。アプリケーション ロードバランサでサービス拡張機能を構成して、エージェントや MCP サーバーなど、さまざまな AI インタラクションのネットワーク トラフィックをスクリーニングできます。また、GKE 推論ゲートウェイでサービス拡張機能を使用して、GKE クラスタとの間のトラフィックをスクリーニングすることもできます。これにより、ロードバランサを通過するすべての AI インタラクションが Model Armor で保護されます。詳細については、 ネットワーク サービスと統合する Google Cloud をご覧ください

Gemini Enterprise Agent Platform

Model Armor は、 フロア設定または テンプレートを使用して、Gemini Enterprise Agent Platform に直接統合できます。 このインテグレーションにより、Gemini モデルのリクエストとレスポンスがスクリーニングされ、フロア設定に違反するリクエストとレスポンスがブロックされます。このインテグレーションにより、Vertex AI の Gemini API 内で generateContent メソッドのプロンプトとレスポンスが保護されます。この統合では、ドキュメントや画像を含むプロンプトとレスポンスのサニタイズはサポートされていません。プロンプトとレスポンスのサニタイズ結果を可視化するには、Cloud Logging を有効にする必要があります。詳細については、 Gemini Enterprise Agent Platform と統合するをご覧ください。

始める前に

API を有効にする

Model Armor を使用するには、Model Armor API を有効にする必要があります。

コンソール

  1. Model Armor API を有効にします。

    API を有効にするために必要なロール

    API を有効にするには、serviceusage.services.enable 権限が必要です。プロジェクトを作成した場合は、オーナーロール(roles/owner)を介してこの権限が付与されている可能性があります。それ以外の場合は、Service Usage 管理者ロール(roles/serviceusage.serviceUsageAdmin)を介してこの権限を取得できます。ロールを付与する方法をご覧ください

    API の有効化

  2. Model Armor を有効にするプロジェクトを選択します。

gcloud

始める前に、Google Cloud CLI で Model Armor API を使用して、次の処理を行います。

  1. コンソール Google Cloud で Cloud Shell をアクティブにします。

    Cloud Shell をアクティブにする

    コンソールの下部にある Google Cloud Cloud Shell セッションが開始し、コマンドライン プロンプトが表示されます。Cloud Shell はシェル環境です 。Google Cloud CLI がすでにインストールされており、現在のプロジェクトの値もすでに設定されています 。セッションが初期化されるまで数秒かかることがあります。

  2. gcloud CLI を使用して API エンドポイントのオーバーライドを設定します

gcloud CLI を使用して API エンドポイントのオーバーライドを設定する

この手順は、gcloud CLI を使用して Model Armor API を有効にする場合にのみ必要です。gcloud CLI がリクエストを Model Armor サービスに正しくルーティングするように、API エンドポイントのオーバーライドを手動で設定する必要があります。

次のコマンドを実行して、Model Armor サービスの API エンドポイントを設定します。

gcloud config set api_endpoint_overrides/modelarmor "https://modelarmor.LOCATION.rep.googleapis.com/"

LOCATION は、Model Armor を使用するリージョンに置き換えます。

割り当てを管理

Model Armor は、割り当てシステム を使用して、公平な使用を確保し、システムの安定性を保護します。Model Armor API のデフォルトの割り当ては、プロジェクトごとに 1,200 QPM です。プロジェクトごとに 0 ~ 1,200 QPM の値を適用できます。調整をリクエストするには、 割り当ての調整をリクエストするをご覧ください。 デフォルトの割り当てを超える割り当てが必要な場合は、 Cloud カスタマーケアにお問い合わせください。

Model Armor の割り当ては、他のサービスと統合する際に重要な考慮事項となります。操作する主な割り当ては、プロジェクトごとに 1 分あたりの API リクエスト数です。

Model Armor を他のサービスと統合する場合は、次の割り当てタイプを考慮してください。

  • Model Armor のデフォルトの割り当て: サービスが分析のために Model Armor API を呼び出すと(プロンプトやレスポンスの確認など)、プロジェクトの Model Armor API の割り当てが消費されます。
  • 統合サービスの割り当て: Model Armor の割り当ては、統合サービスに関連付けられた割り当てとは異なります。リクエスト パス内のすべてのサービスに十分な割り当てがあることを確認する必要があります。アプリケーションのコンテンツをサニタイズするために Model Armor API に対して行われた呼び出しは、Model Armor API の割り当て上限にカウントされます。

割り当て超過の状況を検出する

アプリケーション ログに Model Armor からのエラー(通常は HTTP 429 RESOURCE_EXHAUSTED エラー)が表示されている場合は、Model Armor の割り当て上限に達しています。これは、リクエストが多すぎることを示します。

割り当ての必要量を見積もる

リクエストする Model Armor の割り当て量を決定するには:

  • サービスが Model Armor に送信する 1 分あたりのリクエスト数のピークを見積もります。
  • サービスとのユーザー インタラクションごとに Model Armor が呼び出される回数を考慮します(プロンプトに 1 回、レスポンスに 1 回など)。
  • 同時ユーザーまたはセッションの最大数を考慮します。
  • 予期しない急増に対応するために、妥当なバッファ(予想されるピークの 20 ~ 30% 増など)を含む割り当てをリクエストします。
  • 最適な見積もりから始め、リリース後に使用状況を注意深くモニタリングし、必要に応じて調整をリクエストします。

たとえば、1 分あたり 500 人のユーザーが想定され、各ユーザー インタラクションで Model Armor が 2 回(プロンプトとレスポンス)呼び出される場合は、少なくとも 1,000 QPM が必要です。 バッファを考慮すると、1,200 ~ 1,300 QPM をリクエストすることをおすすめします。

考慮事項

他のサービスと統合する場合は、次の点を考慮してください。

  • 他のサービスの割り当てをモニタリングして管理していることを確認します。他のサービスの割り当てが不足すると、Model Armor の割り当てが十分であっても、アプリケーションに影響します。
  • 一時的な割り当ての問題やその他の再試行可能なエラーに対処するために、アプリケーションの設定で指数バックオフを使用したクライアントサイドの再試行を実装します。詳細については、再試行戦略をご覧ください。

適用タイプ

Model Armor を他のサービスと統合する場合に構成する重要な要素は、適用タイプです。この設定により、Model Armor は、検査するデータ(LLM プロンプトやレスポンスなど)でポリシー違反の可能性を検出したときにどのように動作するかが決まります。適用タイプによって、Model Armor が違反を報告するだけか、積極的に介入するかが決まります。詳細については、適用タイプを定義するをご覧ください。

REST API を使用して統合する

統合に REST API を使用する場合、Model Armor はテンプレートを使用する検出機能としてのみ機能します。ポリシー違反の可能性を積極的に防止するのではなく、事前定義されたテンプレートに基づいて特定して報告します。 Model Armor API と統合すると、アプリケーションはその出力を使用して、提供されたセキュリティ評価の結果に基づいてアクションをブロックまたは許可できます。Model Armor API は、API トラフィックに関連する潜在的な脅威やポリシー違反に関する情報を返します。特に AI インタラクションの場合に役立ちます。アプリケーションは Model Armor API を呼び出し、レスポンスで受信した情報を使用して、事前定義されたカスタム ロジックに基づいて意思決定を行い、アクションを実行できます。

Model Armor を統合する際のオプション

Model Armor には、次のインテグレーション オプションがあります。各オプションには、異なる機能が用意されています。

インテグレーション オプション 検出を構成する サポートされているモダリティ 検査のみ 検査してブロック 対象範囲
Agent Gatewayプレビュー テンプレートのみを使用する テキスト はい はい すべてのモデルとすべてのクラウド
Apigee テンプレートのみを使用する テキスト はい はい すべてのモデルとすべてのクラウド2
Gemini Enterprise テンプレートのみを使用する テキスト、ドキュメント はい はい すべてのモデルとすべてのクラウド2
Google と Google Cloud MCP サーバー フロア設定のみを使用する テキスト はい はい Google と Google Cloud MCP サーバー
Service Extensions テンプレートのみを使用する テキスト はい はい すべてのクラウド2 の OpenAI 形式のモデル1、エージェント、MCP サーバー
Gemini Enterprise Agent Platform フロア設定テンプレートの両方を使用する テキスト はい はい Gemini モデル(非ストリーミング)

1Anthropic Claude、Mistral AI、 Grok など、いくつかの一般的なモデルは OpenAI 仕様をサポートしています。これらのモデルは通常、必要な OpenAI 互換の API レイヤを提供する vLLM などの推論エンジンを使用してデプロイされます。vLLM は、Meta Llama シリーズ、DeepSeek、Mistral、Mixtral ファミリー、Gemma など、幅広いモデルをサポートしています。

2AWS や Azure などの他のパブリック クラウドが含まれます。

Gemini Enterprise Agent Platform との統合により、Model Armor はフロア設定またはテンプレートを使用してインライン適用を行います。インライン ポリシー適用により、Model Armor は、アプリケーション コードを変更することなく、プロセスに直接介入してポリシーを積極的に適用できます。

Service Extensions と Gemini Enterprise の統合では、インライン ポリシーの適用にテンプレートのみが使用されます。インライン ポリシー適用により、Model Armor は、Service Extensions 内と Gemini Enterprise インスタンス内のユーザーまたはエージェントのインタラクションの両方で、アプリケーション コードを変更することなくポリシーを直接適用できます。

Gemini Enterprise、Agent Runtime、Apigee との Model Armor の統合により、最初のユーザー プロンプト、最終的なエージェントまたはモデルのレスポンス、中間ステップ(ウェブ検索ツールから返されるグラウンディング データやレスポンスなど)がサニタイズされます。取得したグラウンディング データまたは中間ペイロードが、構成済みの Model Armor テンプレートまたは Sensitive Data Protection ポリシーに違反している場合、リクエストはブロックされ、SANITIZE_USER_PROMPT オペレーション タイプでログに記録されます。

Security Command Center の Model Armor

Model Armor は、LLM プロンプトとレスポンスを検査して、プロンプト インジェクション、ジェイルブレイクの試み、悪意のある URL、有害なコンテンツなど、さまざまな脅威を検出します。Model Armor は、構成済みのフロア設定の違反を検出すると、プロンプトまたはレスポンスをブロックし、Security Command Center に検出結果を送信します。詳細については、 Model Armor の検出結果をご覧ください。