2026.06.25 コラム
【テックコラム】Gemini Priority API と Priority PayGo の違い
はじめに
こんにちは！DataCurrent の奥村です。 Gemini の混雑（429 エラー）対策などを調べていると、「Gemini Priority API」「Priority inference」「Priority PayGo」といった似た名前が出てきて、どれが何を指すのか迷うことがあるかと思います。本記事では、この「Priority」まわりの用語を整理し、それぞれの使い方と違いをご紹介します。 なお、本記事の内容は 2026 年 6 月執筆時点の情報です。料金や仕様は変更される可能性があるため、最新の情報は公式ドキュメントをご確認ください。
背景
前回のコラムでご紹介したとおり、Gemini モデルを使う入口には「Gemini API」と「Gemini Enterprise Agent Platform（旧 Vertex AI）」の 2 つがあります。「混雑時でも優先的に処理してもらえる優先レーン」という同じコンセプトの機能が、この 2 つの入口それぞれに別の名前・別の実装で用意されているため、非常に紛らわしいのが現状です。今回は重要なポイントに絞って解説します。
呼称の整理
まず一番混乱しやすい呼称から整理します。
- Gemini Priority API ＝ Priority inference ＝ Priority tier：これらはすべて同じものです。Gemini API 側の優先レーン機能の言い換えで、公式ドキュメント内でも表記が混在しています
- Priority PayGo：これだけ別物です。Gemini Enterprise Agent Platform 側の優先レーンです
つまり「Gemini API 側の Priority」と「Agent Platform 側の Priority」の 2 つがある、と覚えておけば大丈夫です。
Gemini Priority API（Gemini API 側）
Gemini API 側では、リクエストに service_tier: "priority" を指定するだけで優先レーンを利用できます。料金は標準比 +75〜100% のプレミアムで、有料プラン（Tier 2 / Tier 3）のプロジェクトが対象です。
サンプルコード:
from google import genai
client = genai.Client()
response = client.models.generate_content(
model="gemini-3.1-flash-lite",
contents="こんにちは",
config={"service_tier": "priority"},
)
print(response.text)
# どの tier で処理されたかはレスポンスヘッダーで確認できる
print(response.sdk_http_response.headers.get("x-gemini-service-tier"))
# → "priority"（優先処理）or "standard"（ダウングレード時）
なお service_tier には、優先とは逆に遅延を許容する代わりに割安になる "flex"（−50%）も指定できます。
Priority PayGo（Gemini Enterprise Agent Platform 側）
Agent Platform 側では、リクエストヘッダーに X-Vertex-AI-LLM-Shared-Request-Type: priority を付与することで優先レーンを利用できます。料金は標準比 +80%（1.8 倍）です。
サンプルコード:
from google import genai
from google.genai.types import HttpOptions
# クライアントにヘッダーを設定しておけば、以降のリクエストはすべて Priority PayGo になる
client = genai.Client(
vertexai=True,
project="YOUR_PROJECT_ID",
location="global",
http_options=HttpOptions(
api_version="v1",
headers={
"X-Vertex-AI-LLM-Request-Type": "shared",
"X-Vertex-AI-LLM-Shared-Request-Type": "priority",
},
),
)
response = client.models.generate_content(
model="gemini-3.1-flash-lite",
contents="こんにちは",
)
print(response.text)
# どのレーンで処理されたかは usage_metadata.traffic_type で確認できる
print(response.usage_metadata.traffic_type)
# → "ON_DEMAND_PRIORITY"（優先処理）or "ON_DEMAND"（ダウングレード時）
なお、上記は「Priority PayGo のみ」を使用する 2 ヘッダー構成です。X-Vertex-AI-LLM-Shared-Request-Type: priority の 1 つだけを指定した場合は、Provisioned Throughput（予約容量）の割り当てがあればそちらを先に消費し、超過分が Priority PayGo で処理される挙動になります。
また、1 点コスト面で注意したいのが、思考トークン（thinking）も出力扱いで 1.8 倍課金される点です。thinking を多用するエージェント用途では、Priority のコストインパクトが大きくなります。
主な違いと共通点
2 つの Priority の主な違いは以下です。
| 項目 | Gemini Priority API | Priority PayGo |
|---|---|---|
| プラットフォーム | Gemini API | Gemini Enterprise Agent Platform |
| 有効化 | service_tier: "priority" を指定 | ヘッダー X-Vertex-AI-LLM-Shared-Request-Type: priority を付与 |
| 料金プレミアム | 標準比 +75〜100% | 標準比 +80%（1.8 倍） |
| 対象 | Tier 2 / Tier 3 の有料プロジェクト | Google Cloud プロジェクト |
| 処理レーンの確認 | レスポンスヘッダー x-gemini-service-tier | usage_metadata.traffic_type |
一方で重要な共通点もあります。どちらも容量逼迫時はリクエストが失敗するのではなく、自動で標準レーンにダウングレードされ、標準料金で課金される（グレースフル・ダウングレード）という挙動です。また、どちらも可用性の SLA はありません（SLA が必要な場合は Agent Platform の Provisioned Throughput を検討することになります）。
そのため、本番運用では上記の確認方法でダウングレード率をログに記録しておくのがおすすめです。ダウングレードが頻発するようであれば Priority では容量が足りていない合図のため、キャパシティを確保してスループットを保証する Provisioned Throughput への移行を検討するフェーズと言えます。
まとめ
紛らわしい Gemini の「Priority」まわりの用語と、Gemini Priority API・Priority PayGo それぞれの使い方をご紹介しました。どちらの Priority を使うかは、そもそも Gemini API と Agent Platform のどちらの入口を使っているかで決まります。混雑時の安定性を上げたい場合は、ぜひ試してみてください！
最後に
自社に専門人材がいない、リソースが足りない等の課題をお持ちの方に、エンジニア領域の支援サービス（Data Engineer Hub）をご提供しています。 お困りごとございましたら是非お気軽にご相談ください。
本件に関するお問い合わせは下記にて承ります。
株式会社DataCurrent
info@datacurrent.co.jp