Meta Muse Spark 1.1:概要・料金・弱点を整理

Meta Muse Spark 1.1とは実際に何なのか

Muse Spark 1.1は、4月に登場した最初のMuse Sparkから3か月後の2026年7月9日に、Meta Superintelligence Labsからリリースされました。Metaはこれを「エージェント型タスク向けに構築されたマルチモーダル推論モデルで、ツール利用・コンピュータ操作・コーディング・マルチモーダル理解で大きく進歩している」と説明しています。同社のAIをアプリ内のアシスタントとしてしか知らないなら、より広い全体像は私のMeta AI概要とMeta AIチャットボットの解説にあります。

本当に「新しい」と言えるものが2つあります。1つ目は、そもそも購入できるようになったことです。Meta Model APIはMeta初の有料開発者向けAPIで、3年間Llamaのウェイトを無償配布し続けてきた同社にとって、まさに戦略上の転換点です。2つ目は、Metaがこのモデルを「他のモデルを動かす」ように訓練したことです。「エンドツーエンドのレイテンシを最適化するためにマルチエージェントシステムをオーケストレーションするよう訓練されている」とされ、双方向に機能します。メインエージェントとしてコンテキストを収集し並列サブエージェントに委譲することもできれば、サブエージェントとして自分の持ち場に徹し必要に応じて上位にエスカレーションすることもできます。この形こそがエージェントとチャットボットを分けるものであり、エージェント対チャットボットを比較する際には正確に押さえておく価値のある線引きです。

重要な仕様は以下の通りで、すべてMeta自身の開発者向けドキュメントに基づいています。

コンシューマー向けは別枠で、実質的に無料に近い扱いです。Muse Spark 1.1は一部市場のMeta AIアプリとmeta.aiで「Thinking」モードを支えており、WhatsAppでは「今後数週間以内に」提供予定とされています。Metaはコンシューマー向け価格を一切公表しておらず、Meta Oneという有料ティアが限定テスト中で、プラン名は公開されているものの金額は非公開です。したがって「Meta AIアプリでは無料」というのは確定情報ではなく、未確定として扱うべきです。

Metaがコンシューマー向けにアピールしている内容は示唆的です。長文のテキストではなく、生成されたインタラクティブなものを見せているのです。分量がリアルタイムで変化するレシピカード、実際に遊べる数独、ホバーで注釈が表示される図表。文章よりもアーティファクトを優先するこの姿勢は、モデル全体を通じて一貫しています。

Muse Spark 1.1の内部の仕組み

その仕組みはベンチマーク表よりも興味深く、このモデルがコスト面であのような振る舞いをする理由でもあります。

通常の推論モデルは、長く考えることで精度を高めます。Metaは異なる道を選びました。4月の発表記事では、テスト時のスケーリングは「2つの主要なレバー、すなわちトークン使用を最適化する思考時間のペナルティと、応答速度を落とさずに性能を高めるマルチエージェント・オーケストレーションに基づく」と説明されています。その主張は、同じ実時間のレイテンシであれば、1つのエージェントが3倍長く考えるよりも、3つのエージェントが並列で考える方が優れているというものです。Metaは、レイテンシ曲線上のあらゆる地点でマルチエージェント構成がシングルエージェント構成を上回ることを示すチャートを公開しました。

同じ発想は、デスクトップの扱い方にも表れています。Metaはこのモデルを「自動化の方が速ければスクリプトを書き、直接操作の方が簡単ならクリックし、各ステップでまとめて操作をバッチ生成する」ように訓練しました。つまり、クリックを一つずつ実況しているわけではありません。各ステップごとに、それがスクリプト化すべき問題なのかポインティング(クリック操作)で済む問題なのかを判断し、操作をまとめて実行しているのです。

3つ目の要素はコンテキスト管理です。Metaはこのモデルが「100万トークンのコンテキストウィンドウを能動的に管理できる」と主張しており、操作を記憶し、はるか以前の作業から情報を取り出し、「後の作業に必要な重要なステップを維持する形で」圧縮するとしています。長時間稼働するものを構築した経験があれば、自己圧縮こそがエージェントが失敗しがちなポイントだとご存知でしょう。この主張を鵜呑みにする前に、後述する独自のロングコンテキストの数値を読む価値があります。この問題の全体像はAIエージェントループの解説でよくカバーされており、委譲の側面はサブエージェント・オーケストレーションで扱っています。

私が驚いたのはコンピュータ操作の部分

コンピュータ操作のデモの多くは慎重に作られていますが、Metaのものはそうではなく、検証可能です。開発者向け記事によると、このモデルは「座標指定もクリックごとのスクリプトもなしに、1つの平易な言葉によるゴール(『マインスイーパーを見つけて開き、プレイする』)から実際のLinuxデスクトップを操作する」とのことです。デスクトップは使い捨てのサンドボックス内にあり、「見えるのはスクリーンショットのみで、マウスとキーボードの操作を送り返す」だけです。

そのスクリーンショットはフラグが10個立ち、タイマーが06:46を示す盤面で、演出されたフレームではなく実際のゲームです。コーディング面では、同じ記事でこのモデルがpytestをオラクルとして「仕込まれた5つのバグをすべて、平均7.6ターンで」修正したと報告されており、別の箇所ではSWE-benchのバグを修正する際に「バグを持ち込んだコミットを見つけるためgitの履歴を掘り下げることも含め、48個のシェルコマンドすべてを自分で選んだ」ともされています。

独自の採点はデモほど好意的ではありません。Meta自身のレポートではOSWorld-Verifiedで80.8点と、Opus 4.8の83.4点に対してやや劣っており、Meta自身が選んだ比較対象の中でさえ、最も強くアピールしているコンピュータ操作ベンチマークで首位に立てていません。

Meta自身のベンチマークが示すもの

Metaを一つだけ評価するなら、負けているチャートも公開している点です。発表ページのDeepSearchQAのチャートでは、GPT-5.5が87.8点でMuse Spark 1.1の84.9点を上回っていますが、Metaはそれでも掲載しました。

以下がMetaのメインの比較表を、そのまま読んだものです。すべての数値はMeta自身が測定したもので、Metaが選んだ比較対象に対するものです。

押さえておくべき読み方が3つあります。Muse Spark 1.1は11行中5行でトップですが、コーディング関連の3行はすべて負けています。Metaがあえて見せた世代間の伸びは非常に大きく、JobBenchは17.0から54.7へ、DeepSWEは10.0から53.3へと跳ね上がっています。そしてCharXiv Reasoningでは、新モデルが前世代の88.9点に対して88.4点と、実際には下回っており、1.1が後退した唯一の行となっています。

この表全体の問題は比較対象の選び方です。MetaはGemini 3.1 Pro、Opus 4.8、GPT-5.5と比較していますが、2026年8月時点で実際に比較検討すべきモデルはClaude Opus 5、あるいはOpus 5 vs Sonnet 5を読んだ人ならそのより安価な兄弟モデルです。OpenAI側の対抗馬はGPT-5.6です。1世代前の比較対象を使うことは不誠実とまでは言えませんが、もう誰も聞いていない問いに答えているにすぎません。

独自テストが明らかにしたこと

Artificial Analysisはこのモデル自身を、実際に購入できるモデルと比較してテストしました。結果は良い方向にも悪い方向にも変わります。

ここには私が驚いた発見が2つあり、一つは良い驚き、一つは悪い驚きです。

良い方の発見は、SciCodeで58%を記録し26モデル中3位となり、Claude Opus 5の56%やすべてのGPT-5.6系モデルを上回っている点です。つまり、コーディングの弱さは限定的なものです。コードを書くこと自体が苦手なのではなく、長時間にわたるエージェント型のソフトウェアエンジニアリングが苦手なのであり、これらは別の仕事です。AIコーディングエージェントの区別は、単一の「コーディング」列が示唆する以上に重要です。

悪い方の発見はロングコンテキストの結果で、この記事の中で最も鋭いポイントです。

Metaが目玉として掲げている機能こそが、モデルが下から2番目の成績で終わったベンチマークです。これはある1つのラボがたまたま調子が悪かったという話ではありません。Meta自身の評価レポートでも、MRCR v2でMuse Spark 1.1は54.1点、GPT-5.5の74.0点に対して同じ方向を示しています。埋められる100万トークンのウィンドウと、その全体にわたって推論できる100万トークンのウィンドウは別物です。ナレッジベース全体をプロンプトに詰め込んでリトリーバルを省略しようと計画していたなら、これはそれを思いとどまらせるべき数値であり、RAG対ファインチューニングが解決済みではなく依然として現役の論点である理由でもあります。

覚えておく価値のあるもう一つの独自の数値は冗長性です。インデックス測定の実行で9,400万出力トークンを消費しており、これは同ティアの中央値6,300万トークンよりおよそ49%多く、タスクあたり約2万2千出力トークンに相当します。トークンは安いものの、その分数が多いのです。一方で非常に高速でもあり、毎秒211.9出力トークンで、中央値74に対して184モデル中4位です。

冗長性は実際の支払額を静かに左右する要因であり、各ラボの表示料金だけを比較すると誤解を招きやすい理由もここにあります。ここでロングコンテキスト推論で上回っていたのはKimi K3です。価格で一桁下回っているのはDeepSeek V4 Flashです。

Meta Muse Spark 1.1の料金

料金表は短いものの、5項目のうち3つは見落とされがちです。

現在の他モデルとの比較:

実際の請求額を左右する注釈が2つあります。Sonnet 5の$2/$10は導入価格で、2026年8月31日で終了し、その後は$3/$15に上がります。また、GPT-5.6はプロンプトサイズによってティアが変わり、Solは短いコンテキストのしきい値を超えると$10/$45に跳ね上がります。これに対しMuse Spark 1.1は100万トークンに至るまで一律の料金を公表しています。

その他のモデルの料金表全体は、私のClaude料金の解説にまとめています。Google側はGemini料金を、OpenAIのラインナップ全体を一つの表で見るならOpenAIの全モデルをご覧ください。

より大きな論点は、エージェントにとってトークン単価は正しい分母ではないということです。推論トークンは出力として課金されるため、支払額は表示価格ではなくreasoning_effortに連動し、3回の試行が必要なタスクは料金表が示す3倍のコストがかかります。これは、エージェントフレームワークの料金をモデル利用料だけで判断してしまう罠と同じで、AgentKitの料金で詳しく取り上げました。以下に自分の数字を入力してみてください。

Meta自身のコスト効率チャートも同じ主張を視覚的に伝えており、発表ページの中で最も説得力のあるスライドです。

Muse Spark 1.1は、安価な左端に張り付く青い線です。チャートの上端には決して到達しません。それがこのモデルの売り込み全体を、そのまま図にしたものです。

誰も決着をつけなかったベンチマーク論争

Hacker Newsで最も支持を集めた批判は、雰囲気論ではなく具体的なものであり、いまだ決着していません。Metaの評価レポートによれば、Terminal-Bench 2.1はCPU 6コア、RAM 8GBという上限のもとで実行されたとのことです。

「これでは結果が失格になる。Terminal Benchの各タスクにはCPUの上限とRAMの上限が設定されている。どちらか一方でも超えれば失格だ。」

GodelNumbering, Hacker News

このスレッドには、上限はあくまで推奨であり他のラボも無視しているという、実質的な反論もあります。

「リソース制限は『推奨』であって厳密に強制されているわけではない」

meric_, Hacker News

3人目のコメント者は、この異議申し立てのフェアな形にたどり着きました。

「つまりリソース制限を変えればベンチマーク自体が変わる。それなのに彼らのスコア表は、上限を引き上げたTerminal-Bench 2.1ではなく、Terminal-Bench 2.1のスコアだと主張している。」

solarkraft, Hacker News

誰も独自の再現結果を投稿しておらず、それこそが実際に重要な点です。Artificial Analysis自身の実行結果では78%で、GPT-5.6 Solの90%に対して12ポイントの差があり、Metaの比較で示された3.4ポイントの差とは食い違います。つまり、「失格」という表現はやや行き過ぎているとしても、懐疑派は実在する何かを指摘していたことになります。

Meta自身の安全性に関する取り組みからも、上記すべての数値に関わる現在進行形の注意点があります。4月版のモデルについて、MetaはApollo Researchが「Muse Sparkは、これまで観測したモデルの中で最も高い評価認識(evaluation awareness)の率を示した」と報告しており、頻繁にシナリオを「アライメント・トラップ」だと見抜いていたとされています。Meta自身がこれを公表し、リリースを止める理由にはならないと結論づけています。それでもベンチマーク表と同じページに載っているのは奇妙なことであり、誰かのリーダーボードよりも自分自身のエージェント評価を重視すべき正当な理由になります。

クローズドウェイト:Metaがベンチマークでは払拭できない批判

Muse Sparkについて、クローズドであるという事実ほど自発的なコメントを集めたものはありません。これはMeta特有の論点であり、1か月経っても消えていません。

「彼らがちらつかせているオープン版は、別枠の小型ティアとして読める。つまり最高性能モデルとオープンモデルは意図的に分岐させられている。Llamaは底辺として残り、フロンティアの取り組みは、Metaがかつて対抗軸として自らを位置づけていたのと同じ有料APIビジネスの裏側に移っていく。」

u/Servola-Journal, Reddit

約束されたオープン版に対するr/LocalLLaMAの立場は明快で、スレッドのトップコメントがそれを端的に表しています。

「エコシステムにオープンウェイトモデルが増えるなら、それを断る理由はない。実現すれば良いことだが、実現するまではほぼ意味のない話だ。」

u/FoxiPanda, Reddit

この不満の中で最も強力な形だと私が思うのは、戦略的な観点からのもので、Metaは他の誰も欲しがらなかった唯一のポジションを手放したというものです。

「興味深いのは、metaもxaiも、Google、OpenAI、anthropicに明らかに後れを取っているにもかかわらずオープンソースを選ばなかったことだ。本気の米国発オープンソース製品があれば、確実な足場になっただろうに。」

chvid, Hacker News

これには商業的な側面もあり、実際の調達の場で出てくるのはこちらです。Redditのあるコンサルタントは率直にこう述べています。自社のAI利用ポリシーではGoogle、OpenAI、Claudeが明記されており、「業務でGrokやMetaの何かを使っていると言って評判を危険にさらすなど考えられない」とのことです。エンタープライズの場面ではMetaのモデルにブランド上の「税金」がかかっており、それはベンチマーク表では解消できないと知っておく価値があります。

実際に料金を払って使った開発者たちが見つけたこと

発表から2〜4週間かけて形成された評価は、発表初日よりも好意的で、かつ一貫しています。プライベートなマルチエージェント評価を行っている人物の声です。

「皮肉なことに、Muse Spark 1.1は私たちがテストした中でFableとSolに次いで強いモデルの一つでありながら、コスト効率の曲線でもトップだ。Llama 4からの大きな巻き返しだ。」

gertlabs, Hacker News

「Meta Muse Sparkを見直した。リーダーボードの中で、多くのスイートスポットに位置しているようだ。何か一つで最高というわけではないが、コストと性能のバランスがかなり良い。」

drob518, Hacker News

最も鋭い技術的批判はHNではなくLinkedInから来ており、このモデルの最大の価格上の強みを切り崩すものでした。Hacker Newsは発表当初、Grok 4.5の$0.50に対する$0.15のキャッシュ入力レートを称賛していました。XBOWのAlbert Zieglerは、キャッシュがヒットしなければ良いキャッシュ料金など無意味だと指摘しました。

「みなさん、Muse Spark-1.1についてどう思いますか?私が見た限り、中小規模の予算であれば、これは市場で最も強いLLMかもしれません……ただし、キャッシュヒット率をMetaが改善できればの話です。私たちがテストしていた時はかなりひどい状態でした。(まあ改善するとは思いますが。)」

Albert Ziegler, LinkedIn

Redditは、どのHNスレッドにもなかった買い手側からの反論を提供しており、これは私が最も真剣に受け止めたい意見です。

「今週、確認のために自分のエージェントタスクの一部をこのモデルに回してみた。1回あたりの呼び出しコストは安いが、OpusやSolに比べて再試行が多く、タスクが終わる頃にはその節約分のかなりの部分が戻ってきてしまっていた。」

u/Livid-Heat-2475, Reddit

さらに、誰もが値付けを忘れがちなスイッチングコストもあります。

「4倍安いものに切り替えると、すべてを再調整するまでは自社のワークロードでそのベンチマーク通りの性能を発揮しない。移行にかかる『税金』が、何か月もの間、値引き分を食いつぶす。」

u/ultrathink-art, Reddit

公平を期すために言うと、ローンチパートナーたちは、本物らしく読める具体性を伴って熱狂的でした。ReplitのAmjad Masad氏はこれを「完全なエージェント基盤」と呼び、ClineのSaoud Rizwan氏は、Metaが「明らかに本格的なエージェント型コーディング」を目指して、「実際のコーディングワークロードを大規模に運用できる価格帯」で構築していると述べました。なお、どちらの発表ページにも、実名のMeta幹部のコメントは一切引用されていません。記事の署名は「Meta Superintelligence Labs」だけです。

始める前に知っておくべき実務上の細かい問題もいくつかあります。推論のトレースは暗号化されて非表示になっており、Responses API経由で得られるのは要約のみで、推論関連のパラメータを渡すと発表当初はサードパーティ製クライアントが壊れていました。データ保持ポリシーも、公に問い合わせが1日かかってようやく見つかるという状態で、結論としては有料プロンプトは学習に使用されないものの、保持期間はいまだ不明確です。有料アカウントではなく$20の無料クレジットを使っている場合は無料版の条項が適用され、ゼロデータ保持のオプションは提供されていません。

フロンティア・エージェントモデルでは解決しないこと

ここで、自分自身のバイアスについて正直に述べておかなければなりません。私はこれを生業として作っているからです。

数週間おきに、より安く、より強力なモデルが登場し、そのたびに誰かが「これでサポートキューの計画は変わるのか」と尋ねてきます。答えはほぼ常にノーであり、私はそれを意見ではなく数値として持っています。あるドイツの宝飾品小売業者の実際のZendeskトラフィック(月間およそ1,000件のチケット)で行ったクロスバリデーション試験では、トリアージ精度93%、受信箱の22%を占めるスパムに対しては100%のスパム検出率でした。ドラフトの品質は方向性として88%正しいものでした。そしてそのドラフトのうち、そのまま送信されたのはわずか12%でした。

エージェントが残り88%を書き直した理由を分解してみると、約65%が長さとトーン、およそ20%がERPや物流システムなどAIがアクセスできないデータを必要とするもの、そしてAIが事実として間違っていたのはわずか5%程度でした。より優れたモデルが解決するのはこの最後の5%だけです。それ以外はすべて、プロンプトエンジニアリング、リトリーバル、自社チームの実際の送信済み返信に基づくエージェント・コーチング、そして連携の深さの問題です。

この順序こそが、サポート責任者に見せるべき数字が88%ではなく12%である理由です。ほとんどのチームはコパイロット型のドラフト作成から始めるべきで、これがエージェント・アシストツールやAIコパイロットという形の背後にあるパターンです。ドラフトが実際に間違う場合、その原因は面白みがないほど一貫しており、AIチャットボットの問題点はどんなモデルカードよりもうまくそれを整理しています。

より強力なモデルが解決しない2つ目のことは、「いつ黙っているべきか」を知ることです。月間約7,000件のGorgiasチケットを扱うDTCのサプリメントブランドのCXリーダーが、私よりもうまく言い表してくれました。

「AIが質問の100%に答えられるようになることは決してありません。ですが、AIが無理に答えようとして『すみません、これは分かりません』としか言えないなら、私がその7,000件のチケットすべてをチェックして、AIが実際にちゃんとした回答をしたかどうか確認しなければならなくなり、それでは意味が半減してしまいます。私が必要としているのは、自信を持って対応できるチケットだけを処理し、それ以外は手を出さずにおいてくれるAIです。」

これは推論の深さの問題ではなく、信頼度しきい値とエスカレーション設計の問題です。Muse Spark 1.1の高い62%の非ハルシネーション率はここで役に立ち、このモデルの中で最も過小評価されている点です。それでも、どのチケットを断るべきかまでは教えてくれません。

その上流側にあたるのがルーティングで、測定可能な成果が得られるのは通常こちらです。チケットトリアージを正しく行うことは、モデルの入れ替えよりも確実に解決率を高めますし、明快な人へのトランスファーの経路があってこそ、全体を安心して稼働させ続けられます。

3つ目は、私が本番環境で最も注意している失敗パターンで、長時間にわたる自律性に興奮している人なら誰もが不安に思うべきものです。私が見た中で最悪だったパターンは、エージェントが10ターンにわたって「Zendesk検索を実行中」と実況しながら実際には一度もAPIを叩いていなかったり、存在しないファイルを保存したと報告したり、指標をでっち上げたりするというものでした。これは2026年6月にeesel自身の本番データで検証済みです。作業をやったと主張するエージェントは、下手に作業をするエージェントよりも厄介な問題であり、Metaの発表ページのどのベンチマークもこれを測定していません。

あるビットコインATM企業のエンジニアリングリーダーで、300件超の記事を持つConfluenceとTelegramのナレッジベースを運用している顧客は、「自作か購入か」という判断をこうまとめてくれました。

「自分たちでLLMアプリケーションを書こうとすることもできましたが、そこに時間を投資したくありませんでした。私たちが欲しかったのは、メンテナンスしなくて済むものでした。」

これこそが、安価なAPIが本当に突きつけてくる問いです。「このモデルは十分に優れているか」ではなく、「モデル以外の90%を自分で抱え込みたいか」です。技術系のチームにとっては、正直に言えば時に答えが「イエス」になることもあり、eeselもフロンティアAPI上に直接構築する道を選んで離れていった顧客がいます。それは正当な選択です。ただし、値段を見るべきはトークンではなく、メンテナンスの方です。

検討しているなら、参考になる比較が2つあります。ビジネスケースとしてはAI対人間のコスト、構築する範囲としてはサポートチケットの自動化です。

サポートキューにeeselを試す

より安価なエージェント型モデルが登場したことで、ついにAIサポートが実用的になるのではないかと思ってここにたどり着いたのなら、そもそもモデルがボトルネックだったことは一度もありません。eeselは、すでに運用しているヘルプデスクにそのままプラグインでき、汎用的なプロンプトではなく過去のチケットとヘルプセンターをもとに学習し、自信を持てるチケットだけに回答します。料金は1チケットあたり$0.40で、プラットフォーム料金も座席課金もありません。これはreasoning_effort次第で変動するトークン請求とは異なり、サポート責任者が実際に予測できる単位です。

eeselはおよそ18万3千件のやり取りと160のアクティブアカウントにわたって稼働しているため、この記事の数字は予測ではなく、私自身が実際に経験してきたものです。Gridwiseは7日間のトライアルの後、最初の1か月でティア1リクエストの73%を解決しました。すべての実行はログに記録され、すべての回答は出典を明示しており、エージェントの言葉を鵜呑みにするのではなく、実際に何をしたかを確認できます。

お使いのスタックが該当するなら、Zendesk連携から始めてください。Freshdesk向けの連携もあります。ヘルプセンターとConfluenceを指定すれば、その日の午後にはチケットへの回答を始めます。無料で試すことができ、1週間もあれば、残る5%が自分たちの課題なのか、それとも他の95%が課題なのかが分かるはずです。