G-genの本間です。当記事では、Gemini Enterprise Agent Platform(略称 Agent Platform)が提供する、フルマネージドの AI エージェント実行基盤である Agent Runtime へ、エージェントをデプロイする際のデプロイ手法について解説します。

はじめに
Agent Platform とは
Gemini Enterprise Agent Platform(旧称 Vertex AI、略称 Agent Platform)は、AI エージェントを構築、管理、実行するために必要な機能を提供する Google Cloud の統合プラットフォームです。
このうち、エージェントの統制を担う機能として、エージェント固有の ID を発行する Agent Identity、エージェントやツールを登録して検出可能にする Agent Registry、これらを参照して通信を制御する Agent Gateway があります。
Agent Platform の全体像については、以下の記事を参照してください。
Agent Runtime とは
Agent Runtime は、Agent Platform に内包されたプロダクトの1つで、エージェントを実行するためのフルマネージドの実行基盤です。Agent Runtime では、組み込みの機能として、エージェントのマルチターン会話を実現するセッション機能や自動スケーリング機能、その他エージェントの機能拡張・運用管理に必要な様々な機能を使用できます。
Agent Runtime の全体像については、以下の記事を参照してください。
当記事について
Agent Runtime に対してエージェントをデプロイするにあたり、デプロイ手法を5つのうちから選択できます。当記事では、それら5つの手法について概要を説明します。
- 参考 : Deploy an agent
5つのデプロイ手法
概要
Agent Runtime で使用可能な5つのデプロイ手法の概要は、以下のとおりです。
| No. | 名称 | 概要 |
|---|---|---|
| 1. | Developer Connect を使用してデプロイ | Developer Connect を介してリンクされた Git リポジトリから直接ソースコードを取得してデプロイする手法。 |
| 2. | ソースファイルからデプロイ | ローカルファイルシステム上のソースコードから直接デプロイする手法。 |
| 3. | Dockerfile を使用してデプロイ | ローカルのソースコードと Dockerfile を送信し、Agent Runtime 側でコンテナイメージを自動でビルドしてデプロイする手法。 |
| 4. | コンテナイメージを使用してデプロイ | Artifact Registry にホストされているコンテナイメージを指定してデプロイする手法。 |
| 5. | Agent Platform SDK オブジェクトからデプロイ | Colab などのノートブック環境で定義されたインメモリのエージェントオブジェクトを直接 Agent Platform SDK の関数に渡してデプロイする手法。 |
なお 2026年10月現在、Agent Runtime は Google Cloud コンソールや標準の gcloud CLI からの直接デプロイには対応していないため、いずれの方式を選択した場合でも、基本的には Agent Platform SDK(または REST API / ADK CLI)を使用し、コードベースでデプロイを実行する必要があります。
また5つのうち、いくつかの手法では、Terraform を用いたエージェントのデプロイや、インフラ基盤の設定管理も可能です。
1. Developer Connect を使用してデプロイする
Google Cloud と GitHub や GitLab などの外部のソースコード管理システムを連携・統合するためのサービスである Developer Connect を使用し、Git リポジトリから直接デプロイする方式です。事前にリポジトリの接続設定を実施したうえで、Agent Platform SDK の developer_connect_source パラメータにリポジトリやブランチを指定してデプロイします。
この方式の場合、エージェントの実装に使用できるプログラミング言語は Python のみです。Developer Connect で Git リポジトリを接続する工数は発生しますが、Git 連携が可能となるため、バージョン管理と連動した継続的デリバリーの自動化に適しています。
2. ソースファイルからデプロイする
ローカル環境のソースファイルから、Agent Platform SDK を使用して Agent Runtime へ直接デプロイする方式です。デプロイ実行時に、対象の開発ディレクトリやエントリーポイント、公開するメソッド定義を指定します。
この方式の場合も、エージェントの実装に使用できるプログラミング言語は Python のみです。Infrastructure as Code(以下、IaC)や GitHub Actions / Cloud Build などの標準的な CI/CD パイプラインに組み込むワークフローと親和性があり、他の選択肢と比較して導入工数が低い点が特徴です。ただし、デプロイ実行時に指定する開発ディレクトリの合計ファイルサイズが 8MB を超えてはいけないという制限があるため、仮想環境ディレクトリや巨大なアセットが含まれないよう注意が必要です。
3. Dockerfile を使用してデプロイする
ローカルのソースファイルとともに、Dockerfile を指定し、Agent Runtime 側でコンテナイメージの自動ビルドとデプロイを実行させる方式です。
この方式では、エージェントの実装に Python 以外のプログラミング言語を使用できます。また、コンテナ環境を定義できるため、OS レベルでのシステムパッケージのインストールや、エージェントをホストする API サーバーの細かい制御が必要な場合にも適しています。なお、ビルドされるコンテナは Agent Runtime が定める所定のランタイム契約(Runtime contract)に準拠している必要があります。詳細は以下の公式ドキュメントを参照してください。
4. コンテナイメージを使用してデプロイする
事前に Artifact Registry にビルド済みのコンテナイメージを push し、Agent Platform SDK でイメージ URI を指定して Agent Runtime へデプロイする方式です。実行にあたっては、Agent Platform のサービスエージェントに対して、対象の Artifact Registry の読み取り権限を付与する必要があります。
「Dockerfile を使用してデプロイする」方式と同様に、Python 以外のプログラミング言語でもエージェントの実装が可能であり、ランタイム契約への準拠が必要です。
Dockerfile 方式との主な違いは、デプロイ時に Agent Runtime 側でビルドするか、事前ビルドしたイメージをデプロイするかという点です。「コンテナイメージを使用してデプロイする」方式は事前ビルドが完了しているため、デプロイ時のパッケージインストール等による待ち時間を最小化できます。
こちらの方式は、CI パイプライン上でコンテナの脆弱性スキャン等のセキュリティツールを通過したイメージのみを本番環境にデプロイするといった、厳格なガバナンス要件や「基盤管理と開発管理の分離」が求められるエンタープライズ環境に適しています。
5. Agent Platform SDK オブジェクトからデプロイする
Colab Enterprise や Agent Platform Workbench などのノートブック環境で定義したメモリ上の Python オブジェクトを、直接 Agent Platform SDK の関数に渡してデプロイする方式です。Python の pickle を用いてメモリ上のエージェントオブジェクトをシリアライズし、Cloud Storage バケットへアップロードします。その後、アップロードされたファイルをもとにコンテナがビルドされます。
この方式では、ノートブック環境でコードを書いて、その場でインタラクティブに動作検証や初期プロトタイピングを手軽に行えます。一方、シリアライズできない複雑なデータ構造や依存関係を持つオブジェクトには適用できず、手動実行が前提となるため、CI/CD パイプラインへの組み込みには適していません。
また、エージェントの実装に使用できるプログラミング言語は Python のみです。
選び方と使い分け
ここまで紹介した Agent Runtime への5つのデプロイ手法は、主にそれぞれ「エージェントの対応言語」「Cloud Storage バケットの要否」「カスタマイズ性」「CI/CD や IaC との親和性」に違いがあります。
開発フェーズ(初期のプロトタイピングか、本番の CI/CD 運用か)や、チームが採用するプログラミング言語・セキュリティ要件に合わせて、以下の比較表を参考に最適なデプロイ手法を選択してください。
| 名称 | エージェントの対応言語 | Cloud Storage バケット | CI/CD・IaC 適性 | 主なユースケース | 主な特徴・制約事項 |
|---|---|---|---|---|---|
| Developer Connect を使用してデプロイ | Python のみ | 不要 | ◎ | Git リポジトリと直結した継続的デリバリー | Developer Connect の事前設定が必要。リポジトリから直接コードを取得してデプロイするため、複雑な事前ビルド処理を伴う運用には不向き。 |
| ソースファイルからデプロイ | Python のみ | 不要 | ◎ | Terraform や GitHub Actions 等を用いた標準的な本番運用 | Pickle 化を行わないため依存関係の再現性が高く、導入工数も低い。送信するソースコード合計サイズに 8MB の制限あり。 |
| Dockerfile を使用してデプロイ | 任意の言語 (Go や Java 等も可) |
不要 | ◯ | OS パッケージの追加や、Python 以外の言語を使用する場合 | クラウド側でコンテナを自動ビルド。ランタイム契約への準拠が必要。 |
| コンテナイメージを使用してデプロイ | 任意の言語 (Go や Java 等も可) |
不要 | ◎ | 厳格な脆弱性スキャンや、デプロイ時間短縮が求められる本番環境 | Artifact Registry のビルド済みイメージを指定するため、デプロイ時のレイテンシが小さい。サービスエージェントへの権限付与とランタイム契約への準拠が必要。 |
| Agent Platform SDK オブジェクトからデプロイ | Python のみ | 必須 | △ | Colab Enterprise 等のノートブック環境での初期プロトタイピング・検証 | メモリ上のオブジェクトを pickle で直感的にデプロイ可能。シリアライズできない複雑な構造や CI/CD への組み込みには不向き。 |
どの方式を採用すべきか迷った場合は、開発のフェーズやプロジェクトの要件を整理したうえで検討してください。
手軽に動作を試したい初期検証フェーズの場合は、ノートブック環境からすぐに実行できる 「Agent Platform SDK オブジェクトからデプロイ」 や、比較的導入コストが低い 「ソースファイルからデプロイ」 から始めることを推奨します。
Python で開発したエージェントを本番運用へ移行し、CI/CD パイプラインへ組み込むフェーズでは、導入コストが低く Terraform などの IaC ツールとも組み合わせやすい 「ソースファイルからデプロイ」、あるいは Git 連携の機能を十分に発揮できる 「Developer Connect を使用してデプロイ」 が選択肢に入ります。
Go や Java といった Python 以外のプログラミング言語でエージェントを実装する場合や、OS レベルのライブラリ追加といった環境カスタマイズが求められる場合には、「Dockerfile を使用してデプロイ」 または 「コンテナイメージを使用してデプロイ」 を選択します。特にエンタープライズの本番環境において、CI パイプラインでのコンテナ脆弱性スキャンを必須とする場合や、スケーリング・デプロイ速度、基盤管理と開発管理の分離を重視する場合には、「コンテナイメージを使用してデプロイ」 の採用が最適です。
本間 優太郎 (記事一覧)
クラウドソリューション部 クラウドエンジニアリング2課
北海道在住
2026年6月に G-gen にジョイン。前職では社内SE、Sler としてアプリ/インフラ開発業務に従事。アプリ/インフラ双方の経験をベースに現在はGoogle Cloudの学習を進めている。
好きなことは子供と遊ぶこと、ゲームをすること。
