top of page
検索

【実践】Model ArmorでVertex AIのAIセキュリティを実装する

  • 執筆者の写真: Hiromi Kuwa
    Hiromi Kuwa
  • 9月12日
  • 読了時間: 6分

AIアプリのセキュリティ問題について


AIを利用したアプリケーションが急速に普及する一方で、悪意あるプロンプトでAIをハッキングしようとする動きも出てきています。

これは、従来のSQLインジェクションのような攻撃と同様、またはそれ以上に深刻なリスクをもたらします。AIアプリケーションのセキュリティ対策の重要性が高まっている今、どのような対策を取ることが出来るか検討していきます。


アプリケーションのセキュリティ対策とModel Armorの選択


しかし対策と言っても、ハックの手法は日々進化しており、自力で全てに対応するのは困難です。また、アプリケーション本来の開発に専念したい開発者にとって、セキュリティ対策に多くの時間を割くのは悩ましい課題です。そこで、専門的なサービスを活用するのが最も効率的な解決策と言えます。


数あるサービスの中でも、Model Armorは現在、Google Cloudサービスとの統合をPre-GA（一般提供開始前）で提供しており、これから本格的な活用が期待されます。Google Cloud Nextでも言及されており、Google Cloudのサービスとシームレスに統合できる点が大きな魅力です。

こうした背景から、今回はModel Armorを実際に試してみることにしました。


Model Armorの役割と機能


Model Armorは、AIアプリケーションと大規模言語モデル（LLM）の間に位置し、悪意ある入力をブロックするゲートウェイのような役割を果たします。自前で様々な対策を検討するのに比べ、簡単な設定を行うだけで、プロンプトインジェクションや機密情報の流出といったリスクへのセキュリティを強化できるのが大きな利点です。


特に、Google Cloudの主要なAIプラットフォームであるVertex AIとの連携が非常に容易なため、既存のサービスに手軽にセキュリティを加えたい開発者にとって、Model Armorは強力な選択肢となるでしょう。


実際の使用例：フロア設定とテンプレートの使い分け


Model Armorには、プロジェクト全体に適用するフロア設定と、より柔軟に制御できるテンプレートという2つの適用方法があります。それぞれの使い方と違いを、実際に試した例を交えて解説します。


フロア設定を使ってみる


まずは、最も手軽なフロア設定から試してみました。これは、特定のプロジェクト全体にModel Armorのポリシーを適用する設定です。 以下の公式ドキュメントを参考に設定を進めました。


フロア設定


今回は、以下の構成で実験してみます。

ree


利用したコード


今回の検証用に作成した、モデルにリクエストを送信する際の簡易的なコードです。

from google import genai
from google.genai import types
import os
from dotenv import load_dotenv

load_dotenv()

project_id = os.getenv("GOOGLE_CLOUD_PROJECT")

client = genai.Client(
    vertexai = True,
    project = project_id,
    location = 'us-central1',
    http_options = types.HttpOptions()
)
response = client.models.generate_content(
    model="gemini-2.5-flash-lite",
    contents="プロンプト"
)

結果


アプリケーションのレスポンスに検出結果は含まれておらず、これまでの結果とあまり違いは見られませんでしたが、Cloud Loggingには検出結果が出力されていました。

該当のログは以下のフィルターで簡単に絞り込めます。

jsonPayload.@type="type.googleapis.com/google.cloud.modelarmor.logging.v1.SanitizeOperationLogEntry"

確認したところ、今回の実験に利用したプロンプトは、特に問題が無いものとして認識されているようですが、何かしら検査が行われたことはログとして出力されています。

ree

機密データの保護 - 検出タイプを「高度」に変更し、DLPで作成した検出・匿名化テンプレートを設定してみました。

以下の通り、ログ上では機密情報が自動的に[PERSON_NAME]のように匿名化されることを確認しました。

（[PERSON_NAME] を検出・匿名化対象としているため、氏名部分が置換されている）

ree

PIIが検出される状態において、Vertex AI の種類を「違反を検出し、ブロックする」に変更するとどうなるか確認してみます。

$python test.py
xxxxxxxxxxx/google/genai/_common.py:474: UserWarning: MODEL_ARMOR is not a valid BlockedReason
warnings.warn(f"{value} is not a valid {cls.__name__}")

SDK（google-genai：v1.33.0）を使用した場合、UserWarning が発生しました。Pre-GAのため、SDKがまだ対応されていないものと思われます。

レスポンスからブロックされた理由を確認します。

# print(response.prompt_feedback.block_reason)
BlockedReason.MODEL_ARMOR

# print(response.prompt_feedback.block_reason_message)
Blocked by Model Armor Floor Setting: The prompt violated SDP/PII filters.
ree

ログとしては、「検査のみ」の場合とほぼ同内容になっているようです。


ブロックする場合はエラーハンドリングが必要にはなりますが、検査のみであれば、アプリケーションのコードには一切の変更を行うことなく導入できる点は、既存のアプリケーションにModel Armorを導入する上で非常に大きなメリットだと感じました。


Model Armorのテンプレートを使ってみる


次に、よりきめ細かな制御が可能なテンプレートを試してみました。

テンプレートは、特定のAIリクエストに対して個別のセキュリティポリシーを適用したい場合に便利です。

実際に利用できる場面としては、プロジェクト内で複数のAIアプリケーションを運用している場合に、それぞれのユースケースに合わせて異なるセキュリティポリシーを適用したい場合に特に有効です。


テンプレートの作成は Model Armor templates console を参考に実施しました。

フロア設定と概ね同じ内容ですが、ブロックを行うか、検査のみとするかが選べない点がフロア設定との大きな差異です。


なお、テンプレートはフロア設定よりも厳しい制限でなければ保存できません。

既にフロア設定が作成されている場合、フロア設定より緩い制限で保存しようとするとエラーが発生しました。


アプリケーションへの組み込み


API のリファレンスを見る限りでは、generate_content にModel Armor のテンプレートを利用する設定を追加するだけでよさそうです。しかし、現時点（2025/09）ではSDKに該当の設定を追加することが出来ませんでした。

そのため、こちらは Python から curl でリクエストを飛ばす形にして検証しました。


テンプレートの適用は、通常のVertex AIへのリクエストに model_armor_config という設定を追加するだけです。

ただし、テンプレートを利用するには、事前にVertex AIのサービスアカウントにModel Armor ユーザーのロールを追加しておく必要があります。


結果


レスポンスとして、以下が返ってきました。フロア設定とあまり違いは無さそうですが、検出結果は即座にブロックとして返されました。

{
  "promptFeedback": {
    "blockReason": "MODEL_ARMOR",
    "blockReasonMessage": "The prompt violated SDP/PII filters."
  },
  "usageMetadata": {
    "trafficType": "ON_DEMAND"
  }
  "modelVersion": "gemini-2.5-flash-lite",
  # 一部省略
}

Cloud Loggingを確認してみます。

ree

ログの内容としても、フロア設定の場合とあまり大きな差は無さそうです。

フロア設定が優先されて、テンプレートが適応されていない可能性も考えましたが、 resource.labels.template_id に利用したテンプレートのID（model-armor-test-template）が出力されていたため、問題なく適応されていると判断しています。

"resource": {
    "type": "modelarmor.googleapis.com/SanitizeOperation",
    "labels": {
      "location": "[location]",
      "resource_container": "projects/[project_number]",
      "template_id": "model-armor-test-template"
    }
  },

なお、フロア設定が適応されている場合は以下の出力でした。

  "resource": {
    "type": "modelarmor.googleapis.com/SanitizeOperation",
    "labels": {
      "template_id": "FLOOR_SETTING--[n]"
      "resource_container": "projects/[project_number]",
      "location": "global"
    }
  }

まとめと今後の展望


Model Armorのフロア設定は、既に運用中のAIアプリケーションにセキュリティ対策を導入する際に非常に手軽で強力な手段です。しかし、Pre-GAということもあり、SDKの修正が追い付いていない等、公開するアプリケーションで採用するには悩ましい点も少なくありません。


今後の正式リリースやアップデートで、より柔軟な設定が可能になることを期待し、引き続き動向を注視していきたいと思います。

 
 
 

コメント

bottom of page