AesCode 32B vs North Mini Code：重みファイルはコミットメントではない

これらのモデルはどちらも Apache 2.0 で、どちらもダウンロード可能であり、どちらも狭い用途向けに作られている。そして、類似点が役に立たなくなるのはまさにそこだ。AesCode 32Bは、編集可能な HTML と CSS を生成するための Microsoft の研究用チェックポイントだ。スライド、ポスター、ダッシュボード、レポートなどが対象となる。その Hugging Face リポジトリは2026年9月29日に作成され、「Release AesCode-32B」というタイトルのコミットは2026年10月7日に反映された。Microsoft は発表を一切行っておらず、モデルカードにはリリース日すら記載されていない。North Mini Codeは、Cohere のオープンウェイトのエージェント型コーディングモデルで、30B の Mixture-of-Experts、アクティブパラメータ数3B、2026年6月リリース、ソフトウェアエンジニアリングとターミナル作業を対象としている。両者を比較する明白な方法はベンチマークで行うことだが、それはうまくいかない。なぜなら、この2つは同じタスクで測定されたことが一度もなく、自らのラボの外の誰かによって測定されたのは、そのうち片方だけだからだ。実際に機能する比較、つまりどちらかを実際に動かせるかどうかを決める比較は、重みファイルだ。

二つのチェックポイント、二つの大きく異なる請求額

これはほとんどの比較が見落とす軸であり、2つのセルフホスト型モデルにとっては、最も重要となる軸です。

• パラメータ — AesCode 32B: 33B、Dense。North Mini Code: 合計30B、アクティブ3B、Mixture-of-Experts。

• 実行に必要なメモリ — AesCode 32B：このカードは、bf16 パラメータだけでもアクセラレータメモリをおよそ 65 GB 確保する計画を推奨しています。North Mini Code：量子化済みで、およそ 20–24 GB あれば十分であり、リファレンスデプロイには Mac Studio も含まれます。

• サービング形態 — AesCode 32B：視覚言語モデルであるため、サービング経路ではテキストだけでなく画像も扱い、その独自の例では4-wayテンソル並列を使用している。North Mini Code：テキスト入力、テキスト出力。ベンチマークでは単一のターミナルツールを使用した。

• ライセンス — 両者ともApache 2.0で、重みも含まれる。この項目は引き分けであり、世間が想定するほどの差別化要因ではない。

• コンテキスト — AesCode 32B：報告された構成では24,576トークン、トレーニング時のプロンプトと応答は8,192に制限。North Mini Code：入力256K、出力64K。

• 何を出力するか — AesCode 32B：完全な HTML ドキュメント、表は HTML テーブル、チャートは ECharts のスペックとして出力。North Mini Code：ハーネスが要求したテキストまたはツール呼び出しをそのまま出力。

• 独立評価 — AesCode 32B：公開されたものはなし。すべての数値は Microsoft のもの。North Mini Code：Artificial Analysis でスコア評価され、その冗長性も指摘された。

2行目を2回読んでください。65GBと4-way並列を必要とする32Bのdense視覚言語モデルは、量子化すればワークステーションに収まる3BアクティブのMoEとは、調達判断が異なります。オープンウェイトを検討する理由が「これを自前のハードウェアで動かしたい」だったなら、その行は、プロンプトを1つも実行する前に、すでに答えの大部分を占めています。

ライセンスは、どちらを選ぶ理由にもならない。

オープンウェイトの比較はほぼ必ずライセンスの話から始まりますが、ここではそれは行き止まりです。両方とも Apache 2.0 で、どちらも完全なウェイトを提供しており、商用展開を妨げるような使用制限はどちらにもありません。割引と引き換えに検討すべきデータ共有条項も、コントリビューターティアも、用途分野の除外規定もありません。この2つのどちらを選ぶにしても、その判断材料は許諾条件ではありません。

ライセンスの話を脇に置いたとき残るのは、そのモデルが訓練によって行うようになったことだ——そしてこの二つは正反対の方向に訓練されている。

一方はターミナルで、もう一方はキャンバスでトレーニングされた

North Mini Codeのモデルカードは、その対象をずばり明言している。コード生成、エージェント型ソフトウェアエンジニアリング、ターミナルタスクだ。Cohereは、SWE-Agent、mini-SWE-Agent、OpenCode、Terminus 2 といった複数のエージェントハーネスでこれを訓練し、とくに、すでに使っているどれの中でも動作するようにしている。また、SWE-Bench Verified、SWE-Bench Pro、Terminal-Bench v2、Terminal-Bench Hard で評価した。公表された弱点は現実のもので、ベンダーが自ら進んで明かしたのではなく、外部の評価者によって見つかった。同サイズクラスの中央値のおよそ3倍の出力トークンを生成するのだ。冗長なモデルは長いエージェント軌跡を書き、長い軌跡こそが、プロモーション価格が終わった後に支払うことになるものだ。

AesCode 32B はまったく別のものを対象に学習されており、そのカードには、ターゲットが成果物であることが異例なほど明確に記されている。この設計の狙いは、コードモデルがキャンバス上でレイアウト、階層、色がどのように一体となるかを認識できない点にある。そこで AesCode は、同じプロンプトから生成した画像を美的リファレンスとして用いつつ、コンテンツの信頼できる唯一の情報源（source of truth）としてプロンプトを維持する。教師信号は、ノードとエッジからなる「デザイングラフ」であり、7つの報酬チャネル——実行、テキスト、境界、表/グラフ、レイアウト、余白、デザイン——のうち、6つは決定論的検証器、1つはサンプルごとのルーブリックに基づいて動作する視覚言語ジャッジである。候補は、外部リクエストをブロックしたサンドボックス化 Playwright ブラウザでレンダリングされ、DOM、計算済みスタイル、バウンディングボックス、スクリーンショットに基づいて採点される。

その仕組みは、ただ一つのことを成り立たせるために存在する。出力は、人間が開いて編集するレンダリング済みのページであり、リポジトリに適用されるパッチではない。AesCode 32B はシェルの使い方を訓練されたことがなく、報酬設計のどこにも、試みることに対して報酬を与えるものはない。

正直に述べられた証拠の非対称性

North Mini Codeは第三者によって実行された。Artificial Analysisは、Coding Indexで33.4、Intelligence Indexで27.6と採点し、冗長性に関する調査結果を公開している。Cohere自身が掲げる看板数値——SWE-Bench Verifiedでのpass@1 61.0%——はベンダー報告だが、誰でもダウンロードできるモデルに対して検証可能であり、さらにモデルカードはそのハーネス選択について率直で、Terminal-Bench Hardでは比較の公平性を保つためArtificial Analysis自身の方法論に従ったとまで記している。

AesCode 32B に匹敵するものは存在しない。その300サンプルのインフォグラフィック評価は、プロンプトごとに3回生成し、選択を行わない方式で、GPT-5.5 の81.28、Claude Opus 4.8 の80.39に対して、総合スコア85.89を出す——すべて Microsoft のハーネス内で、Microsoft のサンプル上で、Microsoft がモデルを訓練する相手とした採点チャネルを使って測定されたものである。数字が公正である実際の可能性はある。この設計はほとんどのベンダー表より透明性が高く、検証スタックとルーブリックビルダーはオープンソース化されており、カードは、比較対象のどのモデルもスタイル次元で60をクリアしていないという事実を公表している。しかし、外部の研究所はそのいずれも再現しておらず、アリーナへの掲載も、リーダーボードでの順位も、独立したスループットテストも存在しない。もし、たまたまベンダー自身のベンチマーク——インフォグラフィックタスク——に有利なベンダー製ベンチマークが、あなたの意思決定で大きな役割を果たしているなら、あなたは、利用可能な唯一の読み方をそのまま受け入れるよう求められている。

この対決にとってこれが具体的に何を意味するかに注目してほしい。共通の数値は存在しない。まったくない。一方のモデルはソフトウェアエンジニアリングのタスクに合格するかどうかで採点され、もう一方はテキストが判読可能か、レイアウトがキャンバスからはみ出さないかで採点される。33.4 を 85.89 の隣に並べるページは、Coding Index とインフォグラフィックの Overall スコアを比較しているのであり、どちらのモデルも相手が何をテストされたのか知らない。

どちらも汎用モデルではなく、それこそが本当のコストだ

この比較のどちらの半面にも罠がある。どちらのモデルを採用するにも、専門特化型のためにセルフホスト型のサービング経路を維持することを意味する。ページをレンダリングする方には65 GBのVRAMとマルチモーダルスタック、ターミナルタスクを処理する方には3B-active MoE用のスロットだ。どちらも自分の仕事は得意で、互いの仕事はできない。つまり、両方の能力を求めるチームは今や2つの推論デプロイを運用しており、その中間にあるすべて、ページレンダラーでもターミナルエージェントでもないモデルのために、3つ目を運用しているのだ。

ルーティング層が後付けではなく、その地位を正当に得るのは、まさにこういうケースだ。プロバイダーの定価、マークアップなしで200以上のモデルを1つのキーで扱えるということは、専門的な作業は、経済性とデータの扱いが理にかなう自社ハードウェア上にとどまり、定型作業はその週に最適なホスト型モデルに回されるということだ。Qwen3-VLバックボーン・ファミリーは、その境界線がいかに薄いかをよく示している。MicrosoftはQwen3-VL-32B-InstructをベースにAesCode 32Bを構築したが、そのファミリーの視覚言語モデルはOrcaRouterのカタログで呼び出し可能だ — Qwen3-VL 235B A22B Instructは入力トークン100万あたり$0.40、出力$1.60、あるいはより小型のQwen3-VL 8B Instructは$0.18と$0.70。これらのどちらもAesCode 32Bではない。ファインチューンはMicrosoftのもので、どのプロバイダーも提供していない。しかし、AesCode 32Bに求めていたものが、スクリーンショットを読み取ってコードを書くモデルであり、美的デザインのファインチューンが特に必要ではなかったのなら、呼び出し可能な選択肢は存在し、GPUのほんの一部のコストで済む。同じエンドポイントの下での自動フェイルオーバーが、それを試してみることと、本番経路をそれに賭けることの違いなのだ。

実際にどうやって決めるか

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

次に、出力をどうしたいのかを問いましょう。答えが、レンダリングされた編集可能なページ——デッキ、レポート、ダッシュボード——であるなら、North Mini Code は役に立てず、この2つのうち問題に照準を合わせているのは AesCode 32B だけです。65 GB、24K コンテキスト、独立した評価が存在しないこと、そしてこれがダウンロード数2桁の未発表モデルであるという事実を、冷静に見据えて臨みましょう。これは研究用リリースであり、研究用リリースは、好奇心を持てる余裕のあるチームに報いてくれます。

答えがリポジトリへの変更——マイグレーション、修正、複数ステップのターミナル作業——であるなら、North Mini Code こそが、ハーネス訓練、256K ウィンドウ、3B アクティブのデプロイプロファイル、そしてその品質と冗長性の両方についての外部測定を備えたものだ。見出しのレートではなく、トークン数で予算を組め。

そして、今四半期のやることリストにデザイン成果物とリポジトリ移行の両方が入っているなら、それが実際には6モデル分の意思決定なのに、これを2モデル分の意思決定として片付けてはいけない。元が取れるところでは特化モデルを走らせ、残りはルーティングせよ。

未発表モデルの問題

最後にもう 1 つ、この 2 つを分けるものがある。それは技術的なことではない。North Mini Code の背後には、モデルカード、ブログ記事、試用できる Hugging Face Space、そして反論できるベンチマーク手法の記録を公開したベンダーがいる。AesCode 32B には、リポジトリ、README、そして「Under review, 2027」と書かれた引用行がある。Microsoft はそれが存在するとは言っていない。

それは、あなたがそれを採用できるようになると変わる。North Mini Codeについては、未解決の問いは、その冗長さが大規模運用では不経済になるかどうかだ——それは実際に動かせば答えが出る問いである。AesCode 32Bについては、未解決の問いは、マイクロソフトがそれをどう扱うつもりなのかだ。すなわち、これが研究用の成果物なのか、製品ラインの最初のリリースなのか、それとも6週間後に70B版へ静かに置き換えられるものなのか。リポジトリのどこにもその答えはなく、モデルカードをどれだけ読んでも分からない。三つのシグナルに注目してほしい——公式発表、85.89の独立再現、推論プロバイダーによるチェックポイントの採用——そして、三つすべてが欠けていることを、モデルが面白くない理由ではなく、現時点の証拠の状態として扱ってほしい。