2026年3月20日時点で、より強い推論、agentic coding、Computer Use を重視するなら Gemini 3 Flash の方が適しています。翻訳、抽出、分類、ルーティングのような大量・低コスト処理を重視するなら Gemini 3.1 Flash-Lite の方が適しています。 このキーワードで本当に知りたい答えはそこです。
ややこしいのは、Google がこの2モデルを1枚の公式ベンチマーク表で正面比較していないことです。判断材料は pricing、Gemini 3 Flash model page、Gemini 3.1 Flash-Lite model page、release notes、rate limits、そして DeepMind の Gemini 3 Flash page と Gemini 3.1 Flash-Lite page に分かれています。
だからこのページでは、無理に「絶対的な勝者」を作りません。価格、機能、batch 上限、ワークロード適性をまとめて、実運用でのルーティング判断に落とし込みます。
要点まとめ
- Gemini 3 Flash を選ぶべき場面: 強い推論、agentic coding、Computer Use、より高い premium fast lane が必要なとき
- Gemini 3.1 Flash-Lite を選ぶべき場面: コスト、スループット、翻訳、抽出、ルーティングを優先したいとき
- 両方残す のがよい場面: 高付加価値タスクと bulk traffic が混在する本番環境
まずはこの表だけ押さえれば十分です。
| 項目 | Gemini 3.1 Flash-Lite | Gemini 3 Flash | 実務上の意味 |
|---|---|---|---|
| 状態 | Preview | Preview | どちらも Stable ではない |
| リリース日 | 2026-03-03 | 2025-12-17 | Flash-Lite は新しいが上位互換ではない |
| Model ID | gemini-3.1-flash-lite-preview | gemini-3-flash-preview | 明示的なルーティングが必要 |
| Standard input | 無料後 $0.25 / 1M | 無料後 $0.50 / 1M | Flash-Lite は半額 |
| Standard output | 無料後 $1.50 / 1M | 無料後 $3.00 / 1M | ここも半額 |
| Batch 価格 | 無料後 $0.125 / $0.75 | free batch なし、以後 $0.25 / $1.50 | 大量 async 処理は Flash-Lite 向き |
| Context window | 1,048,576 | 1,048,576 | 差ではない |
| Max output | 65,536 | 65,536 | ここも同じ |
| Computer Use | 非対応 | 対応 | 明確な機能差 |
| Grounding | 両方対応。ただし free-tier grounding なし | 両方対応。ただし free-tier grounding なし | 無料 grounding の優位はない |
| 向いている用途 | 安価な大量処理 | より強い fast lane | 名前よりレーンの違いが重要 |
なぜこの比較は誤解されやすいのか
名前だけ見ると、Flash-Lite は Flash の廉価版に見えます。公式の見せ方はもう少し違います。
Google は Gemini 3 Flash を、multimodal understanding や agentic coding に強い fast model として位置づけています。一方で Gemini 3.1 Flash-Lite は、高頻度の軽量タスク、低遅延、大量処理、翻訳、抽出、ルーティング向けに置かれています。
つまり、この比較は「どちらが新しいか」ではなく、
- より強い premium fast lane
- より安い high-volume lane
のどちらが必要か、という話です。
価格、free tier、grounding、batch throughput
pricing page にある現在の standard price は以下です。
- Gemini 3.1 Flash-Lite Preview: input
\$0.25、output\$1.50 - Gemini 3 Flash Preview: input
\$0.50、output\$3.00
つまり Gemini 3 Flash は概ね 2倍 の価格です。
翻訳、抽出、ルーティング、要約のような高頻度ワークロードでは、この差だけで Flash-Lite に傾くケースが多いです。
Batch も同じ方向です。
- Gemini 3.1 Flash-Lite Batch:
\$0.125input、\$0.75output - Gemini 3 Flash Batch:
\$0.25input、\$1.50output
さらに rate limits の Tier 1 Batch API 表では、
- Gemini 3.1 Flash-Lite Preview:
10,000,000enqueued batch tokens - Gemini 3 Flash Preview:
3,000,000enqueued batch tokens
となっていて、大量 async 処理では Flash-Lite の方が扱いやすい公開上限になっています。
Grounding についても整理しておく必要があります。両方の model page に Search grounding と Maps grounding は載っていますが、pricing page では両方とも free-tier grounding はなく、paid usage で月 5,000 prompts の無料枠がある形です。したがって、この比較で grounding を無料優位として語るのは正確ではありません。
機能差は名前以上に重要
両モデルは headline specs がかなり似ています。
- text output
- text / image / video / audio / PDF input
1,048,576input tokens65,536output tokens- Batch、Function Calling、Structured Outputs、Code Execution、Caching
この一覧だけ見ると、「高いか安いかの差」に見えます。ですが実際の分岐点は workflow です。
Gemini 3 Flash は Computer Use に対応し、Gemini 3.1 Flash-Lite は対応していません。
UI 操作を伴う agent や tool-heavy automation を考えているなら、これは無視できません。
さらに Google の位置づけ自体も違います。3 Flash は coding や reasoning が強い lane、3.1 Flash-Lite は翻訳、抽出、ルーティングのような軽量高頻度 lane です。
だから Flash-Lite は 3 Flash の単純な置き換え先ではなく、Gemini 3 系の bulk traffic lane と考える方が実務的です。
公式 performance page が示すこと、示さないこと
DeepMind には両方の公式 page があります。
ただし、これはこのペア専用の1枚比較表ではありません。さらに 3.1 Flash-Lite の model card では、より新しい評価方式が使われていて、過去の Gemini model card と完全な apples-to-apples ではないと明記されています。
それでも方向性は十分に読み取れます。
- Gemini 3 Flash は capability 側の公式ストーリーが強い
- Gemini 3.1 Flash-Lite は cost-efficiency 側の公式ストーリーが強い
つまり、「全部でどちらが上か」ではなく、「premium lane に払う意味があるか」が問いです。
どのワークロードにどちらを使うべきか
| ワークロード | まず選ぶモデル | 理由 |
|---|---|---|
| agentic coding | Gemini 3 Flash | より強い capability lane |
| tool-heavy automation | Gemini 3 Flash | Computer Use が決定的 |
| 難しめの multimodal reasoning | Gemini 3 Flash | premium fast lane として自然 |
| 大量翻訳 | Gemini 3.1 Flash-Lite | 安くて高速、大量処理向き |
| 構造化抽出 | Gemini 3.1 Flash-Lite | コストと throughput が重要 |
| 分類 / ルーティング層 | Gemini 3.1 Flash-Lite | 公式の想定用途に近い |
| 大規模 async batch | Gemini 3.1 Flash-Lite | batch 価格と ceiling が有利 |
| 混合本番スタック | 両方 | premium と bulk を分けるのが合理的 |
後悔しない導入方法
安全なのは「どちらか一方に全部寄せる」ことではありません。
- Flash-Lite を安価レーンに置く
翻訳、抽出、タグ付け、ルーティングなど bulk traffic を gemini-3.1-flash-lite-preview に寄せます。
- 3 Flash を premium lane に残す
coding、難しい reasoning、Computer Use、重い agent を gemini-3-flash-preview に残します。
- 平均値だけでなく失敗パターンも評価する
両方とも Preview なので、latency や平均品質だけでは不十分です。structured output の安定性、tool calling、long-context drift、成功タスクあたりのコストまで見てください。
運用上の詰めが必要なら、Gemini API troubleshooting guide もあわせて読む価値があります。
デフォルト昇格の前に確認したい5つのこと
この比較で一番危ないのは、公式の強い数字や価格差をそのまま「全面移行の根拠」にしてしまうことです。実運用では、少なくとも次の5点を見てから判断した方が安全です。
1つ目は structured output の安定性 です。JSON や schema に依存するなら、文章の見栄えよりも、欠損・フォーマット崩れ・再試行回数を見るべきです。
2つ目は tool calling の実運用品質 です。両モデルとも Function Calling をサポートしますが、複数ツール、長いプロンプト、失敗後の回復まで含めると挙動は変わります。
3つ目は 長文コンテキストでの実力 です。headline 上は同じ 1M context でも、長文の参照精度や多段の処理では体感差が出る可能性があります。
4つ目は 成功タスクあたりの実コスト です。token 単価だけでなく、再試行、後処理、fallback まで含めた総コストで見る必要があります。
5つ目は split-route を妥協案ではなく本命候補として扱うこと です。このペアは、1モデルに全てを集約するより、premium lane と bulk lane を分ける方が自然です。
この確認を入れるだけで、「どちらが上か」という抽象論から、「どの仕事をどちらに流すべきか」という実装レベルの判断に変わります。
APIチームとアプリ利用者では判断軸が違う
この比較は API と production routing を前提に読むのが正しいです。APIチームは cost、batch throughput、tool calling、成功タスク単価で判断しますが、Gemini app の利用者は UI 上の見え方や日常利用の体感で判断しがちです。
そのため、Flash-Lite が backend では最適でも、アプリ視点ではそう見えないことがあります。逆に 3 Flash は価格だけ見ると高く見えても、agent workflow では十分に意味がある場合があります。
導入初週ならどう選ぶべきか
もしあなたのチームが 翻訳、抽出、タグ付け、分類のような大量処理をまず安く回したい なら、最初の default 候補は Gemini 3.1 Flash-Lite です。大量トラフィックを受ける前提でコスト設計をしやすく、bulk lane としての役割がはっきりしています。
逆に、code generation、tool use、複数ステップの reasoning を含む agent workflow を先に立ち上げる なら、最初の候補は Gemini 3 Flash です。単価は高くても、critical path での失敗や追加リトライが減るなら、実運用では十分に回収できます。
そして、最初から bulk task と premium task が混在している と分かっているなら、無理に 1 モデルへ統一しない方が現実的です。初週から split-route を前提にしておけば、後で全面移行をやり直すよりもはるかに安全です。この比較で一番実務的な答えは、単一勝者を探すことではなく、仕事の種類ごとにレーンを分けることです。
さらに重要なのは、何をもって勝ちとするかを先に決めること です。3 Flash 側では、複雑な tool use や code generation が何回で通るか、手修正なしでどこまで完了するかが効いてきます。Flash-Lite 側では、成功タスク単価、混雑時の throughput、単純な structured extraction の崩れにくさの方が重要です。評価軸を分けておかないと、比較そのものがずれてしまいます。
短期導入では、同じプロンプトを大量に投げるより、実際の失敗パターンを集める方が価値があります。たとえば schema 崩れ、取りこぼし、関数引数の欠落、長文入力での要約ずれなどです。この種の失敗を観察すると、「速くて安い方を広く使う」「重い判断だけ高い lane に送る」という設計がなぜ有効かを、表の数字より納得しやすくなります。
FAQ
Gemini 3 Flash は Gemini 3.1 Flash-Lite より優れていますか？
能力、agentic coding、Computer Use という意味でははい。コスト効率という意味ではいいえです。
Gemini 3.1 Flash-Lite は Gemini 3 Flash の安価版ですか？
単純な廉価版というより、Gemini 3 系の高スループット用レーンです。
両方とも free tier はありますか？
standard usage にはあります。ただし batch、caching、grounding の条件は同一ではありません。
両方とも grounding を使えますか？
使えますが、どちらも free-tier grounding はありません。
coding に向いているのはどちらですか？
Gemini 3 Flash です。
翻訳、抽出、ルーティングに向いているのはどちらですか？
Gemini 3.1 Flash-Lite です。
3 Flash を全部 Flash-Lite に置き換えるべきですか？
いいえ。bulk traffic だけ Flash-Lite に逃がし、premium task は 3 Flash に残す方が現実的です。