Skip to content
Published on

Gemini 3.7 Flashの導入価格と3週間サイクル — モデル原価を固定費ではなく条件付きの値として扱う理由

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
シェア
Authors

この記事は2026-08-15にHacker News APIとGeekNewsフィードで直接確認した項目に基づいています。スコアと順位は変わり続けます。

何が上がっていたか

Hacker News APIで確認した項目です。タイトルは Gemini 3.7 Flash、アイテム番号は49289112で、2026-08-15時点で946ポイント、コメント482件でした。リンク先はGoogleブログの公式発表です。同じ項目がGeekNewsフィードにも並んでいました。

発表文はこのモデルを、コーディングとエージェントのための最も賢い常用モデルとして紹介し、2026年8月13日付で公開したと記しています。そして直前のモデルであるGemini 3.6 Flashが出てから3週間だという事実も発表文の中にあります。

ベンチマークは上がりました。ただし何と比べたのか

発表文に載った数値です。FrontierCode 1.1 Mainが43.6%で直前の3.6 Flashの34.4%から上がり、DeepSWE v1.1は65.3%で49.0%から、GDP.pdfは34.0%で22.0%から、AutomationBenchは30.4%で17.0%から上がりました。WebDev Arena Eloは1588で1538からです。

上げ幅そのものは大きいです。AutomationBenchはほぼ倍です。ただしこの表には共通点が1つあります。比較対象がすべて同じ系列の直前バージョンだという点です。

これがなぜ問題かというと、みなさんが実際に下すべき判断は「3.6から3.7に上げるか」ではないからです。判断はたいてい「この枠にどの会社のどのモデルを置くか」です。自己参照のベンチマークはその判断に使えません。改善があったという事実を伝えるだけです。

コメントでも同じ指摘が出ました。競合の低価格モデルと比較した数値を出すべきだという要求であり、その低価格モデルがはるかに安いため常用モデルの枠そのものの必要性を切り崩しているという話でした。ベンチマーク表を読むときの一般的な落とし穴はベンチマークの読み方で別に整理しています。

本当のニュースは価格表の文法です

発表文の価格は2行になっています。

2026年12月31日までは入力100万トークンあたり0.75ドル、出力100万トークンあたり3.75ドルです。そして2027年1月1日からは入力100万トークンあたり1.50ドル、出力100万トークンあたり7.50ドルが適用されます。

ちょうど2倍です。そしてこれは「あとで上がるかもしれない」ではなく、値上げの日付と値上げ後の金額がすでに確定して告知されたものです。

コメントで最も繰り返された反応がこの点でした。あるコメントはこの構造を奇妙だと指摘し、直前のモデルが3週間前に出た状況で5か月後もこのモデルを使っていると予想する人が誰なのかと問いました。

この問いが鋭いのは、導入価格という仕掛けの前提に触れるからです。導入価格は通常、切り替えコストを作っておいて期限後に回収する構造です。ところが後継モデルが3週間間隔で出る市場では、期限の時点ですでに他の選択肢がいくつも存在しています。

では原価をどう置くべきか

ここから実務的な結論が出ます。モデル単価を固定費として置いた財務モデルは間違っています。

多くのチームは単価に予想トークン量を掛けて月額を出し、それで承認を得ます。その数字は2026年12月31日に2倍になります。年間予算に換算すれば半分は低い単価、半分は高い単価です。

実際に計算すべきなのは3つの枝です。

  • 期限前の区間: 導入価格ベースの費用。たいていこれが承認された数字です。
  • 期限後にそのまま置く場合: 定価ベースの費用。最悪ケースではなく、何もしなかったときの既定値です。
  • 期限の時点で移す場合: 定価と代替の単価の差から切り替えコストを引いた値。切り替えコストには再評価、プロンプト調整、回帰検証が入ります。

3番目の値が肝心なのに、ほとんどのチームはこれを測ったことがありません。そこで勧めることが1つあります。モデルを最初に組み込むときに切り替えコストを一度測っておくことです。今使っているモデルを別のモデルに差し替えて評価セットを回し直すのに何日かかるかを測れば、その数字が今後すべての価格変動対応の基準になります。何日もかかるなら、みなさんは事実上価格変動に対応できない状態であり、そのとき必要なのは安いモデルではなく、モデル交換を安くする評価パイプラインです。

LLM APIの費用を下げる一般的な筋道はLLM APIコスト最適化戦略とプロンプトキャッシングとエージェントのコスト・遅延に整理しています。

公開されなかった2つの数字

この発表文にはコンテキストウィンドウ長と遅延の数値がありません。

この不在が際立つのは、その2つがよりによってアーキテクチャを決める数字だからです。ベンチマークのスコアはどのモデルを選ぶかに影響しますが、コンテキスト長は文書を分割する必要があるかどうかを決め、最初のトークンまでの時間はストリーミングUIが成立するかどうかを決めます。後者の2つがシステム設計を変えます。

コメントでこの系列の本当の強みとして繰り返し挙げられたのも、正確度ではなく速度、とくに端から端までの応答時間でした。発表文が正確度だけを公開して速度を公開していないのに、使う側は速度のために使うと言っている状況です。

実務的には単純な結論になります。発表資料にない数字は自分で測るしかありません。候補モデル2〜3個について、実際のプロンプト長で最初のトークンまでの時間と完了までの時間をそれぞれ50回ほど測り、中央値と95パーセンタイルを残せば十分です。この計測は半日で終わり、3週間ごとに繰り返されるモデル更新で使い回せます。

どこまで出ているか

発表文に記された提供先は、開発者向けにGoogle Antigravity、Gemini API、Google AI Studio、Android Studio、企業向けにGemini Enterprise Agent Platform、個人向けに160か国以上でGemini SparkのPro/Ultra購読者です。安全面ではCBRNとサイバー攻撃領域の保護策を更新したと言及しています。

誰には当てはまらないか

月間トークン使用量が数百万単位にとどまるチームなら、この記事の価格計算は過剰です。単価が2倍になっても絶対額が小さく、切り替えコストをかけるほうが損です。その規模で最適化する対象は単価ではなく開発時間です。

モデルを自前でホストする組織や固定容量契約を結んだ組織もこの構造とは無関係です。ただしその場合も3週間サイクルという事実は残ります。自前ホスティングではそれが価格の問題ではなく、モデル更新をどれだけ頻繁に検証して配備できるかの問題に変わります。

逆にこの記事が最も直接当てはまるのは、大量分類、要約、パースのように低価格モデルにトラフィックの大半を載せるパイプラインです。そうした枠では単価がそのままサービスの利幅であり、2倍の値上げは即座に損益に現れます。

まとめ

発表文で長く残る情報はベンチマークではなく2つの日付です。3週間前に直前のモデルが出たという日付と、4か月後に単価が2倍になるという日付です。2つを並べて見ると、モデル選択は一度行う決定ではなく定期的にやり直す作業であり、そうなると最適化対象はどのモデルを選ぶかではなく、選ぶ作業をどれだけ安くするかになります。

原文と関連記事

価格モデリングと計測方法についての提案は、発表文に記された数値をもとに筆者が整理したものです。

Discuss on Twitter • View on GitHub