AesCode-8B vs North Mini Code：同じライセンス、同じダウンロードボタン、正反対の問題

この対戦で最も有用な数字は15万だ。これは Cohere がNorth Mini Codeに 2026-08-14 時点で付けたダウンロード数であり、モデルが 2026-06-09 にローンチしてから2か月後のことだ。そしてこの数字こそが、AesCode-8Bとの比較を読み解けるものにする。Microsoft がファインチューンしたQwen3-VL-8B-Instructの Hugging Face リポジトリに表示されているダウンロード数は、2件である。どちらも Apache 2.0 で、どちらもゲートがなく、どちらも今日の午後にダウンロードできる。だが一方は四半期にわたって実運用の手に渡っており、もう一方はラボから出ていない。この差は品質の判定ではない——AesCode-8B を独立に測定した者はいないのだから、どちらの側にも得意げになる材料はない——しかしこれが正直な出発点である。どちらに質問できるコミュニティがあるかを教えてくれるのだから。

この2つはまったく異なる形で登場しており、そのことが何を検証できるかを左右する。North Mini CodeはCohereとCohere Labsによるオープンウェイトのリリースで、モデルカードがあり、その背後にはブログ記事があり、ハーネス選定の記録が残り、ローンチ期間中は100万トークンあたり0.00ドルで提供していたベンダー提供APIもある。AesCode-8Bには発表が一切ない。Microsoftは2026-09-29にリポジトリを作成し、2026-10-07 03:35 UTCに「Release AesCode-8B」というメッセージで重みをコミットし、2026-10-08にトレーニングコードをGitHubへプッシュした。Microsoft Researchの投稿も、リリースノートも、製品ページもなく、引用行には「査読中」と書かれ、年はプレースホルダーの2027になっている。8Bモデルはスライドデッキ、ポスター、ダッシュボードをHTMLとCSSとして出力する。North Mini Codeはエージェントハーネスの中でコードを書く。両者は競合というより、カタログの中の隣人であり、それ自体が一種の発見だ。

それぞれが何を出力するよう訓練されたか

この二つが同じ役割を果たしていないことを最も明快に見て取る方法は、それらから出てくるものを見ることです。

• 出力 — AesCode-8B：完全な HTML と CSS のドキュメントで、リクエストごとに 1 ページをレンダリングします。North Mini Code：テキストとツール呼び出し。実際にはパッチ、シェルコマンド、エージェントの軌跡を意味します。

• サイズ — AesCode-8B：8.8B bf16 の密なモデルで、合計17,543,339,408バイトの4つのsafetensorsシャードに分かれています。North Mini Code：総パラメータ数30B、アクティブパラメータ3B、128のエキスパートを持ち、トークンごとに8つがアクティブなスパースMixture-of-Expertsです。

• コンテキスト — AesCode-8B: 報告されている構成では24,576トークン、トレーニング時のプロンプトとレスポンスはそれぞれ最大8,192。North Mini Code: 入力256K、最大生成64K。

• 入力 — AesCode-8B：テキストと任意の参照画像。North Mini Code：テキストのみで、それ以外はすべてハーネスが提供します。

• トレーニング: — AesCode-8B: 3,000件のコールドスタートデモンストレーションを行い、その後、7,408件のプロンプトに対して400ステップのGDPO強化学習を実施。各候補をサンドボックス化されたブラウザでレンダリングした後、6つの決定論的検証器と視覚的ルーブリックで採点。North Mini Code: エージェントハーネス — SWE-Agent、mini-SWE-Agent、OpenCode、Terminus 2 — に対応しているため、既に使っているどのハーネス内でも動作し、特定の1つに縛られることはありません。

• ライセンス — いずれもApache 2.0、重みも含まれ、用途分野の除外規定もなく、コントリビューター階層もない。この軸において両者は同一であり、これでは何も決まらない。

• 根拠 — AesCode-8B：マイクロソフト自身による300サンプルのインフォグラフィック評価基準で、再現されていない。North Mini Code：ベンダー公表値に加え、独立した測定値。

証拠の非対称性は、見た目よりも小さい

この比較の東側にはアウトサイダーが含まれており、それはベンチマークの差以上の価値がある。Artificial AnalysisはNorth Mini Code自体を実行し、Coding Indexで33.4、Intelligence Indexで27.6と採点している — 同程度の規模のオープンモデルと互角か、それを上回る。CohereはSWE-Bench Verifiedで61.0%のpass@1、MistralのDevstral Small 2の最大2.8倍の出力スループットを報告しているが、いずれもベンダー公表値だ。独立した実行こそがその落とし穴を突き止めた。North Mini Codeは同じベンチマークスイートを完了するのに、同規模クラスの中央値の約3倍の出力トークンを生成する。約7,500万〜7,700万出力トークンで、中央値は2,500万〜3,800万だ。ローンチ期間の価格がゼロのため、現金コストはかからない。犠牲になるのはレイテンシで、プロモーション料金が終わった後の請求額を先取りして見せている。

AesCode-8B には、測定の外側に相当するものがない。Microsoft は、自社の300サンプルのインフォグラフィック評価で Overall 82.94 を報告しており、プロンプトごとに3回生成し、選別は行っていない。これは参照条件付きの GPT-5.5 の 81.28 と Claude Opus 4.8 の 80.39 を上回り、自身のバックボーンを 31.1 Visualポイント上回っている。また、参照条件付き報酬によって、プロンプトのみの Visual が 25.17 から 69.71 に引き上げられたこと、推論時に参照画像を渡さない場合にモデルが失うのはわずか 1.00 Visualポイントで、バックボーンでは 19.55 であることも報告している。これらは極めて具体的な主張であり、ハーネスはオープンソース化されている。これはほとんどのベンダーの表が示す以上のものである。しかし、そのいずれも誰にも再現されていない。アリーナの掲載も、リーダーボード上の順位も、スループット測定も、ルーブリックに対する第三者による検証もない。

特にこの比較にとってそれが何を意味するかに注意してください。共通の数値は存在しません。一方のモデルは、ソフトウェアエンジニアリングのタスクが合格するかどうかと、それらが何トークンを消費するかで評価されます。もう一方は、インフォグラフィックのテキストが読みやすいままでいるか、そのレイアウトがキャンバス内に収まるかで評価されます。33.4 を 82.94 の隣に並べることは、コーディング指標とインフォグラフィックの総合スコアを比較していることになります。

それぞれがどこにデプロイされ、それにいくらかかるのか

North Mini Code のデプロイ実績こそが、ダウンロード数 15 万件を突破した理由だ。3B アクティブの MoE はおよそ 20～24 GB のメモリに量子化され、Cohere のチームは MLX を通じて Mac Studio 上でそれを実演し、3B のアクティブフットプリントがローカル推論を経済的にしている。フル精度なら単一の H100 で動作する。Cohere はローンチ期間中、100 万入力トークンおよび出力トークンあたり $0.00 で提供しており、本番規模向けに管理されたインスタンス単位のデプロイルートも用意している。この数字自体は Cohere 自身の数値で、すべての配布チャネルを集計したものであり、プラットフォーム別の内訳はなく、公開されている Hugging Face の月間数値は一桁小さく、これは集計値が API、ホスト型ゲートウェイ、パッケージマネージャー、ローカルでの取得にまたがっていることと整合する。テレメトリーではなく勢いとして読むべきだ。

AesCode-8Bのデプロイの話はコマンドライン一つだ。カードがそれを直接示している——vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576、そしてtransformers 4.57以降が必要だ（非vLLM経路の場合）。bf16の重み17.5 GBが、24,576トークンと最大2枚の画像分のKVキャッシュと並んで載るため、単体の24 GBカードでも技術的には足りるが、実際にはぎりぎりだ。現実的な最低ラインは40〜48 GBになる。著者らと同じ方法で出力を採点したいなら、レンダリングスタックを追加しよう。このモデルに関するあらゆる品質上の主張は、外部リクエストをブロックしたブラウザでそのHTMLをレンダリングしてなされたものだからだ。我々が見つけられるホスト型エンドポイントは存在せず、当社のカタログにも入っていない。

その最後の点は、これら2つを可用性で比較する人にとって実用的な点です。North Mini Codeは、ベンダー自身のAPIや複数のサードパーティプラットフォーム、さらには重みそのものを通じて利用できます。AesCode-8BはHugging FaceとGitHubにしか存在しません。もしあなたの制約が「明日、サービスからこれを呼び出せる必要がある」というものなら、この2つのうち「はい」と答えるのは1つだけです。

どちらのモデルも解けない構成の問題

この比較のどちらの側にも罠があり、しかもそれは同じ罠だ。どちらかを採用するということは、専門特化モデル用のセルフホスト型サービング経路を維持することを意味する。AesCode-8Bを適切に評価するには、マルチモーダルスタックとレンダラーが必要だ。North Mini Codeには、3B-active MoE用のスロットと、その周囲のエージェントハーネスが必要であり、その冗長さゆえに、トラジェクトリのコストはトークン数が示唆するよりも高くつく。ページジェネレーターとリポジトリエージェントという両方の能力を求めるチームは、今や2つの推論デプロイを運用しており、どちらでもないあらゆるもののために、3つ目も運用している。

多くのモデルの前に置かれた単一のエンドポイントが単なる便利機能ではなく実際に仕事をこなすのは、そういうケースだ。経済性とデータの扱いがそれを正当化するなら、専門特化モデルは自社のハードウェアに置き、定型的なトラフィックは今週それに最適なホスト型モデルへルーティングする。そのすべてを1つのキーの背後で、プロバイダーの定価を0%のマークアップでそのまま通し、プロバイダーが不安定になれば自動的にフェイルオーバーする。Qwen3ファミリーのバックボーンは、その境界がどれほど薄くなるかをよく示している。MicrosoftはQwen3-VL-8B-InstructをベースにAesCode-8Bを構築したが、このファミリーの視覚言語モデルはOrcaRouter経由で呼び出せる——Qwen3-VL-8B-Instructは131,072トークンのコンテキストで入力100万トークンあたり$0.18、出力$0.70、Qwen3-VL 235B A22Bは$0.40と$1.60だ。どちらもAesCode-8Bではない。このファインチューンはMicrosoftのもので、どのプロバイダーも提供していない。しかし、それに求めていたものがスクリーンショットを読んでコードを書くモデルであり、美的デザインのファインチューンが特に必要ではなかったのなら、呼び出し可能な選択肢はGPUのごく一部のコストで済み、調達サイクルではなく午後ひとつで試せる。

どちらも汎用ではないということを踏まえると、どうやって決めればよいのでしょうか。

まずライセンスはテーブルから下ろそう。それは引き分けであり、何も決めることにはならないから。

出力を何にしたいのかを問いかけよ。答えがレンダリング済みで編集可能なページ——デッキ、レポート、ダッシュボード——なら、North Mini Code は役に立たず、AesCode-8B だけが二者のうちその問題に照準を合わせている。冷静に現実を見据えて臨め：予告されていない研究チェックポイント、2 つのダウンロード、単一のインフォグラフィックページでのみ検証された 24K コンテキスト、英語のみの言語タグ、そしてどこにも独立した評価がない。Microsoft 自身の表における Style の上限は、納品前にこれ以上の視覚的修正を必要としないと定義された次元で 53.21 であり、これはベンダーが、人間が依然として出力を編集していると告げているということだ。

もし答えがリポジトリへの変更——移行、修正、複数ステップのターミナル作業——であるなら、North Mini Code はハーネス訓練、256K ウィンドウ、3B アクティブのデプロイプロファイル、機能するベンダー API、そしてその品質と冗長性の両方に関する外部測定を備えたものだ。見出しの料金ではなくトークン数で予算を組め。なぜなら、独立した調査結果によれば、同じ地点に到達するために、同業他社の約3倍も書くからだ。

そして、あなたの四半期に設計成果物とリポジトリ移行の両方が含まれているなら、これを2モデルの判断として扱ってはいけない。スペシャリストはそのGPUに見合うところで走らせ、残りはルーティングし、必要のないサービングパスを維持するのはやめよう。

ベンチマークを超えて長く残る違い

最後にこの2つを分けるものがあり、それは技術的なものではない。North Mini Codeには、カード、投稿、試せるSpace、そして異論を唱えられる方法論を公開したベンダーがあり、さらに15万ダウンロード分に相当する他の人々の経験がある。AesCode-8Bには、リポジトリとREADME、そして「査読中」と書かれた引用がある。

それによって、そもそも未解決の問いが何なのかさえ変わる。North Mini Code の場合、今まさに問われているのは、プロモーション料金が終わった後、その冗長さゆえに大規模運用では採算が取れなくなるかどうかだ。そしてそれは実際に動かせば答えを出せる。すでにほかの大勢の人たちがそうしているからだ。AesCode-8B の場合、今まさに問われているのは、Microsoft がそれをどうするつもりなのかだ。研究用の成果物なのか、製品ラインの最初のリリースなのか、それとも6週間でひっそりと取って代わられる何かなのか。リポジトリのどこにもその答えはなく、モデルカードをどれだけ読んでも答えは出ない。3つのシグナルに注目してほしい。公式発表、82.94の独立再現、あるプロバイダーがそのチェックポイントを採用すること。そして3つすべてが欠けていることを、このモデルが面白くない理由ではなく、現時点での証拠の状態として扱うべきだ。これが面白い理由は、1.00ポイントの参照値の低下であり、その数字は依然としてそこにあり、Microsoft 以外の誰かが検証するのを待っている。