はじめに
2026年8月14日、米Googleから新たな生成AIモデルであるGemini 3.7 Flashが公開されました。前バージョンの 3.6 Flash からわずか3週間でのリリースとなります。
い、いくらなんでも早すぎー...
公開されたブログの内容やスペックを踏まえつつ、今回は独自の検証環境を用いたGemini 3.6 Flashとの比較と、そこから見えてきた新しいモデルとの正しい付き合い方について整理します。
Gemini 3.7 Flashの主な特徴とスペック
公式の発表によると、Gemini 3.7 FlashはコーディングやAIエージェント向けの性能を高めたモデルです。ソフトウェアエンジニアリング、ナレッジワーク、Web開発といったワークフロー全体で大幅に進化しています。
特に伸びが目立つのはコーディングとデバッグ能力です。
FrontierCode 1.1 Mainでは43.6%（3.6 Flashは34.4%）、DeepSWE v1.1でも65.3%（同49.0%）と、いずれも大きくスコアを伸ばしています。Web開発・UI生成の分野でも、少ないプロンプトから実用的なレイアウトや機能を組み立てられるようになっており、WebDev ArenaのEloスコアは1588を記録しています（※3.6 Flashは1538）。金融・法律・バイオサイエンスといった専門分野の複雑なドキュメント処理（GDP.pdf: 34.0%対22.0%）や、実際のビジネスワークフローの遂行（AutomationBench: 30.4%対17.0%）でも、実務での使い勝手が上がっていることがうかがえます。
提供形態やコストに関する主なポイントは以下の通りです。
| 項目 / 対象 | 詳細 |
|---|---|
| 価格設定 | 2026年末までは標準価格の半額（入力100万トークン0.75ドル、出力100万トークン3.75ドル）で提供 ※2027年1月1日より標準価格（入力1.50ドル、出力7.50ドル）が適用 |
| 法人向け | Gemini Enterprise Agent PlatformおよびGemini Enterprise appからアクセス可能 |
| 開発者向け | Google Antigravity、Google AI Studio、Android Studioの Gemini APIを通じて開発が可能 |
| 個人向け | Google AI Pro および Ultra のユーザは、Gemini Sparkを通じて利用可能 |
検証の背景とテーマ選定の理由
公式発表で強調されている通り、Gemini 3.7 Flashの目玉はコーディングおよびAIエージェント向け性能の向上です。Gemini 3 Flash系モデルはすでに高い基礎能力を持っているため、一問一答形式のシンプルなタスクでは、世代間の進化を明確に実感しにくくなっています。
そこで、新モデルの実力を正しく測るためには、LLM自身が自律的に計画を立て、関連ファイルを探索し、コードを修正してテストを実行するといった一連のエージェント的な振る舞いを検証できる環境が必要となります。
ソフトウェアエンジニアリング能力を測定するSWE-bench
エージェントとしての自律性を客観的に評価する指標として、プリンストン大学の研究チームが発表したSWE-benchの枠組みを採用しました。
SWE-benchは、関数やスクリプトを単発で生成させる従来のベンチマークとは異なり、GitHub上の実在するオープンソースプロジェクトで報告されたissueを、そのままプロンプトとしてLLMに与えます。
モデルはリポジトリ全体のコードベースから修正箇所を特定し、コードを編集してテストで検証する自律ループを回す必要があります。
今回はより実践的な評価を行うため、公式のデータセットをそのまま使うのではなく、SWE-bench的なアプローチを参考に独自の自作検証環境を構築し、実際のOSSプロジェクト（sqlfluff）のissueから選定したタスクを対象としています。
評価基盤の設計とデータリーク対策
今回の検証では、Google Cloud上にSWE-bench風のサンドボックス環境を自作しました。
モデルが過去の学習データから正解コードをそのまま出力してしまうデータリークの点も考慮し、純粋なコード解析力を測定するため、インフラ側に以下の対策を実装しています。
- 正しい修正前の状態から検証を始めるため、GitHub API経由でそのissueに対応するbase_commit（修正が入る直前のコミット）を特定してチェックアウト
- Cloud Runにて、マルチインスタンスによるファイル変更の消失を防ぐため、
--max-instances=1かつ--concurrency=1に固定 - 新しく作られたファイルも差分として見逃さないように、
git add -A && git diff --cachedでチェック - チェックアウト後、あえて.gitの履歴を消して作り直し、コミットを1つだけの状態にすることで、エージェントが過去の修正履歴や正解コミットを閲覧する経路を物理的に遮断
- 作業完了後、そのissueを本当に解決した公式PR（Golden Commit）からテストファイルだけを取得・上書きし、pytestで合格・不合格を判定
タスク別の検証結果
実際のオープンソースプロジェクト（sqlfluff）のissueをベースに、両モデルの比較を行いました。
1つ目のタスク（issue #2392）は、まずはお試しとしてissueの内容を要約・改変したものを使用し、2つ目のタスク（issue #478）はより実践に近い検証とするため、実際のissue本文をそのまま使用しています。
① 単一ファイルの新規作成（sqlfluff PR #2405）
SQLFluffのL060ルール（IFNULLやNVLをCOALESCEに置換）において、違反検知時の結果オブジェクトに説明文が含まれていないバグを修正するタスクで、単一ファイルの新規作成と構造定義が求められます。
| モデル | 特徴 | ターン(使用/上限) | 処理時間 | 公式テスト判定 |
|---|---|---|---|---|
| Gemini 3.6 Flash | 大文字・小文字を自動判別して置換する独自実装 | 10 / 10 | 約12分 | PASS |
| Gemini 3.7 Flash | 識別子種別（function_name_identifier等）まで考慮した実装 | 10 / 10 | 約18分 | PASS |
両モデルともに公式PRとは異なる独自のアプローチでコードを生成し、テストをクリアしました。
難易度が低〜中規模であったため、両モデルとも余裕をもって正解を導き出しています。
② 複数ファイルに跨るバグ修正（sqlfluff PR #498）
BETWEEN句に算術式が含まれると構文解析に失敗するバグの修正タスクです。
3つのファイルに跨り、パーサーのコア文法を修正する必要があり、先ほどのものと比べると高難易度な内容です。
| モデル | 特徴 | ターン(使用/上限) | 処理時間 | 公式テスト判定 |
|---|---|---|---|---|
| Gemini 3.6 Flash | 早期（6〜7ターン目）から編集に着手し、ターン切れの時点で実装が完成 | 15 / 15 | 約14分 | PASS |
| Gemini 3.7 Flash (1回目) | 15ターン全て探索に費やし、編集に一度も着手できず終了 | 15 / 15 | 約14分 | FAIL |
| Gemini 3.7 Flash (2回目) | 慎重な調査の後、終盤（22〜23ターン目）で実装し最終回答も生成 | 23 / 25 | 約21分 | PASS |
テストに通った際の実装は、両モデルとも同じ発想でした。「+」や「-」のような四則演算を扱うための文法ルールが、実は未実装のまま放置されていたことを突き止め、それを自力で実装した上で、BETWEEN句がその文法ルールを見るように書き換える、というものです。
実験結果から見えたモデルの特性とシステム設計への示唆
実験データの詳細なログから、モデル間の行動パターンの違いとエージェント設計上の留意点が確認できました。
なぜ3.7 Flashは最初何もできなかったのか？
正解のコミットを見られないようにした状態でも、両モデルともリポジトリの中のコードを自分で読み、文法のルールを実際に調べながら実装していたことから、学習済みの知識をそのまま吐き出しているのではなく、その場でコードを解析して考えていることが確認できました。
その上で興味深かったのが、3.7 Flashと3.6 Flashの挙動の違いです。
3.6 Flashは、早い段階で仮説を立ててコード編集に着手し、テストエラーをフィードバックにして修正を重ねるプロトタイプ駆動型の挙動を示しており、ターン数が制限された環境で高いパフォーマンスを発揮します。
対して3.7 Flashは、リポジトリ全体の依存関係や周辺コンベンションを慎重に調べてからコードを編集するアプローチをとるため、②のタスクの1回目のように、ターン数上限が15ターンの設定では石橋を叩きすぎて渡れないまま、調査中にターン切れを起こしてしまうケースがありました。ただし、25ターンまで拡張した2回目の試行では一括で精度の高い修正を完了させることができています。
見えてくるmax_turns設定の重要性
AIモデルをコーディングエージェントとしてシステムに組み込む際、単純に最新モデルを採用するだけでは十分な性能を引き出せない場合があります。ターン数を抑えた迅速なトライアルアンドエラーが必要な要件には3.6 Flash、十分なターン数を確保して深い解析を行わせる要件には3.7 Flashを割り当てるなど、モデルの特性に合わせてmax_turnsのパラメータやプロンプトを調整するシステム設計が求められるのではないかと思います。
おわりに
正直、複雑なバグ修正のタスクにおいて、3.7 Flashが上限として設定した15ターンを使い切って「FAIL」という結果を返してきた時は、新しいモデルなのになぜ？と面食らいました。
恥ずかしながら新モデルは性能が上がっていて当たり前、少ないターン数でバシッと回答を導き出してくれるだろう、という思い込みがどこかにあったためです。
しかし、上限を25ターンに増やして見事にテストを通過した結果を見て、単純に劣っているのではなく、慎重に全体を把握してから動くため、手番が多く必要だったということに無事に気がつくことができました。
3.7 Flashへのアップデートは、単なる生成スピードや知識のアップデートにとどまらず、エージェントとしての振る舞い自体を変えています。
既存のシステムのモデル名を差し替えるだけでは、max_turnsのようなパラメータが合わずに本来の実力を発揮できない、ということが今回のケースからも分かりました。
直近、Gemini 3シリーズがかなり早いスピード感でリリースされていますが、新しいモデルを使う際は、賢くなったから前と同じように、いやそれ以上に動いてくれるはず！という先入観を捨てて、各モデルの癖に合わせて環境側もチューニングしていく必要がありそうです。