比較

Gemini 3.6 Flash 対 Gemini 3.5 Flash：本番ワークロードを移すべきか？

Jacey

Founder

2026年7月21日

32 分

最終確認日：2026-07-21。執筆：Jacey。モデル発表当日に実施した 216 回の API 呼び出しを含み、手法は結果が登場するセクションで詳しく説明します。EvoLink はサードパーティ製モデルにルーティングする API ゲートウェイを運営しており、本記事で扱う両モデルもそこに含まれます。

短い結論

今すぐ移す：出力 token が請求の大半を占めるなら。agent ループ、長いコード生成、推論の重い作業は 26〜29% 安い範囲に収まります。
効果は小さい：トラフィックが入力寄りなら。出力 1 token あたり入力がおよそ 20 token の文書パイプラインで、節約は 7.1% です。入力価格がまったく変わっていないからです。
知能は横ばい。 独立した計測は、同じ指標で 2 つのモデルを 50.1 と 50.2 に置きます。動いたのは速度です。出力は毎秒 165 token から 304 token へ、タスクあたりは 2.7 分から 1.3 分へ。
まずテスト：ワークロードが知識集約型か、フロントエンド UI を生成するなら。公表された証拠が逆方向を指しているのは、この 2 か所です。
thinking レベルは、モデルよりも請求を大きく動かします。 私たち自身のテストでは、既定の medium から minimal へ下げると、私たちのタスクセットで精度を落とさずに 1 パスのコストを 73.6% 削減しました。どのモデルを使うにせよ、意図的に設定してください。
これはモデル文字列の差し替えでは済みません。 temperature、top_p、top_k は今や受け付けられ、そのあとエラーなく無視され、thinking_budget はもう存在しません。

手短な答え、ワークロード別

このアップグレードの価値は、ほぼ完全に 2 つのことで決まります。トラフィックにおける入力 token と出力 token の比率と、いまレイテンシが不満になっているかどうかです。

あなたのワークロード	判断	理由
マルチターン agent、tool 呼び出しループ、長いコード生成	移す	出力と thinking token が大半を占め、価格が下がったのはそこだけ
タスクのレイテンシが不満になっている場合すべて	移す	独立した計測でタスクあたりの時間がおよそ半減
知識集約型の質問応答	まずシャドー実行	直接比較できる唯一の世代横断の知識スコアは下がった
フロントエンド・UI 生成	まずシャドー実行	Google がここで 2 つの具体的な劣化を文書化、どちらも prompt レベルの対処あり
約 20:1 の文書処理・RAG	急がない	節約は 7.1% で、通常の 1 か月のノイズの範囲内

本当に問いたいのが、代わりに Gemini 3.5 Flash-Lite を使うべきかどうかなら、それは別の判断であり別の答えです。Gemini 3.6 Flash と 3.5 Flash-Lite の比較で扱っています。Flash-Lite は能力が 1 段低いティアであって、いま使っているモデルの新しいバージョンではないので、以下の数字はどれも当てはまりません。

実際に何が変わったか

Gemini 3.6 Flash は新しいモデル世代ではありません。model card は「Gemini 3.5 Flash 上に構築された」と述べており、同じベース上の post-training アップデートということになります。この 1 つの事実が、以下のほとんどを説明します。能力は横ばいに動き、一方で post-training とサービングが動かせるもの（速度と token 効率）が大きく動きました。

実務的な詳細を Google のモデル文書から示します。

model ID： gemini-3.6-flash。安定版が 1 つ、preview サフィックスも日付スタンプもないので、エイリアスの判断は不要です。
コンテキスト： 入力 1,048,576 token、出力 65,536 token で、変化なし。入力は text、image、video、audio、PDF、出力は text のみ。
既定の thinking レベル： medium。minimal、low、medium、high から選択可能。
価格： 入力は 100 万 token あたり $1.50 のまま。出力は $9.00 から $7.50 へ、16.67% の引き下げ。キャッシュ読み取りは 100 万あたり $0.15。batch と priority のティアは Google の料金ページを参照。

これらが、このページの判断に関わるフィールドです。完全な能力マトリクスと、新しい model ID に対する最初の動くリクエストについては、Gemini 3.6 Flash 接続ガイドを参照してください。

広まっているので、正しておく価値のある訂正が 1 つ。入力価格は上がっていません。 gemini-3.5-flash も gemini-3.6-flash も、入力 100 万 token あたり $1.50 です。値上げが隠れているという主張は、より前の Flash 世代の価格と比べたことから来ています。

あなたの請求はどうなるか

コストを下げるとされるものが 2 つあります。出力価格が 16.67% 低いことと、同じタスクで使う出力 token がより少ないと報告されていることです。掛け合わせると、出力側の支出は 30.8% 下がります。

この数字は本物です。それは同時に、このリリースの報道の多くが節約幅を過大に語る理由でもあります。入力価格は動いていません。だからトラフィックが入力寄りであるほど、その 30.8% のうち実際に得られる分は少なくなります。

出力の重い AI ワークロードが、入力の重いパイプラインより多く節約を得る理由を示す Gemini 3.6 Flash のワークロード別コスト比較

Gemini 3.6 Flash の節約は出力側に集中するため、本番のコストへの影響はワークロードの token 比率で決まります。

入力:出力	典型的なワークロード	3.5 Flash	3.6 Flash	変化
20:1	文書処理、RAG	$39.00	$36.23	7.1% 安い
5:1	一般的な質問応答	$16.50	$13.72	16.8% 安い
1:1	thinking を有効にしたマルチターン agent	$10.50	$7.72	26.4% 安い
1:3	推論の重い作業、長いコード生成	$28.50	$20.17	29.2% 安い

この表はこう読んでください。各行は 1 つのワークロードを、3.5 Flash での出力 100 万 token に正規化し、入力 token は記載の比率で設定し、standard ティアの価格で算出しています。新しいモデルでは出力 token が 17% 少なく、入力 token は同一であることを前提としています。

その 17% という前提は、表のすべてがそこに乗っているので、条件を明記する価値があります。この数字は Google が自ら計測したのではなく引用しており、出典は Artificial Analysis です。同じページに公表された絶対 token 数、5,900 万対 7,500 万を計算すると 21.3% になります。2 つの数字は公に整合されていません。私たちは全体を通じてより保守的な 17% を使ったので、この表は約束ではなく、範囲の下端として扱ってください。

もう 1 点。thinking token は出力レートで課金されます。 だから agent の行が最も動くのです。マルチターン agent では、thinking の予算は請求の端数ではなく、その大きな割合を占めます。

そこで実測したところ、表は楽観的だと分かりました。 私たちのタスクセットは、課金対象の出力 1.5 token あたり入力およそ 1 token で動き、表の 1:1 と 1:3 の行の間に位置します。そこでは表は 26〜29% の節約を予測します。実測では medium thinking レベルで 13.6%、high で 20.1% でした。

この差はすべて token 効率の前提にあります。medium では、新しいモデルは前世代より出力 token を 17% 少なくではなく 1.7% 多く課金しました。だから得られた節約のほとんどは、token 効率ではなく価格引き下げから来ています。high では削減が部分的に現れ、出力 token が 6.4% 少なくなりました。手法と完全な数字は次のセクションにあります。

つまり、表はベンダーの主張が示唆する計算として読み、私たちの数字は 1 つの実際のワークロードが実際に生んだものとして読んでください。 あなたの作業が、ベンチマークセットよりも私たちのものに似ているなら、低いほうの数字で計画してください。

知能は同じ、速度はおよそ 2 倍

Artificial Analysis はリリース前のアクセスを得ており、現在、完全な内訳を持つ唯一の独立系ソースです。彼らの数字は high thinking レベルで計測されています。

指標	3.6 Flash	3.5 Flash
Intelligence Index v4.1	50.1	50.2
Humanity's Last Exam（知識集約）	38.3%	40.2%
GPQA Diamond	92.8%	92.2%
SciCode	52.7%	53.1%
長文コンテキスト推論（AA-LCR）	69.7%	69.3%
出力速度	303.6 tok/s	165.4 tok/s
最初の token までの時間	11.54 s	20.22 s
1 問あたり平均時間	1.3 min	2.7 min
1 問あたり平均コスト	$0.50	$0.59

すべての行に 2 つの条件が付きます。第一に、これらは high thinking レベルで計測されており、API の既定は medium なので、既定の構成で動かすのは同じ実験ではありません。第二に、速度とレイテンシの数字は、同じ日にリリースされたモデルで取った 72 時間の中央値で、サンプル窓は 1 日未満であり、変動すると見込むべきです。

それを踏まえると、形ははっきりしており、これは劣化ではなくトレードオフです。Intelligence Index の 50.1 対 50.2 は誤差の範囲です。推論と長文コンテキストのスコアはわずかに上がりました。2 世代を直接比較できる唯一の知識集約型スコア、Humanity's Last Exam は 1.9 ポイント下がりました。一方で出力速度は 84% 上がり、1 問あたりの時間はおよそ半分になりました。

だから、このリリースに求めていたのがより賢いモデルなら、このアップグレードはあなたのために作られたものではなく、gemini-3.5-flashに留まってもその軸では何も損しません。求めていたのが、同じ品質の作業を半分の時間で、より低い単価で終えることなら、それはまさに出荷されたものです。

知識集約型の注意点は、余計な心配 1 つ分ではなく、余計なひと手間 1 つ分の価値があります。1 つのベンチマークでの 1.9 ポイントの動きは、自分の評価セットを確認する合図であって、このリリースを見送る理由ではありません。

thinking レベルは、モデルよりも請求を大きく動かす

上の公表された数字はすべて high thinking レベルのもので、API の既定は medium です。この差は購入判断を変えるほど大きいので、私たちはリリース当日に自分たちのテストを走らせました。

Gemini 3.6 Flash の thinking レベルは段階的により多くの推論 token を積み上げる一方、最終的な本番出力はコンパクトなまま

thinking レベルは、モデルの切り替えそのものよりも課金対象の出力を変え得るので、本番チームは明示的に設定して評価すべきです。

セットアップ： 9 つのタスクを 3 グループに分けました。請求書・ログ・商品 HTML からの構造化抽出、シミュレートされた tool に対する 3〜5 ステップのマルチターン tool 呼び出し、そしてバグ記述を実行可能なパッチにするコードの特定と修正です。入力は 1,000〜4,000 token の間なので、これは長文コンテキストの作業をカバーしません。各タスクは 8 つの「モデル + thinking レベル」構成それぞれに対して 3 回、合計 216 回の呼び出しを、provider を Google AI Studio に固定した OpenRouter 経由で直列に送りました。answer token と thinking token を別々に記録し、すべてゲートウェイ自身の課金ではなく Google の standard ティアの定価で算出しています。sampling parameter は何も設定していません。もう何もしないからです。

構成	answer token	thinking token	thinking の割合	1 パスあたりコスト	正解
3.6 Flash `minimal`	1,162	0	0%	$0.0158	9/9
3.6 Flash `low`	1,056	1,095	51%	$0.0232	9/9
3.6 Flash `medium`（既定）	1,080	5,944	85%	$0.0598	9/9
3.6 Flash `high`	1,092	6,679	86%	$0.0653	9/9
3.5 Flash `medium`	1,078	5,827	84%	$0.0692	9/9
3.5 Flash `high`	1,113	7,185	87%	$0.0818	9/9

3 つのことが際立ちます。

thinking token こそが請求です。 medium と high では、出力側で支払うもの全体の 84〜87% を占めます。answer の長さは表全体でほとんど動きません。どのモデルを選ぶかは、どのレベルを選ぶかよりもはるかにコストへの影響が小さいのです。

minimal は「あまり考えない」ではなく「考えない」です。 thinking token はきっかり 0 で返り、1 パスのコストは medium 既定より 73.6% 安く、スコアは同じ 9 分の 9 でした。レベルを一度も選んでいないために medium になっているなら、それはあなたに使える最大のコストレバーであり、しかもすでに動かしているモデルの上で効きます。

ここでは high は medium より 9.3% しか高くありません。 追加の予算が使われずに終わったからです。thinking は 5,944 token から 6,679 に増えただけでした。これはモデルについてではなく、これらのタスクについての事実です。 より難しい作業では、この差は広がります。

私たちの数字が、もう 1 つの独立実測と食い違うところ

aibenchy はリリース後に 22 の短いベンチマーク問題を走らせ、新しいモデルが medium で 29.4% 高く、high で 9.7% 安いと見出しました。私たちは両方のレベルで安く、それぞれ 13.6% と 20.1% でした。high の結果は方向が一致します。medium の結果は逆を指しており、その理由は 1 つの数字に見えます。彼らは新しいモデルの medium で thinking が 66.2% 多いと計測し、私たちは 2.0% 多いと計測しました。

彼らの結果が間違いだと言うつもりはありません。2 つのタスクセットが同じ問いに逆の答えを出しました。そしてそれこそ持ち帰る価値のある発見です。このモデルが token を節約するかどうかは、何の上で動かすかによるのであって、モデル単独によるのではありません。 Google 自身の「出力 token が 17% 少ない」は、thinking レベルもタスクセットも名指ししておらず、だからこそ、あるワークロードでは再現し、別のワークロードでは再現しないのです。

このテストが教えられないこと。 9 つのタスクは、品質でレベルを分けるほど難しくありませんでした。どの構成も 9 分の 9 でした。だからこれらの数字は、どのレベルで走らせるかについてコストに基づく推奨は支えますが、品質が落ち始める点は特定しません。 繰り返し実行もばらつきました。同じタスクの同一実行の間で thinking token は 6〜51% 動き、だからこそ上の数字は 3 回の平均です。品質の折れ点を見つけることを狙ったより難しいラウンドを別途走らせており、結果が出たらこのページを更新します。

実行に移せる部分は単純です。どのモデルを走らせるにせよ、thinking レベルを明示的に設定し、ベンチマークが公表されたレベルではなく、実際に走らせるレベルで価格を見積もってください。

Google が「新モデルのほうが劣る」と言う 2 点

Google はリリース投稿で 2 つの具体的な弱点を公表しており、どちらも同じ場所に集中しています。

編集する前に探索します。 このモデルは 3.5 Flash よりも、コードを変える前に診断の一巡を走らせる傾向が強いです。複雑なタスクではそれが精度を上げます。単純なフロントエンドのタスクでは、必要でも、払いたくもなかった余計な探索ステップを生みます。

人間の評価者は旧モデルのビジュアル出力を好みました。 とくに視覚的なレイアウトとスタイリングで、評価者は以前のモデルを支持しました。Google が示す緩和策は、スタイリングをモデルの既定に委ねるのではなく、デザインのルールを prompt に書き込むことです。

model card はまた、既知の制限として hallucination と、まれに遅い応答や timeout を挙げています。

どれもアップグレードに反対する論拠ではありません。それは、判断を面ごとに分けることを支持する論拠です。agent 層と UI 生成層があるなら、それらは証拠の異なる別々のワークロードであり、同じ model ID を使わなければならないという決まりはありません。

切り替えはモデル文字列の変更では済まない

ここはチームが足をすくわれる部分で、当日出た「モデル名を変えるだけ」という推奨がいまや誤りである理由です。このリリースを起点に、そしてそれ以降のすべてのモデルについて明示的に、いくつかのパラメータの挙動が変わりました。 完全な一覧は Google の API changelog にあります。本番を静かに壊すのは、以下のものです。

temperature、top_p、top_k は無視され、エラーは出ません。 Google の文書は将来のモデル世代が HTTP 400 を返すと述べていますが、今日これらの値は単に破棄されます。抽出や分類のパイプラインを決定的に保つために temperature=0 に頼っているなら、その保証は、ログ 1 行も、例外も、アラートもなく消えます。 代替の手法は、そのルールを system instruction に置くことです。

これには確認する価値のある二次的なバージョンがあります。OpenRouter のモデルメタデータは、temperature、top_p、seed をいまだに対応パラメータとして列挙しているので、ゲートウェイはあなたの値を受け付けて転送し、モデルはそれを無視します。出力品質を上げようと今日 temperature を調整している人は、no-op を調整しています。

thinking_budget は thinking_level に置き換えられます。 古い数値の予算は文字列 enum になります。1 つのリクエストで両方を送ると 400 が返ります。

より小さいものが 3 つ。 candidate_count は Gemini 3.x では非対応です。最後のメッセージが model ロールを持つリクエストは今や 400 を返し、これにより応答の prefill ができなくなります。そしてすべての FunctionResponse は今や call_id と name の両方を持たなければなりません。

1 行ずつのバージョンは、Google 自身の自動移行ツールや、これが置き換えるモデルの廃止スケジュールも含めて、Gemini 3.6 Flash 移行ガイドを参照してください。

自分で検索する場合の注意が 1 つ。以前の Gemini アップグレード向けに書かれたガイドは、私たち自身の Gemini 3 Flash Preview から Gemini 3.5 Flash への移行を含め、いまだに sampling parameter を使えるものとして記述しています。そのモデルペアでは実際に使えたからです。上記の廃止は、この世代から始まります。

2 つを並べてテストすることについての実務的なメモ。両方の model ID が EvoLink 上の 1 つの OpenAI 互換エンドポイントで公開されているので、base_url を単一のゲートウェイに向け、モデル文字列を切り替えるだけで、2 つ目の統合を先に立ち上げることなく、自分の prompt で A/B できます。これは、上記の知識集約型と UI の問いを自分のトラフィックで答える、最も安上がりな方法です。

スイッチを入れる前に

公表された数字は問いを狭めます。4 つの計測がそれを閉じます。

answer token と thinking token を別々に記録します。 合計 token の指標では、請求がなぜ動いたかは分かりません。これらのモデル間で挙動が異なるのは、2 つの構成要素のうち 1 つだけだからです。
thinking レベルを明示的に固定します。 うっかり medium を引き継がず、公表ベンチマークが使った high ではなく、実際に走らせるレベルで価格を見積もってください。私たちのタスクセットでは、これはモデルの変更よりも価値がありました。 minimal は同じ精度で medium 既定より 73.6% 安かったのです。同じだと決めつける前に、自分の作業がそれに耐えるかを確認してください。
ベンチマークセットではなく、実際の prompt の組み合わせをシャドー実行します。 これが最も重要なのは、トラフィックが知識集約型の場合です。そこは、比較可能なスコアが下がった唯一の軸だからです。
切り替える前に grep します。 コードベースを temperature、top_p、top_k、thinking_budget、candidate_count で検索してください。最初の 3 つは静かに失敗するので、テストは通り、出力はドリフトします。

FAQ

Gemini 3.6 Flash は改名された Gemini 3.5 Pro ですか？ その憶測はリリース後に広まりました。最も多く支持されたコミュニティの回答はそれを否定し、Pro が改名されたという兆候はなく、これは Flash のアップグレードだと論じました。model card はその読み方を支持します。モデルは Gemini 3.5 Flash 上に構築されたと述べているからです。私たちはこの憶測を記録しますが、支持はしません。

gemini-3.5-flash は停止されますか？ Google が発表した廃止日は、gemini-2.5-flash と gemini-2.5-flash-lite が 2026-10-16、gemini-3.1-flash-lite が 2027-05-07 です。2026-07-21 にリリースされたモデルには、廃止日は発表されていません。この判断を迫る公表された期限はないので、時間をかけて計測できます。

入力価格は上がりましたか？ いいえ。両モデルとも standard ティアで入力 100 万 token あたり $1.50 です。変わったのは出力価格だけで、$9.00 から $7.50 へ。

決定的な出力のために temperature=0 を使い続けられますか？ いいえ。そしてこれが注視すべき失敗モードです。パラメータは受け付けられ、エラーなく無視されます。制約を system instruction に移し、リクエストではなく出力を検証してください。

3.6 Flash は RAG にとって意味のあるほど安いですか？ 出力 1 token あたり入力およそ 20 token では、公表された数字は 7.1% の節約を示唆します。本物ですが小さいです。請求の入力側が変わっていないからです。それは見積もりではなく上限として扱ってください。 私たち自身のタスクでは、実効の節約は同じ計算が予測した値を下回り、しかもテストは長文コンテキストの検索をまったくカバーしていません。RAG チームは、このリリースをまずレイテンシの改善、次にコストの改善として扱うべきです。

どの model ID を使うべきですか？ gemini-3.6-flash。安定版が 1 つあり、preview サフィックスも、選ぶべき日付付きのバリアントもありません。