Meta の Muse は、本当にVM に常駐するエージェントだった。頼んだらブロック崩しのゲームをちゃんと作ってきた！6 日間の記録

本記事は Claude Code と一緒に調べ、書きました。Claude Code には、Muse に頼んで作らせた作業のまとめの読み込み、画像の検査、コードの再実行、既存の資料との突き合わせ、図の作成、文章の校正を任せました。何を試すか、結論の判断、修正の指示は筆者です。

Meta の個人向け AI エージェント Muse は、2026-10-23 に日本で提供が始まりました。筆者は、その日から 6 日間、メール、カレンダー、買い物、調べもの、画像の生成などに使いました。この記事は、その 6 日間にやったことを Muse 自身にまとめさせた文書をもとに、Muse が VM の上で何をしているかを確かめ、できたこと、人が仕上げたこと、できなかったことを一覧にして、気づいた点を述べるものです。

Muse の内部の作りは、別の記事にまとめました。Meta の Muse のリバースエンジニアリング情報まとめと、日本で始まった Meta の Muse を早速試した！です。この記事は、その続きとして、利用者の側から見た実際の動きを扱います。

Muse の実体は、仮想マシンに常駐するエージェント

Muse は、Meta が利用者ごとに用意する仮想マシン(VM)に常駐して動くエージェントです。普通の仮想マシンに Codex や Claude Code のようなコーディングのエージェントを載せたときと同じで、Muse は、仮想マシンを自分で操作します。できたことの多くは、その仮想マシンの中の作業(ブラウザの操作、ファイルの保管、コードの実行、定期的な起動)でした。止まった箇所の多くは、仮想マシンの外にあるもの(通販サイトの受け付け、決済の仕組み、生成のサーバー)でした。

Muse に作らせた報告は、Muse の自己申告です。そこで、成果物が手元に残る部分(画像 10 点、動画、コードの実行)は筆者が確かめ、それ以外は申告のままと書き分けました。個人の予定や取引先、保有する資産などの私的な情報は載せず、やったことを、作業の種類の水準で書いています。

用語	意味
筆者	この記事の書き手で、Muse の利用者
Muse の報告	筆者の求めで、Muse が 6 日間にやったことをまとめた文書。画像 10 点とコード、結果の図 2 点が付いた
定期タスク	利用者が指定した確認(たとえば、特定のメールのチェック)を、決めた時刻や間隔で Muse が起動して行い、結果を知らせる設定
本人が実施	Muse が手順の案内や下調べまでを行い、購入、申込、解約の最後の操作を筆者がスマホで行ったこと

要旨

Muse は、Meta の仮想マシンの上のエージェントとして、メールやカレンダーを読んで予定を登録する、調べものをまとめる、定期的に見張って知らせる、画像を作る、コードを動かす、といった作業を、6 日間で滞りなく進めました。一方、購入、決済、解約、申込のような最後の操作は、筆者が自分で行いました。理由は 3 つに分かれ、サイト側が受け付けなかったもの、決済の仕組みが動かなかったもの、Muse が案内にとどめたものがあります。動画の生成は、はじめの 2 回は失敗しましたが、機能が回復した後に改めて頼むと生成できました。

画像、動画、コードで確かめた範囲では、Muse の報告の中身と一致していました。定期タスクは、設定したとおりに動作しました。

全体像を図 1 に示します。

図 1: Muse の構成の全体像(橙は Muse、緑は Meta の仕組み、灰は利用者。破線は想定または推定)

Muse が 6 日間でできたこと

Muse の報告の項目を、1 項目ずつ並べ、結果を 3 つに分けました。分け方は報告の記述に従い、項目の区切りは筆者によります。34 項目のうち、Muse が最後まで行ったものが 27 項目、途中まで進めて最後の操作を人が行ったものが 4 項目、できなかったものが 3 項目でした。作業の分かれ方を図 2 に示します。

図 2: 作業の分担(橙は Muse、黄のひし形は判定、赤は止まった箇所、灰は人。破線は理由が分からないもの、または該当なし)

最後まで行ったこと(27 項目)

• 設定と記憶
  • アシスタント名の決定
  • Gmail、Google カレンダーの連携
  • SNS の連携
  • 好みの記憶
• メールとカレンダー
  • 購入済みチケットのメールの点検
  • カレンダーへのイベントの登録
  • 掲示の写真の読み取り(OCR。画像から文字を読み取る処理)と、読み取った文字の内容のカレンダーへの登録(チャットに添付した写真)
• イベント
  • イベントの検出
  • イベントの推薦
  • イベントの締切の事前の知らせ
  • 予定が重なっているときの問い合わせ
• 調べもの
  • 新製品の仕様
  • 人物や作品に関する経緯
  • ニュース
  • 記事の題材の提案
• 見張る、知らせる
  • 定期タスク 6 件の設定と動作
  • メルカリ、ヤフオクなどの商品検索
  • 商品の定期チェックの登録
• 作る、動かす
  • 画像の生成(10 点)
  • PyTorch の導入(仮想マシンの中)
  • MNIST の学習
  • ブロック崩しのゲームの作成(後の節)
  • データの整形
  • アバターの衣装の変更
• SNS
  • アカウントの確認
  • 自分の Facebook への投稿
  • Instagram で、自分がフォローしているユーザーの記載内容のチェック

途中まで進め、最後を人が行ったこと(4 項目)

• 座席指定のチケットの購入(座席指定まで進めたが、決済の仕組みの不具合で終わらず、本人がスマホで購入)
• 出品サイトでの購入(検索と確認まで。購入は本人)
• イベントの申込(料金と締切の案内まで。申込は本人)
• サブスクリプションの解約(手順の案内と、確認メールの見張りまで。解約は本人)

できなかったこと(3 項目)

• 動画の生成(ダンス動画を 2 回試し、生成するサーバーの過負荷で、どちらも生成されなかった。機能の回復後に改めて頼み、生成できた)
• 通販サイトの注文履歴と配送の確認(サイト側のエラー表示で、ブラウザ経由では見られなかった)
• 日本のパートナー連携(メルカリ、マネーフォワード ME、チケットぴあとの連携は、10 月 28 日の時点で未開始と Muse が確認)

イベント、写真、定期タスクの流れ

イベント、写真、定期タスクの流れを図 3 に示します。

図 3: イベント、写真、定期タスクの流れ(橙は Muse、青は利用者への知らせ、灰は利用者)

定期タスク

定期タスクは、利用者が指定した確認を、決めた時刻や間隔で Muse が実行する機能です。たとえば、特定のメールが届いたかのチェックがあります。筆者が設定したのは 6 件で、間隔は 15 分から 1 回限りまであります。

生成した画像と動画

画像 10 点

Muse の報告には、画像 10 点が付いていました(図 4 には 4 点を載せます)。内訳は、イラスト風 6 点(同じ人物の連作 3 点を含む)、実写風 2 点、コンセプトアート風 1 点、ポスター 1 点です。

図 4: Muse が生成した画像(報告に付いていた 10 点のうち 4 点)

確かめたことは次のとおりです。

• 大きさは縦長 2 点と横長 8 点(1,280×1,920 または 1,920×1,280、WebP)で、10 点とも、同じ 513 バイトの埋め込み情報を持っています。内容は、画像が学習済みの生成モデルによるもの(IPTC の trainedAlgorithmicMedia)であることと、発行者が Meta であることだけです。モデルの名前、依頼文、C2PA の署名は入っていません。したがって、画像から生成モデルを特定することはできません
• 日本語の文字は、ポスターの画像で、見出しも小さな注意書きも読めます。誤りは、営業時間の行に余分な閉じかぎ括弧が 1 つ入っていることだけでした(拡大して確認)
• 同じ人物の連作 3 点は、髪型、服、マフラー、街並みが保たれ、構図と姿勢だけが変わっています。同じ登場人物を保った連作が作れると読めます(縮小した一覧で見た範囲)

画像の品質は、数値で測ったものではなく筆者の印象ですが、いまの最先端のモデルが作る画像を見慣れている人にとっては、GPT Image 1 ぐらいの水準です。Muse 自身も、同じ趣旨のことを述べています。

画像の生成の消費量は分かりません。Muse の利用量は、週あたりのトークンで管理されています。通常の会話で消費するトークンと、画像の生成に必要なトークンは、別に数えられると筆者は想定しますが、Muse に尋ねたところ、Muse は分からないと答えました。画像 10 点の生成が、利用枠をどれだけ使ったかは、確かめていません。

動画 1 本

動画の生成をはじめに 2 回頼んだときは、生成するサーバーの過負荷でどちらも生成されませんでした(「できなかったこと」)。10 月 27 日には動画の生成機能が止まっていて、10 月 28 日に回復したので、筆者が改めて頼み、動画が 1 本できました。図 5 は、その動画から 5 コマを抜き出したものです。画像を押すと、YouTube の限定公開の動画(https://youtu.be/TMmKY8-MFbQ)が開きます。

図 5: Muse が生成した動画の 5 コマ(0、2、4、6、9 秒)

確かめたことは次のとおりです。

• 長さは 10.00 秒、画面は 832×1,040 の縦長、24 コマ毎秒で、約 2.8 MB の MP4 です(映像は H.264、音声は AAC の 24 kHz モノラル)
• 白い背景の前で、ふわふわの毛のキャラクターが、手を振る、片足を上げる、腰に手を当てる、といった踊りを続けます。顔つき、毛の色、体の形は 10 秒の間ずっと保たれていました(5 コマと、1 秒ごとの縮小した一覧で見た範囲)
• 音声が付いています。周波数を画像にして見ると、一定の間隔で打つ音が続く形で、話し声には見えません(聴いてはいません)
• 画像と同じ埋め込み情報(IPTC の trainedAlgorithmicMedia、発行者 Meta)が入っています。モデルの名前と依頼文は入っておらず、動画から生成モデルを特定することはできません
• 動画を ffmpeg 系の道具で書き出した記録(libx264、品質指定 18)が残っています。生成した映像を、生成するサーバーの側で MP4 に変換して返している、と読めますが、確認はしていません

動画の生成が、通常の会話や画像の生成と別に数えられるかも、利用枠をどれだけ使ったかも、確かめていません。

VM 上でのプログラムの実装と実行

筆者は、仮想マシンへ直接 SSH で入ることができません。Muse は、仮想マシンの上に Codex や Claude Code を載せたのと同じ形のエージェントで、筆者は会話を通じて、Muse が載っている仮想マシンを操作させることができます。仮想マシンのスペックは後の節に書きましたが、2 コア(AMD EPYC)、メモリ 8 GB、ディスク 100 GB です。このため、仮想マシンの上のほとんどの操作は、Muse との会話で頼めます。筆者の印象では、Muse に話をすると、仮想マシンの上でできることは、ほとんどやってくれそうな雰囲気でした。

MNIST の学習

今回は、仮想環境を作り、PyTorch の CPU 版を入れて MNIST のプログラムを動かし、結果を報告するよう頼みました。Muse の報告は、Muse が仮想マシンに PyTorch(CPU 版)を入れ、MNIST の学習を行い、テスト精度が 97.27% だったと述べます。コードと結果の図 2 点が付いています。

筆者は、コードを全文読み、同じコードを筆者の計算機で CPU 実行しました。

観点	Muse の報告	再実行(24 スレッド)	再実行(2 スレッド)
テスト精度	97.27%	97.26%(9,726 件)	97.32%(9,732 件)
学習のステップ数	図の横軸が約 188	コードから 94 ステップ × 2 エポック = 188	同左
所要時間	報告に無い	133 秒	10.7 秒

図 6: Muse の報告に付いていた学習の損失(左)と数字ごとの精度(右)

乱数の種は固定されていますが、精度は 97.26% から 97.32% まで、スレッド数によって 6 件の幅で動きました。Muse の報告の 97.27% は、この幅の中にあります。並列の計算で足し算の順序が変わることが原因と考えられますが、確かめてはいません。損失の経過(1 エポック目 0.4745)は、2 通りの再実行で一致しました。数値と図は、コードと整合しました。

Muse の報告に書かれていない条件が 1 つあります。コードは、学習に使うデータを、60,000 件のうちの先頭 12,000 件に絞り、2 エポックだけ回します。報告は「MNIST の学習デモを実行:テスト精度 97.27%」とだけ書くので、読んだ人は全データでの学習と受け取りかねません。

ブロック崩しのゲーム

筆者は Muse に、ブラウザで動くブロック崩しのゲームを作るよう頼みました。依頼した要件は次のとおりです。

• HTML、CSS、JavaScript を使い、外部のライブラリは使わない
• マウスまたはキーボードでパドルを操作する
• ボールが壁、パドル、ブロックに当たると反射する
• スコア、残機、ゲームオーバー、クリアの判定を実装する
• スタート、ポーズ、リスタートができる
• 見た目はモダンで、アニメーションが滑らかである
• バグがあれば自分で直し、生成物はダウンロードできるようにする

生成にかかった時間は、筆者の計測で 1〜2 分でした。Muse は、単一の HTML ファイルで、外部のライブラリもネット接続も要らず、JavaScript の構文チェックは済んでいる、と報告しました。実装した内容としては、次のように述べています。

• 操作は、マウス、矢印キーと A・D キー、タッチで、パドルに当たった位置によって跳ね返る角度が変わる
• 壁、パドル、ブロックのすべてで反射し、ブロックを壊すと破片が飛ぶ
• スコアは行ごとに点数が違い、ハイスコアを保存する。残機は 3 で、全 3 レベルをクリアするとゲームクリアで、残機のボーナスがつく
• レベルが上がると、ブロックの段とボールの速さが増え、2 レベル目からは最上段のブロックが 2 回当てないと壊れない
• 効果音は WebAudio で生成するので、外部のファイルは無い

図 7 に、生成されたゲームの画面を示します。

図 7: 生成されたゲームの画面(左は開始画面、右はプレイ中。筆者がブラウザで開いて撮影)

確かめたことは次のとおりです(画面を出さないブラウザを、自動で操作した範囲)。

• ファイルは 1 本で、470 行、約 18 KB です。コードを全文読んで、外部の読み込みが無いことを確認しました
• 開くと、ブロック 5 段 10 列と「スタート」の画面が出て、押すとゲームが始まります
• マウスの動きでパドルが動き、ボールが当たったブロックが消えました。スコアは 60 になり、ボールを落とすと残機が 3 から 2 に減って、ボールがパドルの上に戻りました(発射は Space かクリック)
• ポーズを押すと「PAUSED」の画面が出て、再開のボタンで戻れました
• 開いている間、コンソールにエラーは出ませんでした

筆者が実際にブラウザで遊んだところ、動作は軽快で、問題はなさそうでした。

気づいた点

人が最後を行う範囲と、その理由

読む、調べる、登録する、知らせるは進み、購入、決済、解約、申込は人が行いました。止まった理由は、Muse の報告から読む限り 3 つです。

• サイト側が受け付けない: 通販サイトでは、ブラウザ経由の閲覧が、サイト側のエラーで止まりました
• 決済の仕組みが動かない: 座席指定のチケットの購入は、決済の仕組みの不具合で終わりませんでした
• Muse が案内にとどめた: 解約と申込は、手順や情報の案内で終わっています。報告は、Muse が手を出せなかったのか、出さない設計なのかを書いていません

最初の 2 つは、日本での初日の試行(日本で始まった Meta の Muse を早速試した！)と同じ型です。

定期タスクの間隔

第三者の解析は、定期実行の定義が、実行の間隔を表す名前(daily、hourly、runonce)で保存される、と報告しています(内部構成の記事)。今回の場合、1 時間ごと、毎日、1 回限りは、この記述と合います。一方、15 分ごとの見張り、平日だけの実行、毎朝 8:15 のように分まで決めた時刻は、この記述にありません。15 分ごとの見張りが、どの仕組みで動くのかは、この記述からは分かりません。

筆者が Muse に定期タスクの置き場所を尋ねると、Muse は次のように答えました。

• この仮想マシンは、Linux 標準の crontab を使っていない。crontab のコマンド自体が入っておらず、/etc/crontab も空である
• 代わりに、Muse 側のスケジューラがジョブを管理している。定義は、~/workspace/cron.d/ と、各ゴールの crons/ フォルダに、Markdown で保存されている
• 筆者が頼んだ 6 件も、Muse の内部動作のためのシステム側のジョブも、このスケジューラで動いている。15 分ごとの見張りも同じである

これは Muse の回答で、筆者は仮想マシンの中でコマンドを打って確かめていません。第三者の解析が述べた定義の名前(daily、hourly、runonce)とは別に、間隔や時刻を直接指定するジョブがある、と読めます。

仮想マシンの中でできることと、外に頼むこと

Muse は、Meta の仮想マシンの上で動くエージェントです。今回の作業は、仮想マシンの中で完結するものと、外に頼むものに分かれました。

場所	今回の作業	結果
仮想マシンの中	Python のライブラリの導入、MNIST の学習、データの整形、定期的な起動、記憶の保管、作業用のブラウザの操作	動いた(コードの結果は上で確かめた)
仮想マシンの外(サイト)	通販サイトの閲覧、決済	止まった。サイト側の受け付けと決済の仕組みの問題
仮想マシンの外(生成)	画像の生成、動画の生成	画像は成功。動画は「生成サーバー」の過負荷で 2 回失敗し、回復後の依頼で成功

Muse は、Codex や Claude Code を普通の仮想マシンに載せたときと同じように、仮想マシンを自分で操作します。今回の MNIST では、Python の仮想環境を ~/workspace/pytorch-mnist-demo/ に作り、pip で PyTorch(CPU 版)を入れ、スクリプトを書いて実行し、図を保存しました。環境の構築から結果の保存までを、Muse が自分で行っています。必要なライブラリは自分で入れられるので、メールやカレンダーのような用意された連携の範囲を超えて、データの整形や在庫の確認のような作業を、スクリプトとして書いて動かせます。

違いは、仮想マシンの管理を Meta が行う点にあります。利用者の筆者は、仮想マシンの中でコマンドを打つ画面(ターミナル)を持たず、Muse に頼んで操作させます。外への通信は Meta の見張りの仕組みを通り、連携の資格情報は仮想マシンの外に保管される、と公式の記事は説明しています。Muse に自由があるのは、仮想マシンの中であり、外のサイトや決済には、サイト側の規則が及びます。

画像と動画の生成は、仮想マシンの外の別のサーバーで行われている、と推定します(動画の失敗が「生成サーバー」の過負荷と表示されたことと、仮想マシンが CPU の機械であることから。確認はしていません)。

仮想マシンの中の設定

筆者が Muse に、仮想マシンの中の設定を尋ねたところ、回答は次の表のとおりでした。右の列は、既存の資料(内部構成の記事が引用する第三者の観測)との照合で、一致は値が同じもの、整合は矛盾しないもの、新規は既存の資料にないものを指します。

種類	観点	Muse の回答	照合
利用者と名前	ログインの利用者	root(仮想マシンの中は root で動作)	整合。Meta は、実行セルの中の root が、ホストでは権限のない利用者に対応づけられると説明している(公式)
	ホスト名	htch-runtime	新規。内部の名前 Hatch の略に見えるが、綴りが hatch でなく htch
	SSH の鍵のコメント	hatch	新規。鍵が仮想マシンの中にあることは、報告されていなかった
資源	CPU	2 コア。ホストは AMD EPYC の世代。PyTorch も 2 スレッドで動いた	一致(2 つの仮想 CPU)。CPU の型は新規
	メモリ	約 8 GB、スワップなし	一致(約 7.7 GiB、割り当て 8 GB)。スワップの有無は新規
	GPU	なし	整合(CPU だけの機械)
	ディスク	100 GB、使用量は約 1.4 GB	一致(永続領域が約 100 GB の btrfs)
保存	ホームの下	揮発しない。仮想マシンが入れ替わっても引き継がれる	整合。永続領域に /home/hatch があり、入れ替えをまたいで残る
	/tmp、/usr など	再起動や入れ替えで消えることがある	整合。書き込み用の層は、使い捨ての鍵で暗号化された約 7.5 GB の一時領域
	運用	仮想マシンは入れ替わりうるが、~/workspace は永続化される。残したいものは ~/workspace/ の下に置く	整合。定期実行の定義も ~/workspace/cron.d/ にある
	MNIST の置き場	~/workspace/pytorch-mnist-demo/(スクリプト、仮想環境 約 1.1 GB、データ約 64 MB、図 2 点)	一致(報告の同梱物)

この表は、Muse の回答であって、筆者が仮想マシンの中でコマンドを実行して得た値ではありません。Muse が、コマンドの出力を見て答えたのか、記憶や推測で答えたのかも分かりません。回答は、既存の資料の観測とよく合います。ただし、合うのは、資源と保存の構成のような、すでに公表または報告されていた内容が多く、新しい情報は、ホスト名、SSH の鍵、CPU の型、スワップの有無に限られます。

確かめるべき食い違いの可能性が 1 つあります。ログインの利用者が root なら、ホームの ~ は通常 /root になります。一方、既存の資料の永続領域は /home/hatch にあります。~/workspace が /root/workspace なのか、環境変数でホームが /home/hatch に設定されているのかは、回答からは分かりません。永続領域の外にホームがあるなら、「ホームの下は揮発しない」という回答と食い違います。ただし、Muse が繰り返し述べているのは、~/workspace を永続の置き場にしている、という運用であり、この部分は、回答が一貫しています。

自分のサーバーへの接続

筆者が Muse に SSH の公開鍵を尋ねると、Muse は公開鍵を教えます。公開鍵は公開してよい情報なので、利用者が持つ VPS(自分のサーバー)の authorized_keys に登録すれば、Muse が仮想マシンから、その VPS に SSH で接続できる、と筆者は想定します。Muse が仮想マシンを自分で操作できることから、できる可能性は高いと考えますが、実際の接続は試していません。

接続の向きを図 8 に示します。

図 8: SSH の向き(緑は外向き、赤は内向き、橙はリバース SSH トンネル。いずれも接続は試していない)

向きが逆の接続、つまり筆者の VPS から Muse の仮想マシンへの SSH は、できないと考えられます(こちらも試していません)。内部構成の記事が引用する観測では、利用者のアプリから仮想マシンへの接続は、仮想マシンごとの名前から Meta の入口を通る経路で、仮想マシンの中の専用の受け口に届きます。SSH で外から入る経路は、公開されていません。したがって、接続は、Muse の側から開始する形になります。

筆者が、Muse に、外向きの SSH を逆向きに使う方法(リバース SSH トンネル)を設定できるか尋ねたところ、Muse は設定しないと答えました。回答の要点は次の 3 つです。

• 仕組みとしては、内側から外へ接続し、その経路を逆向きに使う技術なので、理屈の上では抜け道は存在する
• ただし、それは自分の実行環境への直接のログイン口を新しく開ける行為で、製品として用意された使い方ではないので、自分からは設定しない
• 仮想マシンへのアクセスは、チャットで頼んで、Muse が操作して結果を返す形に設計されている。逆に、Muse が筆者のマシンへ入る方向は正規の使い方で、公開鍵の登録だけで始められる

この拒否は、技術的にできないという答えではなく、Muse 自身の線引きです。外向きの SSH が通るかを試していないので、トンネルが技術的に張れるかどうかも、確かめていません。また、拒否が、モデルの判断か、Meta が設定した規則かは、回答からは分かりません。「チャットで頼んで操作させる形に設計されている」という説明は、Muse の回答であって、Meta の公式の説明ではありません(公式の説明は、利用者が作業中のブラウザの画面を見て引き継げる、という範囲です)。

外への通信はすべて Meta の見張りの仕組み(Sentinel)を通る、と公式の記事は説明しています。SSH のような、ブラウザや連携以外の通信(22 番)を、その見張りが通すかは、確かめていません。

Muse は、仮想マシンから外に出るときの接続元のアドレスを答えました(ここには載せません)。Muse の説明では、共用の出口(NAT やプロキシ)に見え、固定とは限りません。登録情報で調べると、このアドレスは Cloudflare のもので、Cloudflare が公開する位置情報では米国イリノイ州シカゴです。外への通信が Cloudflare の出口を経由する可能性があります(位置は実際の場所とは限りません)。答えを得た方法と、毎回同じ値かは、確かめていません。共用の出口なら、アドレスによる制限は、ほかの利用者の接続も通すので、鍵による認証の補助にとどまります。

確かめていないことは次のとおりです。

• 仮想マシンから VPS への SSH が、実際に通るか
• 鍵が、仮想マシンの入れ替えのあとも同じものか。入れ替えのたびに鍵が変わるなら、登録のやり直しが要る
• Tailscale のような、ネットワークへの参加を要する仕組みを、仮想マシンから使えるか。参加できても、VPS の側から Muse を呼ぶことはできない

登録するときの注意は、鍵を持つのが、root で動く Muse だということです。Muse の誤操作や、読み込んだ文書に仕込まれた指示(プロンプトインジェクション)で、VPS が操作される恐れがあります。登録先は、重要なデータのない専用の VPS と、権限を絞った一般の利用者が無難です。

利用枠の消費

筆者は無料プランで使っています。この記事に書いたような使い方で、10 月 28 日に画面で確認した使用率は 39% でした。リセットは 2 日後の 10 月 30 日の予定です。ここまでの使い方なら、筆者の場合は無料プランでまかなえそうです。

使用率の値は、筆者が画面で読んだものです。画像や動画の生成が、このうちどれだけを占めるかは、確かめていません。

同じ仕様を AWS で借りた場合の価格

Muse の仮想マシンと同じ仕様(2 vCPU の AMD EPYC、メモリ 8 GB、ディスク 100 GB)を、AWS の仮想マシンのサービス(EC2)で借りると、いくらになるかを調べました。東京リージョンで、Linux のオンデマンド(24 時間 365 日の常時稼働)の価格です。月額は、時間単価に 730 時間を掛け、ディスク 100 GB(gp3、1 GB・月あたり 0.096 ドル、月 9.6 ドル)を足して出しました。

構成	時間単価	インスタンスの月額	ディスクを足した月額
m6a.large(AMD EPYC 7R13)	0.1116 ドル	約 81 ドル	約 91 ドル
m7a.large(AMD EPYC 9R14、新しい世代)	0.1497 ドル	約 109 ドル	約 119 ドル
t3a.large(AMD EPYC 7571、バースト型)	0.0979 ドル	約 71 ドル	約 81 ドル

1 ドルを 150 円とすると、m6a.large で月に約 13,700 円です。米国(us-east-1)なら、m6a.large で月に約 71 ドルです(この単価は価格比較サイトの表示で、公式の価格表では確認していません)。公開 IPv4 アドレス(約 3.7 ドル/月)、外向きの通信料、スナップショットは含みません。使う時間だけ起動するなら、月 100 時間で、インスタンスの分は約 11 ドルにとどまります。

同じ仕様の仮想マシンを自分で常時借りると、月に 9,000〜14,000 円程度かかります。筆者は、これぐらいのインスタンスが、無料プランの範囲で使えるのはすごいと思います。ただし、Muse の仮想マシンが実際にどのインスタンスで、Meta がどう運用しているかは分からないので、この価格は仕様を合わせた場合の目安です。

日本のパートナー連携

メルカリ、マネーフォワード ME、チケットぴあとの連携は、発表の 10 月 23 日から 5 日後の 10 月 28 日の時点でも未開始と Muse が回答しました。この回答は、Muse 自身のものなので、公式の発表では確かめていません。メルカリの検索が動いたのは、連携ではなく、作業用のブラウザの操作だと考えられます(日本で始まった Meta の Muse を早速試した！の初日の観察と同じ)。

まとめ

• Muse の利用者から見える画面は会話が中心だが、実体は VM の上に載ったエージェントである。そのため、Codex や Claude Code で行う VM 上の操作は、かなりの範囲でこなせる。今回は、仮想環境の構築、PyTorch の導入、MNIST の学習、ブロック崩しのゲームの作成まで行った
• Muse は、Meta の仮想マシンの上のエージェントで、仮想マシンの中の作業(ブラウザ、ファイル、コード、定期的な起動)は自分で進める。6 日間で 34 項目のうち 27 項目を最後まで行った
• 購入、決済、解約、申込の最後の操作は人が行った(4 項目)。理由は、サイト側の受け付け、決済の仕組み、Muse の案内にとどめる姿勢の 3 つ。動画の生成は、はじめの 2 回は失敗し、回復後の依頼で成功した(3 項目のうち 1 つ)
• 同じ仕様の仮想マシンを AWS の東京で常時借りると、月に約 91 ドル(約 13,700 円)かかる。これぐらいのインスタンスが無料プランの範囲で使えるのは、すごいと思う
• 仮想マシンの設定は、Muse の回答が既存の観測とよく合う。新しいのは、ホスト名、SSH の鍵、CPU の型、スワップの有無で、いずれもコマンドの出力では確かめていない。自分のサーバーへの SSH は、できると想定したが、試していない

出典

確認日はいずれも 2026-10-28。

1. Muse の報告(Muse が作成した README.md)と、同梱の画像 10 点、train_mnist.py、結果の図 2 点
2. 筆者による画像の検査と、MNIST のコードの再実行
3. Meta の Muse のリバースエンジニアリング情報まとめ。定期実行の定義と仮想マシンの資源は、そこに引用された Rohan Adwankar の解析による
4. 日本で始まった Meta の Muse を早速試した！
5. 接続元の登録情報: ARIN の RDAP と Cloudflare の位置情報(api.cloudflare.com/local-ip-ranges.csv)
6. AWS の価格: AWS の公式価格表(東京リージョン、2026-10-27 公表分)。米国の単価は instances.vantage.sh の表示