AesCode 32B vs Muse Code：ポスターエンジンとターミナルエージェントはライバルではない

AesCode 32BとMuse Codeが比較されるのは、どちらの名前に「code」という語が含まれているからであり、そしてそれは両者に共通するほぼ唯一の点でもある。AesCode 32Bは、編集可能なHTMLとCSS——スライド、ポスター、ダッシュボード、レポート——を出力するためのMicrosoftの研究用チェックポイントで、Apache 2.0の下でHugging Faceに公開されている。リポジトリが作成されたのは2026年9月29日で、「Release AesCode-32B」という名前のコミットの日付は2026年10月7日である。Microsoftはこれについて何も発表していない。ローンチ記事もプレスリリースもなく、モデルカード自体にもリリース日は記載されていない。Muse Codeはモデルですらない。Metaのターミナルコーディングエージェントであり、2026年8月初旬からベータ版として、リポジトリに対してシェルコマンドを実行することに時間を費やしている。一方はブラウザで開くファイルを生成する。もう一方はテストが通るまでコマンドを実行する。両者のどちらを選ぶかはモデルの選択ではなく、このページにできる有益なこととは、あたかもそうであるかのように選んでしまうのを止めさせることだ。

それぞれが実際に何のためのものか

AesCode 32BはQwen3-VL-32B-Instructから出発し、モデルカードによれば、3,000件のデモンストレーションに対するコールドスタートの教師ありファインチューニングに続いて、7つの報酬チャネル——実行、テキスト、境界、表/グラフ、レイアウト、空白、デザイン——にわたるGDPO強化学習で訓練されている。これらのチャネルのうち6つは決定論的検証器であり、7つ目は対象ページの「デザイングラフ」に紐づくサンプルごとのルーブリックに基づいて動作する視覚言語審査員である。各候補出力は、外部リクエストをブロックしたサンドボックス化されたPlaywrightブラウザでレンダリングされ、その後、DOM、計算済みスタイル、バウンディングボックス、スクリーンショットから採点される。想定される出力はカードに明記されている。編集可能なスライド、ポスター、ダッシュボード、レポート、さらにマルチモーダルコード生成に関する研究である。モデルは完全なHTMLドキュメントを出力し、その出力が検査可能なままであるように、実際のHTMLテーブル構造とECharts仕様を使用するよう訓練されている。

Muse Codeは構造的に異なることをしている。macOSとLinux向けのネイティブバイナリであり、メインエージェントループ、セッションを通じてコンテキストを収集し続ける非同期バックグラウンドエージェント、サブエージェント同士が衝突しないようにする分離されたGitワークツリー、そしてクラッシュしたセッションを再生または再開できるローカルイベントログを備えている。Meta自身の報告では、数時間単位の期間にわたって数千のツール呼び出しを書き込んでいるとされている。売られているものは成果物ではなく、ループそのものだ。

二つを並べてみると、動詞が一致しない。AesCode 32B はレンダリングする。Muse Code は実行する。もしあなたの問題が「四半期ごとのプレゼン資料の作成にデザイナーが3日かかる」ことなら、Muse Code は無関係で、AesCode 32B はまさにそこを狙っている。もしあなたの問題が「誰も週末を費やしてこの依存関係ツリーをアップグレードしたくない」ことなら、AesCode 32B には何も言うことがなく、Muse Code がそのツールだ。

双方の側の証拠は、同じ種類の証拠ではない。

ここはどの比較ページも間違えてしまう部分なので、時間をかけて丁寧に見る価値があります。

AesCode 32Bの数値は300サンプルのインフォグラフィック評価に由来し、プロンプトごとに3回生成して選別は一切行っていない。それ自体として見ても印象的だ。総合スコアは85.89で、GPT-5.5の81.28、Claude Opus 4.8の80.39に対するものだが、これら2つはいずれもMicrosoft自身のハーネスによって同じ参照画像設定で測定されている。このカードはまた、重大なキャンバス境界障害がサンプルの4.3%で再発するのに対し、GPT-5.5では34.7%であること、そしてAesCode 32Bが自身のQwen3-VL-32BバックボーンをVisual次元で22.4ポイント、総合で24.8ポイント上回ることも報告している。

あれはすべて、ベンダー報告かつ未再現のものとして読め。ベンチマークも、モデルを訓練した報酬チャネルも、それを採点する指標も同じラボの仕事であり、300 サンプルは Microsoft のものだ。それはこの結果を切り捨てる理由にはならない——評価は異例なほど透明で、検証器スタックは公開されており、どのモデルも 60 を超えない次元（「style」、そこでは何も 55.99 を上回らない）をカードが公表していることは、ほとんどのベンダー表が備えている以上の誠実さだ。それは、別のラボが別のタスクで出した数字の隣に 85.89 を並べて、比較が行われたかのように装わないための理由である。

Muse Code の数値もまた、別の意味で Meta が報告したものである。それらはモデルとハーネスをまとめて測定している。Meta は Muse Code について、Terminal-Bench 2.1 で 82.9% と報告しており、Claude Code と組み合わせた Claude Opus 5 の 86.7% に次いで 2 番目で、さらに DeepSWE 1.1 で 59.3%、社内コーディングベンチで 70.6% としている。その表では異なるハーネスが異なるモデルと組み合わされているため、システムのスコアからモデルの寄与を読み取ることはできない。そして、Muse Code が測定される対象と AesCode 32B が測定される対象の間には、まったく重なりがない。一方はターミナルタスクとソフトウェアエンジニアリングで採点され、他方はインフォグラフィックのテキストが判読可能か、そのレイアウトがはみ出さないかで採点される。

「1つの32Bチェックポイント」が隠しているもの

デプロイこそ、この2つの製品が最も大きく分かれるところであり、手短に言えば箇条書きに収まる。

• 概要 — AesCode 32B：ダウンロードする33Bパラメータのモデルチェックポイント。Muse Code：インストール可能なターミナルエージェント製品。

• ライセンス — AesCode 32B: Apache 2.0、ウェイト同梱。Muse Code: プロプライエタリ。その基盤となるモデルは非公開。

• あなたが用意するもの — AesCode 32B: GPU とサービングスタック。Muse Code: API キーまたはサブスクリプション。

ハードウェアの最低ライン — AesCode 32B：そのカードでは、bf16 パラメータだけで約 65 GB のアクセラレータメモリを見込むよう勧めており、自身のサービング例では 4-way テンソル並列を使用している。Muse Code：ラップトップ。

• コンテキスト — AesCode 32B：報告された構成では24,576トークンで、RLトレーニング中はプロンプトと応答が8,192に制限されます。Muse Code：その下にあるMuse Sparkモデルによる100万トークンのウィンドウ。

• 価格 — AesCode 32B：重みは無料。コストはハードウェア。Muse Code：トークン単位の課金、または月額プラン。

• 根拠 — AesCode 32B：自社の300サンプルに対してベンダー自身が実施した評価で、ハーネスも公開されている。Muse Code：エージェントとモデルを組み合わせたスタックについてMetaが報告したシステムレベルのベンチマーク。

あの「ハードウェアの下限」の行こそ、多くの人が飛ばしてしまう行だ。bf16の32Bチェックポイントはラップトップで動かせるモデルではないし、AesCode 32Bはその上さらに視覚言語モデルなので、サービング経路は画像入力も扱う。Muse Codeは午後だけでインストールできるバイナリだ。

それらが真に重なる場合

実際に重なっている部分はただ一つだけで、しかもごく狭い範囲に限られます。どちらも、デザインに近い成果物を指定して、人間が手を加えて仕上げることを前提とした何かを生成させることができるからです。たとえば、チームが社内ダッシュボードをコードとして生成していて、さらにダッシュボードのリポジトリに対してプルリクエストを開けるエージェントも欲しいと考えているなら、どちらの製品もそのワークフローに触れることになります。

そこでも分担は明確だ。AesCode 32B は成果物を生成する。Muse Code は変更を生み出す。両方を行うパイプラインなら、AesCode 32B を呼び出してレンダリングし、次に得られたファイルをエージェントに渡して配置、接続、テストを行うだろう——そして、どちらの製品にもそれを妨げるものはない。なぜなら、両者は同じ枠を争っていたわけではないからだ。

今日予想できる、この対戦カードの半分

ここに、率直に述べておく価値のある実践的な非対称性がある。AesCode 32B は、どの推論プロバイダーによってもデプロイされていない。Hugging Face のカードには、ホストされたエンドポイントも、パートナーも、API も記載されていない。使いたいなら、65 GB の重みをダウンロードし、サービング経路を自分で構築することになる。これは研究リリースとしては普通の状態であり、8 台の GPU を持たない人々とこのモデルの間に立ちはだかる最大の要因でもある。

Muse Code の基盤モデルにはその問題はありません。Muse Spark ファミリーはプレーンな API モデルとして提供されており、Muse Spark 1.2 は OrcaRouter のカタログに掲載されていますそこでは Meta の定価、入力トークン 100 万あたり $1.25、出力トークン 100 万あたり $4.25 で課金されます。プロバイダーの定価をそのまま通す形で、当社側でのマークアップはありません。そのため Meta の価格変更は、先方に反映されたその日にここにも反映されます。1 つのキーで、ほか 200 以上のモデルとあわせてこれを使え、プロバイダー側に不調があれば自動フェイルオーバーが働きます。これが「試しに使ってみる」と「本番経路に載せる」の違いです。このページに実際に求めていたのが、Muse Code 製品を採用せずに Muse Code の中の知能を使う方法だったのなら、それがそのルートであり、それは存在します。求めていたのが AesCode 32B だったのなら、そのルートはダウンロードです。

どちらを選ぶか

成果物そのものが目的なら、AesCode 32B を選べ。大量のデッキ、レポート、ポスター、ダッシュボードを制作していて、ハードウェアを持っているか、それをレンタルする意欲があり、構造化された編集可能な HTML を出力するモデルの魅力 — 表は表のまま、チャートは ECharts の仕様として、すべて Git で差分可能 — が研究グレードのサービング構成に値するなら。未発表でダウンロード数が少ないモデルのアーリーアダプターであること、独立系ラボがそのスコアを再現していないこと、そしてその 24K コンテキストが長い文書にとって現実的な制約であることを受け入れよ。

プロセスそのものが目的なら、Muse Code を選びましょう。ターミナルで動作し、セッション途中のクラッシュにも耐え、複数のワークストリームを分離されたワークツリー内で同時に保持できるエージェントを求めていて、そのためにトークン単位または月単位で支払うことに抵抗がないなら。

どちらも選ばず、必要だったのがAPIキーの背後にある高性能な推論モデルで、ターミナルのハーネスなどそもそも求めていなかったのなら、Muse Spark 1.2へ直接ルーティングしてください。

何がこのページを変えるのだろうか

3つのこと。推論プロバイダーがAesCode 32Bを採用するか、あるいはMicrosoftがホスト型エンドポイントを公開すれば、導入の列は崩れ、そのモデルは午後のひとときで評価できるものになる。そうなればデザイン重視のチームにとって、これはずっと僅差の問いになる。独立した評価が85.89 Overallと4.3%の境界失敗率を再現すれば、証拠の非対称性はかなり縮まる。そしてMetaがMuse Sparkの重みを公開すれば、「片方はダウンロードでき、もう片方はできない」という枠組みは完全に消える。それらのどれかが起こるまでは、正直な要約はこうだ。この2つの製品は同じ言葉を共有しているだけで、同じ仕事を共有しているわけではない。