Metaの先端AI研究組織Meta Superintelligence Labsは、エージェント型コーディングモデル「Muse Spark 1.3」を公開しました。わずか5カ月で4回目となるMuse Sparkの更新であり、改良の焦点は一問一答の文章生成ではありません。複数の工程をまたぐ長時間の作業を維持し、必要に応じてツールを使いながら、利用者と相談してゴールまで進む能力に置かれています。ソフトウェア開発でいえば、単にコード片を返すのではなく、曖昧な依頼を整理し、関連情報を集め、実装や確認を重ねる働き方を想定しています。

この方向性は、生成AIの評価軸が「一度の回答がどれほど賢いか」から「現実の業務をどれほど安定して完了できるか」へ移りつつあることを映しています。長い作業では、最初の計画がそのまま通用するとは限りません。情報同士が矛盾していたり、途中で追加の要望が入ったり、権限不足などの障害が判明したりします。Muse Spark 1.3は、こうした状況で不足する文脈を自ら集め、計画の穴を補うように設計されています。

Metaが前面に出しているのは、単純な性能向上よりも使いやすさです。長い会話の流れを保つこと、利用者との協働を続けること、行き詰まった際にそれを認識することが主要な特徴として説明されています。企業利用の観点では、AIが常に成功したように振る舞うより、できない理由や判断が必要な点を早めに伝えるほうが、運用上の価値は高くなります。Muse Spark 1.3は、その実務的な信頼性を高めようとするリリースと位置付けられます。

Muse Spark 1.3は、Metaの開発環境「Muse Code」と「Meta Model API」で提供されており、企業や開発者はAPI経由で本番用途に組み込めます。一方、モデルの重みは非公開であるため、自社のサーバーや閉域環境にモデルそのものを配置するセルフホスティングには対応していません。機密データの取り扱い方針や社内インフラへの配置を重視する企業にとって、この違いは性能と同じくらい重要な選定条件になります。

推論モードにも注意が必要です。記事で紹介された最上位の「max」モードは、追加の安全性試験が終わるまで利用が制限されています。現時点で開発者が呼び出せるのは「xhigh」モードであり、後述するベンチマークの一部は利用可能なモードと条件が異なります。評価表の最高値だけを見て導入効果を見積もると、実運用で得られる性能との間に差が生じる可能性があります。

価格は従来から据え置かれ、通常枠では100万入力トークン当たり1.25ドル、100万出力トークン当たり4.25ドルとされています。また、コントリビューター向けの枠として、入力0.10ドル、出力0.20ドルという単価も示されています。ただし、総コストは単価だけでは決まりません。エージェントが何回ツールを呼び、会話履歴を何度読み込み、どれほど長い出力を返すかによって変わります。そのため、提供経路、推論モード、データ管理、実タスク当たりの利用量を一つの表にまとめて比較することが現実的です。Metaは将来のオープンウェイト版をロードマップに挙げていますが、今回の提供モデルは非公開である点を区別して理解する必要があります。

Muse Spark 1.3は、特定の一つの実行環境だけに適応するのではなく、複数のエージェント用ハーネスで訓練されています。ハーネスとは、モデルにツール、作業手順、実行結果の受け渡しなどを組み合わせる枠組みを指します。複数環境で学習させる狙いは、ある専用環境ではうまく動いても、別の製品や業務フローでは振る舞いが崩れる問題を抑えることにあります。企業が独自のツール群と接続する場合にも、環境をまたいだ汎用性は重要になります。

オープンエンドな目標を受けた際には、散らばった情報や相互に矛盾する資料から文脈を集め、当初の計画で不足している部分を補います。実際の開発業務では、仕様書、既存コード、テスト結果、担当者の追加説明が完全にそろっているケースは多くありません。そのため、与えられた情報だけで強引に完了させるより、根拠を集め直し、途中で計画を修正できることが長期タスクの成否を左右します。

また、一つの長いスレッド内に複数のワークフローを保持できるように設計されています。利用者が途中で別の依頼を挟んだり、先ほどの作業へ戻るよう指示したりしても、入力を適切なタスクへ対応付ける能力が改善したとMetaは説明しています。これは、単なる長文記憶ではなく、どの情報がどの仕事に属するかを整理する力に関係します。業務導入では、タスク名、目的、完了条件を明確に渡す運用を併用すると、モデル側の改善をより生かしやすくなると考えられます。

今回の更新で実務に直結しやすいのが、利用者との協働方法です。Muse Spark 1.3は、依頼に複数の解釈がある場合には確認質問を行い、作業が停滞した場合には利用者へ助けを求めます。さらに、影響の大きい操作を実行する前には確認を取るようになっています。コードを提案するだけの支援と異なり、外部ツールを操作できるエージェントでは、何を自動実行し、何を人間の承認対象にするかが安全性を大きく左右します。

長時間の実行中にどの程度報告するかも、利用者の好みに合わせられます。細かな進捗を頻繁に知りたい利用者には状態を伝え、任せておきたい利用者には静かにバックグラウンドで処理を続けるという考え方です。報告回数は多ければよいわけではなく、中断による負担と透明性のバランスが必要です。企業では、定期報告が必要な作業、例外時だけ通知する作業、毎回承認が必要な操作をあらかじめ分類すると活用しやすくなります。

Metaは、自身の限界に関する判断も改善したとしています。障害があるにもかかわらず、存在しない成功結果を作り上げるのではなく、直面した問題を明示する方向です。もちろん、この説明だけで誤りがなくなるとは限りません。重要な変更にはテスト、差分確認、監査ログなどを残し、人間が最終判断できる仕組みが引き続き必要です。それでも、質問、行き詰まりの申告、重要操作前の確認という三つの動作が明確になったことは、AIを単なる回答者から協働者へ近づける実用的な変化です。

Muse Spark 1.3は、より多くの長期コーディング課題を使って訓練されています。MetaによるMuse Spark 1.2との比較では、不要な往復が減り、回答の冗長さが抑えられ、コードの書き方も整理されたと説明されています。長期の開発タスクでは、小さな無駄が何度も積み重なります。余計な調査、重複したファイル確認、不要な説明、やり直しが減れば、完了までの時間だけでなく、担当者が確認に費やす時間も抑えられる可能性があります。

Metaのエンジニアによる社内比較では、旧版に対してツール呼び出し回数が約20％、使用トークン数が約25％減少しました。ツール呼び出しは、検索、ファイル操作、テスト実行などの外部処理との往復に相当します。トークンはモデルが読み書きする情報量の単位で、API課金や処理時間に影響します。同じ成果をより少ない呼び出しとトークンで得られるなら、反復回数の多いエージェント処理ほど効果が積み上がります。

ただし、これらはMeta社内の比較値であり、すべての企業タスクで同じ削減率になることを保証する数字ではありません。リポジトリの規模、テストの重さ、接続するツール、プロンプト設計、完了条件によって利用量は変わります。導入検証では、1回のAPI単価だけでなく、業務が完了するまでの総トークン、ツール呼び出し数、処理時間、失敗後の再実行、人間の確認時間を測る必要があります。今回の改善は、エージェントの評価を正答率だけでなく、成果物一件当たりのコストで捉える重要性を示しています。

Muse Spark 1.3は、最大100万トークンのコンテキストウィンドウを備えています。コンテキストウィンドウとは、一度の処理でモデルが参照できる入力や会話履歴の範囲です。大規模なコードベース、長い仕様書、過去の議論などを同じ流れで扱える余地が広がります。ただし、収容できる量が大きいことと、必要な情報を正確に見つけられることは別の能力です。その点を確認するのが、長い入力から指定情報を回収するMRCR v2のような評価です。

Metaの公表値では、MRCR v2で25万6千から51万2千トークンの範囲が98.5、51万2千から100万トークンの範囲が98.1でした。比較対象のGPT-5.6 Solは、それぞれ91.5と73.8とされています。記事に掲載された比較の中では、特に長い範囲で差が大きく示されています。ただし、ベンチマークの条件と自社文書の構造は一致しないため、実際の設計で検索基盤や文書の整理が不要になるとは限りません。

マルチタスク面では、雑多な一つの会話に新しい指示や割り込みが入っても、どのタスクに属する入力かを対応付ける能力が向上したとされています。長い文脈を業務で使う場合、すべてを無秩序に詰め込むより、タスクごとに識別子や完了条件を付け、参照元を明示したほうが監査しやすくなります。100万トークンは大きな受け皿ですが、情報の鮮度、アクセス権、重複、矛盾を管理する仕組みと組み合わせてこそ価値を引き出せます。

Metaの公表値では、ソフトウェア開発能力を測るDeepSWE v1.1でMuse Spark 1.3が75.4を記録し、Claude Opus 5の74.0、GPT-5.6 Solの72.7を上回りました。コードベースに関する質疑を扱うSWE-Atlas Codebase QnAは59.4、端末操作を評価するTerminal-Bench 2.1は88.8で、後者はGPT-5.6 Solと同点でした。Claude Opus 5のTerminal-Bench 2.1は86.7とされています。これらの値は、異なる種類の開発作業での相対的な強みを読む材料になります。

一方、エージェント系の評価では推論モードの差を見落とせません。OSWorld 2.0はmaxモードが66.9、xhighモードが57.2、GDPval-AA v2のEloはそれぞれ1,754と1,709、JobBenchは64.9と61.2でした。DeepSearchQAは両モードとも89.4でした。旧版のMuse Spark 1.2はxhighで評価されているため、新旧モデルの伸びにはモデル自体の改良だけでなく、推論段階の違いが含まれる可能性があります。しかも、maxは現時点で一般の開発者が利用できるモードではありません。

第三者評価機関Artificial Analysisは、提供中のxhighをIntelligence Indexで61、プレビュー版maxを62と評価しています。同機関の比較では、xhighはGPT-5.6 SolのmaxおよびGrok 4.6のhighと同水準で、Claude Opus 5のmaxの63、Claude Fable 5.1のmaxの66を下回りました。銀行業務を題材にしたTau3-Bench Bankingでは、xhighが47％、maxが52％で、後者は同機関が同評価で記録した最高値とされています。

したがって、企業の選定担当者は、提供元の最高スコア、第三者の横断評価、現在利用できるモードを分けて確認する必要があります。ベンチマークは能力の輪郭を知るには有用ですが、セキュリティ要件や保守性、誤操作の影響まで直接示すものではありません。自社の代表的な課題を少数でも用意し、正答率だけでなく完了率、再試行、コスト、人間の修正量を同じ条件で測ることが、数字を業務判断へつなげる方法になります。

日本企業にとってMuse Spark 1.3の注目点は、モデル単体の順位より、長い作業を人間とどう分担するかという設計にあります。たとえば、既存システムの調査、修正候補の作成、テスト実行、結果の要約までを一つの流れにまとめれば、担当者は各工程を個別に指示する負担を減らせる可能性があります。その際には、AIへ渡してよいデータの範囲、利用できるツール、変更可能な環境を先に限定する必要があります。

特に、重要操作の前に確認する振る舞いは、承認プロセスを持つ企業と相性のよい考え方です。ただし、モデルの確認機能だけに統制を任せるのは十分ではありません。読み取り専用の権限から始め、コード変更はレビューを必須にし、本番反映は別の承認経路に分けるなど、システム側でも境界を設ける必要があります。モデルが行き詰まりを申告した場合に、誰へ引き継ぎ、どの情報を添えるかも運用手順として決めておくと安全です。

また、日本語の要件と英語中心の技術資料が混在する環境では、曖昧な依頼を質問で解消する能力が役立つ可能性があります。検証時には、日本語の仕様書、社内固有の略語、古いコード、矛盾する文書を含む現実的な課題を用意することが重要です。効率面では、約20％と約25％という公表値をそのまま予算へ適用せず、自社タスク一件当たりの費用と作業時間を測ります。閉じた重み、API提供、利用可能なxhighという条件を踏まえ、限定的な試行から適用範囲を広げる進め方が堅実です。

最初の検証では、成果が判定しやすく、失敗しても本番へ影響しないタスクを選ぶことが適切です。候補としては、既存コードの説明、テスト案の作成、限定された不具合の修正案などが考えられます。入力資料、期待する成果物、禁止操作、終了条件をそろえ、同じ課題を旧モデルや人手の工程と比較します。これにより、印象ではなく、完了率と必要な修正量を基に評価できます。

測定項目には、総入力・出力トークン、ツール呼び出し回数、完了までの時間、再試行回数、人間への質問回数を含めます。質問が多すぎれば作業が途切れ、少なすぎれば誤解したまま進む可能性があります。頻繁な進捗報告と静かなバックグラウンド実行のどちらが適するかも、業務ごとに決めます。公表された効率改善が、自社環境でもコストや担当者の負担軽減につながるかをここで確認します。

安全面では、重要操作前の確認が実際に働くか、権限不足や情報矛盾を正しく申告できるか、失敗を成功として報告しないかを意図的に試します。APIへ送るデータの分類、ログの保存期間、接続ツールの最小権限、成果物のレビュー責任も整理します。maxモードの数値を前提にせず、現在提供されるxhighで合格基準を満たすかを判断することも欠かせません。長いコンテキスト、高いベンチマーク、効率改善という利点を、統制された小規模検証で確かめてから対象業務を広げることが、企業導入の現実的な道筋になります。