Muse Spark 1.3 チュートリアル：実践的な開発者向けガイド

Meta は 2026 年 9 月 2 日に Muse Spark 1.3 をリリースしました。アップグレード手順は 1 行だけ、モデル ID を変更すること。つまり、エンドポイントも SDK も価格も 1.2 と同じです。

Meta によれば、その 1 行の変更で、同じタスクを約 20% 少ないツール呼び出しと 25% 少ないトークンで完了できるとのこと。これらの数字は Meta のエンジニア自身による比較に基づきますが、対象タスクの詳細や手法の記述はありません。

こういう主張こそ、鵜呑みにする前に確かめたいところです。

そこで Muse Code を導入し、実在のオープンソースプロジェクトをあえて壊して、同じ 3 つのタスクを両モデルで実行しました。

この Muse Code チュートリアルに沿うには、Meta の開発者アカウント、使い慣れたターミナル、そして Muse Code エージェント用に macOS か Linux が必要です。現在のベータでは Windows は未対応です。

要点まとめ

• Muse Spark 1.3 は Meta のフラッグシップなマルチモーダル推論モデル。2026 年 9 月 2 日リリース、コンテキスト長は 100 万トークン。
• Muse Code はデフォルトで muse-spark-1.3-contributor を使用。切り替えない限り Meta がコードで学習します。オプトインではなくオプトアウトです。
• 3 つのコーディングタスクを計 6 回実行した結果、1.3 は 2 件で安く、3 件目は 38% 高価でした。集合としてはコストが 12% 増。
• 1.3 が勝った 2 タスクではモデルの完了回数が 23% と 32% 減少。Meta のツール呼び出しの主張と整合します。非キャッシュ入力は 3 件すべてで減りましたが、25% 減には届かず。
• ultra 推論レベルは CLI とセッション内ピッカーに存在しますが、バックエンド側で機能ゲートにより拒否されます。

Muse Spark 1.3 とは？

Muse Spark 1.3 は Meta Superintelligence Labs が 2026 年 9 月 2 日に公開したフラッグシップのマルチモーダル推論モデルで、巨大なリポジトリを対象にした長時間のエージェントセッションやコーディングに最適化されています。コンテキストは 1,048,576 トークン、入力はテキスト・画像・動画・ファイルに対応。

1.2 から変わった点は 6 つ：

• 効率性。社内比較でツール呼び出し約 20% 減、トークン 25% 減。
• コラボレーション。曖昧なプロンプトに確認質問を返し、影響の大きい操作前に確認。
• スレッド内のマルチタスク。進行中に送ったメッセージが意図したタスクに紐づく。
• 長文の指示追従。多段作業での制約抜けが減少。
• 不可逆操作の較正が向上。
• よりクリーンなコーディングスタイル。不要なターンが減り、冗長性が低下。

いずれも好材料ですが、Meta 公開のスコアカードでは Muse Spark 1.3 をmax 推論、Muse Spark 1.2 をxhigh 推論で比較しています。max はローンチ時点で依然ゲートの内側でした。 

Artificial Analysis は出荷版の xhigh を Intelligence Index 61、max を 62 と評価。差は 1 ポイントのみです。

Matt Crabtree がすでに、完全なベンチマーク表、価格の内訳、GPT-5.6 Sol や Claude Opus 5 との比較を Muse Spark 1.3 リリース分析でカバーしています。ここでは繰り返しません。以下は、実際にインストールして動かすと何が起きるかです。

Muse Spark 1.3 へのアクセス方法

用途に応じて 3 つの経路があります。表から選び、対応するセクションへ進んでください。

ターミナルエージェントの Muse Code

Muse Code は Meta のターミナル向けコーディングエージェント（macOS と Linux のベータ）。Muse Spark を実行するハーネスであり、両者は独立にバージョン管理されます。したがって muse --version の結果からは、どのモデルと対話しているかは分かりません。頭の中で切り分けておいてください。

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

これで 230 MB のバイナリが取得され、~/.local/bin/muse に配置されます。ここは全員の PATH に通っているとは限りません。

続いて取得物を確認します：

muse --version

2026 年 9 月 4 日の時点では Muse Code 1.0.2 (1.0.2-R2040.1) が表示されました。

ベータとしては少し奇妙で、数週間前までサードパーティのツール類では Muse Code を 0.2.1 と記載していたものもありました。取得したバージョンは、取得日と合わせて記録しておくとよいでしょう。

筆者撮影。 ワンライナーで Muse Code をインストールし、macOS でバージョン 1.0.2 を確認。

次に muse を実行します。初回は Not logged in. Run muse again to log in と表示されて終了しました。つまり 2 回実行が必要で、インストールが壊れたのかと勘違いしやすい小さなつまずきです。

2 回目の実行で OAuth デバイスフローが始まります。短いコードを含むサインイン URL を出力し、同じコードを別に表示して、ブラウザで承認する前に一致を確認させます。

Sign in at this page:
  https://auth.meta.com/oauth/device/?code=XXXX-XXXX
confirm this code matches:
  XXXX-XXXX

Waiting for approval…

その後、次の画面が表示されるはずです。

筆者撮影。Meta Model API のサインインフロー。資格情報の発行前にアカウント詳細を確認。

ブラウザ側では氏名の確認、規約同意、カードの登録があります。お支払い画面の料金パネルは、すぐにクリックで飛ばさずに読んでください。理由は 30 秒後に明らかになります。

デフォルトのティアはコードで学習される

ターミナルに戻ると、セッションヘッダーが現在の設定を教えてくれます：

Muse Code 1.0.2
You are logged in.
Model set to muse-spark-1.3-contributor
└ Discounted tokens: your content, including inter-session messages, may be
  used for product improvement.

モデル名をもう一度よく見てください。contributor 版が、初回インストールのデフォルトとして、確認なしで設定されています。

Meta は隠していません。開示はモデル名の下に明記され、決済画面でも contributor に DEFAULT と表示され、作業中もステータスバーに muse-spark-1.3-contributor が見えるようになっています。

ただし、多くの開発者が期待する前提とは負担が逆になっています。

クライアントのリポジトリ内で Muse Code を開いて作業を始めた時点で、そのコードはすでに学習対象となり得るエンドポイントへ送信されています。最初のプロンプトの「前」に、ステータスバーを確認してください。

筆者撮影。 初回の Muse Code セッション。デフォルトモデルは muse-spark-1.3-contributor に設定され、その下に製品改善への利用開示が表示。

ステータスバーには推論努力度も表示され、私の環境では high でした。Artificial Analysis がベンチマークに用いた xhigh ではありません。公開された数字と比較する際は、この点を覚えておく価値があります。

ティアの選択と切り替え

/model を実行すると、4 つの選択肢とレートが表示されるインタラクティブなピッカーが開きます。これらの数字は Meta の決済画面と一致します。

Contributor は入力で約 12 倍、出力で約 21 倍安価です。

その割引の対価は知的財産（IP）です。Meta の文言は「セッション間メッセージを含むコンテンツが製品改善に使用される場合がある」というもので、渡したコードだけに限りません。

Muse Spark 1.2 の両バリアントも、同一価格でピッカーに残っています。これがこの後の比較で重要です。世代間でレートが変わらないため、トークン比較は正規化なしでコスト比較に直結します。

筆者撮影。/model ピッカーに 4 つの Muse Spark バリアントとキャッシュ・入力・出力の各レートが表示。

オプトアウトするには、muse-spark-1.3 へ矢印キーで移動して Enter。ヘッダーから「Discounted tokens」の行が消えます。

クライアントワークには、ターミナルには登場しない、さらに強力な選択肢があります。Meta は ゼロデータ保持のリクエスト受付を開始したとし、トグルではなく営業経由で対応しています。

保持と学習は別問題で、代理店契約では両方の回答が必要になるのが普通です。

レート制限はティア間で挙動が異なるようですが、情報源で食い違いがあります。Meta の開発者ブログは、contributor ティアはリクエスト数ではなく 5 時間ローリングのトークン数で制限と説明。一方、1.2 ローンチ時の報道では 1 分あたり 60 リクエストの制限とされ、まったく別の仕組みです。私の検証では、午後の 90 回ほどのモデル完了でもどちらにも当たりませんでした。

Meta Model API と OpenRouter

Meta Model API は OpenAI SDK 互換のため、移行はモデル ID を変えるだけでクライアントコードはそのまま使えます。モデル ID は muse-spark-1.3 と muse-spark-1.3-contributor です。

OpenRouter ではスラッグ meta/muse-spark-1.3 として提供。これにはコストがあります。OpenRouter はスループットを毎秒約 81 トークンと計測しており、Meta へ直結した Artificial Analysis の 182 トークン/秒に比べて低速。可用性は最初の 3 日間で約 92% でした。プロバイダは Meta のみで、フェイルオーバー先はありません。

最初の Muse Spark 1.3 セッション

以下の検証はすべて python-humanize/humanize（コミット 823ad6096 に固定）を対象に実施。6 モジュールで 1,676 行のソース、テストスイートは 1 秒未満で終了、ドメイン説明は不要。ここではリポジトリを変更しません。

書き込みを渡す前に、エージェントがコードベースをどう探索するかを見るための読み取り専用の質問です。

コードの読み取り感覚をつかむための 2 つのプロンプト。まず 1 つ目から：

Map the dependency graph of this project and tell me which module has the most inbound imports.

2 つのコマンドを実行し、プロジェクト構造を列挙した後、import の grep ではなく AST パーサーを書きました。回答は、最もインバウンド import が多いのは i18n で 4 件、内訳は i18n 4、number 2、filesize・lists・time・_version が各 1。

自作スクリプトで検証したところ数が違い、指摘できたかと思いました。誤っていたのは私のスクリプトの方。相対 import（from ._version import ...）だけを数えて、絶対 import（from humanize.i18n import ...）を見落としていました。このパッケージの多くは絶対 import。モデルは両方を正しく扱いました。

2 つ目のプロンプトは、採点できるので特におすすめです：

List every public function in src/humanize, grouped by module, with a count per module.

回答は合計 20：filesize 1、i18n 5、lists 1、number 8、time 5。すべて正解。さらに追記として、i18n.get_translation は名前上は public だが i18n.__all__ には含まれておらず、他の 4 つだけがエクスポートされていることを指摘。これも正解でした。

このセッションの費用は 8 ターンで $0.01 でした。

Meta が語らない推論レベル

muse --help にはこう書かれています：

--reasoning-effort <EFFORT>
    Meta reasoning effort: none|minimal|low|medium|high|xhigh|ultra
    (default: high)

セッション内の /effort ピッカーでは 7 つのうち 6 つを選択可能で、none は表示されません。

筆者撮影。 /effort ピッカーには 6 つの推論レベルが表示され、high が current と表示。

両方に ultra というレベルが載っていますが、Meta のアナウンスには登場しません。Meta の公開見解は、max 推論は「追加の安全性テストが完了次第、まもなく提供」とのこと。

そこで試してみました：

muse exec --model muse-spark-1.3-contributor --reasoning-effort ultra 'Reply with exactly: ok'

tbh: reasoning effort ultra is not available (gate ultra_reasoning_effort is closed); using xhigh

機能ゲート ultra_reasoning_effort が名指しで存在し、閉じています。機能自体は実装済みで、サーバー側のスイッチがオフということ。「安全性テスト待ち」より踏み込んだ説明で、しかも「tbh」という語まで入った警告メッセージで返ってきます。

実務上の注意は 2 つ。クライアントは CLI とピッカーの両方で、バックエンドが提供しないレベルを広告しています。そして xhigh へ静かにダウングレードします。標準エラーに 1 行出るだけなので、スクリプトや CI のログでは見逃しがち。指定した設定で動いていると信じてしまいます。

さらに、ドキュメントにない値も試しました：

muse exec --model muse-spark-1.3-contributor --reasoning-effort max 'Reply with exactly: ok'

警告は一切なし。普通に実行され、ok と返りました。つまり、ドキュメント外の値は黙って通り、ドキュメントにある値はゲートで止まり、どの努力度で実際に処理されたかは出力からは分かりません。

筆者撮影。ultra 要求は機能ゲート閉鎖で xhigh にサイレントダウン、未ドキュメントの max は素通り。

どの推論レベルで実行されているかを重視する場合は、明示設定して stderr を確認してください。渡したフラグがそのまま使われたと決めつけないこと。

Muse Spark 1.3 の効率性主張は妥当か？

検証方法はこうです。オープンソースのリポジトリを 1 つ選び、実際のバグ修正コミットをリバートしてテストを本当に落とし、同じ 3 つのコーディングタスクを、同じプロンプト・同じフラグで両モデルに実行させます。

上の探索的セッションとは別で、こちらはすべてコードを書き換えます。

コミット 823ad6096 のソース側だけをリバートし、テストは残すと 6 件のテストが落ちます。これが開始状態：

git checkout 823ad6096e1e5ba82ea876ce761fc2efebd76157
git show 823ad6096 -- src/humanize/filesize.py | git apply -R -
python -m pytest tests/test_filesize.py -q

各実行は以下の形で、モデル ID とプロンプトだけ変えました：

muse exec \
  --model muse-spark-1.3-contributor \
  --reasoning-effort high \
  --no-parallel-tool-calls \
  --approval-mode never \
  'PROMPT GOES HERE'

タスク 1：バグ修正

合否は二値。6 件のテストがすべて通るかどうか。

The test suite tests/test_filesize.py is failing. 
Fix the source code in src/humanize/ so that all tests pass. 
Do not modify any file in tests/.

タスク 2：小さな機能追加

解釈の余地があり、両モデルのスコープ感の違いが結果に影響しました。

Add a function called natural_list_with_limit to src/humanize/lists.py. 
It formats a list but truncates after a given number of items, appending "and N more". 
Export it from the package and add tests.

タスク 3：リファクタリング

最も重いタスクで、複数ファイルに渡ります。

src/humanize/number.py is 571 lines. 
Split it into two modules along a sensible boundary, 
update all imports across the package, and make sure the full test suite still passes.

3 つのタスクはリセットなしで連続実行し、タスク 2 と 3 は、その前にモデルが出力した内容を土台に進めました。両モデルとも同じ流れを踏みました。

トークンカウントは ~/.local/share/muse/sessions/ のセッションログから、モデル完了 1 回につき 1 回として集計。6 実行すべてがテスト合格です。

差分（マイナスは 1.3 の方が少ない）：

結果を正直に読む

3 つ中 2 つは安くなり、モデル完了回数は 23% と 32% 減。これは Meta のツール呼び出し主張どおり。一方、リファクタは逆で、完了回数が 70% 増、コストは 38% 増でした。

全体では、1.3 は 1.2 より 12% 高い結果。つまり効率性の主張は本当ですがタスク依存で、単一の見出しパーセンテージでは実態が隠れてしまいます。

非キャッシュ入力は 19%、22%、5% とすべてで減りましたが、25% 減には達しませんでした。

Meta はどのトークンを数えたかを明示しておらず、入力・出力・非キャッシュ・合計のどれを指すかで結果は大きく変わります。

キャッシュヒット率は 88%〜97% で、タスクが長いほど上がりました。キャッシュと非キャッシュを分けずに生の入力トークンだけ報告しても意味は薄いでしょう。リファクタでは 418 万入力のうち実質的な新規コンテキストは 10.9 万で、残り 407 万は 50 分の 1 のレートで課金される再読だからです。

リファクタが単純な負けと言い切れない理由

非効率と断ずる前に、1.3 が実際に何をしたかを見てください。

移動した各ブロックが元とバイト単位で同一であることを、プログラム的に検証しました。

--doctest-modules を新ファイル双方で実行し、/tmp の捨てディレクトリから import 解決をテスト。その上で、誰も要求していない 2 点も指摘しました。humanize.scientific 関数が新サブモジュール名と衝突すること、そして naturaldelta の doctest が pristine なツリーでも同一に失敗しており、今回の変更に起因しないことです。

Muse Spark 1.2 は循環 import 回避のためにヘルパー関数を複製して済ませましたが、1.3 はそれを import し、循環が起きない理由を説明しました。

この設計では「トークンを多く消費した」と「より綿密に作業した」を切り分けられません。正直な表現は、1.3 はより多く支出し、より多く提供した、勝ちかどうかは追加の厳密さを望むか次第、です。

一方、機能追加タスクは逆のパターンで、Meta の「冗長性が減った」という主張を最も端的に示します。Muse Spark 1.2 は、誰も求めていない max_items・n・max_len といった別名パラメータを発明し、テストを 28 本書きました。

Muse Spark 1.3 は妥当なデフォルトを持つ 1 つのシグネチャと 20 本のテストで済ませ、出力トークンは 54% 減。

制御しきれなかったこと

4 点あります。これを書かないのは不誠実になるでしょう。

1. Muse Code が途中で 1.0.2 から 1.0.3 に自己更新したため、6 実行すべてでハーネスが同一ではありませんでした。
2. タスク 2 と 3 は、各モデル自身の直前出力を起点にしており、バイト単位で同一のツリーではありません（連続実行のため）。
3. 各セルは 1 試行のみで、通常の実行間ばらつきは未測定です。
4. 全体を contributor ティアで実行しました。モデル自体は同じでもデータの取り扱い条件は異なります。

いずれも結果の方向性を無効化するものではありませんが、総差 12% は、各セル 3 回ずつの一致を取ったときより弱いシグナルであることは確かです。

Mose Spark 1.3 のベストプラクティスとトラブル解決

初日に知っておきたかったことをいくつか。

コラボレーション挙動を引き出すプロンプト

Muse Spark 1.3 は曖昧なプロンプトに補足質問を返します。つまり、過剰に詳細なプロンプトは、有料の機能をオフにしてしまうのと同じ。過去 2 年間、指示を前段に詰め込むことを学んできた人には逆説的です。

とはいえスコープは依然重要です。「number.py を分割して」だけでは、境界や import 更新、完了条件がモデルの推測に委ねられます。実際に使ったバージョンは、その 3 点を明示しました：

src/humanize/number.py is 571 lines. Split it into two modules along a sensible boundary, update all imports across the package, and make sure the full test suite still passes.

もう 1 点。私のリファクタのプロンプトでは number.py is 571 lines と書きましたが、実際は 567 行です。両モデルとも指摘なしに修正し、1.3 は冒頭の一文で訂正しました。私の数字は、固定コミットではなくリポジトリ先端を測ったものでした。

コストを抑えるには

プロンプトの安定部分は先頭に置いてキャッシュ可能に。ヒット率 88%〜97% なら、キャッシュ戦略の方がモデル選択より請求額に効きます。

3 タスクの合計コストは contributor で $0.034。standard なら $0.91、27 倍でした。これはティア選択を金額で表したもの。3 セントか 90 セントか。

OpenRouter 経由の場合、ウェブ検索は 1,000 回あたり $2.50 で別課金です。

Muse Spark 1.3 が不向きな場面

• 推論の痕跡が公開されない。決定は見えるが理由は見えず、悪いリファクタのデバッグが難しい。
• max 推論がゲートの内側。見出しのベンチマーク構成を本番では使えない。
• 重みは非公開。セルフホスティングもファインチューニングも不可。Meta のロードマップには「Muse Spark のオープンウェイト版リリース」とあるが、バージョン・日付・ライセンスの記載なし。
• 単一プロバイダ。Meta のエンドポイントが劣化したら、迂回先がない。

よくある問題と対処

• muse: command not found（クリーンインストール直後）。スクリプトは ~/.local/bin/muse にインストールします。これは環境によっては PATH に含まれません。
• Not logged in. Run muse again to log in。表示のとおり。初回の muse は終了し、2 回目でサインインが始まります。
• 意図せず contributor ティアになっている。デフォルトです。ステータスバーを確認し、機密開封前に /model を実行。
• ultra 推論が黙って xhigh へ。ゲートが閉じています。指定フラグを信じず stderr を確認。
• Muse Code がセッション中に自己更新。私の環境では 1.0.2 → 1.0.3。計測する場合はバージョンを固定・記録してください。

再現しなかったことが 1 つ

EU のユーザーが 1.3 出荷後も 1.1 を配信されている、という報告がありましたが、私はオランダから一連を実行し、常に 1.3 でした。これらの報告はコンシューマー向けアシスタント Meta.ai に関するもので、Muse Code や Model API には当てはまらないようです。別々のロールアウトです。

総括

Meta の効率性主張は、私の 3 タスク中 2 タスクで成立し、3 つ目では逆。集合のコストは 12% 増でした。1.3 が勝ったケースでツール呼び出しは 23%・32% 減と堅調。トークンについては、どのトークンを数えるかで結論が変わります。

すでに Meta Model API か Muse Code を使っているなら、モデル ID の差し替えは 1 分で済み、日常作業では有利に働くはずです。一方で本番エージェントの新規選定では、max 版がゲートの内側で、推論痕跡がない点は、数週間待つ根拠になります。

実務的に重要なのは効率の数値そのものではありません。Muse Code がデフォルトで学習対象ティアに設定されること、そしてドキュメントにある推論レベルが要求時に黙ってダウングレードされ得ること。この 2 点はいずれも 1 行で確認でき、見落としやすい。

自分のワークロードで比較を走らせてください。私の 3 タスクはあなたの 3 タスクとは異なり、タスク間のばらつきはモデル間の差より大きいこともあり得ます。

完全なベンチマーク像は、Matt の Muse Spark 1.3 リリース分析にあります。今回のようなモデルを自分で評価する力をつけるには、当社の AI Agent Fundamentals スキルトラックから始めてください。