1. コーディング
Muse Spark 1.3 で注目したいのは、単純な「コード性能」よりも処理効率です。
Meta の説明では、1.3 は前世代と比べて、
- ツール呼び出し回数が約20%減少
- タスク完了までのtoken消費が約25%減少
- 回答がより短く、要点中心になった
とされています。
実務では、この手の改善は意外と重要です。
複雑な開発タスクでは、ファイルを読む、ツールを呼ぶ、コードを修正する、結果を確認する、といった処理を何度も繰り返します。
余計なツール呼び出しが減れば、そのぶん処理時間もコストも下がります。
DeepSWE v1.1 では、Muse Spark 1.3 は 75.4 を記録。Meta が公開した比較表では GPT 5.6 Sol と Opus 5 を上回っています。
Artificial Analysis の独立評価でも、1.2 と比べて総合スコアが約4ポイント上がっています。
ベンチマークは参考になりますが、実際の開発では「無駄な手順が減るか」「長いタスクでも方向を見失わないか」のほうが重要です。
2. Agent
Muse Spark 1.3 は、長時間かかるコーディングタスクも重点的に改善されています。
Agent の仕事は、コードを1回生成して終わりではありません。
ファイルを確認し、ツールを使い、修正し、結果をチェックし、その内容を見て次の処理を決めます。
ここで厄介なのは、1回ミスすることより、最初の理解を間違えたまま処理を続けてしまうことです。
Meta によると、1.3 は指示が曖昧なとき、自分で勝手に補完するより、先に確認する傾向が強くなっています。
地味な変化ですが、長い Agent タスクではかなり大事です。
最初の段階で認識違いを止められれば、その後の無駄なツール呼び出しや修正も減らせます。
Meta AI責任者の Alexandr Wang は、すでに開発者の「二桁%」が Contributor を選んでいると話しています。
個人開発やプロトタイプ、初期段階の Agent では、厳格なデータ管理より API コストを優先したい開発者が一定数いる、ということでもあります。
3. マルチモーダル入力と長いコンテキスト
Muse Spark 1.3 のコンテキストウィンドウは 100万tokens です。
英語なら、およそ75万語分に相当します。
用途としては、
- 大規模なコードベースの解析
- 長文ドキュメント
- 複数ファイルをまたぐ作業
- 長い会話履歴
- 長時間動く Agent
などに向いています。
大きなコンテキストの利点は、「たくさん入る」ことだけではありません。
コンテキストが小さいモデルでは、開発者側がファイルを選び、コードを削り、背景情報を何度も追加する必要があります。
ウィンドウが大きければ、その作業をかなり減らせます。
入力はテキスト、画像、動画、音声、PDFに対応しています。
画像や動画、音声の生成には対応しておらず、出力はテキストのみです。
4. Muse Spark 1.2 から何が変わったか
Muse Spark 1.2 は8月5日、1.3 は9月2日に公開されました。間隔は1か月もありません。
主な変更は、処理効率と Agent の動きです。
- ツール呼び出しが約20%減少
- token消費が約25%減少
- Terminal-Bench 2.1 が82.9から88.8へ上昇
- 曖昧な指示では確認を入れやすくなった
- 長いタスクで間違った方向に進み続けにくくなった
具体的な数値の多くは Meta の自社テストです。
Artificial Analysis の評価でも 1.3 が 1.2 より強くなっている傾向は確認されていますが、公式の数字がどの環境でも同じように再現されるかは、もう少し第三者テストを見たいところです。
1.3 は「知能が一気に上がった」というより、余計な処理を減らして、長い仕事をより安定して進められるようにした更新と見るほうが近いです。
コメント(0件)