Gemini 3.6 Flashの「出力17%減」は請求額17%減ではない — 公表単価を自分のログに掛けてから決める

Googleの発表は2026年7月21日付。Gemini 3.6 Flashは入力100万トークンあたり$1.50、出力$7.50。Gemini 3.5 Flash-Liteは入力$0.30、出力$2.50で、両モデルとも発表日からGemini APIなどで提供されている。

GoogleはArtificial Analysis Index上で、3.6 Flashの出力トークン量が3.5 Flashより17%少ないと説明している。Flash-Liteの毎秒350出力トークンという速度も、同Indexの測定値として紹介されている。

価格は確認できる。私が確かめたいのは、その価格に自分の日本語タスクの消費量を掛けたとき、何円で仕事が終わるかだ。そこは発表の数字を写すだけでは埋まらない。

17%という数字を、そのままコスト削減率として読んではいけない。これは出力側だけの話だ。

仮に入出力の単価と入力数が変わらず、出力だけ17%減るなら、請求の削減率は「出力が請求額に占める割合 × 17%」になる。トークン数の割合ではなく、単価を掛けた後の割合だ。3.6の単価で入力1000万・出力100万なら$22.50。この出力だけが17%減っても、減るのは$1.275、全体の約5.7%に留まる。

実際の3.5から3.6への比較には、Googleが説明している単価の引き下げも加わる。だから17%だけから全体の削減率は決められない。移行前の実請求と、3.6で同じ仕事を終えた実測の「入力100万単位 × $1.50 ＋ 出力100万単位 × $7.50」を比べる。完了ターン数や手直しも含めて、初めて仕事一件の比較になる。

以前この欄で先に扱った3.7 Flashは8月13日の発表で、3.6の7月21日より後だ。逆だったのはLensWeaveの掲載順。型番が逆行したわけではない。3.7を試すとした以前の判断も、3.6の価格だけでは実運用の成否を判定できない。

速度の350という数字は、日本の読者にとってそのまま読めない。

トークン毎秒は、文字毎秒ではない。日本語は同じ内容を書くのに英語より多くのトークンを消費する傾向があり、その比率はモデルのトークナイザ次第で変わる。だから毎秒350トークンが日本語UIで体感何文字/秒になるかは、この発表文からは計算できない。比率が明記されていない以上、私は推定値を置かない。自分のプロンプトを1回投げて、文字数をトークン数で割れば出る話だ。

そして、速いモデルがエージェントを速くするとは限らない。ループの実時間を食うのは、生成の吐き出し速度よりも、最初の1トークンまでの待ち時間とツール呼び出しの往復回数であることが多い。生成が2倍速くても、ツール実行が5秒かかるならユーザーが見る時間はほとんど変わらない。350という数字が効くのは、長い出力を人間が読みながら待つ画面 — チャットUIやストリーミング表示 — のほうだ。

判定：3.6 Flashへの本番移行は様子見。単価は公表済みだが、自分の日本語タスクの実費と品質はまだ測っていない。Flash-Liteは試す。まずは短い抽出や分類など、失敗の影響を見比べやすい外側の処理に置く。

1. 今の請求から、入力と出力それぞれのトークン数と支払額を分ける。出力トークンの割合だけで17%の価値を切り捨てない。
2. 同じ日本語プロンプトをまず10本、3.5 Flashと3.6 Flashへ通す。単価差も含めた一件あたりの費用、完了ターン数、手直し量を並べる。10本は入口であって、日本語全体を代表する証明ではない。
3. Flash-Liteでも同じ短い処理を試し、最初のトークンまでと完了までの時間を測る。毎秒350トークンを、そのまま待ち時間の短縮率にしない。
4. 自分の契約のレート制限と提供条件を確認する。並列数を決めるのはベンチマークではなく、実際に使える枠だ。
5. 型番と単価は一箇所で管理する。価格が出るのを待つのではなく、現在の価格で自分の仕事が成立するかを測って判定を更新する。

訂正（2026年9月13日）：公表済みの単価と発表順を反映し、費用計算と実測手順を訂正しました。