9月16日、ÖZGÜR SALGINCIが「Gemini Enterprise Is Becoming an Agent Operating System」と題した記事を公開した。GoogleのGemini Enterpriseエコシステムが、AIエージェントを動作させるためのOSに相当する基盤層へと変化しつつあるという構造的な分析だ。
Computer UseとShell sandboxのGAが示す転換点
この記事の出発点になったのは、2026年9月9日のGemini Enterprise Agent Platformのリリースだ。
中でも著者が最も重視するのが、Computer UseとShell sandboxのGA（一般提供開始）である。
- Computer Use：エージェントがブラウザを操作できる
- Shell sandbox：エージェントが隔離されたLinux環境でコマンドを実行し、ファイルを操作できる
テキストを生成するだけのエージェントと、実際にコンピュータを操作できるエージェントは、リスクの次元が根本的に異なる。モデルが生成したコードが本番インフラ上で直接走ったり、内部システムへの無制限なアクセス権を持つブラウザセッションが動き回ったりする事態は避けなければならない。
Shell sandboxは管理された隔離Linuxコンテナとして実装されており、コマンドはそのコンテナ内で実行される。
Agent
|
v
Policy / Gateway
|
v
Isolated Sandbox
/ \
/ \
v v
Shell Sandbox Computer Use
| |
└──────┬──────┘
|
v
Controlled Access
to the Enterprise
同日のアップデートでは、Agent GatewayがVPC Service Controlsのペリメータルールを適用できるようになった点も見逃せない。VPC Service Controlsはもともとクラウドリソースを保護するための仕組みだが、それを「自律的なソフトウェアエンティティ同士の通信」に適用するというのは、明確なアーキテクチャの転換点だ。
「チャットボット問題」から「分散システム問題」へ
エンタープライズ向けGenAIの第一世代は、ユーザーが質問し、モデルが答えを返す、シンプルな構造だった。
しかし現在、エンタープライズAIのアーキテクチャは大きく変わっている。エージェントは企業データにアクセスし、ツールを使い、APIを呼び出し、別のエージェントを呼び出す。そうなると途端に、モデルの性能よりもモデルの「周囲」に何を置くかが重要になる。
著者のSALGINCI氏はこう問いかける。
- このエージェントは誰か？
- 何にアクセスできるか？
- どこで実行されるか？
- 危険な出力を生成したらどうなるか？
- 組織内にすでに同じエージェントがあるか？
これらはインフラエンジニアが毎日扱う問いだ。「チャットボットをどう作るか」とは全く異なる。
なぜ「Agent OS」という概念が出てくるのか
SALGINCI氏は「Agent Operating System」は自分の解釈であり、Googleの製品名ではないと明確に断ったうえで、このアナロジーを使う。
従来のOSがアプリケーションに対して「実行・分離・ネットワーク・リソースアクセス・セキュリティ境界」を提供するように、エンタープライズエージェントには以下が必要だ、という整理だ。
Agent
|
┌──────────────┼──────────────┐
| | |
Identity Discovery Execution
| | |
Security Registry Sandbox
| | |
└──────────────┼──────────────┘
|
Communication
|
Gateway
|
Observability
※編集部の考察：上図はSALGINCI氏の論旨を視覚化したものであり、元記事に同等の図は存在しない。
それぞれを個別のチームが独自に解決するのではなく、共通インフラとして提供するのがGemini Enterprise Agent Platformの方向性だ、と著者は見る。
銀行の例で見るインフラ問題の具体像
記事では、大手銀行がAIを使った顧客オンボーディングプロセスを構築するシナリオが示されている。
Customer
|
v
Onboarding Agent
|
+----> Identity Verification Agent
| +----> Document Tools
|
+----> Risk Agent
| +----> Risk Data
|
+----> Compliance Agent
| +----> Regulatory Systems
|
+----> Banking API Agent
+----> Core Banking APIs
このアーキテクチャを前にすると、問いは一気に具体化する。
- Risk AgentはRiskデータベースへのアクセス権を誰が許可するのか？
- Compliance AgentはBanking API Agentを呼び出せるのか？
- 別の事業部門が所有するエージェントとOnboarding Agentは通信できるのか？
- あるエージェントが侵害されたら何が起きるか？
- ワークフロー全体をどうトレースするか？
これはもはやチャットボットの問題ではなく、自律的な意思決定を内包した分散システムの問題だ。
Agent Identity、Registry、Gatewayが揃う意味
著者が注目するのは、個別機能の有用性ではなく、これらが一つの整合的な基盤層を形成しつつあるという点だ。
- Agent Identity：「どのアプリケーションがリクエストしたか」ではなく「どのエージェントが、どの権限で、どの意思決定をしたか」を問えるようにする
- Agent Registry：エージェントが数百・数千規模になったとき、何が存在し、誰がオーナーで、どれが承認済みかを把握するためのカタログ。サービスカタログやAPIカタログと同じ問題意識だ
- Agent Gateway：A2A（Agent-to-Agent）やMCP（Model Context Protocol）でエージェント間通信が標準化されても、「どの通信を許可するか」のガバナンスが別途必要になる。Gatewayはその制御点になる
Gemini EnterpriseとGemini Enterprise Agent Platformは別物
記事の冒頭でSALGINCI氏は用語の整理をしている。
- Gemini Enterpriseアプリ：従業員向けのエクスペリエンス。エージェントの発見・作成・共有・実行の場（詳細）
- Gemini Enterprise Agent Platform：開発者向けのプラットフォーム。Vertex AIの進化形として位置づけられ、エージェントのビルド・スケーリング・ガバナンス・最適化を担う
「Gemini EnterpriseアプリがAgent OSになった」という話ではなく、エコシステム全体がエージェントの動作基盤を提供し始めているという観察だ。
詳細はGemini Enterprise Is Becoming an Agent Operating Systemを参照していただきたい。
