FrogNano-4B-2609 vs Gemma 4 12B：SWE-benchで61.5%、そして誰もそれを確認していない

MicrosoftのFrogNano-4B-2609は、40億クラス級のコーディングエージェントで、その派生元はQwen3.5-4Bで、SWE-bench Verifiedでは61.5%を報告している。Gemma 4 12Bは、DeepMindの119億5000万パラメータのエンコーダ不要のマルチモーダルモデルで、そのカードはLiveCodeBench v6で72.0%を報告している。これらは買い手が並べて比較する2つの数字だが、並べて比較すること自体が間違いだ。それらは異なるベンチマーク、異なるハーネス、異なる研究室に由来し、さらに重要なことに、そのうち片方だけが、部外者が読んだことのある公開された評価方法論を持っている。この対決に関するその他のことはすべて、各モデルが実際に何であるかという問題であり、答えは、それらがまったく同じカテゴリーのものではないということだ。

以下のFrogNanoの数値は、Microsoftのモデルカードとその技術レポートに由来する。どちらも9月から公開されており、ラボ外の誰によっても再現されていない。以下のGemma 4 12Bの数値はGoogleのモデルカードに由来し、これもベンダー文書だ。違いは、Gemmaの数値には20週間と約260万ダウンロードにわたる精査が背後にあるのに対し、FrogNanoには2週間と、まだ一桁を超えていないダウンロードカウンターしかないことだ。

各モデルの用途

これはスペックシートが隠してしまう部分だ。FrogNano-4B-2609 は、たまたまコードが得意な汎用モデルではない。ポストトレーニングのすべてがリポジトリレベルのソフトウェアエンジニアリングであり、話しかけられるのではなくハーネスによって駆動されるように設計されたチェックポイントなのだ。

その5つのツールはRead、Write、Edit、GlobとBashです。モデルはそれらへの呼び出しを発行し、サンドボックスがそれらを実行して出力を返し、モデルが要求を停止するまでループが実行されます。評価された構成は、約131Kの合計トークン内で150の対話ステップであり、タスクごとに候補パッチを生成しました。Microsoftのカードは、モデルが英語の、Pythonを多用するリポジトリを対象としており、再現可能な環境と実行可能なテストスイートを備えていること、およびベースモデルから継承された画像と動画のコンポーネントは事後学習されておらず、サポートされていないことを明示しています。

Gemma 4 12Bは逆の形だ。48層の統合モデルで、256Kコンテキストを持ち、視覚や音声のための別個のエンコーダはない——生の画像パッチと音声波形は、軽量な線形層を通じて単一デコーダの埋め込み空間へ直接射影される。テキスト、画像、音声を入力として受け取り、テキストを出力する。システムプロンプト内のトークンによって起動される思考モード、ネイティブの関数呼び出しを備え、Googleのモデルカードでは、想定される用途の一つとしてエージェント型ワークフローをわざわざ挙げている。

つまり本当の問題は、どちらがより賢いかではない。自分で操作しなければならない装置の中でしか機能しない専門特化型コンポーネントが欲しいのか、それとも多くのことをそこそこ上手くこなし、あらゆるものから呼び出せる汎用モデルが欲しいのか、ということだ。

異なる箇所を行ごとに

• パラメータ — FrogNano-4B-2609 はモデルカードに「500M-5B」という範囲を掲げているが、そのカード自体の説明には約46.6億と記載されており、ダウンロードでは BF16 重みの 9.32 GB で決着する。Gemma 4 12B は 11.95B で、一度だけ明記され、決して曖昧にされない。比率はおよそ 2.6 対 1 で、それは借りなければならないものに直接表れる。

• コンテキスト — FrogNano の評価構成は合計約 131K トークンで、推論とツール出力が予算を共有している。Gemma 4 12B は 256,000 トークンを搭載し、それ自体の長文コンテキスト行では、128K で 8 つのニードルを用いた MRCR v2 で 43.4% を記録する。ウィンドウはほぼ 2 倍で、2 番目の数値は能力の主張ではなく公表された測定値である。

• モダリティ — FrogNano-4B-2609 は、チェックポイント内にビジョンタワーを備えているにもかかわらず、テキスト入力・テキスト出力です。Gemma 4 12B はテキスト、画像、音声の入力に対応します。

• 出力上限 — 検証済みのFrogNano構成では、アシスタントの1ターンあたり8,192トークンの生成が可能で、そのカードにはRLトレーニング構成でも同じ上限が使われたと記されている。Gemma 4 12Bは同等の単一ターン上限を公表しておらず、そこでの制約は256Kのコンテキストウィンドウである。

• エージェント型インターフェース — FrogNano は構造化された Leaf 呼び出しを出力し、それらを実行するためのハーネスが必要です。Gemma 4 12B は、指示チューニング済みの形式でネイティブの関数呼び出しを搭載しており、直接呼び出すことができます。

• ライセンス — Gemma 4 12B は Google の Gemma 4 利用規約に基づく Apache 2.0 であり、明快に記載されています。FrogNano のカードは、冒頭部分では MIT、本文では Apache 2.0 となっており、これは脚注ではなく法務レビュー行きになりがちな種類の曖昧さです。

• 数値 — FrogNanoはSWE-bench Verifiedで61.5%、SWE-bench Proで37.6%、Terminal-Bench 2.0で31.1%、PatchEval-Verifiedで47.3%を報告している。Gemma 4 12BはMMLU Proで77.2%、LiveCodeBench v6で72.0%、Codeforces ELO 1659、GPQA Diamondで78.8%、Tau2で69.0%を報告している。GoogleのモデルカードはSWE-benchの行を公開しておらず、MicrosoftのモデルカードはLiveCodeBenchを公開していない。両者のスコアボードにはまったく重複がない。

最後の項目こそ、数字で比較したくなる衝動に終止符を打つべきものだ。両方のカードに共通して載っているベンチマークは一つもない。61.5 と 72.0 を並べて比べる読者は、リポジトリ解決率と競技プログラミングの通過率を比較していることになる。それは、どちらも秒単位だからという理由でマラソンのタイムと100メートルのタイムを比べるようなものだ。

なぜGoogleのSWE-benchに関する沈黙は危険信号ではないのか

箇条書きから引き出したくなる結論は、FrogNano には実際の SWE-bench の数値があり、Gemma にはそれが無いのだから、コーディングの問いでは FrogNano の勝ちだ、というものだ。しかしそれは帰結しない。正確に述べておく価値のある理由があるからだ。

Gemma 4 12B は、Tau2 で 69.0% を報告している — 3 回の実行にわたるエージェント型ツール使用ベンチマーク — とともに、その関数呼び出しサポートと、エージェント型ワークフロー向けの明確な位置づけも示している。Tau2 で 69.0 を記録するモデルは、エージェント型作業を行えないモデルではない。それは、リポジトリ解決ではなくツール使用性能を報告することをベンダーが選んだモデルである。Google はまた、26B や 31B について SWE-bench の行を報告しておらず、これは 12B の弱点ではなくファミリー全体にわたる編集上の選択である。

一方で、Microsoft自身の論文にあるあの直感に反する結果は、Gemmaの購入者が注意深く読むべきものだ。FrogNanoは汎用モデルであるQwen3.5-4Bを出発点とし、Leafハーネスを通じてSWE-bench Verifiedで39.4%を記録した。約1,500件の合成タスクに対する5ラウンドの強化学習によって、それが61.5%まで押し上げられた。教訓は「小さなモデルはコードを書けない」ということではない。そうではなく、39.4%の汎用4Bチェックポイントが、誰かが有能なエージェントループ内で実行したときには、人間が検証した難しいissueセットの3分の1以上をすでに解いていた、ということだ。Gemma 4 12Bはその3倍のサイズで、20週間分成熟している。誰もそれをLeafで実行したことはなく、誰かがそうするまでは、「Gemmaはリポジトリエージェントではない」というのは発見ではなく前提にすぎない。

スコアボードが完全に隠しているハーネス税

これが実用的な非対称性であり、購入を決めるのはまさにこれだ。

Gemma 4 12Bはモデルです。11.95Bの重みをダウンロードし、Transformers、vLLM、SGLangをそれらに向け、テキストを送り、テキストを受け取ります。Googleはサービング経路を公開しており、ライセンスは明確で、260万ダウンロードに相当する人々がすでに荒削りな部分にぶつかり、それらを文書化しています。タスクが「このスタックトレースを要約する」、「このスクリーンショットを読んで何が壊れているか教える」、または「この関数をこれらの引数で呼び出す」であれば、今日動きます。

FrogNano-4B-2609はモデルとハーネスの組み合わせであり、Microsoft自身のREADMEはハーネスを必須としている。github.com/microsoft/FrogNanoにあるリポジトリはLeaf評価装置であり、学習コードではない。これにはKubernetesクラスタ、既存の名前空間、Podとネットワークポリシーを管理する権限、ベンチマーク用コンテナイメージをプルするアクセス、そして適切な推論パーサーとツール呼び出しパーサーを設定したOpenAI互換エンドポイントが必要である。Microsoftのカードは一致条件を率直に述べている。同一のスコアを得るには、一致するチェックポイント、トークナイザー、サービング構成、タスクイメージ、評価プロトコルが必要である。リリースのうちスコアを生成する側の半分こそ、カードがGitHubリンクを指し示している側の半分である。

それには確かな価値があり、切り捨てるのではなく、きちんと評価して名を挙げる価値がある。FrogNanoの貢献は、現在のポリシーの能力に照らして訓練問題を再生成するタスク合成ループだ。論文の主張は、小さなエージェントを合成タスク上で競争力のある水準まで、蒸留を一切使わずに訓練できるというもので、それはフロンティアの教師を雇う余裕がないあらゆる人に道を開く。そのAPIは公開されている。その手法は原理上再現可能だ。それは、また一つの中間チェックポイントよりも強い貢献であり、同時に、参加しようとするほとんどのチームが引き受けるよりも多くの作業でもある。

一つ選ぶなら、仕事で選びなさい

Gemma 4 12B は、作業が複数のモダリティにまたがる場合、何かが画像を見たり音声を聞いたりする必要がある場合、コンテキストが大きなファイルツリーと長いトランスクリプトを同時に保持しなければならない場合、または背後に別のシステムを必要とせずにどのフレームワークでも読み込めるモデルが欲しい場合に選ぶとよい。69.0 の Tau2 スコアとネイティブの関数呼び出しにより、エージェント型パイプラインにとって正当化できる選択肢であり、ラボの言葉を鵜呑みにする必要はない——このモデルは何千人もの人々によって評価されており、結果は秘密ではない。

FrogNano-4B-2609 を選ぶべきなのは、すでにサンドボックス化されたリポジトリエージェントを動かしていて、そこに投入できる 4B クラスのチェックポイントを求めていて、しかも、そこそこのハードウェアに収まる 9.32 GB のダウンロードが判断を左右する制約になっている場合だ。順序立てについては冷静に見極めよ。あなたはスコアを買っているのではなく、一つの手法に賭けているのだ。そして最初にわかるのは、あなたのポーリングループとツール呼び出しパーサーが Leaf に十分似ているかどうかだ。チームによっては三日目の午後に 61.5% 前後の挙動を得るだろうし、チームによっては自分たちの評価セットが SWE-bench Verified より簡単だったと気づくのに二週間を費やすだろう。そして、あなたがどちらなのかを、ラボの外の誰もまだ教えてはくれない。

判断が本当に拮抗しているなら、共通のベンチマークを持たない公表値を論じ合うより、自分の課題で両方を同じハーネス内で走らせるのが安上がりな実験です。OrcaRouterは200以上のモデルを1つのOpenAI互換キー 0%のマークアップで提供しており、プロバイダの定価がそのまま通過するので——ホスト型の汎用モデルと候補セットの残りを、判断する間、単一のエンドポイントと1本の請求ラインの背後に置くことが可能になります。FrogNanoは当社のルートの一つではなく、時期も未定です。重みは自分でホストするダウンロードです。私たちが取り除けるのは、比較のもう一方側の摩擦です。つまり、2つ目の契約、2つ目のSDK、2つ目の認証情報なしで、自分のハーネス内で候補モデルを差し替えられるようにすることです。

正直な要約は、61.5という数字はそれを生み出したラボによる本物の成果であり、現時点でコーディングにおいてFrogNanoを選ぶ唯一の理由である、ということだ。Microsoftの外部の誰かが同じ500タスクで61.5を再現する——あるいは再現に失敗する——とき、この対決に本当の答えが出る。それまでは、ほとんどのチームにとってより安全な既定は、クリーンなライセンス、公開された長コンテキスト測定値、そして20週間分の他人の失敗がすでにドキュメントに取り込まれている11.95Bモデルだ。