Gemini 3.7 Flash が一般提供に入ったのは8月13日でした。案内に「2026年12月31日までは導入価格」とあったので、どのくらい安いのかを見ようと料金表を開きました。
そこに並んでいた数字は、3.6 Flash とまったく同じでした。
入力 $0.75、出力 $3.75。新しいモデルに付いた割引ではなく、Flash 系全体に同じ期限が付いているだけだったのです。そして料金表をもう少し下までたどったところで、話の重心が動きました。この「導入価格」は、年明けに割引が消えるという話ではありません。単価がそのまま倍になる という話でした。
倍になるモデルと、ならないモデルがあります。その線引きを取り違えたまま年を越すと、1月の請求で初めて気づくことになります。
「導入価格」は 3.7 Flash だけの特典ではありませんでした
まず、料金表に書かれている数字をそのまま並べます。以下は2026年8月16日時点の Gemini Developer API の料金ページ を確認したもので、単位は 100万トークンあたりの USD、Paid Tier の Standard 層です。
モデル 入力（2026年内） 入力（2027年〜） 出力（2026年内） 出力（2027年〜）
gemini-3.7-flash$0.75 $1.50 $3.75 $7.50 gemini-3.6-flash$0.75 $1.50 $3.75 $7.50 gemini-3.5-flash$1.50 $1.50 $9.00 $9.00 gemini-3.5-flash-lite$0.30 $0.30 $2.50 $2.50
3.7 Flash と 3.6 Flash は、入力も出力も同じ数字です。つまり「新しいほうを選ぶと高い」という前提は、少なくとも今は成り立ちません。3.6 Flash から 3.7 Flash へ寄せる判断に、金額面の抵抗はありません。
もうひとつ、この表を眺めていて意外だったのは 3.5 Flash の位置です。世代がひとつ前で、単価は 3.7 Flash の2倍。導入価格の設定もないので、年が明けても $1.50 / $9.00 のままです。年明け以降の 3.7 Flash（$1.50 / $7.50）と並べると、入力は同額で、出力は 3.7 Flash のほうが安いことになります。3.5 Flash に留まる金銭的な理由は、今も来年もありません。
新しいモデルへの移行を「安定してから」と先送りしていた場合、その先送りは節約になっていない、というのがここでの結論です。
値上げされるモデルと、されないモデルがあります
もう一度、表の右半分だけを見ます。単価が動くのは 3.7 Flash と 3.6 Flash だけで、3.5 Flash と 3.5 Flash-Lite は据え置きです。
これは「一律の値上げ」ではありません。モデル間の価格比が変わる ということです。
比較 2026年内 2027年〜
3.7 Flash ÷ 3.5 Flash-Lite（入力） 2.5倍 5.0倍 3.7 Flash ÷ 3.5 Flash-Lite（出力） 1.5倍 3.0倍
軽いモデルと重いモデルを振り分けて使っている構成では、この比の変化がそのまま設計への圧力になります。今は「迷ったら上位に投げる」で許容できていた振り分けが、年明けには許容できなくなる可能性があります。振り分け率をどこまで下げれば請求を維持できるのかは後半で計算しますが、まず押さえておきたいのは、値上げの影響はモデル単体ではなく構成全体に効く という点です。
なお、Flash-Lite が据え置きということは、年明け以降は「安いほうへ寄せる」動機が今より強くなるということでもあります。品質要件が許すなら、この数か月は Flash-Lite で通る範囲を広げておく期間として使えます。
バッチ層へ移すと、値上げ分がちょうど打ち消されます
料金表には Standard のほかに Batch と Flex という層があります。3.7 Flash の場合、この2つは Standard の半額です。
層 入力（2026年内） 入力（2027年〜） 出力（2026年内） 出力（2027年〜）
Standard $0.75 $1.50 $3.75 $7.50 Batch / Flex $0.375 $0.75 $1.875 $3.75
ここで、2027年以降の Batch 層の数字と、2026年内の Standard 層の数字を見比べてください。$0.75 と $0.75、$3.75 と $3.75。完全に一致します。
今 Standard で回している処理をバッチ層へ移せば、年明けの値上げ分はちょうど打ち消されます。 入力と出力が同じ倍率で動き、バッチ層が一貫して半額であることから、この一致はトークンの内訳に依存しません。入力偏重の分類処理でも、出力偏重の生成処理でも、同じように成立します。
言い換えると、年明けの値上げに対して取れる手は「使用量を減らす」だけではありません。遅延を差し出すことで金額を据え置く という選択肢があります。バッチ層は即時の応答を返さないため、この交換が成立するのは待てる処理だけですが、待てる処理は思っているより多いはずです。
バッチ層そのものの使い方はGemini Batch Processing API — 大量リクエストを50%オフで効率処理する で扱っていますので、投入の手順はそちらに譲ります。ここで確かめたいのは、その半額が「今の請求を守るのにちょうど足りる」という関係です。
自分の使用量で確かめる
比率の話は、自分の数字に当てはめない限り実感になりません。料金表を持った小さな見積もりスクリプトを用意しておくと、モデルや層を変えるたびに手で計算し直さずに済みます。
"""2027-01-01 の価格改定が、自分のワークロードにいくら効くかを出す。 価格は 2026-08-16 時点の Gemini Developer API 料金ページより（USD / 100万トークン）。 """ from dataclasses import dataclass
@dataclass ( frozen = True ) class Rate : inp: float out: float
# (モデル, 層) -> (2026年内のレート, 2027年以降のレート) PRICES = { ( "gemini-3.7-flash" , "standard" ): (Rate( 0.75 , 3.75 ), Rate( 1.50 , 7.50 )), ( "gemini-3.7-flash" , "batch" ): (Rate( 0.375 , 1.875 ), Rate( 0.75 , 3.75 )), ( "gemini-3.6-flash" , "standard" ): (Rate( 0.75 , 3.75 ), Rate( 1.50 , 7.50 )), ( "gemini-3.5-flash" , "standard" ): (Rate( 1.50 , 9.00 ), Rate( 1.50 , 9.00 )), ( "gemini-3.5-flash-lite" , "standard" ): (Rate( 0.30 , 2.50 ), Rate( 0.30 , 2.50 )), ( "gemini-3.5-flash-lite" , "batch" ): (Rate( 0.15 , 1.25 ), Rate( 0.15 , 1.25 )), }
def monthly_cost (model, tier, in_tokens, out_tokens, era): """era は "2026"（導入価格の期間内）か "2027"（改定後）。""" now, later = PRICES [(model, tier)] rate = now if era == "2026" else later return (in_tokens / 1_000_000 ) * rate.inp + (out_tokens / 1_000_000 ) * rate.out
def compare (label, model, in_tokens, out_tokens): rows = [] for tier in ( "standard" , "batch" ): a = monthly_cost(model, tier, in_tokens, out_tokens, "2026" ) b = monthly_cost(model, tier, in_tokens, out_tokens, "2027" ) rows.append((tier, a, b, b - a))
print ( f " \n [ { label } ] { model } in= { in_tokens :, } out= { out_tokens :, } tokens/月" ) print ( f " { '層' :<10 }{ '2026年内' :>12 }{ '2027年〜' :>12 }{ '差額' :>12 } " ) for tier, a, b, d in rows: print ( f " { tier :<10 }{ a :>11.2f } $ { b :>11.2f } $ { d :>+11.2f } $" )
std_now = rows[ 0 ][ 1 ] # 今の Standard batch_later = rows[ 1 ][ 2 ] # 年明けの Batch print ( f " → 今の standard { std_now :.2f } $ と 2027年の batch { batch_later :.2f } $ の差: " f " { batch_later - std_now :+.4f } $" )
if __name__ == "__main__" : compare( "分類バッチ相当" , "gemini-3.7-flash" , 40_000_000 , 2_000_000 ) compare( "対話・生成相当" , "gemini-3.7-flash" , 8_000_000 , 6_000_000 ) 入力偏重のワークロードと出力偏重のワークロードを、わざと両方入れてあります。実行するとこうなります。
[分類バッチ相当] gemini-3.7-flash in=40,000,000 out=2,000,000 tokens/月 層 2026年内 2027年〜 差額 standard 37.50$ 75.00$ +37.50$ batch 18.75$ 37.50$ +18.75$ → 今の standard 37.50$ と 2027年の batch 37.50$ の差: +0.0000$
[対話・生成相当] gemini-3.7-flash in=8,000,000 out=6,000,000 tokens/月 層 2026年内 2027年〜 差額 standard 28.50$ 57.00$ +28.50$ batch 14.25$ 28.50$ +14.25$ → 今の standard 28.50$ と 2027年の batch 28.50$ の差: +0.0000$ トークンの内訳がまったく違う2つで、差額がどちらも 0.0000$ になります。前節で書いた「打ち消される」は、都合のよい条件を選んだ結果ではありません。
このスクリプトを置いておく価値は、金額そのものよりも前提を1か所に集めておける ことにあります。料金は変わります。表が更新されたら PRICES を書き換えるだけで、見積もりの側は触らずに済みます。投入前にコストの上限を機械的に止める仕組みまで作るなら、countTokens でバッチ投入前にコスト超過を止める設計 と組み合わせるとつながります。
ルーターの昇格率は、年明けに三分の一まで下がります
軽い処理を Flash-Lite、難しい処理を 3.7 Flash へ振り分ける構成を取っている場合、年明けに何が起きるかを見ておきます。Flash-Lite は据え置きで、3.7 Flash だけが倍になるので、同じ振り分け率でも請求の伸び方は一定ではありません。
"""Flash-Lite と 3.7 Flash を振り分けるルーターの、年明けの実質コスト変化を出す。""" BIG = { "2026" : ( 0.75 , 3.75 ), "2027" : ( 1.50 , 7.50 )} # gemini-3.7-flash standard SMALL = { "2026" : ( 0.30 , 2.50 ), "2027" : ( 0.30 , 2.50 )} # gemini-3.5-flash-lite standard
IN_PER_REQ , OUT_PER_REQ = 3_000 , 400 # 1リクエストあたりのトークン数（分類系の想定） REQS = 300_000 # 月間リクエスト数
def blended (p, era): """p = 上位モデルへ昇格させる割合。""" bi, bo = BIG [era] si, so = SMALL [era] big = REQS * p * ( IN_PER_REQ / 1e6 * bi + OUT_PER_REQ / 1e6 * bo) small = REQS * ( 1 - p) * ( IN_PER_REQ / 1e6 * si + OUT_PER_REQ / 1e6 * so) return big + small
print ( f "月間 { REQS :, } req / req あたり in= { IN_PER_REQ :, } out= { OUT_PER_REQ } " ) print ( f " { '昇格率' :>8 }{ '2026年内' :>12 }{ '2027年〜' :>12 }{ '増加率' :>10 } " ) for p in ( 0.05 , 0.10 , 0.20 , 0.30 , 0.50 ): a, b = blended(p, "2026" ), blended(p, "2027" ) print ( f " { p * 100 :>7.0f } % { a :>11.2f } $ { b :>11.2f } $ { (b / a - 1 ) * 100 :>9.1f } %" )
# 2026年内の請求額を 2027年以降も維持するには、昇格率をどこまで下げる必要があるか for p0 in ( 0.10 , 0.20 , 0.30 ): target = blended(p0, "2026" ) lo, hi = 0.0 , p0 for _ in range ( 80 ): # 二分探索 mid = (lo + hi) / 2 if blended(mid, "2027" ) > target: hi = mid else : lo = mid print ( f "昇格率 { p0 * 100 :.0f } % の請求を維持するには、年明けは { lo * 100 :.1f } % まで下げる必要があります" ) 実行結果です。
月間 300,000 req / req あたり in=3,000 out=400 昇格率 2026年内 2027年〜 増加率 5% 597.75$ 654.00$ 9.4% 10% 625.50$ 738.00$ 18.0% 20% 681.00$ 906.00$ 33.0% 30% 736.50$ 1074.00$ 45.8% 50% 847.50$ 1410.00$ 66.4% 昇格率 10% の請求を維持するには、年明けは 3.3% まで下げる必要があります 昇格率 20% の請求を維持するには、年明けは 6.6% まで下げる必要があります 昇格率 30% の請求を維持するには、年明けは 9.9% まで下げる必要があります 見てほしいのは最後の3行です。維持に必要な昇格率が、いずれも元のおよそ三分の一 になっています。10% なら 3.3%、20% なら 6.6%、30% なら 9.9%。
なぜ半分ではなく三分の一なのか。倍になるのは上位モデルの単価であって、請求全体ではないからです。Flash-Lite に流している分は動きません。動くのは「上位へ昇格させたことによる上乗せ分」だけで、この上乗せが3倍強に膨らみます。上位モデルの単価が2倍でも、下位との差額は2倍を超えて開くのです。
この三分の一という比率は、上の入出力比における値です。出力が長いワークロードでは倍率が変わりますから、そこは自分の数字を入れて確かめてください。ただ、「単価が2倍だから昇格率を半分にすれば済む」という直感は、どの条件でも成り立ちません。 半分に絞っても請求は増えます。
私のパイプラインで、どこを動かしたか
個人開発で壁紙アプリを運用していて、新しく追加した画像にカテゴリを付ける処理を Gemini に任せています。分類の結果は App Store と Google Play に出しているアプリの一覧表示にそのまま反映されます。数十のカテゴリへ分類するだけの単純な仕事で、まとまった枚数を一度に流します。もうひとつ、運営しているサイト群の下書き生成があり、こちらは書き上がるまで待つ性質のものです。
長らく、この2つを同じ層で回していました。理由は特になく、最初に動いた形をそのまま続けていただけです。
今回の価格改定を機に、分けることにしました。判断の軸は品質でもトークン量でもなく、**「結果を何分待てるか」**の一点です。
処理 結果が要る時刻 層 理由
画像のカテゴリ分類 翌朝までに揃っていればよい Batch 誰も待っていない。夜間に流して朝に受け取れば足りる 下書きの生成 数分以内 Standard 結果を見てその場で書き直す。待ち時間が作業の速度そのものになる
分けてみて気づいたのは、「待てない」と思い込んでいた処理の多くは、待てないのではなく待ったことがなかっただけ だということでした。分類処理を夜間に寄せても、朝に結果が揃っていれば私の手順は何も変わりません。同期で回していたのは、そのほうが確認しやすかったからで、要件ではありませんでした。
一方で、下書き生成をバッチへ落とすのは無理でした。この場合は半額よりも手の速さを取ります。ここは待ち時間が思考の速度に直結するので、半額のために数十分待つ交換は割に合いません。値段だけを見て全部をバッチへ寄せると、金額は下がっても手が止まります。
もうひとつ、実際にやってみて詰まった点を書いておきます。バッチへ移す作業そのものよりも、どの処理がどの層で走っているのかを把握し直すほうに時間がかかりました。 呼び出し箇所がいくつかに分かれていて、どれが同期でどれが非同期なのかが、コードを読むまで自分でも分からない状態だったのです。層を分ける前提として、モデル名と層の指定を設定側の1か所に集めておく必要がありました。この整理は、次にモデルが入れ替わるときにも効きます。
年末をまたぐジョブは、またがせないほうが確実です
移行を前倒しで進めるなら、ひとつ注意点があります。バッチ層のジョブは投入から完了まで時間がかかるので、12月31日に投入したジョブが1月1日に完了する という状況がありえます。
このとき、どちらの単価で課金されるのか。投入時点なのか、トークンが処理された時点なのか。料金ページには、そこまでの記載を見つけられませんでした。
分からないものを本番運用で確かめるのは、いちばん高くつく学び方です。私は、年末年始をまたぐ大きなジョブを組まないという形で回避することにしました。12月下旬の投入は小さく分割し、日付をまたぐ前に完了させます。これなら、どちらの解釈でも結果は変わりません。
同じ考え方は、失敗したジョブの再試行にも当てはまります。12月に投入して失敗したジョブを1月に再投入すれば、その分は新しい単価で処理されます。年末に向けては、再試行の余地を残さない小さい単位で投入する ほうが、金額の予想が立ちます。バッチの部分失敗をどう扱うかを決めていない場合は、この機会に整理しておくとよいと思います。
年内に決めておくこと
期限は2026年12月31日で、まだ4か月以上あります。ただ、年末は落ち着いて設計を見直せる時期ではないことが多いので、余裕のあるうちに次の3つだけ決めておくと楽になります。
待てる処理と待てない処理の線を引く。 分類・集計・要約・整形など、人が画面の前で待っていない処理を洗い出します。この線引きさえできていれば、バッチ層への移行は後からでも間に合いますモデル名と層の指定を、設定の1か所に集める。 コードのあちこちに直書きされていると、比較のたびに書き換えが要ります。切り替えられる形にしておくことが、判断より先に必要な準備です今の使用量を記録に残す。 年明けに請求が増えたとき、値上げによる増加なのか使用量が伸びたのかを、後から切り分けられるようにしておきます。入力と出力のトークン数を月次で控えておくだけで足ります
3.7 Flash への移行そのものは、3.6 Flash と同額である以上、価格を理由に迷う必要がありません。考えるべきは、その先の12月31日に向けて構成を整えておくかどうか です。
まずは、自分のワークロードのうち「誰も待っていない処理」を1つ選んで、バッチ層で流してみてください。半額が効くかどうかより先に、その処理を待てるかどうかが分かります。
料金は変わりますし、この記事の数字も8月16日時点のものです。移行を決める前には料金ページで現在の値を確かめていただければと思います。私自身、価格表を開くまで 3.6 Flash と同額だとは思っていませんでした。前提は静かに変わるので、定期的に開き直す価値のあるページだと感じています。お読みいただきありがとうございました。