こんにちは。SCSKの島村です。
皆さんはAIエージェントの「ガバナンス」について、どこまで意識されていますでしょうか？
前回の概要編でご紹介した Gemini Enterprise Agent Platform の4レイヤー（Build / Scale / Govern / Optimize）のうち、今回はGovern（ガバナンス）レイヤーを深掘りしていきます。
前回の概要編でご紹介した Gemini Enterprise Agent Platform の4レイヤー（Build / Scale / Govern / Optimize）のうち、今回はGovern（ガバナンス）レイヤーを深掘りしていきます。
本記事では、エージェントを全社展開する上で最も問われる「安全に統制できるのか？」という問いに、Agent Platform がどう答えているかを「ガードレール」と「ハーネス」という2つの切り口で整理します。
本記事では、『AIエージェントにガードレールとハーネスを付ける — Agent Platform Govern 編』について調査・検証した内容をご紹介します。
- 1. なぜエージェントに「ガードレール」と「ハーネス」が必要なのか
- 2. Govern レイヤーの全体マップ
- 3.【ガードレール①】Model Armor — 入出力の防壁
- 4.【ガードレール②】Agent Policy — 行動の制約
- 5.【ガードレール③】Agent Gateway — 通信の関所
- 6.【ハーネス①】Agent Identity — 身元の証明と追跡
- 7.【ハーネス②】Agent Registry — 承認カタログ
- 8.【ハーネス③】Agent Anomaly Detection — 異常の早期検知
- 9.【ハーネス④】Agent Security & Compliance — 脅威対応と監査
- 10. ガードレール × ハーネスの連携 — エージェントライフサイクル全体像
- 11. 「どこから始めればいいのか」— 段階的導入ガイド
- 最後に（まとめ）
1. なぜエージェントに「ガードレール」と「ハーネス」が必要なのか
AIエージェントは従来のAPIやSaaSと本質的に異なります。
決まった入力に決まった出力を返すのではなく、目標を与えられると自律的に判断し、ツールを呼び出し、外部と通信し、結果に応じて次のアクションを決める。
この自律性こそがエージェントの価値ですが、同時に企業にとっては新しいリスクでもあります。
決まった入力に決まった出力を返すのではなく、目標を与えられると自律的に判断し、ツールを呼び出し、外部と通信し、結果に応じて次のアクションを決める。
この自律性こそがエージェントの価値ですが、同時に企業にとっては新しいリスクでもあります。
従来のAPI/SaaS と AIエージェントの根本的な違い
| 比較軸 | 従来の API / SaaS | AI エージェント |
|---|---|---|
| 動作の性質 | 決定論的（同じ入力→同じ出力） | 非決定論的（同じ目標でも経路が変わる） |
| 制御の主体 | 呼び出し元（開発者/アプリ） | エージェント自身 |
| 処理経路 | 事前に固定（コードで定義） | 動的に決定（状況に応じて変更） |
| 外部通信 | 事前定義された宛先のみ | 判断により新しい宛先に接続しうる |
| エラーの影響 | 局所的（呼び出し元に返る） | 連鎖的（次の判断に伝播し増幅） |
ガードレール vs ハーネス の概念整理
この課題に対し、Agent Platform の Govern レイヤーは2種類のアプローチで応えます。
| 概念 | 役割 | 比喩 | 対応する Govern 機能 |
|---|---|---|---|
| ガードレール | 越えてはいけない境界を定義し、逸脱を事前に防止する | 道路の側壁・崖の柵 | Model Armor, Agent Policy, Agent Gateway |
| ハーネス | エージェントの動きを観測・記録・制御するための接続点 | 馬の手綱・登山のハーネス | Agent Identity, Registry, Anomaly Detection, Security, Compliance |
ガードレールとハーネス — 片方だけでは不十分
- ガードレールだけ — 境界の内側で何をしているかが見えない
- ハーネスだけ — 見えていても止められなければ意味がない
- 両方を組み合わせることで、「自律的に動かしつつ、安全に統制する」が実現する
2. Govern レイヤーの全体マップ
各機能のステータス（2026年6月時点）
| 機能 | 分類 | ステータス | 概要 |
|---|---|---|---|
| Model Armor | ガードレール | GA | プロンプトインジェクション・有害コンテンツの検出・遮断 |
| Agent Policy | ガードレール | Preview | エージェントの行動範囲・権限の宣言的定義 |
| Agent Gateway | ガードレール | Preview | エージェント通信の集中制御ポイント |
| Agent Identity | ハーネス | GA | エージェントへの一意ID付与・認証・認可 |
| Agent Registry | ハーネス | New | 承認済みエージェント・ツールの一元カタログ |
| Agent Anomaly Detection | ハーネス | New | 異常な推論パターンのリアルタイム検出 |
| Agent Security | ハーネス | Preview | 脆弱性スキャン・脅威検出ダッシュボード |
| Agent Compliance | ハーネス | — | 規制準拠・監査対応 |
3.【ガードレール①】Model Armor — 入出力の防壁
Model Armor は、エージェントへの入力（プロンプト）とモデルからの出力（レスポンス）の両方を検査し、有害なコンテンツが通過しないようにする防壁です。
道路のガードレールが車の逸脱を物理的に止めるように、Model Armor はプロンプトインジェクション、ジェイルブレイク試行、機密情報の漏洩、有害コンテンツの生成をリアルタイムで検出・遮断します。
防御対象
| 脅威 | 入力側 | 出力側 | 説明 |
|---|---|---|---|
| プロンプトインジェクション | ✓ | — | 悪意ある指示をプロンプトに注入し動作を変える攻撃 |
| ジェイルブレイク | ✓ | — | モデルの安全制約を回避しようとする試行 |
| 機密データ漏洩 | — | ✓ | PII・機密情報を含む応答の出力防止 |
| 有害コンテンツ生成 | — | ✓ | 暴力・差別等の不適切なコンテンツ抑制 |
| 間接プロンプトインジェクション | ✓ | — | ツール経由で注入される隠れた悪意ある指示 |
Agent Gateway との連携
Model Armor は単体でAPI呼び出しも可能ですが、Agent Platform では Agent Gateway に組み込む ことで、すべてのエージェント通信に対してコード変更なしで一括適用できます。
Model Armor の設定ポイント
- テンプレートベースで検出カテゴリと閾値を定義
- Gateway に紐付けることで全エージェントに自動適用
- Sensitive Data Protection（旧DLP）と連携し機密データを検出
- 業界・社内固有のカスタムルールも追加可能
4.【ガードレール②】Agent Policy — 行動の制約
Agent Policy は、エージェントが 「やってよいこと」と「やってはいけないこと」を宣言的に定義 する仕組みです。Model Armor が「入力と出力のコンテンツ」を検査するのに対し、Agent Policy は「エージェントの行動そのもの」を制約します。
ポリシーで定義できること
| ポリシー種別 | 内容 | 例 |
|---|---|---|
| ツール利用制限 | 使用可能なツールのホワイトリスト/ブラックリスト | 「外部API呼び出しは禁止、社内DBのみ許可」 |
| データアクセス範囲 | アクセス可能なデータソース・スコープ | 「人事データは参照不可」 |
| Human-in-the-loop | 特定アクション実行前に人間の承認を要求 | 「10万円超の支払い承認は人間にエスカレーション」 |
| エスカレーション条件 | 自動処理を中断し人間に委ねる条件 | 「確信度80%未満の判断は人間に確認」 |
| 実行環境制約 | 特定リージョン・VPC内でのみ実行許可 | 「JP リージョンのみで処理」 |
Google Cloud IAM チームは、エージェント向けの新しいアクセスポリシー体系として Unified Access Policy (UAP) を発表しています（近日公開予定）。Agent Identity に基づく Who / What / Effect / Conditions / HITL の軸で、きめ細かな制御が可能になります。
5.【ガードレール③】Agent Gateway — 通信の関所
Agent Gateway は、エージェントの全通信が通過する 集中制御ポイント（航空管制塔） です。エージェント間通信（Agent-to-Agent）、エージェントからツールへの通信（Agent-to-Tool）、外部サービスへの通信をすべてここで管理します。
主な機能
| 機能 | 説明 |
|---|---|
| 通信先制御 | 許可リスト / 拒否リストによるエンドポイント制御 |
| Model Armor インライン適用 | Gateway を通過する全通信にコンテンツスクリーニングを自動適用 |
| Identity-Aware Proxy (IAP) 統合 | エージェントのIDに基づいたアクセス制御 |
| Context-Aware Access (CAA) | デバイス状態・IP・場所等のコンテキストに基づく動的制御 |
| 観測性 | クロスクラウド環境含むエージェントトラフィックの可視化 |
ガードレール3層の連携
3つのガードレールは異なるレベルで防御を担当し、リクエスト処理時に3層のフィルターとして連携して動作します：
- Layer 1 — Model Armor（コンテンツレベル）：何を言っているか？ を検査
- Layer 2 — Agent Policy（アクションレベル）：何をしようとしているか？ を判定
- Layer 3 — Agent Gateway（ネットワークレベル）：どこと通信しようとしているか？ を制御
🖥️ コンソール操作：Agent Gateway のセットアップ
Agent Gateway は Google Cloud コンソールの Agent Platform セクションから設定します。
基本的なセットアップフロー：
- Gateway の作成 — Agent Platform > Govern > Gateways で「Create Gateway」を選択。名前・リージョン・VPC ネットワークを指定
- ポリシーの紐付け — Model Armor テンプレートの選択、許可/拒否エンドポイントの定義、IAP/CAA条件の設定
- エージェントの接続 — 構築済みエージェントの通信を Gateway 経由にルーティング
6.【ハーネス①】Agent Identity — 身元の証明と追跡
Agent Identity は、すべてのエージェントに暗号化された一意のIDを付与し、人間のユーザーやサービスアカウントとは区別された独立したIDタイプとして管理する仕組みです。
登山のハーネスが「この人が誰で、どのルートを登っているか」を常に把握可能にするように、Agent Identity は「このエージェントが誰で、何をしたか」を完全に追跡可能にします。
技術的な基盤 — SPIFFE 標準
Agent Identity は SPIFFE（Secure Production Identity Framework For Everyone） 標準に基づいて構築されています。暗号的に保護された識別子が自動プロビジョニングされ、階層構造（trust domain / namespace モデル）により個別またはグループ単位での制御が可能です。
サービスアカウントとの違い
| 比較項目 | サービスアカウント | Agent Identity |
|---|---|---|
| 設計目的 | ワークロード間認証 | AIエージェント固有の認証 |
| 行動パターン | 決定論的 | 非決定論的・自律的 |
| IAMの扱い | 第一級プリンシパル | 新しい第一級プリンシパルタイプ |
| ポリシー適用 | Allow / Deny | Allow / Deny + PAB + UAP + HITL |
| 監査トレイル | 操作ログ | 操作ログ + 推論経路 |
7.【ハーネス②】Agent Registry — 承認カタログ
Agent Registry は、組織で承認されたエージェント・ツール・スキルの 一元管理カタログ（Single Source of Truth） です。「今、組織内にどんなエージェントが走っていて、それらは誰が承認したものか」を常に把握するための仕組みです。
Registry が解決する問題 — シャドーAI
エージェントの構築が容易になるほど、シャドーAI（IT部門が把握・承認していないAIエージェントの利用）のリスクが高まります。Agent Registry はこの問題に対し、以下のワークフローを強制します：
開発 → Registry に登録 → IT部門がレビュー → 承認 → Gallery に公開 → 従業員が利用
主な機能
| 機能 | 説明 |
|---|---|
| エージェントのインデックス化 | 社内の全エージェント・ツール・スキルを自動検出・登録 |
| 承認ワークフロー | 登録 → レビュー → 承認 → 公開の管理フロー |
| Agent Gallery 連携 | Registry で承認されたものだけが Enterprise App の Gallery に表示 |
| バージョン管理 | エージェントの各バージョンを管理、必要に応じてロールバック |
| 資産発見 | 組織全体のAIエージェント資産の棚卸し（シャドーAI検知含む） |
8.【ハーネス③】Agent Anomaly Detection — 異常の早期検知
Agent Anomaly Detection は、稼働中のエージェントが正常な動作パターンから逸脱した瞬間に検知する仕組みです。ガードレール（Model Armor / Policy / Gateway）は事前に定義されたルールベースの防御ですが、未知の異常パターンや「ルールの範囲内だがおかしい動き」はガードレールだけでは防げません。
検出アプローチ
| アプローチ | 仕組み | 得意な検出対象 |
|---|---|---|
| 統計モデル | 正常時のベースラインからの逸脱を定量的に検出 | 異常なリクエスト頻度、レイテンシ急上昇、トークン消費量の異常 |
| LLM-as-a-judge | LLMがエージェントの推論ログを意味的に評価 | 論理の飛躍、不自然な判断パターン、目標からの逸脱 |
Anomaly Detection は Agent Threat Detection と連携し、リバースシェルの実行や既知の悪意あるIPへの接続といった明確な脅威もカバーします。
9.【ハーネス④】Agent Security & Compliance — 脅威対応と監査
Agent Security
Agent Security は Security Command Center と連携した統合ダッシュボードです。エージェント固有のセキュリティリスクを一箇所で可視化します。
| 機能 | 説明 |
|---|---|
| セキュリティポスチャ | セキュアバイデザインのテンプレートとGoogle推奨コントロール |
| 脆弱性スキャン | エージェントのパッケージ・スキルの脆弱性をデプロイ前に検出 |
| 資産発見 | 組織全体のAIエージェント資産の自動棚卸し |
| 脅威検出 | ランタイムでの悪意あるアクティビティの検出 |
| グラフベースのリスク分析 | エージェントとモデル間の関係をマッピングしリスクを特定 |
Agent Compliance
企業が規制要件を満たし、監査に対応するための証跡管理を担います。
| 要件 | 対応する機能 |
|---|---|
| 操作の追跡 | Cloud Audit Logs（全操作の自動記録） |
| 機密データの保護 | Sensitive Data Protection（旧DLP）連携 |
| ネットワーク境界の制御 | VPC Service Controls（データ境界の強制） |
| 暗号化の管理 | CMEK（顧客管理の暗号鍵） |
| 業界規制対応 | HIPAA / FedRAMP High / SOC 2 |
10. ガードレール × ハーネスの連携 — エージェントライフサイクル全体像
| フェーズ | やること | ガードレール | ハーネス |
|---|---|---|---|
| ① 開発 | エージェントを構築 | Policy を定義 | Identity を付与 |
| ② 登録 | 組織カタログに登録 | — | Registry に登録・承認 |
| ③ デプロイ | 本番環境に配置 | Gateway に接続設定 | Security で脆弱性スキャン |
| ④ 稼働 | リクエストを処理 | Model Armor + Policy + Gateway | Anomaly Detection で監視 |
| ⑤ インシデント | 異常検知・対応 | Gateway でブロック | Security + Threat Detection |
| ⑥ 監査 | コンプライアンス確認 | — | Compliance でエビデンス出力 |
11. 「どこから始めればいいのか」— 段階的導入ガイド
すべてを一度に導入する必要はありません。組織の成熟度とリスク許容度に応じて段階的に強化していくのが現実的です。
Step 1：最低限の統制（PoC〜パイロット）
- Agent Identity — 誰が何をしたか追跡可能にする
- Agent Policy（基本） — 行動範囲の大枠を定義する
Step 2：通信制御（本番導入初期）
- Agent Gateway — 全通信を集中管理し、未承認通信をブロック
- Model Armor — プロンプトインジェクション・データ漏洩を防止
Step 3：可視化と組織統制（全社展開）
- Agent Registry — 何が動いているかを組織として把握
- Agent Anomaly Detection — 稼働中の異常を早期検知
- Agent Security — 脅威の統合可視化
Step 4：監査対応・規制準拠（規制業界・大規模運用）
- Agent Compliance — 規制対応のエビデンス出力
- VPC-SC / CMEK — データ境界と暗号化の強制
- Organization Policy — 組織全体のポリシー強制
組織タイプ別の推奨
| 組織タイプ | 推奨ステップ | 理由 |
|---|---|---|
| スタートアップ・PoC | Step 1 | まず動かすことが優先、最低限の追跡可能性 |
| 一般企業・社内利用 | Step 2〜3 | 通信制御と可視化で実用レベルの安全性確保 |
| 金融・医療・公共 | Step 4 | 規制要件を満たす完全な統制が必要 |
| グローバル大企業 | Step 3〜4 | 組織統制 + データ所在地・暗号化の制御 |
最後に（まとめ）
今回は『AIエージェントにガードレールとハーネスを付ける — Agent Platform Govern 編』として、Govern レイヤーの全体像をご紹介しました。
- ガードレール（Model Armor / Agent Policy / Agent Gateway）= 越えてはいけない境界を定義し、逸脱を事前に防止する
- ハーネス（Agent Identity / Registry / Anomaly Detection / Security / Compliance）= 動きを観測・記録・制御し、問題発生時に手綱を引く
- 8つの機能はバラバラではなく、エージェントのライフサイクルに沿って連携する
- 全社展開の段階に応じて Step 1〜4 で段階的に強化していくアプローチが現実的
リスク × 機能 対応表
| リスク | 種別 | 対応する機能 |
|---|---|---|
| プロンプトインジェクション | ガードレール | Model Armor |
| 想定外の行動・権限超越 | ガードレール | Agent Policy |
| 不正な外部通信 | ガードレール | Agent Gateway |
| 追跡不能・説明責任の欠如 | ハーネス | Agent Identity |
| シャドーAI の増殖 | ハーネス | Agent Registry |
| 暴走・異常動作 | ハーネス | Agent Anomaly Detection |
| セキュリティ脅威 | ハーネス | Agent Security |
| 規制違反 | ハーネス | Agent Compliance |
次回は Optimize（最適化）編 として、エージェントを本番運用しながら「どう磨き続けるか」を検証します。Agent Simulation によるデプロイ前テスト、Agent Evaluation による本番品質の継続計測を試す予定です。
今後とも、AIMLに関する情報やGoogle CloudのAIMLサービスのアップデート情報を掲載していきたいと思います。
最後まで読んでいただき、ありがとうございました！！！
最後まで読んでいただき、ありがとうございました！！！