“シャドー AI エージェント”を統制せよ！Google Cloudで作る「次世代エージェント基盤」

利便性の裏に潜む、シャドー AI エージェントの台頭リスク

　AIエージェントとは、与えられたゴールを達成するために、①環境を認識し（ユーザーの要望や必要なデータの所在など）、②LLMで推論・意思決定し、③何らかの行動に移す──これらを自律的に行う。さらに全体を見て④学習・適応することで、結果的にはゴール達成させるものを指す。

　技術的には「LLMを推論エンジンとして使い、目的に向けて様々なツールを呼び出す実行単位」とも言える。ユーザーがゴールをインプットすると、エージェントは何かしらの計画を立て、ツールやAPIを駆使して、最終的な結果に帰着する。チャットボットとの大きな違いは「答える」だけではなく、「実行する」ところだ。

　今では誰もが簡単にAIエージェントを作れるようになり、便利なエージェントが次々と誕生し、現場の生産性は爆上がりしている。グーグル・クラウド・ジャパン 関本信太郎氏は「大エージェント時代」と呼ぶ。

　その一方、新たな課題も生まれてきている。たとえば、企業のシステム管理者の目が届かないところで勝手に動くシャドーAIエージェント。個人のアカウントで作られ、会社から承認されてない外部APIを使うなど、独自ルールで動いていたりする。今のところ「便利だからいい」と見過ごされがちだが、放置したままではどのような悪影響があるか考えてみよう。

　大枠でとらえると、AIエージェントもアプリケーションの一種と考えることができる。では、何が違うのか。一般的なアプリケーションはインプットから固定のロジックを経てアウトプットを導き出すのに対して、AIエージェントは先述したように、推論・実行後に再判断・再実行する可能性もあるため、途中経過や結果は必ずしも同じとは限らないという性質を持つ。

　またAIエージェントは各種ツールを駆使することで、従来の生成AIのような「回答者」から「実行者」へと変貌を遂げている。なお、この場合のツールというのは、検索、クエリ、更新など、API、データベース、SaaS、何らかのコード実行などを指す。

　そうしたことから関本氏は「エージェント設計は、APIの設計だけではなく、何ができるかの権限設計、何を実行したかの監査設計が重要になります」と強調した。

　AIエージェントは同じ依頼でも、異なる経路を取る可能性があるため、そこはリスクととらえることができる。AIエージェントの利便性が高まり、重要なデータを扱えるようになるほど価値は高まるものの、リスクも同時に大きくなる。ただし関本氏は「だから危険ととらえるのではなく、毎回同じ経路をたどらないという特徴を鑑みた上で、ガードレールを敷くことや、監査や再現性の設計が重要になります。出力品質だけではなく、安全性のためには実行経路の説明可能性を担保することが大事です」と念を押す。

禁止は逆効果に　“開発者も喜ぶ”セキュリティ統制は？

　シャドーAIエージェントを野放しのままでは企業のリスクになりかねない。しかし、ただ禁止するのでは逆効果になりかねず「公式ルート（Golden Path）」を提供することが解決策となる。

　ここで役立つのが「Platform as a Product」となるプラットフォームエンジニアリングの発想だ。開発しやすいプラットフォームとガバナンスを両立させる。つまり「早く作りたい・自由に試したい・業務に組み込みたい」という開発者の体験を向上させつつ、「権限を絞りたい・監査したい・安全に運用したい」という統制もできるようにするのだ。

　仮にプラットフォームエンジニアリングがない状態では、本番に出すところで詰む。なぜなら、欲しいものは作れるのでPoCまでは進むものの、チームごとに作り方が違う、ツールの権限が属人化している、ログが追えない、評価基準がないなど、運用設計の欠如で行き詰まってしまうためだ。

　公式ルートを作るということは、承認済みのLLMやツール、権限や評価のテンプレートを提供し、デプロイ標準をAIエージェントに合わせてアップデートすることになる。

　具体的には次のようなものが必要になる。1点目は「Developer Portal」、ここに承認済みのツールやガイドラインを明示する。2点目はセキュアなひな形となる「Template」。権限設定やログ出力が標準装備されたもので、開発者はこれを使えばすぐに開発に着手できるようになる。3点目は「Deploy」、セキュリティレビューの自動化と、標準化されたCI/CDパイプラインで即時公開できるようにする。4点目は透明性の高い監視となる「Observe」で、プロンプトの実行ログ、ツール呼び出し履歴、コストや遅延を一元管理できるようにする。5点目は「Improve」、本番データから精度を監視しながらチューニングを継続していく。

　プラットフォームチームが設計するのは、AIエージェントのインフラ基盤（実行ランタイムやネットワーク）、ID、ゲートウェイ、オブザーバビリティなどになる。

　インフラ基盤は、マネージドプラットフォームとDIYエージェントプラットフォーム、2つの選択肢がある。前者は標準的なマネージドサービスを使い、簡単かつ安全に構築。後者はKubernetesなどのインフラ上に独自構築する。

　Google Cloudで構築するのであれば、一番簡単な方法として関本氏が挙げたのがマネージドプラットフォームで必要な機能が集約された「Gemini Enterprise Agent Platform（以下、Agent Platform）」だ。DIYエージェントプラットフォームで進めるなら、Google CloudのKubernetesとなるGKEを使う選択肢もある。

　Agent Platformには、ビルドに必要なテンプレートやフレームワークのほかにも、エージェントを実行するランタイム、ガバナンスを効かせるためのエージェントの各機能、そして最適化を進めるためのオブザーバビリティ機能などが盛り込まれている。

セキュアな次世代エージェント基盤を実現するための機能を紹介

　Agent Platformで主要な機能をピックアップしよう。まずは実行基盤となる「Gemini Enterprise Agent Runtime」だ。AIエージェントを本番環境に簡単にデプロイできて、自動でスケールもできるフルマネージドなプラットフォームだ。AIエージェントのフレームワークはGoogleのAgent Development Kitだけではなく、LangChainなどオープンなフレームワークや、Pythonでの実行もサポートしている。

　関本氏は「デプロイしたら、自動的にオブザーバビリティ機能と連携、コード実行のためのサンドボックス、コンテキスト管理のためのマネージドなメモリなども簡単に使えるのがいいところです」と話す。

　逆にあえてDIYが必要なケースとなるのは、業務ロジックから必要なときにエージェントを使えるように既存アプリに組み込むとか、エージェントネイティブなアプリを作るようなケースだ。DIYならエージェント単体ではなく、周辺システム全体を設計し、同じプラットフォームに載せられるのが強みとなる。

　ここからはセキュアなエージェントプラットフォームを簡単に実現するための機能を列挙していく。

Agent Identity

　エージェントにアイデンティティを持たせるための機能だ。ここでは「SPIFFE」というワンタイムのアイデンティティを使う。特徴はエージェントそのものとして振る舞うことと、エンドユーザーとして振る舞うこと、両方できるので2つの顔を持つ。加えて、ネットワークアイデンティティのレベルのポリシーを適用することも可能だ。

　ここで重要になるのが「エージェントを誰として動かすか」を定義できるところだ。それぞれのエージェントを実行主体として扱い、追跡可能な固有のアイデンティティを持たせることで、「誰の委任で、どのエージェントが、どのツールにアクセスしたか」などを追跡できる。

Ambient Networking（現在はプレビュー版）

　Kubernetesのサービスメッシュ機能。エージェント同士やエージェントとツール間の通信を安全にする仕組みで、サービス検出、サービス接続、認証、可観測性を簡素化する。主にDIYエージェントプラットフォームのときに有効になる機能と言える。

Agent Gateway

　ユーザーからのアクセス、またはエージェント通信の入口に検問のような形で置くことで、統一的なデータのポリシーを適用することができる。なお使い分けとしては、エージェント間の通信はAmbient Networking、外部との通信の入口はAgent Gatewayが担う。

Agent Observability

　繰り返しになるが、AIエージェントの実行パスは非決定的なので、再現性やデバッグが課題となる。そこで「Agent Observability」は、OpenTelemetryプロトコルを使用してオブザーバビリティ機能を付与することで、エージェントからトレース、メトリクス、ログを自動的に収集できるようになる。これにより、エージェント間やエージェントとツールの接続を可視化したり、どのような動きをしているのかを追跡したりすることが可能となる。

　AIエージェントのオブザーバビリティで重要なのは結果だけでなく、経路を見ることだ。ガバナンスの観点だけではなく、不要なツールを多数呼び出していないか、遅いツールはないかをチェックすることで品質を安定させ、不審な挙動がないかといった監査にも有効となる。

Model Armor

　あらゆる経路からのAIエージェントの保護に有効なのが「Model Armor」だ。プロンプトインジェクションのように悪意あるユーザーがプロンプトにコードを埋め込むことでシステムを破壊する攻撃から保護したり、危険・不適切・有害コンテンツを排除したり、個人識別情報をマスキング・遮断したり、悪意あるファイル・ドキュメントや危険なURLをブロックしたりする。

　このModel Armorを先述したAgent GatewayやGoogle CloudのGatewayなどと連携させることで、インプットの無害化や遮断ができて安全性を高められる。関本氏は「これらは予防的な防御なので、完ぺきに防げるわけではありませんが、様々なレイヤーでかけておくことが重要で、役立ちます」と話す。

GKE Agent Sandbox

　DIYエージェントプラットフォーム向けの機能で、LLMがコードを生成し、エージェントが実行するとき、安全ななかでコードを実行する。オープンソースとして提供されているものを拡張してGKEに実装している。一般的にサンドボックスは必要になってから起動するため時間がかかりがちだが、あらかじめ起動済みのサンドボックスを用意しておいて、リクエストが来たら即座に割り当てられるので、低レイテンシを実現できている。

Pod Snapshots

　AIエージェントが何か実行している間にユーザーが離席するとき、課金されないようにいったん止めることでコストを節約する。ユーザーが戻ってきたらPodをリストアして作業再開する。

　さて、これまでGemini Enterprise Agent RuntimeとGKEの両方に言及してきたので「どちらがいいだろう」と悩むかもしれない。関本氏は「両方提供し、使いやすいプラットフォームを目指すといい」と勧めた。基本的なエージェントはAgent Runtime、既存アプリにエージェントを組み込むならDIY（GKE）といった具合にどちらも公式ルートとして選べるようにするということだ。

　最後に関本氏は「エージェント時代の競争力は、個別のエージェントではなく、安全に届け続けるようなクラウドネイティブなエージェントプラットフォームとなるでしょう。Agent Platformでエージェントの開発・実行・統制を標準化し、一方、複雑な業務組み込み・独自推論基盤・細かな実行制御が必要な領域にはGKE/Kubernetesで補完することで、安全かつ素早くエージェントを作れるようにするといいと思います」と述べた。