Gemini 3.1 Pro Preview vs Gemini 3 Flash: どちらを使うべきか

2026年3月21日時点で、ボトルネックが難しい推論、software engineering の深さ、そして custom tools を絡めた多段ワークフローの信頼性にあるなら、Gemini 3.1 Pro Preview に課金する意味があります。逆に、より安い premium-fast lane、free tier、そして明示的な Computer Use 対応を重視するなら、Gemini 3 Flash の方が依然として優れた default です。 これがこの比較の短い答えです。

ややこしいのは、名前だけ見ると「同じ family の単純な上位版と下位版」に見えてしまうことです。ですが、現在の公式ページはそう書いていません。Google は Gemini 3.1 Pro Preview を、高い reasoning ceiling、software engineering、precise tool usage に寄せた premium lane として見せています。一方、Gemini 3 Flash は、より速く、より安く、browser や UI agent の文脈でも使いやすい premium-fast lane として位置づけられています。

そのため答えは1ページにまとまっておらず、pricing、Gemini 3.1 Pro Preview model page、Gemini 3 Flash Preview model page、rate limits、release notes、そして DeepMind の Gemini 3.1 Pro model card と Gemini 3 Flash page に分散しています。このページでは、その最新の公式情報を1つの routing recommendation にまとめます。

要点まとめ

先に結論だけ知りたいなら、このルールで十分です。

• Gemini 3.1 Pro Preview を選ぶべき場面: 失敗コストが高く、ワークフローが多段で、より強い reasoning や custom-tool behavior が review コストを減らせるとき
• Gemini 3 Flash を選ぶべき場面: 強いモデルは必要だが、コスト、free tier、Computer Use の方が最大 reasoning quality より重要なとき
• 両方残すべき場面: mixed production traffic を扱っているとき。2026年3月時点では、これが最も現実的な答えになることが多いです

まず押さえるべき比較表は次のとおりです。

この表が見えていれば、だいたいの判断はできます。あとは、Pro の premium がどこで正当化されるのか、Flash がどこで依然として勝つのか、そしていつ honest answer が「両方残す」なのかを詰めるだけです。

なぜこれは単純なアップグレード経路ではないのか

このテーマで最もよくある誤読は、「3.1 Pro の方が新しいのだから Flash を置き換えるはずだ」あるいは「Flash は安いのだからほとんどの場面で十分だ」と考えることです。現在の公式ドキュメントは、そのどちらも裏づけていません。

まず、見た目上は非常に似ている部分があります。両方の official model page は 1,048,576 input tokens と 65,536 output tokens を示しています。さらに、batch、caching、code execution、function calling、search grounding、Maps grounding、URL context、structured outputs など、多くの Gemini API surface を共有しています。チェックリストだけを見ると、本当に近い2モデルに見えます。

ですが、だからこそ比較は「解釈」が重要になります。headline specs が同じなら、もう問うべきは「どちらがより広い context を買えるか」ではありません。問うべきは「どちらが workflow のどこに価値を出すか」です。

もう1つの混乱要因は naming churn です。Google の release notes によると、古い gemini-3-pro-preview は 2026年3月9日 に shut down され、gemini-3.1-pro-preview に置き換えられています。そのため、検索結果にはまだ古い比較記事が残りやすく、読者が旧名と新名を正しく結び付けられていないケースがあります。

だから、本当に役に立つ問いは「どちらが family の勝者か」ではありません。

• どの workloads が Pro 3.1 の higher reasoning ceiling と custom-tools の強みを本当に必要とするのか
• どの workloads が、価格差と Computer Use の公開サポートを考えると、依然として Flash に残るべきなのか
• production traffic が十分に mixed で、single winner より split-routing の方が安全なのではないか

この視点で見ると、散らばった公式情報がはじめて実務的な decision に変わります。

2026年3月21日時点の価格、free tier、grounding、rate limits

この比較を具体的な recommendation に変えるのは pricing です。

現在の公式 Gemini Developer API pricing page によれば、Gemini 3.1 Pro Preview には free tier がありません。200k prompt tokens までは 1M input tokens あたり $2.00、1M output tokens あたり $12.00。200k を超えると、standard lane は $4.00 input と $18.00 output に上がります。Batch では半額になりますが、それでも $1.00 input と $6.00 output です。

一方の Gemini 3 Flash は、絶対的に安いとは言えないものの、Pro と比べるとかなり安いです。同じ pricing page では、Flash は free tier あり、paid usage では $0.50 input と $3.00 output、batch では $0.25 input と $1.50 output と書かれています。

つまり、現在の公開価格では Pro 3.1 は Flash の 約4倍 です。standard でも batch でも同じ倍率です。これは「少し高い」レベルではなく、routing を変えるには十分大きい差です。

したがって、Pro はより高い first-pass quality、少ない retries、低い human review cost、あるいはより信頼できる agent behavior によって、その差額を取り返せなければいけません。そこまで届かない workload では、Pro を default にするのは説明しにくくなります。

ここで、さらに3つの pricing-related facts も押さえるべきです。

1つ目は free tier の差です。Flash は prompt tuning、routing 実験、staging に使いやすく、learning loop を回しやすいモデルです。

2つ目は grounding です。現行 pricing page では、両モデルとも paid usage で 月 5,000 件の無料 grounding prompts があり、その後は Google Search queries も Google Maps queries も 1,000 件あたり $14 です。つまり、この2モデルの比較では grounding economics はほぼ差になりません。

3つ目は rate limits です。現在の rate-limits page は、active RPM と TPM は AI Studio で確認すべきであり、さらに preview models は制限がより厳しい と明記しています。つまり、responsible な記事は「不変の RPM 数字」を書き切るべきではありません。

それでも、この公開ページには1つ役立つ数字があります。Tier 1 の Batch API ceiling です。Google は Gemini 3.1 Pro Preview に 5,000,000 enqueued batch tokens、Gemini 3 Flash Preview に 3,000,000 を示しています。Flash の方が安い一方で、batch ceiling は Pro の方が大きいわけです。

この組み合わせこそ、価格だけで結論を出せない理由です。安い高速トラフィックが重要なら Flash、価値の高い batch job が重要なら Pro ceiling も考慮に入れるべきです。

なぜ Gemini 3.1 Pro Preview は premium を払う価値があることがあるのか

Pro 3.1 に 4 倍近いコストを払うことが理にかなう workloads は実際にあります。

公式の Gemini 3.1 Pro Preview page は、Google が何を売っていると考えているのかをかなり直接的に書いています。そこでは、better thinking、improved token efficiency、より grounded で factually consistent な体験が強調されます。さらに重要なのは、software engineering behavior、precise tool usage、reliable multi-step execution across real-world domains に最適化されていると述べている点です。

これは cheap-throughput model の言い方ではありません。高価でも、難しい workflow で高い精度を期待させる premium lane の言い方です。

さらに Gemini 3.1 Pro model card では、2026年2月時点の benchmark として Terminal-Bench 2.0、SWE-Bench Verified、APEX-Agents、MCP Atlas のような hard coding / tool-use 指標が並んでいます。もちろんこれはあなたの個別アプリの性能保証ではありませんが、Google が Pro 3.1 を serious engineering と multi-step agents 向け higher-ceiling option として見せたいのは十分伝わります。

実運用でさらに大きいのが product surface の違いです。公式ページは gemini-3.1-pro-preview-customtools という別 endpoint を明示しており、そこでは custom tools の prioritization がより強いとされています。これは「すべての agent は Pro に移行すべき」という意味ではありませんが、少なくとも published docs が tool-heavy systems に向けたシグナルを出していることは確かです。

しかも、現実には弱い回答のコストは token そのものではないことが多いです。

• 壊れた code patch
• スキップされた tool call
• hallucinated action
• multi-step execution の失敗
• 追加の human review

こうしたコストは、簡単に token 料金を上回ります。したがって、答えを間違えたときの cost が十分に高いなら、より強い model にお金を払う合理性が出てきます。

実務上はこう覚えるのが最も簡単です。

workflow failure が高くつき、better reasoning または better custom-tool behavior で 4x premium を回収できるなら、Gemini 3.1 Pro Preview は意味があります。

その条件を満たさないなら、Pro を default にするのは難しいです。

なぜ Gemini 3 Flash は今でも重要な production lane を取るのか

Pro-first の比較記事がよくやるミスは、Flash を一時的な妥協案のように扱うことです。現在の docs はそう読めません。

公式の Gemini 3 Flash Preview page は、Flash を "the best model in the world for multimodal understanding" であり、Google の "most powerful agentic and vibe-coding model yet" と表現しています。DeepMind の Gemini 3 Flash page も、frontier intelligence at speed、強い function-call handling、Gemini ecosystem 全体への広い展開を強調しています。

特に重要なのは、現行の Flash model page が Computer Use を supported capability として明示している ことです。現在の Pro 3.1 page には Computer Use が capability block にありません。その代わりに、precise tool usage と customtools endpoint が強調されています。この wording difference は小さくありません。どの kind of buyer がどちらを見るべきかを変えます。

もしあなたの system が次のようなものに近いなら、

• browser automation
• UI interaction
• visible screen workflows
• 強いが cost discipline も必要な premium fast model
• free-tier experimentation を重視する production setup

Flash の方が、現時点の published case が強いと言えます。

さらに ecosystem reach も buyer behavior に影響します。DeepMind page では Flash が Gemini API、Google AI Studio、Vertex AI、Gemini CLI、Gemini app、Gemini Enterprise、Google AI Mode、Antigravity、Android Studio にまたがって提供されていると示されています。これだけで API model として優位と断定することはできませんが、多くのチームが Flash を operational lane として感じる理由にはなります。

信頼性についても理想化は禁物です。両モデルに friction はありますが、Flash まわりの complaints は比較的見つけやすいです。2026年1月の Google developer forum では gemini-3-flash-preview に関する truncated output、hallucinated data、不完全な tool calls の報告があり、同日 Reddit では Flash と Pro の両方で 503 high-demand errors が話題になっていました。これは公式保証ではありませんが、preview model の選択が benchmark だけでなく fallback と reliability の問題でもあることを示しています。

それでも Flash が弱いわけではありません。むしろ recommendation はこう絞ると実務的です。

より安い current fast lane が必要なとき、Computer Use が重要なとき、あるいは高品質は欲しいが Pro premium を毎回払うほどではないとき、Gemini 3 Flash を選ぶのが合理的です。

どの workloads が答えを変えるのか

この比較を actionable にする最善の方法は、「best model 論争」をやめて workload routing に変えることです。

特に最後の行は、多くのチームにとって一番大事です。本当に問うべきなのは "which one replaces the other?" ではなく、"which prompt classes deserve Pro?" です。

この考え方なら、一部の難しいリクエストの存在だけを理由に、全トラフィックへ Pro のコストを課す必要がありません。

境界線をもう少し詰めたいなら、Gemini 3.1 Flash-Lite vs Gemini 3 Flash guide と Gemini 3.1 Pro Preview vs Gemini 3.1 Flash-Lite comparison も参考になります。運用上の障害対応については Gemini API error troubleshooting guide が役立ちます。

置き換えるべきか、split-route すべきか、それとも両方残すべきか

多くの serious API teams にとって、最も安全なのは full replacement ではありません。

すべてを Pro 3.1 に移すと、Flash でも十分に動く大量の traffic にまで高い cost を払うことになります。逆に全部を Flash に統一すると、本当に Pro の stronger reasoning や better tool prioritization が必要だった hardest workflows を取りこぼすかもしれません。

そのため、最も defensible な rollout path は通常次の形です。

1. まず Flash を broad default lane にする。

gemini-3-flash-preview を、強い fast model、free-tier-friendly testing、Computer Use が必要な場所に置きます。

1. 本当に難しい workflows だけを Pro に昇格させる。

gemini-3.1-pro-preview または gemini-3.1-pro-preview-customtools に上げるのは、答えを間違えるコストが大きい slices だけにします。

1. 平均勝利ではなく、高くつく失敗を測る。

average quality だけではなく、次を追跡するべきです。

• failed tool sequences
• schema drift
• rework burden
• retries
• cost per successful task
• Pro が token cost を上回る human time savings を本当に生むか

こうして初めて、Pro が traffic の 5% を担当すべきなのか、30% なのか、ほとんど不要なのかが見えてきます。

quota planning を深掘りしたいなら Gemini API rate limits per tier guide も併せて読む価値があります。

実用的な bottom line は次のとおりです。

workload が極端に単一でない限り、single winner を無理に作るべきではありません。mixed production traffic では、Flash をより安い current fast lane として残し、最も難しい custom-tool と reasoning-heavy work だけを Pro 3.1 に送る方が安全です。

FAQ

Gemini 3.1 Pro Preview は Gemini 3 Flash より優れていますか。
より難しい reasoning、software engineering、custom-tool-heavy workflows ではそう言いやすいです。ただし、cost-sensitive premium-fast traffic では自動的にそうとは言えません。Flash には default になり続けるだけの実利があります。

どちらが安いですか。
Gemini 3 Flash です。2026年3月21日の pricing page では、Flash は $0.50 input と $3.00 output、Gemini 3.1 Pro Preview は 200k prompt tokens までは $2.00 input と $12.00 output です。

token limits は同じですか。
はい。両方の current model pages は 1,048,576 input tokens と 65,536 output tokens を示しています。つまり、これは bigger-context decision ではありません。

Computer Use をサポートするのはどちらですか。
現在の Gemini 3 Flash model page は Computer Use を明示しています。Gemini 3.1 Pro Preview page は capability block に Computer Use を載せておらず、precise tool usage と customtools endpoint を強調しています。

coding agent にはどちらを使うべきですか。
agent が custom tools、bash、複雑な multi-step engineering behavior に強く依存するなら、まず Pro 3.1 を試すのが自然です。速度、価格、browser/UI interaction が重要なら、Flash がより良い第一候補になることも多いです。

Gemini 3 Flash を全部 Gemini 3.1 Pro Preview に置き換えるべきですか。
通常は違います。Pro の quality が token cost をきちんと回収できる slices だけを昇格させ、それ以外は Flash に残すか split-route する方が合理的です。