Gemini 3.1 Pro API ガイド: 導入、料金、制限、移行ポイント (2026)

Gemini 3.1 Pro API は、長いコンテキスト、マルチモーダル入力、そしてツールを使う開発ワークフロー向けに Google が提供している有料 preview パスです。2026年3月28日 時点で公式ドキュメントを再確認すると、現在のメイン model は gemini-3.1-pro-preview で、古い gemini-3-pro-preview はすでに停止され新モデルへ向くようになっています。さらに、bash と登録ツールを混在させるエージェント向けに gemini-3.1-pro-preview-customtools という別 endpoint も用意されています。ここで知りたいのは「新しいモデルのニュース」ではなく、「今日どう接続するか」「どの model ID を使うか」「どこで料金と制限を判断するか」でしょう。このページはそこに絞っています。

“

エビデンス注記: 本記事は Google の Gemini 3.1 Pro モデルページ、料金ページ、rate limits ページ、API key ガイド、OpenAI compatibility ドキュメント、Gemini 3 developer guide、release notes を 2026年3月28日に再確認したうえで書いています。

TL;DR

• 基本の model path は gemini-3.1-pro-preview です。
• gemini-3.1-pro-preview-customtools は、ツール優先度が本当に重要なエージェント用途でのみ選ぶべきです。
• Gemini 3.1 Pro のプログラム API は無料ではありません。ただし AI Studio で先に挙動を確かめるのは簡単です。
• 200k prompt までは input $2.00 / output $12.00、そこを超えると上の価格帯に入ります。
• 実際の RPM、TPM、RPD は固定のブログ表より AI Studio を見るべきです。Google 自身がそう案内しています。
• gemini-3-pro-preview をまだ使っているなら、これは単なる名称変更ではなく移行対象です。

最短で Gemini 3.1 Pro の最初のリクエストを動かす

Gemini API key の作成は今も Google AI Studio が中心です。実務的な順番は単純で、AI Studio を開いて対象プロジェクトを作成または import し、そこで API key を発行し、ローカルでは GEMINI_API_KEY か GOOGLE_API_KEY を設定します。Google の API key ガイドでは、公式ライブラリはそのどちらも自動で拾い、両方ある場合は GOOGLE_API_KEY が優先されると明記されています。まずは prompt の感触を確かめたいだけなら AI Studio で十分です。Gemini 3.1 Pro をアプリから呼ぶなら、最初から billing を接続しておく前提で考えたほうが安全です。

多くのチームにとって最も素直な入口は、余計な抽象化を足さない公式 GenAI SDK です。Python、JavaScript、REST の最小構成は次のとおりです。

python
from google import genai
from google.genai import types

client = genai.Client()

response = client.models.generate_content(
    model="gemini-3.1-pro-preview",
    contents="Review this API design and list the main tradeoffs.",
    config=types.GenerateContentConfig(
        thinking_config=types.ThinkingConfig(thinking_level="medium")
    ),
)

print(response.text)

javascript
import { GoogleGenAI } from "@google/genai";

const ai = new GoogleGenAI({});

const response = await ai.models.generateContent({
  model: "gemini-3.1-pro-preview",
  contents: "Review this API design and list the main tradeoffs.",
  config: {
    thinkingConfig: {
      thinkingLevel: "medium",
    },
  },
});

console.log(response.text);

bash
curl "https://generativelanguage.googleapis.com/v1beta/models/gemini-3.1-pro-preview:generateContent" \
  -H "x-goog-api-key: $GEMINI_API_KEY" \
  -H "Content-Type: application/json" \
  -X POST \
  -d '{
    "contents": [{
      "parts": [{"text": "Review this API design and list the main tradeoffs."}]
    }],
    "generationConfig": {
      "thinkingConfig": {
        "thinkingLevel": "medium"
      }
    }
  }'

ここで大切なのは、単に動くことではなく、明示的な model と reasoning 設定で動かすことです。Gemini 3 developer guide では、Gemini 3.1 Pro 系では high がデフォルトの dynamic reasoning level とされています。つまり、thinking を暗黙のままにしておくと、遅延や output token コストまで暗黙のままにしているのと近くなります。

最初に選ぶべきは prompt ではなく model path

最初の判断は prompt engineering ではなく model path です。

標準の入口は gemini-3.1-pro-preview です。Google のモデルページでは、Gemini 3 Pro 系をさらに改善した preview モデルとして説明されており、thinking、token efficiency、software engineering、agentic workflow での扱いやすさが強化されています。入力として text、image、video、audio、PDF を受け取り、出力は text です。さらに Batch API、caching、code execution、function calling、search grounding、Maps grounding、structured outputs、URL context をサポートします。大きな文書の解析、複合入力の reasoning、構造化出力、ツールを含む workflow には十分に意味のある選択です。

一方で制約もはっきりしています。Gemini 3.1 Pro Preview は image generation、audio generation、Live API をサポートしません。画像そのものを生成したい、リアルタイム音声対話が必要、あるいは「とにかく安く大量のテキスト処理を回したい」という仕事なら、最初から Pro を標準解にしないほうがいいです。その場合は Flash、Flash-Lite、image 系、live 系のほうが自然です。無料で API を試したい読者なら、まずは Gemini API free tier ガイド を見たほうが役に立ちます。

もう一つの分岐が gemini-3.1-pro-preview-customtools です。これは別の高性能モデルというより、bash と custom tools を併用するエージェント向けの専用 endpoint です。Google のモデルページは、view_file や search_code のような custom tools をより優先しやすいと説明する一方、そうしたツールが本質的でない用途では quality fluctuation が起きる場合があるとも書いています。つまり、「ツールの優先度」が課題なら customtools は正しい選択です。普通の reasoning、チャット、文書解析が中心なら標準版に留まるほうが自然です。さらに掘り下げたいなら、別ページの Gemini 3.1 Pro customtools ガイド を参照してください。

ここで曖昧にしてはいけない事実もあります。Google の release notes では、gemini-3-pro-preview は 2026年3月9日 に shut down され、gemini-3.1-pro-preview に向くようになったと明記されています。古い alias が一部のコードを延命していても、新しい実装は現行の model string を明示的に使うべきです。

料金と制限は「それっぽい表」ではなく実際の運用前提で見る

Gemini 3.1 Pro の料金で重要なのは、長い prompt に入った瞬間に価格帯が切り替わることです。現在の Google pricing ページでは、200k tokens までの標準料金は次のとおりです。

この閾値が大事なのは、Gemini 3.1 Pro の魅力が 1,048,576 tokens の input window にあるからです。1M context だけを見ていると気づきにくいのですが、実際に長大な context を常用すると、料金のかかり方そのものが変わります。実務では benchmark の細かな行より、次の4つのレバーのほうが先に効きます。

1. 日常の prompt は可能なら 200k 未満に保つ。
2. 非同期でよい処理は Batch に寄せる。
3. 何度も送る巨大な instruction や参照コンテキストには caching を使う。
4. thinking level をコストレバーとして扱う。

Google の pricing ページは caching のサポートも確認しており、search grounding が別料金になることも示しています。現在の Web 情報に依存する仕事なら grounding に意味はありますが、そうでない場合は不要なコスト要因になりがちです。

制限の見方はさらに重要です。Google の rate limits ページは、実際の API limits は usage tier と account 状態に依存し、AI Studio で active limits を見るべきだ と明示しています。つまり、このテーマでは静的なブログ表をそのまま信じるのが一番危険です。とはいえ、公式ページから読み取れる運用ルールはあります。

• rate limiting は RPM、TPM、RPD で評価される
• quota は API key 単位ではなく project 単位
• RPD のリセットは Pacific の深夜
• preview モデルは制限がより厳しい
• 自分の active limits は AI Studio にある

同じページでは tier の上がり方も説明されています。Tier 1 は billing を有効にした時点から始まり、Tier 2 は一定の支払い履歴と日数、Tier 3 はさらに大きい spend と履歴が条件です。capacity planning を本気でやるなら、公式ページでルールを理解したうえで、最終判断は AI Studio の数字で行うべきです。

なお、2026年3月12日の release notes では、AI Studio に project-level spend caps が追加されたことも記録されています。Gemini 3.1 Pro をチーム利用するなら、予算ガードとして先に設定しておく価値があります。

thinking、長いコンテキスト、キャッシュを放置すると高くつく

Gemini 3.1 Pro は、API の見た目がきれいだからといって完全にデフォルト任せにしてよいモデルではありません。Gemini 3 developer guide では、Gemini 3.1 Pro に low、medium、high の 3 段階の thinking level があり、high が dynamic なデフォルトであることが示されています。同時に、thinking_level と古い thinking_budget は同じ request に一緒に入れられず、混在すると 400 になるとも書かれています。これは移行時にとても大事です。

実務的には、まず medium を日常作業の初期 default とし、タスクの複雑さに応じて上げ下げするのが扱いやすいです。これは Google の逐語的な推奨ではなく、ドキュメントに出ている挙動と料金構造から引いた工学的な判断です。抽出、分類、短い変換のように深い reasoning が本質でない仕事なら low から始めるほうが自然です。複雑な分析、大きな codebase のレビュー、多段 reasoning のように Pro の強みを本当に使う仕事だけ high を選ぶべきです。

長いコンテキストも同じです。1M token window があること自体は本当ですが、問いは「入るかどうか」ではなく「どれだけの頻度で長文料金を払うべきか」と「どこを cache や要約で先に整理すべきか」です。毎回まったく同じ巨大な system prompt や資料セットを送り直しているなら、最も怠惰な実装が最も高価な実装になりやすいです。

thinking の運用をもっと詳しく見たいなら、別記事の Gemini 3.1 Pro thinking level ガイド が役立ちます。この総合ガイドで押さえるべき要点は、reasoning を明示すること、200k の価格閾値を忘れないこと、長いコンテキストを「使えるから使う」で常態化させないことの 3 つです。

Gemini 3 Pro Preview や OpenAI SDK から移行するなら

もし以前 Gemini 3 Pro Preview を使っていたなら、移行の結論は明快です。2026年3月9日の release notes によると、旧モデルは shut down され、gemini-3-pro-preview は gemini-3.1-pro-preview を指すようになりました。実務としては、コード内の model string を明示的に更新し、thinking に関する前提を見直し、その workload を standard で続けるのか -customtools に寄せるのかを決めるべきです。

一方、すでに OpenAI SDK を深く使っているチームにとっては、Google の OpenAI compatibility layer が最も摩擦の少ない橋になります。公式ドキュメントでは、API key、base URL、model name を変えるだけで OpenAI の Python や JavaScript ライブラリから Gemini を呼べると説明されています。既存の OpenAI client stack の中でまず Gemini を試したいなら、かなり現実的な道です。

python
from openai import OpenAI

client = OpenAI(
    api_key="GEMINI_API_KEY",
    base_url="https://generativelanguage.googleapis.com/v1beta/openai/"
)

response = client.chat.completions.create(
    model="gemini-3.1-pro-preview",
    reasoning_effort="medium",
    messages=[
        {"role": "user", "content": "Summarize the migration risks in this API design."}
    ]
)

print(response.choices[0].message.content)

この compatibility ドキュメントは reasoning_effort と Gemini 側の reasoning control の対応も示しています。minimal と low は Gemini の low、medium は medium、high は high に対応します。大事なのは native path と同じで、機能が重なる reasoning 指定を二重に載せないことです。OpenAI 互換経路で reasoning_effort を使っているなら、別の Gemini thinking 設定をさらに重ねないほうが安全です。

古いチュートリアルや社内 snippet を見直すなら、ここがちょうど良いタイミングです。preview モデルでは、「古い model name を一つ直せば終わり」ではなく、パラメータやコスト前提まで一緒に古くなっていることが多いからです。現行 model string へ揃え、代表的な prompts を AI Studio で再テストしてから production に戻すのが最も堅実です。

Gemini 3.1 Pro を使うべきケースと、使わないほうがいいケース

Gemini 3.1 Pro が正しい API になるのは、強い reasoning、長いコンテキスト、tool-aware なマルチモーダル表面の 3 つが本当に同時に必要な時です。大きな文書のレビュー、大きな codebase の解析、複雑な mixed input からの structured extraction、code execution や function calling、grounding、URL context を使う agent workflow では、この組み合わせが効きます。また、preview モデルであることや stricter limits を受け入れられるチームにも向いています。

gemini-3.1-pro-preview-customtools を選ぶべきなのは、bash と登録ツールを併用するエージェントで、問題の核心が tool priority にある場合です。速度やコスト感度のほうが大事なら、より安い Flash や Flash-Lite に寄せるべきです。image output や live audio が必要なら、別のモデルファミリーに行くべきです。そして「まず無料 API で試したい」が出発点なら、最初から Pro を標準解にしないほうがよく、その場合は Gemini API free tier ガイド や Gemini API rate limits ガイド を先に読むほうが役に立ちます。

Gemini、OpenAI、Claude を一つのルーティング層の後ろで比較したいなら、laozhang.ai のようなゲートウェイが便利な場面もあります。ですが重要なのは「モデル名が並んでいるか」ではなく、「必要な variant と feature を本当に透過しているか」です。customtools や preview 固有の挙動が必要なら特にそこを確認してください。

結論はシンプルです。Gemini 3.1 Pro API は、その形そのものが必要な時に使う価値があります。もし本当に必要なのが「安くて速い高スループットのテキスト処理」なら、Pro 料金を払う理由はありません。逆に「巨大なマルチモーダル context、structured output、grounding、信頼できる multi-step execution」が欲しいなら、Gemini 3.1 Pro は今でもかなり有力な選択です。

FAQ

Gemini 3.1 Pro API は無料ですか。
無料ではありません。Google の現行 pricing ページでは Gemini 3.1 Pro Preview に free API tier はありません。AI Studio で試すことはできますが、プログラムからの利用は有料です。

gemini-3-pro-preview はまだ使えますか。
2026年3月9日に停止されました。release notes では現在 gemini-3.1-pro-preview を指すとされていますが、新しいコードでは現行 model string を明示すべきです。

gemini-3.1-pro-preview-customtools を毎回使うべきですか。
いいえ。custom tools の優先度が本当に重要な時だけ使うべきです。Google も、そうした利点がない用途では quality fluctuation の可能性を示しています。

自分の RPM、TPM、RPD はどこで見ますか。
AI Studio です。Google の rate limits ページも、active limits はそこで見るべきだと案内しています。

OpenAI SDK から Gemini 3.1 Pro を呼べますか。
呼べます。Google の OpenAI compatibility ドキュメントでは、API key、base URL、model name を変えるだけで使えると説明されています。

Gemini 3.1 Pro は画像生成や Live API をサポートしますか。
サポートしません。現行モデルページでは image generation、audio generation、Live API は unsupported です。