2026年9月11日

暴走しないAIエージェントの作り方～Google CloudのAgent Guardrail設計～

Popular tags

Content

「AIエージェントに顧客対応を任せたら、聞かれてもいないのに競合製品を褒めるようなことを言い出した」
「バッチ処理を自動化するエージェントに、うっかり本番データベースの中身を外部のAPIに投げさせてしまった」

AIエージェントの活用が進むほど、経営層やセキュリティ責任者の頭を悩ませるのが「エージェントの暴走」というリスクです。あいまいな指示、モデルのハルシネーション（幻覚）、悪意あるユーザーによるjailbreak（脱獄）やプロンプトインジェクション、ツール経由の間接的なプロンプトインジェクションなど、AIエージェントが制御不能になる原因は一つではありません。

こうしたリスクを未然に防ぎ、「強力だが信頼できるエージェント」を構築するための多層防御の仕組みを提供しているのが、Google CloudのAgent Platform（ADK）です。本記事では、ビジネス視点で押さえておくべき「Agent Guardrail（エージェントの安全対策）」の全体像を、5つの防御レイヤーに分けて解説します。

リスクの全体像

対策を考える前に、まず「何が起こりうるのか」を整理しておきましょう。AIエージェントに関するリスクは、大きく3つのカテゴリーに分類できます。

リスクカテゴリー	具体例
目標のズレ・意図の誤読	意図しない目標を追いかけてしまう「報酬ハッキング」。複雑・曖昧な指示を誤って解釈してしまう。
有害コンテンツ生成・ブランド毀損	有害・差別的・不適切なコンテンツの生成。ブランドの価値観に反する発言や、本題から外れた会話。
危険な操作の実行	システムを破壊するコマンドの実行、無許可の決済・金融取引、個人情報（PII）の漏洩、データの外部流出。

Google CloudのAgent Platformは、この3種類のリスクそれぞれに対して具体的な防御手段を用意しています。次の見出しから順番に見ていきましょう。

誰の権限で行動させるか

エージェントが外部システムを操作する際、「誰の権限で動くか」は極めて重要なセキュリティ設計です。同じエージェントの中でも、ツールごとに異なる権限戦略を選べます。

	Agent-Auth（エージェント自身の権限）	User-Auth（操作者本人の権限）
動く主体	エージェント固有のID（サービスアカウント等）	操作しているユーザー本人（OAuthトークンなど）
権限の制御方法	外部システム側のアクセスポリシーで絞る（例：読み取り専用アクセスのみ許可）。モデルが何を判断しても、許可されていない操作は実行できません。	ユーザー本人ができる範囲のことしかエージェントもできない、という形で自動的に制限されます。
向いているケース	ユーザーによって権限差がない、シンプルな用途。	ユーザーごとに権限が異なる、または悪意あるユーザーによる悪用リスクを抑えたい場合。

実務上とくに評価されているのが、この2つの中間にあたる「委任された権限（Delegated Authority）」という第三のパターンです。エージェントは、やり取りしている従業員が本来持っている権限をそのまま引き継いで動作します。これにより、エージェントが明示的に許可されていないデータには一切アクセスできないことが保証されるうえ、複雑な権限構造をゼロから作り直す必要がなくなり、クリーンな監査証跡も自然に残ります。

Google CloudのAgent Platformでは、この3つのモデル（ユーザーIDで直接動作／エージェント独自の独立ID／委任された権限）を安全な「エージェントID」として体系的にサポートしています。詳細はAgent Identityのドキュメントをご覧ください。ただしUser-Authは、OAuthスコープなど「まとまった単位」でしか権限を委譲できないことが多く、実際にエージェントが必要とする範囲より広い権限を渡してしまいがちです。そこで重要になるのが、次に紹介する「ガードレール」による追加の絞り込みです。

入力・出力を検査する「ガードレール」

権限を絞るだけでなく、エージェントが「何を受け取り、何を出力するか」を精密にチェックする仕組みが「ガードレール」です。Agent Platformでは、主に3つの手段を組み合わせます。

1

In-Tool Guardrails（ツール自体を守り仕様にする）

ツールを設計する段階で「モデルが指定するパラメータ」と「開発者があらかじめ決めた設定情報（Tool Context）」を分けておき、実行時に照合します。例えば「特定のテーブルにしかクエリを実行させない」「SELECT文しか許可しない」といったポリシーを、ツール自身に組み込めます。

2

Geminiモデル標準の安全機能

Geminiモデルには標準でコンテンツフィルターが備わっています。児童搾取コンテンツやPII（個人情報）を含む出力を自動的にブロックする「非設定型フィルター」に加え、ヘイトスピーチ・嫌がらせ・性的表現・危険なコンテンツの4カテゴリーについて、確率とリスクの度合いに応じたブロック閾値を自社ポリシーに合わせて設定できる「設定型フィルター」があります。さらに、システムインストラクションでブランドのトーンや話題の範囲、禁止事項を直接指示することもできます。

3

Callbacks & Plugins（再利用可能な安全ポリシー）

個別のエージェントに限定した事前検証は「コールバック」で実装しますが、複数のエージェントに横断的に安全ポリシーを適用したい場合は「プラグイン」が推奨されます。プラグインは一度設定すれば、そのランナーを使うすべてのエージェントに自動的に適用されるため、コードの重複なく一貫したガードレールを維持できます。

代表的なプラグイン例

Gemini as a Judge： 軽量・高速なGeminiモデルを使い、ユーザー入力やツールの入出力、エージェントの応答が適切か、プロンプトインジェクションやjailbreakの兆候がないかを判定させます。不適切と判定された場合は定型の断りメッセージを返します。
Model Armor： Model Armor APIに問い合わせ、コンテンツ安全違反の可能性を実行の各段階でチェックします。
Global Instruction Plugin： ADKに標準搭載されているプラグインで、すべてのLLM呼び出しに対して共通の指示文を自動的に差し込みます。「ブランドのトーンはこう」「この話題には触れない」といった全社共通のルールを、エージェントごとにプロンプトを書き分けるのではなく、アプリ全体に一括で強制できます。

なお、「Gemini as a Judgeプラグイン」や「Model Armorプラグイン」は概念だけでなく、Google Cloud上で実際に使える機能として提供されています。Model ArmorはAgent Platformと統合することで、プロンプトがGeminiモデルに届く前とレスポンスがアプリケーションに届く前の両方をインターセプトし、プロンプトインジェクションやjailbreakの検出、機密データの保護を自動で行います。プロジェクト全体に適用する「フロア設定」と、リクエスト単位で細かく設定する「テンプレート」の2通りの構成方法があります。

危険な操作を閉じ込める

入出力のチェックに加えて、「万が一おかしな動きをしても被害が外に広がらない」ようにする、物理的な封じ込めも重要です。

	サンドボックス化されたコード実行	VPC-SCによるネットワーク境界
何を守るか	エージェントが生成・実行するコードそのもの	外部システムとの通信経路
具体的な手段	Vertex Gemini Enterprise APIのコード実行機能や、データ分析用のCode Interpreter Extensionを利用。自前実装の場合はネットワーク遮断・実行後の完全クリーンアップを行う「隔離環境」を用意します。	VPC Service Controlsの境界内でエージェントを実行し、すべてのAPI呼び出しを境界内リソースのみに限定します。
注意点	自前実装時は、通信遮断とデータクリーンアップの徹底が必要です。	境界だけでは「粗い」制御にとどまるため、見出し3で紹介したツール単位のガードレールと組み合わせることが重要です。

継続的に検証する

安全対策は「作って終わり」ではありません。エージェントが実際にどう動いているかを継続的に可視化し、検証し続ける仕組みが最後の防御レイヤーです。

評価（Evaluation）： エージェントの最終的な出力の品質・関連性・正確性を評価ツールで確認します。

トレーシング（Tracing）： エージェントがどのツールを選び、どんな戦略で、どれだけ効率的に解決策にたどり着いたのかというプロセス全体を可視化します。問題が起きた際の原因調査だけでなく、日常的な品質モニタリングにも欠かせません。

見落としがちな注意点：エージェントの出力をブラウザ上に表示するUIでは、HTMLやJSを適切にエスケープしないと、悪意ある入力（間接的なプロンプトインジェクション）によって埋め込まれたコードがそのまま実行されてしまう危険があります。画面に第三者へセッション情報を送信する<img>タグを仕込まれる、といった攻撃例も報告されています。モデルが生成したテキストは必ずコードとしてではなく文字列としてエスケープして表示することが必須です。

個々のエージェントを安全に作っても、組織全体で見たときに「誰がどんなエージェントを、どんな権限で動かしているか」が分からなくなってしまっては本末転倒です。監視されていない、いわゆる「シャドーAI」は、深刻なデータの断片化とコンプライアンスリスクを引き起こします。

1

Agent Registry（エージェントの棚卸し台帳）

すべてのアクティブなエージェント、そのビジネスオーナー、アクセス先のデータセット、許可されたツールを自動的に一覧化する、一元管理された検索可能なディレクトリです。手作業のスプレッドシート管理から卒業し、重複したエージェントの統合や、放置された危険なエンドポイントの安全な廃止を確実に行えるようになります（Agent Registryの詳細）。

2

2層構造のポリシー（IAM＋セマンティック）

まずIAMポリシーで「このエージェントはこのツールとこのデータバケットにしかアクセスできない」という明確な境界を引きます。加えてセマンティックポリシーにより、ユーザーの自然言語での指示の「意図」をリアルタイムで解析し、エージェントが答えようとしている内容が実行前に主要なビジネスルールやコンプライアンス要件に沿っているかを検証します（Policiesの詳細）。

3

Agent Gateway（すべての通信の検問所）

ポリシーは、実行時に強制され、明確な監査証跡が残らなければ意味を持ちません。すべてのエージェントの通信をAgent Gateway経由でルーティングすることで、ユーザー・エージェント・ツール間のやり取りを自動的にインターセプトし、ポリシー違反の即時ブロック、コンテンツのサニタイズ、プロンプトインジェクションの防止を行います。さらに、あらゆるやり取りからネットワーク層のテレメトリーを生成し、リアルタイムの挙動指標や実行トレースをオブザーバビリティ基盤に流し込みます（Agent Gatewayの詳細）。

脅威検知との連携：Security Command Centerの一部であるAgent Platformの脅威検出は、エージェントの意思決定ループをリアルタイムで監査します。不正なデータベースコマンドの試行や、未検証の外部ネットワークアドレスへの接続といった普段とは異なる挙動を検知すると、ほぼリアルタイムでイベントにフラグを立てて隔離します。ガードレールを「すり抜けようとする」異常な兆候そのものを見張る、最後の砦です。

まとめ

AIエージェントの安全性は、単一の仕組みで担保できるものではありません。「誰の権限で動くか」「何を入出力するか」「万が一の際にどこまで被害が広がるか」「実際にどう動いているか」「組織全体でどう見渡すか」という5つの問いに、それぞれ具体的な仕組みで答えていく多層防御こそが、エージェントを安心して本番投入できる唯一の道です。