TL;DR: 以前、「AIモデルの『できる／できない』をベンダー単位のラベルだけで判断すると危ういかもしれない」という記事を公開した。Meta社のAI API「Muse Spark」を検証し、「Web検索は今回試したエンドポイント・パラメータでは使えなかった」「画像生成は今回試したモデル名では使えなかった」という2つの結果を報告した記事だったように思う。当時の記事は「他のエンドポイント/設定は未確認」と明記していたので、その"未確認"の部分を、その後じっくり読み進めた公式ドキュメントを頼りに実際に確認しに行ってみた。結果、Web検索はChat CompletionsではなくResponses APIを使えば動作し(実機で内閣総理大臣クエリを投げ、根拠としてkantei.go.jpを含む引用付きで、確認日時点の現職の名前が返ってきた)、画像生成はmuse-spark-1.2ではなく専用モデルmuse-image-1.0を呼べば成功する(実機で1600×1600のWebP画像を生成できた)ことが分かった。この基盤には開発者向けAPIだけでなく、ターミナルで動くコーディングエージェント「Muse Code」、オープンウェイトのローカル動作モデル「Muse Glimmer」という別の製品群もあるようだと分かったので、公式ドキュメントで確認できた範囲で併せて紹介する。

(本記事の図版は、今回検証対象そのものであるmuse-image-1.0(Muse Image)で生成した)

1. 前回の記事のおさらいと、話の発端

以前、「AIモデルの『できる／できない』を、ベンダー単位のラベルだけで判断すると危ういかもしれない」という記事をQiita・Zenn・Mediumの3プラットフォームに公開したのだった。Meta社の新しいAI API「Muse Spark」を実際に検証し、公式発表やパートナー企業のコメントで示唆されていた「Web検索」「画像生成」の2機能を試したところ、いずれもエラーで拒否された、という内容だったように記憶している。

読み返すと、当時の記事は結論をかなり慎重にスコープを限定して書いていた。判断表には「Web検索グラウンディング | 今回試した組み合わせでは失敗 | ...他の設定は未確認」「画像生成機能 | 今回試した組み合わせでは失敗 | ...他のエンドポイント/設定は未確認」と、はっきり"宿題"として残していた。今回の記事は、その宿題を実際に片付けに行った記録、と言えるかもしれない。

きっかけは、Meta社の公式ドキュメントサイトを一通り読み進める機会があったことだった。APIリファレンス、各プロトコルの解説ページ、エラーハンドリングの仕様など、前回の検証では見ていなかったページを確認していくうちに、「他のエンドポイント/設定は未確認」としていた部分について、実際に試せる材料が揃っていることに、ようやく気づいた。

2. 確認1: Web検索は`Chat Completions`では使えないが、`Responses API`では使えた

前回の記事では、client.chat.completions.create(...)に対してtools=[{"type": "web_search"}]、extra_body={"web_search": True}、extra_body={"web_search_options": {}}という3通りのパラメータを試し、いずれも400エラーで拒否されたことを報告していた。

Meta公式の「Search grounding」ドキュメントページ(dev.meta.ai、開発者アカウントでのログイン後に閲覧可能なページ、2026-08-30確認)には、次のように明記されていた。

Search grounding is not available through the Chat Completions API.

つまり、前回検証したChat CompletionsでWeb検索が拒否されたこと自体は正確な観測で、そこは公式ドキュメントとも矛盾しない。ただ、Meta Model APIにはChat Completions以外に「Responses API」というもう一つの呼び出し形式があり、公式ドキュメントによれば、こちらでは検索が正式にサポートされているらしい。

実際に、同じAPIキーでResponses APIを使って再検証してみることにした。

response = client.responses.create(
    model="muse-spark-1.2",
    input="2026年8月時点の日本の内閣総理大臣は誰ですか？",
    tools=[{"type": "web_search"}],
)

結果、14件のweb_search_callが完了し、グラウンディングされた回答として「高市早苗」(2025年10月21日就任)という現職の名前が返ってきた。根拠としてkantei.go.jp(首相官邸公式ドメイン)を含む引用も付いていた。検索なしのベースライン(同じ質問を検索toolなしで投げた場合)では「石破茂」という、より古い時点の情報が返ってきており、両者を比べると、検索toolを付けた場合の方が確認日時点の実際の状況に近い回答だった、と言えそうだ(検索なし回答が「学習データが古いため」なのか、別の要因によるものかまでは、この1件の比較だけでは断定できない)。

少なくとも、確認日時点のこのアカウント・このモデル・Responses APIの組み合わせでは、検索付きのグラウンディング応答が実際に返ってきた、ということは言えると思う。ただし、web_search_callが14件実行されたことと、返ってきた回答・引用の内容が完全に正確であることは別の話でもある。個々の引用URLの中身を1件ずつ照合したわけではないので、その点は留保しておきたい。

3. 確認2: 画像生成は`muse-spark-1.2`では使えないが、専用モデル`muse-image-1.0`では使えた

前回の記事では、client.images.generate(model="muse-spark-1.2", ...)が404 model_not_foundを返したことを報告していた。これも、テストした範囲では正確な観測だったのだろうと思う。

その後、公式ドキュメントを読み進めると、Metaはテキスト・画像理解・推論を担うMuse Sparkとは別に、画像生成専用の別モデルmuse-image-1.0を提供していることが分かってきた(dev.meta.ai「Image generation with Muse Image」ドキュメントページ、2026-08-30確認)。専用のエンドポイント(/v1/images/generations、/v1/images/edits)を持ち、Responses API経由ではテキストと画像を交互に生成する対話的な画像編集にも対応しているとのことだった。

実際に、同じAPIキーでmuse-image-1.0を指定して再検証してみることにした。

client.images.generate(
    model="muse-image-1.0",
    prompt="a small red circle on a plain white background, minimal flat icon style",
    n=1,
)

結果、1600×1600ピクセルのWebP画像が返ってきて、目視で確認したところ、指示通り白背景に赤い円が描かれているようだった。ドキュメント記載の料金は1枚あたり定額$0.01(トークン従量制ではない)とのことだった。

「Muse Sparkは画像生成できない」という前回の観測は、muse-spark-1.2というモデル名の範囲では正確だった。今回分かったのは、Metaのミューズ系モデル全体で見ると、画像生成専用の別モデルが用意されている、という追加情報だったのだろう。

4. 前回の記事は、結局どこまで正しかったのか

ここで一度、前回の記事の位置づけを整理し直してみたい。

前回の記事の結論は、こうだった。

ある機能が「使えるか」を、モデルやベンダーに貼れる一枚看板のラベルだけで済ませるのは危うい。モデルの版・エンドポイント・ペイロードの組み合わせごとに確かめ直す必要がある。

そして、実際に前回の記事の本文・判断表を読み返してみると、この教訓通り「今回試した組み合わせでは失敗」「他のエンドポイント/設定は未確認」と、きちんとスコープを限定して書かれていた。つまり、前回の記事が自分自身の教訓を真正面から破っていた、とまでは言えなさそうに思える。前回の記事は宿題を残しただけで、教訓自体には従っていたことになる。

ただし、それでもなお、今回わざわざこの続編を書く意味はあると思っている。理由は2つある。

1つ目は、実務上の話として、「今回試した範囲では失敗」という慎重な書き方をしていても、記事のタイトルや読後感としては「このAPIは検索も画像生成もできない」という単純化された印象の方が強く残りやすい、という点なのかもしれない。実際、この記事を書く前の自分自身が、まさにそう記憶していた。厳密には正しく書いていたはずの前回の記事の細部を、書いた本人が忘れていた、というのが正直なところなのかもしれない。

2つ目の理由として、前回の記事が「未確認」として残した宿題を、実際に片付けてみせること自体が、記事の結論(記録を残し、機会があれば再検証する)の実践になるのではないか、と考えたからだった。教訓を破っていたかどうかより、教訓を実際にやり切ったかどうかの方が、今回はむしろ大事な論点だったように思う。

5. 確認の先に見えた、Metaのミューズ系AI基盤の全体像

今回の確認作業のために公式ドキュメントを一通り読み進める過程で、Muse Sparkという1つのモデルの話にとどまらない、Meta AI基盤の全体像が見えてきたので、公式ドキュメントで確認できた範囲で、簡単に整理しておきたい(以下の情報は主にdev.meta.ai配下の開発者向けドキュメント、2026-08-30確認時点のものです)。

Metaの「Muse」系AI基盤は、大きく3つの製品ラインに分かれているようだ。

製品	位置づけ	使い方
Model API	Muse Sparkを開発者がコードから直接呼ぶAPI	HTTP API、3種類の呼び出し形式(後述)から選択
Muse Code	ターミナル/CIで動くコーディングエージェントCLI	`muse`コマンドをインストールして対話/ヘッドレス実行
Muse Glimmer	オープンウェイトのローカル動作モデル(30B)	重みをダウンロードし、自分のGPU/CPU上でvLLM・llama.cpp等でホスト

Model APIの3つの呼び出し形式

前回の記事の宿題の原因になった「エンドポイントの違い」を整理すると、Model APIの公式ドキュメント(「Choosing an API」ページ)には、3種類の呼び出し方式が説明されている。

形式	特徴
Responses API	reasoning(思考過程)をターン間で保持でき、検索・エージェント的な多段処理向け。Web検索が使えるのはこちら
Chat Completions	OpenAI互換。単発〜簡易な会話向け。Web検索は使えない(これが前回の記事の宿題の元)
Messages API	Anthropic(Claude)互換。公式ドキュメントによれば「stateless」なアダプタで、内部的にはResponses API向けのリクエストに変換して同じパイプラインで処理される、と説明されている。検索toolもそのまま利用できるという

公式ドキュメントには「3形式とも同じモデルを呼び、同じベアラートークン認証を使い、トークンあたりの料金も同じ」という趣旨の記載があった。「どの形式を使うか」で機能の有無が変わってしまう、という点が今回確認した内容の核心だったのだろうと思う。

Muse Code: ターミナルで動くコーディングエージェント

Muse Codeは、Claude CodeやCodex CLIと同種の、ターミナル/CIで動くコーディングエージェントのようだ。museコマンドを一行インストーラでセットアップすると、対話モード(ターミナルUI)とヘッドレスモード(muse exec "<prompt>"、CI・スクリプト向け)の両方が使えるようになる。

公式ドキュメントによれば、承認制御とOSレベルのサンドボックス(Linuxではbubblewrap、macOSではSeatbelt)がデフォルトで有効になっており、明示的に許可しない限り任意のファイル書き換え・シェル実行はできない設計になっているという(ドキュメント記載の仕様であり、全バージョン・全起動モードで自分たちが個別に動作確認したわけではない)。サブエージェント・スキル・フック・MCPサーバー連携といった拡張の仕組みも用意されているようだ。

課金は、従量課金(APIキー経由)か、月額固定のサブスクリプション(公式ドキュメント記載: Everyday/High/Powerの3段階、Everydayは月額¥799〜、5時間あたり10〜50リクエストという上限つき、2026-08-30確認)の2択になっているようだ。

自分たちの環境でも、実際にMuse Codeをインストールし、複数のAIモデルが持ち回りでレビュー・アイデア出しを行う社内の会議システムに、もう1つの参加者として組み込んでみた。目的は、いきなり実装作業そのものを任せることではなく、まずは既存の監査役(複数のAIエージェント)と一緒にレビューに加わってもらい、判断の質を実際に確かめてから、より踏み込んだ用途への採用を検討することだった。実際にこの記事の下書き自体をMuse Codeに監査させてみたところ、章ごとの断定の強さが不統一である点や、実機検証の裏付けが本文に不足している点など、具体的で的を射た指摘が返ってきて、素朴に「使えそうだ」という手応えを持てたように思う。ただし、実装作業そのものを任せる判断はまだ先の話で、今回はあくまで監査役としての評価にとどめておきたい。

Muse Glimmer: 自前でホストするオープンウェイトモデル

Muse Glimmerは、Muse Sparkから蒸留された30Bパラメータのモデルで、重みがApache 2.0ライセンスで公開されている。学習コードやデータセットまで公開されているわけではないため、正確には「オープンソース」というより「オープンウェイト」と呼ぶ方が適切だろう。API経由ではなく、自分のマシン上でvLLM・SGLang・llama.cpp・ExecuTorchといったランタイムを使ってホストする形で使う(いずれも公式ドキュメントに記載されたランタイムのようだ)。量子化済みのGGUF版も配布されており、公式ドキュメントによれば、量子化版の一構成(K-Quant 17GB相当)であれば、24GB級のGPU1枚に収まる計算になるらしい。

「APIとして呼ぶ(Model API)」「CLIエージェントとして使う(Muse Code)」「自前でホストする(Muse Glimmer)」という3通りの使い方が用意されている、という整理は、それなりにしっくりくるとも言える。

6. まとめ: 「未確認」と書いたら、いつか確認しに行く

前回の記事の結論そのものは、変わっていないのだろう。「機能の有無を、モデルやベンダーの一枚看板のラベルで判断してはいけない。エンドポイント・モデルの版・ペイロードの組み合わせごとに確かめ、確認した日付とともに記録しておくべきだ」という主張は、今回の一連の確認作業によって、むしろ裏付けられたようだ。

前回の記事は、教訓を破っていたわけではなく、教訓通りに「未確認」と書いて宿題を残していた。今回はその宿題を、実際に手を動かして片付けに行った、というだけの話だったのかもしれない。地味な話だが、「未確認と書いたことを、後日ちゃんと確認しに行く」というのも、案外そのままでは実践されないものなのかもしれない。

AIの進化が速い分野では、公式ドキュメントも、検証結果も、あっという間に古くなってしまうものなのだろう。大切なのは「一度検証したから正しい」で止まらず、自分が過去に「未確認」と書いた箇所を思い出し、機会があれば実際に確かめ直しに行く、という地道な姿勢なのかもしれない。

次に自分が「今回試した範囲では失敗」と書いたとき、その"宿題"を、あなたなら後日ちゃんと片付けに行くだろうか。