Gemini API と Gemini Enterprise Agent Platform — Vertex AI リブランド後の使い分け

「Vertex AI でいいのか、Gemini Developer API でいいのか、Cloud Next で『Gemini Enterprise Agent Platform』なる新名称が出たけど何が変わった？」。Gemini API の全貌を整理する。これまでの本連載で扱った Gemini App、NotebookLM、Gemini CLI、Jules はすべてこの API インフラの上に乗っている。

2026 年 4 月の Google Cloud Next 2026 で、Google は Vertex AI を Gemini Enterprise Agent Platform にリブランドし、Agentspace と Gemini Code Assist Enterprise を統合した。この変更は単なる名称変更ではなく、Google の「AI 戦略の重心が個別 API 提供からエージェントプラットフォームへ移った」ことを示すマーケットメッセージだ。本記事はこの構造変化を、開発者・メイカー視点で実装レベルで掘る。

2 つの API インフラ — Developer API と Enterprise Platform

Google が提供する Gemini モデルへの API アクセス経路は、現在 2 つに整理されている。

Gemini Developer API（ai.google.dev）は、個人開発者や試作向けの軽量パス。Google アカウントだけで始められ、AI Studio の Web UI とほぼ同じ感覚で API キーを発行する。SDK は google-genai（Python）と @google/genai（TypeScript）の 2 系統で、いずれも GA に達している。最小限のコードで Gemini を呼べる。

Python での最小例:

from google import genai
client = genai.Client()
response = client.models.generate_content( model="gemini-3.1-pro-preview", contents="Klipper の Input Shaping を 200 字で説明して"
)
print(response.text)

API キーは環境変数 GEMINI_API_KEY から自動取得される。10 行未満で Gemini との対話が動く。同じ感覚で TypeScript / JavaScript からも呼べる構造で、Web フロントエンドからも、Node サーバーからも、CLI ツールからも、同じ SDK で統一的に扱える。これは OpenAI SDK や Anthropic SDK と同じ書き心地で、AI SDK 業界全体の API 設計がほぼ収斂してきたことを示している。

Gemini Enterprise Agent Platform（旧 Vertex AI、cloud.google.com 提供）は、企業向けの統合プラットフォーム。同じ Gemini モデルを呼べるが、加えて IAM ベースのアクセス制御、Cloud Logging との統合、SLA、データレジデンシー（リージョン固定）、私的 VPC 経由の通信などの企業向け機能が揃う。Cloud Next 2026 で Vertex AI / Agentspace / Gemini Code Assist Enterprise の 3 製品が統合され、per-agent pricing の単一プロダクトに収斂した。

選択基準はシンプルだ。個人開発と試作は Developer API、業務システム統合と組織導入は Enterprise Agent Platform。同じモデルを同じ単価で呼べるが、周辺機能と契約条件が違う。

リブランドの本質は、Google が「API は商品ではなく、エージェントが商品」という認識に切り替えたところにある。従来の Vertex AI は「Google Cloud 上で動く生成 AI API」という位置付けだったが、Enterprise Agent Platform は「組織内で動く自律エージェント群を構築・運用するための基盤」と再定義された。Agentspace（社内 AI ハブ）や Gemini Code Assist Enterprise を吸収したのも、この再定義の延長線上にある。

開発者にとっての実務的な影響は、「個別 API を組み立てる」から「エージェント仕様を定義する」へとアプローチが変わる点だ。たとえば、「顧客サポート Bot」を作るときに、従来は generateContent API、function calling、メモリ管理、ログ、認証を 1 つずつ組み立てていた。Enterprise Agent Platform では、Agent Studio で「サポートエージェント」を定義し、必要な機能（Memory Bank、Tool Use、A2A 通信）を選択するだけで、これらが統合済みの実行環境として提供される。コードを書く量が桁違いに減る。

Gemini Developer API の料金体系

Gemini API の単価は Gemini 3.1 Pro 完全ガイドで確認した通り、モデル別に大きく違う。

200K token を超える長大コンテキストでは入出力単価が上がる階層課金が適用される。Thinking token は出力単価と同じレートで課金されるため、HIGH モードを使う場合のコスト試算は注意が必要だ。

円換算（1 USD = 157.5 JPY）で見ると、Pro モデルの入力 1M token は約 ¥315、出力 1M token は約 ¥1,890。Flash-Lite なら入力 ¥15.75、出力 ¥63 まで下がる。100 万 token は概算で英文書類 1,500 ページ相当なので、コスト感覚としては「辞書 1 冊分の入力で数百円、出力で 2 千円程度」。

無料枠は 2026-04-01 以降 Flash / Flash-Lite のみ。Pro モデルは試用でも従量課金が発生する。試したい場合は Vertex AI（現 Gemini Enterprise Agent Platform）の新規 $300（約 ¥47,250）/90 日クレジットを使うか、AI Pro $19.99 契約に切り替える方が経済的になる場合がある。

新規クレジット $300 は、Pro モデルで本気で試すなら 90 日で使い切れる規模だ。設計図 100 件の自動分析、過去案件 500 件のメタデータ抽出、自社マニュアル 1,000 ページの構造化、これらをまとめて回せば $300 は十分に消化される。逆に、軽い試用なら 90 日で 30 ドルも使わない。利用想定によって、サブスクリプションと従量課金のどちらが経済的かを試算してから決めるのが正解だ。

200K token 超の長大コンテキストでは入出力単価が上がる階層課金が適用される。具体的な単価は公式ページで確認する必要があるが、概念としては「1M token を超えるリクエストは、1M 未満より割増になる」と覚えておけばよい。Gemini プロンプト設計術で扱った Lost-in-the-middle 問題と合わせて、できる限り 1M token 以内に文脈を抑える設計が、コストと品質の両面で有利だ。

コスト最適化のための 4 つの機能

Gemini API には、コストを抑える機能が複数組み込まれている。これらを使いこなさないと、想定外の請求が来る。

Context Caching: Gemini プロンプト設計術で扱った通り、同一文脈を再利用する仕組み。設計マニュアルや過去案件 PDF のような「毎回同じコンテキスト」を低単価でキャッシュ化できる。保持時間は指定可能で、業務パターンに合わせて 1 時間〜24 時間で設定する。料金は通常入力単価の数分の 1 程度に圧縮される。

Batch API: リアルタイム性を求めない処理は Batch API で 50% 割引が効く。Etsy 商品説明 1,000 件の生成、設計図 PDF 100 件からの寸法抽出、月次レポート集約など、夜間バッチ処理に向く。リアルタイム応答の半額で同じモデルを呼べる経済性は、業務スクリプトで活用する価値が高い。応答までの待ち時間が長くなる代わりに、コストが半減する設計だ。

Thinking Budget の制御: Gemini 3.1 Pro の HIGH モードを常用するとコストが急増する。thinking_config パラメータで LOW / MEDIUM / HIGH を明示し、用途別に切り替える。Gemini プロンプト設計術で扱った「重要判断には HIGH、量産には LOW」原則を、API コードに落とし込む。Thinking token は出力単価と同じく課金される点は要注意。

モデル切替の透過性: 同じ SDK でモデル名を gemini-3.1-pro-preview から gemini-2.5-flash-lite に変えるだけで切り替えられる。プロンプトテンプレートを 2 系統用意し、要求品質に応じて切替するパイプラインを組めば、月次 API コストが大幅に下がる。

4 機能を組み合わせると、たとえばこんなパイプラインが組める。Context Caching に自社マニュアル 200 ページを常駐させ、日中の質問応答は Flash モデルで即応（Caching 経由なので入力単価が割安）、夜間の月次レポート生成は Pro モデル + Batch API で半額生成、HIGH モード使用箇所は厳選してコスト管理。月次の API 請求が、何も考えずに Pro モデル全使用した場合と比べて 5〜10 倍違うこともある。Gemini API の単純な単価表だけ見て「高い」と判断するのは早計で、機能の組み合わせ次第で経済性は大きく変わる。

Function Calling と Structured Output

Gemini API の中核機能のひとつが Function Calling（ツール使用）だ。LLM に外部ツールを「使う権利」を渡し、必要時にツール呼び出しの構造化データを返させる仕組み。Gemini CLI 入門とJules 非同期コーディングエージェントで扱った Gemini CLI や Jules はこの機能の上に組み上げられている。

Gemini 3 系列では、Function Calling と Structured Output を組み合わせられる。これは強力で、「モデルは関数呼び出しを返すか、特定 JSON Schema に沿った構造化応答を返すかのいずれか」を保証する。応答パースエラーが理論上ゼロになる。

Function Calling のモードは 3 つ。

3D プリント業務での実例: 「Klipper config の問題箇所を抽出する関数」を定義し、ANY モードで analyze_klipper_config(file_path, focus_areas) を呼ばせる。応答が必ずこの関数の引数形式で来るので、後段のスクリプトでパースエラーを気にせず処理できる。

Structured Output は JSON Schema、Pydantic（Python）、Zod（TypeScript）等のスキーマライブラリと統合できる。たとえば Python で BaseModel を定義し、それを response_schema に渡すと、Gemini の応答が自動で BaseModel インスタンスにデシリアライズされる。型安全な開発体験は、JavaScript の型定義文化が浸透している現代の開発者にとって自然な書き方だ。

ANY モードを多用する設計には注意も必要だ。「常に関数呼び出しを返せ」という強い制約は、モデルの自由度を奪う。本来「これは関数で解決すべきではない」と判断すべきケースでも強引に関数化される可能性がある。バッチ処理のような決定論的タスクでは ANY が最適だが、対話的なエージェントでは AUTO や VALIDATED の方が応答品質が安定する。

Gemini Enterprise Agent Platform の 4 つの柱

Vertex AI の後継として登場した Gemini Enterprise Agent Platform は、Build / Scale / Govern / Optimize の 4 つの柱で構成されている。

Build: Agent Studio（低コード UI）、Workspace Studio（no-code）、Agent Development Kit（ADK v1.0、Python / Go / Java / TypeScript で提供）。エンジニアでなくてもエージェントを設計できる UI と、複雑なグラフベース構造を扱うコード SDK の両輪。

Scale: Agent Runtime（サブ秒コールドスタート、状態保持エージェント）、Model Garden（200 以上のモデルカタログ）。Gemini だけでなく、Claude、Llama、Mistral など他社モデルも統合できる「マルチモデル基盤」として設計されている。

Govern: IAM ベースのアクセス制御、Cloud Logging 統合、データレジデンシー、A2A Protocol によるエージェント間通信の認証・認可。エンタープライズ要件を満たす管理機能群。

Optimize: コスト監視、パフォーマンス最適化、自動チューニング。組織内で稼働する複数エージェントの全体最適。

メイカー個人事業者の視点では、Agent Studio の低コード UI が試す価値がある。「Klipper config レビュー専用エージェント」「材料選定アシスタント」「Etsy 出品自動化エージェント」など、自分の業務に特化したエージェントを画面操作で組める。ADK で本格的にコードを書くより、まず Agent Studio で動くプロトタイプを作る順序が効率的だ。

Workspace Studio はさらに敷居が低く、no-code でエージェントを構築できる UI として位置づけられている。営業や事務職など非エンジニア層が、自分の業務改善のために小さなエージェントを作る、というユースケースを想定した設計だ。プログラミング経験のないクライアントが「自社業務にエージェントを入れたい」と相談してきたとき、Workspace Studio の存在を知っているとアドバイスの幅が広がる。

Model Garden の 200+ モデルラインナップは、ロックイン回避の観点で重要だ。Gemini だけでなく、Claude、Llama、Mistral、Cohere、Stable Diffusion などのモデルを同じプラットフォーム上で呼び出せる。プロジェクトごとに最適なモデルを選び、必要に応じて差し替える設計が可能になる。これは「Google Cloud に来るが Gemini にロックされない」というメッセージで、エンタープライズ顧客の警戒心を下げる戦略になっている。

Memory Bank と Agent2Agent Protocol

リブランドの目玉が Memory Bank と A2A（Agent2Agent）Protocol だ。

Memory Bank は、エージェントがセッション横断で永続記憶を保持する仕組み。Notebooks in Gemini × NotebookLMで扱った NotebookLM の知識ベース機能を、API レベルでエージェントに組み込む構造化版と理解するとよい。ユーザーの好み、過去の判断、業務ルールをエージェントが学習し続け、毎回ゼロから説明する必要がなくなる。

A2A Protocol は、異なるベンダーの AI エージェントが互いを発見し、能力を交渉し、タスクを安全に委譲するためのオープン仕様。バージョン 1.0 が Cloud Next 26 で本番対応となり、現在 150 企業で稼働、Linux Foundation の Agentic AI Foundation で管理されている。これは MCP（Anthropic 策定、Gemini CLI 入門で扱った）と並ぶ「エージェント時代のオープンプロトコル」の双璧として位置づけられる。

MCP がツールと LLM の接続プロトコルだとすれば、A2A はエージェント間の通信プロトコル。両者は補完関係で、現実のシステムは両方を使う。Google が自社プロトコルを Linux Foundation に渡したのは、Anthropic の MCP に対抗するためでもある。プロトコルの覇権争いは、特定 AI ベンダーへのロックインを避ける戦略上重要で、開発者は両方を理解しておく必要がある。

A2A の現場感を 1 つ示す。あなたが「3D プリント受注エージェント」を組み、それが顧客対応 → 設計検証 → 生産スケジューリング → 出荷連絡の各サブエージェントに作業を委譲する設計を考えるとする。従来は全部 1 つのコード内で関数として実装するか、独自プロトコルで通信させる必要があった。A2A に従えば、各サブエージェントは独立サービス（自社製でも他社製でも）として動き、共通仕様で能力交換と委譲ができる。「設計検証」だけは Cognition Devin に任せ、「顧客対応」は Gemini 3.1 Pro で、と組み合わせる選択肢も開く。

旧 Vertex AI からの移行 — 2026-06-24 廃止期限

リブランドに伴い、旧 Vertex AI SDK の一部モジュールが 2026 年 6 月 24 日に廃止される。既存のコードで vertexai.preview.generative_models のような古いインポートを使っている場合は、Gen AI SDK（google-genai Python / @google/genai TypeScript）への移行が必須だ。

移行の影響範囲を整理する。

• モデル ID: gemini-3.1-pro-preview のような新形式に統一
• インポート: from google import genai 形式に変更
• クライアント初期化: client = genai.Client() の単純化
• 認証: Vertex 経由は引き続き ADC（Application Default Credentials）、Developer API は API キー

CI/CD パイプラインに古い SDK が組み込まれている場合、6 月までに対応する必要がある。組織で複数のリポジトリを抱えるなら、Jules に「Vertex AI SDK の使用箇所を全て新 SDK に置換する PR を作って」と依頼するのが効率的だ。Jules 非同期コーディングエージェントで扱った Jules の非同期実行が、まさにこの種の移行作業で威力を発揮する。

移行の落とし穴として、認証経路が変わるケースがある。旧 Vertex AI では Service Account JSON を環境変数 GOOGLE_APPLICATION_CREDENTIALS で渡す方式が多かったが、新 SDK では Application Default Credentials（ADC）が推奨される。gcloud auth application-default login で認証する流れに切り替わるため、CI 環境では適切な権限を持つサービスアカウントの ADC 認証情報を再設定する必要がある。

リージョン指定の扱いも変わる。旧 Vertex は vertexai.init(project="プロジェクト名", location="us-central1") のように明示的にロケーションを指定する形だったが、新 SDK ではプロジェクトと環境変数で制御する。データレジデンシー要件がある場合は、引き続きロケーション設定を慎重に確認すること。日本拠点のクライアント向けには asia-northeast1（東京）を選ぶ判断が、データ主権の観点で重要になる。

3D プリント業務での Gemini API 統合パターン

メイカー視点で、Gemini API を業務システムに組み込む現実的なパターンを 4 つ示す。

パターン A — Klipper config 健全性チェック CLI: ローカルマシン or Raspberry Pi 上で Python スクリプトを動かし、Gemini Developer API 経由で printer.cfg を分析。Function Calling で「問題箇所の構造化レポート」を返させる。コストは Pro モデルで 1 回数十円、Flash で数円程度。

パターン B — Etsy 商品説明バッチ生成（Batch API）: 月次で新商品 50 件分の英語説明文を Batch API で 50% 割引生成。出力単価半額で 1 回数十円程度に収まる。生成結果は CSV にまとめて Etsy へ手動アップロード。

パターン C — 顧客サポート Bot（Cloud Functions + Memory Bank）: 自社製品仕様を Memory Bank に登録し、顧客からの問い合わせに永続コンテキストで応答する Bot を Cloud Functions に乗せる。Enterprise Agent Platform 契約が必要だが、IAM とロギングが効くため法人運用にも耐える。

パターン D — 3D スキャン処理パイプライン（A2A 連携）: スキャン → メッシュ修復 → スライス → 印刷準備の各段階を独立エージェントとして組み、A2A Protocol でやり取りさせる。Memory Bank で過去の処理パラメータを記憶し、案件ごとに最適化を継続する。

パターン A / B は個人事業者でも今日から組める。パターン C / D は組織規模になってからの設計だが、A2A や Memory Bank の存在を知っていれば、将来の拡張パスが見える。

実装時のコスト見積もりを 1 つ示す。パターン A の Klipper config レビュー CLI を Gemini 3.1 Pro で月 30 回回す場合、1 回あたり入力 5K token / 出力 2K token と想定すると、月コストは約 ¥80（入力 ¥47 + 出力 ¥33）に収まる。Flash モデルなら 1 桁安い ¥10 前後。個人開発者の月次出費としては誤差レベルで、AI Pro $19.99 サブスクリプションよりはるかに安く済む。

パターン B の Batch API による Etsy 説明文 50 件生成は、1 件あたり入力 1K token / 出力 1K token として、Batch 割引適用後で月 ¥10 程度。これも誤差レベルだ。API 経由の運用は、サブスクリプションよりはるかに安く済むケースが多いことを覚えておくと、固定費削減につながる。AI Pro 月額 ¥3,148 を払うか、Pay-as-you-go で月数十円〜数百円で済ませるか、利用頻度で判断する。

まとめ — 開発者が今夜から押さえる 5 行

本記事の要点を 5 行に圧縮する。

1. 個人試作は Gemini Developer API（ai.google.dev）、業務組織は Gemini Enterprise Agent Platform（旧 Vertex AI）
2. SDK は google-genai（Python）と @google/genai（TypeScript）の 2 系統、GA 達成
3. コスト最適化は Context Caching + Batch API（50% off）+ Thinking Budget + モデル切替の組み合わせ
4. Function Calling と Structured Output 併用で応答パースエラー実質ゼロ、3 モード（AUTO / VALIDATED / ANY）使い分け
5. 2026-06-24 までに旧 Vertex AI SDK から Gen AI SDK へ移行必須、Jules で自動移行 PR を組む選択肢あり。手動対応も可能だが、複数リポジトリ抱える組織では自動化が現実的

明日（2026-05-24 公開予定）はシリーズ最終日。Claude Opus 4.7、ChatGPT GPT-5.5、そして Gemini 3.1 Pro エコシステムを横断比較する。メイカー視点での「最適な AI コーディング御三家の組み合わせ」を月商規模別に提示し、本連載の総決算とする。

Gemini API は、Gemini 3.1 Pro 完全ガイド のモデル系譜、Gemini プロンプト設計術 のプロンプト設計、Notebooks in Gemini × NotebookLM の NotebookLM、Gemini CLI 入門 の Gemini CLI、Jules 非同期コーディングエージェント の Jules 全ての土台になる技術インフラだ。サブスクリプションだけでなく、API レベルで自分の業務を再設計できる開発者は、固定費を抑えながら高い柔軟性を獲得できる。今夜、最初の client.models.generate_content(…) を 10 行で書いてみることから、その世界は開く。Cloud Next 2026 で Google が示した「エージェントが商品」という方向性は、向こう数年の AI 業界の主旋律になる可能性が高い。その流れに早く乗ることが、技術的にも経済的にも有利だ。

参照

• Gemini Developer API（公式）
• Gemini Enterprise Agent Platform 公式ページ
• Gemini API Quickstart
• Gemini API Pricing
• Function Calling with the Gemini API
• Structured Outputs in the Gemini API
• Google Cloud Next 2026: Gemini Enterprise Agent Platform 発表（HPCwire）
• A2A Protocol（Moor Insights & Strategy）
• google-genai SDK（TypeScript）GitHub
• swiftwand.com 関連記事: Gemini 3.1 Pro 完全ガイド
• swiftwand.com 関連記事: Jules 非同期エージェント

ブラウザだけでできる本格的なAI画像生成【ConoHa AI Canvas】

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.