Gemini のプロトタイプが実運用に近づいても、すぐに Vertex AI 側へ移る必要はない。まず Google AI Studio と Gemini Developer API を使い続ける前提で、いま詰まっているものを具体的に分ける。割り当て、課金、プロジェクト所有者、共同編集者、必要なモデル行、サーバー側の実装、付料金額やデータ利用条件が問題なら、有料 Developer API で解ける可能性が高い。
企業プラットフォームへ移る理由は、単に「本番だから」ではなく、IAM、組織ポリシー、リージョンやデータ所在地、予約スループット、Model Garden、MLOps、VPC やセキュリティ審査、企業サポート、調達、コンプライアンスといった統制が受け入れ条件になった時だ。よくある「AI Studio は試作、Vertex AI は本番」という二分法は入口としては分かりやすいが、有料 Developer API という中間段階を消してしまう。
まず三つのルートで判断する
| いま困っていること | 先に見るルート | 理由 |
|---|---|---|
| prompt、モデル挙動、function calling、structured output、バックエンド試作を早く確認したい。 | Google AI Studio + Gemini Developer API。 | Google は、特定の企業統制が必要ない限り Developer API を多くの開発者向けのルートとして示している。 |
| 試作は動き、次に課金、quota、プロジェクト所有、paid model access、paid data-use terms が問題になった。 | 有料 Gemini Developer API project。 | これは実運用の中間ルートであり、ただちに企業プラットフォームへ移る理由ではない。 |
| IAM、組織ポリシー、regional/data controls、provisioned throughput、MLOps、Model Garden、VPC/security、support、compliance が必須。 | Gemini Enterprise Agent Platform / Google Cloud enterprise route。 | これは API Key の強弱ではなく、プラットフォーム統制の問題になる。 |
最初の失敗は、AI Studio をおもちゃ扱いし、Vertex AI をすべての本番アプリの唯一の正解にしてしまうことだ。有料 Developer API project は、実際のアプリに必要な課金、より高い使用量、プロジェクト所有者、共同編集者、paid-tier のデータ利用境界を持てる。企業統制が不要なアプリなら、この段階で十分に運用できる場合がある。
二つ目の失敗は、AI Studio で API Key が作れたことを production readiness と誤解することだ。Key は認証の出発点であって、課金状態、現在の rate limits、モデル提供状況、データ利用条件、endpoint、ログ、retry、rollback、secret 管理の確認ではない。実運用前には、Key ではなくプロジェクトと運用条件を確認する。
名前ではなく責任範囲で分ける
名前の印象ではなく、何を管理している面かで見る。
| 名前 | 実際の役割 | 向いていること | 勘違いしやすいこと |
|---|---|---|---|
| Google AI Studio | Gemini を試し、prompt を調整し、Key や project を扱うブラウザ面。 | 早いモデル確認、Key 作成、初回リクエスト、project の確認。 | すべてのモデル、リージョン、quota、本番ポリシーが承認済みである保証。 |
| Gemini Developer API | ai.google.dev の直接開発者 API ルート。 | 多くの app build、SDK integration、普通の backend、企業統制を必要としない paid project。 | 自動的な IAM、data residency、MLOps、private networking。 |
| 有料 Developer API | 同じ Developer API を課金付き project と paid-tier 条件で使う段階。 | 普通の本番圧力、quota、billing、project ownership、paid data terms。 | compliance architecture の代替。 |
| Vertex AI / enterprise platform | 現在の Google Cloud 側では Gemini Enterprise Agent Platform や関連 Cloud AI services に近い企業ルート。 | 組織統制、regional/data controls、provisioned throughput、Model Garden、MLOps、support、compliance。 | すべての本番アプリの既定ルート。 |
| Gemini Enterprise app | 企業ユーザー向けのアプリ体験。 | 会社知識、enterprise user access、内部 workflow。 | Developer API やすべての Vertex AI API call の同義語。 |
Google の Gemini API migration docs は、Gemini Developer API と Gemini Enterprise Agent Platform API という二つの API products を示している。さらに、多くの開発者は、特定の enterprise controls が必要な場合を除き Developer API を使うべきだと説明している。この一文を中心に置くと、判断がかなり整理される。
Vertex AI という名前は、古い資料や Cloud チームの会話では今もよく出る。だから認識用の言葉として残してよい。ただし本文の判断軸は、Developer API、paid Developer API、enterprise platform の三段階に置く。名前の古さより、どのルートがどの責任を持つかが重要だ。
Developer API に残るべき場面
まだ app-shaped な仕事であれば、Google AI Studio と Gemini Developer API に残る。app-shaped とは、Gemini モデルを使うアプリを作り、試し、運用へ持っていくための課題が中心で、企業プラットフォーム級の統制がまだ必須になっていない状態だ。
Developer API に合う仕事は次のようなものだ。
- prompt と response shape の検証。
- structured output、function calling、multimodal input のテスト。
- unified Google Gen AI SDK を使った通常の backend integration。
- 小規模から中規模の社内ツールやサービス。
- モデル挙動を見てから product decision をする段階。
- project owner、collaborators、billing account が明確なら足りるチーム開発。
- Developer API の billing、quota、logging、data-use terms で許容できる低リスク本番。
「本番か試作か」だけでなく、残っているリスクの種類を見る。残りの問題が quota、billing、model row、retry、project owner、Key restriction なら、まだ Developer API 内の設計問題である可能性が高い。残りの問題が org policy、data residency evidence、private connectivity、centralized audit なら、企業ルートの検討が必要になる。
設定作業は分けて扱う。Key 作成、secret 管理、初回リクエスト、403/429 の準備は Google AI Studio API key setup の領域だ。無料枠、project-level limits、現在の rate limit、いつ billing を有効にするかは Gemini API free tier limits の領域だ。プラットフォーム選択は、setup 手順ではなく、移行条件を扱う。
先に有料 Developer API を評価する場面
有料 Developer API は、二列比較で落ちやすい重要な中間ルートだ。
| 本番で起きる圧力 | 有料 Developer API で足りる場合 | 企業プラットフォームが関係する場合 |
|---|---|---|
| Billing | paid project、budget owner、より高い使用量 tier が必要。 | enterprise discount、support contract、procurement、committed capacity が必要。 |
| Quota | RPM、TPM、RPD、paid-tier behavior を上げたい。 | provisioned throughput、Cloud quota governance、dedicated support が必要。 |
| Data use | paid Developer API terms でデータ審査に通る。 | residency、retention、audit、contract control が必要。 |
| Project ownership | Google Cloud project、collaborators、billing account、Key restrictions で足りる。 | IAM、org policy、service accounts、network controls、central security review が必須。 |
| Model access | 必要な model が Developer API で使える。 | Model Garden、partner models、managed model platform、MLOps が必要。 |
Google の pricing page は Free、Paid、Enterprise を分けている。重要なのは、今日の価格表を固定で覚えることではなく、それぞれの意味を理解することだ。Free は開発者と小規模 project に便利だが、product improvement のための data-use boundary がある。Paid はより高い volume や advanced features を必要とする production applications 向けで、content は product improvement に使われないと説明されている。Enterprise は support、security/compliance、provisioned throughput、discounts、MLOps、Model Garden などの enterprise controls を指す。
Billing docs も、rate limits、tiers、billing state、caps が project や billing account の現実であることを示している。つまり project は paid setup へ進められる。すべての本番判断を Cloud enterprise migration に変える必要はない。
したがって「本番だから Vertex」という表現をルールにしない。まず blocker を言葉にする。blocker が usage volume、billing、project ownership、paid model row、paid data-use boundary なら、有料 Developer API を先に評価する。blocker が policy、residency、IAM、provisioned capacity、compliance evidence なら、企業プラットフォームが現実的な候補になる。
企業プラットフォームへ移る場面
企業移行は、便利さではなく統制の決定だ。理由は具体的でなければならない。
| トリガー | 移行前の確認 |
|---|---|
| IAM と org policy | Cloud IAM、service account、org policy、central security review が必須か。 |
| Endpoint と region control | regional endpoint、global endpoint behavior、location-specific architecture が必要か。 |
| Data residency と retention | Developer API では満たせない residency、retention、logging、audit の要求があるか。 |
| Provisioned throughput | 通常の tier movement や retry ではなく予約容量が必要か。 |
| Model Garden と MLOps | managed model platform、evaluation pipeline、deployment governance、partner model が必要か。 |
| Network と security controls | VPC、private connectivity、centralized logs、Cloud security controls が審査条件か。 |
| Support と compliance | enterprise support、contract review、compliance workflow、procurement alignment が必要か。 |
Endpoint という言葉は読み過ぎやすい。Google Cloud の locations docs は regional endpoints と global endpoints を説明するが、endpoint 名だけで data residency や in-region ML processing が保証されるわけではない。Residency が要件なら data residency docs を見る。Zero data retention が要件なら zero data retention docs と、顧客側で必要な actions を確認する。
移行判断には証拠が必要だ。どの control が必要なのか、どの Google doc がその control を所有しているのか、どの service や endpoint や設定で満たすのか、security reviewer や compliance reviewer が何を証拠として受け入れるのかを短く書く。「より enterprise」というだけでは根拠にならない。
API Key と project ownership も古い比較を変えた
古い比較では、AI Studio は個人向けの単純な Key、Cloud 側は本格的な identity platform と説明されがちだった。現在の Key まわりはもう少し細かい。
Gemini API key docs は、Gemini API requests が standard API keys または authorization API keys で認証できると説明している。新しい Google AI Studio keys は auth keys by default になっている。同じ docs では、unrestricted standard keys は 2026 年 6 月 19 日以降拒否され、standard keys は 2026 年 9 月までに migration が必要だとされている。
これは AI Studio が enterprise platform と同じという意味ではない。Developer API route が、昔の simple key という説明より project-aware になったという意味だ。Key は Google Cloud project に紐づき、project が collaborators、permissions、billing context を持つ。多くのチームには十分な管理単位になる。ただし、organization-wide IAM、Cloud network controls、residency architecture、retention、audit、MLOps governance の代わりにはならない。
| 質問 | Developer API の答え | Enterprise platform の答え |
|---|---|---|
| project-owned key は backend app を支えられるか | project、billing、limits、model、key restrictions が合えば可能。 | 可能だが、移行理由は key ではなく広い platform control であるべき。 |
| Key を frontend code に置けるか | 置くべきではない。server-side または managed secrets に置く。 | 同じく置くべきではない。enterprise controls は public credentials を安全にしない。 |
| ひとつの Key は production readiness の証明か | 違う。billing、live limits、data policy、region、model access が必要。 | 違う。IAM、endpoints、residency、retention、support、rollout controls が必要。 |
| 2026 年 6 月と 9 月の Key 日付は重要か | 古い standard keys が残るなら重要。 | 重要だが、enterprise migration は Key hygiene の近道ではない。 |
移行前のチェックリスト
Developer API から企業ルートへ移す前に、短い decision record を作る。
- 現在のルートを書く。AI Studio prototype、free Developer API project、paid Developer API project、existing Cloud enterprise route のどれか。
- 未解決の blocker を書く。quota、billing、data-use policy、region、IAM、support、provisioned capacity、MLOps、Model Garden、compliance、procurement のどれか。
- owner docs を開く。API keys、pricing、billing、rate limits、enterprise locations、data residency、zero retention。
- blocker が paid Developer API で解けるのか、enterprise platform control が必要なのかを決める。
- 同じ model family、request shape、latency expectations、retry policy、logging boundary で小さな pilot を作る。
- traffic を動かす前に cost owner、quota owner、data owner、support owner を確定する。
- rollback を簡単にしておく。enterprise path が accepted workload で同等以上と分かるまで、旧 Developer API route は callable にしておく。
この記録は、幅広い feature matrix より強い。quota と billing だけが問題のチームは、早すぎる enterprise migration complexity を抱える必要がない。data residency や provisioned throughput が必須のチームは、fast API key だけで足りるふりを続けるべきではない。
Setup と quota の問題は分ける
| 狭い問題 | 先に見る場所 |
|---|---|
| Key 作成、安全な保存、初回リクエスト、403/429 readiness。 | Google AI Studio API key setup |
| model row が無料か、project-level limits、いつ billing を有効化するか、429 の原因。 | Gemini API free tier limits |
| workload が普通の Developer API production readiness ではなく Cloud controls を必要としているか。 | platform choice と migration checklist。 |
分けることで、各ページの役割が明確になる。Key setup はコマンドとエラー復旧を扱う。Quota は価格と現在の limit を扱う。Platform choice は surface owner と migration threshold を扱う。
よくある質問
本番の Gemini アプリは Vertex AI を使うべきか
多くのアプリは Gemini Developer API から始められる。有料 Developer API project は billing、quota、project ownership、paid terms、backend integration を扱える。IAM、regional/data controls、provisioned throughput、MLOps、Model Garden、support、compliance、procurement が必須になった時に enterprise route を検討する。
Google AI Studio は試作専用か
試作専用ではない。AI Studio は Gemini を試し、Key や project を扱うブラウザ面であり、Gemini Developer API はその後も多くのアプリで使える開発者ルートだ。重要なのは、未解決要求が普通のアプリ運用か企業統制かである。
Gemini は Vertex AI と同じものか
同じではない。Gemini models は複数の Google surfaces から利用できる。直接開発者ルートは Gemini Developer API。企業側 Google Cloud route は現在、Gemini Enterprise Agent Platform と関連 Cloud AI services として説明されることが多い。Vertex AI はその側の shorthand として残っている。
いつ有料 Developer API にすべきか
usage volume、billing、project ownership、paid model rows、paid data-use boundary が blocker なら、有料 Developer API を先に評価する。これらは多くの場合、enterprise migration ではなく、prototype を paid project にするサインだ。
いつ enterprise platform に移る価値があるか
IAM、org policy、regional endpoint architecture、data residency、zero retention work、provisioned throughput、Model Garden、MLOps、private networking、enterprise support、compliance review、procurement structure といった platform controls が明示された時だ。
2026 年 6 月以降の AI Studio Key はどう扱うべきか
古い standard keys を確認する。Google の API-key docs は、unrestricted standard keys が 2026 年 6 月 19 日以降拒否され、standard keys は 2026 年 9 月までに migration が必要だとしている。新しい AI Studio keys は auth keys by default だ。
Regional endpoint は data residency を保証するか
保証しない。Endpoint location と data residency は別の確認事項だ。Residency が重要なら、data residency docs、supported location、request path、logging behavior、retention setup を確認する。
Developer API と enterprise route を併用できるか
できる。段階移行のほうが安全なことが多い。Developer API を prototype、low-risk workloads、rollback に残し、enterprise pilot で IAM、endpoint、data、throughput、logging、support、cost behavior を確認してから traffic を移す。
