Gemini 3.7 Flash API の実測コスト：3.6 より 2.5〜8 倍安い

この記事は Synthorai ブログの記事 Gemini 3.7 Flash API の実測コスト：3.6 より 2.5〜8 倍安い の転載です。原文（多言語対応）はリンク先をご覧ください。

Gemini 3.7 Flash は、同じタスクでも Gemini 3.6 Flash の 2.5〜8 分の 1 の料金で済みます。公表された値下げで説明できるのは、そのうち半分だけです。導入価格は入力 100 万 token あたり $0.75、出力 100 万 token あたり $3.75 で、3.6 より 50％安く設定されています。実測でも、同じ 6.9K-token の prompt に対する課金額はちょうど半分でした（$0.00529 と $0.01057）。もう半分の要因は、あまり表に出ていません。gemini-3.7-flash は、同じ 4 タスクで 3.6 より thinking token を 26〜77％少なく消費しました。リリース 2 日目に、料金条件、thinking の調整機能（1 つは廃止）、Google のドキュメントにある互換性上の変更点と説明が不十分な変更点、さらに cache、context、tokenizer の互換性を検証しました。

TL;DR

• 導入価格は $0.75/$3.75 で、2026 年 12 月 31 日まで適用されます。その後は $1.50/$7.50 です。実測では、同じ prompt の課金額が 3.6 のちょうど半分でした。
• デフォルトの thinking は 3.6 比で 26〜77％減りました（5-step タスクで 144 token と 384 token）。タスク単位の料金は 2 分の 1 ではなく、2.5〜8 分の 1 です。
• 無効化できなくなりました。どの off 指定も 400（「Thinking level is unsupported」）を返します。現在の下限は low です。
• 2-turn の tool loop では、tool result を処理する turn で 3.7 の思考量が 3.6 の約半分でした（32 token と 61 token）。回答不能な質問を拒否する処理は、両モデルとも約 500 token を消費しました。

Gemini 3.7 Flash の実際の料金は？

2026 年 12 月 31 日までは 3.6 の半額です。さらに、今回測定したすべてのタスクで、消費 token 数も 3.6 の半分未満でした。Google が発表したローンチ価格は、入力 100 万 token あたり $0.75、出力 100 万 token あたり $3.75 です。2027 年 1 月 1 日以降は $1.50/$7.50 に戻り、3.6 と同額になります。cache read は 100 万 token あたり $0.075 で、導入価格の入力単価の 10％です。実測値も料金表どおりでした。同じ 6.9K-token の prompt は、3.7 で $0.0052875、3.6 で $0.0105675 となり、きれいに半額です。

より大きいのは、モデルが消費しなくなった token です。同一条件のタスクに salt を加えて各 3 回実行し、reasoning token の中央値と出力料金を比較しました。

タスク	3.7 reasoning token	3.6 reasoning token	3.7 出力料金	3.6 出力料金	タスク料金比
単純な検索	73	98	$0.0003	$0.0008	2.7 分の 1
2-hop の文章題	62	266	$0.0002	$0.0020	8.4 分の 1
5-step の算術	144	384	$0.0006	$0.0029	5.3 分の 1
JSON 抽出	251	340	$0.0011	$0.0027	2.5 分の 1

Google は 3.7 について「より入念に考える」と説明しています。今回のタスクでは、入念さは token の増加ではなく減少として現れました。正答率は両モデルとも全項目で 3/3 です。半額の単価と半分以下の thinking を合わせると、cache を使わなくても、実運用でのタスク単位の料金は 61〜88％下がります。ただし、この差は期間限定です。予算は 1 月 1 日の価格改定を前提に組む必要があります。Sonnet 5 の導入価格と同じパターンです。

この傾向に当てはまらないタスクが 1 つあります。しかも、通常は予算に入れにくい「回答拒否」です。架空の 5 つの対象（企業、研究機関、町の憲章、合金、賞）について質問したところ、両モデルとも 5 件すべてで回答を拒否しました。その際の thinking は、今回測定したどのタスクよりも多く、reasoning token の中央値は 3.7 が 511、3.6 が 494 でした。「その記録は存在しない」と答えるだけで、5-step の算術問題を解く場合の 3.5 倍の thinking を消費します。欠損データに頻繁に当たる RAG pipeline では、miss のたびにこのコストが発生します。ここだけは 3.7 の効率改善が消えます。一方で、ローンチ直後に出ていた懸念を検証する材料にもなりました。レビューでは 3.7 の hallucination 率が高いと指摘されていましたが、架空の対象に関する質問では 5 件中 5 件で断定を避け、3.6 と同じ結果でした。

3.7 で使える thinking control は？

使えるのは、ドキュメントどおり low、medium（デフォルト）、high の 3 段階です。off はありません。ドキュメントに明記されていないのは、3.6 で使えた無効化手段がすべて廃止された点です。reasoning_effort: "none"、"minimal"、thinking_budget: 0、thinking: {"type": "disabled"}、enable_thinking: false のどれを送っても、upstream から同じ 400 が返りました。「Thinking level is unsupported: THINKING_LEVEL_MINIMAL」です。別の独立した request path では、さらに明確に「Reasoning is mandatory for this endpoint and cannot be disabled」と返ります。特定 client の変換層ではなく、モデル側の制約です。同じ batch で測定した 3.6-flash では、none と minimal を指定すれば引き続き消費量をゼロにできます。Flash 系も pro tier の方針と同じになりました。thinking は無効化できず、無効化できる最後の Flash は 3.6 です。

有効な調整値を 5-step タスクで比較しました（各 3 回の中央値、すべて 3/3 正解）。

設定	3.7 reasoning token	3.6 reasoning token
low	133	138
medium（デフォルト）	147	284
high	291	409

実装上の注意点は 2 つです。まず、デフォルトが medium という説明は実測でも確認できました。設定なしでは 154 token、明示的に medium を指定した場合は 147 token で、差はほぼありません。次に、thinking_budget は実質的に廃止されています。送信した 16〜1,024 の非ゼロ値はすべて受け付けられましたが、消費量はどれも 135〜138 token でした。指定しても何も変わりません。3.6 では、小さい budget は off、大きい budget は上限値としてまだ機能します。3.6 の integration で budget によりコストを制御している場合、3.7 では level を 1 つ選ぶだけです。それ以外の調整手段はありません。vendor ごとの調整機能が実際に効くかどうかは、thinking-control の比較表を参照してください。

agent を 1 step 動かすコストは？

tool の選択挙動は 3.6 と同じです。安くなったのは、step 間の判断に使う token です。2 つの function（incident の検索と、その結果に含まれる service の再起動）を使う 2-turn の loop を、各モデルで 3 回ずつ実行しました。

loop の step	3.7 reasoning／出力 token	3.6 reasoning／出力 token
Turn 1：tool を選択	85／110	85／110
Turn 2：tool result に基づいて実行	32／58	61／87

両モデルとも、最初に get_incident、次に restart_service を 3/3 で選び、prompt token 数も同一でした。差が出たのは 2 turn 目です。3.7 は次の call を決めるまでの thinking が約半分です。agent が繰り返すのはこの処理です。この中央値で 20-step の loop を回すと、出力料金は 3.7 で約 $0.0043、3.6 で $0.0131 になります。この差は単価ではなく token 数によるものなので、1 月の価格改定後も比率は変わりません。Google がagent benchmark の向上をコスト面の利点として説明する根拠はここにあります。hop ごとの判断に使う token が減り、それが多数の hop に積み上がります。

競合モデルとの優劣は benchmark によって変わるため、coding agent を切り替える前に確認が必要です。独立系の比較記事では、3.7 Flash は FrontierCode で Sonnet 5 を上回っています（43.6％ と 42.7％）。AutomationBench では Sonnet 5 の約 3 倍です。一方で、同じ比較記事とローンチ週の報道によると、Terminal-bench では GPT-5.6 Terra、desktop-task の試験では Sonnet 5 が首位です。コストの低さについては、3.7 が明確に優位です。

3.6 から upgrade すると何が壊れる？

確実に 400 になる変更が 2 つあります。ほかにも、ドキュメントの説明ほど明確に失敗しない変更がいくつかあります。Google の migration note では、temperature、top_p、top_k、candidate_count、prefill 済みの model turn を削除するよう案内しています。実測結果は次のとおりです。

変更	ドキュメントの説明	実際の挙動
prefill 済み assistant turn	削除が必要	400：「Requests ending with a model turn are not supported」（3.6 でも拒否されます。今回からドキュメントに明記されただけです）
n > 1	削除が必要	測定した interface では 400
temperature／top_p／top_k	削除が必要	3.7 と 3.6 のどちらでも、警告なしで受理
64K の出力上限を超える max_tokens	64K 上限	検証した 2 つの request path では 200,000 まで 200 で受理。生成時に暗黙的に上限が適用される
thinking_budget	level に置き換え	受理されるが無効（どの値でも消費量は 135 token で一定）

検証方法には一貫性がありません。thinking の設定値は厳密に検証され、未対応の level を送ると、その値を含む明確な 400 が返ります。一方、sampling parameter や出力上限は、どの値を送ってもそのまま受け付けます。client library がデフォルトで temperature を設定していても、現時点では問題ありません。guided output のために assistant turn を prefill している場合は、upgrade 前からすでに動いていません。

cache、context、tokenizer は引き継げる？

引き継げます。ただし、cache の反映は遅くなっています。implicit cache は 3.6 と同じ条件で hit しました。同一 prompt の 2 回目では、6,905 token のうち 4,076 token が cache され、call の料金は 52％下がりました。cache read の単価は、導入価格の入力単価の 10％です。ただし、cache 構築までの遅延が伸びました。3.6 は初回 call の 4 秒後に hit しましたが、3.7 は 4 秒後には hit せず、30 秒後に hit しました。短時間に重複 request が集中すると、cache が有効になる前に処理されます。それ以外の書き込み側のコスト構造は変わりません。

context は 1 回の call で 708,912 input token を受理し、needle question に正しく回答しました。1M という仕様と一致し、料金表にも long-context 向けの別料金はありません。text tokenizer は 4 世代で byte 単位まで同一でした。gemini-3.1-pro-preview、3.5-flash、3.6、3.7 のすべてで、英語、中国語、code を混在させた同一 corpus が 50 token と数えられました。そのまま token budget を移行できます。画像入力も、Gemini 系で測定した全サイズ一律 1,089 tokenのままです。どちらの世代も reasoning text は返しません。すべての call で reasoning_content は空でした。両モデルとも、課金対象の thinking は確認できません。ローンチ週の thread でも引き続き不満が出ています。structured output も維持されています。strict な json_schema では、3/3 で正しく有効な JSON が返りました。また、reasoning_effort: "low" を指定すると抽出処理の thinking はゼロになりました。調整値の比較で一貫して確認できた、単一 step なら安全という結果と同じです。

FAQ

Gemini 3.7 Flash API の料金はいくらですか？

導入価格は、入力 100 万 token あたり $0.75、出力 100 万 token あたり $3.75 で、2026 年 12 月 31 日まで適用されます。2027 年 1 月 1 日以降は $1.50/$7.50 に戻り、Gemini 3.6 Flash と同額です。cache read は 100 万 token あたり $0.075 です。同一 prompt の実測では、3.7 の課金額は 3.6 のちょうど半分でした。

Gemini 3.7 Flash の thinking は無効化できますか？

できません。どの off 指定も 400（「Thinking level is unsupported」）を返します。指定できるのは low、medium（デフォルト）、high です。low でも、今回の 5-step タスクでは 133 reasoning token を消費しました。reasoning_effort: "none" が使える最新の Flash は Gemini 3.6 Flash で、料金は 3.7 の導入価格終了後と同じです。

Gemini 3.7 Flash は 3.6 より request 単位でも本当に安いですか？

公表された 50％引き以上に安くなります。同じタスクで thinking も 26〜77％少ないため、実測したタスク単位の料金は 61〜88％下がりました。2-hop の文章題では $0.0020 から $0.0002 に下がっています。12 月 31 日以降は単価が同水準に戻るため、thinking の削減分だけが残ります。

Gemini 3.6 Flash 向けの code は 3.7 でも動きますか？

大部分は動きます。ドキュメントでは削除対象になっている sampling parameter（temperature、top_p、top_k）も引き続き受理されます。上限を超えた max_tokens は暗黙的に clamp されます。明確に壊れるのは 2 点です。prefill 済み assistant turn は 400 を返しますが、これは 3.6 でも同じでした。また、thinking を無効化する設定はすべて 400 になるため、コスト制御は thinking_budget から 3 段階の level に移行する必要があります。

リリース 2 日後の 2026-08-15 に Synthorai gateway 経由で測定しました。検証内容は、調整値と off 指定の matrix（effort 7 値、budget 5 値、off parameter 2 種類、n=3、すべての比較で gemini-3.6-flash も同じ batch 内で再実行）、4 タスクの reasoning-tax 測定、strict-JSON の structured output、非推奨 parameter の挙動、出力上限と 708K-context の受理、2 種類の待機時間を使った implicit-cache の pair、Gemini 4 世代での固定 corpus の tokenizer 比較、2-turn の function-calling loop（各モデル n=3）、架空の対象に関する 5 問の回答拒否テストです。タスク料金は、実測した completion token 数に各モデルの現行出力単価を掛けて算出しました。上限超過の max_tokens が受理されることと off 設定が存在しないことは、別の独立した request path でも確認しています。導入価格と期間は Google の公開条件に基づきます。rollout の進行に伴い、挙動が変わる可能性があります。