Muse WonderとFullはどこで使える?APIとMuse Codeの利用条件

Wonderの公式API IDとFullのサブスクリプション条件を確認し、地域・アカウント・課金・初回リクエストの違いを整理します。

クリーム色のカードに描かれたタイプライター。Muse CodeとAPIの選択肢を表しています。

Muse WonderはMetaのModel APIとMuse Codeで利用できます。Muse Wonder Fullは現在、Muse CodeのPower UsageおよびMaximum Usage契約者向け特典であり、従量課金のModel APIモデルではありません。Wonderの推論強度をmaxに上げてもFullには変わりません。

Metaの10月12日の発表では、複数の製品が同時に紹介されました。本稿は2026年10月15日に確認した公式モデル文書を基に、それぞれの利用・課金条件を分けて説明します。アカウント登録、サブスクリプション購入、有料API例の実行はしていません。文書に利用経路があることと、個々のアカウントに権限があることは別です。

目的に合う利用経路を選ぶ

経路現在提供されているもの思い込まないようにしたい点
従量課金のModel APIWonder、正確なIDはmuse-wonder-1.0現在、Fullの従量課金APIモデルはない
Muse CodeWonder。FullはPower UsageまたはMaximum Usageで利用契約は汎用APIトークンのパッケージではない
一般向けMuse提供開始を予告、当初は契約者向け「近日公開」は全アカウントが今日選択できる証拠ではない

モデル文書では、Wonderはテキスト、画像、動画、音声、PDFを入力でき、出力はテキストとされています。マルチモーダル入力への対応は、画像・動画生成への対応ではありません。コンテキストは1,048,576トークンで、推論レベルはmaxまでありますが、これらの設定だけでは実タスクの品質やFullの利用権は判断できません。

Fullが目的なら、対象のMuse Code契約と実際のモデル選択欄から確認してください。muse-wonder-fullのようなAPI識別子を作り出したり、別モデルになることを期待して推論パラメータを上げ続けたりしないでください。

地域とアカウントの条件を先に確認する

登録ガイドは、18歳以上であること、対応地域にいること、アカウント・チームを用意することを求めています。APIリクエストの送信には、必要な支払い設定とAPIキーも必要です。登録だけでAPIの準備が完了するわけではありません。

10月12日更新のGeographic Use Policyは、制限対象地域として香港・マカオを含む中国とロシアを明記しています。これらの地域からのアクセスに加え、同地域のエンドユーザーにモデル組み込み製品を提供することも制限し、地域制限の回避を禁止しています。全対象地域と条件は現行ポリシー全文を確認してください。この段落は対象国の完全な一覧ではありません。

言語と所在地は別です。別の地域に住む中国語・ロシア語話者も、自分の法域とアカウントを確認する必要があります。一方、確認した制限一覧に日本や韓国がないことは、現地の全アカウント、支払い手段、契約特典を当方が検証したことを意味しません。実際の対応国と登録条件が引き続き適用されます。

所在地や用途が制限対象なら調査にとどめ、その用途が認められたサービスを選んでください。ゲートウェイ、VPN、海外の支払い手段は、元のポリシーが適用されなくなる証拠ではありません。

Wonderの公式API設定

API概要とCreate a responseリファレンスが示す経路は次のとおりです。

項目文書に記載された値
ベースURLhttps://api.meta.ai/v1
ResponsesエンドポイントPOST https://api.meta.ai/v1/responses
モデルmuse-wonder-1.0
認証Authorization: Bearer $MODEL_API_KEY
最小の本文フィールドmodel、input

文書にはChat CompletionsとMessagesインターフェースもあります。一つの文書化されたインターフェースを選び、それに対応するリクエスト形式を使ってください。別系統のAPIの本文を貼り付け、URLだけ変えればよいと考えないでください。汎用例の一部はMuse Sparkを使っていますが、公式概要はWonder用にモデルをmuse-wonder-1.0へ置き換えられると明記しています。

以下は利用資格のあるアカウント向けの、文書に基づく最小Responsesリクエストです。実行すると利用料金が発生し得ます。この記事のためには実行していません。キーは自分の環境で安全に設定し、本物のキーを記事、スクリーンショット、共有ターミナルログに載せないでください。

curl --fail-with-body -sS https://api.meta.ai/v1/responses \
  -H "Authorization: Bearer $MODEL_API_KEY" \
  -H 'Content-Type: application/json' \
  -d '{"model":"muse-wonder-1.0","input":"Reply with the word ready."}'

ここでreadyは要求する合格目標であり、取得済みの応答ではありません。Meta文書のようにOpenAI SDKを使う場合は、MetaのベースURLとMetaのキーを両方設定してください。SDK標準のOpenAIエンドポイントを残すと、別の提供元にリクエストを送ることになります。

初回リクエストの結果を確認する

アクセス確認シートで、許可されたリクエストの実行前後の確認を記録してください。認証情報も、成功済みと記入された結果も含まれていません。

実行前に、選んだ製品、地域ポリシーの確認、アカウント・チーム、モデル利用権、課金元、エンドポイント、正確なモデルIDを記録します。従量課金の呼び出しを意図しているか確認してください。Code契約でその料金を賄えるとは限りません。

実行後は次を確認します。

  1. HTTPステータスと構造化されたエラー。ネットワークから応答があっても、推論成功とは限りません。
  2. 応答の状態。不完全または失敗なら詳細を調べ、オブジェクトが返っただけで回答完了と扱わないでください。
  3. outputのメッセージ項目内にあるテキストとoutput_textの内容。RESTの生JSONに、単一のトップレベル回答文字列があるとは限りません。
  4. 指示した出力タスク、提供される場合は返却されたモデル情報、使用量フィールド。
  5. 対応するアカウントの使用量と請求記録。回答だけでは、どの残高が使われたか分かりません。

自分の組織の方針が許す場合は、機密情報を除いた結果と時刻を保存します。公式サンプル応答を、Ofoxがモデルをテストしたという主張に置き換えないでください。本稿が提供するのは確認手順であり、作り物の応答スクリーンショットではありません。

Muse Codeの契約は認証情報も異なる

契約文書によると、サブスクリプション利用はCLIの初期設定で自動接続される認証情報に結び付いており、Muse Code用です。別途作成した追加APIキーは従量課金のままです。契約後に新しいAPIキーでアプリを作っても、Codeの利用枠が自動で引き継がれるわけではありません。

同じ文書では、サブスクリプションの既定値がContributorモードで、内容を学習に利用できると説明されています。これは無効化でき、その設定では無効化後の新しい内容は学習に使われません。非公開の仕事を送信する前に、現在のアカウント設定とポリシーを確認してください。Wonderの従量課金提供はStandardモードです。契約のモードや特典が別のAPIキーに移ると考えないでください。

Fullの利用には、指定された契約階層と実際の登録時の提供状況が関係します。地域によって特典が異なる場合もあります。世界共通の利用権を約束するのではなく、アカウントに表示される内容を記録してください。

モデルが見つからない・リクエストが失敗する場合

症状次に確認すること判断に必要な証拠
従量課金モデル一覧にFullがない製品の経路公式情報ではFullはCode契約特典
Wonderの呼び出しが別の提供元に届くベースURLとSDK初期化Metaのエンドポイントと意図したキーを併せて設定
認証や権限のエラーキーの有効性、チーム、アカウント権限機密情報を除いたエラーとアカウント設定。秘密鍵自体は共有しない
モデルが見つからない正確なIDと対応インターフェース公式経路のmuse-wonder-1.0とアカウントの利用権
Code契約があるのにAPI料金が発生認証情報の作成元と請求独立したAPIキーか、Code初期設定で接続した認証情報か
一般向けアプリにモデルがない段階的提供とアカウントの状況発表だけでなく、実際のモデル選択欄

何かが返るまで無関係な識別子を試さないでください。別モデルをテストしただけで、元の問題が残る可能性があります。最初のエラーを保存し、設定上の問題を一つずつ変更します。

発表だけでは確認できないこと

発表ではActive MemoryとFocusをシステム機能として説明しています。これは、すべての生APIリクエストが自動的にセッション間の記憶を保持する証拠ではありません。使うエンドポイントと製品の仕様に沿って状態管理を設計し、自分の許可されたテストで動作を確かめてください。

同様に、発表時のベンチマークは個別タスクの比較ではありません。本稿ではWonderを他モデルと順位付けせず、Ofoxでの利用可否や未検証の価格も提示していません。ファイル公開とアカウント利用を分ける関連例として、Step 5 Previewの重みとAPI経路も参照してください。

正しい製品とモデルを特定し、適用される地域・アカウント条件、実際の課金経路、自分で許可の範囲内で行った確認結果を記録できれば、課題は完了です。不明な項目は未解決のまま残し、発表をデプロイ成功の証拠に読み替えないでください。