FrogNano-4B-2609：Microsoftは4BのコーディングエージェントをHugging Faceに投入し、それを一切発表しなかった

リポジトリは2026年9月17日、最初のコミットとともに公開され、チェックポイント自体はその4分後に上がった。その後は何もない。Microsoft AIからのツイートも、Microsoft Researchブログの記事も、ローンチページもない。7週間が経った今もmicrosoft/FrogNano-4B-2609 — 40億クラス規模のコーディングエージェントで、Qwen3.5-4B上に構築された — の背後には依然として何の発表もなく、その沈黙こそがこのモデルの公開をめぐる最も重要な事実である。あるのは、論文とハーネスの存在をうたうモデルカード、ハーネスであって論文ではないと判明したGitHubリポジトリ、そしてcreatedAtが9月17日で、「Release date 22-SEP-2026」と記されたカードの下に置かれていることだ。どちらの日付もその場で作り上げられたものであり、どちらも間違いではないが、互いに食い違っている。

実際に公開されているものは何ですか

以下はすべて今この瞬間ハブ上で確認可能であり、本記事中の数値はすべて Microsoft 自身のカード、またはリポジトリ自体のバイト数に由来している。第三者によって再現されたものは何もない — Artificial Analysis の項目も、アリーナ評価も、FrogNano に関する独立した評価も、どこにも存在しない。

• 重み — Microsoft 組織下の1つの公開リポジトリ、ゲートなし、ハブ上で MIT タグ付き、15ファイル、ダウンロードゲートなし、署名する契約もなし。

• ディスク上の重み — 2つのsafetensorsシャードにまたがる9.32 GB、オプティマイザを含まないファイルセットを含むリポジトリデータ596億バイト、インデックス内の738テンソル。

• アーキテクチャ — Qwen3_5ForConditionalGeneration。Qwen3.5-4Bから受け継いだ密な32層のハイブリッドスタックで、24層のビジョンタワーを備えており、モデルカードによればこれも受け継がれたもので、事後学習は一切行われていないという.

• カード自体のパラメータ欄 —「500M-5B」。これは数値ではなく帯域であり、より正確なのはダウンロードした文書です。

• ライセンス — カードのフロントマターには MIT と記されている。カード自体の本文には Apache License 2.0 と記されており、GitHub のハーネスは実際に MIT LICENSE ファイルを同梱している。これら2つの記述は、同じリリース内の異なる成果物について述べたものである。

• 発表 — なし。Microsoft Researchのブログにも、チーム自身の研究サイトにも、Hugging Face組織のフィードにも、リポジトリ一覧として以外には一切載っていない。

その最後の一行こそ、この記事の残りを読むうえでの読者の姿勢を決めるべきものだ。ひっそりとアップロードされたチェックポイントは、公表されたものに劣る成果物ではない——そのカードはしばしば長い。誰もプレスリリース向けに短く編集したりしないからだ。だが、公表されたリリースがただで得られる唯一のフィルター、つまり他の人々がそれを見るというフィルターを、それは通っていない。

スコア、そしてそれらすべてを制作したのは誰か

Microsoftは、FrogNanoがSWE-bench Verifiedで61.5%、SWE-bench Proで37.6%、Terminal-Bench 2.0で31.1%、PatchEval-Verifiedで47.3%に到達したと報告している。いずれもLeafハーネスを通じて測定されたAvg@3の解決率である。同じカードには出発点も示されている。Qwen3.5-4Bは、同一のハーネスと予算の下でSWE-bench Verifiedの39.4%を記録した。5回の強化学習イテレーションにより、49.1%、53.1%、56.7%、59.1%、61.5%へと進み、ベースモデルを22.1ポイント上回った。Microsoft自身の表現では、これは約56%の相対的改善に丸められる。

そのラダーについては、二つの点に立ち止まって考える価値がある。というのも、それらはベンダーが誤った箇所ではなく、要約が誤りやすい箇所だからだ。

第一は、Iter 5 の不一致である。カードの見出し表は最終イテレーションについて 61.5% と述べているが、論文自身の効率付録は同じ5つのチェックポイントの推移を 48.2%、53.4%、58.3%、58.6%、61.6% として報告している。近いのは最後の数字だけであり、誰もが引用するのも最後の数字だけである。最終的な数値は安定した結果として扱い、中間の段階は別のものの測定として扱え。別の集計方法の下では、それらは明らかにそうだからである。

第二の点は、FrogNano が、その出発点となったモデルよりあらゆる軸で一様に優れているわけではないということだ。公表されている並列ツール呼び出し率は1.71%である。モデルカードは、後のイテレーションで単一ターン内に複数のツール呼び出しを発火する能力を失ったこと、そしてチームの統合作業がそれを部分的に取り戻すために存在していることを率直に認めている。より多くの問題を解決しつつ、ほぼ並行呼び出しを行わないモデルは、脚注ではなく、実際のエンジニアリング上のトレードオフなのだ。

ハーネスが製品であり、リポジトリがそのハーネスである。

FrogNanoは単独では動作しません。5つのツールに対する構造化された呼び出しを発行します——Read、Write、Edit、Glob、そしてBash——そして何かがそれらを隔離された環境で実行し、出力を返さなければなりません。その何かがLeafであり、ここでその道筋はやや珍しいことをします。

モデルカードの「additional related assets」行では、技術レポートが aka.ms/frognano-tech-report、ハーネスが github.com/microsoft/FrogNano にリンクされています。aka.msのリンクは PDF を指しておらず、arXiv のアブストラクトページへ直接リダイレクトします。実際のレポートが置かれているのはそこです。一方、GitHub リポジトリには学習コードも RL レシピもチェックポイントも含まれていません。その README 自体が、OpenAI 互換のエンドポイントに対して Kubernetes サンドボックス内でコーディングエージェントを実行する評価ハーネスについて説明しており、学習の経緯については arXiv 論文を参照するよう促しています。つまり、カードの 2 つのアセットリンクは、論文へのポインタと、その論文への返信へのポインタであり、名前は共有されたものなのです。

これは、モデルを使おうと考えている人にとって実用的な理由から重要な点です。文書化されているサービングレシピは SGLang と --reasoning-parser qwen3 および --tool-call-parser qwen3_coder であり、ハーネスはすでにツール呼び出しと推論を話せるエンドポイントを求めます。パース設定を少しでも間違えると、ハーネスが JSON を期待する箇所でモデルがテキストを出力し、外から見ると設定の誤りではなくモデル自体が悪いように見えてしまいます。このカードは、一致するスコアを得るには一致するチェックポイント、トークナイザー、サービング設定、タスク画像、評価プロトコルが必要だと明言しています——つまり、ハーネスが結果の半分を占めるとベンダー自身が認めているのです。

ハードウェアを選定する人には、はっきり言っておく価値もある。モデルカードで評価されたコンテキストにおける9.32 GBのチェックポイントは、9.32 GBの推論問題ではない。評価は、合計約131Kトークン、150ステップの予算で実行された。メモリは重みではなくコンテキストに比例して増える。そしてモデルカードには、最小GPU構成は依然として「リリース前に検証する必要がある」と書かれている。これは、すでにダウンロード可能なモデルに記されている表現だ。

そのトレーニングが実際に何をしたのかを、1段落で

この論文の貢献はモデルではなく、ループである。TaskPilotは実際のリポジトリのスナップショットから候補のソフトウェアエンジニアリングタスクを生成し、現在のチェックポイントからのロールアウトをそれらに対して実行し、ポリシーが時々なら解けるかどうかの境目付近にあるものを保持し、恒久的に自明または恒久的に不可能な候補を破棄する。採用された集合が次のチェックポイントを訓練する。その次のチェックポイントが続くラウンドのタスク生成を調整するので、タスク分布はポリシーが動くにつれて動く。合計でおよそ1,500の検証済み環境。蒸留はない。カードは、エージェント固有のポストトレーニングがより強力なモデルの解答軌跡、行動、推論トレース、パッチターゲットを一切使っていないと明言している。より強力なモデルはタスクを書くが、答えを示すことはない。

マイクロソフトはそのループを5回反復し、統合を一切行う前の時点で8.7ポイントの向上を報告している。実行の途中でログ長ペナルティが追加されたのは、推論トレースが改善の速度を上回って増大していたためだ。

モデルカードは、このアプローチ全体がどこで脆いかについて、異例なほど率直だ。訓練データはPythonが中心で、主に英語である。カードに記載された対応自然言語セットは英語のみで、それ以外は含まれず、ベースモデルのより広範な多言語対応は明示的に主張されていない。性能はハーネスとテストの品質に敏感である。生成されたパッチは「利用可能なテストに合格していても、不正確または安全でない可能性がある」。4Bのモデルカードは、その段落を、すべての読者が心に留めるべき一文で締めくくっている。すなわち、資格のある人間によるレビューと、独立した回帰テストおよびセキュリティテストなしに使用してはならない。これはベンダーが自社の成果物について述べた声明であり、その上にあるどのスコアボードの行よりも有用な一文である。

これで買い手はどうなるのか、そしてルーターはどこに当てはまるのか

FrogNanoは、あなたが呼び出すモデルではない。ファーストパーティAPIも、ホスト型エンドポイントも、サーバーレスイメージも存在しない。これはチェックポイントであり、使うには、Kubernetesでホストされるサンドボックスの背後に独自のSGLangデプロイを立ち上げるか、すでに運用しているエージェントスタック内のコンポーネントとして評価するかのどちらかだ。これが今日の導入経路のすべてであり、どんな発表もその形を変えることはなかっただろう。

ここでルーティングレイヤーが正直にできることは、最初に聞こえるほど大層なものではなく、もっと限定的なことだ。自前でホストするFrogNanoを、自分のハーネス内でホスト型のコーディングモデルと比較する計画なら、ホスト型の側こそ、二つ目の契約ではなく一つのキーの背後に置かれることで恩恵を受ける側だ。OrcaRouterは200以上のモデルを、単一のOpenAI互換エンドポイントの背後に0%のマークアップで提供している。つまり各プロバイダーの定価がそのまま透過的に適用され、ベンダーの価格変更は同じ日に当社側でも反映される。これは、単一のベンチマーク数値ではなく、解決した課題あたりのコストで結果が決まる比較検証にとって重要なことだ。当社はFrogNanoをホストしておらず、その予定もない。重みとサービングの作業はあなたの側のものだ。

それを決着させる3つのこと

まず、独立した再現である。この記事のあらゆる数値——61.5、37.6、31.1、47.3——は、そのモデルを訓練したラボが、同じラボが保守するハーネス上で、同じラボが測定したベースモデルの値に対して算出したものだ。それは完全で内部的に一貫した全体像であり、同時に閉じたループでもある。有用なテストは、利害関係のない誰かが、Microsoft によるタスクセットのキャリブレーション作業なしに、同じ500タスクで39.4から61.5へのジャンプを再現できるかどうかである。

第二に、誰かがハーネスの主張をエンドツーエンドで検証しなければならない。リポジトリは公開されており、これは多くのリリースが成し遂げられていないことだが、それは評価用のリグである。もし5つのツールとサンドボックス分離が本当に性能のメカニズムであるなら、公開された構成を実行する第三者は、公表された数値に近い結果になるはずだ。もしそうならなければ、その差こそが本当の発見である。

第三に、そして答えるのに最もコストがかからない点だが、Microsoft はこれが製品なのか、論文の成果物なのかを明言すべきだ。カードの配布セクションは、重みとカードとハーネスを成果物として扱っており、それは製品リリースというより論文発表のように読める。「Release date 22-SEP-2026」は製品リリースのように読める。発表されたモデルなら、ブログ記事の最初の一文でその曖昧さは解消されていたはずだが、ブログ記事は存在しない。

それまでは、正しい姿勢とはこのリリース自体が示唆するものである。FrogNano-4B-2609 は、実在し、ダウンロード可能で、MIT と Apache、そしておそらくそうではないライセンスのチェックポイントであり、異例なほど詳細なモデルカード、公開された評価ハーネス、本物の方法論的アイデア、そして Microsoft のアドレスを持たない人物が一度も触れたことのないスコアボードを備えている。研究室にとって、それは完結していて興味深い成果物だ。午前三時にエージェントをリポジトリの前に配置しようとしているチームにとって、それは追う価値のある手がかりであり、まだ下す価値のある決定ではない。