Google ADKにModel Armorガードレールが標準搭載──「スクリーニングに失敗したら通す」ではなく「失敗したら塞ぐ」を既定にした設計

3行まとめ

1. Google製のエージェント開発フレームワークADKはv2.8.0(2026年8月26日公開、コミット11efc3f)で、Google Cloud Model Armorの検閲テンプレートを組み込むModelArmorPluginを追加した
2. 既定は「スクリーニングに失敗したらブロックする(block_on_screening_failure=True)」という保守的な設計で、判定不能な状況では通さずに塞ぐ
3. 公式ドキュメントは自ら3つの制約(ツール出力は検査対象外・ブロック以外の処理は未対応・音声検査は文字起こし精度に依存)を明記している

Googleがオープンソースで提供するエージェント開発フレームワーク「ADK（Agent Development Kit）」は、v2.8.0（2026年8月26日公開）で、Google Cloud Model Armorのコンテンツ検閲機能をプラグインとして組み込んだModelArmorPluginを追加した。GitHubのコミットメッセージでは「feat: add Model Armor guardrail plugin」という1行だが、公式ドキュメントには具体的な仕組みと設計判断が詳しく書かれている。

Model Armorとは何をするサービスか

まず前提として、公式ドキュメントはModel Armor自体をこう説明している。

"Model Armor is a Google Cloud service that inspects text for prompt injection and jailbreak attempts, harmful content, and sensitive data. You define what to look for in a template — a named, server-side policy — and the service returns a verdict for each piece of text you send it."

（Model Armorは、プロンプトインジェクションやジェイルブレイクの試み、有害なコンテンツ、機微な情報について、テキストを検査するGoogle Cloudのサービスだ。何を検出対象にするかは「テンプレート」——名前付きのサーバーサイドポリシー——として定義し、サービスは送信したテキストの断片ごとに判定結果を返す）

つまりModel Armor自体はGoogle Cloud側のサーバーサイドサービスであり、今回ADKに追加されたのは、そのサービスをエージェントの入出力に自動的に噛ませるための「プラグイン」だ。

入力と出力、両方を別々のテンプレートで検査できる

コミット本文には次のような機能概要がある。

"Screen user input and model output with Google Cloud Model Armor templates, through the before and after model callbacks

• input is screened against the prompt template
• output is screened against the response template

When content is matched, a safe configurable message can be returned as a blocking response."

（before・afterのモデルコールバックを通じて、Google Cloud Model Armorのテンプレートでユーザー入力とモデル出力をスクリーニングする。入力はプロンプトテンプレートに対して、出力はレスポンステンプレートに対してスクリーニングされる。コンテンツがマッチした場合、設定可能な安全なメッセージをブロッキング応答として返せる）

公式ドキュメントによれば、導入はpip install 'google-adk[gcp]'でパッケージを追加した上で、Appにプラグインとして登録するだけで済む。

app = App(
    name="model_armor_demo",
    root_agent=agent,
    plugins=[
        ModelArmorPlugin(
            config=ModelArmorConfig(
                prompt_template_name="projects/my-project/locations/us-central1/templates/my-prompt-template",
                response_template_name="projects/my-project/locations/us-central1/templates/my-response-template",
            )
        )
    ],
)

入力用（prompt_template_name）と出力用（response_template_name）のテンプレートをそれぞれ独立に指定でき、どちらか片方だけを有効にすることもできる。

「スクリーニングに失敗したら、通さずに塞ぐ」という既定

公式ドキュメントが明記している設計上のポイントは、スクリーニング処理自体が失敗した場合の挙動だ。

"Block screening failures by default: by default screening failures are blocked rather than delivered."

（既定でスクリーニング失敗をブロックする：既定では、スクリーニングが失敗した場合、コンテンツは配信されるのではなくブロックされる）

判定ロジックの表も公式ドキュメントに掲載されている。invocation_resultがSUCCESS（すべてのフィルタが正常に実行された）の場合のみ、実際の判定結果（filter_match_state）を見て通す・塞ぐを決める。それ以外——一部または全部のフィルタがスキップ・失敗した、あるいはフィールド自体が未設定だった場合——は、すべて「スクリーニング失敗」として扱われ、block_on_screening_failureという設定に従って、既定ではブロックされる。公式ドキュメントに掲載されている表をそのまま引用する。

スクリーニングが正常に完了した場合、filter_match_stateがMATCH_FOUND（少なくとも1つのフィルタが反応した）であればコンテンツはブロックされ、それ以外はそのまま通過する。

ModelArmorConfigの設定項目一覧も公式ドキュメントに掲載されている。

少なくともどちらか一方のテンプレート名は設定必須で、両方を設定する場合は同一のGCPロケーションに存在するテンプレートでなければならないという制約も明記されている。

これは前述のGooseのHooks機能（本サイトの別記事で扱った、フックが壊れた場合は許可扱いにする「fail open」設計）とは正反対の判断だ。Model Armorは、判定できない状況では「念のため通す」のではなく「念のため塞ぐ」という、より保守的な安全側の設計を選んでいる。同じ「外部の検査プロセスが失敗した時どうするか」という問題に対して、ツールによって逆の答えを出している点は比較材料として興味深い。

ブロックされた応答には専用のメタデータが付く

もう1つの特徴は、ブロックが発生したことをアプリケーション側から検出できるようにしている点だ。

"Blocked responses are marked with custom_metadata['model_armor_blocked'] so your application can detect them."

（ブロックされた応答はcustom_metadata['model_armor_blocked']でマークされ、アプリケーション側で検出できるようにしている）

単に無害なメッセージにすり替えるだけでなく、「これはModel Armorによってブロックされた応答だ」という事実自体をメタデータとして残すことで、開発者側がログ収集やユーザーへの追加説明などの後処理を組み込めるようにしている。

認証はApplication Default Credentials

公式ドキュメントによれば、認証情報は「Application Default Credentials」（Google Cloudの標準的な認証情報解決の仕組み）から取得される。テンプレートのパス指定は、projects/{project}/locations/{location}/templates/{template}というフルリソースパス形式が必須で、リージョンごとのエンドポイントを意識した設計になっている(prompt_template_nameとresponse_template_nameの両方を設定する場合、テンプレート名から解析される{location}部分が一致している必要があり、1つのプラグインインスタンスは1つのリージョンのエンドポイントとしか通信しない)。

Model Armor自体はマルチクラウド対応の独立サービス

ADKのプラグインが呼び出しているModel Armor自体についても、Google Cloud公式ドキュメントで確認した。Model Armorは「Google CloudでAIをデプロイしている場合でも、他のクラウドプロバイダーでデプロイしている場合でも」使えるサービスと説明されており、ADK専用の機能ではない。公式の用途例としては、LLMのプロンプト・応答に含まれる機密情報(知的財産・個人情報)の漏洩防止、プロンプトインジェクション・ジェイルブレイク攻撃への対策に加えて、「PDF内のテキストをスキャンして機微・悪意のある内容を検出する」「チャットボットが競合他社のソリューションを推薦しないようにする(ブランド保護)」「AIが生成したSNS投稿から危険・憎悪的なコンテンツを検出する」といった、プロンプトインジェクション対策以外の使い道も挙げられている。ADKのModelArmorPluginは、こうした汎用サービスをエージェントの入出力に自動的につなぐための薄いラッパーだと位置づけられる。

公式ドキュメントが明記する3つの制約

公式ドキュメントの末尾には「Limitations」という節があり、次の3点が現時点の制約として明記されている。

• ツールの出力は検査対象外:検査対象になるのは直近のuserコンテンツのテキスト部分のみで、ツールの実行結果はfunction_responseという形でリクエストに追加されるため、Model Armorには届かない
• 対応できる制御は限定的:現時点のプラグインは検出結果のログ記録とブロックのみに対応しており、テキストの一部だけを置換・墨消しするような処理には対応していない(将来の拡張候補として言及されている)
• 音声のライブ検査は文字起こし経由:音声によるライブ検査は、音声認識による文字起こし結果を介して行われるため、その文字起こしの精度に検査の質が左右される

Gooseとは逆の「fail closed」という選択

筆者は、AIエージェントの入出力を外部の検閲サービスに通す、という構成自体は理解していたが、「検閲サービスが応答できなかった時にどうするか」という一見マイナーな設計判断が、実はガードレール機構全体の信頼性を左右する核心的なポイントだと、このドキュメントを読んで改めて認識した。ガードレールを導入したつもりでも、それが「壊れたら無効化される」設計なのか「壊れたら全部止める」設計なのかで、実際に得られる安全性はまったく違う。ADKのModel Armorプラグインは後者を選び、それを既定の挙動として明記している点は、企業向けの用途を意識した保守的な判断だと考えられる。

料金体系とレイテンシへの影響は範囲外だった

Model Armor自体の料金体系や、テンプレート作成の具体的な手順（Google Cloudコンソール側の操作）については、今回参照したADK側のドキュメントの範囲を超えるため確認していない。またこのプラグインが実際にどの程度のレイテンシを追加するか（Model Armorへの追加のAPI呼び出しがエージェントの応答速度にどう影響するか）についての実測値も、公式ドキュメントには記載がなかった。

関連記事

• AIエージェントとは──指示に答えるAIと、仕事を進めるAIの違いをわかりやすく整理する
• MCP（Model Context Protocol）とは──AIとツールをつなぐ共通規格
• 2026年は「AIエージェント元年」──企業は何を準備すべきか