Gemini 3.2 の機能解説記事はすでに別途用意してあります。本記事はその次の段階、つまり「リリース直後から数週間使い込んで分かった、現場での向き不向き」を整理した記事です。スペック表だけでは見えてこない部分を共有することで、自分の業務で 3.2 を採用すべきかの判断材料にしていただければと思います。
私自身は、個人開発のアプリ業務、執筆、翻訳、リサーチ、画像レビューなど、幅広い場面で Gemini 3.2 を使っています。同じプロンプトを 3.1 系と 3.2 で並べて検証する機会も多く、その実感をベースにお話しします。
結論を先に：3.2 は「長文の整合性」で前モデルを大きく超えた
3.2 の最大の進化を一言で表すと、「長いコンテキストでの整合性」です。3.1 系では、入力が 5 万トークンを超えたあたりから「冒頭で述べた制約」を後半で忘れる傾向がありましたが、3.2 ではこれが大きく改善されています。具体的には、私の手元のテストでは 30 万トークンクラスの長文でも、初出の固有名詞や定義を最後まで保持できるようになっています。
逆に「短い対話の俊敏さ」は、感覚的に 3.1 系と大差ないか、むしろ 3.1 Flash のほうが体感速度では速いことがあります。3.2 を使うべきかは、「自分の業務が長文寄りか短文寄りか」を最初に問うのが現実的です。
向く用途 1: 大量ドキュメントの一括レビュー
最も恩恵が大きいのは、契約書、論文、設計書など、何万語にもなる文書をまとめてレビューする作業です。3.1 系では、文書全体を読ませても序盤の重要事項を後半で参照できないことが頻繁にありましたが、3.2 はこれを大きく改善しています。
私が直近で試したのは、自分が書いてきた 5 つのアプリ規約（合計約 12 万文字）を一括で読ませて、共通する不整合を洗い出す作業です。3.2 は「アプリ A では 14 日返金保証、アプリ B では 7 日になっています。意図した違いか確認してください」という具合に、文書間の差分まで指摘してくれました。3.1 系で同じ作業をやらせると、「アプリ A」のあたりで指摘が打ち止めになる印象でした。
向く用途 2: コードベース全体を見渡したリファクタリング提案
3.2 は、リポジトリ全体を読ませた上での構造提案にも強くなりました。30〜50 ファイルクラスの中規模リポジトリで、「現状の構造の問題点を 5 つ挙げ、それぞれに対する具体的な修正案を出してほしい」と依頼すると、3.1 系より明らかに筋の通った提案が返ってきます。
実装に至るまでの順序立て、依存関係の認識、影響範囲の見積もりが、3.1 系の「箇条書きで提案するだけ」から「順序立った計画書」へと進化しています。Antigravity や Cursor のような IDE 統合ツール経由で使うと、この恩恵が最大化されます。
向く用途 3: 多言語の長文翻訳
これは私が個人的に最も助かっている用途です。日本語で書いた記事を英語に訳す際、3.1 系では翻訳を進めるうちに用語のブレが生じることがありました。3.2 では、用語集を冒頭で渡しておけば、最後までその用語を一貫して使ってくれます。
この記事の英語版も 3.2 を使って下訳を作っています。最終的な校正は人手で入れますが、3.1 系のときよりも修正量が確実に減りました。
[長文翻訳のプロンプト構成例]
1. 用語集（10〜30 個）
2. 文体ガイド（敬体・である調などの指定）
3. 過去に翻訳済みの参考訳（2〜3 例）
4. 翻訳対象の本文
向かない用途 1: 短い質問への即答
「明日の天気は？」のような単発の短い問いに対しては、3.2 の優位性はほぼ感じられません。むしろレスポンス時間が 3.1 Flash より遅いケースもあるため、用途次第では 3.1 Flash を残す価値があります。
私のアプリでは、ユーザー向けのチャット機能には 3.1 Flash を使い、管理画面のレポート生成だけ 3.2 に振り分けています。同じモデルで全部統一するより、用途で分けたほうがコストとレイテンシのバランスが取れます。
向かない用途 2: リアルタイム性が求められる音声対話
音声入力からの即応が必要な用途では、現状の 3.2 は最適とは言えません。ストリーミング応答自体は対応していますが、3.1 Flash のスループットには及ばず、対話のテンポが少し重く感じられます。
音声アシスタント系のプロダクトを作っている方は、当面は 3.1 Flash を中心に据え、3.2 は「ユーザーの発話を一括で要約する後処理」にだけ使う、といった分担が現実的です。
向かない用途 3: 厳密に同じ出力を求める定型タスク
3.2 は「文脈を踏まえた柔軟な出力」が得意になった反面、「毎回まったく同じフォーマットで出してほしい」というタスクで微妙な揺らぎが出ることがあります。テンプレートに完全一致させたい場合は、3.1 Flash + 厳密なフューショット例のほうが安定します。
私のアプリのバックエンドでは、定型レポートの生成は 3.1 Flash、要約や考察を含むレポートは 3.2、と使い分けています。
価格・レイテンシ・精度のバランスを取るコツ
実務では、3.2 をすべての処理に使うのは過剰です。私の運用ルールはシンプルで、「入力が 1 万トークン以上、または出力に推論が必要なタスク」は 3.2、それ以外は 3.1 Flash としています。これだけで月のコストが半減し、ユーザー体験のレイテンシも改善されました。
// 簡易ルーティングの例
function pickModel(promptLen: number, requiresReasoning: boolean) {
if (promptLen > 10_000 || requiresReasoning) return "gemini-3.2";
return "gemini-3.1-flash";
}次のアクション
明日からできることは、自分の業務の中で「長文を扱う処理」と「短文を扱う処理」を 1 つずつ選び、それぞれを 3.1 Flash と 3.2 で並走させてみることです。同じ入力での出力を比較するだけで、自分の業務にとっての 3.2 の価値がはっきりします。私自身、この比較をやって初めて、自分のアプリのどのフローに 3.2 を入れるべきかが言語化できました。