社内でオンプレ環境上にAI・機械学習基盤を組んで運用している場合、Googleクラウド側の選択肢がここ数年で大きく再編されたことに気づいている方は多くないかもしれません。
Vertex AI（Googleクラウドの機械学習開発プラットフォーム）は、モデル学習・評価・パイプライン管理などの全機能が、Gemini Enterprise Agent Platformという新しい枠組みに統合されました。コンソールでVertex AIを探すと、自動的にこちらへリダイレクトされる状態になっています。
この記事は、社内向けAI基盤の移行やリプレースを検討している基盤エンジニア・SRE・インフラ担当の方に向けた内容です。オンプレで運用してきた推論基盤やバッチ処理をクラウド側のどのサービスに寄せるべきか、判断材料を整理する参考になれば幸いです。
どんな場面でこの選定が必要になるか
典型的なのは、オンプレのGPUサーバーで動かしていたモデル推論基盤が、老朽化やライセンス更新のタイミングで見直しを迫られるケースです。
もう一つは、社内のプロトタイプ止まりだったAI活用を、業務部門に配布できる形にしたいという要望が出てきた場面です。この場合、単なる推論エンドポイントの移設ではなく、権限管理や監査ログをどこに持たせるかという運用設計の話になります。
Google側の選択肢は、AI Studio、Gemini Enterprise Agent Platform、Gemini Enterprise app、Antigravityという4系統に分かれています。名前が似ているため混同しやすく、どれが自社の移行先として妥当か見極める必要があります。
判断軸
運用主体の技術レベルが最初の軸です。エンジニアがバックエンドまで書くのか、業務部門の担当者が使うだけなのかで、選ぶべき層がまったく変わります。
状態管理とガバナンスの要件も重要です。単発の応答を返すだけのツールと、複数ステップにまたがって判断を続け、状態を保持するエージェントとでは、必要なインフラ・監査要件が別物になります。IAM（アクセス権限管理の仕組み）やVPC Service Controls（クラウド内の通信境界を制御する機能）が必要かどうかは、この軸で決まります。
移行の粒度も見ておくべきポイントです。オンプレのバッチジョブ一式をまるごと移すのか、CI/CDパイプラインの一部だけをAI化するのか、開発者のローカル作業だけを支援したいのかで、適したツールの形態が変わります。
運用コストの発生点も無視できません。インフラをGoogle側に自動プロビジョニングしてもらうのか、既存のGoogle Cloudプロジェクトに乗せて自分たちで管理するのかで、コストの見え方も請求書の粒度も変わってきます。
選択肢の比較
| ツール | 主な用途 | インフラの持ち方 | 想定ユーザー |
|---|---|---|---|
| AI Studio | プロトタイプ検証・軽量Webアプリ構築 | Cloud FirestoreやCloud SQL、Firebase Authenticationを自動provisioning | 個人開発者・小規模チーム |
| Gemini Enterprise Agent Platform | 本番エージェントの開発・運用（旧Vertex AI） | IAM・VPC-SCなど自前のGoogle Cloud環境で構築 | プラットフォームエンジニア・MLOps担当 |
| Gemini Enterprise app | 業務部門への配布・ノーコード利用 | Agent Platformで作られたエージェントを配布するSaaS層 | 非エンジニアの業務ユーザー |
| Antigravity(IDE/CLI/SDK) | 開発者のコーディング支援・CI/CD組み込み | ローカルIDE、CLI、または自社コードへのSDK埋め込み | アプリケーション開発者 |
Agent Platformの内部では、Agent Studio（ローコードのビジュアルビルダー）とAgent Development Kit（Python・Go・Java・TypeScriptでコードから組む方式）の2通りの作り方が用意されています。実行基盤はAgent Engineというマネージドランタイムが担い、Model Gardenからは200種類以上のモデル（GeminiやClaudeを含む）を選べます。
オンプレ運用に慣れたエンジニアからすると、Agent Engineは自前で構築していたKubernetes上の推論クラスタや、Kubeflow Pipelinesで組んでいた学習パイプラインの置き換え先に近い位置づけです。IAMとVPC-SCの組み合わせは、オンプレの社内ネットワークでVLANとADグループで権限を絞っていた設計思想と対応させて考えると理解しやすくなります。
ケース別の推奨
業務部門からの要望で「社内文書を検索できるチャットが欲しい」程度であれば、Gemini Enterprise appの配布機能を確認するところから始めるのが妥当です。エージェント本体はAgent Platform側で作り、配布だけをこちらに任せる構成になります。
オンプレのGPUサーバーで動かしていたモデル推論基盤をリプレースしたいなら、Agent Platformへの移行を軸に検討します。特に複数ステップの判断を伴うワークフロー（在庫確認→発注可否判定→承認依頼、といった連鎖処理）がある場合、状態保持とガバナンス機能が必須になるため、この選択が妥当です。
CI/CDパイプラインにAIレビューやテスト生成を組み込みたいなら、Antigravity CLIの利用を検討します。ヘッドレスで動作するため、既存のGitHub Actionsやシェルベースのワークフローに組み込みやすい構成です。
社内で「まず試してみたい」という段階なら、AI Studioでプロトタイプを作り、実際に必要なバックエンド要件（データベース、認証方式）を洗い出してから、本番移行先をAgent Platformにするかを判断する流れが現実的です。
あえて見送るべき条件
単発の質問応答や文書要約だけで用途が完結するなら、Agent Platformのフル機能は過剰投資になります。IAMやVPC-SCの設計に時間をかけるより、AI Studioレベルの軽量構成で十分なケースは少なくありません。
逆に、既にオンプレでKubernetesベースのMLOps基盤が安定稼働しており、監視・アラート設計も社内のPrometheus/Grafanaに統合済みという場合、無理に全面移行する必要はありません。部分的にAgent Platformを併用し、監視の一元化だけを先行して進める選択肢もあります。
社内規定でデータの越境移転や特定リージョン外への保存が禁止されている場合は、移行前に利用可能なリージョンとデータレジデンシー（データの保存場所に関する制約）の要件をGoogle Cloudの公式ドキュメントで確認する必要があります。この確認を飛ばして移行を進めると、後から契約や法務側の指摘で差し戻しになるリスクがあります。
移行判断のまとめ
Googleの開発者・エンター向けAIツール群は、名前が似ていても役割が明確に分かれています。プロトタイプ検証はAI Studio、本番エージェント運用はAgent Platform、業務部門への配布はEnterprise app、開発者支援はAntigravityという整理で捉えると迷いにくくなります。
移行を検討する際は、まずGoogle Cloudコンソールで自社のVertex AIプロジェクトがAgent Platformにどう表示されているかを確認するところから始めてみてください。既存のIAM設定やVPC構成がそのまま引き継がれているか、監査ログの出力先が想定通りかを確認する作業が、最初の具体的な一歩になります。
運用コストと監視体制の設計は、移行後に慌てて整えるのではなく、移行前の判断軸の時点で洗い出しておくと、障害発生時の切り分けもスムーズになります。