Muse Spark 1.3 が GPT-5.6-Sol に匹敵し世界第 3 位へ

昨日から続く「ローンチシーズン」は続いています。今日は Gemini 3.8 Flash の噂が流れていましたが、先月ザッカーバーグ氏の復帰宣言で約束されていた「Muse Spark 1.3」こそが、今日のメインニュースとしてふさわしいタイトルを獲得しました。AAII（AI Alignment and Intelligence Index）によると、同モデルは現在世界第 3 位の性能を誇っています。

ついに OpenAI や Anthropic の最前線モデル（Opus、Fable ではありません）と互角のスコアを記録し、その自信を示したばかりか、今後オープンウェイト版も公開されるという発表もありました。

また興味深いのは価格設定です。トレーニングへの参加を選択すると、料金が 90% 以上安くなるというモデルを採用しています。

AI News（2026 年 8 月 22 日〜24 日）

今回は 12 のサブレッド、544 件の Twitter、および Discord を調査しましたが、新たな情報は見つかりませんでした。AINews のウェブサイトでは過去のニュースをすべて検索可能です。なお、AINews は現在「Latent Space」の一部門となっています。メール配信の頻度設定は、ご自身の希望に合わせてオン・オフ切り替えが可能です。

AI Twitter リキャップ

• エージェントエンジニアリングのカリキュラムと開発者向け実践

スタンフォード大学は、AI ネイティブなソフトウェアエンジニアリングを一つの学問分野として確立しようとしています。@mihail_eric氏は、「2026 年のソフトウェア工学のメタモルフォーシス（変容）」を中心とした『The Modern Software Developer』の新エディションを発表しました。

注目すべきは、単にコースが開設されることではなく、カリキュラムが根本からリセットされている点です。2025 年秋学期の教材の 85% が置き換えられ、エージェントスキル、コンテキストエンジニアリング、MCP ポータル、エージェント対応コードベース設計、アジェンティックなコードレビュー、セキュリティ、並列バックグラウンドエージェント、そしてソフトウェアファクトリーといったトピックが新たに採用されます。このコースでは、学生は Browserbase、OpenHands、Semgrep、Milvus、Marimo、CrewAI、Warp、Vercel、Unsloth、Anyscale などのパートナー企業からの支援を受けながら、実際のオープンソースリポジトリへプルリクエスト（PR）を送ることを義務付けられています。

スタンフォード大学ではもう一つのコースが、第一原理に基づくエージェント構築に焦点を当てています。@Diyi_Yang氏と@michaelryan207氏は、CS329Z「Engineering AI Agents」を発表し、これは明示的に「ゼロから」エージェントを構築することを軸に構成されています。Mihail Eric氏のコースと併せて、これは「プロンプトエンジニアリング」という教育手法から、システム指向のエージェントエンジニアリングへと広範な転換を示唆しています。つまり、モデルの利用そのものだけでなく、ハルネス（基盤）、評価、メモリ、ツール類、オーケストレーション、そして実運用における制約といった要素を重視する方向へシフトしているのです。

実務家の議論は、単純なルーティングではなく「状態を保持した知能の割り当て」へと収束しつつあります。パネルディスカッションで @HarryStebbings は、@EnoReyes の主張を紹介しました。モデルから最大限の性能を引き出すには、単にリクエストを振り分けるだけでは不十分であり、エージェントはタスクの状態や直前の出来事、そして次に来るべきことを理解し、知能を動的に割り当てる必要があると指摘したのです。

これは @jerryjliu0 の見解とも一致しています。ベンダー中立のスタートアップ企業は、ハネス（基盤）全体を最適化し、最先端モデルとオープンウェイトモデルを状況に応じて使い分けることで、特定のタスクにおいてはフロンティア・ラボを上回る成果を出せるという点です。

モデルアーキテクチャと推論：Astra の噂、ループ型トランスフォーマー、リアルタイム推論

「Astra はループ型トランスフォーマーである」という噂は、見出しが示すほど画期的なものではない可能性があります。@rasbt 氏は OpenAI の rumored Astra アーキテクチャに関する報道を分析し、引用されている「再帰的深さ」や「ループ型トランスフォーマー」という概念自体が、単なるアーキテクチャの微調整に過ぎず、それだけで画期的な突破をもたらすものではないと指摘しています。

彼が例として挙げているのが、Nanbeige 4.2-3B です。これはオープンウェイトで公開された先行事例であり、22 レイヤーからなるトランスフォーマースタックを 2 回再利用することで、パラメータの保存量を倍増させることなく、実質的に 44 レイヤー相当のモデルとして動作します。この手法のトレードオフは明確です。メモリ使用量はほぼ同等ですが、計算コストは約 2 倍になり、標準的なスタックと比較してトークン効率の維持は部分的なものに留まります。

より本質的な歴史的な先例としては、「再帰の混合（Mixture-of-recursions）」が挙げられます。これは学習されたルーターが適応的に各トークンに割り当てるパス数を決定する仕組みで、簡単なトークンは早期に処理を終了させ、難しいトークンにはさらに計算リソースを割くことができます。

また、@rasbt 氏による重要な補足として、「再帰性」が必ずしも「隠された推論（hidden reasoning）」を意味するわけではないという点があります。レイヤーの再利用は、本質的に「思考の連鎖（chain-of-thought）」を曖昧にするものではなく、単にトークン生成前に計算を潜在表現（latent activations）内に多く移動させるだけです。もし再帰的深さが可視的な推論プロセスを減らしているように見えるとしても、それはループ型トランスフォーマーがテキストによる思考の連鎖を本質的に抑制するからではなく、モデルが中間トークンをより少なく生成すれば済むだけの話です。

リアルタイム・マルチモーダルなワークロードに対応するインフラの更新が続いています。@vikhyatk 氏が Photon 2.1 を発表し、テキストから音声への変換モデルや NVIDIA B200 のサポートを、リアルタイム・マルチモーダル推論エンジンに追加しました。一方、Baseten は @baseten を通じて GLM-5.3 Fast のホスト型提供を開始し、より高い TPS とリアルタイム展開への適応性を強調しています。

エージェントのハルネス化、スキル検索、RL 後学習ツール

ByteDance Seed の HarnessDev は、タスク完了だけでなく「ハルネス」自体を中心にエージェント評価を再定義するものです。@omarsar0 氏が紹介した新しい論文によると、HarnessDev ではモデルに、弱いが実行可能なシードから始めて実行用ハルネスを構築させ、その後、下流のフィードバックを用いて第 2 ステージで改善させるというアプローチを取ります。両ステージは能力と実行トークンコストの両面で評価され、効率性も目的の一部となっています。6 つのクリエイター LLM、4 つのドメイン、そして 2,207 の保持された下流インスタンスにわたるテストでは、生成されたハルネスはコード、検索、研究分野において成熟した人間が設計したシステムにはまだ劣りますが、ライティングや機械学習の実験分野では同等かそれ以上の性能を示しました。重要な点は、自己進化型のハルネスが役立つ一方で、その効果は不安定でモデル依存性が高く、部分的な転移しかできないということです。

関連するエコシグナルとして、exo と再帰的自己改善ツールリングも注目されています。@omarsar0 氏は、exo ハルネスを再帰的改善ワークフローを理解するための有用な入り口として指摘しました。これは、エージェントが出力だけでなく、その足場自体も改善していくフレームワークへの関心が高まっていることを示しています。

スキル検索は集計データ上では良好に見えても、実際にそのスキルが発火するタスクにとっては悪影響を及ぼす可能性があります。@dair_ai は「Retrieval-Invoked Actual-Use Effect（検索が実際に使用された場合の真の効果）」という概念を提案した論文を紹介しました。これは同一タスクを2回実行し、片方はスキル有効化あり、もう片方は無効化で比較するマッチド評価手法です。重要なのは、検索機能が実際に発火したタスクのみを対象に効果を検証することにあります。

コードや数学の分野における17種類のLLMを対象とした調査では、全体スコアは向上しているにもかかわらず、検索が使用された特定のタスク群においてはネガティブな影響が生じているケースが確認されました。スキルライブラリやツールディレクトリを運用するチームにとって、これは集計値の上昇だけを過大評価しないよう警告する実践的な知見です。

RL（強化学習）のポストトレーニング基盤は、より製品化されたものへと進化しています。SGLang チームは Baseten と NVIDIA Dynamo と共催したイベントで、Miles という RL 学習フレームワークを紹介しました。このフレームワークでは SGLang をロールアウト推論エンジンとして採用し、高速かつ信頼性の高い RL ポストトレーニングを実現しています（@sgl_project）。また、@AravSrinivas は Miles を「オープンソースの RL-as-a-service」として位置づけ、個別に構築する社内パイプラインではなく、再利用可能なポストトレーニングスタックへと移行するトレンドを強調しました。

Google Gemini 3.8 Flash Cyber および Google ツール利用におけるプロダクション上の課題

Google は、強力なベンチマーク結果を誇る専門的なサイバーセキュリティモデルを発表しました。サンダル・ピチャイ氏は「Gemini 3.8 Flash Cyber」を発表し、これは Google が持つ最も能力の高いサイバーセキュリティモデルとして位置づけられながら、Flash レベルの速度と価格設定も維持しています。

報告されている数値では、CyberGym で 86.2%、パッチ適用に関する CWE-Bench で 47.2%、そして 20 のプログラミング言語にわたる内部脆弱性発見ベンチマークで 70% 以上の成功率を記録しました。

一方で、開発者の間ではハッシュ（harness）やアカウントリスクへの懸念が浮上しています。Theo氏は、Google は現在、ハッシュ、コードアプリ、サードパーティとの統合、そして特にコアとなる Google アカウントに紐づく厳格な禁止措置において、開発者にとって使いにくい環境にあると指摘しました。

QuinnyPig 氏はこの懸念をさらに鋭くし、問題の波及範囲が Gmail や Workspace に留まらず、同じアイデンティティに関連付けられた Google Cloud アカウントにも及ぶ可能性があることを強調しています。Theo氏が後に Gemini のタスク（1, 2, 3）において、ツール呼び出しに依存した遅いコーディング行動を訴えたのはあくまで個人的な体験談ですが、ベンチマークでのパフォーマンスと実際の開発者向け UX の間に大きな隔たりがあることを浮き彫りにしています。

Meta Muse Spark 1.3 と動画・マルチモーダルモデルのリリースサイクル

Meta は、エージェントタスクやコーディングワークロード向けに「Muse Spark 1.3」をリリースしました。@shengjia_zhao 氏は、このモデルが Spark シリーズの中で最も強力なものであり、特に長時間の作業処理と複雑な指示への忠実な対応において優れていると紹介しています。

コミュニティからは価格対性能比に関する反応が多く寄せられました。@alexandr_wang 氏は「たった 10 ドルで何ができるか」とそのコストパフォーマンスを指摘し、他のユーザーも競合する高価なモデルと比較して、速度やトークン効率の面で優れていると評価しています。

アリババの「Wan 3.0」は、動画分野でのサードパーティによるベンチマーク結果で好成績を収めています。@ArtificialAnlys 氏によると、人工知能分析（Artificial Analysis）のリーダーボードでは、「音声付き動画編集」で 1 位、「音声付きテキストから動画へ」で 2 位、「音声付き画像から動画へ」で 5 位を獲得しました。

このモデルは、テキスト、画像、動画、音声、ドキュメント、ウェブページを参照元として受け付けるオールインワンの生成・編集ツールとして位置づけられています。ネイティブ音声をサポートし、1080p で最大 30 秒の動画を生成可能です。パブリックプレビューでの料金は、480p で 1 秒あたり 0.05 ドルから始まり、1080p では 0.20 ドルとなります。

参照資料を多用するマルチモーダル UX も進化しています。@imagine は、プロンプト内の @-タグ機能を通じて、画像、音声、キャラクターの参照を最大 14 件までサポート可能にしました。これは、複数のアセットを制御してクリエイティブな作業を行う上で、小さくても実用的なインターフェースの改善です。

オープンモデル、ロボティクス、そして注目すべきツイート

オープンモデルの開発はさらにスケールアップを続けています。@percyliang 氏は、Marin 535B-A23B のトレーニングが 13% 完了したと共有しました。このプロジェクトの計算リソースは、ジェン・フアンとロリ・フアン財団によって提供され、CoreWeave で実行されています。この投稿が注目される理由は、ベンチマークの数値そのものよりも、慈善団体による計算資源の支援を背景とした大規模なオープンモデルトレーニングの持続可能性が示された点にあります。

物理 AI とオープンロボティクスプラットフォームも着実に前進しています。@maze_rapid 氏は「Palmimo DevKit」を発表しました。これは卓上型 AI ロボットプラットフォームで、オープンソースソフトウェアと交換可能な AI ブレインを搭載しています。開発者が深いロボット工学の専門知識を持たなくても、数行の Python コードでロボットのアプリケーションを制御できるように設計されています。まだ初期段階ですが、エージェントフレームワークが身体性のあるシステムへと拡張される例として注目すべきものです。

エンゲージメント数の多い主要なツイート：

@mihail_eric: カリキュラムを大幅に見直し、OSS コラボレーションを強化したスタンフォード大学の AI ネイティブソフトウェア開発者向けコースについて。

@sundarpichai: Gemini 3.8 Flash Cyber のローンチと、強力なサイバーセキュリティベンチマークに関する主張について。

@rasbt: ループ型トランスフォーマーのアーキテクチャの詳細解説と、Astra に関する噂が新規性を過大評価している可能性について。

@Diyi_Yang / @michaelryan207: 新しいスタンフォード大学コース「CS329Z: Engineering AI Agents」について。

AI Reddit リキャップ

/r/LocalLlama + /r/localLLM リキャップ

1. Muse Spark と Spark-X2.5 のオープンウェイトモデル

Muse Spark のオープンウェイトがまもなく公開される見込み（活動数：902）

画像は、Mark Zuckerberg が X で投稿したスクリーンショットです。そこでは Muse Spark 1.3 の展開が発表され、コーディング能力、エージェントワークフロー、長文コンテキスト処理における大幅な改善が謳われています。また、「オープンウェイトはまもなく公開される」とも明記されています。

添付されたベンチマーク表によると、Muse Spark 1.3 は Muse Spark 1.2 を上回り、GPT 5.6 Sol や Opus 5 と並ぶ性能をエージェント評価、長文コンテキスト評価、コーディング評価の各項目で示しています。一方、Reddit の投稿者自身は、「Spark は自分のハードウェアには大きすぎるため、Llama 5 か Glimmer と Spark の間のモデルが出るまで待っている」と述べています。

コメント欄では、複数の主要研究機関が技術的に収束しつつあるという証拠としてこの結果を捉える声が多く見られます。「決定的な秘密兵器はない」「最前線の差は数ヶ月しかない」といった意見もあれば、「Muse Glimmer は過小評価されている。コーディング以外のタスクでは Qwen 3.8:27B を上回っている」と主張するコメントもあります。

さらに、報告された長文コンテキスト処理の結果が異常に高い点についても注目が集まりました。具体的には「MRCR 512k〜1m で 98.1%」という数値です。あるユーザーは「これは Muse Spark が百万トークン規模での『コンテキストの劣化（context rot）』を事実上解決したことを意味するのか」と疑問を呈しています。

もしこのベンチマークが正確であれば、512k 以上のコンテキストにおいて持続的な検索・推論品質を維持できるという点は、今回のスレッドで最も技術的に注目すべき主張となります。なぜなら、多くのオープンソースおよびクローズドモデルにとって、長文コンテキストでの性能維持は依然として大きな弱点となっているからです。

あるユーザーは、Muse Glimmer がコーディング以外のタスクにおいて「非常に優秀」であり、主観的には Qwen 3 8/27B よりも優れていると報告しました。これは、Muse の小規模または以前のモデルでもプログラミングベンチマークの枠を超えて競争力を持っている可能性を示唆しています。この比較はあくまで個人の体験談ですが、包括的なリーダーボードでのパフォーマンスではなく、タスク固有の強みを示していると考えられます。

複数のコメント投稿者が、表示されたスコアの背後にあるパラメータ数の推測を問いかけました。ベンチマークが正確であるならば、Muse Spark はトリリオン・パラメータ規模に達している可能性があると指摘されています。これにより、実用的な展開に関する懸念も浮上しました。趣味のレベルでのローカル実行は困難かもしれませんが、中国語モデル以外の選択肢が必要な組織にとっては、ポリシーやコンプライアンス上の理由からオープンウェイト版が依然として有用である可能性があります。

新モデル：Spark-X2.5-4B、Spark-X2.5-1.7B（活動数：301）

XHToken が Spark-X2.5 の 1.7B と 4B をリリースしました。これは単なる微調整ではなく、独自のアーキテクチャを採用したモデルのようです。モデルカードには、ネイティブで 1M トークンのコンテキスト長をサポートし、多言語対応が可能であること、そして約 20T トークンでの事前学習とロングコンテキスト・ポストトレーニング段階を経て訓練されたことが記載されています。

アーキテクチャについては、フルアテンションとスライディングウィンドウアテンションを組み合わせることで、ロングコンテキストにおける KV キャッシュや計算コストを削減しているとのことです。また、4B モデルのベンチマーク結果は、Qwen クラスの約 9B モデルなどよりも遥かに大きなモデルと比較しても遜色ない性能を示すとされています。

llama.cpp への公式統合はまだ行われておらず、現在進行中の PR #27868 のマージか、XHToken が開発する独自フォークに依存しています。GGUF ファイルは 1.7B と 4B で利用可能です。

コメント欄では、報告された 20T トークン規模の事前学習データ量に対して感銘を受ける声が多く見られました。特に、パラメータ数が 5B を下回るモデルでネイティブ 1M コンテキストを実現した点は、技術的に非常に注目すべき成果として評価されています。

一方で、ベンチマーク結果、特に「4B モデルが約 9B モデルと同等の性能を持つ」という主張が独立したテストでも再現されるかどうかについては、慎重な関心が寄せられています。

あるテスターが「pi ハーネス」を用いた初期の定性的なテスト結果を報告しました。モデルに「あなたはどのモデルですか」と問いかけた際、回答する前にツールを使ってハーネス名を検査・分析している様子が見られ、エージェント的な振る舞いやツール使用の傾向を示唆しています。ただし、そのプロセスには過度な思考（"overthink[ing] a lot"）も含まれていました。

簡易的な推論テストでは「カーウォッシュ」の問題に失敗しました。テスターはさらに、日常利用における品質を比較するため Qwen3.5 9B との対照実験を計画しています。

1. Qwen3.8 のベンチマークと GGUF による高速化

Qwen が王者となるのか？（アクティビティ：732）

画像は「Arena AI Code Arena WebDev リーダーボード」を示しており、Qwen3.8-Max-0902 がスコア 1,691 で 1 位にランクインしています。これは Claude Opus 5 Max（1,688）や Kimi K3 Max（1,674）をわずかに上回る結果です。

この投稿の文脈では、Qwen の拡張推論能力とポストトレーニングにおけるスケーリング効果が、より大規模なフロンティアシステムとの差を縮めつつあることを示唆しています。将来的な Qwen 4 のリリースやオープンウェイト版の更新以前に、その差が埋まる可能性も指摘されています。

コメント欄では、ローカル環境やオープンウェイト版の Qwen バリアントに対する期待感が顕著でした。あるユーザーは「Q3.8-27B をローカルで実行した方が、有料の ChatGPT によるコーディング体験よりも優れていた」と主張しています。他方、トップパフォーマンスを示す Max モデルがオープンウェイト化されるかどうかを疑問視する声もありました。

また、拡張推論機能への評価は高いものの、難易度の高いタスクでは数時間の遅延が発生するというトレードオフにも言及されています。

あるユーザーは、Q3.8-27B を PI と組み合わせて使用した際のローカル環境でのコーディング性能が非常に高いと報告しています。このモデルは、それまで有料で利用していた ChatGPT 5.1 のコードタスクにおけるパフォーマンスを上回ったとのことです。特に注目すべきは、実務的なタスクの遂行能力です。wiki ページを .txt ファイルとして提供されるなどの適切なコンテキストを与えられれば、ローカル PC で完全に動作させつつデータプライバシーも守りながら、わずかな修正だけで動くコードを生成します。

複数のコメントでは、推論時間の延長が主要な差別化要因であるという指摘があります。あるユーザーは「Qwen 3.8 Max は私の課題セットで 100% 正解するが、回答に至るまでに数時間かかる」と述べています。これは、精度や信頼性と、推論に特化したワークロードにおける極めて高い推論レイテンシとのトレードオフを浮き彫りにしています。

提示されたベンチマークグラフについては懐疑的な意見もあります。あるコメントでは「数字が非常に操作されているように見える」と指摘され、別のコメントでは「なぜ Fable 5.1 が比較に含まれていないのか」と疑問が呈されています。モデルのランキング評価は、ベンチマークの選択や報告方法、あるいは競合他社の省略に大きく依存している可能性があるという懸念です。

Qwen3.8-Flash-Next-GGUF のための MTP（Multi-Token Prediction）対応が Unsloth からリリースされました（活動状況：671）。Unsloth は、ローカル実行環境や OpenAI 互換エンドポイント向けに設計された GGUF 利用パスとともに、MTP サポートとファイルを提供しています。関連するテスト手順は、llama.cpp の Unsloth 版ブランチ/PR（unslothai/llama.cpp#144）に紐付けられています。

コメント欄では、新たにマージされた llama.cpp の最適化（ggml-org/llama.cpp#28123）が指摘されています。この最適化により、コード生成時のスループットは 123 トークン/秒から 183 トークン/秒へ、文章生成時は 83 トークン/秒から 144 トークン/秒へと向上しました。一方、ドラフト機能なしのベースラインではそれぞれ 108 トークン/秒でした。パッチ適用前には、文章生成における MTP の速度がドラフトなしよりも遅いという問題も報告されていました。

議論は主に実用的な観点から展開されており、SSD オフロードの安定性や「改善されたか」といった質問が寄せられています。また、MTP 用のファイルはすでに数日前から利用可能だった可能性についても言及されています。

コメントで引用された llama.cpp の最適化 PR（ggml-org/llama.cpp#28123）は、Qwen3.8-Flash-Next-GGUF における MTP のスループット向上を明確に示しています。ドラフト機能なしのベースラインが 108 トークン/秒だったのに対し、変更前の MTP はコードで 123 トークン/秒、文章では 83 トークン/秒でした。しかし、最適化後の MTP はコードで 183 トークン/秒、文章で 144 トークン/秒に改善されました。

技術的な核心は、マージ前には文章ワークロードにおいて MTP が通常のデコーディングよりも遅くなるケースがあったものの、今回のパッチによりドラフト処理が一貫して有益なものになった点にあります。

llama.cpp の未解決のランタイムやサポートに関する詳細を追跡しているコメント投稿者が複数います。具体的には、SSD オフロードが安定しているか、MTP ファイルにおける -shared オプションが非共有モードとどう異なるかなどです。

別のユーザーは、必要な llama.cpp 機能のサポートがまだ完全にマージされていないと考えており、ローカル環境でのパフォーマンスが約 9 tok/s と低いことを報告しています。これは、ハードウェアや設定の影響が依然として大きいことを示唆しています。

続きを読む