Gemini 3.6 Flash：コストが 30 倍変わる思考ダイヤルを実測

Gemini 3.6 Flash では、回答とは別に思考 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 もリリースされた。本記事では、汎用モデルである 3.6 Flash と Flash-Lite の 2 階層を実測する。

TL;DR

• reasoning_effort: "minimal" にすると、1 回あたりのコストはデフォルト比で 91〜97% 下がった。120 語のタスクでは 30 倍の差が出た。単一ステップ、構造化出力、tool calling では精度を維持したが、複数ステップの計算問題は 3/3 → 0/3 に悪化した。
• Google が掲げる「出力 token が 17% 少ない」という効果は、ワークロードによって変わる。reasoning の比率が高いタスクでは token が 19% 減り、コストは 32% 下がった。一方、agent スイートでは token が 9% 増えたが、コストは 6% 下がった。
• 1M のコンテキストウィンドウは実際に使える。972K token の位置に置いた needle も正しく取得できた。prompt cache も Google 公称の下限 4,096 token と完全に一致した。仕様どおりの結果であり、「1M コンテキスト」を掲げながら実際には届かないモデルとは異なる。

以下の数値はすべて、2026-07-24 に Synthorai gateway 経由で計測した。キャッシュを回避するため、繰り返す prompt には毎回 salt を加えている。各数値は生の usage record で確認できる。

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

出力料金の大半は reasoning が占め、内容が見えなくても課金される。デフォルトの effort では、回答より思考に多くの token を使う。この reasoning token には、出力と同じ $7.50/M の単価が適用される。

押さえるべき傾向は明確だ。事実を 2 token で答えるだけでも、reasoning に 69 token が使われた。120 語の段落では、文章を書くときの 30 倍の token を思考に費やしている。reasoning token 数は completion_tokens_details.reasoning_tokens に記録されるため、量は確認できるが内容は見られない。Gemini は思考の要約も trace も一切返さない。token 使用量の内訳 で調べたモデルの中でも、最も閉じた部類に入る。Kimi K3 は chain of thought をすべて返し、GPT-5.6 は要約を返す。次のセクションでは、このコストを抑える方法を扱う。

思考ダイヤルは実際に何を変えるのか？

思考ダイヤルは、コストを確実かつ単調に変える。ほとんどのタスクでは、ほぼ無条件にコストを削減できる。reasoning_effort、またはネイティブの thinking_config.thinking_level を minimal にすると、reasoning token は 0 になり、タスクごとのコストは 91〜97% 下がった。

指定できる値は minimal、low、medium（デフォルト）、high で、実測でも段階を上げるたびに reasoning token が単調に増えた。minimal は 0 token、low は約 180、medium は約 530、high は約 650 だった。minimal では思考できないため、複数ステップの計算には対応できない。鉛筆と袋を扱う文章問題に簡潔な回答を強制すると、3 回すべて不正解だった。同じ間違いを繰り返したのではなく、回答はばらついていた。一方、検索、分類、整形、単一ステップの質問では精度を維持し、料金を 10 分の 1 前後まで下げた。

実運用上のルールは、Kimi K3 での検証結果と同じだ。抽出、検索、整形なら minimal をデフォルトにしてもよい。中間ステップが必要な処理では危険な設定になる。グローバルに固定せず、route ごとに設定するべきだ。reasoning が多いタスクへ投入する前に、自社のタスクで精度を検証する必要がある。

本番でリクエスト数が多い代表例として、構造化出力と function calling がある。どちらもデフォルトでは reasoning token を消費するが、minimal でも問題なく動作した。JSON schema を使ったスキーマ制約付き抽出では、デフォルトで reasoning token が 337 課金され、有効な JSON が返った。minimal では reasoning が 0 になったが、引き続き schema に準拠した有効な JSON が返り、コストは 9 分の 1 だった。function call も同様だ。デフォルトでは reasoning token が 74 で、正しい get_weather(city) call が返った。minimal では reasoning が 0 になり、同じ正しい call が返り、コストは 4 分の 1 だった。これらは「構造化」されているだけの単一ステップタスクだ。指定された field を埋めるために、モデルが思考する必要はない。トラフィックの中心が抽出や tool routing なら、minimal にするだけでほぼ無条件にコストを削減できる。

「出力 token が 17% 少ない」という主張は再現するのか？

結果はワークロードによって変わり、その違いから理由も見えてくる。Google は 3.6 Flash の発表時に、Artificial Analysis Index で 3.5 Flash より出力 token が約 17% 少ないと説明していた。個別の agentic 評価では最大 65% とされている。両モデルを独自の 2 つのテスト環境で比較したところ、結果の方向は逆になった。

reasoning 比率が高い短いタスクでは、公称値を再現しただけでなく上回った。出力 token の合計は 19% 減り、Google の 17% に近い。減ったのは回答ではなく、ほぼ reasoning だった。両モデルを同じ条件で再実行し、出力 token を分けて確認すると、見える回答は 4% しか短くなっていない一方、reasoning は 19% 減っていた。特に数学と文章生成で差が大きく、3.6 は同じ結果に少ない思考量で到達している。これが benchmark の差を生む仕組みだ。思考予算を多く使う処理では、3.6 のほうが同じ回答を効率よく生成できる。

agentic なマルチターントラフィックでは逆転し、スイート全体で 3.6 の出力 token は 3.5 より約 9% 多かった。効率化されているのは reasoning フェーズだが、agent loop では予算に占める reasoning の割合が小さい。削減できる余地が少なく、3.6 のやや長い turn が上回った。それでも料金は下がる。2 つの効果の組み合わせが異なるためだ。reasoning 比率が高いタスクでは、token 数の削減と $9→$7.50 への値下げが重なり、コストは 32% 下がった。agent トラフィックでは、値下げだけで 6% 下がった。「出力 token が 17% 少ない」という主張は、出力の大半を思考が占める場合には再現するが、そうでなければ逆転する。公称値をそのまま当てはめず、自社のワークロード構成で計測するべきだ。前のセクションで扱った思考ダイヤルは、バージョン更新よりもはるかに大きくコストを動かす。

1M のコンテキストウィンドウは本当に使えるのか？

使えるうえ、上限超過時も明確に失敗する。サイズを段階的に増やした prompt の先頭に recall 用の needle を置いたところ、入力 972K token でも正しく取得できた。上限を超える prompt では、内容を黙って切り捨てるのではなく、明確な 400 input token count exceeds the maximum が返った。市場にあるすべての「1M コンテキスト」モデルが、公称どおりのウィンドウを実際に提供しているわけではないため、この違いは大きい。再現する場合は、文として自然で内容にばらつきのある filler を使う必要がある。同じ token の繰り返しだけで prompt を埋めると、サイズ上限よりかなり前からモデルの出力が意味のない文字列へ崩れた。

prompt cache は自動で動作し、重要な数値も仕様どおりだった。Google は Flash モデルの context caching について、最小 4,096 token と明記している。実測結果も正確に一致した。約 2.1K token 以下の prefix は一度も cache されず、約 4.1K token から hit が始まった。5〜8 回の warm-up 後に hit すると、末尾の約 2.1K token だけが cache 対象外として残った。cache 済み入力の読み取り単価は $0.15/M で、新規入力の $1.50 に対して 10 分の 1 となる。公称値が実際の endpoint より大きいモデルもあるが、Gemini 3.6 Flash は cache の下限も 1M ウィンドウもドキュメントどおりに動作した。ただし、cache の効果が出るのは、実際に長く安定した prefix がある場合だけだ。また、Flash 系で利用できるのは自動の implicit caching のみで、明示的な cached-content API には対応していない。そのため、大きなドキュメントを手動で固定し、下限未満で再利用することはできない。

Gemini 3.5 Flash-Lite はどこに位置付けられるのか？

Flash-Lite はコストを予測しやすい tier だ。reasoning token を裏で消費しないため、料金は見える出力にそのまま比例する。同じ複数ステップの計算問題で、Flash-Lite は $0.00057、3.6 Flash のデフォルトは $0.00368 だった。Flash-Lite は約 6 分の 1 のコストで、隠れた reasoning field ではなく、回答内で計算過程を示した。入力 $0.30/M、出力 $2.50/M なので、大量リクエスト、低 latency、単一ステップの処理には最初に選ぶべきモデルだ。タスクに reasoning が必要なら、ダイヤルで思考量を増やせる 3.6 Flash を使う。tokenizer は 3 つの新モデル間だけでなく、Gemini 2.5 Flash から変わっていない。英語、中国語、日本語、韓国語、Python のすべてで、確認した全世代の token 数が完全に一致した。2.5 向けに作った言語別の予算は、baseline を取り直さずに 3.6 でも使える。

FAQ

Gemini 3.6 Flash の reasoning は完全に無効化できるか？

検証では、reasoning_effort: "minimal"、または thinking_level: "minimal" にすると reasoning token は 0 になった。これがダイヤルの下限で、指定できる段階は minimal、low、medium、high だ。独立した「disabled」状態はなく、reasoning を強制的に無効化しようとすると upstream で拒否される。そのため、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 のどちらを選ぶべきか？

どちらも同程度の価格帯にある高速 tier で、単一の勝者がいるわけではない。選択はワークロードによって決まる。コスト面では、3.6 Flash の思考ダイヤルが大きな違いになる。minimal なら単一ステップのトラフィックでコストを 10 分の 1 前後にできる。一方、デフォルトでは reasoning token を消費するが、$1/$5 の Haiku 4.5 にはそのコストがない。公開 benchmark では、coding の深さは Haiku 4.5、数学と token 単価は 3.6 Flash が優位だ。自社トラフィックの内容に合わせて選び、採用前に両方を実際のタスクで計測する必要がある。

Gemini 3.6 Flash は 3.5 Flash より安いか？

計測したすべてのワークロードで安かったが、削減幅は処理の種類によって変わる。出力単価は $9/M から $7.50/M に下がった。reasoning 比率が高い短いタスクでは、3.6 の出力 token も減ったため、コストは約 32% 下がった。agent トラフィックでは token 数がわずかに増え、値下げ分だけで約 6% 安くなった。どちらの場合も 3.6 のほうが安い。移行後は、自社のワークロード構成で再計測するべきだ。モデル系列ごとの token 単価の内訳は、token 使用量の内訳 を参照してほしい。

2026-07-24 に Synthorai gateway 経由で gemini-3.6-flash、gemini-3.5-flash、gemini-3.5-flash-lite を計測。タスクマトリクスと agent スイートの token 数はリクエストごとの usage record、effort ダイヤルの結果は salt を加えた 5 タスクの ablation（各セル n=3）、コンテキストと cache は needle recall と prefix sweep に基づく。精度は、正解を一意に検証できるタスクのみ集計した。料金と挙動は変更される可能性があるため、自社の usage record で確認してほしい。

← ブログに戻る