優秀なAIエージェントを、安心して会社に迎える——Platform Builders編

Day 1では、自然言語で頼むと驚くほど速く仕事を進める「ものすごく優秀な新人」を迎えました。Day 2のPlatform Builders Trackで考えたのは、その新人が一人ではなくなった世界です。

営業支援、顧客分析、問い合わせ対応、販促。部署ごとにエージェントが増え、互いを呼び出し、社内データを読み、外部の道具も使うようになる。仕事は速くなります。一方で、管理者には新しい問いが生まれます。

• 会社には、いま何体のエージェントがいるのか
• そのうち、承認を受けずに動いているものはないか
• 顧客データを読んだのは、どのエージェントなのか
• 「呼び出してよい」と「データを書き換えてよい」を分けられているか
• 危険な入力を、実際の通信経路で検査できているか
• 問題が起きた後、何が起きたかを一本の時系列に戻せるか

これは、AIを監視で縛る話ではありません。能力の高い同僚へ、名札、担当範囲、入退室経路、作業記録を渡す話です。自由に働ける範囲を明確にするからこそ、任せられる仕事を増やせます。

この記事では、Build with Gemini Tokyo Day 2の演習シナリオとGoogle Cloudの公式資料を手掛かりに、エージェントの管理台帳、機械としての身元、通信の入口、データへの権限、通信内容の検査、作業記録、公開前の評価を、一つの運用設計としてつなぎます。各仕組みの製品名は、役割を説明するときに初めて示します。

この記事で持ち帰れること

最初に地図を置きます。用語を暗記する必要はありません。

表は左列だけを上から読めば、記事全体の問いになります。中央と右は「その問いを、どの役割と仕組みで解くか」です。いま製品名が分からなくても、本文で同じ順序をたどります。

大切なのは、これらを別々の製品として導入することではありません。台帳にある主体だけが、許された経路を通り、許された資源へアクセスし、その結果を後から検証できる。この一続きの条件を保つことが目的です。

この先も、一つの事件だけを追う

説明のため、ここで架空の会社を一つ設定します。社名はNovaSmartです。顧客の好みに合わせて商品を提案するサービスを運営し、その処理をAIエージェントへ任せています。

この先は機能のカタログとして読むのではなく、NovaSmartで起きた「台帳にない販促エージェントが顧客データへ到達した」という架空の一件を、少しずつ解決する物語として読み進めます。登場人物と役割は固定します。

NovaSmartとこの事件は、統制上の問題を一続きで説明するための設定であり、実在企業の事故ではありません。一方、本文で「演習では」と書く画面や結果は、ハンズオンで確認した内容です。物語と確認事実を混同しないよう、この表現を使い分けます。

• 業務責任者：販促という仕事をなぜ行うのか、何をしてはいけないかを決める
• Platform担当：エージェントを登録し、共通の入口、実行基盤、記録の仕組みを提供する
• Security担当：誰がどの経路で何へ到達できるかを検査する
• 正式なPersonalization Agent：顧客ごとの商品提案を作る、会社が承認済みのエージェント
• 台帳外の販促Agent：所有者も用途も確定しないまま動いていた調査対象

物語は五つの問いで進みます。「何がいるか」「誰として動くか」「どの道と権限を使うか」「危険な内容をどこで止めるか」「後から説明し、次版を出してよいか」です。一つ答えるたびに、次の問いが必要になる理由を確認します。

先に、用語を日常語へ置き換える

厳密な違いは本文で補います。まずはこの対応だけ持っていれば、途中で製品名が増えても、いま何の問題を解いているかを見失いにくくなります。

記事は三つの段階で進みます。第1段階（1〜8章）は目の前の事故を仕組みで解く基礎編、第2段階（9〜12章）は同じ仕組みを本番規模で破綻させない設計編、第3段階（13〜17章）は約束、指標、事故対応、導入順へ落とす運用編です。途中の振り返りでは、いまどこまで解けたかを確認します。

1. 物語の始まり：知らないエージェントが顧客データを読んでいた

先ほど設定した架空企業NovaSmartでは、顧客向けのPersonalization Agentが正式に運用されています。ある日、管理チームが実行中のサービスを調べると、台帳に載っていない販促用エージェントも見つかりました。しかも二つのエージェントは、同じ機械用アカウントで顧客データへアクセスしていました。

ここで起きている問題は「怪しいプログラムが一つあった」だけではありません。

1. 台帳と実態がずれている
2. 所有者が分からない
3. 二つの実行主体をログ上で区別できない
4. 一方だけ権限を止めるのが難しい
5. 事故が起きても責任範囲を切り分けにくい

この場面から、エージェント統制の設計を順に解いていきます。

2. 一つの台帳だけでなく、「四つの一覧」を照合する

2.1 「登録済み」と「存在する」は同じではない

社員名簿に名前がなければ、人が社内に存在しないとは限りません。同じように、Agent Registryに登録されていないエージェントも実行環境には存在できます。反対に、登録済みでも、すでに停止しているものがあります。

そこで一つの一覧だけを見るのではなく、四つの場所から得た観測結果を、同じエージェントごとに横並びで照合します。四つは集合の分類でも、二軸の四象限でもありません。台帳、実行基盤、通信経路、利用記録という、それぞれ別の仕組みが見ている事実です。

• 登録されているもの：会社が認識し、所有者や用途を記録したもの
• 動いているもの：実行基盤で現在稼働できるもの
• 到達できるもの：ネットワークやゲートウェイを通じて呼び出せるもの
• 利用実績があるもの：ログやトレースに、決めた観測期間内の活動があるもの

図の表では、✓が「その場所で確認できた」、—が「確認できなかった」を表します。たとえば、実行基盤・接続経路・利用ログには現れるのに登録台帳だけに現れないエージェントは、「動いて使われているが、会社の管理対象になっていない」と読めます。反対に、登録台帳にしか現れなければ、廃止後の記録が残っている可能性があります。

演習では、この照合によって台帳外のエージェントが見つかりました。

この画面の価値は、単なる「未登録の一件」ではありません。管理対象と実行実態の差を、機械的に検出できることです。

2.2 Agent Registryは名簿ではなく、統制の接続点

Agent Registryの公式資料では、Agentの名前だけでなく、提供するサービス、呼び出し先、利用する手順とその版、公開者なども扱います。これは、名前と説明文を置くカタログ以上の意味を持ちます。

たとえば「問い合わせ回答Agent」という名前だけでは、次の判断ができません。

• どこへ接続するのか
• どの版の作業手順や業務規則を使うのか
• 誰が公開したのか
• どの通信方式で呼べるのか
• 現在の所有者は誰か
• 廃止予定か、正式運用中か

つまり台帳は、実行主体、認可、通信経路、評価結果を結ぶための主キーになります。

ただし、自動登録は完全性の証明ではありません。Agentの登録方法には、自動登録される実行基盤と手動登録が必要なケースがあります。「自動登録を有効にした」という設定と、「すべてを発見できた」という観測結果は別です。

2.3 一度の棚卸しではなく、差分を継続的に閉じる

本番で守りたいのは、次の状態です。

実行可能なエージェントは、許容時間内に必ず管理対象へ収束する。

ここで重要なのは「常に完全一致」という非現実的な目標ではなく、ずれを何分で発見し、誰が何分で所有者を確定し、停止または登録まで持っていくかです。

以下は、その考え方を示す小さなPython例です。やりたいことは、実行環境の一覧と台帳を照合し、「動いているのに未登録」「登録済みだが所有者がない」を検出することです。実装そのものより、比較する二つの集合と、検出理由を明示する点が重要です。

from dataclasses import dataclass

@dataclass(frozen=True)
class RunningAgent:
    resource_id: str
    endpoint: str
    principal: str

@dataclass(frozen=True)
class RegisteredAgent:
    resource_id: str
    owner: str | None
    lifecycle: str

def find_governance_gaps(running_agents, registered_agents):
    registry = {agent.resource_id: agent for agent in registered_agents}
    findings = []

    for agent in running_agents:
        registered = registry.get(agent.resource_id)
        if registered is None:
            findings.append({
                "severity": "critical",
                "reason": "実行中だが台帳にない",
                "resource_id": agent.resource_id,
                "principal": agent.principal,
            })
        elif not registered.owner:
            findings.append({
                "severity": "high",
                "reason": "所有者が未設定",
                "resource_id": agent.resource_id,
            })

    return findings

この処理の出力は、一覧表をきれいにするためではなく、是正作業へつなげます。測るべきなのは、未登録件数、検知時間、所有者確定時間、廃止済みの接続先（Endpoint）が残っている時間です。

ここまでの振り返り

NovaSmartは、正式な台帳と実際の実行環境を照合し、台帳外の販促Agentを発見できました。これで「何がいるか」は分かりました。

次に残る問題：二つのAgentが同じ名義で顧客データへアクセスしていたため、どちらの仕事だったかを区別できません。次は「誰として動いたか」を解きます。

3. 人・エージェント・利用者を、三つの主体として分ける

3.1 「誰がやったか」は一つの名前では答えられない

業務エージェントには、少なくとも三種類の主体が関わります。

• 業務上の所有者：その機能とリスクに責任を持つ部署や人
• エージェントの実行主体（エージェントID）：クラウド資源へアクセスするときの、エージェント専用の機械的な身元
• 利用者：エージェントへ依頼し、必要なら権限を委譲する人

「マーケティング部が所有」と台帳に書いても、二つのエージェントが同じ実行主体を共有していれば、監査ログから起点を区別できません。逆に実行主体が一意でも、所有者がなければ、問題時の判断者が決まりません。また、利用者本人には見えない文書をエージェント自身の広い権限で読めば、利用者側のアクセス制御を迂回します。

演習の初期状態では、正式なエージェントと台帳外のエージェントが同じ主体で顧客データへアクセスしていました。

データアクセスの記録はあります。しかし二つの仕事が同じ名札で記録されるため、どちらが読んだのかを主体だけでは断定できません。

3.2 Agent Identityが解くこと、解かないこと

Google CloudのAgent Identityは、エージェントごとに専用の実行主体、つまりエージェントIDを与える仕組みです。公式概要では、エージェント資源と、その作成から廃止までの期間に結び付く、SPIFFEという標準を基盤としたIdentityとして説明されています。

ここで出てくるSPIFFEとは何か

SPIFFE（Secure Production Identity Framework for Everyone）は、サーバー、コンテナ、プログラムなどの動いているソフトウェアへ、検証可能な身元を与えるためのオープン標準です。このような実行中のソフトウェアを、ここではワークロードと呼びます。

従来は、IPアドレスや共有されたAPI keyを見て「おそらくこのプログラムだろう」と判断する構成がありました。しかし、コンテナの作り直しや自動拡張で実行場所が頻繁に変わる環境では、場所をそのまま身元として扱えません。また、複数のプログラムで一つの秘密を共有すると、記録に同じ名前しか残らず、どれが操作したのか区別できません。

SPIFFEでは、この問題を主に二つの要素で解きます。

spiffe://... から始まるSPIFFE IDは、パスワードや秘密鍵そのものではありません。あくまで「誰か」を表す名前です。接続先は、その名前が組み込まれたSVIDと、発行元を検証するための信頼情報を確認して、「信頼している組織が、この実行中のソフトウェアを確かにこのIDだと認めた」と判断します。

Google CloudのAgent Identityでは、エージェントへ一意のSPIFFE IDとX.509証明書が割り当てられます。証明書は短期間で更新され、Google Cloud用のAccess Tokenもエージェント固有の証明書へ暗号学的に結び付けられます。そのため、長期間使う秘密鍵を各所へ配る方式よりも、盗まれたTokenの使い回しや、複数エージェントによる身元の共有を抑えやすくなります。

つまり、ここでの「エージェントID」は単なる台帳上の番号ではありません。エージェントを表す名前、その名前を証明する短期Credential、作成から廃止までのライフサイクルをまとめて扱うための実行時Identityです。

得られる利点は次の通りです。

• エージェント単位で権限を狭められる
• 一体だけ停止、失効、調査しやすい
• ログの主体からエージェント資源へ帰属をたどりやすい
• 廃止とIdentityのライフサイクルを結び付けやすい
• 共有された長期Credentialの横流しリスクを減らせる

一方、Identityを分けるだけで所有責任、経路制御、入力検査、品質評価が自動的に解決するわけではありません。名札は重要ですが、名札だけで会社の統制は完成しません。

演習では、台帳外だったエージェントに所有者を設定し、二つの実行主体を分離しました。正式なPersonalization Agentの正常系を保ちながら、販促Agentから顧客データの閲覧権限を外せる状態にしています。

ここで学べるのは「エラーになったから成功」ではありません。正規の業務は通り、許可していない組み合わせだけが拒否され、その差をログで説明できることが成功です。

3.3 監査記録は、後から結合できる形にする

一つのログへ全部を書き込む必要はありません。ただし、依頼、エージェント、利用者、認可判断、対象資源を後から結合できる共通キーが要ります。

次のJSONは、監査時に再構成したい情報の見本です。目的はJSONを書くことではなく、「誰の依頼を、どのエージェントが、どの規則で判定され、何に対して実行したか」を欠落させないことです。

{
  "request_id": "req-...",
  "trace_id": "trace-...",
  "human_owner": "marketing-platform",
  "agent_resource": "customer-personalization-agent",
  "runtime_principal": "principal://...",
  "delegated_user": "internal-user-or-null",
  "requested_action": "read_customer_data",
  "target_resource": "customer_dataset",
  "policy_version": "2026-09-04.3",
  "decision": "DENY",
  "decision_point": "RESOURCE_IAM"
}

この例では、実名や秘密情報を記録することが目的ではありません。組織の保持方針に合わせて識別子を最小化しながら、同じtrace_idで各ログをたどれることが重要です。

ここでNovaSmartは、正式なAgentと台帳外Agentへ別々の名札を渡せる状態になりました。ただし、名札が違っても、裏口から直接データへ行けたり、必要以上に強い鍵を持っていたりすれば事故は防げません。そこで次に、通信の入口とデータの鍵を分けます。

4. GatewayとIAM：「呼んでよい」と「操作してよい」は別

4.1 受付と金庫の鍵を同じものにしない

Agent Gatewayを会社の受付、IAMを各部屋や金庫の鍵と考えると分かりやすくなります。

• Gatewayは、誰がどのエージェントやツールを、どの経路で呼べるかを制御する
• IAMは、その実行主体がデータ分析基盤、ファイル保管場所、業務APIなどの資源に何をできるかを制御する

Agent Gatewayの公式概要では、利用者からAgentへの入口と、Agentから外部サービスへの出口を扱います。Agent同士の通信や一般的なAPI通信へ、身元、台帳情報、許可規則、通信記録を接続する役割です。対応方式の細かな名称より、「入口と出口を同じ統制へ通せる」点が重要です。

しかし、Gatewayを通過できたことは、対象データの書き込みを許可されたことを意味しません。逆にIAMだけを厳密にしても、非正規の直接経路が残れば、呼び出し方やレート、プロトコル、送信先を統一的に制御できません。

flowchart LR
    U[利用者] -->|依頼| G[Agent Gateway]
    G -->|呼び出しを許可| A[エージェント]
    A -->|データ操作を要求| I[IAM]
    I -->|許可| D[業務データ]
    I -->|拒否| X[操作しない]

この図の前半は経路の認可、後半は資源操作の認可です。両方が通ったときだけ業務操作が成立します。

4.2 Denyは強いが、更新直後を決めつけない

IAM DenyはAllowより先に評価され、上位階層から継承されます。強力な安全装置ですが、ポリシー変更には伝播時間があります。

そのため変更テストは、次のように行います。

1. 変更前の期待結果を記録する
2. ポリシーの版と更新時刻を記録する
3. 一定間隔で同じ条件を再試行する
4. 許可・拒否の両方を確認する
5. タイムアウトしたら「ポリシーが誤り」と「反映待ち」を分けて報告する

重要なのは、テストの都合で長く待つことではありません。分散システムの反映時間を、試験条件の一部として明示することです。

4.3 最小権限は、ロール名ではなく到達可能な行為で測る

「Viewerだから安全」とは限りません。閲覧した情報を別のシステムへ送信できるなら、読み取りだけでも重大な情報流出につながります。評価すべきは個々のロールではなく、組み合わせた結果として可能になる行為です。

たとえば、次を一つの到達可能性として考えます。

顧客データを読む → 内容を要約する → 外部の宛先へ送る

各権限が別々のサービスにあっても、この経路が完成すればデータ流出能力を持ちます。Gatewayの送信先制御、IAM、DLP（機密情報の持ち出し防止）、内容検査、監査を組み合わせる理由はここにあります。

ここまでの振り返り

Agentごとに名札を分け、呼び出し経路をGatewayへ寄せ、データ操作はIAMで判定するところまで進みました。「受付を通れた」と「金庫を開けられる」は別の許可です。

次に残る問題：正規の経路でも、利用者の入力や、Agentが外部機能を呼ぶための窓口（Tool）から返る内容に、隠れた命令や機密情報が混ざることがあります。次は通信の中身をどこで検査するかを考えます。

5. Model Armor：「置いた」ではなく「どこを通ったか」を証明する

5.1 AIファイアウォールという比喩の限界

Model Armorは、AIへ入る依頼とAIから出る応答を検査するGoogle Cloudの仕組みです。公式概要では、AIへ隠れた命令を差し込むPrompt Injection、安全規則の回避、機密情報、不正なURL、悪意のあるファイルなどを検査できます。しかし検査規則を作っただけでは、すべての入力と出力が自動的に検査されるわけではありません。

確認すべきは、通信の方向、プロトコル、本文形式、ストリーミング、暗号化、例外経路です。Agent Gatewayとの統合でも、検査対象となる操作やpayloadはプロトコルごとに定義されています。

5.2 通信の検問表（Coverage matrix）を作る

難しい言葉に見えますが、Coverage matrixは「どの道に検問所があるか」の表です。

この表を作ると、二つの抜けが見つかります。

• 製品上は保護を設定したが、実際の通信がその経路を通っていない
• テキスト本文は検査したが、Tool結果、添付、ストリーム断片、別プロトコルが対象外

5.3 誤検知も見逃しも、業務影響として測る

安全性テストでは、危険な入力を止められるかだけでなく、正常な入力を壊さないかも確認します。

• 検出率
• 誤検知率
• 見逃し率
• 検査による遅延
• Mask後に業務が継続できる割合
• Block理由を利用者と運用者が理解できる割合

高感度にして正常業務の半分が止まるなら、安全装置として運用できません。逆に業務影響を恐れてすべて通せば意味がありません。安全と可用性を同じ評価表へ載せます。

6. Observability：ログの量ではなく、出来事を復元できるか

6.1 一つの依頼を最後まで追う

エージェントの応答は、一回のモデル呼び出しだけで作られるとは限りません。利用者の依頼、Gatewayの判断、Agentの推論、Tool呼び出し、データアクセス、内容検査、最終回答が連なります。

それぞれにログがあっても、時刻、主体、trace_id、対象資源が結び付かなければ、事故の因果関係を復元できません。

Agent tracingの公式資料では、OpenTelemetryのspanと実行グラフを確認できます。一方で、promptやresponse本文を無制限に保存すると、観測基盤へ機密情報を複製することになります。

そこで、証跡の設計にも最小化が必要です。

• 本文を保存するか、hashや分類だけにするか
• 何日保持するか
• 誰が閲覧できるか
• 機密情報をどこでMaskするか
• インシデント時にだけ詳細記録へ切り替えるか

また、Cloud Audit Logsでは、サービスによってData Access Logの既定状態が異なります。Data Access Logの構成をしていなければ、「ログが見つからない」は「アクセスがなかった」ことの証明になりません。

6.2 「証拠がない」を三つに分ける

調査でログが見つからないとき、少なくとも次の三つを分けます。

1. 本当に操作が起きなかった
2. 操作は起きたが、記録対象ではなかった
3. 記録されたが、保持期限、権限、検索条件のため見つからない

この区別がないと、ログの欠落を無事故の証明として扱ってしまいます。

ここまでの振り返り

Model Armorで「どの通信を検査できるか」を道ごとに確認し、Traceと監査ログで一つの依頼を後から復元する準備ができました。NovaSmartは、危険な内容を止める場所と、起きたことをたどる方法を持ち始めています。

次に残る問題：記録が取れても、その版を利用者へ出してよいとは限りません。次は、正常系・禁止系・運用品質をまとめた出荷判定へ進みます。

7. Evaluation：賢さの採点ではなく、出荷判定にする

ここでいうEvaluationは、Agentの回答へ感想点を付けることではなく、用意した試験ケースを実行し、期待した結果と経路になったかを検査する工程です。Agent evaluationでは、評価用データセットから実行を生成し、評価全体とケースごとの結果を管理できます。平均点を一つ出すだけでは、本番の判断には足りません。

7.1 結果と経路を分けて評価する

たとえば最終回答が正しくても、禁止されたデータを一度読んでから答えたなら、安全な成功とは言えません。

• 結果の評価：回答は正しいか、根拠に沿うか、役に立つか
• 経路の評価：許可されたToolを、許可された順序と主体で使ったか
• 安全の評価：機密、Injection、越権、危険な副作用を防げたか
• 運用の評価：遅延、費用、再試行、可用性が基準内か

7.2 平均値の裏にある失敗を見る

平均95点でも、次の一件が含まれればリリースできない場合があります。

• 100回に1回、別顧客の情報を返す
• 低頻度だが承認なしで注文を確定する
• 特定言語だけ安全規則を迂回する
• Tool障害時に、実行していない操作を成功と報告する

したがってrelease gateには、平均値だけでなく「一件でも起きてはいけない条件」を含めます。

8. すべてを一つの制御ループへ戻す

ここまでの仕組みは、次の循環として動かします。

flowchart LR
    A[発見] --> B[所有者と主体を確定]
    B --> C[経路と権限を制限]
    C --> D[入力・出力を検査]
    D --> E[実行証跡を収集]
    E --> F[評価と異常検知]
    F -->|問題あり| B
    F -->|基準を満たす| G[次版を公開]
    G --> A

台帳は一度作って終わりではありません。新しい版、新しいTool、新しい接続先、新しい利用者、新しい攻撃手法が入るたびに再評価します。

基礎編の到達点

ここまでで、発見、身元、経路、権限、内容検査、証跡、評価が一つの循環になりました。NovaSmartの目の前の問題へ対処する最低限の仕組みはそろいました。

ここから先は新しい製品紹介ではありません。同じ仕組みを本番で長く運用すると現れる、三つの難題を掘ります。第一に、正しい名札を持つAgentが利用者の弱い権限を迂回する問題。第二に、複数の判定点を矛盾なくつなぐ問題。第三に、ログを監査可能な証拠へ変える問題です。

9. 名札を分けても起きる事故：「混乱した代理人」を防ぐ

ここからは少し高度な話です。ただし、出発点は素朴です。

NovaSmartのPersonalization Agentへ、担当者が「この顧客群を見せて」と頼んだとします。Agent自身は全地域の顧客を分析できますが、担当者は自分の地域しか見られません。このときAgentが担当者の範囲を検証せず、自分の広い権限だけで検索すると、担当者はAgentを代理人として別地域の顧客情報を読めるかもしれません。

Agentが悪意を持ったのではありません。権限の強い主体が、権限の弱い依頼者の意図を十分に検証せず代行したのです。これは古くからある**confused deputy（混乱した代理人）**の問題が、自然言語とTool選択を通じて現れたものです。

9.1 「Agentに権限がある」と「この依頼で使ってよい」を分ける

認可判断には、Agentのprincipalだけでなく、利用者、目的、対象、操作、時点が必要です。

許可 = f(
  利用者,
  Agent Identity,
  業務目的,
  操作,
  対象資源,
  データ分類,
  時点,
  承認状態
)

この式は製品仕様ではなく、設計時に見落としを防ぐための考え方です。たとえば同じ顧客データでも、問い合わせ回答のための一件参照と、販促分析のための全件exportでは目的と危険度が違います。

式を数学として解く必要はありません。左から「頼んだ人」「代行するAgent」「仕事の目的」「しようとする操作」「対象」「機密度」「いつ」「承認済みか」を順に確認し、全部がそろったときだけ許可する、という点を読めば十分です。

9.2 三つの実行方式を使い分ける

何でも利用者委譲にすればよいわけではありません。夜間の自動処理には、その場で操作する利用者がいません。反対に、すべてAgent自身の広い権限にすると、利用者ごとの閲覧範囲を定めたアクセス制御（ACL）を失います。操作ごとに方式を選びます。

9.3 Tool descriptionを認可境界にしない

「このToolは管理者だけが使ってください」と説明文へ書くことは、モデルの選択を助けます。しかし、強制力のある認可にはなりません。Prompt Injection、モデル更新、Tool競合、実装ミスで選ばれる可能性があるからです。

説明文は誘導、Gateway policyは経路上の制御、IAMは資源側の制御です。高リスク操作ではさらに、業務ルールを決定的なコードで検査します。

10. 一つの許可では守れない：判定点をつなぐ

一つの依頼は、複数の判定点を通ります。

次の表は、上から下へ実際の通信順に読めます。入口で利用者を確認し、AgentからToolへの出口を確認し、Toolの引数を検査し、最後はデータに最も近いIAMと業務ルールで止めます。どこか一行が通ればよいのではなく、必要な行をすべて通過して初めて実行できます。

ここで重要なのは、すべてを同じ場所へ集約することではありません。むしろ資源に近い場所でも最終確認することで、上流の迂回や誤設定へ耐えます。これは、一か所が破られても次で止める**多層防御（defense in depth）**です。

10.1 AllowとDenyの理由を利用者向け・運用者向けに分ける

拒否理由を詳しく返しすぎると、存在する資源名や内部policyを攻撃者へ教える場合があります。逆に「エラーです」だけでは正規利用者が直せません。

• 利用者向け：何を変更すればよいか、安全な範囲で示す
• 運用者向け：どの判定点、規則版、主体、対象で拒否したか残す
• 監査向け：改ざん耐性、保持、閲覧制御を持たせる

同じ拒否でも、三者へ同じ情報を出す必要はありません。

10.2 Emergency stopを設計しておく

重大な問題を発見したとき、次のどの粒度で止められるかを事前に決めます。

• 特定Agentだけを停止する
• 特定Toolへの呼び出しだけを止める
• 書き込み操作だけを読み取りへ縮退する
• 特定の顧客組織（Tenant）や地域だけを隔離する
• すべての外向き通信を止める

共有principalや共有Endpointが多いほど、停止範囲が広がります。Identityと経路の分離は、平時の最小権限だけでなく、事故時に影響が広がる範囲（blast radius）を小さくするためにも必要です。

11. ログを集めるだけでは足りない：証拠へ変える

運用画面に大量のグラフがあっても、監査の問いへ答えられるとは限りません。Evidenceは、ある主張を支持または反証できる形で集めます。

たとえば「販促Agentは顧客表を読めなかった」という主張を証明するには、単なるerror messageでは弱い場合があります。

1. どのAgent Identityで試したか
2. どの時点のpolicyを使ったか
3. どのresourceとpermissionを要求したか
4. IAMがどの理由で拒否したか
5. 別経路や別Toolで到達できなかったか
6. 正規Agentの許可された処理は維持できたか

拒否だけを試すと、ネットワーク障害や認証失敗でも「拒否された」ように見えます。だから正常系と禁止系を同じ条件で対にします。

11.1 証跡そのものを守る

ログには、機密情報、利用者の依頼、Tool引数、業務データの一部が含まれます。観測基盤が新しい情報漏えい経路にならないようにします。

• 収集前に分類し、必要ならMaskする
• 本文ではなくhash、長さ、分類、参照IDを保存する
• 閲覧権限を開発者、運用者、監査人で分ける
• 保持期間と法的holdを分ける
• exportと二次利用を監査する
• 時刻同期と改ざん検知を用意する

「すべて記録すれば安全」ではありません。再構成に必要な情報を、最小限かつ信頼できる形で残すことが目的です。

11.2 SLOを二種類に分ける

可用性SLOだけでは、統制の劣化を見逃します。たとえば応答成功率99.9%でも、共有principalや証跡欠落が増えているかもしれません。

そこで、利用者と合意するサービス水準の目標であるSLOを、サービスSLOとassurance SLOに分けます。

次の表では、左を「利用者へ提供するサービスの健康」、右を「安全性を説明する仕組みの健康」として読みます。応答が速くても証跡が欠けていれば不合格であり、証跡が完璧でも業務が止まり続ければやはり不合格です。

二つを同じrelease判断と運用reviewへ持ち込みます。

12. 統制を止めない組織設計：Platform Teamだけに責任を集めない

エージェントの台帳やGatewayを共通基盤チーム（Platform Team）が運用しても、販促規程、顧客データの意味、許容できる誤りまで一つのチームでは判断できません。技術基盤を中央化しながら、業務上の責任は各業務領域へ分散します。

中央チームがすべてのAgentを手作業で承認すると、いずれボトルネックになります。反対に、各部署へ完全に任せると台帳、Identity、証跡がばらつきます。

よいPlatformは、次を「舗装された道」として提供します。

• 登録時にOwner、用途、データ分類を必須にするtemplate
• AgentごとのIdentity発行
• Gateway経由の標準接続
• 読み取り専用、要承認、実行可能といったpolicyの雛形
• 共通traceと監査保持
• release前の標準評価
• 期限切れ、Owner不在、重大失敗時の自動停止

業務チームは道の上で速く進み、例外が必要なときだけ追加reviewを受けます。

12.1 リスク段階を、Agentの名前ではなく行為で決める

「FAQ Agentだから低リスク」「Finance Agentだから高リスク」という分類だけでは粗すぎます。同じAgentでも、公開情報の要約と、顧客口座の変更では危険度が違います。

これにより、一体のAgentへ必要以上の強い制限をかけず、操作単位で制御できます。

12.2 Policy driftを運用上の変更として追う

コードを変更しなくても、IAM role、Gateway rule、Registry metadata、Model Armor template、接続先のACLが変われば、Agentの実効能力は変わります。

したがって、構成変更もreleaseと同じように扱います。

1. 変更前後の差を保存する
2. 影響するAgentと行為を列挙する
3. 許可・拒否の代表ケースを再実行する
4. 反映完了を観測する
5. 問題時に前版へ戻せるようにする

Agent codeの版だけを記録しても、実際の挙動を再現できない理由がここにあります。

高度な論点の振り返り

正しいIdentityを持つことは出発点にすぎません。利用者の目的まで含めて認可し、複数の判定点を通し、正常系と禁止系を対で試し、その結果を改ざんされにくい証拠として残す必要があります。さらに、業務判断を各部門が担える仕組みにしなければ、中央Platform Teamが承認待ちの列を作ります。

次に残る問題：この考え方を日々の運用へ落とすには、抽象的な「安全にする」ではなく、守る約束、測る指標、事故時の動きを明文化する必要があります。

13. 本番で守る約束

製品名ではなく、検証できる約束として書くと設計レビューがしやすくなります。

監視したい指標

ここでいうp95遅延は、100件中おおむね95件が収まる応答時間です。平均だけでは隠れやすい「遅い側の体験」を見るために使います。

• 実行中だが未登録のAgent数
• 所有者不明の継続時間
• 共有principalの数
• 正規Gatewayを迂回できるEndpoint数
• 検査対象外の通信パターン数
• 重要操作でtraceを最後まで結べた割合
• 誤検知率と見逃し率
• 拒否すべき評価ケースの通過数
• ポリシー変更が期待結果へ収束するまでの時間

14. 事故対応でどう使うか

NovaSmartで発見した問題を、本番の事故調査としてもう一度たどります。「顧客情報が許可なく検索された疑い」が通報された場面です。

1. Audit Logから対象資源、操作、principal、時刻を特定する
2. principalからAgent IdentityとAgent resourceをたどる
3. Registryから所有者、版、Endpoint、接続可能なToolを確認する
4. traceで依頼、Gateway判断、Agent、Tool呼び出しを復元する
5. delegated userと認可コンテキストを確認する
6. 内容検査の判定と適用テンプレート版を確認する
7. 同じ条件を評価データへ追加し、修正後に回帰試験する

共有principal、共通traceの欠落、Data Access Logの未設定があると、この途中で調査が止まります。ガバナンス設計は、平時の一覧画面より、事故時に問いへ答えられるかで評価すべきです。

15. 導入するなら、どこから始めるか

まず見つける

実行基盤、到達可能Endpoint、Registry、実利用を照合します。最初から完璧な分類を作るより、所有者不明と未登録を検出することを優先します。

次に主体を分ける

Agent単位のIdentityへ移し、長期Credentialと共有principalを減らします。正規処理が通る試験と、越権処理が拒否される試験を対にします。

経路を閉じる

Gatewayを必須経路にし、直接Endpoint、代替プロトコル、未知の送信先を洗い出します。IAMは資源側の最終防衛線として残します。

検査範囲を測る

Model Armorなどの設定名ではなく、実トラフィックの方向と形式ごとにcoverageを確認します。正常業務への影響も同時に測ります。

証跡と出荷を接続する

ログを集めるだけで終えず、評価失敗、ポリシー違反、未登録資産をrelease gateや是正フローへ接続します。

16. よくある誤解を短く解く

「Registryに載っているから安全」

Registryは所有と能力を説明する入口です。実行主体、権限、経路、検査、実際の挙動まで安全だとは証明しません。

「サービスアカウントを分ければ監査できる」

主体の分離は必要です。ただし利用者、所有者、trace、対象資源、ポリシー版まで結べなければ、業務上の因果関係は不足します。

「GatewayがIAMを代替する」

Gatewayは呼び出し経路、IAMは資源操作を主に守ります。片方だけでは閉じません。

「Model Armorを有効にすれば安全」

設定の存在ではなく、必要な通信が実際に検査点を通り、期待する違反を止め、正常処理を壊さないことを試験します。

「ログがないので何も起きていない」

記録対象、保持期間、閲覧権限、検索条件を確認するまで結論にできません。

「評価の平均が高いので公開できる」

低頻度でも重大な越権や情報漏えいは、平均に埋もれます。出荷不可条件を別に持ちます。

17. 実務チェックリスト

台帳

• 実行中、登録済み、到達可能、実利用を別々に取得できる
• Agent、Endpoint、Tool、Skill、Publisherの関係をたどれる
• 所有者、用途、データ分類、ライフサイクルがある
• 未登録と廃止済み残存を継続検出する

主体と権限

• Agentごとに実行主体を分けている
• 長期鍵と共有Credentialを減らしている
• 所有者、Agent、利用者を区別して記録する
• 許可試験と拒否試験を対で持つ
• 読み取り権限と外部送信能力を組み合わせて評価する

経路と内容検査

• Gatewayを通らない経路を把握している
• プロトコル、方向、形式ごとの検査範囲を持つ
• Tool結果や添付も検査対象として検討した
• 誤検知、見逃し、遅延を測っている

証跡と評価

• 依頼からデータ操作まで共通traceで追える
• Data Access Logの設定と保持を確認した
• 本文の保存を最小化し、閲覧権限を制御した
• 結果だけでなくTool経路も評価する
• 高リスク失敗を平均値から分離した

おわりに

Day 2のPlatform Builders Trackが教えてくれたのは、エージェントを増やす前に「統制製品を全部入れよう」という話ではありません。

まず、誰がいるかを知る。次に、一体ずつ名札を分ける。正規の入口を通し、部屋ごとの鍵を渡し、危険物の検査点を置く。そして、どの依頼がどの行為になったかを後から説明できるようにする。

この順序なら、ガバナンスは開発速度を止める壁ではなくなります。安全に任せられる範囲を明確にし、エージェントへより大きな仕事を渡すためのプラットフォームになります。

公式資料

• Gemini Enterprise Agent Platform overview
• Agent Registry overview
• Register agents
• Agent Identity overview
• SPIFFE Overview
• IAM principals overview
• Agent自身のAuthorityで認証する
• Agent Gateway overview
• IAM Deny policies
• Model Armor overview
• Model ArmorとAgent Gatewayの統合
• Cloud Audit Logs overview
• Data Access audit logsを構成する
• Agent tracing
• Evaluate agents