Gemini 3.7 Flashの全容｜実務3タスクで3.6と比べたら出力が完全一致した話【2026年8月】

結論: 2026年8月14日、GoogleがGemini 3.7 Flashを公開しました。Gemini 3.6 Flashからわずか3週間での世代交代です。ベンチマークも価格も大きく動きましたが、これらはすべてGoogleの公表値です。そこで私が記事制作で普段使っている3つのタスクで3.6と並べて測ったところ、うち2つは出力がバイト単位で完全に一致しました。

この記事の要点:

• 公表ベンチマークは5項目すべてで向上。DeepSWE v1.1は49.0%→65.3%（Google公式、2026年8月14日）
• 私の実務3タスクで比較したところ、HTML整形とコードのバグ修正は出力が完全一致。差が出たのはレビューだけだった
• そこから引けるのは「新しい方が優秀」ではなく、正解が一意に決まるタスクではモデルを上げても変わらないという線。ただし一例です

対象読者: 業務にLLMを組み込んでいるエンジニア、新モデルへの乗り換えを迷っている方。

読了後にできること: ベンチマークのスコア差を自分の用途にどう翻訳するか、その判断軸が持てます。

3週間で、また新しいFlashが出た

2026年8月14日、GoogleがGemini 3.7 Flashを公開しました。

驚いたのは間隔です。前世代のGemini 3.6 Flashが出てから、まだ3週間しか経っていません。

3週間で何かが動くのは、これが初めてではありません。当ブログでは先日、GPT-5.6が発売3週間で最大80%値下げされた件も取り上げました。

株式会社デュスク取締役の大竹です。

普段はSES事業の会社で取締役をやりつつ、自分でも手を動かしてAIツールを業務に組み込んでいます。このブログの記事制作にも、工程ごとにAIを噛ませています。

そして今回のGemini 3.7 Flashは、私がその制作フローで実際に使っているモデルの後継にあたります。

つまり「乗り換えるべきか」を、他人事ではなく自分の問題として判断する必要がありました。

なので、測りました。

先に結果だけ言うと、3つのタスクのうち2つで、3.6と3.7の出力が1バイトの差もなく一致しました。

Gemini 3.7 Flashの価格とベンチマーク — 発表内容の整理

まず発表内容を整理します。この節に出てくる数値は、すべてGoogleが公表しているものです。

Googleは3.7 Flashを、コーディングおよびエージェント向けの主力モデルと説明しています。

公表されているベンチマークは以下のとおりです。

DeepSWE v1.1が49.0%から65.3%、AutomationBenchが17.0%から30.4%。3週間の間隔を考えると、かなり大きな数字です。

価格は次のようになっています。

初回価格はGemini 3.6 Flashの半額という位置づけです。

価格が動くのはこのところ続いていて、当ブログでもGrok 4.6が競合の半額以下で出た件を先日扱ったばかりです。

ここで注意したいのは、年明けに価格が倍になる点です。今のコスト感で年間試算を組むと、2027年に予算が合わなくなります。

提供先は、Google Antigravity、Google AI Studio、Android Studio（Gemini API経由）、Gemini Enterprise Agent Platform、Gemini Enterprise、そしてGeminiアプリのSparkです。

なお、AndroidにおけるGeminiの扱いは規制の影響も受けます。そちらはEUがAndroidのAI層を開放させる動きとして別記事で扱っています。

ここまでは、すべてGoogleの公表値です

ここで一度立ち止まります。

上に並べた数字は、すべてGoogle自身が出したものです。発表は今日なので、当然ながら独立した第三者による検証はまだ存在しません。

ベンダーが公表するベンチマークには、条件の選び方に幅があると私は考えています。

どの比較対象を並べるか、どの設定で走らせるか。意図的に不正をしなくても、自社に有利な形になりやすい構造がある、という意味です。

これはGoogleに限った話ではなく、どのベンダーでも同じだと思っています。

そしてもう一つ。ベンチマークで伸びた幅が、自分の用途でそのまま出るとは限りません。

私が知りたかったのはそこでした。

DeepSWE v1.1が16.3ポイント伸びたとして、それは私の作業を速くしたり、正確にしたりするのか。

数字を眺めていても分からないので、測ることにしました。

【実測】私が普段使っている手順で、3.6と3.7を並べてみた

そもそも、どう使っているのか

先に前提を説明させてください。ここを飛ばすと、後半の数字の意味が伝わらないためです。

まず断っておくと、これは会社として標準化された運用ではありません。私が個人的に組んでいるやり方です。

私は記事を書くとき、作業を工程ごとに分けて担当を割り振っています。

文章そのもの、つまり「何を言うか」「どういう言い回しにするか」はAIに書かせていません。そこは自分の担当です。

Gemini Flashに渡しているのは、判断の要らない機械的な作業に限定しています。普段やらせているのは次の2つです。

• HTML衛生パス — 下書きに紛れ込んだmarkdown記法のHTML化、裸URLのリンク化、見出し階層の是正、全角半角の正規化、閉じ忘れタグの補完。「地の文は一字も変えるな」という制約付きで渡します
• 投稿前レビュー — 完成稿を独立した目でチェックさせる工程。事実誤り、固有名詞の露出、出典のない伝聞、断定表現を拾わせます

加えて今回は、3つ目としてコードのバグ修正も測りました。

理由は単純で、Googleが向上を謳っているのはコーディング領域だからです。

文章まわりのタスクだけで測って「差がなかった」と言っても、それは的外れな検証になってしまいます。

題材には、私がこのブログの投稿に使っているスクリプトそのものを使いました。

測り方

3タスクに共通する条件です。

• 指示文と入力ファイルは完全に同一。差し替えたのはモデル指定だけ
• 入力ファイルが同一であることはSHA256で確認
• 所要時間が汚れるので、並列ではなく逐次で実行
• 「直すべきもの」と「触ってはいけないもの」の両方を仕込んだ

最後の一つが今回の肝です。

検出率だけを見ていると、「よく直すモデル＝良いモデル」という評価になってしまいます。でも実務で本当に困るのは、頼んでいないことまで勝手に直してくるモデルです。

なので、直してはいけない箇所も一緒に埋めました。

たとえばHTMLのタスクでは、元記事にある「良いもの食べれるね！」というら抜き言葉をそのまま残しました。

校正の観点なら直すべき表現ですが、衛生パスの担当範囲は構造と記号だけです。ここに手を出したら指示違反になります。

検証① HTML衛生パス — 出力が完全に一致した

実在の記事下書きに、不備を14件仕込んだものを用意しました。

数字が同じどころではありませんでした。

出力ファイルが、1バイトの差もなく一致しました。修正内容も、順序も、改行位置も同じです。

トラップも両方とも完全に温存されていました。ら抜き言葉を「直したい欲」に負けずに残せているのは、指示追従がきちんと効いている証拠です。

面白かったのは、見逃しまで一致していたことです。

両方とも、全角記号の混在（本文の他の箇所は半角なのに1箇所だけ全角）だけを取りこぼしました。

「全角半角の正規化」と指示していたのに、数字は直して記号は素通しする。この癖まで同じでした。

検証② 投稿前レビュー — ここで初めて差が出た。ただし「優劣」ではない

次に、実在の記事下書きを両モデルにレビューさせました。観点も指示文も同一です。

両モデルとも、同じ2件を挙げました。給与に関する表現が誤読を招きうる点と、「絶対に」という断定表現が使われている点です。

分岐したのはそこからです。

同じ2件に対して、3.6は「要修正」と判定して差し戻し、3.7は「軽微」と判定して通しました。

ゲートとして使っている以上、これは無視できない違いです。同じ記事が、モデルを替えただけで止まったり通ったりするということですから。

ちなみに3.6は、この2件に加えてさらに2件を挙げていました。どちらも実在する箇所への妥当な指摘でしたが、直すかどうかは好みの範囲に入るものでした。

一方で3.6には別の問題がありました。

「ある行に表記ゆれがある」と、行番号つきで報告してきたのです。

ところが該当行を確認すると、そんな表記ゆれはありませんでした。ファイル全体を検索しても、指摘された語は一度も出てきません。

もっともらしい体裁の、事実に反する指摘でした。

ここは、2つの違いを分けて考える必要があります。

ひとつは判定の厳しさです。同じ指摘を「要修正」と見るか「軽微」と見るか。これは優劣ではなく性格の違いで、どちらが正しいとも言えません。ゲートを厳しく運用したいか、緩く運用したいかという設計の問題です。

もうひとつは、事実に反する指摘が出たことです。これは性格の問題ではありません。単純に困ります。行番号つきで報告されると、こちらは実際にファイルを開いて確認する手間が発生しますから。

ただし、これを「3.7の方が正確だ」と一般化するには足りません。1回ずつしか回していないので、3.6がたまたま外した回に当たっただけ、という可能性を排除できないからです。

言えるのは、拾う数が多い方が信頼できるとは限らない、ということくらいです。

検証③ コードのバグ修正 — Googleの土俵でも、やはり一致した

ここまでの2つは日本語の文章まわりのタスクです。

「コーディングの向上を謳っているモデルを、コーディング以外で測っても意味がない」という反論は当然あります。

なので、同じやり方をコードでもやりました。

投稿スクリプトにバグを8件仕込みます。

内訳は、型チェック（tsc）が捕まえるものが3件、型は通るが挙動が誤っているものが5件です。元のコードが型エラー0件であることは事前に確認しました。

またしても、出力がバイト単位で一致しました。

この検証は判定が楽でした。修正後のファイルを元の正しいスクリプトと差分比較したら、差分がゼロだったからです。

「8件すべて正しく直した」と「余計な変更を一切していない」が、一度に確認できました。

特筆したいのは、両モデルとも下書き投稿のフラグが逆になっているバグを拾ったことです。

これは型チェックでは捕まりません。「このスクリプトは下書きとして保存するためのものだ」という意図を理解して初めて、おかしいと気づけるバグです。

仕込んだ8件の中でも、見逃せば書きかけの記事がそのまま公開されてしまう、一番たちの悪いものでした。

なお所要時間は、3タスクを通して3.6が45秒・53秒・70秒、3.7が54秒・49秒・86秒でした。3.7が速かったのは3回のうち1回だけですが、いずれも数十秒の差で、実務で気になる水準ではありません。

この実測は、あくまで一例です

ここは正直に書いておきます。

各タスク1回ずつしか回していません。LLMは同じ入力でも出力が揺れるので、本来は複数回の試行が必要です。

今回の「完全一致」も、回数を増やせば崩れる可能性があります。

High設定でしか試していません。MediumやLowでは違う結果になるかもしれません。

そして一番大きな留保がこれです。コードのタスクは「正解が一意に決まる」バグ修正でした。

壊れたものを元に戻す型の問題なので、両モデルが同じ答えに収束するのは、ある程度自然とも言えます。

仕様から新規に実装させるような、正解が一つに定まらないタスクなら差が出た可能性は十分あります。今回測ったのは、コーディング能力の全般ではありません。

どのタスクも規模が小さい点も同じです。HTMLは記事1本、コードはスクリプト1本。

大規模なリポジトリを横断するエージェント的な作業は、これでは測れていません。

ですので、この結果は「Googleの公表値が怪しい」という話ではありません。測っている対象が違うだけです。

何が言えて、何が言えないのか

3つの結果を並べると、きれいな線が引けました。

言えないことから先に書きます。

「3.7が3.6より優れている」あるいは「劣っている」という一般論は、この実測からは言えません。

言えるのはこちらです。

• 正解が一意に決まるタスクでは、世代交代しても出力が変わらないことがある。それはコーディングでも同じだった
• 差が出たのは、正解が一意に決まらない「判断」のタスクだけ。しかもその差は主に、厳しさや慎重さといった「性格」として現れた(事実に反する指摘が1件出た点は性格の話ではないが、1回の試行では精度差とまでは言えない)
• ベンチマークの改善幅は、自分の用途にそのまま効くとは限らない

エンジニア・SES現場への示唆

今回のような間隔で更新が続くなら、「毎回追いかけて乗り換える」という運用は現実的ではなくなります。検証が追いつきません。

代わりに必要なのは、自分の実務タスクを固定した、小さな検証セットだと思っています。

今回のように「不備をN件仕込んだ入力」を一つ持っておけば、新しいモデルが出るたびに数分で判断できます。

コツは、触ってはいけないトラップを一緒に埋めておくことです。そうすると「直せるか」だけでなく「余計なことをしないか」まで、一度に測れます。

実務で事故るのは、たいてい後者です。

SESの現場では、常駐先でAIツールの導入可否を相談されることがあります。

そのときにベンダーのベンチマーク値をそのまま持っていく人と、その現場のタスクで測った結果を持っていける人とでは、説得力がまるで違います。

コスト面でも同じことが言えます。

正解が一意に決まる用途なら、差が出ないのですから安い方や枯れた方を選ぶのが合理的です。

初回価格に釣られて全面的に移行する前に、自分の用途で差が出るのかを見た方がいいと思います。

今すぐ確認・検討すべきこと

• 自分がLLMに投げている作業を、「正解が一意に決まるか、決まらないか」で仕分けてみる。「難しいか、簡単か」ではない点が肝です
• 一意に決まる側（整形・変換・バグ修正・移行作業）は、モデルを上げても効果が薄い可能性がある
• 一意に決まらない側（レビュー・評価・設計判断・優先順位づけ）は、モデルを変えると挙動の性格が変わる。差し替えたら必ず再検証する
• 特にレビューやゲートの用途では、モデルの差し替えで通過しやすさが変わる点に注意。基準が緩む方向に動くと、気づかないまま素通りが増えます。今回まさにそれが起きました
• 初回価格（2026年12月31日まで）と2027年以降の通常価格の差を、年間のコスト試算に入れておく

まとめ

3週間で世代交代しました。ベンチマークの数字も伸びています。

でも私が普段回しているタスクでは、コードも含めて、出力が1バイトも変わりませんでした。

これはGoogleの発表を否定するものではありません。タスクの性質が違う、というだけの話です。

差が出たのは、正解が一つに決まらない「判断」の工程だけでした。しかもそれは、1回ずつの試行で見た限りでは、優劣というより性格の違いに見えました。

繰り返しになりますが、この実測はあくまで一例です。

1回ずつしか回していませんし、High設定だけですし、タスクの規模も小さい。バグ修正にいたっては正解が一意に決まる問題でした。

なので持ち帰っていただきたいのは、この結論そのものではありません。

自分のタスクで測る、という習慣の方です。

新しいモデルが出るたびに情報を追いかけるのは、正直しんどいですよね。

でも手元に小さな検証セットが一つあるだけで、その判断は数分で終わります。次のモデルは、たぶんまた3週間後に来ますから。

参考・出典

• Google公式発表「Gemini 3.7 Flash」（2026年8月14日）: https://blog.google/intl/ja-jp/company-news/technology/gemini-37-flash/
• 本文中のベンチマーク数値・価格・提供先は、すべて上記の公式発表によるものです
• 実測パートの数値は、2026年8月14日に筆者が計測したものです