Gemini 3.6 Flash：コストを 30 倍動かす思考ダイヤル（実測）

Gemini 3.6 Flash は、回答に加えて thinking token にも課金する。しかも消費する量はリクエストごとに調整できるダイヤルだ。同じ 120 語のライティングタスクで、デフォルト設定は $0.03316、minimal 設定は $0.00110 を請求した。読者には見分けのつかない出力に対して 30 倍の差が出る。このダイヤルはこのモデルで最も重要なコスト判断であり、鋭い落とし穴がひとつ付いてくる。Gemini 3.6 Flash は 2026-07-21 に一般提供が始まった。価格は入力 100 万 token あたり $1.50、出力 100 万 token あたり $7.50 で、3.5 Flash の出力 $9 から下がっている。同時に Gemini 3.5 Flash-Lite とセキュリティ調整済みの 3.5 Flash Cyber もリリースされた。この記事では汎用の 2 ティア、3.6 Flash と Flash-Lite を測定する。

TL;DR

• reasoning_effort: "minimal" はデフォルトと比べて呼び出しあたりのコストを 91〜97% 削減する（120 語タスクで 30 倍の差）。単一ステップ、構造化出力、tool-calling の作業では無料同然だが、複数ステップの数学は 3/3 → 0/3 と壊れる。
• Google の「出力 token が 17% 減る」というのはワークロード依存だ。reasoning が重いタスクでは 19% 軽く（32% 安く）なったが、agent スイートでは 9% 重く（6% 安く）なった。
• 1M コンテキストは本物で（972K token に置いた針を再現）、prompt caching は Google が公表する 4,096 token の下限とぴったり一致する。宣伝する「1M コンテキスト」に届かないモデルもある中で、スペック通りのきれいな一致だ。

以下はすべて 2026-07-24 に Synthorai ゲートウェイ経由で測定した。繰り返すプロンプトはキャッシュを無効化するために salt を付けている。すべての数値は生の usage レコードが裏付けている。

デフォルト設定で Gemini 3.6 Flash はタスクごとにいくらかかるか

出力の請求額は reasoning が支配的で、しかも見えるかどうかに関係なく課金される。デフォルトの effort では、モデルは回答よりはるかに多くの token を思考に使い、その reasoning token は出力レートの $7.50/M がそのまま適用される。

押さえておくべきパターンはこうだ。2 token の事実回答にも 69 token の reasoning が付き、120 語の段落は書く量の 30 倍の token を思考に使った。reasoning token は completion_tokens_details.reasoning_tokens に項目化されているので、数は見えるが中身はまったく見えない。Gemini は thinking の要約もトレースも一切返さない。token 使用量の解剖 の調査でマッピングしたスペクトルの中で最も閉じた端にあたる。同じ調査では Kimi K3 は思考の連鎖を丸ごと返し、GPT-5.6 は要約を返した。次のセクションでは、この消費量を下げる話をする。

thinking ダイヤルは実際に何をするのか

これは正真正銘の、単調に効くコストレバーであり，ほとんどのタスクではほぼタダで得をする。reasoning_effort（またはネイティブの thinking_config.thinking_level）を minimal に設定すると、reasoning token がゼロになり，タスクあたりのコストが 91〜97% 削減された：

ダイヤルは実在し，受け付ける値は minimal，low，medium（デフォルト），high の 4 つだ。計測では各段階を上げるごとに reasoning が単調に増えた（minimal は 0 token，low は約 180，medium は約 530，high は約 650）。minimal にできないことがひとつだけある。考えることだ。そして複数ステップの計算はそれを必要とする。鉛筆と袋の文章題を短く答えるよう強制すると，モデルは 3 回とも間違えた。しかも 1 つの体系的なミスではなく，バラバラの誤答だった。検索、分類、フォーマット、単一ステップの質問では，minimal は精度を保ったまま費用を 1 桁削った。

実用的なルールは Kimi K3 で見つけたものと同じだ。抽出、ルックアップ、フォーマットには minimal が正当なデフォルトになるが，中間ステップが必要なものには地雷になる。グローバルではなくルートごとに設定し，reasoning 重めのタスクに投入する前に，自分のタスクで精度を検証すること。

高トラフィックな本番形態を 2 つ挙げると話が具体的になる。structured output と function calling はどちらもデフォルトでは reasoning を消費するが，どちらも minimal で安全に動かせる。スキーマ制約付きの抽出（JSON スキーマ付きの response_format）は，デフォルトでは 337 reasoning token を計上して有効な JSON を返した。minimal では reasoning がゼロになり，それでもスキーマに準拠した有効な JSON を返し，コストは 9 分の 1 になった。function call も同じ挙動だった。デフォルトでは 74 reasoning token を使って正しい get_weather(city) 呼び出しを行い，minimal では reasoning ゼロで同じ正しい呼び出しを行い，コストは 4 分の 1 になった。これらは「structured」の体裁をまとった単一ステップのタスクであり，モデルは埋めるよう指示されたフィールドにたどり着くのに考える必要はない。だからトラフィックが抽出やツールルーティングなら，minimal はほぼタダで得をする。

「出力トークン17%削減」という主張は本当か？

ワークロードによる。そして、その内訳が示唆に富む。Google はローンチ時、3.6 Flash は Artificial Analysis Index で 3.5 Flash より出力トークンを約 17% 削減する（個別の agentic 評価では最大 65%）と位置づけた。我々は両モデルを自前のテストベッド 2 つに通したところ、正負が逆になる結果が出た。

reasoning 中心の短いタスクでは、主張が再現しただけでなく謳い文句を上回った。出力全体は 19% 減り、Google の 17% に近い。しかもその削減はほぼすべて thinking から来ており、回答部分ではなかった。両モデルをペアで再実行して出力トークンを分解すると、目に見える回答は 4% しか縮まなかったのに対し、reasoning は 19% 減った。削減は数学と文章生成のタスクに集中していて、3.6 はより少ない検討で同じ結果に到達している。これがベンチマークの裏側にある仕組みだ。thinking budget に依存する作業では、3.6 は同じ回答をより効率的に出す。

agentic なマルチターンのトラフィックでは符号が反転する。スイート全体で、3.6 は 3.5 より出力を約 9% 多く消費した。効率の改善は reasoning フェーズにあるが、エージェントループは budget に占める reasoning の割合が相対的に低いため、削れる余地が少なく、3.6 のわずかに長いターンが上回ってしまう。それでもどちらも請求額は下がる。2 つの効果の積み上がり方が違うからだ。reasoning 中心のタスクはトークン削減と $9→$7.50 のレート引き下げの両方で得をする（−32%）。エージェントトラフィックは価格の分だけ得をする（−6%）。率直にまとめると、「出力トークン17%削減」は thinking が出力を支配する場合は本物で、そうでない場合は逆転する。謳い文句を鵜呑みにせず、自分のミックスで測ること。そして前節で触れたダイヤルの方が、バージョンアップよりはるかに大きく効くことを覚えておくといい。

1M のコンテキストウィンドウは本物か？

本物だ。しかも黙って壊れるのではなく、はっきりと失敗する。サイズを増やしていくプロンプトの先頭に recall 用の針を置いたところ、入力 972K トークンでも正しくリコールされた。上限を超えたプロンプトは、内容を黙って切り捨てるのではなく、きれいに 400 input token count exceeds the maximum を返した。これはあえて明言しておく価値がある。市場に出回っている「1M コンテキスト」モデルのすべてが、広告どおりのウィンドウを実際に提供しているわけではないからだ。これを再現する人へのテスト上の注意が 1 つ。padding には多様で文の形をした filler を使うこと。単一のトークンを繰り返して作ったプロンプトは、サイズ上限のかなり手前でモデルを退化した意味不明の出力に追い込んだ。

Prompt caching は自動で、肝心の数字は仕様どおりだ。Google は Flash モデルの context caching に 4,096 トークンの最小値を文書化しており、我々の sweep はまさにそこに着地した。約 2.1K 以下の prefix は決してキャッシュされず、ヒットは約 4.1K トークンから始まり、各ヒットは 5〜8 回の呼び出しのウォームアップの後、末尾のおよそ 2.1K を未キャッシュのまま残した。キャッシュ済み入力は $0.15/M で読め、新規レート $1.50 の 10 倍割引になる。これははっきり述べておく価値がある。安心できるケースだからだ。我々が測ってきた一部のモデルは、広告している数字がエンドポイントの実際の挙動を上回っていたが、Gemini 3.6 Flash のキャッシュの下限も 1M ウィンドウも、どちらもドキュメントどおりに動く。ただしキャッシングが割に合うのは、本当に長く安定した prefix の場合だけだ。それと、Flash 層は自動（暗黙的）キャッシングのみをサポートし、明示的な cached-content API はサポートしていない点に注意。大きなドキュメントを手動でピン留めして下限以下で再利用することはできない。

Gemini 3.5 Flash-Lite の位置づけ

Flash-Lite はコストが読めるティアだ。reasoning token を裏で消費することがないので，請求額は見えている出力とそのまま一致する。同じマルチステップの数学問題で， Flash-Lite は $0.00057 だったのに対し， 3.6 Flash はデフォルトで $0.00368，およそ 6 倍安い。しかも答えを隠れた reasoning フィールドではなく，見える形で導き出している。input $0.30/M・output $2.50/M という価格なので，大量処理でレイテンシに敏感なシングルステップの作業ではこれをデフォルトにするのが正しい。ダイヤルで reasoning を足し戻す必要があるタスクなら 3.6 Flash に上げればいい。tokenizer は新しい 3 モデル間で変わらないだけでなく， Gemini 2.5 Flash まで遡っても同じだ。英語・中国語・日本語・韓国語・Python のいずれでも，検証したすべての世代で token 数は一致した。つまり 2.5 向けに組んだ言語別の予算は，再測定なしでそのまま 3.6 に持ち込める。

FAQ

Gemini 3.6 Flash で reasoning を完全にオフにできる？

reasoning_effort: "minimal"（または thinking_level: "minimal"）を指定すると，我々のテストでは reasoning token がゼロになった。これがダイヤルの下限だ。受け付けられる段階は minimal，low，medium，high の 4 つ。独立した「無効化」状態は存在せず，reasoning を強制的に無効にしようとする指定は上流で拒否される。したがって minimal が最も低い設定であり，シングルステップのタスクにはそれで十分低い。

Gemini の請求額が，見えている答えから想像するより高いのはなぜ？

reasoning token が出力と同じレートで課金される一方で，返ってくるテキストには含まれないからだ。2 token の答えに，数十から数千の課金対象 reasoning token が乗っていることもある。実際の出力課金を確認するには completion_tokens_details.reasoning_tokens を読むか，total_tokens − prompt − completion を突き合わせる。そしてタスクが許すならダイヤルを下げる。

Gemini 3.6 Flash と Claude Haiku 4.5，どちらを選ぶ？

両者は同じ高速ティアの枠を似た価格で占めており，どちらか一方が勝つというより，ワークロードで使い分ける話だ。コストの観点では 3.6 Flash の thinking ダイヤルが差別化要因になる。minimal にすればシングルステップのトラフィックでは桁違いに安くなる。一方でデフォルトでは， $1/$5 の Haiku 4.5 が消費しない reasoning を使う。公開ベンチマークでは，コーディングの深さで Haiku 4.5 が上，数学と素の token 価格で 3.6 Flash が上だ。自分のトラフィックがどちらでできているかで選び，決める前に両方を自分のタスクで測ること。

Gemini 3.6 Flash は 3.5 Flash より安い？

我々が測定したすべてのワークロードで安かった。ただしどれだけ安いかは中身の形による。output は $9/M から $7.50/M に下がった。reasoning の多い短いタスクでは 3.6 は消費 output token も少なく，コストは約 32% 下がった。エージェント系のトラフィックでは token をわずかに多く消費し，節約分はレート引き下げだけによる約 6% だった。いずれにせよ安い。移行して自分のミックスで測り直せばいい。ファミリー横断の token あたりコスト分解については， token usage anatomy の調査を参照。

測定は 2026-07-24，Synthorai ゲートウェイ経由の gemini-3.6-flash，gemini-3.5-flash，gemini-3.5-flash-lite。タスクマトリクスとエージェントスイートの token 数は呼び出しごとの usage レコードから，effort ダイヤルの結果は salt を加えた 5 タスクの ablation（セルあたり n=3）から，コンテキストとキャッシュの検証は needle-recall と prefix sweep から取得した。精度カウントには，チェック可能な答えが 1 つに定まるタスクを使用。価格と挙動は変わる可能性がある。自分の usage レコードで確認すること。

← ブログに戻る