出力 100万トークンあたり $9 が $7.50 に下がった。入力は $1.50 で据え置き。2026年7月21日に Google が発表した Gemini 3.6 Flash の価格だ。値下げ幅そのものより、公表された「出力トークンが約17%少なくなる」のほうが請求額に効く。単価と使用量は掛け算なので、両方下がると効き方が変わる。
目次
7月21日に出た3モデル
同時に発表されたのは3つで、性格がはっきり分かれている。旗艦の 3.5 Pro は含まれていない。
| モデル | 入力 / 100万 | 出力 / 100万 | 位置づけ |
|---|---|---|---|
| Gemini 3.6 Flash既定候補 | $1.50 | $7.50 | 新しい標準の作業用。1Mコンテキスト維持、知識カットオフは2026年3月へ前進 |
| Gemini 3.5 Flash-Lite | $0.30 | $2.50 | 翻訳・大量データ処理など、高スループット向け |
| Gemini 3.5 Flash Cyber | （用途特化） | セキュリティ領域向けの派生 | |
Google の説明では、3.6 Flash は Artificial Analysis Index の測定で 3.5 Flash より出力トークンが17%少なく、複数手順の作業では推論のステップ数とツール呼び出しの回数も減るとしている。長時間かかる開発作業ではエージェントのトークン費用が最大65%下がる、という数字も出ている。
65%という数字は条件付きの上限値として読んでおきたい。筆者は同じ条件で追試していないので、ここは公表値として扱う。長時間かかる作業でのエージェント利用が対象なので、単発の質問応答でそのまま出る数字ではない。自分の使い方がどちら寄りかで、期待値は変わってくる。
単価の比較だけでは請求額は分からない
モデルを選ぶとき、料金表の数字だけを並べて比べる方法には穴がある。請求額は「単価 × 使ったトークン量」で決まるので、片方だけ見ても答えが出ない。
今回の発表は、その両方が同時に動いた事例になる。出力単価が $9 から $7.50 へ下がり、同じ作業で出力トークンが約17%減るなら、掛け算の結果はもっと大きく動く。
同じ作業を1万回まわしたときの出力費用（仮に1回あたり2,000トークン出力とする）
3.5 Flash : 2,000 × 10,000 = 2,000万トークン → $9.00/100万 × 20 = $180
3.6 Flash : 1,660 × 10,000 = 1,660万トークン → $7.50/100万 × 16.6 = $124.5
※ 1,660 は「17%少ない」の公表値をそのまま当てた仮の値この計算の前提は「同じ作業で出力量が本当に17%減るか」で、そこは自分の使い方で確かめるしかない。要約のように出力が短い作業と、コードを丸ごと書かせる作業では、削減の効き方が違う。
手元で出力トークンを数える
確かめ方は単純で、同じプロンプトを両方のモデルに投げて、返ってきたメタ情報の出力トークン数を記録する。
import os, google.generativeai as genai
genai.configure(api_key=os.environ["GEMINI_API_KEY"])
PROMPT = open("task.md", encoding="utf-8").read() # 自分がよく出す依頼をそのまま使う
for name in ["gemini-3.5-flash", "gemini-3.6-flash"]:
model = genai.GenerativeModel(name)
res = model.generate_content(PROMPT)
u = res.usage_metadata
print(f"{name:20} in={u.prompt_token_count:6} out={u.candidates_token_count:6}")測るときは、自分が実際に使っているプロンプトを使う。ベンチマーク用に作った短い例文で測ると、削減効果が出る場面と出ない場面の区別がつかない。競艇予想AIのようにデータを渡して判断させる用途なら、そのときの入力をそのまま流せばいい。
記録するのは出力トークン数と、成果物が使い物になったかの2列で足りる。安いモデルが短く答えて用を成さないなら、削減は意味を持たない。
実際に測ったら、請求対象は増えていた
この手順を OpenRouter 経由で走らせた。google/gemini-3.6-flash と google/gemini-3.5-flash に、要約・分類・抽出・説明・翻訳の5タスクを temperature=0 で同じ文面で投げ、返ってきた completion_tokens を足した。
結果は逆だった。
| 1回目・5タスク合計 | 出力トークン |
|---|---|
| 3.5 Flash | 1,744 |
| 3.6 Flash | 1,963（+12.6%） |
17%減るはずのものが増えている。目立ったのは「1語で答えて」と指示した分類タスクで、返ってきた答えは warn の1語なのに、出力トークンは206を数えていた。
推論トークンだった。
2回目は completion_tokens_details.reasoning_tokens も一緒に取った。
| 2回目・5タスク合計 | 出力トークン | うち推論 | 本文 |
|---|---|---|---|
| 3.5 Flash | 1,572 | 1,398 | 174 |
| 3.6 Flash請求は増える | 2,173（+38.2%） | 2,026 | 147（-15.5%） |
公表値の17%減は、目に見える本文のほうに出ていた。5タスクで -15.5% なので、公表値に近い。増えたのは推論の側で、3.6 Flash の出力トークンの93%が推論に消えていた。
請求は completion_tokens の合計にかかる。本文が15%減っても、推論が45%増えれば支払いは増える。
| 測定回 | 3.5 Flash の出力費用 | 3.6 Flash の出力費用 | 差 |
|---|---|---|---|
| 1回目 | $0.015696 | $0.014723 | 3.6 が 6.2% 安い |
| 2回目 | $0.014148 | $0.016298 | 3.6 が 15.2% 高い |
同じ5タスクを2回投げただけで、安いほうと高いほうが入れ替わった。temperature を0にしても推論トークン数は揃わない。1回測って結論を出せる差ではなかった。
推論トークンを絞ると効き幅が変わる
費用が推論で決まっているなら、そこを絞るのが早い。OpenRouter の reasoning パラメータで3通り試した。
{"reasoning": {"enabled": false}}
// -> 400 Reasoning is mandatory for this endpoint and cannot be disabled.
{"reasoning": {"effort": "minimal"}}
// -> 200 出力 1 トークン（推論 0）。答えは "error" で正しい
{"reasoning": {"max_tokens": 128}}
// -> 200 出力 93 トークン（推論 92）無効化はできなかった。effort を minimal にすると推論が0になり、分類タスクの出力が1トークンまで落ちた。答えの中身は変わっていない。
定型処理を下位モデルへ振る話を下に書いているが、同じモデルのまま effort を下げる選択肢が先に来る。分類や抽出のように答えが1語で済む処理では、乗り換えより効き幅が大きかった。
この測定は OpenRouter 経由なので、Google の API を直接叩いた場合や別のプロバイダ経由では数字が変わりうる。未検証: GEMINI_API_KEY で直接叩いたときの推論トークンの出方は確かめていない。
知識カットオフが2026年3月へ進んだ
価格の陰に隠れやすいが、知識の基準時点が前へ動いたのは日常の使い勝手に効く。半年前で止まっているモデルに新しいライブラリの使い方を聞くと、廃止済みの書き方を自信たっぷりに返してくる。
筆者はこれで一度痛い目に遭っている。外部APIの廃止予定だった機能を、確認しないまま全経路に組み込んで、ある日いっせいに動かなくなった。以来、モデルが返した「新しめの話」は一次情報で裏を取るようにしている。
カットオフが進むと、この裏取りの回数が減る。ゼロにはならない。2026年3月以降に出た仕様変更は相変わらず知らないので、直近4か月ぶんは自分で確認する前提は残る。今回で言えば、7月28日に確定する MCP の仕様変更などがそれに当たる。
3.5 Pro を出さなかったという情報の使い道
Google は 6月の予定だった 3.5 Pro を出さず、コーディングと複雑な推論が社内の期待に届かなかったと説明している。パートナー向けのテストは続いていて、準備ができ次第の提供とされている。
この情報は、モデル選定の材料として使える。旗艦モデルの登場を待って設計を止めるより、いま手に入る Flash 級で足りる範囲を確かめておくほうが前に進む。届かない部分が具体的に分かっていれば、旗艦が出たときに何を測り直すかもすぐ決まる。
筆者は常に最上位のモデルを指名する使い方をしていない。難所だけ上位に振り、実装は下位に任せる形を既定にしている。この方針だと、旗艦が遅れても手が止まらない。
安いモデルへどこまで振れるか
費用を下げる作業は、モデルを乗り換えるよりタスクを分類し直すほうが効く。同じプロジェクトの中でも、要求される判断の重さは一定ではない。
| 作業 | 振り先 | 理由 |
|---|---|---|
| 翻訳・整形・分類のような定型処理 | Flash-Lite | 出力が短く、正解が明確。単価差がそのまま効く |
| 日常の実装・修正主戦場 | 3.6 Flash | 出力量の削減が最も効く帯。失敗のやり直しも少ない |
| 設計判断・原因不明の不具合 | 上位モデル | ここを安く済ませると、やり直しで結局高くつく |
分類の見直しで詰まったら、直近1週間に投げた依頼を10件ほど眺めてみるといい。半分以上が定型処理なら、そこを下位モデルへ振るだけで請求額は動く。開発の進め方で書いたとおり、AI の出力は読んでから受け取る前提なので、下位モデルに振った処理ほど検算のしやすさで選ぶ。
値下げより効くのは、使用量を見る習慣
単価が下がった月に請求額が上がる、ということは普通に起きる。安くなったぶん気軽に投げるようになり、回数が増えるからだ。個人開発だと自分以外に止める人がいないので、この増え方に気づくのが遅れる。
筆者が決めているのは、週に1回だけ使用量を見る時間を作ることだ。毎日見ると細かい上下に振り回されるし、月に1回だと請求が確定してから気づく。週次なら、増えた原因になった作業がまだ記憶に残っている。
見る数字も3つに絞っている。今週の合計費用、いちばん費用を使った処理、先週との差。差が大きい週だけ、その処理の中身を確認すればいい。原因はたいてい1つの処理に偏っていて、全体を見直す必要はない。
この習慣があると、モデルの乗り換え判断も速くなる。乗り換えた翌週の数字を見れば、公表値どおりに減ったかが分かる。減っていなければ、自分の使い方が公表値の前提と違うということになる。
下位モデルへ振るときの見分け方
Flash-Lite は入力 $0.30・出力 $2.50 で、3.6 Flash と比べても大きく安い。安さに引かれて何でも振ると、やり直しの回数で損をする。振ってよいかどうかは、次の3点で判断できる。
正解が機械的に検算できるか。翻訳の訳抜け、JSON の形式、分類ラベルの妥当性。出力を自動で検査できるなら、多少精度が落ちても取り返せる。
失敗したときの被害が小さいか。下書きの生成なら書き直せばいい。公開直前の校正で見落とすと、そのまま世に出る。
入力が短いか。長い文脈を読ませる作業は、モデルの理解力が結果を左右する。ここを安いモデルに振ると、内容を取り違えた出力が返ってきて、確認の手間が増える。
よくある疑問
17%削減は日本語でも同じか。公表値は特定の指標での測定なので、日本語の作業でそのまま出るとは限らない。自分のプロンプトで測るのが確実になる。
乗り換えのタイミングは。既存の処理が安定して回っているなら、急ぐ理由は薄い。新しく組む処理から使い始めて、比較の材料が溜まってから既存分を移すほうが安全になる。
3.5 Flash はいつまで使えるか。提供終了の告知は出ていない。ただし旧モデルが残り続ける保証もないので、切り替え手順だけは用意しておきたい。モデル名を1箇所にまとめておけば、差し替えは設定変更で済む。
まとめ
今回の発表で確かめるべきなのは、値下げ幅ではない。自分がよく出す依頼で、出力トークンが実際にどれだけ減るかだ。減り方は作業の性質で変わるので、公表値をそのまま自分の請求額に当てはめられない。
今日やるなら、直近でいちばん多く投げているプロンプトを1つ選び、新旧2モデルに同じ内容を投げて出力トークン数を並べる。2回以上まわすこと。筆者の5タスクでは、1回目と2回目で安いモデルが入れ替わった。あわせて推論トークンを別列で記録すると、本文が減っているのに請求が増える状況を見分けられる。
測った結果は、日付とプロンプトの内容を添えて残しておきたい。次にモデルが出たとき、同じ手順で比べられる。手元に基準値があるかどうかで、新しい発表への向き合い方が変わる。公表値を読んで想像するか、自分の数字と並べて判断するかの差になる。
一次ソース: Introducing Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber（Google）
