Gemini Enterprise Agent Platform｜Vertex AI改称

「Vertex AI が Gemini Enterprise Agent Platform になったらしいけれど、結局これは何なのか」。似た名前の「Gemini Enterprise」という別のものまであり、かなり分かりにくくなっています。この記事では Google Cloud の公式情報で確認できる範囲だけを使い、これが何で、Vertex AI とどういう関係にあり、貴社がいま触るべきものなのかを整理します。

結論から言うと：Gemini Enterprise Agent Platform は、Vertex AI の名称を変えて機能を拡張した後継プラットフォームです。Google Cloud は2026年4月23日の公式ブログで「Vertex AI の進化版（the evolution of Vertex AI）」と明言し、さらに「今後、すべての Vertex AI のサービスとロードマップは、単独のサービスとしてではなく Agent Platform を通じてのみ提供される」としています。製品ページのタイトルも「Gemini Enterprise Agent Platform (formerly Vertex AI)」＝旧 Vertex AI、という表記に変わりました。中身は Build / Scale / Govern / Optimize の4本柱で整理され、200種類以上のモデルを扱える開発者向けの基盤です。ただしこれは「AIエージェントを作る側」の道具で、社員がそのまま使うアプリではありません。

一言でいうと何なのか：Vertex AI の看板の掛け替え＋大幅増築

Gemini Enterprise Agent Platform（以下、Agent Platform）は、公式ドキュメントの表現では「エンタープライズ品質の AI エージェントとモデルベースのソリューションを、構築・デプロイ・統制・最適化するための統合プラットフォーム」です。200以上の基盤モデルへのアクセスから運用管理まで、AI のライフサイクル全体をカバーするとされています。

これまで Vertex AI が担ってきた「モデルを選ぶ・学習させる・アプリに組み込む」役割はそのまま引き継がれ、そこにエージェント同士の連携、DevOps、オーケストレーション、セキュリティが足された構図です。

既存の Vertex AI 利用者に何が起きるのか

公式には「名称変更（name changes）」の一覧ページが用意されていて、旧名と新名の対応表が公開されています。主なものを抜き出すと次のとおりです。

実務で気をつけたいのは、この対応表はあくまで「呼び名」の一覧であって、既存のエンドポイントURLやSDKをどう移行するかの手順書ではないという点です。公式の名称変更ページに、APIホスト名やクライアントライブラリの書き換えが要るかどうかの記述はありません。すでに本番運用している場合は、使っている個別サービスのドキュメントとリリースノートで都度確認するのが安全です。

AIエージェントそのものの仕組みを先に押さえたい方は、基礎から整理したガイド記事のほうが理解が早いかもしれません。

4本柱：Build / Scale / Govern / Optimize を日本語にかみ砕く

Agent Platform は公式ドキュメントで4つの柱に沿って整理されています。専門用語が並びますが、日常の言葉に置き換えるとそう複雑な話ではありません。

Build（作る）

エージェントを設計・試作・開発するための道具立てです。

• Agent Development Kit（ADK）：コードで本格的に組む開発キット。モデル非依存で、複数のサブエージェントを組み合わせた複雑な処理も書けます。公式ブログによれば、ADK 経由で Gemini モデルに毎月6兆トークン以上が処理されているとのことです。
• Agent Studio：旧 Vertex AI Studio にあたるノーコード寄りの画面。作ったものを ADK 側に書き出して本格開発へ移せるとされています。
• Agent Garden：要するに「テンプレート集」。請求書処理、財務分析、コードの近代化といった用途別の出来合いエージェントが並び、ゼロから書かずに済みます。
• Model Garden：モデルの品揃え棚。Gemini 系だけでなく Anthropic の Claude やオープンモデルの Gemma まで200種類以上から選べます。
• RAG Engine / Vector Search：社内文書などの自社データをモデルにつなぎ、回答の根拠にする仕組みです。

Scale（動かし続ける）

試作品を本番稼働に持っていく実行環境です。中心は Agent Runtime で、公式ブログでは「1秒未満のコールドスタート」と「数日間にわたって自律稼働する長時間エージェント」への対応が挙げられています。ほかに、会話の途中経過を保持する Sessions、会話をまたいで記憶を持ち越す Memory Bank、生成コードを隔離環境で安全に走らせる Code Execution / Agent Sandbox があります。

Govern（統制する）

ここが今回の目玉で、中小企業にとっても考え方が参考になる部分です。

• Agent Identity：エージェント1体ごとに固有の暗号的なIDを発行する仕組み。「AIにも社員証を持たせる」イメージで、どのエージェントが何をしたかが監査できる形で残ります。
• Agent Registry：社内のAIエージェント台帳。組織内のエージェント・ツール・MCPサーバーを一元的に登録し、承認されたものだけを使える状態にします。
• Agent Gateway：エージェントが外部ツールを呼ぶとき必ず通る関所。公式ブログでは「エージェント生態系の航空管制」と表現され、Model Armor によるプロンプトインジェクションや情報漏洩への防御を効かせるとされています。

Optimize（良くしていく）

Agent Simulation は合成ユーザーとの会話でエージェントを事前テストするもの、Agent Evaluation は本番のやりとりを継続的に採点するもの、Agent Observability は何をどう考えて動いたかの実行トレースを可視化するものです。さらに Agent Optimizer が失敗パターンを自動でまとめ、システム指示の改善案を出すとされています。

混同注意：Gemini Enterprise「アプリ」と Agent Platform は別物

ここが一番よく取り違えられるところです。名前は似ていますが、Gemini Enterprise アプリは「社員が使う側」、Agent Platform は「作る側」で、役割はまったく違います。Agent Platform で作ったエージェントを、Gemini Enterprise アプリを通じて社員に配る、という関係です。

実務で多いのは、「社員に AI を配りたいだけ」なのに開発基盤の資料を読み込んで疲れてしまうパターンです。社員が使うだけならアプリ側、独自の業務ロジックを本番運用したいなら基盤側と最初に切り分けておくと迷いません。

「エージェントに身元を持たせる」という2026年の潮流

この3点セットが同時に出てきたことには、はっきりした背景があります。公式ブログの冒頭では、生成AIの初期は「安全で信頼できる業務ツールを作ること」自体が難題だったが、今は「エージェントが複数のシステムをまたいで動き、しかもセキュリティとガバナンスのガードレールがないまま動いていることが多い」という別種の複雑さに向き合っている、と述べられています。

つまり、問題の中心が「AIの賢さ」から「AIの振る舞いをどう管理するか」に移ったということです。人間の社員に ID と権限と操作ログがあるように、実際に発注や送信をするエージェントにも同じ扱いが要る——というのが Agent Identity の発想です。

これは大企業だけの話に見えますが、構造は中小企業でも変わりません。社員10人の会社でも「見積書の自動作成」「問い合わせの一次返信」「在庫確認」と仕組みが別々に増えれば、半年後には誰も全体像を把握していないAIが社内に散らばっている状態になります。何が動いていて、どのデータにアクセスでき、誰が止められるのか。この3つを一枚の表で管理しておくだけでも、Agent Registry の思想は小さく実践できます。

とくに社内データをどこまでAIに渡すかの線引きは早めに決めておきたいところで、AIエージェントに社内データを安全に渡す方法を整理した記事も判断材料になるはずです。

私たちも、こうした社内向けのAIを小さく作って育てるお手伝いをしています。記事の途中で恐縮ですが、もし「自社の業務に合わせたAIを、いきなり大規模にせず現実的な範囲で作りたい」とお考えでしたら、よろしければ合わせてご覧いただけたら嬉しいです。

料金と、直近のアップデート状況

Agent Platform の料金は、製品ページの記載では「使ったツール・ストレージ・計算資源・Cloud リソースぶんを支払う」従量課金で、新規顧客には最大300ドル分の無料クレジットが用意されています。単価の例としては、テキスト・チャット・コード生成が入力/出力それぞれ1,000文字あたり0.0001ドルから、Pipelines の実行が1回あたり0.03ドルから、と公式ページに記載があります。総額はモデルと利用量で大きく変わるため、公式の料金計算ツールで見積もるほかありません。

更新も続いています。公式リリースノートには、2026年8月13日に Gemini 3.7 Flash が一般提供（GA）、8月15日にセマンティックガバナンスポリシーの監視指標がプレビュー提供、7月24日に Anthropic の Claude Opus 5 が Model Garden に追加、といった記載があります。一方、7月21日付けで一部のオープンモデル用エンドポイントが非推奨となり2026年10月21日に廃止予定とされている点は、該当モデルの利用者は確認が必要です。

できないこと・注意しておきたい点

正直なところ、中小企業がそのまま導入して幸せになれる製品ではありません。検討する前に、次の点は押さえておきたいところです。

• 開発基盤であって、完成品のアプリではありません。 ADK にせよ Agent Studio にせよ、業務ロジックを設計して形にする人が要ります。社内にエンジニアがいない状態で「入れれば動く」ものではありません。
• 費用が読みにくい構造です。 シート課金のアプリ側と違い、基盤側はモデル呼び出し・ストレージ・実行環境が積み上がる従量課金です。上限の見積もりは最初に立てておくべきところです。
• プレビュー段階の機能が多く含まれます。 リリースノート上でも Preview 表記の機能が並んでいます。プレビューは仕様変更や提供条件の変更があり得るため、基幹業務を最初から預けるのは慎重にしたいところです。
• 移行の細部が公式にすべて書かれてはいません。 名称変更の対応表はありますが、既存構成の書き換えが要るかは機能ごとに個別確認するしかない状況です。
• 日本語情報がまだ薄い領域です。 一次情報は英語のドキュメントが中心で更新も速く、日本語の解説だけを頼りにすると古い前提で判断してしまうおそれがあります。

中小企業は、いま触るべきか触らなくてよいか

判断軸はシンプルで、「社内に、作って運用し続ける人がいるか」の一点だと考えています。

触らなくてよいケース：社内に開発体制がなく、やりたいことが議事録の要約・メール下書き・社内文書検索といった一般的な効率化にとどまる場合。完成品を1シートから試すほうが、費用も学習コストも圧倒的に軽く済みます。まずどの業務から着手すべきかを決めるところから始めるのが現実的です。

触る価値があるケース：独自の見積ロジックや業界特有の書類処理など自社にしかない業務フローがあり、それを本番品質で長期運用したい場合。加えて、社内または外部に継続的に手を入れられる開発リソースがある場合です。この条件が揃えば、統制と監視が最初から入った基盤を選ぶ意味は大きくなります。

迷ったときの中間解：まず完成品を少人数で試し、社内で本当に定着する業務を見極める。そこで「自社専用に作り込む価値がある」と分かったものだけを独自開発に回す。この順番なら失敗しても損失は小さく済みます。自社で作るか外部に任せるかの判断も、この段階で考えれば十分です。

Microsoft 365 が中心の組織であれば、同じ「エージェントに実務を任せる」路線としてCopilot Cowork で何を任せられるかを整理した記事も判断材料になります。

Mihata では、中小企業向けにAI導入のご相談と独自AIの開発をお受けしています。「うちの規模でどこまでやるべきか分からない」という段階のご相談でも構いません。もしお役に立てそうでしたら、お気軽にお声がけいただけたら嬉しいです。