Personal Agent Bench

ほかの言語English简体中文한국어

Meta Museはオープンソースなのか?公開されているもの、いないもの

このページは 2026-10-13 時点の英語版を機械翻訳し、数値を原文と照合したものです。内容が食い違う場合は英語版が優先されます。

Meta Museはオープンソースなのか。答えは「いいえ」です。Museのエージェント、アクセスに使うアプリ、Metaのクラウド上で動くLinuxマシンはいずれも非公開です。MetaがMuse用として名前を挙げた2つのモデルも、重みは公開されていません。提供開始時に採用されたMuse Sparkと、10月12日に発表され、近くMuseのより多くの機能を支えるとMetaが説明するMuse Wonderです。ただし、「Meta Muse オープンソース」という検索が空振りというわけでもありません。MetaはMuseの名を冠する2つのものを公開しています。2026年10月2日に公開した、Museと通信する小型デバイスを作るためのキットと、8月に重みを公開した300億パラメータのモデル、Muse Glimmerです。どちらを使っても、Museそのものを自分で動かせるわけではありません。このページでは各層を順に確認し、判断の根拠を示したうえで、Museではできないことを実現するために作られた2つのオープンソースプロジェクトを紹介します。

  • Museのエージェント、アプリ、ユーザーごとのクラウドVMは非公開です。Metaは設計を公に説明しており、当サイトの解析でも外部から調べましたが、コードは公開されていません。
  • Museが提供開始時に採用したモデル、Muse SparkはAPI経由で提供されています。2026年10月12日時点で、Hugging Face上にSparkの重みは見つかりませんでした。
  • 10月12日に発表され、Museのより多くの機能に採用される予定のMuse Wonderも、API経由のみの提供です。Metaのモデルカードには、重みの公開について記載がありません。
  • Muse Glimmer 30Bは、Apache 2.0のもとで重みが公開されています。Muse Sparkから蒸留され、手元のハードウェアで動かすために作られたモデルです。MetaがMuseを動かしていると説明するモデルとは別物です。
  • Muse GadgetsはApache 2.0のオープンソースですが、どのガジェットもペアリングにMetaのトークンが必要です。つまり、Museを置き換えるものではなく、拡張するものです。

Meta Museはオープンソースなのか?層ごとに確認

Museという名前は複数の層を指しており、公開状況もそれぞれ異なります。

  • アプリ。 iOS、Android、Web、WhatsAppに加え、9月17日からはMacアプリもあります。非公開です。
  • エージェントと、それが動くマシン。 各ユーザーにはMetaのクラウド上のLinux仮想マシンが割り当てられ、そこでエージェント、ツール、そしてMetaがSentinelと呼ぶ監視役が動きます。非公開です。Metaは設計の詳細な説明を公開していますが、コードは公開していません。
  • モデル。 Metaの提供開始時の投稿は、Museが「Muse Sparkを搭載」すると説明し、セキュリティ解説ではMuse Spark 1.3を挙げています。10月12日には、契約者を皮切りに、Muse Wonderを近くMuseのより多くの機能に採用すると発表しました。どちらも重みは公開されていません。
  • Muse Code。 Metaが別途提供するターミナル用コーディングエージェントで、dev.meta.aiからインストールします。Metaは2026年8月31日にベータ版の終了を発表しました。公開SDKはMITライセンスですが、このリポジトリはホスト側バイナリを明示的に対象外としています。これだけでは、エージェントの実行環境全体がオープンソースだとは確認できません。
  • 周辺デバイス。 Muse Gadgets SDKはApache 2.0のオープンソースです。

これらとは別に、同じファミリーには重みが公開されたMuse Glimmer 30Bがあります。手元のハードウェアで動きますが、Museという製品が採用モデルとして挙げているものではありません。

要するに、Museを動かすために必要な部分は非公開で、公開されているのはその周辺部分です。

Meta MuseのエージェントとVM:非公開だが、設計は公表

MuseをMuseたらしめているのはエージェントです。長く続く1つの会話、ファイルとして保存される記憶、呼び出せるツール、そしてマシンの外へ出るあらゆるものを確認するゲートがあります。そのすべてが、Metaがユーザーごとに用意する仮想マシン、Muse Secure VM上で動きます。この実行環境のソースコードは一切公開されていません。

一方、Metaが公開した説明は、異例といえるほど詳細です。セキュリティ解説によれば、コネクターの操作を承認したり、外部へのネットワーク通信を許可したりできるのは、第2のエージェントであるSentinelだけです。エージェントは仮の認証情報を使い、承認後にネットワーク境界で本物の認証情報に差し替えられます。また、承認依頼は会話を経由せず、アプリへ直接届きます。現時点では、スタッフによるユーザーデータへのアクセスはポリシーで制限されているのであって、不可能にされているわけではないこと、暗号化されたMuse Confidential VMを今後導入する計画があることも記されています。

設計を公開することと、オープンソースにすることは別です。その設計を実際に担保するコードを読んだり、自分で動かしたり、利用中のビルドが説明どおりかを確かめたりすることはできません。当サイトのMuse解析では、リクエストの構造と246のメソッドを含む権限一覧まで確認できました。同時に、実行環境からモデルへ実際に送られた個々のリクエストをはじめ、確認できなかったものも列挙しています。

Muse Spark:Meta Museが提供開始時に採用したモデルは、なぜオープンソースではないのか

Muse Sparkは、Metaが提供開始時の投稿で「これまでで最も高性能なモデル」と呼んだモデルです。Museの提供開始時の投稿とセキュリティ解説の両方で、採用モデルとして名前が挙がっています。SparkのモデルはAPI経由で呼び出せます。OpenRouterのMetaページには、2026年10月12日時点でMuse Spark 1.2と1.3が掲載されており、ほかのホスト型モデルと同様にトークン単位で料金が設定されていました。

できないのは、Sparkのダウンロードです。10月12日にHugging Faceを検索したところ、Metaが公開したMuse Sparkの重みは見つからず、同じ名前を使う無関係のプロジェクトがあるだけでした。「muse spark open source」という見出しを見かけたなら、ほぼ間違いなく、Spark自体ではなく、以下の2つの公開物のどちらかについての記事です。

これはMuseを再現したい人にとって重要な点です。エージェントの設計が詳しく説明されていても、推論を担うモデルには別のものを使うことになります。

Muse Wonder:新しいモデルも非公開

Metaは10月12日、Muse WonderとMuse Wonder Fullの2つのバージョンからなるMuse Wonderを発表し、これまでで最も高性能なモデルと位置づけました。Metaの研究ブログによると、Muse Wonderは発表時点でMeta Model API経由で呼び出せるほか、Muse Codeでも利用できます。Muse Wonder FullはMuse Code契約者のみが利用可能です。また、Wonderは「近くMuseの機能を支える」ようになり、契約者から先に提供されます。無料アカウントへの提供日は示されていません。

いずれも、重みの公開を伴うものではありません。モデルカードには、コンテキスト長が100万トークンで、入力はテキスト、画像、動画、音声、出力はテキストと記載されています。重みについて述べているのは、開発・展開時にMetaの重み保護プログラムで保護したという点だけです。発表にもモデルカードにも、重みの公開についての記載はありません。10月13日のOpenRouterでは、Muse Wonderは入力100万トークンあたり4ドル、出力100万トークンあたり20ドルのホスト型モデルとして掲載されていました。提供形態はSparkと同じで、料金はより高くなっています。

注意すべき点が1つあります。発表の数時間後、meta-01と名乗るHugging Faceアカウントがmuse-wonderというリポジトリを作成しました。10月13日時点でモデルファイルはなく、このアカウントは、meta-models名義で公開しているMeta Superintelligence Labsのものではありません。「Muse Wonder weights」のダウンロードリンクがあっても、Metaが何かを公開した証拠にはなりません。

Metaはまた、Museを使うすべての人に向けた特化型モデルを、Muse Wonderを使って構築すると説明しています。これは、すべてのMuseユーザーに同じ水準の能力を届けるという話であり、重みの公開を約束したものではありません。GlimmerはSparkから蒸留して作られましたが、Wonderから何か公開されるものが生まれるかどうかについて、Metaは何も述べていません。

Muse Glimmer:Meta Museファミリーで重みが公開されているモデル

ここで取り上げる、重みが公開されたモデルはMuse Glimmer 30Bです。Meta Superintelligence Labsが2026年8月9日にApache 2.0ライセンスでHugging Faceに公開しました。ダウンロードに申請や承認は必要ありません。

モデルカードによると、画像エンコーダーを内蔵した約296億パラメータの密なモデルで、Muse Sparkから蒸留され、「一般消費者向けハードウェア上で自律的なエージェントタスクを行うために専用設計」されています。約4ビットに量子化すると、言語モデルは20 GB未満に収まります。モデルカードが想定する構成のビデオメモリ容量は24 GBから64 GBです。学習の対象としてツール利用、失敗からの復旧、複数段階の計画を挙げ、OpenClawやHermes Agentなどのオープンなエージェントフレームワークで動作すると説明しています。

注意点は2つあります。まず、Glimmerは、MetaがMuseを動かしていると説明するモデルではありません。提供開始時の投稿とセキュリティ解説は、どちらもSparkを挙げています。自宅でGlimmerを動かせば、同じ研究組織が作った高性能な公開モデルを使えますが、Museを複製できるわけではありません。次に、「重みの公開」は学習過程の公開と同じではありません。モデルカードによると、学習データには一般公開データ、ライセンスを取得したデータ、Metaの製品やサービスから得られた情報が含まれますが、そのデータは一切公開されていません。

それでも、多くの人にとってGlimmerはこの問いへの最も役立つ答えです。自分で管理でき、エージェント用途に使えるMeta学習済みモデルが欲しいなら、これが該当します。当サイトの実行場所の比較ページでは、ホスト型エージェントと自分で動かすエージェントを並べています。このようなモデルが位置づけられるのは後者です。

Muse Gadgets:Meta Muse自体のオープンソース部分

「Meta Muse オープンソース」という見出しの大半のきっかけとなったのが、Muse Gadgetsです。2026年10月2日、GitHub上のMetaのfacebookincubator組織で公開されました。

デバイス用SDKが2つ含まれています。1つは市販のESP32ボード向けファームウェアです。画面、スピーカー、センサーなどを備えた小型ボードで、画像を表示したり、音声を再生したり、測定値をMuseに送ったりできます。もう1つはRaspberry Piや余っているLinuxマシン向けのサービスで、独自のコマンドを追加し、Museにそのマシン上の作業を任せられます。デバイス設定で開発者モードを有効にすると、ガジェットをiOSやAndroidのMuseアプリとペアリングできます。MetaのREADMEはリスクを軽い調子で説明しており、副作用としてボードが起動不能になることや、保証が無効になることなどを挙げています。

セットアップは、公式のESP32クイックスタートまたはLinux向け手順に従ってください。ペアリングの前にSDKトークンを取得し、利用規約を確認します。

コードはApache 2.0で公開されています。ただし、一部のサードパーティー製ファイルにはそれぞれのライセンスが適用され、例外としてアニメーション付きアバターは対象外です。より大きな制約は、ペアリングの段階にあります。どのガジェットにもMetaのSDKトークンが必要で、Metaが別途定めるGadget SDKの規約が適用されます。つまり、Muse Gadgetsがオープンソースなのは、デバイス側のコードを読んで変更できるという意味です。Museを別の環境へ持ち出せるようにはなりません。接続先のMuseアカウントがなければ、ガジェットには通信する相手がいないのです。

Meta Museの代わりになるオープンソースプロジェクト

検索の背景にある疑問が「Museのようなものを自分で動かせるか」であれば、その答えとなることを明確に目指したプロジェクトが2つあります。両者が選んだ方針は正反対です。

CopilotKitのOpenMuseは、9月15日にMITライセンスで公開されました。自分で管理するサーバー上で動き、状態を保持するブラウザーと、任意で使えるLinuxワークスペースを備えています。アプリは、そのサーバーにアクセスする窓口です。当サイトでは、外部から挙動を調べるのではなく、ソースコードを読みました。そこで見つかった留意点は、会話の永続保存が、MITライセンスの対象外であるCopilotKitのホスト型サービスに依存していることです。

Zhejiang Universityの小規模チームによるnanoMuseは、9月下旬にGPL-3.0-or-laterでGitHubに公開されました。サーバー上に1つのエージェントを置くのではなく、各デバイスにエージェントを丸ごと配置します。Androidとコンピューターでは、画面を通じてほかのアプリを操作できます。Meta Museにも、一部のMacアプリを操作するMacアプリがあります。nanoMuseの論文は、MuseのようなユーザーごとのVMと、それに伴う強固なセキュリティ境界を備えていないことを率直に認めています。

どちらもMetaとは関係がなく、当サイトの試験は受けておらず、まだ新しいプロジェクトです。当サイトではそれぞれのページで、公開情報と未解明の点を整理しています。

Meta Museが公開されれば、何が変わるのか

ここで公開を求める理由は、抽象的なものではありません。パーソナルエージェントは、受信トレイ、カレンダー、文章化されたユーザープロフィールを保持し、ユーザーが離れている間もそれらを使って行動します。具体的に何を送信し、何を保存し、支払いの手前にあるゲートが本当に機能するのか。こうした仕組みについて人々が最も知りたい点ほど、外部から確かめるのは難しいのです。

当サイトの調査にも、その隔たりが表れています。Museではリクエストの形式と権限一覧を説明できましたが、リクエストがマシンの外へ出るところは一度も確認できませんでした。OpenMuseの公開リポジトリは調べられます。ただし、当サイトはホスト側の永続保存処理の内部までは調査しておらず、データの送信先をすべて特定できたわけでもありません。これらはどちらが安全かを判定するものではありませんが、調べようと思った人が誰でも検証できるのは片方だけです。

当サイトのMuse解析では、モデルへのリクエストが組み立てられる、ユーザーごとのLinux VMについて説明しています。また、Metaのセキュリティ解説は、大半のベンダーが公開するものより詳細です。デバイス用キットと小型モデルの公開は、確かな前進です。それでも、実際に会話するエージェントと、それを動かすマシンは、引き続きMetaの管理下にあります。

FAQ

Meta Museはオープンソースですか? いいえ。Museのエージェント、アプリ、それが動くクラウドVMは非公開で、Muse SparkもMuse Wonderも重みを公開していません。MetaはMuse Gadgets SDKをオープンソース化し、Muse Glimmer 30Bモデルの重みを公開しています。

Muse Sparkはオープンソースですか? いいえ。Muse Sparkはホスト型API経由で利用できますが、2026年10月12日時点で、Metaは重みを公開していませんでした。重みが公開されているのは、Sparkから蒸留されたMuse Glimmer 30Bです。

Muse Wonderはオープンソースですか? いいえ。Metaは2026年10月12日、Muse WonderとMuse Wonder Fullを、Meta Model APIやMuse Codeから利用するホスト型モデルとして発表しました。モデルカードには重みの公開について記載がなく、10月13日時点でHugging Faceにあるmuse-wonderリポジトリは、Metaではないアカウントが作った空のリポジトリです。

Muse Glimmerとは何ですか? Meta Superintelligence Labsが2026年8月にApache 2.0で重みを公開した、約300億パラメータのモデルです。エージェントタスク向けに作られ、一般消費者向けハードウェアで動くよう設計されています。MetaがMuseアプリを動かしていると説明するモデルではありません。

Muse Gadgetsとは何ですか? ESP32ボードやLinuxコンピューターを使い、自分のMuseとペアリングする小型デバイスを作るためのオープンソースSDKです。2026年10月2日に公開されました。どのガジェットも、ペアリングにはMetaのトークンが必要です。

Meta Museをセルフホストできますか? いいえ。エージェントはMetaのインフラ上でしか動きません。同じような仕組みを自分で動かしたいなら、OpenMuseとnanoMuseという、独立した2つのオープンソースプロジェクトがあります。ソースコードの比較ページでは、ほかの選択肢とともに、両者の実装上の制約を取り上げています。

OpenMuseはMetaが作ったものですか? いいえ。OpenMuseはCopilotKit、nanoMuseは独立した大学のチームによるものです。名前だけでは、Metaとの関係や、開発者がその名前を選んだ理由は判断できません。