レビューとは何を指すか、そして何を検証できなかったか
Muse Spark 1.1は2026年7月9日にリリースされたので、実際の環境で使われ始めてから4日ではなく、およそ4週間が経っている。これは重要な違いだ。今では発表当日の雰囲気論ではなく、独立した検証データが存在する。Meta全体の状況については、私のMeta AIの概観記事にまとめている。
フロンティアモデルの発表にしては、一次情報の量が少ない。その理由は構造的なものだ。Meta Model APIは米国限定で公開された。開発者からは、ベトナム、カナダ、アルゼンチンから初日にブロックされたとの報告があり、OpenRouterに載るのはおよそ1週間後だった。あるコメント投稿者は、その実務上の影響を率直に書いている。
「Openrouterで使えないと、本当にテストしづらい。Grok 4.5やGPT-5.6 Lunaと比較しようと思っていたが、まともに使えると分かるまでMetaにわざわざサインアップする気にはなれない。」
つまり413件のコメントが付いた発表スレッドからも、実使用のレポートはほんの一握りしか出てこなかった。以下の内容は主に3種類の情報源に基づいている。Artificial Analysisによる独立検証、Meta自身による105ページの評価レポート、そして実際に動かすことに成功したごく少数のエンジニアたちだ。誰も検証していない箇所については、無理に埋めず、その旨を明記する。
この1枚のチャートが、他のすべての結果を説明する
Intelligence Indexを構成する各ベンチマークにおけるMuse Spark 1.1の順位を示す。同じモデル、同じ週、同じ1つのラボがすべてのテストを実施している。
たいていのモデルは、良い意味で「退屈」だ。どのテストでもほぼ同じパーセンタイルに収まるので、1つの数字が残りを予測してくれる。しかしこのモデルは違う。最高順位と最低順位の差は、多くの価格帯のトップとボトムの差全体よりも大きい。
だからこそ、誰もが繰り返す「50.6対Opus 5の60.7」という見出し的な比較は、行動につながる情報をほとんど与えてくれない。それは優れた結果1つと、悪い結果1つを平均しているに過ぎない。本当に知るべきなのは、自分がその2つのうちどちらを買おうとしているかだ。
実際に勝っている点
ここに挙げる3点は本物であり、この後に続く批判の中に埋もれさせたくない。
コード生成がうまい。 「価格の割に」うまいのではなく、単純にうまい。SciCodeではClaude Opus 5、GPT-5.6 Sol、Grok 4.5を上回る。発表後によく言われた「Metaはコーディングで遅れている」という言説は、コード生成そのものではなく長時間のエージェント実行についての話であり、この2つはまったく別の仕事だ。
| モデル | SciCode |
|---|---|
| Kimi K3 (max) | 58.7% |
| Muse Spark 1.1 (xhigh) | 58.2% |
| GPT-5.6 Sol (high) | 56.9% |
| Claude Opus 5 (max) | 55.7% |
| Grok 4.5 (high) | 54.1% |
| Gemini 3.6 Flash | 52.7% |
| DeepSeek V4 Flash | 49.9% |
ボード上で最速だ。 秒間217.4出力トークンで、Claude Opus 5の55.7を大きく上回り、Gemini 3.6 Flashの213.5をわずかに上回る。ユーザー向けの用途であれば、誰かが計測するまでもなく、ユーザーは4倍のスループットの差を体感する。
キャッシュ料金は、この製品の中で最もよく設計された部分だ。 100万トークンあたり0.15ドルで88%の割引となり、それが自動的に適用され、管理すべきキャッシュキーもない。あるエンジニアは、なぜ表示価格よりもこの比率のほうが重要なのかを指摘している。
「キャッシュ入力料金の比率が優れている。Grok 4.5は$2/$6で登場したのに、キャッシュ入力トークン100万あたり0.50ドルをこっそり請求してくる。それってOpus 4.8と同じくらい高いじゃないか!」
これらを組み合わせると、向いている用途の形がはっきり見えてくる。短いプロンプト、安定したシステムプロンプト、大量の処理、1呼び出しにつき1つの判断。バッチ分類、タグ付け、抽出、ルーティングなどだ。料金体系の全容はMuse Spark 1.1の料金の記事にまとめている。他社との比較はClaudeの料金から見てほしい。OpenAIのラインナップはすべてのOpenAIモデルの1つの表にまとまっている。
崩れる場面
Metaはこれをエージェントモデルとして位置づけている。その発表は、ツール利用やマルチステップのワークフローを前面に押し出しており、それはエージェントとチャットボットを分けるまさにその境界線にあたる。だから公平なテストとは、独立系のエージェント評価ということになる。ここからレビューの流れが変わる。
| エージェント系ベンチマーク | Muse Spark 1.1 | セット内最高 | 順位 |
|---|---|---|---|
| AA-Briefcase Elo | 868.9 | Claude Opus 5が1718.7 | 19機種中18位 |
| GDPval-AA v2 Elo | 1370.6 | Claude Opus 5が1852.0 | 7機種中最下位 |
| Tau-3 Banking | 25.2% | Kimi K3が34.0% | 10機種中9位 |
この矛盾は見逃しようがない。エージェント型のツール利用を売りにしたモデルが、独立系のボードではエージェント性能で最下位クラスなのだ。GDPvalではOpus 5に481 Elo差をつけられており、信頼区間はそれより上のどのモデルとも重ならない。エージェント型のツール利用では、入力0.14ドル・出力0.28ドルのDeepSeek V4 Flashにも及ばない。
Metaもこれを完全には否定していない。自社の評価レポートでも、「長時間にわたるエージェントタスク(DeepSWEやDeepSearchQAなど)については、大幅な改善はいまだ最高性能の競合モデルに遅れをとっているか、同等にとどまっている」と認めている。ただしこの記述の比較対象はOpus 4.8とGPT-5.5であり、どちらも今買うべきモデルより1世代前のものだ。
コミュニティの見方もおおむね同じ結論に落ち着いている。あるコメント投稿者は、このモデルがコーディングのリーダーボードの上位に現れているのを見て、それをリーダーボード自体が壊れている証拠だとみなした。
「Typescript(Combined)のトップ3がGrok 4.5、Muse Spark 1.1(笑)、Gemini 3.5! Flashだなんて、このベンチマークが壊れているのは明らかだ」
最も鋭い表現は、4つのモデルによる作品対決の中から出てきた。ある参加者は、Muse Sparkがそのセットの中で最良の単一成果物を生み出したにもかかわらず、5点中2点しか付かなかったことに戸惑っていた。その説明こそが、このモデルの本質を一文で言い表している。
「2/5というのは品質の点数ではなく、そこに書いてある通り一貫性の点数だ。全リンクは下部にある。Sparkの試みのほとんどは失敗している」
高い天井。低い底。このレビューの他のすべては、そこから導かれる。
これまでに公開された中で最も長い1回のセッションも、同じ結論に行き着く。コーディング用CLI経由でこのモデルを3時間使い続けた開発者からの報告だ。
「3時間ぶっ通しで試してみたが、正直がっかりした。最近のMetaに何が起きているのか分からないが、彼らはOSSモデルの火付け役となったLlamaの生みの親だったはずだ。今はクローズドソースになっているとはいえ、感覚としてはKimi 2.7とGLM 5.2の間くらいで、Opus 4.8 mediumやSonnet5には遠く及ばない」
この報告は、あまり重く受け止めすぎないほうがいい。これは1人のある午後の体験談に過ぎず、彼自身が計測した数字は何も示されていない。実際、ほとんど誰もそれを示していない。RedditとHacker Newsを4週間分見渡しても、実際にこのモデルを動かした一次報告はせいぜい十数件で、そのうち自分で計測した数値を公表している者は1人もいない。100万トークンのウィンドウを公の場でストレステストした人もいない。理由の一部は地域制限、もう一部は、APIキーを入手できないモデルは趣味レベルの開発者にベンチマークされないからだ。
この仕事、Muse Spark 1.1に任せるべきか?
実際に抱えている仕事を選んでほしい。答えは価格以上に変わる。
これはまさにこのモデルのために作られた仕事だ。短い入力、1つの判断、大量処理、そして自動キャッシュ料金が残りを片付けてくれる。
秒間217.4出力トークンで動作し、ボード上最速。安定したシステムプロンプトであれば、1.25ドルではなく100万トークンあたり0.15ドルで課金される。
誰もが繰り返す「コーディングの弱さ」という話は、長時間のエージェント実行についてのものであり、コードを書くこと自体の話ではない。単一の関数を書かせれば、業界トップクラスに近い。
SciCodeでは58.2%で8機種中2位となり、55.7%のClaude Opus 5や、テストされたすべてのGPT-5.6系バリアントを上回る。
長時間にわたる仕事では方向を見失いがちで、リトライが静かにコスト削減分を食いつぶしていく。数時間かかる実行には、より強力なモデルを残しておくべきだ。
AA-BriefcaseではElo 868.9で19機種中18位となり、Gemini 3.6 FlashやNemotron 3 Ultraよりも下だ。
100万トークンのウィンドウは目玉機能でありながら、計測された結果の中では最も弱い部類に入る。まず検索(リトリーバル)し、それからプロンプトを組み立てること。アーカイブをまるごと投げ込んではいけない。
長文コンテキスト推論は26機種中25位で、Meta自身のレポートでもMRCR v2で54.1と、GPT-5.5の74.0に及ばない。
コンピュータ操作のデモはやらせではなく本物で検証可能であり、ステップごとにスクリプトを使うかクリックするかを判断している。ただし、最も強くアピールしているベンチマークでも首位には立てていない。
Meta自身のレポートではOSWorld-Verifiedで80.8となっており、83.4のClaude Opus 4.8には及ばない。
事実をでっち上げないことと、黙るべき時を知っていることは別物であり、これはMeta自身のテストによればこのモデルのアライメントの中で最も弱い項目だ。
Metaのペトリ評価では入力ハルシネーションが1.67で、GPT-5.5の1.22やClaude Opus 4.8の1.34より悪い。
Meta自身がドキュメント化している失敗モード
これは、何かに組み込む前にぜひ知っておきたい部分だ。発表記事ではなく、ドキュメントの奥に埋もれている。
Muse Spark 1.1は思考の連鎖(chain of thought)を非公開にしており、これ自体は今では普通のことだ。異例なのは、最も一般的な統合経路で何が起きるかという点だ。Meta自身の推論ドキュメントによれば、Chat Completionsではreasoning_contentフィールドが呼び出し元に届く前に空へと編集され、「再生できるものが何もなく、各ターンはゼロから推論し直すことになる」とされている。
Metaのコーディングエージェントガイドはその結果をはっきりと書いている。モデルは「自分の以前の思考の筋道を見失い、すでに終えた作業を繰り返したり、以前のステップと矛盾したりするなど、不安定な振る舞いをすることがある」という。
マルチステップのエージェントワークを売りにしたモデルが、多くのツールがデフォルトで使う経路では、ターンの間に自分自身の推論を忘れてしまう。複数ターンにわたる推論が維持されるのはResponses APIだけであり、そこではサーバー側がprevious_response_idを通じてコンテキストを保持してくれる。
これは机上の空論ではない。発表後に出た中で最も詳細な実機レポートが、まさにこの種の問題を描写している。それを書いたのは、コンテナ内でCodexをこのAPIに対して動かしたエンジニアだ。
「これは何らかのパースエラーか統合エラーで、おそらくCodexがサーバー側のツール呼び出しや、Metaがそのidをどう扱うかを想定していないことが原因だと思う……museでCodexを動かした最初の数回は、ウェブ検索以外の最初の呼び出しで必ず失敗していた。」
彼はそれを修正し、モデルについては前向きな評価を保っていた。重要なのは、Meta自身のドキュメントと、実際のハーネスに組み込んだ最初の人物という、独立した2つの情報源が同じ根本原因にたどり着いている点だ。エージェント周りの配線は独自仕様であり、サードパーティ製のハーネスはそこでつまずく。
みんなが引用しているハルシネーション数値は、実は見るべき数値ではない
ここで、私自身の以前の記事も含めて出回っている「都合の良い解釈」を訂正しておく必要がある。
Muse Spark 1.1は確かに良好な「ハルシネーションを起こさない率」を持っている。つまり、それなりの頻度ででっち上げるのではなく回答を拒否するということだ。これは事実であり、それなりに価値がある。しかし、正解には加点しハルシネーションには減点する複合指標であるナレッジ信頼性指数では18.0となる。これは自身のモデルページに掲載された12構成の中で最も低い数値だ。Claude Opus 5は31.3を記録している。
Meta自身のアライメントテストも、他社が公表したどの表現よりも率直な言葉でこれに同意している。評価レポート中のPetri 3.0評価にはこうある。「入力ハルシネーション(1.67)が主要な問題であり、GPT-5.5(1.22)やClaude 4.8 Opus(1.34)より高い」。同じ箇所では、ユーザーに対する欺瞞の増加と、過剰な拒否(オーバーリフューザル)の増加も指摘されている。
つまり、Meta自身を含む2つの独立した情報源が、同じ結論にたどり着いている。ハルシネーションは、このモデルの最も強い部分ではなく、最も弱い部分なのだ。
とはいえ、それすらも私がサポート導入の判断材料にする数値ではない。本当に見るべきなのはこちらだ。
あらゆるハルシネーションベンチマークは、モデルが世界についての事実をでっち上げるかどうかを測っている。しかし、サポート現場で実際に起きる失敗のほとんどは、そういう形をしていない。私たちが関わったあるB2Bテクニカルサポートチームは、Zendesk上で月間およそ200件、やがて2,000件規模にまで拡大しつつあるチケットを処理していたが、そこで本当のバージョンの問題に突き当たった。彼らのボットは、データベースに存在しない車種にも対応していると顧客に伝えてしまった。自社のヘルプセンター自体が「全車種に対応しています」と書いていたからだ。モデルはその情報源に忠実だった。情報源のほうが間違っていたのだ。
どのリーダーボードのスコアも、これを捉えることはできない。だからこそ、ナレッジベースでAIを学習させることは、モデルの問題である以前にコンテンツの問題であり、確信度のしきい値の設定の方が、推論性能のアップグレードよりも回答品質に効いてくる。
同じ論理は、より上流の工程にも当てはまる。チケットトリアージを正しく行うことは、モデルの入れ替えよりも確実に解決率を動かす。失敗のパターンは十分に一貫しているため、AIチャットボットの問題点というまとめ記事の方が、どんなモデルカードよりもよくカタログ化できている。
スピードは本物、ただし見るべき時計を間違えないこと
スループットの数値は本物であり、このモデルの単独指標としては最も優れたものだ。しかしレイテンシの数値には補足が必要だ。
| 指標 | Muse Spark 1.1 | Claude Opus 5 (max) |
|---|---|---|
| 出力速度 | 217.4 tok/s | 55.7 tok/s |
| 最初のトークンまでの時間 | 2.89秒 | - |
| 最初の回答が出るまでの思考時間 | 9.20秒 | - |
| 最初の回答トークンまでの時間 | 12.09秒 | 51.22秒 |
Metaが示す生の数値、2.89秒という最初のトークンまでの時間はボード上最速だ。ただし、これはユーザーが実際に体感するものではない。9.2秒の非表示の推論時間を加えると、実際に役立つ最初のトークンが届くのは12.09秒後になる。それでもOpus 5よりは十分に優れているので、結論自体は変わらない。とはいえ、見出しの数字が示唆するより4倍遅いのも事実だ。
同じ非表示の推論が、コストの話にも直結している。課金対象となる出力トークンの68%は、呼び出し側が決して目にすることのない思考部分だ。1タスクあたり推論トークン15,164に対して、回答トークンは7,232にとどまる。Artificial Analysisのフルインデックス実行では、合計約548ドルのうち360ドルが推論に費やされていた。トークン自体は安いが、考える習慣は高くつく。これが、AIカスタマーサービスのコストが料金表通りにはならない理由だ。
始める前に知っておくべき4つの落とし穴
どれも致命的な問題ではない。ただ、何も知らずに出くわすと、それぞれ半日は潰れる。
tool_choiceは"auto"しか受け付けない。 特定のツールを強制することはできず、"required"や"none"も存在しない。それ以外を指定すると400エラーが返ってくる。- 構造化出力はデフォルトで無効。
strict: falseの状態では、Metaのツール呼び出しリファレンスが、生成された引数は「スキーマに対してバリデーションが通る保証はない」と警告している。何かを実行する前に必ず検証すること。 - Claude Codeでは3つの別々の変更が必要。
/v1を含まないベースURL、5つすべてのモデルエイリアスをmuse-spark-1.1に付け替えること、そしてANTHROPIC_API_KEYの代わりにANTHROPIC_AUTH_TOKENを使うこと。 - MCPは謳われているが文書化されていない。 発表記事では、このモデルはMCPサーバーやカスタムスキルにも汎化すると書かれている。しかしツール呼び出しリファレンスにはそのどちらも記載がない。実際に示されている拡張手段は、開発者定義のツールのみだ。
また、カスタムツールが暴走するループに対するサーバー側の上限も存在しない。max_tool_callsはMetaの組み込みツールのみを制限するもので、これはAIエージェントループが空回りするのを見たことがある人なら知っておく価値がある。委任(デリゲーション)側の話はサブエージェントのオーケストレーションで扱っており、自分自身でテストすべき理由はエージェント評価にまとめている。
Metaがまだ公表していないこと
情報の欠落もレビューの材料になる。そしてこのリストは、発表から4週間が経った時点にしては長すぎる。
| 未公表の項目 | なぜ重要か |
|---|---|
| 最大出力トークン数 | リクエストの上限を見積もれない |
| 知識のカットオフ日 | 情報の陳腐化について判断できない |
| パラメータ数 | アーキテクチャの詳細が一切分からない |
| 地域の許可リスト | 分かっていることはすべてブロックされたユーザーからの情報のみ |
| データ保持期間 | 有料プロンプトは学習に使われないが、保持期間自体は明記されていない |
| 稼働率・可用性のSLA | 一切公表なし |
| キャッシュ可能な最小プレフィックス長 | 0.15ドルの料金は文書化されていない変数に依存している |
またMetaは公式のTerminal-Benchリーダーボードにも登場していないため、自己申告のスコアには第三者による確認がない。この数値をめぐる手法上の論争については、私のMuse Spark 1.1の概観記事で扱っている。まだ決着はついていない。
誰が買うべきで、誰が見送るべきか
買うべきなのは、大量かつ短時間で完結する仕事をこなす場合だ。分類、タグ付け、抽出、ルーティング、単一ファイルのコード生成など、1回の呼び出しが1つの回答を生み、それを何百万回も繰り返すようなケース。速度は本物で、キャッシュ料金も優秀であり、1タスクあたり約0.29ドルという価格は、Opus 5の料金との差が意味を持つほど大きい。
見送るべきなのは、長時間動くエージェント、ディープリサーチの実行、あるいは大規模なドキュメント群にまたがって推論しなければならない仕事の場合だ。独立系のエージェント関連の数値には、大きな開きがある。これは、リトライの回数まで含めて計算すると、結局GPT-5.6やOpus 5にお金を払ったほうが安上がりになる数少ないケースの一つだ。特にコーディング用のハーネスに関しては、現時点ではCodexの方が文書が充実している。
様子を見るべきなのは、米国外にいる場合、公表された保持ポリシーが必要な場合、あるいはオープンウェイトが必要な場合だ。最後の点については、実際に手元に置けるウェイトを持つフロンティア級に近いモデルとしてKimi K3が最も近い選択肢になる。クローズドウェイトへの転換は、この発表の中でコミュニティが最も許していない部分だ。
リーダーボードを追いかけている誰かによる、控えめだが的を射た見方があり、私もこれには同意していい。
「Meta Muse Sparkを見直した。リーダーボード上の多くのスイートスポットに位置しているようだ。特別何かで一番というわけではないが、コストとパフォーマンスのバランスがかなり良い。」
サポートキューにとって、これは何を変えるのか
ほとんど何も変わらない。新しいモデルが実際に何かを変えたときにそれに気づくことも仕事の一部である私が、あえてそう言っている。
数週間おきに、より安く、より速いモデルが登場し、誰かが「これでヘルプデスクの計画は書き換わるのか」と聞いてくる。正直な答えは、モデルは制約要因だったことなど一度もない、というものだ。eesel自身のクロスバリデーション済みの試験では、エージェントがAIの下書きを書き直したとき、その編集内容の約65%は長さとトーンに関するものだった。約20%はERPや物流システムなど、AIがアクセスできないデータを必要としていた。AIが事実として間違っていたのは、わずか5%程度に過ぎなかった。より優れたモデルが解決してくれるのは、その最後の5%だけだ。残りはプロンプトエンジニアリング、検索(リトリーバル)、チーム自身が実際に送った返信をもとにしたエージェントのコーチング、そして統合の深さの問題だ。
だからこそ、ほとんどのチームはコパイロット型の下書き作成から始めるべきであり、それがエージェントアシストツールの背後にあるパターンであり、きれいなエスカレーション経路がリーダーボードの順位よりも重要な理由でもある。技術スタックではなくビジネスケースを組み立てているなら、AI対人間のコストの方が有用な枠組みになる。
私が本番環境で最も注意深く見張っている失敗は、Metaの発表ページに載っているどのベンチマークも測っていないものだ。実際には実行していない検索を、あたかも実行したかのように語るエージェント。保存していないファイルを保存したと報告するエージェント。「作業をやったふりをする」エージェントは、「作業を下手にやる」エージェントよりも厄介な問題であり、ターンの間に自分自身の推論を忘れてしまうモデルを、自己申告の相手として信頼するわけにはいかない。
サポートに必要なのは生のモデルキーではなく、eeselだ
もしあなたが本当に必要としているのが、顧客のチケットに回答するAIなのだとしたら、今月どのモデルがインデックスの首位に立っているかは、ほとんど意味のある問いではない。本当に問うべきは、誰かに返信する前に、それが安全だと証明できるかどうかだ。
eeselはまさにその部分を中心に作られている。AIエージェントを自社の過去のチケットに対してシミュレーションで実行し、実際の過去のやり取りに対する回答を、顧客が1人でも目にする前に確認できる。まだ回答が十分なレベルに達していなければ、コパイロットモードから始めればいい。AIが下書きを作り、送信するのはあくまでチームのままだ。
セットアップは大掛かりなプロジェクトではなく、ヘルプデスクとの接続作業だ。数分でZendeskに接続し、すでに書かれているヘルプセンターを読み込み、100万トークン単位ではなく解決したチケットごとに課金される。だから請求額は、その日モデルがどれだけ饒舌だったかではなく、実際にこなした仕事量を反映する。無料で試すことができ、料金も公開されている。
総評
Muse Spark 1.1 は、間違ったラベルを貼られた良いモデルだ。Metaはこれをエージェントとして売り出したが、エージェント系のベンチマークこそがこのモデルの最悪の結果になっている。証拠に基づけば、これは現時点で入手できる、高速かつ安価な単発型モデルとしては最良の存在であり、優れたコード生成スコアと、他の追随を許さないキャッシュ料金を備えている。
Metaが分類したカテゴリーではなく、自分が抱えている仕事そのものを基準に判断すれば、このモデルの位置づけは簡単に見えてくる。何百万回もの短い呼び出しには、これを使えばいい。長時間の実行には、より強力なものを残しておくこと。そして100万トークンのウィンドウに惑わされて、検索(リトリーバル)をやめてしまわないこと。1タスクあたりのコストがOpus 5のおよそ8分の1であれば、正しい仕事において「2番目に良い」というポジションは、十分に成立するビジネスだ。
よくある質問
Meta Muse Spark 1.1 は実際のところ良いモデルなのか?
Muse Spark 1.1 はClaude Opus 5と比べてどうか?
Muse Spark 1.1 は高速か?
Muse Spark 1.1 はハルシネーションを起こすか?
Muse Spark 1.1 をClaude CodeやCodexで使えるか?
/v1を含まないベースURLが必要で、5つのモデルエイリアスすべてを付け替え、APIキーの代わりにANTHROPIC_AUTH_TOKENを使う必要がある。より大きな罠は、Chat Completionsの経路ではターン間でモデルの推論内容が破棄される点で、長時間の実行では同じ作業を繰り返したり、矛盾したりする。代わりにResponses APIを使うべきだ。Muse Spark 1.1 はカスタマーサポート用として価値があるか?
Meta Model APIはどこで使えるか?
Article by
Kurnia Kharisma Agung Samiadjie
Kurnia is a software engineer and writer at eesel AI with two years of SEO experience, writing about AI tools, helpdesk software, and customer support. He pairs a developer's understanding of how these products are built with search-driven research into what actually ranks and resonates with the people searching for them.
