「Gemini 3.1 Pro が出たけれど、2.5 Pro からわざわざ乗り換える必要はあるのか」。新しい世代が出るたびに、同じ問いが頭をよぎります。世代交代のたびに変わった点と変わっていない点を押さえておくことは、API コストを抑えながら開発の品質を保つうえで、地味ですが効いてきます。
実際に両モデルを使ってみた感触を踏まえながら、実用的な観点から比較していきます。
前提: 2.5 Pro から 3.1 Pro への変更点の概要
Gemini 3.1 Pro は、2.5 Pro の後継として 2026 年初頭にリリースされました。公式アナウンスでは以下が主な改善点として挙げられています。
- コーディング能力の向上: 複雑なマルチファイル変更や、エラーの自動修正精度が向上
- 長文脈での推論品質: 2M トークンのコンテキストウィンドウは共通ですが、長い文書の後半部分での応答精度が改善
- マルチモーダル処理: 画像・動画の理解精度が向上し、特に複雑な図表の読み取りが改善
- Computer Use の強化: Gemini 3.1 から本格的な Computer Use が一般提供された（2.5 では限定プレビュー）
コンテキストウィンドウのサイズ（最大 2M トークン）や料金体系は基本的に継続しています。
コーディングタスクで使うなら
コーディング系のタスクでは、3.1 Pro の強みがはっきり出やすいです。
2.5 Pro では、大きなリファクタリングを依頼したときに「一部だけ変更して残りを忘れる」ことがありました。3.1 Pro では、同じ指示を与えても変更の整合性が保たれやすくなっています。
import google.generativeai as genai
genai.configure(api_key="YOUR_GEMINI_API_KEY")
# 3.1 Pro を使う場合
model = genai.GenerativeModel(
model_name="gemini-3.1-pro",
generation_config={
"temperature": 0.1, # コーディングは低めに設定
"max_output_tokens": 8192,
}
)
# 2.5 Pro を使う場合（コスト重視・シンプルタスク向け）
model_legacy = genai.GenerativeModel(
model_name="gemini-2.5-pro",
generation_config={
"temperature": 0.1,
"max_output_tokens": 8192,
}
)一方、「50行以内のシンプルな関数を書く」「正規表現を生成する」「短いコードのレビューをする」といった単純タスクでは、2.5 Pro でも十分な品質が出ます。API コストの観点からも、すべてのリクエストを 3.1 Pro に切り替える必要はないかもしれません。
長文書の処理で使うなら
2M トークンという長いコンテキストウィンドウの恩恵を受ける場面——たとえば、数百ページの PDF や長いコードベースを渡して質問するケース——では、3.1 Pro の優位性が感じられます。
2.5 Pro は、文書の「前半部分」に関しては優秀ですが、100 万トークンを超えるような長い文書の終盤に記載された内容を参照させると、精度が落ちる傾向がありました。3.1 Pro はこの点が改善されており、文書全体を均等に参照できる印象です。
ただし、50 万トークン以内の文書であれば、2.5 Pro でも実用上の問題は感じにくいです。
マルチモーダルで使うなら
画像・動画を含むタスクでは、3.1 Pro を選ぶ方が無難です。
2.5 Pro でも基本的な画像理解はできますが、グラフや設計図など「構造を読み取る必要がある画像」については、3.1 Pro の解釈がより正確です。また、動画の特定フレームから情報を取り出すタスクは、3.1 Pro 以降での改善が体感できます。
Computer Use を使うなら
3.1 Pro 一択です。2.5 Pro の Computer Use は限定プレビューの段階で、実用に耐えるレベルではありませんでした。ブラウザ操作やデスクトップ自動化を含む用途では、3.1 Pro を使うことが前提になります。
コストの考え方
2026 年 5 月時点の料金では、3.1 Pro は 2.5 Pro より若干高く設定されています。
大量のリクエストを処理するシステムであれば、タスクの種類によってモデルを使い分けることで、品質を落とさずにコストを抑えられます。
def choose_model(task_type: str) -> str:
"""タスク種別に応じてモデルを選択する"""
high_complexity_tasks = {
"complex_refactoring", # 複雑なリファクタリング
"long_document_qa", # 長文書への質問回答
"multimodal_analysis", # 画像・動画分析
"computer_use", # PC操作の自動化
}
if task_type in high_complexity_tasks:
return "gemini-3.1-pro"
else:
return "gemini-2.5-pro" # シンプルタスクは 2.5 Pro でコスト節約全体を振り返って: どちらを選ぶか
一言で言えば、新しいプロジェクトを始めるなら 3.1 Pro、すでに 2.5 Pro で動いているシステムは段階的な移行が現実的です。
既存システムを一斉に切り替える必要はありません。Computer Use を使いたい、複雑なコーディングタスクの精度を上げたい、長い文書をフルに活用したい——そういったユースケースが出てきたタイミングで 3.1 Pro に移行するので十分だと感じています。
API のモデル名を変更するだけで切り替えられるので、まずはテスト環境で自分のユースケースに実際に試してみてください。