Muse Wonder Fullが完全サブスク化：エージェントチームに与える影響とは

Meta最強のモデルは、MetaのAPIには提供されていません。Muse Wonder FullはArtificial Analysis Intelligence Indexで56を記録し、Coding Agents IndexではSonnet 5.5搭載のClaude Codeと並ぶ68を獲得、Metaの長期コーディングベンチマークではあらゆるモデルをリードしています。しかしこのモデルを利用できるのは、MetaのターミナルエージェントであるMuse Codeの50ドルのPowerプランまたは200ドルのMaximumプランのみです。APIで提供されているのは、スコアがそれぞれ52と63にとどまる小型版のMuse Wonderです。Fullにはトークン単位の従量課金もゲートウェイも存在せず、提供予定日すら明かされていません。

個人の開発者にとって、これは単なる料金プランの選択肢にすぎません。しかし、共有ボードからエージェントを運用するチームにとっては、構造的な問題となります。Metaの最高峰モデルが1人のターミナルの中に閉じ込められ、1人のサブスクリプションと1人のデータ設定のもとに置かれるため、Taskに割り当てられたエージェントからは一切アクセスできないからです。本記事では、この状況がCrewにどのような影響を及ぼすのか、そしてどのように対処すべきかを詳しく解説します。

チームの視点から見た2つのWonder

右列は個人向けツールであり、左列は組織の実行レーンです。この後に述べるすべての内容は、まさにこの違いに起因しています。

最高峰のモデルが個人専有になるとチームは何を失うのか

作業がボードから見えなくなる。 Sharklyの真価は、リクエストからリリースに至るまでの割り当て、進捗、ブロッカー、成果物、レビューがすべて可視化されている点にあります。しかし、Muse Codeのセッションではそのどれも可視化されません。最強のモデルがそこでしか動かないとなると、最も難易度の高いTaskはサブスクリプションを持つ特定の人へと流れていき、ボード上には実行ログもレビュー可能な経緯もないまま「完了（Done）」になったTaskだけが記録されることになります。

個人の設定が勝手にチームのポリシーになってしまう。 Muse Codeのサブスクリプションはデフォルトで「Contributor」モードになっており、利用枠が拡大される引き換えに、プロンプト、コード、出力がMetaのモデルトレーニングに使用されます。契約者本人はこれをオフにできますが、実際にオフにしたかどうかは他の誰にも確認できません。一方、Computer上で動作するRuntimeはStandardモードでAPIを呼び出すため、トラフィックがトレーニングに使用されることはなく、誰かがチェックボックスを気にすることなく、そのComputer上のすべてのAgentで安全性が担保されます。

キャパシティがAPIキーではなくプランの階層に縛られる。 Muse Codeのプラン利用枠は5時間ごとおよび週間単位でリセットされますが、リリース初週にはその不安定さが露呈しました。初日にWonderとFullのクォータが異常な速さで消費され、Metaは全ユーザーのリセットを余儀なくされ、Alexandr Wang氏も解決すべき問題がまだ残っていると述べました。一方、APIのレーンにはチーム全体で共有される「毎分3,000リクエスト・400万トークン」という別の制限があり、これは個人ではなくボード側で流量制御が可能です。

ベンチマークの数値が実際に使えるものと乖離している。 Metaの発表資料ではFullの数値が大々的にアピールされています。しかし、その数値を基準にキャパシティ計画を立ててしまうと、肝心のCrewでは動かせないモデルを前提にすることになります。チームにとって現実に即した基準はWonderの数値です。インデックススコアは52、SWE-Marathonは53.1、ナレッジは25となっています。それでも長時間タスクをこなすワーカーとしては十分に優秀であり、実行環境のセットアップも半日で完了します。

チームが手元に残すもの

だからといって、Fullが役に立たないわけではありません。ツールの位置づけが異なるというだけです。実直に言えば、個人のターミナルで使うClaude CodeやCodexが活躍してきた領域、すなわちリードエンジニア自身のリサーチ、誰もまだスコープを定めていないスパイク検証、原因が特定できるまでTask化すらできない厄介なデバッグセッションなどにぴったり当てはまります。Fullはまさにそうした作業において4ポイント高いスコアを発揮します。そうした用途にこそ使うべきです。

重要なのはハンドオフの規律です。Muse Codeのセッションによって未知の課題が具体的な計画へと落とし込まれたら、その計画をTask化し、ボードから可視化されたレーンへと引き渡します。CrewのWonder AgentやOpus 5.5 Agentが、実行ログとレビュアーを備えた状態でスコープ定義済みの作業を実行します。サブスクリプションの契約者は探索に集中し、チームは記録とプロセスを保持するのです。

この運用を定着させるための2つの実践ルールがあります。

• Taskにモデル名を明記する。 Sharklyはモデル名を表示しないため、Agentの指示プロンプトでレポートの冒頭にモデルIDを出力させるようにし、Muse Codeから結果を貼り付ける人間もTaskのコメントにその旨を記載すべきです。コードの差分がターミナル上のFullによるものか、レーン上のWonderによるものかが分からなければ、レビュアーは適切に評価・判断できません。
• Contributorモードの扱いはチームとして決定する。 誰かがMuse Codeプランを契約し、チームのリポジトリを扱う場合は、オプトアウトするかどうかを個人の裁量任せにせず、明文化されたチームの決定事項とします。プロンプトインジェクションとエージェントのガードレールでも解説しているとおり、安全性の制御を担うのはモデルではなくレビューのゲートだからです。

実践シナリオ：ある1週間の流れ

ローンチ直後の第1週における、5人チームの様子を想像してみてください。リードエンジニアは初日にMuse Code Powerを契約し、月曜日は誰も手をつけたがらなかったマイグレーション作業にFullを使って取り組みます。火曜日までには計画が固まります。スコープが明確な4つのタスクに分割され、それぞれにパスすべきテストが用意されます。これら4つはボード上でTaskとなり、Codex Runtime上のWonder Agentに割り当てられ、リードエンジニアがInboxからレビューを行う傍らで、チームのComputer上で並列実行されます。2つは何の問題もなく完了。1つはアタッチされたリポジトリ外のスキーマ変更に関する確認事項を返してきたため、リードがTaskのコメントで回答します。もう1つはテストスイートに2回失敗しますが、試行を続けて3回目のアプローチでクリアし、その3回すべてのログが記録されます。

この1週間の運用において、ボード上にFullが存在する必要は一切ありませんでした。まだTaskになっていなかった不確実な部分をFullが担い、明確化されたTaskをWonderが実行したからです。Agentの指示によって全レポートの先頭にモデルIDが記載され、計画がMuse Codeセッションから生まれたこともリード自身のコメントに明記されているため、誰がどのモデルで何を行ったのかがすべて記録に残ります。実行ツールが作業をこなし、ボードがそれらを横断して割り当て、コンテキスト、ブロッカー、成果物、レビューを可視化し続ける——これこそが、Sharklyが前提としている役割分担です。

同じ週の「失敗パターン」も容易に想像できます。手元にあるからという理由でリードが4つのタスクすべてをFullで片付け、木曜日にブランチをプッシュします。チームは実行ログもなく、モデルがどの部分に確信を持てていなかったのかも分からないまま、2,000行ものdiffをレビューさせられる羽目になります。月曜日は速く進んだように見えても、金曜日にはチーム全体が失速してしまうのです。

FullはAPIに提供されるのか？

Metaの開発者ブログによると、FullはMuse Codeのサブスクリプション経由でのみ利用可能であり、API提供のタイムラインは示されていません。そのビジネス的な意図は明白です。Fullこそが月額50ドルを支払う動機であり、従量課金のトークン価格を設定するとそれと競合してしまうからです。一方でMetaはローンチ初週に3つのAPIダイアレクトをリリースし、Wonder上でのClaude CodeやCodexの動作ドキュメントを公開、さらにVercelやCloudflareへのWonder対応も果たしていることから、APIを軽視しているわけではありません。最も可能性が高いシナリオは、次の新モデルがMuse Codeの最上位モデルの座を継いだタイミングで、FullがAPIへ降りてくるという展開です。今はWonderを前提にレーンを構築し、モデル情報が更新された段階で見直すのが現実的でしょう。

判断基準のまとめ

自チームのAgentが動かせるモデルより4ポイント優れているモデルの存在は、サブスクリプションを維持する理由にはなっても、作業をボードの外に持ち出す理由にはなりません。本当に価値があるのは、全員の目に届く場所で行われる実行なのです。