個人開発で Gemini を使い始めた頃、私は深く考えずに 2.0 Flash を既定にしていました。安く、速く、たいていの用途では不満がなかったからです。
雲行きが変わったのは、ユーザーが入力した文章から構造化データを取り出す処理を組んだあたりでした。ネストの深い出力を求めると、2.0 Flash はときどき階層を一段取り違える。落ちるわけではありません。けれど後段で弾く処理が少しずつ増えていく。
同じ入力を 2.5 Pro に流してみたところ、取り違えはほぼ消えました。代わりに応答は目に見えて遅くなり、費用も上がります。精度は欲しい、でも全部を重いモデルに投げるのは違う。この記事は、その線引きをどこに置いたかの記録です。2026年4月時点の 2.5 Pro と 2.0 Flash を、実装と費用の両面から並べていきます。
どこで精度差が出たか
体感で差がはっきり出たのは、次のような処理でした。
- ネストの深い構造化抽出：配列の中にオブジェクト、その中にさらに条件付きフィールド、という形の出力
- 複数条件を束ねた判定：入力の中の複数の手がかりを突き合わせて1つの結論を出す処理
- 長めの文章の要約と再編：元の意味を保ったまま圧縮する処理
逆に、感情のポジティブ/ネガティブ判定や単純なカテゴリ分けのような処理では、2.0 Flash と 2.5 Pro の出力に有意な差を感じませんでした。差が出るのは「一度に複数のことを考えさせる」ときです。
私が最初につまずいた構造化抽出を、現行の SDK（@google/genai）で書くとこうなります。
import { GoogleGenAI } from "@google/genai";
const ai = new GoogleGenAI({ apiKey: process.env.GEMINI_API_KEY });
const prompt = `
次のテキストから構造化データを抽出してください。
ネストされたオブジェクト・配列・条件付きフィールドを正確に識別し、
指定のスキーマに沿った JSON だけを返してください。
テキスト:
"顧客は太郎（30歳）で東京在住。過去3件の注文（2026-01-15, 2026-02-20, 2026-03-10）があり、
金額はそれぞれ 5000, 12000, 8500 円。配送先は複数登録されている。"
`;
async function extract(model) {
const res = await ai.models.generateContent({
model,
contents: prompt,
config: {
responseMimeType: "application/json",
responseSchema: {
type: "object",
properties: {
name: { type: "string" },
age: { type: "number" },
location: { type: "string" },
orders: {
type: "array",
items: {
type: "object",
properties: {
date: { type: "string" },
amount: { type: "number" },
},
},
},
},
},
},
});
// 現行 SDK では res.text はプロパティ（関数ではない）
return JSON.parse(res.text);
}ポイントは responseSchema を渡していることです。スキーマを添えると、モデル差による「階層の取り違え」はどちらのモデルでも減ります。それでも、条件付きフィールドが増えたときの安定感は 2.5 Pro のほうが一段上でした。スキーマで土台を固めたうえで、なお崩れやすい処理だけを Pro に回す、という発想がこのあと効いてきます。
応答の速さはどれくらい違うか
同じプロンプトを何度か投げて手元で測った範囲では、2.0 Flash がおおむね 200〜300ms、2.5 Pro が 400〜600ms でした。モデルが大きいぶん、Pro は待ち時間が伸びます。
この差は、用途によって重みがまったく変わります。ユーザーの入力に対してその場で返すチャットのような処理では、100〜300ms の上乗せがそのまま体感の遅さになります。一方、バッチでまとめて処理する場面や、裏側で非同期に走らせる処理では、数百ミリ秒の差はほぼ気になりません。私の分類・抽出まわりは後者だったので、速度はあまり判断材料になりませんでした。
費用を1リクエスト単位で見る
判断の中心になったのは費用です。2026年4月時点の価格（100万トークンあたり）を並べます。
| 項目 | Gemini 2.0 Flash | Gemini 2.5 Pro |
|---|---|---|
| 入力（1Mトークン） | ¥0.6 | ¥1.5 |
| 出力（1Mトークン） | ¥2.4 | ¥6.0 |
| 応答速度の目安 | 200〜300ms | 400〜600ms |
| 向く処理 | 分類・単純抽出・チャット | 深いネスト抽出・複合判定・要約 |
単価だけ見ると 2.5 Pro は 2.0 Flash の約2.5倍です。ただし、実際に効いてくるのは1リクエストあたりの絶対額です。入力500トークン・出力200トークンで月10万リクエストを回すと、こうなります。
- Gemini 2.0 Flash：月額およそ ¥360（1リクエスト ¥0.0036）
- Gemini 2.5 Pro：月額およそ ¥900（1リクエスト ¥0.0090）
差は月 ¥540。個人開発の規模なら、この額は「精度のために払ってよい保険料」の範囲でした。逆に言えば、月に数百万リクエストを超えるような規模だと、この 2.5 倍は無視できない額に育ちます。全部を Pro にするかどうかは、この掛け算の結果次第です。
私の使い分け — 既定は Flash、要所で Pro
結局、私が落ち着いた形は「既定は 2.0 Flash、崩れやすい処理だけ 2.5 Pro に回す」でした。モデルを1つに決め切らず、入力の複雑さで振り分けます。判定は大げさなものではなく、スキーマの深さと入力長でざっくり分けるだけです。
function pickModel(schema, inputText) {
const depth = estimateSchemaDepth(schema); // ネストの深さを数える簡易関数
const longInput = inputText.length > 2000;
// 深いネスト or 長文なら Pro、それ以外は Flash
if (depth >= 3 || longInput) return "gemini-2.5-pro-latest";
return "gemini-2.0-flash-latest";
}この振り分けを入れてから、後段で JSON を弾いて作り直す処理がほとんど呼ばれなくなりました。費用は Flash 一本のときより少し増えましたが、失敗した応答を捨てて再実行する無駄が減ったぶん、体感の安定感は明らかに上がりました。精度と費用を天秤にかけるとき、私自身は「後始末のコスト」まで含めて考えるようにしています。
切り替えるときに詰まったところ
モデル名を差し替えるだけで動く、と思って油断すると足をすくわれます。API の呼び出し方は互換でも、返ってくる文章の癖はモデルごとに違います。私の場合、2.0 Flash 向けに調整していた出力パース（特に JSON の前後に説明文が混ざるかどうか）が、2.5 Pro では挙動が変わり、いったんパースが崩れました。
切り替え時に確かめておきたいのは次の3点です。第一に、responseMimeType と responseSchema を明示しておくこと。これでモデルによらず「JSON だけ」を受け取りやすくなります。第二に、既存のパース処理を本番前にモデルを変えた状態で必ず通しておくこと。第三に、システムプロンプトの粒度です。2.5 Pro は細かい指示をよく汲むので、Flash 時代に削っていた指示を足すと精度が伸びる場面がありました。
まとめ: 一律に決めない
2.5 Pro と 2.0 Flash は、上位互換と下位互換の関係ではありません。速くて安いほうと、深く考えられるほう、という別々の道具です。私の答えは「既定は Flash、崩れやすい処理だけ Pro」でしたが、これはあくまで個人開発という規模での結論です。
なお、ここで挙げた 2.5 Pro / 2.0 Flash は執筆時点より世代が進んでいます。読者の方が実装される時期には、より新しい Flash / Pro の組が既定になっているはずです。それでも「軽い処理は安いモデル、複雑な処理だけ重いモデルに回す」という線引きの考え方はそのまま使えます。まずはご自身のいちばん複雑な処理を両方のモデルに通し、後始末の手間まで含めて比べてみてください。そこに、切り替えるべきかどうかの答えが出ます。
実際に触ってみるなら Google AI Studio で同じ入力を流し、最新のモデル名と価格は Gemini API 公式ドキュメント で確認するのが確実です。お読みいただきありがとうございました。