Gemini APIや無料版を使い始めたエンジニアが最初にぶつかるのが「制限（レートリミット・コンテキスト・利用制限）」の壁だ。本記事ではGoogleが公開している仕様書をベースに、Gemini 2.5シリーズの各種制限を技術的に整理し、429エラーを回避する実装パターン、ティア別の使い分け、そして経営判断に直結するコスト構造までを解説する。
何ができるか（Geminiの制限の全体像）
Geminiの「制限」は大きく4種類に分かれる。混同すると設計を誤るので最初に整理しておきたい。
1. レートリミット（RPM / TPM / RPD） Google AI Studio経由のGemini APIは、以下3つの軸で計測される（公式ドキュメント）。
- RPM: Requests Per Minute
- TPM: Tokens Per Minute（入力＋出力の合計）
- RPD: Requests Per Day
たとえばGemini 2.5 Proの無料ティアは1日あたりのリクエスト数が厳しく制限されており、実運用には不向きとされる。Tier 1（課金アカウント有効化済み）で大幅に緩和され、Tier 2/3は累積支払額に応じて自動昇格する仕組みになっている。
2. コンテキストウィンドウ Gemini 2.5 Proは最大1,048,576トークン入力 / 65,536トークン出力（公式仕様）。これは現行モデルではトップクラスで、コードベース全体の投入やマルチドキュメントRAGに有利だ。ただし長文プロンプトはレイテンシとコストに直結するため、後述するContext Cachingが必須になる。
3. Safety Filter（コンテンツ制限）
HARM_CATEGORY_HARASSMENT、HARM_CATEGORY_HATE_SPEECHなど4カテゴリ×4閾値（BLOCK_NONE〜BLOCK_LOW_AND_ABOVE）で制御可能。医療・法務・セキュリティ系の用途ではBLOCK_ONLY_HIGHへの緩和が必要なケースが多い。
4. 無料版Geminiアプリの利用回数制限 consumer向けGemini（gemini.google.com）では、2.5 Proへのアクセス回数が日次でリセットされる仕様が報じられている。Google AI Pro / Ultraサブスクリプションで上限が拡張される。
経営者として知っておきたいポイント
レートリミットは単なる技術制約ではなく、ビジネスのスケーラビリティ上限を意味する。SaaSを構築する場合、無料ティアやTier 1のままでは数百ユーザー規模でTPM枯渇が発生する。Tier昇格は「累積課金額＋一定の経過日数」が条件のため、PMF前の段階から少額でも課金を始めて昇格パスを確保しておくのが定石だ。
また、Context Caching（公式）を利用すると、繰り返し送る長文プロンプト（システム指示、ナレッジベース）のトークン課金が大幅に圧縮される。報じられている範囲では入力トークン単価の約25%程度になるとされ、長文RAG型プロダクトのCOGS（原価）を直接押し下げる。CTO層はこの設計を最初から織り込むべきだ。
さらに、Vertex AI（GCP経由）とGemini API（AI Studio経由）では制限ポリシーが異なる。Vertex AIはプロジェクト単位でクォータ申請ができ、エンタープライズSLAも付く。本番運用ではVertex AI移行が現実解になる。
実装/活用の最小ステップ
Step 1: 429エラーの指数バックオフ実装
import time, random
from google import genai
from google.genai import errors
client = genai.Client(api_key="YOUR_KEY")
def generate_with_retry(prompt, max_retries=5):
for i in range(max_retries):
try:
return client.models.generate_content(
model="gemini-2.5-pro",
contents=prompt
)
except errors.APIError as e:
if e.code == 429:
wait = (2 ** i) + random.random()
time.sleep(wait)
else:
raise
raise RuntimeError("Rate limit exceeded")
google-genai SDK（旧google-generativeaiから移行推奨）ではAPIError.codeで429を判定できる。ジッター付き指数バックオフは最低限の作法。
Step 2: Context Cachingで長文プロンプトを圧縮
cache = client.caches.create(
model="gemini-2.5-flash",
config={
"contents": [{"role": "user", "parts": [{"text": LARGE_DOC}]}],
"ttl": "3600s",
}
)
response = client.models.generate_content(
model="gemini-2.5-flash",
contents="この契約書の問題点を3つ挙げて",
config={"cached_content": cache.name}
)
最小キャッシュトークン数（Flash系で1,024トークン以上、Proで2,048以上が要件とされる）を下回るとキャッシュ作成に失敗する点に注意。
Step 3: トークン事前計測でTPM超過を防ぐ
count = client.models.count_tokens(
model="gemini-2.5-pro",
contents=prompt
)
if count.total_tokens > 200_000:
prompt = truncate_with_priority(prompt)
count_tokensは無料かつ高速。バッチ処理前に必ず通すべきガード。
Step 4: バッチ処理での非同期分散
asyncio.SemaphoreでRPMをアプリ側でも制御する：
sem = asyncio.Semaphore(10) # Tier 1のRPMに合わせる
async def call(prompt):
async with sem:
return await client.aio.models.generate_content(...)
注意点・落とし穴
1. TPMは「入力＋出力＋キャッシュ読込」の合計
出力トークンを忘れがちだが、max_output_tokens=8192で投げ続けると見かけのRPMより早くTPMが枯渇する。プロダクションではmax_output_tokensを明示的に絞ること。
2. Safety Filterのfinish_reason=SAFETY
レスポンスが空で返ってきた時、エラーではなくcandidates[0].finish_reasonがSAFETYまたはRECITATIONになっているケースがある。例外を投げないので、必ずfinish_reasonを検査するロジックが必要。
3. 構造化出力（JSON mode）と関数呼び出しの相互排他
response_mime_type="application/json"とFunction Callingを同時指定するとエラーになる仕様が報じられている。エージェント実装時はモードを切り替える設計に。
4. データ利用ポリシーの違い 無料ティアでは入力データがモデル改善に利用される可能性がある旨が利用規約に明記されている。有料ティアおよびVertex AI経由ではオプトアウト扱いとなる。顧客データを扱うSaaSは絶対に有料ティアまたはVertex AIを使うこと。これはコンプライアンス上の必須条件だ。
5. リージョン制約
Vertex AIではモデルごとに利用可能リージョンが異なる。日本リージョン（asia-northeast1）で2.5 Proが利用できないケースもあり、us-central1へのフォールバック設計が必要になる。
制限は「敵」ではなく、システム設計の前提条件だ。429を握りつぶさず、Context Cachingでコストを削り、Tier昇格パスを早期に確保する——この3点を押さえれば、Geminiは現行LLMの中で最もコスト効率の良い選択肢の一つになる。