Gemini 3.8 Flash は単価が据え置きでも、請求が増えることがあります

モデル ID を1行書き換えるだけの作業になるはずでした。9月2日に Gemini 3.8 Flash が一般提供へ移ったあと、私はまず料金の欄を開いて、入力 $0.75・出力 $3.75 per 1M という数字が 3.7 Flash と同じであることを確かめました。同じ単価なら、迷う理由はありません。

手が止まったのは、そのあとに続く短い段落を読んだときでした。3.8 Flash は難しい課題に対して「より手を尽くす」設計で、推論の刻みを細かくし、ツールを繰り返し呼び、自分の出した答えを途中で検証しながら進みます。そのぶんトークンを多く使うことがある——と、はっきり書かれていたのです。

単価が動かなくても、使うトークンが増えれば請求は増えます。書いてしまえば当たり前のことなのですが、料金表の数字だけを見比べていた私は、あやうく見落とすところでした。

単価と請求は、別の数字です

まず事実の確認からお伝えします。Gemini 3.8 Flash・3.7 Flash・3.6 Flash はいずれも 2026年12月31日まで導入価格が適用され、2027年1月1日から標準価格に切り替わります。

項目	導入価格（〜2026-12-31）	標準価格（2027-01-01〜）
入力 per 1M tokens	$0.75	$1.50
出力 per 1M tokens	$3.75	$7.50

3.8 Flash のモデル ID は gemini-3.8-flash、既定の thinking level は medium、コンテキストは 100 万トークン、最大出力は 64k トークンです。数字はいずれも Gemini API の 3.8 Flash 解説ページに載っています。

ここで押さえておきたいのは、請求書に出てくる金額が「単価 × トークン数」だという点です。単価の列が 3.7 と 3.8 で並んでいるなら、動く余地があるのはトークン数のほうだけになります。

増えるのは、モデルが考える手数です

3.8 Flash では thinking level を low / medium / high から選べます。既定は medium で、minimal は指定するとエラーになりますので、以前の設定をそのまま持ち込むと最初の呼び出しで止まります。

from google import genai
 
client = genai.Client()
 
interaction = client.interactions.create(
    model="gemini-3.8-flash",
    input="この請求書 PDF から、日付・品目・税抜金額だけを JSON で抜き出してください。",
    generation_config={
        # 定型の抽出なので low で十分です（既定は medium）
        # minimal は 3.8 Flash では非対応でエラーになります
        "thinking_level": "low"
    },
)
 
print(interaction.output_text)

公式ドキュメントは、この点について移行を急がせる書き方をしていません。日常的な作業であれば effort を下げてトークン消費を抑えられること、そして 3.7 Flash は効率重視のワークロード向けに引き続き完全にサポートされることが、どちらも明記されています（Google 公式ブログにも同じ趣旨の記述があります）。

「新しいほうが良い」ではなく「仕事の性質で選んでください」という案内なのだと受け取りました。個人開発で Lab のサイト群を回している私の側から見ると、実際に走らせている処理の多くは、難しい判断ではなく同じ形の変換を大量に繰り返す仕事です。多言語の下訳、記事メタデータの整理、ストア掲載文の文字数調整——手数を増やしてもらう必要がない種類の作業ばかりでした。

切り替える前に、出力トークンを1週間だけ記録します

見積もりを立てるには、いまの数字が要ります。難しい計測は不要で、既存の呼び出しに1行足すだけで足ります。

import json
import time
 
def log_usage(interaction, route: str, path: str = "usage.jsonl") -> None:
    """1回の呼び出しのトークン数を追記します。集計は後からで構いません。"""
    u = interaction.usage  # SDK のバージョンによって属性名が異なる場合があります
    record = {
        "ts": time.time(),
        "route": route,          # どの経路の呼び出しかを必ず残します
        "model": interaction.model,
        "input_tokens": getattr(u, "input_tokens", None),
        "output_tokens": getattr(u, "output_tokens", None),
    }
    with open(path, "a", encoding="utf-8") as f:
        f.write(json.dumps(record, ensure_ascii=False) + "\n")

route を必ず入れておくことをお勧めします。あとで「翻訳の経路だけ 3.7 に残す」といった判断をするとき、経路ごとの平均が出せないと選びようがないためです。私自身、最初はモデル名だけを記録していて、平均が1本にまとまってしまい、測り直す羽目になりました。

記録した数字を、年末と年明けの二本立てで見積もります

1週間ぶんの平均が取れたら、あとは掛け算です。次のスクリプトは、3.7 に据え置いた場合と 3.8 へ切り替えた場合の月額を、導入価格と標準価格の両方で出します。

INTRO = {"input": 0.75, "output": 3.75}      # 2026-12-31 まで
STANDARD = {"input": 1.50, "output": 7.50}   # 2027-01-01 から
 
 
def monthly_cost(calls_per_day, in_tokens, out_tokens, price, days=30):
    total_in = calls_per_day * days * in_tokens
    total_out = calls_per_day * days * out_tokens
    return (total_in * price["input"] + total_out * price["output"]) / 1_000_000
 
 
def compare(calls_per_day, in_tokens, out_tokens, growth):
    """growth は 3.8 に切り替えたときの出力トークンの倍率です。"""
    out_38 = out_tokens * growth
    rows = []
    for label, price in (("導入価格", INTRO), ("標準価格", STANDARD)):
        keep = monthly_cost(calls_per_day, in_tokens, out_tokens, price)
        move = monthly_cost(calls_per_day, in_tokens, out_38, price)
        rows.append((label, keep, move, move - keep))
    return rows
 
 
CALLS, IN, OUT, GROWTH = 500, 1200, 800, 1.35
for label, keep, move, diff in compare(CALLS, IN, OUT, GROWTH):
    print(f"{label}: 据え置き ${keep:.2f} / 切替 ${move:.2f} / 差額 ${diff:.2f}")
 
# 導入価格: 据え置き $58.50 / 切替 $74.25 / 差額 $15.75
# 標準価格: 据え置き $117.00 / 切替 $148.50 / 差額 $31.50

例として置いた 1日 500 回・入力 1,200 トークン・出力 800 トークンという形で、出力が 1.35 倍になったとします。このとき月額は $58.50 から $74.25 へ、差額は $15.75 です。

ここで一つ、私が計算するまで感覚を外していたことがあります。出力が 1.35 倍になっても、総額は 1.35 倍にはなりません。 この例で総額が増えたのは 26.9% でした。理由は単純で、出力が総額に占める割合がこの構成では 76.9% しかないからです。35% の伸びに 76.9% を掛けると 26.9% になります。

つまり、長いコンテキストを毎回送っていて入力側が重い構成ほど、出力が増えても総額はさほど動きません。逆に短いプロンプトで長文を書かせる構成では、手数の増加がほぼそのまま請求に乗ります。同じ「3.8 に上げる」でも、影響の大きさは経路ごとに違うのです。

そしてもう一つ、年明けの扱いを忘れないでください。標準価格に切り替わると、据え置きも切替も金額が倍になりますので、差額も倍になります。上の例では $15.75 だった差が $31.50 になります。いま許容できる差だからという理由だけで決めてしまうと、1月の請求書で同じ判断をもう一度することになるかもしれません。

出力トークンが総額へどう効くかを分解した記録は、出力トークンが17%減ったときに総額はいくら下がるのかにも書いております。価格改定そのものへの対処は、3.7 Flash の値上げ分をバッチ層で相殺した記録のほうが近い話になります。

私が引いた線引きと、切り替えるときに外すもの

いまのところ、私はこう決めています。手数をかけてほしい仕事だけ 3.8 に渡し、同じ形を繰り返す仕事は 3.7 に残します。 多段の調査や、複数ファイルにまたがる修正のように「途中で自分の答えを検証してほしい」場面では 3.8 の設計が効きます。一方で下訳や整形のように答えの形が決まっている経路では、手数が増えても品質はほとんど動かず、請求だけが伸びます。

実際に gemini-3.8-flash へ差し替えるときは、古い設定を持ち込まないようにしてください。移行時に外すものは決まっています。

temperature / top_p / top_k を生成設定から削除します
thinking_budget を文字列の thinking_level へ置き換えます（minimal は使えません）
candidate_count を削除します（Gemini 3 以降は非対応です）

サンプリング系のパラメータについては、非推奨化のときに私が困ったのは決定性ではなく多様性の側でした。その経緯はtemperature 非推奨で先に困ったのは多様性の側だった話に書き残しています。

まず今週は、いちばん呼び出し回数の多い経路を1つだけ選んで、そこに出力トークンのログを足してみてください。数字が7日ぶん溜まってから決めても、12月31日までにはまだ間があります。

お読みいただきありがとうございました。私自身、料金表の同じ数字を見て安心しかけた側ですので、同じ落とし穴を先に共有できていれば嬉しいです。