大規模なコードベースをエージェントに扱わせる際、モデルだけを替えても作業は完結しない。長い実装では途中の判断を保ち、並行する処理の結果を受け取り、失敗したプロセスを再開する実行基盤が要る。Metaは8月5日、その部分まで含めた端末型コーディングエージェント「Muse Code」をベータ公開した。新しいMuse Spark 1.2は、このMuse Codeのハーネスと共同で訓練されている。
Muse CodeはmacOSとLinuxで提供され、大規模リポジトリの計画、実装、検証を端末から扱う。Metaが今回売り出す単位はモデル単体ではなく、モデルがツールを使い、長い処理を続けるためのハーネスまで含む製品である。大きな文脈窓を渡して一度で答えを出させる設計とは、狙いが異なる。
導入はcurl -fsSL https://dev.meta.ai/install.sh | bashで行う。もっとも、ベータ版のMuse Codeについて、発表は料金の対象範囲、利用上限、対応地域の詳細を示していない。端末から試せることと、組織の開発工程へそのまま組み込めることは分けて考える必要がある。
長時間タスクをつなぐ常駐エージェント
Muse Codeは通常のエージェントループに加え、各セッション中に持続する非同期バックグラウンドエージェントを動かす。これはセッションをまたいで常駐する仕組みではなく、セッション中に専門エージェントが活動を続ける設計である。メインの作業と並行して次の処理を進め、その結果をメインエージェントへ報告する。複数モジュールをまたぐ作業では、手が空くまで待つのではなく、調査や後続処理を走らせておける。
もう一方の柱が、ローカルの追記型イベントログである。Metaによれば、ここにはモデル呼び出し、ツール実行、承認、編集を追記する。ログを基に実行を正確に再現でき、クラッシュした場合も停止地点から再開できるという。
並列化と再開可能性は別の役割を担う。前者は作業中に何を先回りして進めるかを扱い、後者は処理が途切れても同じ履歴をたどれるようにする。標準スキルの/planは承認付きで計画を作り、/grillはその計画をストレステストし、/goalは指定した目標の達成を扱う。エージェントに任せる範囲を広げるほど、こうした途中経過の管理が実装の成否に関わる。
1.2はハーネスと一緒に学習した
Muse Spark 1.2は、コード生成、複雑なデバッグ、コードベースの理解、エンドツーエンドの開発ワークフローを対象にしたMuse Spark 1.1の更新版である。Metaは同モデルをMuse Codeと共同訓練し、rejection samplingで選んだハーネス上の実行軌跡を使った。さらに、goals、compaction、subagentsに合わせてレシピを最適化し、Muse Codeのツールセットも統合したとしている。
長期タスク向けの訓練には、リポジトリ全体の生成、大規模なエンドツーエンドプロジェクト、auto-researchを含めた。ここで使ったplanning、goal conditioning、context compactionは、長い処理で現在の目的を失わないための手法である。学習の対象は、モデルがどのような指示に反応するかに限られない。ハーネスが目標や圧縮した文脈をどう渡すかも含まれる。
学習データの作り方にも自己改善の手順を組み込んだ。MetaはMuse Spark 1.1で難しいコーディング環境と指示追従テンプレートを生成し、候補解が要件を満たす度合いを同モデルに採点させたという。1.2は、前世代が作った課題と評価を足場に、複雑な指示へより正確に従うよう訓練されたことになる。
MetaはGPUカーネル最適化で、NVIDIA Hopper向けのKDA/MLAカーネルを対象に、1,000回を超えるツール呼び出しと最長24時間の実行を試したと説明する。ベースラインから大幅に改善したというが、発表本文に改善率はない。この事例は長く回るコード探索が可能だという条件を示すものであり、一般的な開発タスクの速度や生産性を測った結果ではない。
1Mトークンでもコードベース理解は別問題
Muse Spark 1.2の文脈窓は100万トークンである。しかし、大規模コードベースの難しさは、読み込める量だけで決まらない。モジュール間の依存関係、暗黙の命名規則、互換性の制約を、変更の間も探索し続けなければならない。
Metaは2026年4月、別の社内事例として、4リポジトリ、3言語、4,100超のファイルを対象に、AI向けナビゲーションを約5%から100%へ広げた取り組みを紹介している。予備試験では、タスク当たりのツール呼び出しとトークンを約40%減らした。この事例が扱ったのは文脈ファイルと依存関係のインデックスであり、Muse Codeの機能を測ったものではない。
対照すると、Muse Codeが補おうとするのはコード知識の事前計算ではなく、長い処理の方向維持、並列作業、クラッシュ後の継続、ハーネスとの協調である。とはいえ、100万トークンの文脈と再開機構があっても、特定のリポジトリに埋もれた暗黙知を正しく読めるとは限らない。「大規模リポジトリを扱う」は対象領域であって、すべての変更の正確さを保証する表現ではない。
価格はデータ利用、評価はハーネスで読む
Muse Spark 1.2はMuse CodeとMeta Model APIで提供され、Metaは利用範囲を世界へ広げたと説明する。Meta Model APIはパブリックプレビューである。価格表には、製品改善に使うと記されたcontributor版と、使わないと記された通常版が並ぶ。
| 区分 | 入力100万トークン | キャッシュ入力100万トークン | 出力100万トークン | 価格表の記載 |
|---|---|---|---|---|
| contributor版 | 0.10ドル | 0.002ドル | 0.20ドル | 製品改善に使う |
| 通常版 | 1.25ドル | 0.15ドル | 4.25ドル | 製品改善に使わない |
この表が示すのは価格表上のデータ利用区分である。コード、プロンプト、ツール履歴をどこまで保存・利用するかは、ここからは分からない。自社のリポジトリをつなぐ利用者は、料金差とともに、その扱いを個別に確認する必要がある。
ベンチマークも数値だけで比較できない。Metaの方法論によると、Terminal-Bench 2.1は公式89タスクを5試行のpass@1平均で、DeepSWE v1.1は91リポジトリ・5言語の113タスクを同じく5試行のpass@1平均で測る。Muse Spark 1.2にはMuse Codeを使い、他モデルには各社が選んだエージェントを使っており、同一ハーネスの比較ではない。
ベータ公開後に確かめるべきなのは、ベンチマーク順位より、実際のリポジトリでどこまで作業を継続できるかである。利用上限、対応地域、企業向け管理、Muse Codeのログ保存期間は発表で詳しく示されていない。長時間の処理を開発工程へ入れられるかは、これらの条件と独立した実タスクの検証がそろって初めて判断できる。
