何が起きたのか

Metaが2026年8月5日、ターミナル上で動くコーディングエージェント Muse Code をベータ公開しました。同時に、これと共同学習されたコーディング特化モデル Muse Spark 1.2 も提供開始しています（Meta Research 公式ブログ 2026-08-05）。公式ブログはMuse Codeを「a terminal coding agent powered by Muse Spark 1.2」と位置づけ、大規模リポジトリにおける変更計画・コード記述・結果検証を一貫して扱う用途を挙げています。

導入はmacOSとLinuxで1コマンドです。

curl-fsSLhttps://dev.meta.ai/install.sh|bash

TechCrunchの報道では、Mark Zuckerberg氏が「complete software engineering tasks across large repos」と述べ、Meta AI責任者のAlexandr Wang氏は「especially from a cost perspective」と価格面の優位を強調しています（TechCrunch 2026-08-05）。

ただし、この発表で技術的に読む価値があるのは「Claude Code / Codex の対抗馬がもう1つ増えた」という横並びの話ではありません。公式ブログが明記している2つの設計選択──セッション中ずっと生き続ける非同期バックグラウンドエージェントと、追記型のローカルイベントログ──が、既存のサブエージェント方式と何を変えるのかです。

常駐エージェント：タスクごとに生成しないという選択

公式ブログはMuse Codeの構成を「a simple agent loop plus a set of async background agents to enhance the main agent’s capability」と説明しています。そして重要なのは、これらのバックグラウンドエージェントがタスクごとに生成されるのではなく、セッションを通じて常駐する点です。MarkTechPostの解説によれば、Metaはこの設計の狙いを「avoids redundant information gathering」および「reduces latency and steering on difficult, multi-step tasks」と説明しています（MarkTechPost 2026-08-05）。

ここが Claude Code のサブエージェント方式との設計差分です。Claude Code のサブエージェントは既定では呼び出しごとに新しいインスタンスとして起動し、公式ドキュメントも「Each subagent invocation creates a new instance with fresh context」と明記しています（Claude Docs: Subagents 2026-08-06）。この既定の挙動では、サブエージェントは呼ばれるたびに真っさらな文脈から始まり、「このリポジトリはどう構成されているか」「ビルドコマンドは何か」「テストはどこにあるか」を毎回集め直します。これは隔離性という利点の裏返しで、親の文脈を汚さない代わりに、探索コストを毎回支払う構造になっています。

ただし Claude Code 側にも例外は用意されています。同ドキュメントは SendMessage による再開について「Resumed subagents retain their full conversation history, including all previous tool calls, results, and reasoning」と述べ、さらに memory フィールドでサブエージェント自身に永続メモリを持たせられるとしています。つまり違いは「文脈を引き継げるか否か」ではなく、引き継ぎが既定なのか明示的な操作なのかという設計方針の差です。

再収集される文脈の量を式にすると差が見えます。共通文脈が最後まで保持され、途中での再収集や脱落が起きないという単純化モデルで考えます。1回のセッションで $n$ 個のサブタスクを処理し、リポジトリ理解に必要な共通文脈が $c$ トークン、各タスク固有の増分が $d_i$ トークンだとすると、使い捨て型はタスクごとに $c$ を集め直すので、セッション全体で収集される文脈量は

$$G_{\text{ephemeral}} = \sum_{i=1}^{n} (c + d_i) = n\,c + \sum_{i=1}^{n} d_i$$

常駐型は共通文脈を1度だけ集め、以後は増分だけを足していきます。

$$G_{\text{resident}} = c + \sum_{i=1}^{n} d_i$$

差分の $(n-1)\,c$ が、ツール往復で集め直さずに済む文脈量です。$n$ が数十〜数百に伸びる長時間タスクでは、この項が支配的になります。逆に $n$ が小さければ差は無視できるので、常駐型が効くのは長く走らせるほどという条件付きの優位です。

ただしこの差は、そのまま請求される入力トークンの差にはなりません。モデル呼び出しは毎回、保持している文脈を入力として送り直す方式が一般的で、常駐エージェントであっても $c$ は呼び出しのたびに（多くはキャッシュ入力として）計上されます。むしろ履歴が積み上がる分、入力トークンの総量は常駐型のほうが大きくなる場合もあります。常駐設計が削るのは主に、$c$ を組み立て直すためのツール往復と、そこで生じるレイテンシ・引き継ぎ・エージェント間の認識のずれです。上の式も理想的な上限で、実際にはコンパクションによる履歴の圧縮、文脈からの脱落、リポジトリ側の変更によって、常駐型でも再探索は発生します。

金額面では、使い捨て型の不利はプロンプトキャッシュで大きく緩和できます。Muse Spark 1.2 のキャッシュ済み入力は 1M トークンあたり 0.15ドル で、非キャッシュ入力 1.25ドル の約8分の1です（Unite.AI 2026-08-05）。つまり常駐設計の差が出るのは金額そのものより、再収集に費やされるツール往復のレイテンシと、そこで文脈がずれることによる手戻りだと読むのが妥当です。

一方でTechCrunchは、Muse Codeが分離されたworktree上で並列にサブエージェントを走らせ、「build six features for a game simultaneously with no collisions」と説明されたとも報じています。常駐エージェントと使い捨て並列ワーカーは排他ではなく、役割が違うものとして併存しているようです。

追記型イベントログ：クラッシュ復帰を可能にする設計

もう1つの設計が、ローカルの追記専用イベントログです。公式ブログは「a local event log in which every model call, tool run, approval, and edit is appended」と書き、クラッシュ後は「the agent can resume precisely where it stopped」と述べています。MarkTechPostはこれを「replay-exact and restart-safe」と要約しています。

この設計が効いてくる規模を、公式ブログ自身がケーススタディで示しています。NVIDIA Hopper GPU上でKDAおよびMLAカーネルを反復的に最適化させた事例で、実行は「1,000+ tool calls (up to 24 hours)」に及んだとされています。

24時間・1,000回超のツール呼び出しという水準になると、途中で実行が中断する確率は無視できません。ただし中断を招くのは、ツール呼び出しのエラーそのものではありません。ツールが1回失敗しても、再試行する・別のコマンドに切り替える・エラーをモデルに返して続行する、といった処理が可能です。セッションそのものが失われるのは、プロセスのクラッシュ、ホストの再起動、API障害、認証の期限切れといった事象のほうです。

そうしたセッション中断事象が1ステップあたり $q$ の確率で独立に起きると仮に置けば、$N$ ステップを無事故で完走する確率は

$$P_{\text{complete}} = (1 - q)^{N}$$

です。$q = 0.001$、$N = 1000$ なら $P_{\text{complete}} \approx 0.37$ で、完走しないほうが多数派になります。実際の障害は独立でも等確率でもなく（ネットワーク障害やAPI障害は相関します）、この数値はMuse Codeの実測障害率ではなく、水準感をつかむための仮想モデルです。それでも、チェックポイントなしの設計では中断が「最初からやり直し」を意味することは変わりません。追記型ログは、記録済みの地点から処理を再開できるようにする仕組みです。

もっとも、そこから再構成できるのはログに残ったモデル呼び出し・ツール実行・承認・編集の履歴です。外部APIへの書き込み、パッケージの公開、データベース更新のように、エージェントの外側で確定した副作用まで巻き戻せることを意味するわけではありません。

同時に、このログは監査に使える活動履歴でもあります。承認と編集が時系列で残るので、エージェントがいつ何を変えたかを後から追跡できます。ただしログはローカルに置かれるため、そこに含まれるプロンプト・コード断片・認証まわりの出力をどう保護するかは利用側の責任になります。公式ブログはログの暗号化や保持期間について記述していません。改ざん耐性やアクセス制御についても公開情報からは確認できないため、正式な監査証跡として扱えるかは別途の検証が要ります。

ベンチマーク：数値は図の中にある

公式ブログはTerminal-Bench 2.1、DeepSWE 1.1、Meta Internal Coding Benchの3つで比較図を掲載しています。ただし本文テキストには数値がなく、Unite.AIは「the page presents them as images without a methodology write-up」と指摘しています。図の読み取り値として複数の二次報道が一致して伝えているのは次の水準です。

ベンチマークMuse Spark 1.2参考
Terminal-Bench 2.182.9%Claude Opus 5 が 86.7% で首位、Muse は2位
DeepSWE 1.159.3%Opus 5（65.0%）、GPT-5.6 Terra（64.8%）に次ぐ3位
Meta Internal Coding Bench70.6%Opus 5 が 79.4% で首位、Muse は2位

（Vorp Labs 2026-08-05、CodingFleet、VentureBeat 2026-08-05）

つまり Muse Spark 1.2 は、Terminal-Bench 2.1 と Meta Internal Coding Bench では Claude Opus 5 に次ぐ2位ですが、DeepSWE 1.1 では OpenAI の GPT-5.6 Terra にも抜かれて3位です（Yahoo Tech 2026-08-05）。「全指標で2位」ではなく、ベンチマークによって順位が割れている点は押さえておく必要があります。

評価条件はMarkTechPostが整理しており、Terminal-Bench 2.1は89タスクをpass@1で5試行、DeepSWE v1.1は91リポジトリ・5言語にまたがる113タスク、Meta Internal Coding Benchは実際のプルリクエスト440件をタスク化したものとされています。3つ目は社内独自ベンチマークで、外部からの再現手段はありません。

数値そのものより注目すべきは、Metaが自社の比較図で3指標のいずれでも自らを首位に置いていない点です。beincryptoは「Zuckerberg’s Muse Code Loses to Anthropic on Meta’s Own Benchmark Charts」という見出しでこれを報じました（BeInCrypto 2026-08-05）。Wang氏の「cost perspective」という言葉と合わせて読むと、Metaが訴求しているのは首位性ではなく、性能あたりの価格であることがわかります。

価格と『コントリビューター枠』：日本の企業利用で効いてくる条件

Muse Spark 1.2 は Meta Model API から提供され、コンテキスト長は 1,048,576 トークン（約100万）です（Vercel AI Gateway）。前世代の Muse Spark 1.1 も 2026年7月9日の発表時点で100万トークン文脈を備えていました（Meta AI 公式ブログ 2026-07-09）ので、1.2の主眼は文脈長ではなくコーディング能力の底上げです。

料金は1Mトークンあたりで次のとおり報じられています（単位はいずれも米ドル）。

ティア入力キャッシュ入力出力データの扱い
muse-spark-1.21.250.154.25プロンプトはMetaの製品改善に使われない
muse-spark-1.2-contributor0.100.0020.20入出力がMetaのモデル学習・改善に使われる

入力で12.5倍、出力で21.25倍の差です。この倍率は、単なる割引ではなく対価の交換だと理解する必要があります。Vercel AI Gatewayのモデルページは、コントリビューター枠について「Your inputs and outputs are used to train and improve Meta’s AI models」と明記しています。

コーディングエージェントの文脈で「入力」が何を指すかを具体化すると、判断は速くなります。エージェントが読むのはソースコード、設定ファイル、テスト、コミット履歴、そして実行時のスタックトレースやログです。出力は生成された差分そのものです。つまりコントリビューター枠を業務リポジトリに向けて使うことは、そのリポジトリの実質的な内容を学習データとして提供することに近い意味を持ちます。

日本企業の実務では、受託開発の成果物に対する秘密保持義務、OSS利用時のライセンス条項、個人情報を含むテストフィクスチャなどが絡みます。これらは「安いから試す」で片付く判断ではありません。一方で、公開OSSのフォークでの検証、社内ハッカソン、使い捨てのプロトタイプなど、そもそも秘匿性がない対象であれば、20分の1の出力単価は実験の回数を大きく増やせます。境界線を引くべきなのはリポジトリ単位であって、開発者個人の判断単位ではないはずです。

なお標準ティアの入力1.25ドル / 出力4.25ドルという価格は、Muse Spark 1.1 が2026年7月にAPI提供を始めた時点の水準と同じ数値として報じられており、1.2 での値上げは確認できません。

残された不確実性

ベンチマーク数値の一次確認ができていない。 公式ブログの比較は画像として掲載されており、本文テキストに数値がありません。本記事に載せた82.9% / 59.3% / 70.6%は、その図を読み取った二次報道に依拠した値です。Metaはこれらを図としては公表していますが、本文テキストや機械可読な表の形では出しておらず、本記事は数値そのものを一次資料の文字列としては確認できていません。前世代1.1のTerminal-Bench 2.1スコアについては、報道間で76.2と80.0という食い違いが確認できました。世代間の改善幅を語る際は、この揺れを織り込む必要があります。

価格の公式ページを直接確認できていない。 Meta公式のMuse Spark 1.2モデルページ（developer.meta.com）はJavaScript描画のため本文を取得できず、料金表の一次確認ができませんでした。掲載した価格はOpenRouter、Vercel AI Gateway、および複数の技術メディアが一致して伝えている値ですが、実際に課金する前にMeta Model APIのコンソールで確認してください。

コントリビューター枠の適用範囲が不明。 Vercelの文言が対象としているのは「inputs and outputs」、つまりMeta側へ送信されたデータです。問題は、エージェントがローカルで読み取ったファイルのうち、どこまでがモデル入力・ツール実行結果・テレメトリーとして実際に送信されるのかで、これは公開情報からは判別できません。またオプトアウトの可否、既に送信したデータの削除請求、保持期間、地域ごとの法的な扱いについても記述を確認できていません。

インストール経路のリスク。 curl | bash 形式のインストールは、配布元が侵害された場合に任意コード実行に直結します。ベータ段階のツールを業務端末に入れる場合、スクリプトを一度ダウンロードして内容を確認してから実行する、あるいはコンテナ内で試すといった手当てが現実的です。

ベータ品質と提供範囲。 Muse Codeはベータであり、対応プラットフォームはmacOSとLinuxです。Muse Sparkの重みは公開されておらず、Meta Model API経由のホスト提供のみです。オンプレミス要件がある組織は現時点で選択肢に入りません。

まとめ

Muse Codeの発表で技術的に意味があるのは、ベンチマークの順位ではなく2つの設計選択です。1つは、バックグラウンドエージェントをタスクごとに生成せずセッション中常駐させることで、リポジトリ理解の再収集を省く構造。もう1つは、モデル呼び出し・ツール実行・承認・編集をすべて追記型ログに残し、クラッシュ後に停止地点から再開できるようにした点です。どちらも「エージェントを24時間走らせる」という前提から逆算された設計で、公式ブログのGPUカーネル最適化事例における1,000回超のツール呼び出しという数字が、その前提を裏づけています。

短いタスクでは、これらの設計による恩恵は相対的に小さくなります。クラッシュからの復帰は短い実行でも働きますが、失われるものがそもそも少ないためです。差が大きく出るのは長時間・多ステップの実行で、そこでは常駐による再収集削減と、ログによる失敗コストの局所化が同じ方向に働きます。

価格については、標準ティアの入力1.25ドル / 出力4.25ドルは競争的な水準ですが、実験の経済性を本当に変えるのはコントリビューター枠の入力0.10ドル / 出力0.20ドルです。ただしこれはコードを学習データとして提供する対価であり、リポジトリ単位で線引きすべき判断です。安さを理由に業務コードへ適用する前に、契約と規程を先に確認する順序が要ります。

主要出典

関連する過去記事