
2026/09/26 3:18
Meta の Muse は OpenAI モデルの muse-special とラベル付けされたものを使用しているようです。
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
9月21日の分析により、個人用の Muse VM のログから、セッションのほとんどは Meta 内の「Avocado」モデルを使用していた一方、1 つのセッション(
azure/muse-special)は MAGI を介して OpenAI Azure チェーンを迂回し GPT 応答を処理していたことが判明しました。トランスクリプト分析の結果、このセッションは OpenAI 風の署名(gpt_responses_v1)を使用しており、「gAAAAA」で始まる暗号化ペイロードおよび 24 文字のツールコール ID を持ち、Avocado の 32 文字のヘキサン形式とは異なっていました。これは OpenAI の Responses API を呼び出しているか、Azure ホスト上の OpenAI モデルを実行していることを示唆しています。Meta の Muse デモンは、約 15 の Avocado バージョンに加え、Anthropic モデル(Claude Opus 4.6–4.8、Sonnet 4.6、Haiku 4.5)および GPT バリアント(5.5/5.6)のより広範なカタログを維持しており、Anthropic サポートのために明示的な配管ファイルが用意されています。実行環境変数には外部プロバイダへのアクセスを無効化できるプロキシのキルスイッチが含まれています。重要なのは、ルーティングロジックにより Meta がサーバー側でモデルを切り替えたり、蒸留および強化学習のための A/B テスト応答を行ったりすることをユーザーの要求なしに行える点です。OpenAI と Anthropic の生の推論連鎖は暗号化され、Meta の RL 完了サーバーによって明示的に拒絶されており、そのため Meta は最終的な返信、ツールコール、サマリーのみを認識します。対照的に、Avocado の思考テキストはプライバシー設定でユーザーが除外しない限り、トレーニングのために署名なしで直接トランスクリプトに書き込まれます。Meta は調査を承認し、研究者が数百万人以上のユーザーにサービスを提供する実行セルを検査するアクセス権を与えた一方で、独立して応答の A/B テストおよび蒸留を行う能力を保持しています。これは「ユーザーの期待(データが選択されたモデルのみへ流れ続けること)」と「現実(サーバー側で複数のモデルを用いてデータが処理されること)」の乖離を浮き彫りにし、プライバシー上の懸念を生み出し、AI エコシステムに対する信頼に影響を与えています。本文
Muse の裏側を探る:「muse-special」モデルと Azure OpenAI への接続
今回の投稿では、Muse のファイルシステムを調査する第 2 部として、「奇妙なセッション」「モデル名の追跡」「Muse のモデルカタログ」「Anthropic に関するインフラ(Plumbing)」「実装理由」「蒸留の真偽」といったテーマに迫ります。
Muse がウェブサイトを構築する最中に発見された
azure/muse-special というラベル付きモデルについて深く掘り下げ、**「Muse は裏側で実際には OpenAI や Claude のモデルを利用しているのか?」**という問いに正面から答えていきます。
1. 奇妙なセッション
Muse は、各エージェントセッションで使用されたモデルを記録しています。私の仮想マシン(VM)内のほぼすべてのセッションログでは、Meta の内部モデルである**「Avocado」**宛てにルーティングされていました。しかし、例外が 1 つ存在します。
- 9 月 21 日の特定セッションのみ:
というモデル名が使用されていました。azure/muse-special - 他の全セッション:Meta 内部モデル「Avocado」のみで使用されました。
この不一致は非常に興味深く、Muse が単一プロバイダーに固執していない可能性を示唆しています。
[図 1]:私の VM 内のセッションをモデル別にまとめたもの。すべてが Avocado であったのは例外なく、9 月 21 日の 1 つのセッションだけが
でした。azure/muse-special
2. モデル名への追跡
この現象は好奇心をそそり、Cursor のリポジトリ全体を検索したところ、**「MAGI ネイティブの Azure OpenAI ルートを介した GPT レスポンズモデルクライアント」**という記述が見つかりました。
カタログ内のモデル一覧
Muse のエージェントデモン(daemon)に含まれるモデルカタログには、以下のものが列挙されています:
- Meta 系: 「Avocado」のバージョン約 15 バージョン
- Anthropic 系:
- Claude Opus 4.6 / 4.7 / 4.8
- Sonnet 4.6 と Haiku 4.5
- OpenAI・Azure 系: GPT-5.5 と GPT-5.6 のバリエーション
- 他社系: Fireworks、Meta 自ホスト経由の Kimi K3 など
トランスクリプトの詳細な分析
azure/muse-special に関連するセッショントランスクリプトを検索したところ、OpenAI 由来であるという 2 つの決定的な証拠が見つかりました:
- シグネチャの不一致
- シグネチャは
というタグが付けられています。gpt_responses_v1 - ペイロードは
で始まるOpenAI が使用する暗号化形式です。gAAAAA
- シグネチャは
- ツール呼び出し ID の形式
- ID は
に続いて大文字小文字を混ぜた 24 文字で構成されています。call_ - 対照的に、Avocado セッションは
に続けて16 進数の 32 文字を使用しています。call_
- ID は
これらの違いは、
muse-special が OpenAI のモデル(またはその Responses API)を直接使用している可能性を強く示唆しています。具体的には、Azure 経由で提供される GPT モデルへの**エイリアス(別名)**であると考えられます。
[図 2]:
トランスクリプトからの行例:OpenAI スタイルのmuse-specialID と、暗号化されたcall_ペイロードを含むgAAAAAシグネチャ。gpt_responses_v1
3. Muse のモデルカタログ
Muse の runtime が参照可能な全モデルファミリーは以下のように整理できます(注:同梱されているからといって実際に使用されるとは限りません)。
- Meta (Avocado): v15 など、約 15 バージョン存在
- Anthropic:
- Claude Opus (4.6, 4.7, 4.8)
- Sonnet 4.6 / Haiku 4.5
- OpenAI / Azure:
- GPT-5.5 / GPT-5.6
- その他:
- Fireworks
- Kimi K3 (Meta 自ホスト)
[図 3]:ハッチ(hatch)デモンに同梱されたモデル ID をファミリーごとにまとめたサマリー。
4. Anthropic に関するインフラ(Plumbing)
Anthropic モデルの利用には、単なる API キー以上の高度な処理パイプラインが組み込まれています。具体的には以下のコンポーネントが含まれます:
anthropic/request_flow.rs
(プロンプト変換用)anthropic/convert_prompt.rs
(ストリーミングパーサー用)anthropic/parse_sse_stream.rs
疑問点と実装構造
環境変数に Anthropic または OpenAI の API キーファイルが存在し、かつ推論プロキシへのアクセス権限が制限されています。一方で、環境変数には**「殺しスイッチ」**も設定されています:
JARVIS_ANTHROPIC_BASE_URL_REVPROXY_OVERRIDE=0
この設定(コメントによると古くない構成)は、リアルタイムで外部接続を遮断できる機能として実装されています。
[図 4]:runtime の環境変数にある
。「リアルタイムの殺しスイッチ」です。JARVIS_ANTHROPIC_BASE_URL_REVPROXY_OVERRIDE=0
5. これらを実装する理由
なぜ複数のプロバイダーと複雑なインフラが必要なのか。主な理由は以下の 2 つに集約されます:
- パフォーマンスの最適化
- OpenAI または Anthropic のモデルの方が、特定のタスクにおいて Muse 単体では満たせない優れたパフォーマンスを発揮するため。
- 必要な場合にのみ外部モデルへルーティングする設計です。
- A/B テストと学習機能の準備
- すべての VM に、蒸留(Distillation)や強化学習(RL)用のモデル回答・ツール呼び出しを収集する機能が備わっています。
真実:サーバーサイドの選択
Muse 背後のモデル選定は、ユーザーが設定するのではなく、サーバーサイドで動的に決定されています。Runtime は複数のプロバイダークライアントを持っており、Meta に相談することなくルーティングを変更できる能力を与えられています。
私のケースでは Avocado(Meta)を使用しなかったのは単一セッションのみでしたが、それ以外のモデルを利用するためのインフラは既に存在していました。
6. Meta は蒸留をしているのか?
ここで重要なのは、Meta が他の社(OpenAI/Anthropic)のモデルをそのまま「蒸留(Distillation)」して重み(weights)をコピーしているかどうかです。
「muse-special」の挙動(非蒸留)
- 思考プロセスの暗号化: 生思考は暗号化され、RL コンプレーションサーバーからは拒否されています。
- 返却されるデータのみ: Meta が得られるのは、OpenAI/Anthropic から返却された回答、ツール呼び出し、そして簡潔な思考サマリー(場合により)のみです。
- 結論: Meta が他の社の重みをコピーしているという明確な示唆はありません。
「Avocado」の挙動(蒸留・学習可能)
対照的に、内部モデルである Avocado の場合は異なります。
- 思考テキスト: 直接トランスクリプトに書き込まれ、シグネチャなしで利用可能です。
- データ利用: リポジトリとプライバシー声明によると、会話データは Meta の AI 開発(蒸留や RL)に使用される可能性があります(オプトアウトは可能)。
7. 結びの言葉
今回の調査を通じて得られた結論は以下の通りです:
- 推測:
は、Azure を介して提供されるOpenAI モデルである可能性が最も高い。muse-special - 評価: Meta がリリースした魅力的なプロジェクトであり、多様なアプローチを取りたてることが称賛に値する。
- 未来: 数億人規模の利用が期待される製品の内部構造を解明できたことは、この「パーソナルエージェント」の今後への早期洞察を得られた点で価値がある。
状況は急速に変化していますが、現時点ではシステムは破綻しておらず、正常に機能しています。
Muse に携わりたい、さらに学びたいという方はご連絡ください。貢献する機会があればと思います。
pete at mouse dot dev -Pete (@heypeterjames)