Gemini エージェントとは｜企業向け機能と Agent Gateway の注意点

はじめに

Google Cloud は 2026 年 10 月 8 日（米国時間）、イベント「Gemini at Work 2026」の基調講演で、企業の業務向けに設計した汎用 AI エージェント「Gemini エージェント」を発表しました。質問への回答だけでなく、資料作成やデータ分析、コードの作成と実行まで、1 つのエージェントに任せることを目指した製品です。

一方で、「これまでの Gemini と何が違うのか」「個人向けの Gemini Spark とどう違うのか」が分かりにくい発表でもあります。また、エージェントが社内システムや外部サービスへ自律的にアクセスする以上、企業で導入する際は通信の統制や権限管理が欠かせません。本記事では、発表内容の整理から始め、後半でインフラ担当者向けに Agent Gateway の仕組みと導入上の注意点を解説します。

本記事の情報は 2026 年 10 月 9 日時点で確認した公式情報に基づきます。発表直後のため、提供状況や仕様は今後更新される可能性があります。

結論として、Gemini エージェントは「質問に答える AI」から「目的を渡して仕事を任せる AI」へ進めた企業向けの製品で、個人向けの Gemini Spark とは管理機能と接続先の範囲が大きく異なります。企業で使う場合は、エージェントの外向き通信を Agent Gateway で許可制にする設計が基本ですが、Gemini Enterprise では対応モードや配置リージョンに制約があり、ゲートウェイを経由しない通信もある点に注意が必要です。Gemini エージェント自体の提供開始時期や料金は、確認時点で公式に示されていません。

Gemini エージェントとは｜発表内容と何ができるか

Gemini エージェントは、質問応答、ナレッジワーク、画像・メディアの生成、コードの作成と実行を、1 つのエージェントと 1 つの API で提供する業務向けの汎用エージェントです。基調講演では、指示ではなく目的を渡し、完成した成果物を受け取る使い方が示されました。

Google が発表した主な機能

基調講演の発表を、機能ごとに整理します。いずれも Google の発表内容で、提供時期は個別に示されていないものが大半です。

従来の Gemini との違い

Gemini にはこれまでも、個人向けの Gemini Spark のように、バックグラウンドで作業を進めるエージェント機能が提供されてきました。ただし、多くの利用場面では、ユーザーが質問や指示を入力して回答や文章を受け取る対話型の使い方が中心でした。

今回の Gemini エージェントは、こうした自律実行を企業の業務向けにまとめた点が特徴です。目的を受け取ったエージェントが作業を計画し、社内システムや業務 SaaS を使い分けて成果物を返し、作業はクラウド上で継続して必要に応じてサブエージェントへ分担されます。さらに、企業の管理者がエージェントの ID、権限、通信、費用を統制する仕組みが一体で提供される点が、個人向けの製品との大きな違いです。

業務での利用例

次の 2 つの例のうち、1 つ目は Google が基調講演で示した例、2 つ目は本記事が説明のために用意した想定例です。

Google が示した例: 会議調整と報告資料の作成

「来週、いつもの地域イベント担当者と会議を設定して」と依頼すると、Gemini が Chat スペースのメンバーや前回イベントのスレッドから対象者を特定し、予定を確認したうえで日程調整のメールを始めます。また、上司から最新状況をスライドで求めるメールが届くと、Workspace がそれを委任可能なタスクとして認識し、1 クリックで Gemini に任せる選択肢を表示します。

想定例: インフラ運用の週次報告

運用チームが「先週の障害チケットを集計し、再発傾向と対策案を週次報告書にまとめて」と依頼する使い方です。ServiceNow や Jira との接続は発表に含まれていますが、この一連の流れを Google がデモしたわけではありません。実際に使う場合は、接続先ごとの権限設計と、後述する通信統制が前提になります。

個人向け Gemini・Gemini Spark との違い

Google には、個人向けの Gemini アプリと、2026 年 5 月の Google I/O で発表された個人向けエージェント「Gemini Spark」があります。今回の Gemini エージェントは、これらとは別に企業向けとして発表されたものです。

個人向けと企業向けの位置付けの比較

公式情報で確認できた範囲を整理します。確認できなかった項目は「未確認」としています。

Gemini Spark の紹介ページでも、企業向けには Gemini Enterprise を通じた Gemini エージェントが案内されています。個人の作業を代行する Spark と、組織の統制下で業務を担う Gemini エージェントは、用途だけでなく管理の主体が異なると考えると整理しやすくなります。

Gemini Enterprise・Agent Platform・Agent Gateway の関係

企業向けの名称は似ているため、本記事では次のように区別します。

Gemini Enterprise

従業員が利用する企業向けの AI アプリケーションです。基調講演の導入事例の多くは、Gemini Enterprise の利用事例として紹介されています。

Gemini Enterprise Agent Platform

エージェントを構築、実行、統制するための Google Cloud の基盤です。Agent Runtime、Agent Registry、Agent Identity、Agent Gateway などで構成されます。

Agent Gateway

Agent Platform の構成要素の 1 つで、ゲートウェイを経由するエージェントの通信にポリシーを適用する制御点です。Agent Runtime のエージェントと Gemini Enterprise の通信に適用できますが、Gemini Enterprise では外向き通信のみが対象で、ゲートウェイを経由しない通信もあります。

つまり、従業員は Gemini Enterprise を通じてエージェントを使い、インフラ担当者は Agent Platform 側でゲートウェイを経由する通信と権限を統制する関係です。

Agent Gateway とは｜企業向けエージェントに通信統制が必要な理由

エージェントは人の操作を待たずに、社内システムや外部の MCP サーバーへ自律的にアクセスします。サブエージェントが生成されれば通信の主体も増えるため、「どのエージェントが、どこへ、何を送ったか」を通信経路上で統制できないと、情報漏えいや想定外の操作を防ぐことが難しくなります。

基調講演でも、企業でのエージェント活用の成否は「統制できるか」と「費用をまかなえるか」で決まるとし、統制の論点として「エージェントは誰か」「何を許可されているか」「何をしたか」「何に触れてはならないか」の 4 つの問いを示しました。最後の問いに答えるのが Agent Gateway だと説明されています。

参考: Google Cloud Blog（Gemini at Work 2026 基調講演）
“All traffic — in, out, and between agents — passes through Agent Gateway”
（エージェントの内向き、外向き、エージェント間のすべての通信が Agent Gateway を通過します）
https://cloud.google.com/blog/products/ai-machine-learning/welcome-to-gemini-at-work-2026

ただし、これは基調講演での説明です。後述のとおり、公式ドキュメント上は Gemini Enterprise で利用できるのは外向き（egress）モードのみで、ゲートウェイを経由しない通信も記載されています。以下は公式ドキュメントに基づいて解説します。

Agent Gateway を構成するガバナンス要素

Agent Gateway は単体で動くのではなく、ID、登録簿、ポリシーと組み合わせて機能します。

ネットワーク設計の観点で特に重要なのは、外向き通信が既定で遮断される点です。

参考: Agent Gateway overview（Google Cloud Documentation）
“By default, all connections are blocked unless an explicit IAM policy grants access.”
（明示的な IAM ポリシーでアクセスを許可しない限り、すべての接続は既定で遮断されます）
https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/gateways/agent-gateway-overview

2 つのモードと対応ランタイム

Agent Gateway には、クライアントからエージェントへの通信を守る Client-to-Agent と、エージェントから外部への通信を守る Agent-to-Anywhere の 2 つのモードがあります。対応状況はランタイムによって異なります。

外向き通信がゲートウェイを通過する順序

Agent-to-Anywhere モードでは、エージェントの外向きリクエストは次の順序で評価されます。どの段階で拒否されたかを切り分けるために、順序を把握しておくと障害対応に役立ちます。

1. エージェント ID を持つエージェントの外向きリクエストを、ゲートウェイが受け取ります。
2. IAP が、宛先に対する iap.resources.egressViaIAP 権限をエージェント ID に付与した IAM ポリシーがあるかを確認します。Principal Access Boundary ポリシーもこの段階で評価されます。
3. 宛先が Agent Registry に登録されているかを確認します。未登録の宛先は、宛先 URL を対象とした明示的なポリシーがない限り拒否されます。
4. Model Armor、Semantic Governance Policies、外部の認可エンジンなど、設定済みの検査を適用します。
5. すべての検査を通過したリクエストを宛先へ転送します。

従来の API ゲートウェイとの比較

「ゲートウェイ」という名称から既存の API ゲートウェイと同じ位置付けに見えますが、守る通信の向きと主体が異なります。次の表は、一般的な API ゲートウェイの構成と、公式ドキュメントで確認できる Agent Gateway の仕様を筆者が対比したものです。

筆者の見解として、Agent Gateway は既存の API ゲートウェイを置き換えるものではなく、エージェントの外向き通信に特化した制御点と捉えると、既存のプロキシや SWG（Secure Web Gateway）の設計と並べて検討しやすくなります。なお、API リファレンスには Google 管理のプロキシに加え、既存の Application Load Balancer や Secure Web Proxy に接続する self-managed の構成も定義されています。ただし、セットアップ手順で確認できたのは Google 管理の構成のみです。

ゲートウェイを経由しない通信

Gemini Enterprise のドキュメントには、Gemini Enterprise のエージェント同士の直接通信や、エージェントとデータコネクター（カスタム MCP サーバーを含む）の直接通信では、Agent Gateway のポリシーが適用されないと記載されています。ゲートウェイで統制したい MCP サーバーやエージェントは、データコネクターとして直接追加するのではなく、Agent Registry に登録してからアプリへインポートする構成にする必要があります。あわせて、ガバナンスポリシーを適用できるのは、ゲートウェイに関連付けたレジストリ内のリソースに限られます。

Gemini Enterprise で導入する際の制約と注意点

Gemini Enterprise と組み合わせる場合は、Agent Runtime より制約が多くなります。ここでは、リージョン、監査のみモード、権限、導入手順、コストの順に確認します。手順やコマンドは公式ドキュメントに基づくもので、筆者の環境での実機検証は行っていません。

リージョンの対応関係とデータ所在の考え方

Gemini Enterprise アプリに紐付ける Agent Gateway は、アプリのロケーションに対応するリージョンへ配置する必要があります。関連付けられるレジストリは最大 2 つで、1 つは global、もう 1 つはリージョンまたはマルチリージョンのレジストリです。

マルチリージョンの us と eu のレジストリは、エージェント、エンドポイント、MCP サーバーの手動登録に対応していません。また、Gemini Enterprise のリリースノートには日本の国内リージョンへの言及がありますが、上記の対応表には global、us、eu のみが記載されています。国内リージョンのアプリで Agent Gateway を利用できるかは、確認時点の公開ドキュメントでは確認できませんでした。

データ所在を検討する際は、次の 4 つを同一視しないことが重要です。

参考: Route Gemini Enterprise traffic through Agent Gateway（Google Cloud Documentation）
“Enabling Agent Gateway routes all Gemini Enterprise traffic, including LLM calls, through the gateway.”
（Agent Gateway を有効にすると、LLM 呼び出しを含む Gemini Enterprise のすべての通信がゲートウェイを経由します）
https://docs.cloud.google.com/gemini-enterprise-agent-platform/govern/gateways/agent-gateway-ge-deploy

筆者の理解では、ゲートウェイの配置はデータ所在の要件そのものではなく、通信がどこを経由するかに関わる要素です。データ所在の要件がある場合は、アプリのロケーション、モデルの処理場所、保存場所を Gemini Enterprise のドキュメントで個別に確認し、そのうえでゲートウェイの配置が要件と矛盾しないかを確認することをおすすめします。

監査のみモードで確認できること・できないこと

Gemini Enterprise アプリにゲートウェイを紐付けた時点で、既存のエージェント通信はすべて即座にゲートウェイ経由へ切り替わります。そのため公式ドキュメントでは、IAP を監査のみ（dry-run）モードで先に展開し、設定を検証してから強制へ移行する方法が推奨されています。

参考: Troubleshoot Agent Gateway connectivity（Google Cloud Documentation）
“IAP logs denials but does not enforce them.”
（IAP は拒否をログに記録しますが、拒否を強制しません）
https://docs.cloud.google.com/gemini-enterprise-agent-platform/troubleshooting/troubleshoot-agent-gateway

ここで注意したいのは、監査のみモードで強制が止まるのは IAP による IAM ポリシーの評価だけという点です。ゲートウェイの紐付け自体で通信経路が変わるため、IAM 以外の要因で通信が失敗する可能性は残ります。トラブルシューティングのドキュメントでも、監査のみモードで 403 が返る場合は、ゲートウェイのプロキシや宛先側が原因の可能性が高いとされています。

IAP のログで監査のみモードのリクエストを絞り込むには、ログクエリーに protoPayload.metadata.iamEnforcementMode="DRY_RUN" を追加します。ゲートウェイ側の拒否は、Cloud Logging の networkservices.googleapis.com/Gateway で httpRequest.status=403 として確認できます。

認可拡張の設定値とサービスアカウントの権限

IAP を参照する認可拡張の設定例は、資料によって値が異なります。本記事では、確認時点の公式ドキュメントの例に合わせています。

本記事が failOpen: false と V2 を採用した理由は、更新日が新しく、Agent Gateway の手順として示された公式ドキュメントの値であるためです。Service Extensions の API リファレンスでは、failOpen は拡張の呼び出しが失敗またはタイムアウトした際の挙動を決める設定で、既定値は FALSE です。V1 は従来の Allow ポリシー、V2 は Unified Access Policy を指し、ドキュメントは V2 を推奨しています。Codelab の値は採用理由が説明されていないため、本記事の手順には採用していません。

導入時に必要な権限は、次のとおりです。Discovery Engine Service Agent の権限は、Gemini Enterprise の通信をゲートウェイへ流すための前提で、公式ドキュメント「Route Gemini Enterprise traffic through Agent Gateway」の「Permissions required」に、必要な権限とカスタムロールの作成・付与手順が記載されています。具体的な権限名とコマンドは、同ページの最新の記載に従ってください。

Agent Gateway の導入手順

Gemini Enterprise アプリの外向き通信を Agent Gateway で統制する手順です。公式ドキュメント（Set up Agent Gateway、Route Gemini Enterprise traffic through Agent Gateway）をもとに構成しています。

gcloud services enable \
    compute.googleapis.com \
    networksecurity.googleapis.com \
    networkservices.googleapis.com \
    iam.googleapis.com \
    iap.googleapis.com \
    agentregistry.googleapis.com \
    --project=PROJECT_ID

name: AGENT_GATEWAY_NAME
protocols:
  - MCP
googleManaged:
  governedAccessPath: AGENT_TO_ANYWHERE
registries:
  - AGENT_REGISTRY_URI_1
  - OPTIONAL_AGENT_REGISTRY_URI_2

gcloud network-services agent-gateways import AGENT_GATEWAY_NAME \
 --source="my-agent-gateway-egress.yaml" \
 --location=LOCATION

name: AUTHORIZATION_EXTENSION_NAME
service: iap.googleapis.com
failOpen: false
timeout: 1s
metadata:
  iapPolicyVersion: "V2"
  iamEnforcementMode: "DRY_RUN"

gcloud beta service-extensions authz-extensions import AUTHORIZATION_EXTENSION_NAME \
  --source=iap-request-authz-extension.yaml \
  --location=LOCATION

name: AUTHORIZATION_POLICY_NAME
target:
  resources:
    - "projects/PROJECT_ID/locations/LOCATION/agentGateways/AGENT_GATEWAY_NAME"
policyProfile: REQUEST_AUTHZ
action: CUSTOM
customProvider:
  authzExtension:
    resources:
      - "projects/PROJECT_ID/locations/LOCATION/authzExtensions/AUTHORIZATION_EXTENSION_NAME"

gcloud network-security authz-policies import AUTHORIZATION_POLICY_NAME \
  --source=iap-request-authz-policy.yaml \
  --location=LOCATION

監査のみモードの期間は、エージェントが現在どの宛先へ通信しているかを棚卸しする機会にもなります。ログから宛先の一覧を作成し、レジストリ登録と許可ポリシーに反映すると、強制モード移行後の手戻りを減らせます。

そのほかの制約

• Gemini Enterprise では、ゲートウェイはデプロイしたプロジェクトとリージョンの範囲だけを統制します。統制用プロジェクトから複数プロジェクトをまとめる構成は、Agent Runtime の egress モードのみ対応です。
• 1 つのゲートウェイで統制できる Agent Registry の登録リソースは 5,000 までで、egress ゲートウェイに設定できる認可ポリシーは 4 つまでです。
• VPC Service Controls の境界をエージェント通信へ適用できるのは、2026 年 9 月 8 日以降に作成し、エージェント接続テンプレートで VPC 接続を構成したゲートウェイに限られます。
• プライベート CA を使う宛先向けの trustConfig では、PEM ファイルを手動でローテーションする必要があります。
• Workforce Identity Federation はプレビューのため、Agent Platform と Agent Gateway でのサポートは限定的です。
• 承認済みのゲートウェイ以外への紐付けを制限したい場合は、カスタム組織ポリシー制約で Gemini Enterprise アプリのゲートウェイ設定を制御できます。

支出上限に達するとエージェントが停止する

基調講演では、通信の統制と並んで費用の統制も導入の成否を分ける要素とされました。2026 年 8 月に発表された請求関連の機能と今回の追加分を合わせると、主な機能は次のとおりです。

参考: Google Cloud Blog（FinOps for the AI era）
“If a project hits its limit, the agent’s API calls temporarily pause”
（プロジェクトが上限に達すると、エージェントの API 呼び出しは一時停止します）
https://cloud.google.com/blog/products/ai-machine-learning/flexible-billing-and-cost-controls-for-agents-on-google-cloud

Gemini Enterprise 自体の利用形態としては、ユーザー単位のサブスクリプションと従量課金が案内されています。Gemini エージェントは数時間から数日にわたるタスクをクラウド側で実行し続けるため、上限に達すると処理が途中で止まります。業務フローに組み込むプロジェクトでは、停止を許容するか、超過を許可して継続させるかを事前に決めておくことを推奨します。また、Gemini エージェントや Agent Gateway 自体の料金は、確認時点で公式の料金ページから確認できませんでした。導入前に最新の料金情報を確認してください。

Google の発表から読み取れる狙い

最後に、Google が公式に表明している方針と、それを踏まえた筆者の考察を分けて整理します。

Google は基調講演で、仕事の起点がプロンプトの入力画面に移りつつあると述べ、Gemini エージェントには指示ではなく目的を渡すと説明しました。また、モデルを選べること、半導体からセキュリティまでを Google が統合して提供すること、顧客の入力と出力は顧客のものであることを「約束」として掲げています。利用経路に Microsoft 365 や Slack、モデルに Anthropic の Claude を含めている点も、公式に示された方針です。

以下は、これらの発表を踏まえた筆者の考察です。

質問応答ツールから業務実行基盤へ

クラウドでの継続実行、サブエージェント、専用アカウントを持つコワーカーエージェントは、いずれも AI を「相談相手」から「業務を担う実行主体」に位置付け直す機能です。評価の基準も、回答の正確さから、任せた仕事を最後まで安全に完了できるかへ移ると考えられます。

統制機能で企業導入の障壁を下げる

エージェントに業務を任せるほど、情報システム部門やセキュリティ部門の承認が導入の障壁になります。Agent Gateway、エージェント ID、監査証跡、支出上限を同じ発表で打ち出したのは、この承認プロセスに必要な説明材料をそろえる狙いがあると筆者は見ています。ネットワーク担当者が慣れたプロキシ型の制御点で統制できる点は、既存の運用に組み込みやすい要素です。

Workspace と Google Cloud を組み合わせた業務基盤

従業員が使う窓口は Workspace や Gemini Enterprise、統制とデータは Google Cloud という役割分担が、今回の発表でより明確になりました。メールや文書の文脈を持つ Workspace と、データ基盤や通信統制を持つ Google Cloud を組み合わせることで、業務アプリと基盤の両方を Google の上に集約する構図と考えられます。一方で、Microsoft 365 や Slack、他社モデルにも対応する姿勢を示しており、既存環境を置き換えずに入り込む戦略とも読み取れます。

まとめ

Gemini at Work 2026 で発表された Gemini エージェントは、目的を渡して業務を任せる企業向けの汎用エージェントです。個人向けの Gemini Spark とは管理の主体と接続先の範囲が異なり、企業で使う場合は Agent Gateway による通信統制と費用管理が導入の前提になります。提供時期や料金は未発表のため、公式情報の更新を確認しながら準備を進めることをおすすめします。

• Gemini エージェントは目的を受け取り、成果物まで仕上げる業務向けの AI です。
• 個人向けの Gemini Spark とは、管理機能と接続先の範囲が異なります。
• Agent Gateway はエージェントの外向き通信を既定で遮断し、許可制にします。
• Gemini Enterprise は egress のみ対応で、経由しない通信もあります。
• ゲートウェイの配置リージョンとデータの保存場所は分けて確認します。
• 監査のみモードでも、IAM 以外の要因による通信失敗は起こり得ます。
• 支出上限に達するとエージェントが停止するため、超過設定を決めておきます。

以上、最後までお読みいただきありがとうございました。