はじめに
エージェントを選ぶとき、何を見るべきでしょうか。
2026年10月8日、Google Cloudが、企業向けの単一のエージェント「Gemini agent」を発表しました。この発表から読み取れる答えは、モデルの賢さより、統制をどこに置くかです。
理由は、次の流れです。エージェントとモデルが別々の選択になり、下のモデルは、仕事ごとに入れ替わるようになりました。モデルが入れ替わるなら、ID・権限・監査・境界・予算といった統制は、モデルではなく、エージェントの層に置くことになります。
エージェントの層(ハーネス)とモデルの違いは、以前の解説記事で書きました。今回は、その考え方が、製品の設計としてどう現れたかを見ていきます。
何が発表されたのか
発表は、Google Cloudの年次イベント「Gemini at Work 2026」の基調講演(10月8日)で行われました。詳細な公式ブログは、翌9日付で公開されています。
Gemini agentは、質問への回答、知識作業、画像やメディアの生成、コードの作成と実行までを、1つのエージェントと1つのAPIで担う、とされています。
Workspace(Gmail、Drive、Docsなど)の中でも動きますが、Workspaceに閉じた製品ではありません。公式ブログによると、Workspaceのほか、Microsoft 365、Slack、コマンドラインなど、さまざまなチャネルから使え、APIを通じて他社のアプリに組み込む「ヘッドレスエージェント」としても動作します。接続先は、Confluence、Microsoft Office、Teams、Slack、Git、Jira、Salesforce、ServiceNow、BigQuery、Databricks、Postgres、Snowflakeなどで、任意のMCPサーバーにも対応します。
なお、Googleには、開発者向けのエージェント環境として、すでにAntigravityがあります。今回のGemini agentは、企業の仕事全般を担う別のレイヤーで、両者の関係は、公式ブログには書かれていません。
エージェントとモデルを分ける設計
公式ブログに、次の一文があります。
Gemini is the agent, and the model underneath it is a separate choice.
エージェントはGeminiで、その下のモデルは別の選択、という意味です。仕事ごとに最適なモデルを選んで使う設計で、現時点では、GoogleのGeminiファミリーと、AnthropicのClaudeを使い分けます。将来は、ほかの非公開・オープンなモデルにも広げる、とされています。
これは、Googleだけの動きではありません。4社の「エージェントの層」と、モデルの関係を、公式の情報から整理すると、次のようになります。
| 会社 | ハーネス(主な製品) | ハーネスとモデルの関係 |
|---|---|---|
| OpenAI | Codex、Agents API(Codexと同じハーネスを、APIとして提供) | OpenAIのモデル向け。Codexのハーネスは、オープンソース。他社モデルへの対応は、確認したページに記載なし |
| Anthropic | Claude Code、Agent SDK、Managed Agents | Claudeに強く結びつく設計(「モデルの進化に合わせて、ハーネスの前提を見直す」)。他社モデルへの対応は、確認したページに記載なし |
| Antigravity(開発者向け)、Gemini agent(企業向け) | 開発者向けは、Geminiに最適化。企業向けは、GeminiとClaudeを使い分ける | |
| xAI | Grok Build | 標準はGrok。設定で、任意のモデルを指定できる。ハーネスは、Apache 2.0で公開 |
共通しているのは、4社とも、ハーネスを、モデルとは別の製品として出していることです。ただ、結びつきの強さには差があります。Anthropicは、ハーネスをClaudeの進化に合わせて育てる方向です。xAIは、ハーネスを公開して、モデルを差し替えられるようにしました。Googleは、開発者向けではGeminiに最適化し、企業向けではマルチモデルにする、と層で分けています。
(出典: OpenAI Agents API、Anthropic Agent SDK・Managed Agents、Google I/O 2026 開発者向けまとめ、xAI ドキュメント。いずれも各社の公式ページです。)
だから、統制はエージェントの層に置く
モデルが仕事ごとに入れ替わるなら、ID、権限、ログ、通信の制限を、モデルごとに作るわけにはいきません。統制は、どのモデルが動いていても変わらない場所、つまりエージェントの層に置くのが自然です。
Googleの公式ブログのセキュリティとガバナンスの節は、まさにその設計です。エージェントの統制を、次の4つの問いに整理しています。
- エージェントは誰か(ID): エージェントごとに、暗号学的に証明されるIDを持ち、従業員のように管理される。権限は最小限に絞る。
- 何を許可されているか(権限): 役割ベースの細かい権限を、セキュリティ管理者が承認する。外部システムとは、OAuthなどの標準で、IDを伝播する。
- 何をしたか(監査): すべての操作が、人ではなく、エージェントに帰属する監査証跡に残る。リアルタイムで監視できる。
- 何に、絶対に触れさせないか(Agent Gateway): AI向けのネットワークファイアウォール。エージェントの実行は、独自のネットワーク境界を持つ「Agent Sandbox」の中で行われ、受信・送信・エージェント間のすべての通信が、このゲートウェイを通る。ポリシーは1回書けば、全エージェントに適用される。
VPCの設計、IAM、監査ログ、ファイアウォールと、考え方は、ほぼそのままです。エージェントが人のように振る舞う時代に、人と同じ統制を、エージェントにもかける、という設計が、製品の標準機能として語られた点が重要です。
予算の統制も、同じ流れです。プロジェクト単位で、AIの利用額にハードな上限をかけられます。上限に達すると、そのプロジェクトのエージェントは一時停止し、コンソールからワンクリックで再開できます。トークンの使用量と、サンドボックスの費用を監視し、プロジェクト単位なので、部門への課金の振り替えもできる、とされています。
(出典: Google Cloud公式ブログ、blog.google の発表ページ)
ほかの話題も、同じ方向を向いている
今週のほかのニュースも、「統制をどこに置くか」という視点で並べると、つながって見えます。
OneTrustが「CORIE」を発表(9月29日): AIエージェントの統制のための共有レイヤーです。ポリシーを、ツール呼び出しの時点で適用し、許可・停止・人によるレビューへの回付を判断します。エージェント、リクエスト、目的、結果、適用したポリシーを、記録として残す、とされています。エージェントの層で止めて、証跡を残す、という方向は、Googleの発表と同じです。同社の調査として、87%の組織がエージェントの利用を進める一方で、明確な統制・監督体制があるのは47%、という数字も出ています。ただし、これはベンダー自身の調査です。(出典: OneTrust公式発表)
GitLabの「AI Gateway」に重大な脆弱性(10月2日にパッチ公開): 統制の入口になる部品自体も、守る対象だ、という例です。自社ホスト型のAI Gatewayに、CVSS 9.9の脆弱性(CVE-2026-90970)があり、回避策はなく、対策はパッチの適用です。攻撃には、Duo Agent Platformの権限を持つ認証済みのユーザーが必要とされています。AI Gatewayは、GitLab本体とは別にバージョン管理されているため、本体だけを更新して安心せず、AI Gatewayの側も確認しておきたいところです。(出典: GitLabのパッチ情報、BleepingComputer)
オランダのDIVD、AIエージェントが関与した侵害を公表: 統制のないエージェントは、攻撃側にも使われる、という例です。脆弱性の開示を行う非営利団体DIVDが、ヘルプデスクソフト「Zammad」の未知の脆弱性2件を連鎖させた不正侵入を受けた、と公表しました。DIVDは、この侵入にAIエージェントが関わっていた、との分析を示しています。侵害の発生は9月21日で、AIエージェントの関与が報じられたのは、10月に入ってからです。発生日と報道の時期は、分けて読む必要があります。細かい攻撃の手口は、DIVD自身の説明を確認できた範囲にとどめます。(出典: DIVDの公表ページ、BleepingComputer)
確認しておきたい点
発表の勢いに対して、確認できていない点もあります。
- 提供時期と価格: 公式ブログには、Gemini agent本体の提供時期や価格の記載がありません。書かれているのは、業界別の特化版(金融・法務)がプレビュー、政府・医療・小売は近日対応、ということだけです。
- 報道: 9to5Googleは、現在はプライベートプレビューで、Workspaceの一部のBusiness・Enterpriseプランに、近日中に広く提供される、と伝えています。ただし、これは報道で、Google自身の記載ではありません。調査会社のFuturumは、「ほとんどの発表について、価格と一般提供の日付は、公表されていない」と指摘しています。
- 事例の数字: 公式ブログの導入事例の数字は、Googleの発表によるものです。
(出典: 9to5Google、Futurum)
インフラ現場にとっての意味
先週取り上げたAWSの診断エージェントは、インフラの診断という専用の用途でした(前回の週刊)。今回のGeminiは、仕事全般を担う汎用のエージェントです。用途は違いますが、どちらも、導入の入口で問われるのは「AIに何を許可するか」でした。
エージェントは、モデルが賢いかどうかよりも、統制をどう設計するかで、使えるかどうかが決まります。そして、モデルが入れ替わる前提なら、その設計は、モデルの外側に置くことになります。
もし自社でエージェント基盤を検討するなら、製品を問わず、次の点を確認しておきたいところです。
- エージェントごとのIDと、ロール(最小権限)を、どう設計・管理するか
- ネットワークの境界と、通信の許可・遮断のポリシーを、どこに置くか
- 監査ログを、どこに残し、誰が、どう見るか
- 予算の上限を、どの単位(プロジェクト、部門)でかけるか
- 統制の入口になる部品(ゲートウェイなど)の、更新と脆弱性の管理を、誰が担うか
- データやログの扱い(保持、利用目的)が、公式に明記されているか
結局、エージェントも、ネットワーク設計とアクセス制御と予算管理次第です。長年のインフラの経験が、この分野でも活きる場面だと思います。
次のアクション
Gemini agentの提供条件が公式に示されたら、まず、検証用のプロジェクトで、IDと権限、ゲートウェイ、予算上限の挙動を、確かめるのが現実的です。それまでは、上の確認項目を、自社の設計に当てはめて、棚卸ししておくのが、有効だと思います。
今週のもう1つの話題:テックレイオフの集計
トラッカーのSkillSyncerによると、10月9日更新の時点で、2026年のレイオフは519件、影響を受けた人は225,122人、そのうち41%がAIや自動化を理由に挙げている、とされています。集計は、報道や企業の発表、提出書類などに基づくもので、集計方法が異なる他のトラッカーとは、数字が一致しません。数字だけで不安になるより、「どの職種の需要が伸びているか」とセットで見るのが、現実的です。統制の設計は、まさに、人が担う仕事として残る領域です。(出典: SkillSyncer)
コメント