Muse Spark 1.1を公開

 (ai.meta.com)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • Meta Superintelligence Labsが公開したMuse Spark 1.1は、エージェント作業を対象にしたマルチモーダル推論モデルで、ツール・コンピュータ使用、コーディング、マルチモーダル理解を前世代より強化
  • 外部アプリやサービス全体にまたがる計画・オーケストレーションを担い、native tools、MCP servers、custom skillsにzero-shotで汎化する点が中核
  • 100万トークンのコンテキストウィンドウを能動的に管理し、過去の作業情報を検索し、以後の段階に必要な重要な文脈を圧縮して保持
  • 開発者は公開プレビューとして提供されるMeta Model APIでモデルにアクセスでき、Meta AIアプリとmeta.aiでは「Thinking」モードで利用可能
  • MetaはAdvanced AI Scaling Frameworkに従って展開前の安全性評価を実施し、Chemical & Biological、Cybersecurity、Loss of Controlのカテゴリで安全マージン内にあると評価

Muse Spark 1.1の位置づけと提供形態

  • Muse Spark 1.1はMeta Superintelligence Labsの最新モデルで、既存のMuse Sparkに対する主要アップグレードとして紹介されている
  • エージェント作業向けのマルチモーダル推論モデルであり、次の領域での向上を強調
    • ツール利用
    • コンピュータ利用
    • コーディング
    • マルチモーダル理解
  • 今回の公開は、Muse Imageの発表とあわせて、Metaが語る「personal superintelligence」のビジョンに近づく一歩と位置づけられている
  • 開発者は公開プレビューとして提供されるMeta Model APIを通じてMuse Spark 1.1にアクセスできる
  • Meta AIアプリとmeta.aiでは「Thinking」モードで提供される

エージェント作業と長文脈処理

  • 複数の外部アプリやサービスにまたがる個人向けエージェント作業で、計画を立てて実行フローをオーケストレーションする
  • native tools、MCP servers、custom skillsにzero-shotで汎化する
  • 複雑なプロジェクトをMuse Sparkより大幅に高速で処理できるよう学習されている
    • メインエージェントはコンテキストを収集して計画を立てた後、並列subagentに実行を委任する
    • subagentは担当タスクに従い、利用可能なツールを理解し、必要なときにはメインエージェントへエスカレーションする
  • 100万トークンのコンテキストウィンドウを能動的に管理する
    • 実行した行動を記憶する
    • はるか以前の作業情報を検索する
    • 後続の作業に必要な重要ステップを残すよう圧縮する

コンピュータ利用の自動化

  • Muse Spark 1.1は、複数のアプリケーションを行き来し、情報がリアルタイムで変化するコンピュータ利用ワークフローに強みを示す
  • 長いセッションでもコンテキストを維持し、変化する要件に適応し、見慣れないインターフェースを最小限の人手介入で探索する
  • デスクトップ作業を常にクリック単位だけで処理するのではなく、状況に応じて自動化と直接操作を使い分ける
    • 自動化のほうが速いときはスクリプトを書く
    • 直接の操作が単純なときはクリックを使う
    • 各段階で複数の動作をまとめて生成する
  • 夕食パーティー準備の例では、注文プロセス中に新しいコンテキストが発生するとそれを認識し、ユーザー介入なしに必要な更新を行う

コーディング性能と開発ワークフロー

  • 大規模で複雑なコードベースを扱う実践的なコーディング作業で、Muse Spark 1.1の性能が大きく向上
  • 複雑なバグの診断と修正、エンタープライズ級システムの新機能実装、大規模なコード移行を実行できる
  • Webアプリケーション生成やend-to-endの質疑応答といったユースケースで、初代モデルに比べて大きな向上を示す
  • さまざまなハーネスに滑らかに適応し、複雑なマルチターン動作を安定して処理できるよう学習されている
    • planning mode
    • goal conditioning
    • subagent delegation
    • context compaction といった一般的なエージェントコーディング機能をサポートする
  • OpenCodeのデバッグデモでは、チャットWebアプリを作成し、自動スクリーンショットでユーザーに見える失敗を見つけ、関連コードまで追跡して修正したうえで、変更内容を検証する
  • Meta社内の開発者と研究者はMuse Spark 1.1を日常的に使用しており、Meta Internal Coding BenchでMuse Sparkを大きく上回り、主要な代替モデルと競争力のある結果を示している
  • 研究者たちはMuse Spark 1.1をワークフローに活用し、モデル開発・評価作業も自動化している
  • DeepSWE評価の例では、OpenCode内で複数の推論強度ごとにDeepSWEの一部タスクを自己評価し、結果に基づく分析ダッシュボードを生成する

マルチモーダル理解と実行

  • Muse Spark 1.1は、知覚、マルチモーダル推論、ツール利用を組み合わせる作業でも強みを示す
  • 実環境と相互作用しながら、根拠のある成果物を作成できる
    • 視覚資料からコード成果物を生成
    • 画像・動画に対する非常に詳細なキャプションを生成
    • マルチモーダルなユースケース向けにエージェントワークフローを実行
  • 知覚と行動の両方が必要な状況で、マルチモーダル能力がとくに有用
    • 視覚と音声を検査する
    • 長いワークフローの間も細部を保持する
    • ユーザーの代わりにコンピュータを操作する際にその細部を活用する
  • Facebook Marketplaceエージェントの例では、スマートフォンで撮影した動画から有用な写真を抽出し、商品を推論したうえで、ユーザーのブラウザを操作してMarketplaceの出品を作成する

安全性評価

  • Metaは展開前にAdvanced AI Scaling Frameworkに従って広範な安全性評価を実施した
  • このフレームワークは、Metaの最も高度なモデル向けの評価、脅威モデル、展開基準を定義する
  • 評価カテゴリには次のfrontier riskが含まれる
    • Chemical & Biological
    • Cybersecurity
    • Loss of Control
  • Metaの評価では、Muse Spark 1.1はすべてのfrontier riskカテゴリで安全マージン内で動作する
  • 直接的なjailbreak、信頼できないデータに由来する間接攻撃、prompt injection、developer-prompt攻撃に対して強い耐性を示す
  • その結果、adversarial robustnessが改善し、hallucination率とsycophancyが低下する
  • 安全性に関する全体内容はMuse Spark 1.1 Evaluation Reportに文書化されている

初期パートナーの反応と今後の計画

  • Meta Model APIの公開プレビューを通じて、開発者は初めてMuse Spark 1.1ベースの開発を始められる
  • 初期パートナーは、長文脈処理、コーディング、推論能力を組み合わせて大規模なエージェントワークロードを処理できる基盤モデルだと評価している
  • Replit CEOのAmjad Masadは、100万トークンのコンテキスト、画像・動画・PDFのマルチモーダル対応、引用付きの組み込み検索、構造化出力、並列ツール呼び出し、OpenAI互換パッケージを1つのモデルに収めた点を強調した
  • Cline CEOのSaoud Rizwanは、強力なツール利用と、実際のコーディングワークロードをスケールして実行できる価格帯を兼ね備えているため、Cline開発者に早期アクセスを提供したかったと述べた
  • BoxのYashodha Bhavnaniは、Boxのエンタープライズ業務評価セットでMuse Sparkが現在の主要frontierモデルと競争力のあるエンタープライズ能力を示したと評価した
  • OpenClaw FoundationのDave Morinは、Muse Spark 1.1をエージェント実行において高速かつ強力なモデルだと評価した
  • Metaはさらに高性能なモデルを学習中で、今後共有する予定としている

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Hacker Newsの反応

  • リンク先のレポートにははるかに詳しい内容がある: https://ai.meta.com/static-resource/muse-spark-1-1-evaluatio...
    Terminal-Bench-2.1 の詳細を見ると、「公式リポジトリの Terminal-Bench 2.1 の 89 個のタスクを、bash ツール専用のエージェントハーネスで評価し、リソースは CPU 6 コアと RAM 8GB に制限した」とあるが、これだと結果は 失格
    各 terminal bench タスクには CPU 上限と RAM 上限が個別にあり、どちらか一方でも超えると失格になる。tbench-2.1 では 89 個のうち CPU 6 コアを許容するタスクは 0 個で、RAM 8GB を許容するタスクも 8 個しかない
    こういう怪しいベンチマークは、モデルのベンチマーク性能を上げるためのハーネス作りの面白さを完全に奪ってしまう。何をしても見出しの不正確な数字には勝てないからだ。たぶんそれでこのモデルは公式リーダーボード https://www.tbench.ai/leaderboard/terminal-bench/2.1 に載っていないのだと思う
    元 Meta 社員として少しほろ苦い気持ちになるが、それほど驚きはない。PSC が終わって次に進むまでは、数字を上げること が主要な評価指標だった

    • モデルが誤って fork bomb を起こす場合を別にすれば、なぜ リソース制限 を気にする必要があるのか分からない。このベンチマークはターミナルの使い方、特に bash ツール呼び出しをたくさんつなげる能力を見るものだと思っていたが、どんなテストケースでそれが重要になるのか?
    • クローズドモデルの問題はまさにこれ。私たちがお金を払っている相手が より優れた基盤モデル なのか、それともベンチマークスコアを最大化するよううまく設計されたハーネスなのか、正確には分からない
    • 純粋に興味本位なのだが、リソース制限がボトルネックになる頻度はどれくらいあるのか? ハーネスはここで何を助けるのか? 並列性を制限したり、より効率的なツールを使ったりするのか?
    • 言いたいことは分かるが、そこまで重要かどうかはよく分からない
      harbor / tb2.1 は Docker 実行で使える スワップ を制限していたのか? 以前、Docker インスタンスの実行が仕様より多くのメモリを使えてしまうバグがあった。本来のタスクの一部はスワップを使えないと実質的に完了不可能で、Docker がスワップにアクセスできないようにするとオラクル解でも通らなかった
      記憶では crack-7z-hash と filter-js-from-html にその問題があったが、数か月見ていないので確信はない
    • それほど大きな問題には見えない。どんな製品を評価するときでも、作った側の話をそのまま信じたりはしない。もちろんバイアスがあるからだ。だから https://artificialanalysis.ai のような 独立テスト が存在する

  • 数日間先行して試すことができ、その間に LLM 用プラグインを作れた。ターミナルではこんなふうにモデルを試せる
    uv tool install llm
    llm install llm-meta-ai
    llm keys set meta-ai
    # paste API key here
    llm -m meta-ai/muse-spark-1.1 "Generate an SVG of a pelican riding a bicycle"
    結果はこちら: https://tools.simonwillison.net/markdown-svg-renderer#url=ht...
    比較用に、Muse Spark 1 で出たペリカンはこちら: https://simonwillison.net/2026/Apr/8/muse-spark/

    • こうも多くのモデルを 先行プレビュー する時間をどうやって作っているのか気になる。最近のモデル公開は本当に目まぐるしいが、たまには仕事のように感じないか?

  • Zuck は正面から競争するより、モデル市場の スポイラー役 に集中したほうがいいのかもしれない
    Anthropic や OpenAI のモデル売上に追いつく必要はなく、その売上を 99% 削れればいい。フロンティアモデルの開発に何十億ドルも注ぎ込み続け、オープンウェイト で公開して、コーディングモデルをコモディティ化すればいい。そこに、よくできたオープンソースの標準ハーネスも必要だ
    これができて、しかも事業として成り立つ位置にいる人はほとんどいない。どうせ流れはその方向に向かう可能性が高く、彼はその速度を大きく加速できる。コンパイラがそうだったように、モデルも独占的な製品からコモディティへ移っていってほしい
    これは Zuck が世界に対してできる最善のことの一つかもしれない

    • 彼らが売上を失ったら、Meta の計算資源は誰が借りて使うことになるのか?
    • 本当の スポイラー王 になるには、学習データセットをオープンソースで公開すればいい。そこまで行くかは疑わしい
    • コーディングモデルは目的地ではない。コーディングモデルは 汎用知能 に向かうためのブートストラップ過程の一部にすぎない
    • llama で既にそれを試していなかったか?
    • 彼がやるべきなのは、こうしたモデルを作るのがもうそれほど難しくないと証明することだけだ。これらの企業の moat は、フロンティアモデルの構築が本当に難しいという 認識 にあるのだから

  • 価格が信じられないほど安い。100万トークンあたり入力 $1.25、出力 $4.5 で、キャッシュされた入力は $0.15。
    https://dev.meta.ai/docs/getting-started/pricing-rate-limits

    • これは xAI Grok 4.5 と最も直接的に比較できる。どちらも方向性としては「Haiku の価格で Opus 級の知能」に近く、こういうモデルをアプリに組み込みたいアプリケーション開発者にとってはかなり大きな話だ。
      Haiku と Sonnet を Grok 4.5 に置き換えるテストをしていたが、これも一度使ってみるつもり。特にキャッシュ価格はずっと安い
    • キャッシュされた入力の価格比率が良い。
      Grok 4.5 は $2/$6 で出てきたが、ひっそりとキャッシュされた入力に100万トークンあたり $0.50 を課金している。これは Opus 4.8 並みに高い水準だ
    • Meta は今のところ、モデルを選ぶ大半の人のレーダーには入っていない。本当に良いモデルがあるなら、競合価格に合わせる前に補助金を出してユーザーを確保するのは理にかなっている
    • Qwen 3.7 Max より安い。Grok 4.5 の入力 $2 / 出力 $6 に続いて、大手研究所が GLM 5.2 の圧力を感じていることを示す2つ目のシグナルだ
    • それでも依然としてばかげた高さではある。Google 検索結果100件に $10 払うと考えてみれば、実質これがそういうことだ。
      出力100万トークンあたり $1.50 超を払おうとする人がなぜいるのか本当に分からない。ましてや $15〜50 などなおさらだ。消費者が実際に従量課金を払うケースなんてあるのか?

  • 昨日までの時点では OpenAI と Anthropic が取り返しのつかないほど先行しているという空気が強かった気がするが、今では xAI と Meta も少なくとも実用モデルで競争可能なものを出してきていて、価格も安い。
    もちろん Fable、そしておそらく近いうちに出る GPT-6 まで見れば、2つの先頭研究所が先行しているという話はまだ成り立つが、世論を主導する層が言っていたような完全に終わったゲームではない

    • もうモデルはだいたい十分に良くなった。大きなブレークスルーがない限り、これから重要なのは コストだけだ
    • 人々は Google が出遅れたことを、Anthropic と OpenAI がものすごく先に行ったことだと誤解していた。実際には Tensorflow、Angular、GCP のときのように Google が出遅れたのに近い
    • そのニュアンスは少し違う。
      GLM 5.2 への期待感は以前からすでに大きかった。xAI や Meta が別のやり方で大きな差を作ったわけではなく、GLM 5.2 に近い結果と近い価格に寄っている

  • 個人的には Meta は好きではないが、これは認める。競争が多いほど一般消費者には良いし、企業にも良い。
    中国モデル、Grok、Meta、Google、OpenAI、Anthropic がすべて競争しているのは勝利だと思う。こういう補助金付きトークンを使えるうちに、できるだけ活用しようと狂ったように作っている

    • Meta のローカル llama モデルは、かつて オープンソース AI の顔だった。本当に様変わりした
    • 間違いなく良いことだと思う。ただ、こうした進展によって AI 時代に必要なソフトウェアエンジニアの数が増えるのか減るのかは、まだ自分の中で議論が続いている。
      一方では、製品作りが簡単になって、より多くの人が作り、より多くの製品や機能が生まれるはずだ。非技術者もたくさん作ろうとするだろうが、どこかで行き詰まり、結局はエンジニアが必要になる。熟練した技術系企業と非技術系の起業家、予備軍が生み出す製品総量は莫大になるはずだ。近い将来、より多くのソフトウェアエンジニアが必要になるという 上振れシナリオ はここにある。
      逆に、1年ほど経てば人々はこうした製品を大量に作るだろうが、その大半はマーケティングも販売も収益化もできないだろう。結局、そこまで多くのソフトウェアエンジニアは必要なくなるかもしれない。それでも全体としては、上振れシナリオが純効果として勝つ可能性が高いと思う
    • 中国モデルをさらに挙げるなら DeepSeek、GLM(Z.ai)、Minimax、Kimi(Moonshot)、Hy3(Tencent)、Qwen(Alibaba) がある。
      それぞれ重みをダウンロードして ローカル実行できる
    • 彼はこのニュースを自分の Meta Threads ではなく X に投稿した。これを大きく広めたい関心がどの程度あるかを示している。もちろん、こうした企業が現金を燃やし続ける間は、こちらとしてはコストが負担可能な水準にとどまるかもしれない
    • これまで見てきた中で最大の 技術競争だ。最も裕福な企業、最も賢い人々、最も裕福な国々が飛び込んでいる。
      競争が良いことなのかは分からないし、数年後に分かるだろう。久しぶりに肉体労働の仕事に就く日を楽しみにしている

  • どうしてどの会社も、あらゆるベンチマークで自社が1位のように見せられるんだろう?

    • まず自分で選んだベンチマークの束で、どのモデルがより悪く見えるかを見る。
      次に競合モデルの 以前のバージョン と比較する。それでも良く見えなければ、自社の以前のモデルと比較する
    • 堀がそれほど深くなく、改善は漸進的で、比較対象のモデルを選んで並べられるからだ。
      公平に言えば、主な強みが価格なら、近い性能帯のモデルと比較するほうが適切に見える
    • 今や Gemini と比較するのは 無料のビンゴマス みたいな感じだ
    • AI を深く知っている人の基準では、コーディングにおける 標準ベンチマーク は何だと考えればいいのか?
    • 自社モデルが少なくとも N 個のベンチマークで上回る、その正確な瞬間を待って発表すればいい

  • Meta が クローズドウェイトモデル を開発・公開していたことを見落としていた。残念だ。米国産のオープンウェイトモデルで、もっと進展があるといいのだが

  • コンテナ内で codex と一緒に動くようにした。参考までに、Codex:Muse インターフェースでは大半の人が遭遇するバグがあるようだ。
    私の見る限り、codex がサーバー側ツール呼び出しを想定しておらず、Meta の ID の扱い方のせいで起きる一種のパースまたは統合エラーだ。codex を muse と最初の数回動かしたとき、最初の非ウェブ検索呼び出しで失敗した。
    修正はしたし、個人的にはカスタムの サーバー側ツール呼び出し と無期限のファイル保存にはまだ完全には納得していないが、今のところかなり良いモデルで、楽しく使っている。
    https://github.com/accretional/awesome-muse-spark/blob/main/...

  • 公開されたベンチマークを見ると、コーディングやマルチモーダルもかなり良いが、ツール呼び出しの成功率が非常に高いように思える
    この性能の形に最も合うユースケースは何だろうか？

    • デバッグと診断ではツール呼び出しが非常に多い。ログを grep したり変換したり、プロファイラやトレーサーを呼び出したり、インシデントレポートを書くことまで含まれる
      バグ診断は、ある程度コーディングもしつつ、ツール活用をよりうまくこなすべき領域だ。良い診断レポートがあれば、修正は Opus に任せればよい
      Opus もある程度レポートは書けるが、typst 文書では今でも表の幅をよく間違え、最後の列にテキストがぎっしり詰まっているのに幅は数文字分しかない、ということが起こる
    • Gemini 3.5 Flash はツール呼び出しでは Fable より優れている。ツール呼び出しはおそらく 事後学習 によって比較的簡単に改善できる領域のひとつだろう
    • 今後、新しいリリースが出るたびにこうしたパターンを見ることになるのか気になる。ツール利用は急速に変化する可能性が高いため、最も知的なモデルよりも 最新のモデル が常に優位に立つことになるかもしれない
    • これは少し役に立たない話にも聞こえる。JSON のような制約付きデコーダの性能が高いのは興味深いが、通常のデコーダでツールバリデータを通し、良いエラーメッセージを受け取ってから再試行するループなら、ほとんどの場合 2 回目の試行でツールを動かせる。入力はキャッシュされるので、コストもそれほど高くない