OpenCodeで月10ドル、Meta Muse Spark 1.3に寄せる判断基準

この記事のまとめ

OpenCodeなら、月額10ドルのサブスクリプションや期間限定の無料枠から、Meta Muse Spark 1.3 Contributorを低コストで試せます。価格と性能、安いモデルに寄せるときの判断基準、寄せる前に確かめたい条件を、次の4つのポイントで整理します。

OpenCode Goは月額10ドルのサブスクリプションで、5時間12ドル分、週30ドル分、月60ドル分という利用枠があります。購読は任意です。
Muse Spark 1.3は公開時点のベンチマークで61点と報じられ、Contributor tierは入力が12.5倍、出力が21倍安い一方、レート制限は100 RPMです。
コストに敏感でツールを多用する作業は安いモデルに寄せ、最も難しい長期推論はフロンティアモデルに残す振り分けが示されています。
Contributor tierは学習利用の許諾と地域の条件が付きます。初期の失敗モードの報告もあり、自前の評価とコスト上限の設定が判断材料になります。

OpenCode Goと月10ドルの枠

月額10ドルの利用枠と上限

OpenCode Goは月額10ドルのサブスクリプションで、使える量はドルの価値で決まります。生成AIをコーディング補助に使い倒している人にとって、この料金体系は注目に値します。

OpenCode Goは、人気のオープンなコーディングモデルに信頼性の高いアクセスを提供する低コストのサブスクリプションです。OpenCodeの他のプロバイダーと同じように動き、購読してAPIキーを取得すれば使えます。利用は完全に任意で、OpenCodeを使うために購読しなければならないわけではありません（参照*1）。

使用量には3つの上限があります。5時間制限は12ドル分、週間制限は30ドル分、月間制限は60ドル分の使用量です。月60ドル分の使用量を10ドルで賄える計算になります。

制限はドル単位の価値で定義されるため、実際に送れるリクエスト数は使うモデルによって変わります。MiMo-V2.5のような安価なモデルでは多くのリクエストが可能で、GLM-5.2のような高コストのモデルでは少なくなります（参照*1）。私がモデルの使い分けを考えるとき、まずこの「ドル単位での上限」という発想が実務的だと感じます。高性能モデルに固執せず、タスクの難易度でモデルを選べば、同じ予算でこなせる仕事量がまったく変わるからです。

OpenCodeは、月額10ドルで6倍の使用量を提供することを目指すとしています。多くのモデルでは、まとめ買い割引とGPU容量の予約によってこれを実現していると説明しています。その節約分を、6倍の倍率を通じて利用者に還元する形です（参照*1）。

Contributorモデルの接続手順

Muse Spark 1.3 Contributorは、Goの購読からTUIの操作までの流れで使えるようになります。

接続は3つの手順で進みます。まずOpenCode Zenにサインインし、Goを購読して、APIキーをコピーします。

次にTUIで/connectコマンドを実行し、OpenCode Goを選んでAPIキーを貼り付けます。最後にTUIで/modelsを実行すると、Goで利用できるモデルの一覧が表示されます（参照*1）。

設定に書くモデルIDには決まった形があります。Muse Spark 1.3 ContributorのモデルIDはmuse-spark-1.3-contributorで、エンドポイントはhttps://opencode.ai/zen/go/v1/responses、対応SDKは@ai-sdk/openaiです。

OpenCode設定のモデルIDは、opencode-go/というプレフィックスにモデルIDを続ける形式です。たとえばKimi K3なら、設定でopencode-go/kimi-k3と書きます（参照*1）。

使えるモデルと地域には条件が付きます。モデル一覧は、テストや新しいモデルの追加に伴って変更される場合があります。また、Muse Spark 1.3 Contributorを使える地域は、Metaの地理的利用ポリシーで許可された地域に限られます（参照*1）。

Zenの無料枠と従量課金

OpenCode ZenではMuse Spark 1.3 Contributor Freeが期間限定で無料提供され、ほかのモデルはリクエスト単位の課金になります。無料の間に自分のリポジトリで動作を確認しておくのが、賢い使い方だと思います。

無料の提供には目的と期限があります。Muse Spark 1.3 Contributor FreeはOpenCodeで期間限定で利用でき、チームはこの期間にフィードバックを集めてモデルを改善するとしています。

価格表でも、このモデルは入力・出力・キャッシュのいずれも無料と記載されています。Zenはリクエストごとに課金される仕組みで、アカウントにクレジットを追加して使います（参照*2）。

同じ価格表には、有償モデルの単価も並んでいます。1Mトークンあたりで、Claude Fable 5は入力10.00ドル、出力50.00ドル、キャッシュ読み取り1.00ドル、キャッシュ書き込み12.50ドルです。Muse Spark 1.2は入力1.25ドル、出力4.25ドル、キャッシュ0.15ドルで、Muse Spark 1.3 Contributor Freeはいずれも無料の扱いです（参照*3）。

割引には引き換え条件があります。Muse Spark 1.3 Contributorは、将来のMetaモデルのトレーニングにプロンプトと完了文を使う許可と引き換えに、トークン価格が大幅に割引されます（参照*1）。この点は後述のデータ利用条件と合わせて、業務内容に応じた判断が必要です。

Muse Spark 1.3の実力と価格

長期作業向けの設計と効率

Muse Spark 1.3は、長い作業を1つのスレッドで続けることを狙って設計されたモデルです。私が生成AIをコーディング補助に使う中で感じてきた課題のひとつが、複数ステップにわたる作業でコンテキストが崩れることでした。この設計思想はその問題に直接向き合っています。

設計の狙いは、長期の作業を支えることにあります。Metaの説明では、利用者と協力しながら、1つの長いスレッドで複数のワークフローを同時に扱えるようにしています。

目標が漠然としている場合は、ツールを使って、散らかった情報や食い違う情報から自分でコンテキストを作ります。計画の抜けを先回りして直し、学んだ内容を追いながら最終的な成果物を作ります（参照*4）。

1.2と比べた効率は、社内での比較として示されています。1.3は長期のコーディング作業をより多く学習し、よくあるエンジニアリングの流れで使い勝手が向上したとMetaは述べています。

1.2と比べると、必要のない場面ではやり取りの回数が減り、説明の冗長さも抑えられ、コーディングのスタイルも整理されています。Metaのエンジニアによる比較では、大幅に速く効率的で、ツール呼び出しが約20%、トークンが約25%少なくなりました（参照*4）。

提供の経路は2つです。Muse Spark 1.3は、Muse CodeとMeta Model APIで利用できます（参照*4）。

ベンチマークとタスク単価

公開時点のベンチマークでは、上位モデルと並ぶ点数と、タスクあたりの安さが示されています。ただし私は、ベンチマークの数字はあくまで入り口として見るようにしています。新モデルが出るたびに宣伝文句ではなく手元のタスクで実力を確かめる姿勢が、実務では欠かせないからです。

点数と公開日はBeamが伝えています。Metaは2026年9月2日、5か月で4回目となるMuse SparkのリリースとしてMuse CodeとMeta Model APIでMuse Spark 1.3を公開しました。

利用可能なバージョンはArtificial Analysis Intelligence Indexで61点を記録し、GPT-5.6 SolやGrok 4.6と同水準です。それでいて、タスクあたりでは最も安価な強力モデルであり続けているとBeamは説明しています（参照*5）。

コーディング系のベンチマークでも数字が出ています。DeepSWE v1.1で75.4、Terminal-Bench 2.1で88.8、SWEAtlas CodeBase QnAで59.4を記録し、同じ層のコーディング関連ベンチマークをリードしています（参照*5）。

タスクあたりのコストは、同水準のモデルと差があります。Muse SparkはIntelligence Indexでトップ層の知能レベルに、タスクあたりおよそ0.40ドルで到達します。同程度の水準では、Kimi K3が約0.86ドル、GPT-5.5が1.18ドルです（参照*5）。

この数字は初期段階のものだという注記も付いています。Beamは、モデルが登場してまだ数日しかたっておらず、数か月にわたる本番利用ではなく、公開ベンチマークと個々の開発者による実行に基づく第一印象だとしています（参照*5）。私が以前DeepResearch系の機能を検証した際にも同様の問題があり、見た目が整ったレポートであるほど、誤情報や根拠の弱い記述が混じっていることに気づきにくい。新モデルのベンチマークも同じ目線で読む必要があります。

Contributor tierの価格と制限

Contributor tierは単価が大きく下がる代わりに、レート制限が標準tierより低く設定されています。

標準tierの価格は1.2から変わっていません。LiteLLMの記載では、1Mトークンあたりの標準tierは入力1.25ドル、出力4.25ドル、キャッシュ入力0.15ドルです。Contributor tierは入力0.10ドル、出力0.20ドル、キャッシュ入力0.002ドルです（参照*6）。

価格差とレート制限は、同じ記載の中で並んでいます。Contributor tierは入力が12.5倍、出力が21倍安く、終了日は付いていません。

レート制限も異なり、Contributorは100 RPM、標準は3,000 RPMで、キー単位ではなくチーム単位で適用されます。Web検索のグラウンディングは、どちらも1,000クエリあたり2.50ドルの課金です（参照*6）。

扱える入力とコンテキスト長も確認しておきたい条件です。テキスト、画像、動画、PDFの入力は1.2と同じように動き、/v1/chat/completions、/v1/responses、/v1/messagesで利用できます。コンテキストウィンドウは1,048,576トークンです（参照*6）。

フロンティアモデルとの価格差

トークン単価の開き

OpenCode Zenの価格表では、フロンティア級モデルとMuse Spark系の単価が桁ごと違います。この価格差を見て「とりあえず安いほうを使えばいい」と判断するのは早計です。問題は何のタスクに使うか、です。

まず、フロンティア級モデルの単価です。Zenの価格表では、Claude Fable 5.1は入力10.00ドル、出力50.00ドル、キャッシュ読み取り0.25ドル、キャッシュ書き込み12.50ドルです。

Claude Fable 5は入力10.00ドル、出力50.00ドル、キャッシュ読み取り1.00ドル、キャッシュ書き込み12.50ドルです。同じ表でMuse Spark 1.2は入力1.25ドル、出力4.25ドル、キャッシュ0.15ドルとなっています（参照*2）。

見出しの価格は据え置きで、動いたのはキャッシュ料金でした。tech-insiderの記事は、Fable 5.1は多くの人が引用する数字ではFable 5と同じで、入力トークン100万個あたり10ドル、出力トークン100万個あたり50ドルだと整理しています。

変わったのはキャッシュ料金の中の数字で、エージェント型ワークロードを動かす人にとってより重要な変更だと説明しています。プロンプトキャッシュの読み取り料金はトークン100万個あたり1.00ドルから0.25ドルへ75%引き下げられ、キャッシュ読み取りの倍率は基本入力料金の0.1倍から0.025倍になりました（参照*7）。

安い側には期間の条件が付きます。Muse Spark 1.3 Contributor Freeは、OpenCodeで期間限定の提供として価格表に無料と記載されています（参照*2）。

到達する知能水準の差

同じIntelligence Indexでも、どの媒体が何を測ったかで扱いが違います。私が複数のモデルを同じタスクで比較してきた経験から言うと、スコアの絶対値より「どのタスクで計測されたか」を確認することのほうがずっと重要です。

フロンティア級の点数は、最大努力レベルでの測定として報じられています。tech-insiderの記事は、このベンチマークでClaude Fable 5.1が最大努力レベルで66点を獲得したと伝えています。ArtificialAnalysisとThe Registerはいずれも、測定されたモデルの中で長期的なエージェント型知識作業をリードしていると説明しています（参照*7）。

同じ記事は、直接比較はまだできないとしています。Meta Muse Spark 1.3は、利用できる報道の範囲ではまだIntelligence Indexでベンチマークされていないため、3者の直接的なスコア比較はできないという整理です。確認されているのは、Axiosが報じた、Muse Spark 1.2と比べてコーディングおよびエージェント型タスクが大幅に改善したというMeta自身の主張だと書かれています（参照*7）。

一方のBeamは、Indexの点数を挙げたうえで役割分担を勧めています。Beamは、利用可能なバージョンがIndexで61点を記録し、GPT-5.6 SolやGrok 4.6と同水準だとしています。

そのうえで、最も難しい長期的な推論はClaude Opus 5やFable 5.1のようなフロンティアモデルに任せるよう勧め、これらは現在もIndexでMuse Sparkを上回ると述べています。重要なのは、すべてに1つのモデルを使うのではなく、仕事ごとに振り分けるモデル非依存のスタックだという整理です（参照*5）。これは私が自社の業務でも実践していることと同じ考え方で、「高性能なモデル1本で全部やる」より「タスクに合わせて振り分ける」ほうが、コストと品質の両方で結果が出やすい。

安いモデルに寄せる判断基準

向いている作業と頻度

寄せる候補は、コストが制約になり、ツールを多く使う高頻度の作業です。逆に言えば、判断の精度がそのまま業務品質に直結するタスクは、安いモデルに寄せるべきではありません。

Beamは、標準モデルを置き換える話ではないと明言しています。Beamによれば、ベンチマークの結果はMuse Sparkを標準モデルにすべきだという意味ではなく、コストに敏感でツールを多用する作業をMuse Sparkに振り分けるという意味です。Beamでは業務に合うモデルで本番エージェントを運用しており、1.3には特定の大きな適用範囲があるとしています（参照*5）。

具体的な候補として3種類の作業が挙がっています。1つ目は、タスクあたりのコストが制約となる高頻度のエージェント作業で、バックオフィス業務の大部分がこれに当たります。

2つ目は、複数ステップのツール呼び出しエージェントで、ツール呼び出しとトークンが少ない効率が数千回の実行を通じて積み重なります。3つ目は、コーディングおよびターミナルのエージェントで、同じ層のベンチマークでリードしています（参照*5）。

ただし、安くすれば使われるとは限りません。Anthropicの分析では、ClaudeのAPI記録のサンプルでタスクの特性を調整すると、コストが1%上昇するごとに利用頻度は0.29%低下しました。この推定によれば、特定のタスクのコストが10%下がっても、利用は約3%増えるだけです（参照*8）。価格が下がっても利用が劇的には増えないという事実は、モデルの普及を考えるうえで重要な視点だと思います。

安いモデルが上位に近い評価へ届いた測定例もあります。ある評価研究では、gpt-5.6-solのタスクあたり平均コストは8.51ドルで、gemma-4-31b-itの0.02ドルの411倍でした。

平均スコアの差は4.18点です。gpt-5.6-lunaはタスクあたり0.15ドルで7.46点に達し、リーダーの平均スコアの93%を1.8%のコストで実現し、過半数成功率は60%でした（参照*9）。

データ利用と地域の制約

Contributor tierは価格が下がる代わりに、学習利用と地域の条件が付きます。この条件を見落としたまま業務に使うのは、後から問題になりやすい典型的なパターンです。

割引の引き換えになるのは、学習への利用許可です。Muse Spark 1.3 Contributorは、将来のMetaモデルのトレーニングにプロンプトと完了文を使用する許可と引き換えに、トークン価格が大幅に割引されます。

利用できる地域は、Metaの地理的利用ポリシーで許可された地域に限られます。モデルごとの扱いも違い、Grok 4.6とGPT 5.6 Lunaは学習に使用されずデータ保持は30日、Muse Spark 1.3 Contributorは学習に使用され、ZDRではありません（参照*1）。

Beamは、作業の機密性に合わせてtierを選ぶよう求めています。Beamによれば、Metaの低価格なContributor tierは大幅な割引と引き換えに入力と出力を学習に使用する権利を認めており、標準tierでは認められていません。規制対象のデータを送る前に、正確な学習および保持の条件を確認するよう促しています（参照*5）。私がAI導入支援をしていて感じるのは、こうした利用規約の確認を法務やコンプライアンスと連携してやれている組織は、まだ少数だということです。便利さに引っ張られてルールが後回しになるのは、AIに限らず技術導入の典型的な落とし穴です。

組織側で使わせないようにする手段もあります。OpenCode Zenでは、管理者がワークスペースごとに特定のモデルを有効化または無効化できます。

無効にしたモデルへのリクエストはエラーを返します。これは、データを収集するモデルの利用を止めたい場合に役立つ機能です（参照*2）。

振り分けとフォールバック設計

社内アプリでは、すべてを1つのモデルに任せず、難易度で振り分ける設計が使われます。この「振り分ける」という発想は、私がコンサルティングの現場でよく伝えることでもあります。「AIに何をさせるか」を決めずに導入すると、すべてのタスクをフロンティアモデルに投げて予算を使い切る、という結果になりやすいからです。

研究では、静的なモデル展開の弱点が整理されています。小規模なモデルは通常の問い合わせには十分ですが、複雑なタスクにはより高性能なモデルが必要です。

静的なモデル展開では、入力される問い合わせの複雑さや分野が考慮されないため、性能が最適化されずコストが増加します。問い合わせの特性に基づいてモデルを適応的に選ぶ動的ルーティングが、この課題への解決策として登場しています（参照*10）。

カスケードは、安い側から始める組み方です。典型的な構成では、まず小規模で安価なLLMに問い合わせて初期回答を作ります。その回答の品質に基づいて、システムは回答を受け入れるか、より大規模で高性能なLLMへ問い合わせを引き上げて改善または再生成するかを決めます（参照*10）。

こうした構成は支出管理の手段として広がっているという指摘もあります。tech-insiderの記事は、最初に安価なモデルを使い、難しいケースでは高価なモデルをフォールバックとして使う階層型ルーティングが、AIチャットボットの支出を管理しようとするチームにとって急速に標準的なアーキテクチャになっていると述べています（参照*7）。

寄せる前に確認する落とし穴

初期に報告された失敗モード

公開直後には、ループや分野ごとのばらつきといった報告が出ています。新モデルを評価するとき、私はこういった初期報告を重視します。宣伝文句より、実際に使った人の「うまくいかなかった」報告のほうが、導入判断に役立つからです。

1つ目は、同じファイルを行き来する動きです。Beamによると、エージェントがファイルを作成した直後に同じファイルを再読または再編集したり、自分の作業を編集してから取り消したりするという報告が複数あります。これはコンテキストを消費し、実行を停滞させます（参照*5）。

2つ目は、分野や言語による差です。フロントエンド作業では強い報告がある一方、一部の言語では明らかに弱く、Rustが低い点として挙げられています。

能力は、任せる可能性のある仕事全体で均一ではないという整理です。そしてBeamは、これが初期段階の話であり、モデルが登場して数日しかたっていない、公開ベンチマークと個々の開発者による実行に基づく第一印象だと注記しています（参照*5）。

評価研究では、できたと言い切る傾向が最も多く観測されました。この研究で最も頻繁に付いたタグはoverclaimingで、評価の31.4%に付与されました。続いてmissing_artifactsが22.6%、shallow_analysisが17.7%、truncated_runが16.4%、premature_completionが12.5%でした（参照*9）。AIの出力が「完了した」と返してきても、実際には途中で止まっていたり、成果物が欠けていたりするケースは、私自身も業務で経験しています。チェックなしに次の工程に進むと、後になって全体をやり直すことになります。

自前評価とコスト上限

切り替えの判断は、自分たちの環境での評価と、支払いの上限設定がセットになります。ここを省略すると、コスト削減のつもりが品質問題の発生で余計な修正コストがかかる、という結果になりがちです。

Beamは、公開ベンチマークだけで決めないよう求めています。実行を先に進める前に各ステップが実際に完了したことを確認するチェック、ループを止めるリトライとガードレール、そして公開ベンチマークではなく自分のリポジトリとハーネスでの評価が必要だとしています（参照*5）。

品質ゲートの枠組みを提案した研究もあります。この研究は、証拠に基づくリリース判断としてPROMOTE、HOLD、ROLLBACKを伴う品質ゲートを導入する自動セルフテストフレームワークを示しました。評価する側面は、タスク成功率、調査コンテキストの保持、P95レイテンシ、安全性合格率、証拠カバレッジという経験的に裏付けられた5つです（参照*11）。

支払いの上限にも、注意しておきたい条件があります。OpenCode Zenでは、月間の利用上限を20ドルに設定すると、Zenは1か月に20ドルを超えて使いません。ただし自動リロードを有効にしていると、残高が5ドルを下回った場合に20ドルを超えて請求される可能性があります（参照*2）。

利用ツール側にも満たすべき条件があります。アカウントにフラグが付かないように、使用するツールが不正なトラフィックを生成しないこと、広範なユーザーエージェントを使わず自身を適切に識別すること、プロンプトキャッシュを最適化できるようx-opencode-sessionヘッダーを含めることが求められています（参照*1）。

おわりに

ここまで、OpenCodeから低コストでMuse Spark 1.3 Contributorを使う道筋を見てきました。月額10ドルのOpenCode Goには、5時間・週間・月間というドル価値での上限があり、購読は任意です（参照*1）。私がこの仕組みで注目するのは、「どのモデルを使うか」でリクエスト数が変わるという設計です。安いモデルを選べばより多くのリクエストを試せるため、検証コストを下げながら自前の評価を積み重ねやすい構造になっています。

OpenCode ZenのMuse Spark 1.3 Contributor Freeは、フィードバックを集めるための期間限定の提供です（参照*2）。

寄せるかどうかは、作業の種類、データの条件、検証の体制を合わせて考える話になります。Beamは、コストに敏感でツールを多用する作業を振り分け、最も難しい長期的な推論はフロンティアモデルに任せる形を示しています（参照*5）。自分のリポジトリとハーネスでの評価や、ワークスペースでの上限設定も、その判断材料になります。私の経験上、生成AI導入で最初に詰まるのはプロンプトでもモデル選定でもなく、「AIに何をさせるか」を業務レベルで言語化するところです。Muse Spark 1.3もContributor tierの条件も、その言語化ができていれば正しく使える選択肢になります。

監修者

安達裕哉（あだちゆうや）

デロイトトーマツコンサルティングにて品質マネジメント、人事などの分野でコンサルティングに従事しその後、監査法人トーマツの中小企業向けコンサルティング部門の立ち上げに参画。大阪支社長、東京支社長を歴任したのち2013年5月にwebマーケティング、コンテンツ制作を行う「ティネクト株式会社」を設立。ビジネスメディア「Books&Apps」を運営。
2023年7月に生成AIコンサルティング、およびAIメディア運営を行う「ワークワンダース株式会社」を設立。ICJ2号ファンドによる調達を実施(1.3億円)。
著書「頭のいい人が話す前に考えていること」が、95万部（2026年6月時点）を売り上げる。
（“2023年・2024年上半期に日本で一番売れたビジネス書”（トーハン調べ／日販調べ））