AesCode-8Bがひっそりと登場：Microsoftの8BモデルがスライドやダッシュボードをHTMLとして生成

マイクロソフトの新リリースで最も興味深い数字は1.00である。参照画像をAesCode-8B——スライドやポスター、ダッシュボードを編集可能なHTMLとCSSとして書き出す80億パラメータのモデル——から伏せると、その視覚スコアは100点満点中1点下がる。同じ参照画像をQwen3-VL-8B-Instruct——AesCode-8Bがファインチューニングの元にしたオープンウェイトモデル——から伏せると、下落幅は19.55点となる。GPT-5.5では10.04点である。実際の研究成果が宿っているのはこの一つの比較であり、それはマイクロソフトが同時に公表した見出しの下に横たわっている。自社の300サンプルのルーブリックにおいて、AesCode-8Bの総合スコア82.94は、参照条件付きのGPT-5.5の81.28、Claude Opus 4.8の80.39をわずかに上回り、より大きな兄弟モデルであるAesCode-32Bは85.89となっている。

このリリースについて公表されたものは何もない。マイクロソフトは2026-10-07にHugging Face上でApache 2.0の下で重みをコミットし — AesCode-8Bと、同じ方法でQwen3-VL-32B-Instructから構築された32Bのコンパニオン — 翌日にはトレーニングと評価のコードをGitHubにプッシュした。Microsoft Researchのブログ記事も、リリースノートも、製品ページも、プレプリントも存在しない。モデルカードの引用には「Under review」、年は2027と書かれており、これは日付ではなくプレースホルダーだ。2026-10-11時点で、8Bリポジトリはダウンロード数2、いいね1を示しており、GitHubリポジトリはスター1を示している。以下で数値を伴うものはすべて、自分で検証できるタイムスタンプか、マイクロソフトが自社の評価セットについて報告した数値のいずれかである — そしてこの区別はここではいつも以上に重要だ。なぜなら、このモデルのどの部分も他の誰かによって測定されていないからである。

出荷されたもの、そして箱に入っていないもの

このリリースを規定する日付は3つあり、それがこのリリースに含まれる唯一の日付である。Hugging Face のmicrosoft/AesCode-8Bリポジトリは2026-09-29に作成され、重みは2026-10-07 03:35 UTC に「Release AesCode-8B」というメッセージでコミットされ、microsoft/AesCodeコードリポジトリはその翌日、2026-10-08 23:14 UTC に公開された。32B の重みも同じコミットの時間帯に投入された。その間のことはどこでも一切発表されなかった。

• Weights — 4つのsafetensorsシャード、合計17,543,339,408バイト。これはおよそ88億のbf16パラメータに相当します。Microsoftはこのモデルを8Bと表記しており、Hugging Faceのsizeフィールドでは9Bに丸められています。これは食い違いではなく、丸めによるものです。

• アーキテクチャ — Qwen3-VL レシピをそのままファインチューニングしたもの: Qwen3VLForConditionalGeneration、36 個の隠れ層、隠れサイズ 4,096、8 個のキー・バリューヘッドを備えた 32 個のアテンションヘッド、151,936 トークンの語彙、およびインターリーブされた mrope 位置。必要なのはtransformers 4.57 以降です。

• コンテキストと出力 — 報告された実行では、24,576トークンのコンテキストと最大12,000の出力トークンを使用し、temperature 0.8、top-p 0.95で、プロンプトごとに3回のロールアウトを選択なしで生成しました。vLLMのサービングコマンドでは、プロンプトごとに2枚の画像が許可されます。参照画像と、それだけです。出力がテキストだからです。

• ライセンス — Apache 2.0。Qwen3-VLバックボーンに準拠していると説明されています。完全に許容的で、ゲーティングはなく、利用規定の追補もありません。

• 同梱されていないもの — トレーニングデータと評価データです。リポジトリにはパイプラインが含まれ、想定される入力と出力が文書化されており、期待する分割ファイルについても言及されていますが、モデルカードにもコードリポジトリにもデータセットの公開は記載されていません。手に入るのはレシピであって、材料ではありません。

• また、標準では含まれていません — ホストされたエンドポイントもありません。AesCode-8B を提供する API はどこにも見つかりませんでしたし、私たち自身のカタログにも含まれていません。プロバイダーが採用するまでは、評価するにはご自身の GPU に重みをロードする必要があります。

Microsoftが用いている枠組みは、それ自体が設計指針のすべてと言えるので、引用に値する。コードモデルは「レイアウト、階層、色がキャンバス上でどのように一体となるのかを認識できない」一方、画像生成器は「視覚的に魅力的なページを構成するが、テキスト、数値、論理関係をしばしば誤って描画する」。AesCodeは、一方から構成感覚を、もう一方から検証可能性を取り入れようとする試みだ。

1.00点という結果の解説

最初の段落の数字の背後にある仕組みは次のとおりです。トレーニング中、すべてのプロンプトは、その同じプロンプトから生成された参照画像とペアにされます。マイクロソフト自身の実行では、画像には GPT-Image-2 を使用し、短いアイデアを詳細なコンテンツプロンプトへ展開するために GPT-5.5 を使用しました。参照画像はコンテンツの権威を持たず、テキストプロンプトが引き続き信頼できる情報源です。参照画像が提供するのはレイアウトとスタイルであり、報酬関数はそれら二つを分離しておくように構築されています。

その結果、視覚的事前情報は入力側ではなくポリシー側に組み込まれることになる。AesCode-8B は、推論時に参照を除去すると Visual ポイントを 1.00 失う。自身のバックボーンは、参照条件付きで評価すると Visual 44.72 だが、参照なしでは 19.55 ポイント低下する。GPT-5.5 は 10.04 失う。これを蒸留した形が、すなわち、モデルが画像を必要としなくなったということだ。

結果の後半こそ、見落とされやすい部分だ。Microsoftの報告によると、参照ベースの報酬はプロンプトのみのVisualを25.17から69.71へ引き上げた——推論時に参照を一切見ないモデルでも、参照に対して訓練されたことによる恩恵を受けている。自社のパイプラインで参照生成ステップを省くつもりだったなら、それは訓練でも省く必要はないと告げる数字だ。

これ全体について正直に言っておくべき但し書きは次のとおりです。これはMicrosoftの評価基準であり、Microsoftの300件のインフォグラフィックサンプルに対して、プロンプトごとに3回採点され、都合の良い結果だけを選ぶことはしていません。スコアの半分は決定論的検証器から来ており、誰でも再現できます。残りの半分、つまりチェックリストの各次元は、文書が素性を明かしていない視覚言語モデルによって判定されます。それを生み出した判定者がどれか分からなければ、後半を再現することはできません。

センスが重みに染み込むところ

トレーニング手法は、今回のリリースの中で最も応用可能なアイデアを含む部分であり、それは出力から示唆されるよりも機械的だ。

• すべてはまずグラフである。 各ターゲットはデザイングラフとして表現される：テキスト、チャート、テーブル、カード、領域、画像スロットのノード、および包含、整列、順序、接続のエッジ。グラフの要点は帰属である — キャンバス上のすべてのプロパティは名前付き要素に属するため、すべてのプロパティを個別にスコアリングできる。

• 7つの報酬チャネル。 6つの決定論的検証器が解析可能な項目 — 実行、正確なテキスト、境界、表およびグラフのデータ、意味的レイアウト、空白 — をチェックし、サンプル固有のビジュアルグラフルーブリックが、幾何学と配置に関するグラフに束縛されたはい/いいえの質問として構築され、残りを採点します。チャネルは execution、text、boundary、tablechart、layout、whitespace、design です。

• チャネルは統合される前に正規化される。GDPOは各チャネルをロールアウトグループ内で正規化するため、密なルールベースの信号が疎な視覚信号を飲み込んでしまうことはない。Microsoftは同一設定の単純なスカラーGRPOに対して5.12 Visualポイント上回ると測定している——ベンダー報告ではあるが、単なる主張ではなく具体的なアブレーションである。

• スコアリングはレンダリングによって行われる。候補のHTMLは、外部リクエストをブロックしたサンドボックス化されたPlaywrightブラウザでレンダリングされ、ハーネスがDOM、計算済みスタイル、バウンディングボックス、コンソールのステータス、およびスクリーンショットを読み取る。表はHTMLテーブルでなければならず、チャートはEChartsスペックでなければならない。この制約は実際に機能している——出力を検証ツールが解析できる形に強制するのである。

• レシピそのもの。 3,000件のデモンストレーションに対するコールドスタート教師ありファインチューニングを学習率1e-5で行い、その後、verlのFSDP-vLLMハイブリッドエンジン上で7,408件のプロンプトに対してGDPOを400ステップ実行します。クリティックも、別途訓練した報酬モデルも使用しません。AdamWを一定の5e-6で使い、ウォームアップなし、重み減衰0.01、1ステップあたり128プロンプトで各8ロールアウト、KL係数とエントロピー係数はどちらも0.001、プロンプトと応答はそれぞれ最大8,192トークンです。リリースされた実行では、8基のNVIDIA B200を搭載した単一ノードを使用しました。AesCode-32Bは同じレシピを520ステップにわたって使用します。

全体として読めば、これはモデル公開を衣装としてまとった報酬設計の論文であり——そしてそれは、引用がプレプリントを指すのではなく「査読中」となっていることと整合している。

スコアボード、そして誰がそれを保証するのか

以下はすべて、モデルカードに報告されている、300件のインフォグラフィックサンプルに対するMicrosoft自身の評価です。Ruleは、プログラムによるText、Bound、Chartのチェックを平均します。Visualは、Content、Layout、Styleというチェックリスト項目を平均します。Overallは、この2つの平均です。スコアは、各プロンプトにつき3回の生成にわたって平均されたパーセンテージであり、選択は行っていません。「Ref.」は、プロンプトとともに生成された参照がモデルに与えられたかどうかを示します。

• AesCode-8B（参照付き） — テキスト 94.06、バウンド 88.36、チャート 87.79、ルール 90.07；コンテンツ 86.41、レイアウト 87.80、スタイル 53.21、ビジュアル 75.80；総合 82.94。

• 自身のバックボーンとの比較 — 参照条件付き Qwen3-VL-8B-Instruct は Visual 44.72、Overall 51.93 を記録。これは Visual で 31.1 ポイント、Overall で 31.0 ポイントの向上であり、テーブル内で最も驚きの少ない比較です。というのも、この訓練の主眼はまさに視覚的な半分にあるからです。

• GPT-5.5に対して、参照条件付き — 総合81.28、コンテンツ82.44、レイアウト89.93、スタイル57.91。

• Claude Opus 4.8 との比較、参照条件あり — 総合 80.39、コンテンツ 86.42、レイアウト 89.76。

• AesCode-32B、参照条件付き — テキスト95.34、バウンド97.27、チャート90.37、ルール94.33、レイアウト90.58、ビジュアル77.44、総合85.89。自身の32Bバックボーンを22.4ポイント上回るビジュアル。

• Styleの上限 — 表内のどのモデルも60を超えておらず、GPT-5.5の57.91がその最高値です。AesCode-8Bは53.21にとどまります。マイクロソフト自身の定義は容赦ありません。Styleは、納品前にこれ以上視覚的な修正を必要としない設計にのみ与えられます。つまり、人間が実際にページを未編集のまま出荷するかどうかを測るその唯一の次元において、8Bモデルはトップではありません。

• 境界の失敗 — 深刻なキャンバスオーバーフロー障害が300サンプル中4.3%で再発し、GPT-5.5では34.7%です。オーバーフローは、生成されたHTMLを単に醜くするのではなく使用不能にしてしまう失敗モードです。

さて、ここからが表と同じくらい重要な部分です。上の数値はすべてベンダーによる自己申告で、再現されていません。AesCode-8B は、我々が確認できたどの独立系リーダーボードにも登場しておらず、GPT-5.5 や Claude Opus 4.8 との比較は、Microsoft のルーブリックで、それらのモデルがチューニングされていないタスクで、しかも「Layout」の定義がページをとにかく生成すること自体を評価する形で行われています。Text スコア 94.06 は、このモデルがテキストで GPT-5.5 に勝つという意味ではありません。インフォグラフィックページ上で、プロンプトに矛盾せずラベルを配置できるという意味であり、はるかに小さな主張です。Style の結果は、このルーブリックが AesCode に有利に細工されていないことを示す証拠です — 最大のスコアボード上の勝利のすぐ隣に、最も芳しくない数値が座っているのです。

確認されていることと、確認されていないこと

これはひっそりとリリースされたものだからこそ、両者を明示的に区別する価値がある。

• 確認済み — 重みは存在し、Apache 2.0 の下でダウンロード可能。2つのリリースタイムスタンプはリポジトリ内にある。アーキテクチャ、パラメータ数、コンテキスト長、サンプリング設定はすべて公開されている config とモデルカードに記載されている。学習レシピと報酬設計は、異論を唱えられる程度には詳細に文書化されている。コード、検証スタック、ルーブリックビルダーは公開されている。32B のコンパニオンも存在する。

• 未確認 — ベンダー以外の誰かによるベンチマーク数値のいずれも。ドキュメント自体が査読中と説明している論文。スコアの視覚的な半分の背後にいる視覚言語ジャッジの正体。いずれかのプロバイダーがこれをホストするかどうか。報告されている評価は単一のインフォグラフィックページ上で行われているため、24,576トークンのコンテキストが実際の複数スライドのデッキで持ちこたえるかどうか。そして英語以外での振る舞いに関するあらゆること——モデルカードの言語タグは「en」のみ。

実行したい場合、そしてそれにいくらかかるか

Qwen3-VL-8B-Instruct — AesCode-8B のファインチューニング元となったモデルであり、誰かが独立した AesCode の結果を公開するまで得られる最強の単一比較対象 — は別問題である：

AesCode-8B自体のサービング手順は短く、モデルカードに直接記載されています：vllm serve microsoft/AesCode-8B --limit-mm-per-prompt image=2 --max-model-len 24576。vLLM以外のルートではtransformers 4.57以降を使用し、テキストプロンプトの前に任意の参照画像を受け付けるPythonスニペットも用意されています。

自分で計算しなければならないのはメモリだ。17.5 GBのbf16重みを、24,576トークンのコンテキストと最大2枚の画像に対応するKVキャッシュと並べて収める必要がある。そのため、単一の24 GBカードは重みには技術的には足りるが、それ以外のすべてには不安を感じるほどぎりぎりだ。現実的な最低ラインは40～48 GB、あるいは24 GBカード2枚である。32Bのコンパニオンは問題の次元が違う。そのシャードは合計66.7 GBに達するため、テンソル並列とマルチGPUノードが必要になる。レンダラーも見込んでおく必要がある。モデルは完全なHTMLドキュメントを出力し、それについてのあらゆる品質の主張はそのドキュメントをレンダリングすることでなされる。したがって、自分の出力を採点するには、外部リクエストをブロックした状態でPlaywrightを立ち上げることになる。

推論時に参照画像を生成する必要はありません——まさにそれが1.00点の結果で手に入るものです——しかし、ドキュメントには、参照画像が提供された場合に品質が依然として最も高くなると明確に書かれているので、誠実な設定は参照不要（reference-free）ではなく参照任意（reference-optional）です。

AesCode-8BはOrcaRouterがルーティングする対象ではなく、他にホストされている場所も見つけられなかったため、現時点で評価するとなれば自分のハードウェア上に重みを置くしかありません。しかしそのバックボーンとなると話は別です。Qwen3-VL-8B-Instruct は現在OrcaRouter経由でルーティング可能で、入力トークン100万あたり$0.18、出力トークン100万あたり$0.70、コンテキストは131,072トークンです — これにより、誰かのレシピを再現するためにGPUを1週間費やす前に、このアーキテクチャの未チューニング版が自分のインフォグラフィック用プロンプトでどう振る舞うかを安価に確認できます。OrcaRouterはプロバイダーの定価を0%のマークアップでそのまま通し、プロバイダー間で自動的にフェイルオーバーします。そのため、この比較にかかるのは1つのキーだけで、2つ目の契約は不要です。AesCode-8Bがいずれ当社がルーティングするプロバイダーに登場すれば、その日のうちにカタログに載ります。そして、もしあなたがそれをセルフホストするなら、本番環境でフォールバック先となるモデルは、すでにその1つのエンドポイントの背後にあるものです — これは、独立した評価が一切ないままひっそりとリリースされたモデルにとって妥当な姿勢です。

何を見るべきか

2つある。どちらも、また別のベンチマーク表ではない。

最初は論文だ。「AesCode: Aesthetic Code Generation with Decoupled Cross-Modal Rewards」は2027年の査読中として引用されているが、これはスケジュールというより、BibTeXエントリに打ち込まれたプレースホルダーのように読める。プレプリントかカメラレディが現れるまで、上記の報酬チャネルに関する説明は、研究室の外では誰も読めない抄録の要約にすぎない——そして、Visual Graph Rubricがそれ自体が誤っている設計グラフをどう扱うかといった興味深い問いは、全文でしか答えられない。

二つ目はホスティングだ。構造化された検証可能なHTMLを出力する8.8BのApache-2.0モデルは、まさにプラットフォームが採用する形をしている。なぜなら、その出力はJPEGとは違って検査可能だからだ。誰かがそれを配信した瞬間、これはセルフホスティングの判断ではなくルーティングの判断になり、コスト比較はGPU時間の話ではなくなる。

期待してはいけないのは、白黒はっきりした評決だ。スタイルは、これも含めてあの表にあるあらゆるシステムにとっての上限であり、スタイルだけが、人間がそのページをそのまま出荷するかどうかを問う次元だ。AesCode-8Bについて擁護可能な読み方は、狭いが確かなものだ。つまり、機械がチェックできる視覚デザインの部分では非常に優れ、チェックできない部分では中程度であり、このニッチ領域で、それら二つの隔たりがリリースの偶然の産物ではなくリリースの主眼となっている最初のオープンウェイトモデルなのだ。