Muse Spark 1.3の変更点と料金｜企業導入の判断軸【2026年9月】

最終更新：2026年9月

「Metaが安いモデルを出したらしいけど、うちで使っていいものなの？」

2026年9月2日にMetaが公開したMuse Spark 1.3は、発表直後から日本語のニュースサイトやSNSでも一気に話題になりました。理由ははっきりしていて、価格です。データを学習に使わせることに同意する「Contributor」枠を選ぶと、入力が100万トークンあたり$0.10、出力が$0.20。同じ作業をClaude Opus 5やGPT-6 Astraで回すのと比べると、桁がひとつ違います。

ただ、この手の話は「安い」だけを見て決めると、あとで確実に揉めます。安さの原資が何なのか、自社のコードや顧客情報を入れてよい枠なのか、既存のClaude CodeやCodexを置き換える話なのか、それとも別枠で足す話なのか。ここを整理しないまま現場が使い始めると、情報システム部門と法務が後追いで止めることになります。

この記事では、Metaの公式発表・公式モデルページ・公式ドキュメントで2026年9月5日時点で実際に確認できる数字だけを並べたうえで、中小企業や事業部門がMuse Spark 1.3を業務に入れるかどうかを決めるための判断軸を整理します。ベンチマークの解説記事はすでに数多く出ているので、ここでは「契約・費用・運用リスク」に寄せます。読み終えたら、そのまま社内の稟議メモに転記できる粒度にしてあります。

なお、Metaのモデル群とMuse Codeの位置づけそのものについてはMeta Muse Codeとは｜Claude Code比較で、それ以前の世代についてはMuse Spark 1.1参入｜Claude Code比較で扱っています。AI導入そのものの進め方はAI導入戦略ガイドにまとめています。

Muse Spark 1.3で1.2から何が変わったのか

Metaは2026年9月2日、AI Research（研究部門）のブログでIntroducing Muse Spark 1.3を公開しました。公式に書かれている変更点は、大きく4つです。

• 長い時間軸の作業を1つのスレッドで続けられる：複数のワークフローを並行して進めながら、途中で作業が崩れにくくなったとしています。長期のコーディングタスクで訓練されたと明記されています。
• 複雑で長い指示への追従が改善：多段階の指示を保持し続ける能力が上がったとされています。
• 自分の能力と限界の認識が向上：できないことをできると言い張らず、確認を挟む挙動が強化されたという説明です。
• 効率の改善：Metaのエンジニアによる比較で、同じ作業に対してツール呼び出しが約20%、トークン消費が約25%少なくなったと記載されています。

ここで大事なのは、この20%／25%という数字が「Metaのエンジニアによる比較（In comparisons by Meta engineers）」だと公式ブログ自身が明記している点です。第三者が独立に検証した値ではありませんし、比較に使われたタスクの内訳も公開されていません。社内説明で使うときは「Metaの発表値」と必ず添えてください。

ベンチマークについては、Metaは1.3・1.2・GPT 5.6 Sol（max）・Opus 5（max）を並べたスコアカードを公開しています。日本語ではPC Watchの記事が主要な値を伝えており、長文脈のMRCR 256K–512Kで98.5、コーディングのDeepSWE v1.1で75.4といった数字が挙げられています。

提供形態はMuse CodeとMeta Model APIの2経路で、発表当日からロールアウトが始まりました。ただし「max reasoning」モードは追加の安全テストを終えてから提供するとされており、発表時点では全モードが揃っていません。この点は後述の「ベンチマークの読み方」で効いてきます。

もう1点、公式ブログには安全性の改善も書かれています。敵対的な入力とプロンプトインジェクションへの耐性を強化し、取り返しのつかない操作に対する校正を改善した、という趣旨です。エージェントとして端末やCIで動かす前提のモデルなので、この項目は機能追加ではなく前提条件として読むべきところです。

料金とレート上限｜Standard版とContributor版の実額

ここが今回いちばん実務に効くところです。発表翌日の時点では「1.3の確定価格は公式に出ていない」と書いている解説記事もありましたが、2026年9月5日時点で、Metaの公式モデルページと公式ドキュメントの両方に1.3の単価が掲載されています。以下はMuse SparkモデルページおよびMeta Model API 公式ドキュメントの料金・レート上限ページ（いずれも参照日 2026年9月4日）の表記です。

単位はすべて米ドル・100万トークンあたりです。日本円での請求額は為替と課税区分で変わるため、社内資料に載せるときはドル建てのまま置いて、換算値は「参考」と明示するのが安全です。参考までに、前掲のPC Watchは入力$1.25を約199円、出力$4.25を約676円と換算しています（2026年9月2日時点の為替）。

レート上限で注意したいのは、安いContributor版のほうがリクエスト上限が厳しい点です。Standard版が毎分3,000リクエストなのに対し、Contributor版は毎分100リクエスト。並列でエージェントを走らせる使い方だと、価格以前に上限で詰まります。「安いほうで全部回す」という設計は、料金表だけでなくレート上限の面でも成立しません。

なお同じ料金ページには、画像生成のMuse Imageが1枚あたり$0.01、音声書き起こしのMuse Voice Transcribeが1時間あたり$0.18という記載もあります。Muse Spark 1.3はテキストだけでなく動画・画像・文書をそのまま扱えるマルチモーダルモデルとしてモデルページに記載されているので、周辺モデルの単価も合わせて見ておくと見積もりがぶれません。

他社モデルの単価と並べたい場合は、毎月更新している主要AIモデルAPI料金 横断比較と主要AIモデル コンテキスト長 横断比較を参照してください。

Contributor版が安い理由｜「学習に使わせる」対価の中身

公式ドキュメントの表現は明確です。Standard版については「あなたのプロンプトと出力はMetaのモデルの学習に使われない（your prompts and completions are not used to train Meta models）」、Contributor版については「あなたのプロンプトと出力を将来のMetaモデルの学習に使う許可（permission to use your prompts and completions to train future Meta models）」と書かれています。モデルページ側でも、1.3-contributorは「Used to improve our products」、1.3は「Not used to improve our products」と対比で書かれています。

つまり入力で12.5分の1、出力で21.25分の1という価格差は、値引きではなく取引です。渡しているのは、自社のプロンプト（＝業務の手順や判断基準そのもの）と、モデルの出力（＝それに対する成果物）です。

事例区分: 想定シナリオ
以下は実際の測定結果ではなく、公式仕様から導いた構成例です。

たとえば見積書のチェック業務をContributor版に載せた場合、渡ることになるのは「見積書PDFの中身」だけではありません。「どの項目を、どの基準で、いくつ以上なら差し戻すか」という社内ルールがプロンプトに書かれていれば、それも一緒に渡ります。金額そのものより、判断基準のほうが漏らしたくない、というケースは珍しくないはずです。

逆に言えば、Contributor版が使える領域は確実にあります。公開情報しか含まない調査、社外に出しても困らないサンプルコードでの検証、OSSのドキュメント整理、社内勉強会の教材づくり。このあたりは価格差がそのまま効きます。「使ってはいけない」ではなく「入れてよいデータを先に線引きする」が正しい構えです。

実務的には、次の3分類をあらかじめ社内で決めておくと運用が楽になります。

1. Contributor版に入れてよい：公開済み情報、社外公開前提の文章、ダミーデータ、OSSコード
2. Standard版のみ可：社内文書、顧客名を含まない業務データ、自社プロダクトのコード
3. どちらも不可：個人情報、顧客の機密、契約書原本、未公表の財務情報（この層は外部APIに出す前に社内規程の確認が先）

使い方は2通り｜Muse Code（ターミナル・CI）とMeta Model API

公式ドキュメントは、両者の関係をこう説明しています。「Muse CodeとAPIは、同じモデルを使う2つの方法。既製のエージェントをコマンドラインやCIで動かすならMuse Code、自分でエージェントやアプリを作るならAPIを直接呼ぶ」。

Muse Code：ターミナルとCIで動く既製エージェント

公式ドキュメントによると、Muse CodeはMuse Sparkを土台にしたターミナル／CI向けのコーディングエージェントで、計画・編集・コマンド実行を行い、承認（approvals）とOSサンドボックスが初回実行時から有効です。導入コマンドはmacOS／Linux向けに以下が案内されています。

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

初回起動時にブラウザサインインまたはAPIキーでの認証を求められ、自動化環境では環境変数 META_API_KEY を使います。プロジェクトを開くと「このワークスペースを信頼するか」を尋ね、承認するとプロジェクトのskills・rules・hooksを読み込む設計です。CIなど非対話環境では、1つのプロンプトを最後まで実行する次のコマンドが用意されています。

muse exec "<prompt>"

ここで見落とされがちな点があります。公式ドキュメントには「既定のモデルは muse-spark-1.2」と記載されています（2026年9月4日参照時点）。つまりMuse Codeを入れただけでは1.3で動くとは限らず、モデル指定が必要になる可能性があります。「1.3を試したのに変わらなかった」という話が出たら、まず実際にどのモデルIDで動いていたかを確認してください。

Meta Model API：自社アプリに組み込む場合

APIで指定できるモデルIDは、Standard枠が muse-spark-1.3 / muse-spark-1.2 / muse-spark-1.1 / muse-image-1.0 / muse-voice-transcribe-1.0、Contributor枠が muse-spark-1.3-contributor / muse-spark-1.2-contributor です。推論の深さはリクエストごとに調整できるとされています。

社内の実装ルールとしては、モデルIDを設定ファイルの1箇所に集約し、末尾が -contributor かどうかをコードレベルで判定できるようにしておくことを推奨します。安いほうを試したまま本番に混入する事故は、モデルIDが文字列でベタ書きされている環境で起こります。

主要モデルの中での位置づけ｜公式単価と第三者スコアで並べる

「Claude CodeやCodexから乗り換えるべきか」を判断するには、単価だけでなく到達点も並べる必要があります。以下は各社の公式料金ページで2026年9月4日に確認した単価と、第三者ベンチマークサイトArtificial Analysisが2026年9月2日に公開した知能指標をまとめたものです。公式に確認できた値だけを載せています。

OpenAIの2モデルは短いコンテキストでの単価です。長いコンテキストでは別単価（GPT-6 Astraは入力$20／出力$75、GPT-5.6 Solは入力$8／出力$30）が適用されると公式料金ページに記載があります。またGPT-5.6 Solの価格は、少なくとも2026年11月21日までのプロモーション価格である旨が同ページに明記されています。Claude Sonnet 5の$2／$10は、当初は導入価格でしたが現在は標準価格になったと公式ドキュメントに記載されています。

表から読み取れることは、はっきりしています。Muse Spark 1.3のStandard版は、Claude Opus 5に近い到達点を、Opus 5の4分の1から6分の1の単価で提供しているという構図です。ただし最上位のFable 5.1（指標66）には届いていません。

そしてもう1つ、社内説明で必ず補足すべき注意点があります。Artificial Analysisの分析によれば、知能指標62を出した「max」はMetaのパートナー向け限定プレビューで、一般に使えるのは指標61の「xhigh」です。Metaの公式ブログにも「max reasoningは追加の安全テストのあとに提供」と書かれており、両者は整合しています。ベンチマークの最高値をそのまま「今日から使える性能」として稟議に書くと、あとで実測と合わなくなります。

単価が下がっても総額が下がるとは限らない

ここが、この記事でいちばんお伝えしたい部分です。

Metaの公式ブログは、社内比較でトークンが約25%減ったとしています。一方、Artificial Analysisの評価では、Muse Spark 1.3（xhigh）の1タスクあたり費用は$0.55で、これは1.2の$0.40より高いと報告されています。理由として、エージェント評価において1タスクあたりの入力トークンが約57%増えていることが挙げられています。

この2つは矛盾ではありません。測っているタスクが違うだけです。Metaは自社エンジニアの作業を、Artificial Analysisは自社の評価セットを測っています。そして、あなたの会社のタスクはそのどちらでもありません。

APIの請求は「単価×トークン数」で決まります。単価が12分の1でも、1タスクで消費するトークンが増えれば総額は下がりません。特にエージェント型の使い方は、ツールを何度も呼び、そのたびに文脈を読み直すため、トークン消費が読みにくい領域です。

したがって、社内で意思決定するときの正しい問いは「1トークンいくらか」ではなく「うちの代表的な1タスクを完了させるのに、いくらかかるか」です。これを測る手順は次の章で扱います。

契約前に情シス・法務が確認する6項目

Muse Spark 1.3に限らず、海外ベンダーのAI APIを業務に入れるときに、日本企業で実際に止まりやすいのがこの6点です。1.3について公式に確認できた事実と、確認できていない事実を分けて書きます。

1. 学習利用の有無：公式ドキュメントに明記あり。Standardは学習に使わない、Contributorは使う。→ 確認済み。契約前にどちらのモデルIDを使うかを文書で決める。
2. データの保存期間：今回参照した公式ドキュメントの範囲では、保存期間の記載を確認できませんでした。→ 未確認。ベンダーへの照会事項として残す。
3. データの保管場所（データレジデンシー）：同様に、参照した範囲では記載を確認できませんでした。→ 未確認。国内保管が要件なら、この点が解けるまで本番投入は保留。
4. レート上限：公式ドキュメントに明記あり。Standardは毎分3,000リクエスト／400万トークン、Contributorは毎分100リクエスト／300万トークン。→ 確認済み。並列処理の設計はこの範囲内で。
5. 最大出力トークン数：モデルページ・料金ページの範囲では記載を確認できませんでした。→ 未確認。長文生成が要件なら実測が必要。
6. 提供継続性：Metaはオープンウェイト版の提供を予定していると公式に述べていますが、時期は示されていません。既定モデルが1.2のままである点も含め、バージョンの切り替わりに追随できる実装にしておく。→ 一部確認済み。

「未確認」と書ける勇気が、この手の検討では効きます。埋まっていない欄を推測で埋めた資料は、あとで必ず食い違いを生みます。ベンダー照会の一覧をつくるときは、次のプロンプトをそのまま使えます。

あなたは日本企業の情報システム部門の担当者です。
以下のAI APIを業務利用する前に、ベンダーへ照会すべき事項を洗い出してください。

# 対象
- サービス名: [Meta Model API / Muse Spark 1.3]
- 用途: [社内文書の要約と分類]
- 扱うデータ: [社内文書。個人情報は含まない予定]

# 出力形式
| 確認項目 | 公開情報で確認できたか | 確認できた内容 | 未確認の場合の照会文 |

# 制約
- 公開情報で確認できていない項目は「未確認」と明記し、推測で埋めないこと
- 照会文は、そのままメールに貼れる日本語の敬体で書くこと
- 社内規程との突き合わせが必要な項目には「要社内確認」を付けること

業務に入れるかを決めるPoCの組み立て方

事例区分: 想定シナリオ
以下は実測結果ではなく、企業向けAI研修・導入支援で用いている検証設計の型です。数値は各社が自社で測る前提の枠組みとして提示しています。

新しいモデルが出るたびに全社で試そうとすると、必ず途中で止まります。対象を絞り、期間を切り、測る指標を先に決める。この3点だけを守れば、判断できる材料は集まります。

手順1：業務を1つだけ選ぶ

選定条件は3つです。①毎週発生する ②手順が言葉で説明できる ③失敗しても取り返しがつく。この3つを満たす業務が最初の候補です。逆に、月1回しか発生しない業務や、失敗が顧客に直接届く業務は最初に選ばないでください。効果が測れないか、事故になるかのどちらかです。

あなたは業務改善のコンサルタントです。
以下の部署の業務から、AIエージェントの検証対象として最適な業務を3つ選び、
それぞれ「選んだ理由」と「選ばなかった業務との違い」を書いてください。

# 部署
[例: 営業事務、5名]

# 業務一覧
[箇条書きで10〜20件。頻度と所要時間を添える]

# 選定条件
1. 毎週発生する
2. 手順を言葉で説明できる
3. 失敗しても取り返しがつく（顧客に直接届かない）

# 出力形式
| 順位 | 業務名 | 週あたり発生回数 | 選んだ理由 | 想定リスク |

手順2：入れるデータの線引きを先に決める

前述の3分類（Contributor可／Standardのみ可／どちらも不可）を、選んだ業務に当てはめます。ここでどちらも不可のデータが混ざるなら、そのデータを外した状態で検証できるかを先に確認します。外せないなら、その業務は今回の対象から降ろします。

手順3：評価指標を3つだけ決める

多くのPoCが失敗するのは、指標を決めずに「なんとなく便利だった」で終わるからです。決めるのは3つだけで十分です。

• 所要時間：着手から完了までの実測時間（担当者が計測する）
• 手戻り率：出力をそのまま使えた件数 ÷ 全件数
• 総費用：APIの請求額を件数で割った、1件あたりの実額

3つ目が今回の肝です。前章のとおり、単価が安くても総額は読めません。請求額を件数で割った実額こそが、他社モデルと比較できる唯一の数字です。

あなたはPoCの設計担当です。
以下の業務について、限られた期間で判断できる検証計画を作ってください。

# 検証期間
[2週間]

# 対象業務
[手順1で選んだ業務]

# 評価指標（この3つに限定）
1. 所要時間（着手から完了まで）
2. 手戻り率（そのまま使えた件数 ÷ 全件数）
3. 1件あたり総費用（API請求額 ÷ 件数）

# 出力形式
- 計測方法: 誰が、いつ、どうやって記録するか
- 比較対象: 現行手順の数値をどう取るか
- 継続判断の基準: どの数値ならGO、どの数値ならNO GO
- 記録シートの列定義

# 制約
- 指標を4つ以上に増やさないこと
- 「効率化された」など定性的な表現を判断基準に入れないこと

手順4：現行手順の数値を先に取る

比較対象がないPoCは、結論が出ません。AIを使う前の所要時間と手戻り率を、同じ定義で先に記録しておいてください。ここを飛ばすと、最後に「たぶん速くなった気がする」で終わります。

手順5：継続か中止かを、決めた基準で機械的に判断する

PoCの終わりに議論を始めると、声の大きい人の意見が通ります。手順3で決めたGO／NO GOの基準に照らして、事務的に決めてください。判断結果を社内に説明する文書は、次のプロンプトで下書きが作れます。

あなたは情報システム部門の責任者です。
以下のPoC結果をもとに、経営会議向けの報告メモを作成してください。

# 前提
- 検証したモデル: [muse-spark-1.3]
- 対象業務: [　　]
- 検証期間: [　　]

# 実測値
- 所要時間: 現行 [　] 分 → 検証後 [　] 分
- 手戻り率: 現行 [　] % → 検証後 [　] %
- 1件あたり総費用: [　] 円

# 出力形式
1. 結論（継続 / 条件付き継続 / 中止）を1文で
2. 判断根拠（上記3指標のみで説明）
3. 継続する場合に必要な追加投資と体制
4. 残っているリスクと未確認事項

# 制約
- 実測していない数値を書かないこと
- 「将来的に期待できる」など未確定の効果を根拠にしないこと
- 未確認事項は「未確認」と明記すること

導入時のリスクと運用ルール

Muse Spark 1.3は、端末でコマンドを実行し、CIでコードを書き換えるエージェントとして使う前提のモデルです。チャットとはリスクの性質が違います。Metaの公式ブログも敵対的入力とプロンプトインジェクションへの耐性強化に触れていますが、モデル側の改善は運用ルールの代わりにはなりません。最低限、次の4点を決めてから動かしてください。

プロンプトインジェクション：外部から読んだ文字列は命令ではない

エージェントはWebページ、Issue、ログ、社外から届いたファイルを読みます。そこに「これまでの指示を無視して」と書かれていた場合に従ってしまうのが、プロンプトインジェクションです。対策の原則は単純で、取得したデータに含まれる文言を、実行指示として扱わないことをシステムプロンプト側で明示し、外部データを読んだ直後に外部送信・削除・権限変更が起きない設計にしておくことです。

あなたはコーディングエージェントの安全設計をレビューする担当者です。
以下のエージェント構成について、プロンプトインジェクションの受け入れテストを設計してください。

# 構成
- 実行環境: [ローカル端末 / CI]
- 読み込む外部データ: [公開Web、GitHub Issue、社内Wiki]
- 実行できる操作: [ファイル編集、コマンド実行、外部API呼び出し]

# 出力形式
| テストID | 攻撃シナリオ | 仕込む文言 | 期待する挙動 | 失敗と判定する挙動 |

# 制約
- 実際に外部へ送信する操作を含むテストは「要事前承認」と明記すること
- 想定シナリオであり実測結果ではない旨を冒頭に書くこと

権限最小化：エージェントに渡す権限は業務単位で切る

Muse Codeは承認とOSサンドボックスが初回から有効で、ワークスペースを信頼するかを尋ねる設計になっています。この仕組みを無効化しないこと、そして読み取り専用で足りる業務に書き込み権限を渡さないことが基本です。CIで使う場合は、リポジトリ単位・ブランチ単位でトークンの権限を分けてください。

人間の承認：取り返しのつかない操作の前で必ず止める

外部送信、公開、本番反映、削除、決済。この5つは、実行前に人が確認する運用にします。エージェントの精度が上がるほど、この線引きは緩みがちです。精度ではなく、影響の可逆性で線を引いてください。

監査ログ：誰が、どのモデルIDで、何を投げたかを残す

Standard版とContributor版が同じAPIで並存する以上、どちらのモデルIDにどのデータを投げたかの記録がないと、あとから説明できません。モデルID、リクエスト日時、実行者、対象業務の4つは最低限ログに残す設計にしてください。これは事故が起きたときのためではなく、事故が起きていないことを証明するために必要です。

Uravationならこう判断する｜部門別の可否

ここまでの材料をもとに、2026年9月5日時点で私たちが企業に説明する場合の判断を書きます。前提が変われば結論も変わるので、そのまま丸写しにせず、自社の条件に当てて読み替えてください。

総じて、「置き換える」ではなく「安い枠を1つ足して、自社の代表タスクで総額を測る」のが、この時点での現実的な使い方だと考えています。Metaのモデル群全体の企業向け整理はLlama 4導入ガイド｜Muse Sparkとの違いと活用法、Muse Spark登場時の市場の反応はMeta Muse Spark発表｜株価9%急騰にまとめています。

よくある失敗パターンと回避策

失敗1：Contributor版の単価で全社の費用を試算してしまう

❌ 「入力$0.10だから、うちの規模なら月数千円で済む」と稟議に書く
⭕ 業務データを扱う前提ならStandard版（入力$1.25／出力$4.25）で試算し、Contributor版は公開情報を扱う用途に限って別枠で計上する

なぜ重要か：この誤りは、金額が10倍以上ずれるだけでなく、「業務データを学習に渡す前提の見積もり」を経営が承認したことになってしまいます。数字の間違いより、こちらのほうが深刻です。

失敗2：ベンチマークの最高値を「今日使える性能」として説明する

❌ 「Opus 5を超えるスコアが出ている」と報告する
⭕ 「最高値は限定プレビューの max 版。一般提供の xhigh 版は第三者指標で61で、Opus 5の63には届いていない」と分けて報告する

なぜ重要か：Metaの公式ブログ自身が「max reasoningは追加の安全テストのあとに提供」と書いています。使えないモードの数字で意思決定すると、導入後に「話が違う」となります。

失敗3：単価だけを比較して総額を測らない

❌ 「単価が4分の1だから費用も4分の1」と結論づける
⭕ 自社の代表タスクを一定件数流し、API請求額を件数で割った実額で比較する

なぜ重要か：第三者評価では、1.3の1タスクあたり費用は1.2より上がっています（$0.40→$0.55、エージェント評価で入力トークンが約57%増）。単価と総額は別物です。

失敗4：Muse Codeを入れただけで1.3が動いていると思い込む

❌ 導入コマンドを実行し、そのまま「1.3を検証した」と報告する
⭕ 実行時のモデルIDを確認し、記録に残す（公式ドキュメントの既定モデルは muse-spark-1.2 と記載されている）

なぜ重要か：検証の前提が崩れます。「変わらなかった」という結論が、実は旧バージョンを測っていただけ、という事故はバージョン切り替え期に頻発します。

よくある質問

Muse Spark 1.3の料金はいくらですか？

2026年9月5日時点で、公式モデルページと公式ドキュメントに1.3の単価が掲載されています。Standard版（muse-spark-1.3）が100万トークンあたり入力$1.25・キャッシュ入力$0.15・出力$4.25、Contributor版（muse-spark-1.3-contributor）が入力$0.10・キャッシュ入力$0.002・出力$0.20です。単位は米ドルです。

Contributor版と通常版の違いは何ですか？

価格と、プロンプト・出力の扱い、そしてレート上限が違います。Contributor版は「あなたのプロンプトと出力を将来のMetaモデルの学習に使う許可」と引き換えに安く提供されるもので、リクエスト上限は毎分100件です。Standard版は「学習に使われない」と明記されており、上限は毎分3,000件です。業務データを扱うならStandard版を選んでください。

1.2から乗り換えるべきですか？

単価は1.2と1.3で同額です（公式料金ページは1.3・1.2・1.1を同じ単価で掲載）。したがって、性能が上がるなら移行しない理由は基本的にありません。ただし1タスクあたりのトークン消費が増える可能性があるため、移行前後で請求額を件数で割った実額を比較してください。またMuse Codeの既定モデルは公式ドキュメント上で1.2のままなので、明示的な指定が必要です。

コンテキスト長は本当に100万トークン使えますか？

公式モデルページには1M（100万）トークンと記載されています。ただし、長い文脈を入れれば入れるほど入力トークンの請求は増えます。「入るから全部入れる」は費用面で不利になりやすいので、必要な範囲に絞る設計を前提にしてください。他モデルとの比較は主要AIモデル コンテキスト長 横断比較を参照してください。

日本国内にデータは保管されますか？

2026年9月5日時点で、本記事が参照した公式モデルページおよび公式ドキュメントの範囲では、データの保管場所と保存期間についての記載を確認できていません。国内保管や保存期間が要件になっている場合は、この点をベンダーに照会し、回答が得られるまで本番投入を保留するのが安全です。

参考・出典

• Introducing Muse Spark 1.3 — Meta AI Research（公開日: 2026-09-02 / 参照日: 2026-09-04）
• Muse Spark モデルページ — Meta for Developers（参照日: 2026-09-04）
• Pricing and rate limits — Meta Model API 公式ドキュメント（参照日: 2026-09-04）
• Muse Code — Meta Model API 公式ドキュメント（参照日: 2026-09-04）
• Meta、コードもエージェントも強化「Muse Spark 1.3」。オープンウェイト化へ — PC Watch（公開日: 2026-09-02 / 参照日: 2026-09-04）
• Muse Spark 1.3: Meta reaches the frontier — Artificial Analysis（公開日: 2026-09-02 / 参照日: 2026-09-04）
• Pricing — Anthropic 公式ドキュメント（参照日: 2026-09-04）
• Pricing — OpenAI 公式ドキュメント（参照日: 2026-09-04）

まとめ：今日から始める3つのアクション

1. 今日やること：自社で「Contributor版に入れてよいデータ／Standard版のみ可／どちらも不可」の3分類を紙1枚で決める。これが決まっていないと、価格の話は前に進みません。
2. 今週中：毎週発生し、手順が説明でき、失敗しても取り返しがつく業務を1つ選び、現行手順の所要時間と手戻り率を記録し始める。比較対象がなければPoCは結論を出せません。
3. 今月中：選んだ業務をStandard版（muse-spark-1.3）で回し、API請求額を件数で割った1件あたり実額を出す。単価ではなく総額で、既存のモデルと並べて判断する。

あわせて読みたい：

• Meta Muse Codeとは｜Claude Code比較 — ターミナル型エージェントとしての立ち位置
• 主要AIモデルAPI料金 横断比較 — 各社の最新単価を毎月更新

著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。
100社以上の企業向けAI研修・導入支援。著書『AIエージェント仕事術』『Claude仕事術』（SBクリエイティブ・シリーズ累計50,000部突破）。
SBクリエイティブ「ビジネス+IT」ほかで生成AI連載を執筆（NewsPicks最大1,125ピックス）。

ご質問・ご相談はお問い合わせフォームからお気軽にどうぞ。