9月25日、Pete（@heypeterjames）が「Is Meta's Muse secretly running an OpenAI model?」と題した記事を公開した。MetaのAIコーディングエージェント「Muse」のセッションログを解析した結果、OpenAIのモデルがAzure経由でバックエンドに使われている可能性が浮上したというものだ。

Metaが「自社モデルを活用した」製品として訴求するMuseの内部で、競合他社のモデルが動いているかもしれない。この発見は、AIエージェントの透明性という業界全体の問いを改めて浮き彫りにしている。

きっかけは1件の異常なセッションログ

Museは2026年にMetaが公開したAIコーディングエージェントで、自然言語の指示からWebサイトやUIを生成する機能を持つ。GitHub CopilotやCursorと同様、複数のサブエージェントが自律的にタスクを処理する設計だ。MetaのLlama戦略（オープンソースモデルの公開・普及）との関係もあり、Meta製モデルが中核を担うと広く認識されてきた。

PeteはMuseのファイルシステム内部を調査した前回記事をHacker Newsのフロントページに掲載した実績を持つ。今回はその続編として、自身のVM上に残るセッションログをほぼ全件確認した。

MuseはWebサイト構築時、各エージェントセッションが使用したモデルを記録している。大半のセッションはMetaの内部モデル「Avocado」（Metaが自社開発・ホストする推論モデル）にルーティングされていた。しかし1件だけ、9月21日付のサブエージェントセッションで azure/muse-special というモデル名が使われていた。

この名前を手がかりにリポジトリを検索すると、次の記述が見つかった：

"GPT Responses model client via MAGI native Azure OpenAI lane."

「MAGI」はMuseのエージェントインフラを指す内部コードネームとみられる。モデルカタログには azure/muse-special の隣に azure/gpt-5.6-sol というエントリも並んでいた。

OpenAI製モデルを示す2つの痕跡

セッションのトランスクリプトを掘り下げると、決定的な手がかりが2つ見つかった。

1. シグネチャが gpt_responses_v1 でタグ付けされており、gAAAAA で始まる暗号化ペイロードを含む（OpenAIのResponses APIが使用する形式）
2. ツールコールIDが call_ + 24文字の英数字混在という形式

Avocadoセッションのツールコールは call_ + 32文字の16進数という形式であり、明確に異なる。これらの特徴は muse-special がOpenAIのResponses APIを経由するモデルであることを強く示唆している。ただし具体的にどのGPTモデルなのか、なぜそのサブエージェントが選択されたのかは、ログからは判明しなかった。

モデルカタログの全貌

Museのエージェントデーモン（hatch daemon）に同梱されているモデルカタログには、Avocadoの約15バージョンに加えて、以下が含まれていた：

• Claude Opus 4.6 / 4.7 / 4.8、Sonnet 4.6、Haiku 4.5（Anthropic製）
• GPT-5.5、GPT-5.6系（OpenAI直接、Azure、Codex経由）
• Kimi K3（中国のMoonshot AIが開発するモデル。Fireworks経由およびMeta自社ホストの両方で登録）

Kimi K3がMetaのカタログに並んでいる点は特異だ。コスト・性能・特定言語での優位性など、外部モデルをルーティング先に加える動機は複数考えられる。ただし「カタログに載っている＝実際に使われた」ではなく、ランタイムがアドレス可能な状態にあることを意味するに過ぎない。MetaがAnthropicやOpenAIとの間でどのような契約・連携を結んでいるかは、現時点では公表されていない。

Anthropicとの接続基盤も実装済み

Claude対応はモデルIDの登録にとどまらず、以下のソースコードが実装されている：

• anthropic/request_flow.rs
• anthropic/convert_prompt.rs
• anthropic/parse_sse_stream.rs

AnthropicおよびOpenAIのAPIキーファイルも存在しており、アクセスは推論プロキシサービスに限定されている。環境変数 JARVIS_ANTHROPIC_BASE_URL_REVPROXY_OVERRIDE=0 には「ライブのキルスイッチ」というコメントが付されており、設定の残骸ではなく現役の制御機構と判断できる。

MetaはOpenAIから「蒸留」しているのか

Peteは2つの仮説を挙げている。

1. 特定タスクに対して外部モデルが優れているため、選択的にルーティングしている
2. A/Bテストや蒸留・強化学習（RL）のためにデータを収集している

蒸留（distillation）とは、大規模モデルの出力を教師データとして小規模モデルを訓練する手法で、競合モデルの出力を無断使用することへの倫理的・法的懸念が業界で議論されている。

この点についてPeteの結論は「No」だ。muse-special モデルでは生の推論過程（chain of thought）が暗号化されており、Metaが参照できるのは最終的な返答・ツールコール・短い推論サマリーのみ。バイナリ内には「暗号化された推論はRLの完了サーバーのオーバーライドに使えない」と明示されており、OpenAI/Anthropicの重みをコピーしている形跡はないとPeteは述べている。

一方、Avocadoモデルでは思考テキストがトランスクリプトに直接書き込まれ、RL（強化学習）用途に利用可能な状態になっている。Metaのプライバシーポリシーおよびリポジトリによれば、オプトアウトしない限りAvocadoとの会話はMetaのAI開発に使用される可能性がある。

「どのモデルが動いているか」をユーザーは知れない

MuseのランタイムはAnthropic・OpenAI・Fireworks等、複数プロバイダーのクライアントを持ち、ユーザーに断らずバックエンドのルーティングを変更できる構造になっている。Peteのケースで外部モデルへのルーティングは1セッションのみだったが、インフラ的には随時切り替え可能だ。

「どのモデルが自分のコードを処理しているか」をユーザーが把握できない設計は、AIエージェントの透明性という観点で今後議論を呼ぶ可能性がある。MuseはMetaのAIコーディング戦略の中核製品であり、この構造の詳細についてMetaからの公式コメントは今のところ出ていない。

詳細はIs Meta's Muse secretly running an OpenAI model?を参照していただきたい。