Meta の Muse のリバースエンジニアリング情報まとめ

本記事は Claude Code と一緒に調べ、書きました。公開された解析と Meta の記事の取得、出典との照合、図の作成、文章の校正に使っています。何を調べるか、結論の判断、修正の指示は筆者です。

Meta の個人向け AI エージェント Muse の内部の作りは、Meta が詳しく公開していません。一方で、利用者が自分の Muse の環境を調べて公開した解析が、いくつもあります。この記事は、それらと Meta の公式の記事を突き合わせて、Muse の内部構成を整理したものです。インフラ、データの扱い、プロアクティブな動き、ブラウザの操作、外部との通信、エージェントの実行系、Claude Agent SDK などとの比べを扱います。

この記事の前提

• 筆者は、Muse の内部に独自にアクセスしていません。すべて、公開された他者の解析と、公式の記事に基づきます
• Muse の利用規約には、リバースエンジニアリングを禁じる条項があります。この記事は、公開された解析の紹介と整理で、同じことを勧めるものではありません。条項の原文は、規約のページで確認してください
• 解析は、特定の利用者の環境の、特定の日付(多くは 2026-09-24)の観測です。日本版を含む現在の版に当てはまるとは限りません
• 確かさは、公式、観測、再構成、仮説、未確認の 5 つに分けて書きます

先行した解析者への敬意

この記事は、自分の Muse の環境を調べ、結果と限界を公開した方々の仕事の上に成り立っています。筆者がしたのは、それらを読み、出典と突き合わせて整理することだけです。内部を実際に調べ、手順と証拠を示して公開してくださったことに、敬意と感謝を述べます。

• Jules Kuehn さん: 実行セルの中から、ファイルシステム、マウント、実際の道具の呼び出しを観測し、エージェントに与えられた道具の定義を、約 42 万字にわたって採録しました。観測、契約、推論、アクセスできない点を区別して書いてあり、この記事の確かさの書き分けの手本にしました
• Rohan Adwankar さん: 仮想マシンの種別、ディスク、データベース、バイナリの文字列を調べ、数値と手順を示したうえで、推測は推測と書いています
• Peter James さん: ブラウザの構成を、文字列から再構成し、自分の誤りを訂正しています
• Cygankiewicz さん: サブエージェントの同時起動を、試行の台帳とトレースつきで試し、当初の記述も訂正しています
• Futuresociety: 書き出した仮想マシンのファイルから、47 件の指摘を、ファイル名と行の引用つきで公開しています。AI が生成したレポートであることを、自ら明記しています
• mahdi-salmanzade さん: アプリの静的解析を公開し、アプリを実行していないことを明記しています

どの解析も、観測と推論を分け、1 つの環境の、ある日の観測だと断っています。この記事で、証拠の強さを書き分けられたのは、この姿勢に倣えたからです。誤りがあれば、筆者の読み違いです。

用語

用語	意味
筆者	この記事の書き手
Muse、Hatch	Muse は Meta の個人向けの AI エージェント。Hatch は、バイナリやパスに現れる、Muse の内部の名前
Muse Secure VM	利用者ごとに 1 台ずつ用意される、専用の Linux の仮想マシン
実行セル	Secure VM の中で、エージェントとユーザーのコードが動く区画。systemd-nspawn のコンテナ
Sentinel、hatch-authd、privsep	セルの外で動く安全の部品。Sentinel は外への通信と連携の許可、hatch-authd は資格情報の保管、privsep は連携のコードを道具ごとの狭い権限で動かす
Cloud Hypervisor、KVM	仮想マシンを動かす仕組み。KVM は Linux の機能、Cloud Hypervisor はその上で仮想マシンを動かすソフトウェア
RV(Reliable Volume)	第三者の解析が観測した、暗号化された永続の領域。VM を入れ替えても残る
PostgreSQL、pgvector	PostgreSQL は、VM の中で動くデータベース。pgvector は、そこでベクトル(意味の近さ)を検索する拡張
埋め込み、再順位付け	埋め込みは、文章を数値のベクトルにすること。再順位付けは、検索で出た候補を、関連の強い順に並べ直すこと
cron、hooks、heartbeat	cron は、時刻による定期や単発の実行。hooks は、条件を軽く調べ、成立したときだけエージェントを起こす仕組み。heartbeat は、一定の間隔で動く内部の確認
tracking、user_goal、todo	Muse が持つ 3 種類の状態。todo は 1 回の作業の段取り、tracking は配送や予約のような終わりのある案件、user_goal は長期の目標
workflow	保存して何度でも実行できる、決まった手順のプログラム
サブエージェント	本体のエージェントが起動する、作業を分担する子のエージェント
道具の定義	エージェントに与えられる道具の名前、説明、引数の定義。エージェントの指示の一部として、観測者が採録した
スキル	道具の使い方や手順を書いた SKILL.md と、補助のファイルの組。必要なときに読み込まれる
コネクタ、CLI、MCP	コネクタは、Muse を外部のサービス(Gmail、カレンダー、Spotify など)につなぐ連携。CLI は、コマンドラインから呼ぶ道具で、Muse のコネクタはこれで作られている。MCP は、AI を外部のサービスにつなぐ共通の取り決め(Model Context Protocol)
アクセシビリティ木	画面の読み上げ機能が使う、ページの構造の要約。要素の役割と名前を持つ。ページの HTML そのものではない
LLM、VLM、DOM、CDP	LLM は、文章を読み書きする大規模な AI。VLM は、画像も読める LLM。DOM は、ウェブページの HTML の構造を、プログラムが扱える形にしたもの。CDP は、Chromium を外から操作する接続(Chrome DevTools Protocol)
OpenClaw	利用者の環境で動く、オープンソースの個人向けエージェント。Muse のファイルの構成と似た設計を持つ
ブートストラップ	利用者の会話もメモリも空の状態で、製品が最初から持っている規則
確認の区分	公式、観測、再構成、仮説、未確認の 5 つ。図 2 に示す

要旨

Muse の構成は、公式の説明と第三者の観測がよく一致している。ただし、Kuehn、Adwankar、Futuresociety の観測は、いずれも 2026-09-24 前後の、同じ時期の版を見ている可能性が高い。一致は、独立した複数の確認というより、同一の版のスナップショットが一致していることかもしれない。利用者ごとの仮想マシンの中に、エージェントが動く実行セルがあり、セルの外に、通信と連携の許可、資格情報、安全の分類器、データベース、ブラウザのブローカー、推論の中継が置かれている。持続する状態は暗号化された別の領域にあり、仮想マシンの入れ替えで失われない。中核の LLM の推論は仮想マシンの外で行われ、中には、埋め込み、再順位付け、音声認識、安全の分類器といった小型のモデルがある(2 章、3 章)。

エージェントは、会話の内容を、記憶(Markdown のファイル)、todo、tracking、user_goal、cron、hooks のどれかに、自分の判断で振り分ける。常設のファイルは毎ターン、プロンプトに注入され、そのほかの記憶は必要なときに検索で引く。メモリは、人が参照し編集する永続の記憶が Markdown を中心に構成され、PostgreSQL が全文検索とベクトル検索の索引に加えて、構造化された記憶関連の状態も持つと報告されている。両者の書き込みの順序、索引から再構築できるか、整合の取り方、最終的な正本は、確かめられていない。「忘れて」と頼んでも、会話の記録は残る(4 章)。

プロアクティブな動きには、cron、hooks、heartbeat という、時刻と条件で起動する仕組みがある。これとは別に、第三者が取得した VM のファイルには、製品が管理する定期ジョブ(6 時間のフォローアップの選別、毎時の記憶の抽出、毎晩の Dreaming、1 日 24 枠のフィード)の定義と、一部の実行例が報告されている。ただし、各ジョブが毎回 LLM を呼ぶか、すべての利用者で有効かは、確かめられていない。一方、会話もメモリも空で、メールをつないだだけのとき、何を、どの期間、何件、どのモデルで調べるかは、公開された資料から分からない。これが最大の未解明である(5 章、11 章)。本文の証拠は、初期探索が存在しない、または利用者の目標と会話に限られるという見方と、むしろ整合する。

ブラウザの操作は、画像を読む VLM が 1 手ずつ判断する形ではない。エージェントが受け取るのは、アクセシビリティ木のラベルで、ラベルと実際の DOM の対応は、セルの外のブローカーが持つ。主要なコネクタの実装の経路は、MCP ではなく、スキルと CLI と、道具ごとに権限を分けたワーカーの組として観測されている。MCP を併用している可能性は、確かめられていない(7 章、8 章)。

エージェントの実行の基本の流れは、Claude Agent SDK などと同じで、違いは、長期の状態、スケジューラ、承認、通知を、製品として標準で持つ点にある(6 章)。筆者の日本での試行は、この構成と矛盾せず、メールの認証コードを Muse が自分で拾って入力した動きにも、内部の文書に対応する設計の記述がある(12 章)。

図 1: この記事の地図

1 調べ方と文献の調書

1.1 調べ方

元になったのは、第三者が公開した解析と、Meta の公式の記事である。主張は、出典を 1 件ずつ取り直して確かめた。確かめられなかった点は、14 章に分けて書いた。Meta の公開資料に基づく技術の整理は、筆者の別の記事(出典 17)にあり、この記事は、そこに書かれていない第三者の解析と、プロアクティブとデータの扱いに重点を置く。

Meta は公式に、実行環境の細かい構成を公開していない。第三者の解析は、特定の利用者の環境、特定の日付(多くは 2026-09-24)の版を調べたもので、日本版を含むすべての利用者に当てはまるとは限らない。筆者は、Muse の内部に独自にアクセスしておらず、この記事の観測は、すべて他者の報告による。

読めなかったものは、Meta の Muse for Productivity のページ(本文が取得できなかった。出典 6)と、The Verge の記事(取得できなかった。出典 13)である。

第三者の解析は、どれも、著者の 1 つの環境、特定の日付の観測である。バイナリの文字列やパスは、その機能が有効であることや、実際に呼ばれたことを示さない。Kuehn は、観測した内容と推論を明確に分けて書いており、プロアクティブの内部は観測できていないと断っている。Futuresocietyの解析は、自ら AI で生成したレポートと明記している。

1.2 文献の見方

各調書は、次の項目で書く。

• 書誌: 著者、題名、日付、場所
• 種別: 公式の記事、個人の観測、取得したファイルの分析、論文、ドキュメント
• 方法: どうやって調べたか
• 確かめた範囲: 筆者が、今回、どこまで読んだか
• 信頼できる点と限界
• 本件での使いどころ

信頼できる度合いの目安は、次のとおりである。観測した内容と推論を分けて書いているか、著者が限界を自分で書いているか、出所のファイルや行を示しているか、1 つの環境の話であることを断っているか。

確認の区分は、図 2 のとおりである。

図 2: 確認の区分

1.3 Meta の公式の文献

表 1: Meta の公式の文献

文献	種別と日付	内容	確かめた範囲	使いどころ
Tarek Sheasha, "How We Built Safety Into Muse"(出典 1)	技術記事。2026-09-08	仮想マシン、実行セル、Sentinel、hatch-authd、privsep、hatch-safety、ブラウザ、Confidential VM の計画	読了	構成の公式の骨格。プロアクティブの方針は書かれていない
Mona Sarantakos ほか, "How We Designed Muse"(出典 4)	設計記事。2026-09	Ideas、Goals、プロアクティブな連絡の調整、通知の基準	読了	プロアクティブの公式の説明。「予定と関連する出来事に応じて動き、結果を出す価値を評価する」。具体的な条件は書かれていない
"Muse Wonder"(出典 5)	モデルの発表。2026-10-12	Muse Wonder の提供先と展開時期、Active Memory、Active Focus	読了	モデルの展開の時期。プロアクティブの仕組みは書かれていない
"Muse for Productivity"(出典 6)	製品のページ	メール、カレンダー、ファイルの連携	本文を取得できず	「メールをつなげれば重要なものを選別する」という説明の有無は、確かめられていない

設計記事は、プロアクティブの技術の詳細を書かず、安全の技術記事を参照するよう案内している。安全の技術記事は、プロアクティブの方針を書いていない。つまり、Meta の公式の資料の範囲では、プロアクティブの内部は、書かれていない。

1.4 利用者による観測

表 2: 第三者の観測の文献

文献	方法	確かめた範囲	信頼できる点	限界
Jules Kuehn, "Muse Agent Architecture: An Interface Tour"(出典 7)	2026-09-24 に、実行セルの中から、ファイルシステム、マウント、ps、バイナリの文字列、実際の道具の呼び出しで観測。各記述に、観測、インターフェースの契約、推論、アクセスできない、のラベルを付ける	全体の約 42 万字を、5 回に分けて読了	道具のスキーマをそのまま採録。観測と推論を分ける。観測できなかった点を自分で書く	1 つのセッション、1 日の観測。プロアクティブの内部は観測できていない
Rohan Adwankar, "What's in a Muse?"(出典 8)	シェルから、一般的なツールで仮想マシンを調べる	要点を確認	数値と手順を示す。推測を推測と書く(avocado が Muse Spark 1.3 の名前かは推測)	仮想マシンの内側からの観測。夜間のロールアウト 3 回分
Peter James, "Inside Muse's browser stack"(出典 9)	製品に含まれるファイルと文字列を読む	要点を確認	「文字列からの再構成」と明記し、誤りを訂正する	多くが文字列とパスからの推測
Cygankiewicz, サブエージェントの負荷試験(出典 11)	自分のセッションで、4 条件の起動の試験	数字を確認	試行の台帳と DB のトレースに基づく。当初の記述を訂正している	各条件 1 回。Meta の認可を受けた評価ではない
Futuresociety, "Muse, in its own files"(出典 10)	2026-09-24 に、Muse に VM のルートファイルシステムを書き出させたものの分析	ページが読み込む report_data.json を直接取得し、47 件の指摘(高 5、中 14、低 28)と、各指摘の引用を確認	指摘をファイルの行範囲に紐づけ、引用をスクリプトで照合する、と書く。データに引用の文字列が入っていることを確認した(原ファイルの存在は未検証)	AI で生成したレポートと自ら断る。1 つの VM の、特定の日付のファイルに基づく。引用の解釈には、著者の評価が混じる
mahdi-salmanzade, "meta-muse-teardown"(出典 12)	macOS、Android、iOS のアプリの静的解析	要点を確認	「アプリを実行していない」と明記	機能が存在することと、データが送られたことは別

Futuresociety のハイライトの 5 件は、次のとおりである(出典 10)。安全のブロックリストにニュースサイトが入っていること、「忘れて」が記憶を消さず、会話が残って読み続けられること、データが利用者の仮想マシンの外に公開されること、利用者の知る人々のプロファイルを作ること、エージェントが自分のファイルシステムを書き出したこと。6 時間のフォローアップの選別や、24 枠のフィードの処理は、ページ本体ではなく、読み込まれるデータ(report_data.json)に入っていて、1.6 節で確かめた。

1.5 道具の定義の読み直し

Kuehn の文書は、エージェントに与えられた道具の定義を、そのまま採録している。後半の部分を読み直して、プロアクティブの仕組みに関わる記述を見つけた(出典 7)。いずれも、道具の説明文の原文である。

表 3: 道具の定義にある、プロアクティブに関わる記述

道具	原文(英語のまま)の趣旨	読み取れること
user_goal(名前空間の説明)	"Proactive Letters delivered in chat are produced from these goals"	チャットに届く先回りの手紙は、目標から作られる
user_goal.update	"Set pushable to false when the user says to stop proactive brief pushes for this goal"	目標ごとに、先回りの通知を止められる
user_goal.update、tracking.update	"escalation is what to do if a stated condition is not met by a date"、"Never infer one from elapsed time or a soft deadline"	期日までに条件が満たされないときの対応は、利用者が述べた条件に限る。経過時間や緩い期限から推測して作らない
tracking.update	"with action notify (tell the user) or ask (the user must decide next)"	対応は、知らせるか、利用者に決めてもらう、のどちらか
tracking(名前空間の説明)	"Attach the cron or check-in to that goal (cron owner goal:<goal-slug>)"	cron や確認は、目標に結び付けて作る
hooks.add	"Instruction for the worker agent launched when the polling script calls wake(...)"、"decides whether the main agent should be notified"	ポーリングのスクリプトが wake を呼ぶと、ワーカーのエージェントが起動し、本体のエージェントに知らせるかをワーカーが決める
hooks.add	"Seconds between script polls. Defaults to 60."、"Defaults to the chat where it was created."	ポーリングの間隔の既定は 60 秒。知らせる先の既定は、作られたチャット
cron	"a cron delivers to the chat where it was created by default"、"the run always happens and the worker decides what reaches the user"	cron は、必ず実行され、利用者に何を届けるかは、ワーカーが決める
feed	"Scheduled units arrive on their own."	フィードの予定された単位は、自動で届く。完了を知らせる連絡はない
tracking(ライフサイクル)	"the daemon's tracking lifecycle coordinator"	tracking の状態の変更は、デーモンの調整役が処理する

これらの記述は、4 つの意味を持つ。

1. 先回りの手紙の出どころが目標であること。これは、目標が無ければ、手紙が作られない、とは言っていない。製品が管理するフィードや内部のジョブが、別にある可能性がある
2. escalation(期日までに条件が満たされないときの対応)は、利用者が述べた条件に限って設定する、と定義されていること。この制約は、その場面に限った記述で、通常の hooks、目標の生成、初期の探索、フォローアップの候補の生成の全体に適用されるかは、確かめられていない。中心の問いの根拠としては、補助的な状況証拠にとどまる
3. hooks の wake のあとに、ワーカーが「本体に知らせるか」を判断すること。条件が成立しても、利用者への通知は、さらにもう 1 段の判断を通る
4. 先回りの通知を止める設定(pushable)が、目標の単位にあること。利用者が、先回りを増やす、止める、を会話で頼めるという公式の説明(出典 4)の、実装の側の手がかりである

heartbeat、memory_search、memory_explain、proactive という名前の道具の定義は、採録された範囲に見つからなかった。Kuehn の文書には、付録 A と B(プロンプトの抜粋)があると注記されているが、取得した本文には含まれていなかった。

1.6 Futuresociety の指摘データの確認

ページは、指摘を、同じ場所のデータ(report_data.json、約 23 万字)から読み込んでいた。取得して確かめたところ、47 件の指摘があり、各指摘には、題、主張、文脈、引用(VM の中のファイルの名前と行、原文)が付いていた。ここで確かめたのは、第三者のデータ(report_data.json)に、その引用の文字列が入っていることである。仮想マシンに実際にそのファイルがあったか、エージェントが書き出すとき、およびレポートを作る AI の処理で、改変、補完、捏造がなかったかは、確かめていない。書き出しはエージェント自身が行い、分析は AI が行っている。以下の「確認」は、この範囲の意味で読む。

プロアクティブに関わるものは、次のとおりである(出典 10)。

表 4: プロアクティブに関わる指摘と、データ内の引用で確認した内容(原ファイルは未検証)

指摘の識別子	確かめられた内容	出所のファイル
relationship-pages(高)	毎時の Relationships のジョブが、関係のある人物とグループの頁を書く。新しいテスト用のアカウントでは、同じセッションの中で動き、「不足」と報告した	docs/self_improvement.md、workspace/self_improvement/objectives/relationships/CURRENT.md
dreaming-profile(中)	毎晩の Dreaming が、直近の会話から「何が破綻したか、この利用者がどうなりつつあるか」を書く。毎日の Studying が、ときどき「利用者が示唆したが、明示しなかった目標」を提案する	docs/self_improvement.md
proactive-no-quiet(低)	静かな時間帯の設定は無い。承認は後回しにできず、夜に動いている作業も通知を出しうる。減らしたいと言われたら、止まると約束せず、好みのファイルを更新する。6 時間ごとのフォローアップの選別は、FEEDBACK.md と、最大 48 時間の見える会話を読む	docs/calls-texts-notifications.md、skills/forget/references/artifact-inventory.md
forget-hides-retention(高)	「忘れて」は、記憶のメモを編集するが、会話の記録は残す。フォローアップの選別の指示に、忘れた話題を使わず、無関係な候補が無ければ conversation_follow_up.nothing_to_do を呼ぶ、とある	docs/privacy-and-credentials.md、実行バイナリの文字列
template-bugs(低)	毎時の記憶のジョブのプロンプトに、「利用者は Context」という未展開のテンプレート変数と、「年は 2026 で 2025 ではない」というパッチがある。24 枠のフィードの処理が列挙され、空のアカウントでも、買い物のループが毎時動き、サブエージェントを 1 つ起動した	ジョブのセッションの記録
otp-auto-lookup(低)	利用者が頼んだサインインや決済で、サイトが送られたばかりのコードを待っていると確認できたとき、エージェントは、頼まれなくても、接続したメールやメッセージから、保護された検索を行う。コードは不透明な参照として扱い、入力には改めての承認が要る	docs/privacy-and-credentials.md
browser-default-allow(低)	ブラウザの通常のフォームの送信は、現在、既定で許可され、承認を求めない。ログイン、購入、投稿には承認が要る	docs/privacy-and-credentials.md
no-confirm-actions(低)	カレンダーの予定の削除などは、明確な依頼なら、追加の確認なしに進められる	skills/google-calendar/SKILL.md ほか
openclaw-unattributed(低)	SOUL.md の最初の行が、OpenClaw のテンプレートと同じ。帰属の表示は無い	home/hatch/SOUL.md
feed-engagement-loop(中)	フィードは、利用者の反応から学習した好みの要約から作られ、利用者が止められる設定は無い	docs/feed.md

この確認で、3 つのことが分かった。

1. 製品が管理する定期ジョブの定義と、一部の実行例が、利用者の依頼なしに存在する。6 時間の選別、毎時の記憶と人物の記録、毎日の Studying、毎晩の Dreaming、1 日 24 枠のフィード(feed pulse 00〜23 という名前のジョブ)である。各ジョブが毎回モデルを呼ぶか、すべての利用者で有効かは、引用からは分からない
2. 6 時間の選別は、候補が無ければ、nothing_to_do という道具を呼んで終わる。この道具を呼ぶのが、モデルか、決まった処理かは、引用からは分からない。モデルが毎回動くなら、空の窓でも推論の費用がかかる
3. 3D セキュアなどの認証コードをエージェントが自分で探す動きは、内部の文書に、設計として書かれている

2 構成の全体

この章は、利用者 1 人あたりの構成を、2 つの図で示す。図 3 は、仮想マシンの内外の部品の配置、図 4 は、実行部(ハーネス)とメモリの入れ子である。

2.1 利用者ごとの構成

図 3: Muse の 1 利用者あたりの構成。実線は公式の説明、点線は第三者の観測

Meta は、実行セルの中の root が、ホストの root ではなく、権限のない利用者に対応づけられる、と説明している。セルの外の部品(Sentinel、hatch-authd など)が、セルの中のエージェントから手を出せない位置にある、というのが設計の中心である(出典 1)。

2.2 ハーネスとメモリの外枠

図 4: Muse のハーネスとメモリの構造(外枠のブロック図)。外側から、仮想マシン、実行セル、ハーネス、メモリと作業領域の順に入れ子になっている。実行セルの道具の呼び出しと通信は、すべてセルの外の部品を通る。実線の枠は公式の説明と観測、破線の枠は観測や第三者の指摘にとどまるもの

読み方は、次のとおりである。

• 外枠は、利用者ごとの仮想マシンである。その中に、信頼しない区画(実行セル)と、信頼する区画(ホスト側)がある
• 実行セルの中が、ハーネス(エージェントの実行部)と、メモリと作業領域に分かれる。ハーネスは、実行の流れ、道具、スキルを持つ。メモリと作業領域は、毎ターン注入される常設ファイル、必要なときに引く記憶、予定や目標の定義に分かれる
• ハーネスとメモリは、ファイルの読み書きでつながる。記憶の索引と、tracking や user_goal の状態は、セルの外の PostgreSQL にある
• モデルの推論は、推論の中継を通って、仮想マシンの外に出る。外部のサービスへの通信は、Sentinel の許可を通る

3 インフラ

仮想化、ディスク、データベース、入口と出口、推論の経路、ブラウザの配置を、観測の順に整理する。

3.1 仮想化とセル

Adwankar は、仮想マシンの中で、systemd-detect-virt が systemd-nspawn を返し、DMI の情報が Cloud Hypervisor を示すことから、KVM の上の Cloud Hypervisor の仮想マシンの中に、systemd-nspawn のセルがある、という入れ子を報告した(観測)。見えた資源は、2 つの仮想 CPU と約 7.7 GiB のメモリで、割り当ては 8 GB、実際に使っていたのは約 2 GB だった。この値は、観測した 1 つのインスタンスのもので、全プラン共通の仕様ではない(出典 8)。

Meta の公式の説明は、セルに専用のファイルシステムと仮想ネットワークの口があり、システムコールが絞られ、カーネルの特権が限られる、と述べている(公式。出典 1)。

3.2 ディスクと永続化

Adwankar の観測では、仮想マシンは 4 つのブロックデバイスを持つ。

表 5: 観測したディスクの構成

デバイス	観測	読み取れる役割
vda	読み取り専用の btrfs、約 7.3 GB	配布される基本のイメージ
vdb	書き込み用の層。使い捨ての鍵で暗号化、約 7.5 GB	作業の一時領域
vdc	整合性を検証するイメージ、約 587 MB	実行ファイルとスキルの配布
vdd	LUKS2 で暗号化された約 100 GB の btrfs(RV)	/home/hatch、データベースなどの永続状態

/home/hatch は、zstd 圧縮の btrfs として観測された。Kuehn も、同じ配置を報告している(出典 7、8)。

新しいビルドを配るときは、新しい仮想マシンを作り、RV をつなぎ替え、古い仮想マシンを止める、という入れ替えの流れが観測された。実行できる状態になるまでに約 39 秒で、記事は約 40 秒の停止と書いている。再起動の命令も、実際は入れ替えに誘導された。この時間は、観測した環境の夜間のロールアウト 3 回分で、全体の一般的な値ではない(観測。出典 8)。

Meta は、仮想マシンのデータを継続的にバックアップして復元できる、と公式に述べているが、復旧の目標の時間や、鍵の管理は公開していない(出典 1、17)。

3.3 データベース

仮想マシンの中の PostgreSQL が、永続する状態を持つ。Unix ソケットで接続し、194 という数字は、スキーマの参照資料(4,116 行)の見出しを数えたものである。スキーマの名前には、activity、agent、device、feed、goals、ideas、ingest、memory、messages、runtime、scheduler、self_improvement、spaces が挙げられている(観測。出典 8)。エージェントが使うデータベースの口は、制約つきの読み取りである。テーブルが存在することと、機能が常に使われていることは別である。

3.4 入口

利用者のアプリから仮想マシンへの接続は、仮想マシンごとの名前(<識別子>.metaaivm.com)から、Meta のエッジを通り、仮想マシンの中の ingress-rev-proxy に届く。実行ファイルに Noise_XX という暗号の方式の名前があり、アプリと仮想マシンのあいだに持続するセッションがあると分析されている(観測。出典 8)。

デーモンの計測の名前(ingress_ms、admission_ms、time_to_llm_ms、time_to_first_response_token_ms など)から、送信の直後の「応答中」の表示は、モデルが推論を始めた証拠ではなく、受け付けが先に終わっているだけの可能性が示されている(観測。出典 8)。

3.5 出口と権限

外への通信は、すべて Sentinel を通る。資格情報の本物は hatch-authd にあり、セルの中には代理のトークンしかない。ユーザーのデータを読んだプロセスには印が付き、通信がより厳しく判定される。承認は、会話の中ではなく、Sentinel から利用者の画面に直接出る別の画面で行う。メールの連携は、1 回限りのコード、パスワードの再設定のリンク、ログインのリンクを、決まった規則と分類器で取り除く(公式。出典 1)。詳しい仕組みは、筆者の別の記事(出典 17)にある。

図 5: 外への通信が許されるまでの流れ(Meta の技術記事の記述)

3.6 推論の経路とモデルの名前

中核のモデルの推論は、仮想マシンの外で行われる。Meta も、推論とテレメトリのために必要なデータを外に送る、と述べている(公式。出典 1)。

Adwankar は、約 327 MB の Rust 製のバイナリの文字列から、環境変数 JARVIS_INFERENCE_PROXY_SOCK(推論の中継のソケット)、avocado-5.16-v4 や avocado-memory-flush-v1 といった識別子、さらに claude-opus-4-6、claude-opus-4-8、claude-sonnet-4-6、gpt-5.6-sol、gpt-5.5-codex という文字列を観測した。avocado が Muse Spark 1.3 の内部の名前かは、著者自身が推測にとどめている。どのモデルが応答するかは、サーバー側で決まり、仮想マシンの中からは見えない(観測。出典 8)。

文字列がバイナリにあることは、そのモデルが利用者への応答に使われる証拠ではない。記述された経路があることと、その経路が実際に使われることは、分けて考える。

仮想マシンの中には、小型のモデルがある。埋め込みの all-MiniLM-L6-v2(約 91 MB、384 次元)、再順位付けの jina-reranker-v1-turbo-en(約 153 MB)、音声認識の faster-whisper-tiny である(観測。出典 8)。

3.7 ブラウザの配置

Meta は、ブラウザが Chromium で、専用のブラウザのサブエージェントが操作し、CDP(ブラウザを外から操作する接続)の管理はセルの外のブローカーが行うと説明している。サブエージェントに渡すのは、アクセシビリティ木の写しで、ページの生の構造や、ページの中のスクリプトの実行は渡さない(公式。出典 1)。

Peter James は、ブラウザの作業が、エージェント自身の仮想マシンではなく、あらかじめ起動された別のブラウザの仮想マシンのプールから借りた環境で行われる、という構成を、ファイルの文字列から再構成した。ブローカーは、制御用の Stefi と連携し、失敗したときはエージェントの仮想マシンの中で動かす経路に退避する。設定には、利用者の地域に合わせた住宅用の出口(egress)を選ぶ項目もあるが、著者は、これが自動化ブラウザを検知されなくするものでも、Cloudflare の通過を保証するものでもない、と明記している(再構成。出典 9)。多くは文字列とパスからの推測で、著者自身が断っている。

ブラウザの作業の流れとページの読み方は、7 章で扱う。

3.8 観測の方法ごとの区分

この章の記述は、観測の方法が違う。実行中の環境の観測と、バイナリの文字列からの再構成を分けて読む。

観測の方法	該当する記述	読み方
実行中の環境の観測(ps、ファイル、ログ、システムの情報)	仮想マシンの種別、2 つの仮想 CPU と約 7.7 GiB、ディスクの構成、約 39 秒の入れ替え、heartbeat のログ	1 つの環境の、その日の観測で、全プラン共通とは言えない
取得したファイルの引用	Kuehn の道具の定義、Futuresociety の指摘の引用	定義と一部の実行例が分かる。毎回の実行や、全利用者での有効は別の問題
バイナリの文字列からの再構成	推論の中継のソケット名、モデル名の文字列、ブラウザの仮想マシンのプール、Stefi、AxSnapshot などの部品名	文字列があることは、その機能が使われた証拠ではない
公式の説明	Meta の技術記事	設計の意図で、実装の細部は書かれていない

4 データのライフサイクルとメモリ

会話が、記憶や予定になり、いつ読み出され、どう忘れられるかを、データの種類と置き場所から順にたどる。

4.1 データの種類と置き場所

表 6: Muse が持つデータの置き場所

データ	置き場所	書く主体	読む主体	区分
常設ファイル(AGENTS.md、SOUL.md、IDENTITY.md、USER.md、MEMORY.md、TOOLS.md、HEARTBEAT.md、PROACTIVE_PREFERENCES.md)	仮想マシンの中の Markdown	エージェント、利用者	毎ターン、プロンプトに注入	観測(出典 7)
日付つきの記録、人物とグループの頁、bank(world、experience、opinions)	~/memory/ の Markdown	エージェント、毎時のジョブ	memory_search、memory_get、memory_explain	観測(出典 7、8)
記憶の索引	PostgreSQL(全文 + 384 次元のベクトル)	索引のジョブ	memory_search	観測(出典 8)
好みの記録 FEEDBACK.md	~/FEEDBACK.md	エージェント	6 時間ごとのフォローアップの選別	再構成(出典 10)
tracking	データベース。状態の変更は、デーモンの調整役が処理	エージェント	エージェント、cron の確認	観測(出典 7)
user_goal	~/workspace/goals/<名前>/ の GOAL.md、files/(利用者向け)、hidden_files/(内部の記録)	利用者、エージェント、Studying	エージェント、先回りの手紙の元	観測(出典 7)
cron の定義	~/workspace/cron.d/ の Markdown(daily、hourly、runonce など)	エージェント	スケジューラ(実行のたびに本文を注入)	観測(出典 7)
hooks	~/hooks/scripts/ のスクリプトと ~/hooks/state/	エージェント	ポーリングで実行	観測(出典 7)
夜間の振り返り	~/dreams/	Dreaming	エージェント	再構成(出典 10)
フィードとアイデア	データベース	毎時のフィードのジョブ	利用者の画面	再構成(出典 10)
ゴミ箱	trash の名前空間。30 日後に自動で掃除	エージェント	復元	観測(出典 7)
資格情報	hatch-authd(セルの外の Secure Vault)。メモリ、ファイル、URL、ログには書かない	利用者が専用のページで入力	道具の実行時に、保護された経路で	観測、公式(出典 7、1)
中央に公開される記憶の埋め込み、fleet-learning の outbox、教訓	利用者ごとの仮想マシンの外	製品	Meta	再構成(出典 10)
テレメトリ、ジャーナル、WAL、スナップショット、バックアップ	仮想マシンの内外	製品	運用	再構成(出典 10)

図 6: Muse のデータのライフサイクル。書く主体、置き場所、読む主体、仮想マシンの外の写し

記憶に書かないものが決まっている。資格情報、コード、カード番号、政府の身分証の番号は、保存せず、存在と置き場所だけを記録する(観測。出典 7)。ただし Futuresociety は、毎時の記憶の抽出の指示に、健康、性、宗教、政治などの機微なカテゴリの規則が書かれていないこと、買い物のジョブの例のプロファイルが、配達の門の暗証番号、カードの下 4 桁、アレルギーを保存していることを指摘している(出典 10。システムプロンプトは取得されておらず、別に規則がある可能性がある)。

4.2 会話から、記憶・予定・目標への振り分け

図 7: 会話の内容が、記憶、todo、tracking、user_goal、cron、hooks に振り分けられる流れ(道具の定義と内部の文書からの筆者の整理。発言の例は筆者の例)

振り分けの規則は、道具の定義から、次のとおり読み取れる(観測。出典 7)。

• 記憶: 事実と好みを、MEMORY.md や ~/memory/ に、学んだらすぐ、応答の前に書く。書き込み専用の道具は無く、ファイルの編集で書く
• todo: 3 手順以上の作業の、このターンのチェックリスト。1 回の呼び出しで、リスト全体を置き換える
• tracking: 配送、予約、約束、継続のプロジェクトのように、会話のあとも続く、具体的な案件。具体的になったときに開き、解決したときに閉じる
• user_goal: 進捗、下位の目標、資料、予定を持つ、長期の願い。作業の領域を持つ
• cron: 時刻による予定。実行のたびに、ワーカーが 1 回起動する。履歴だけが、実行の有無の証拠になる。単発の「はい」は、1 回の実行だけを許可し、繰り返しには、予定を名指しした承認が別に要る
• hooks: 「X が来たら教えて」のための、軽いポーリング。既定の間隔は 60 秒で、条件が成立したときだけ、ワーカーを起こす
• escalation: 期日までに条件が満たされないときの対応(知らせる、または利用者に聞く)。利用者が述べた条件に限り、経過した時間や緩い期限から推測して作らない(この制約が cron、hooks、目標の生成の全体に及ぶかは未確認)

cron の持ち主は、目標に結び付けて作る(goal:<名前>)。cron の本文には、口座番号、資格情報、個人の識別子を書かない。本文は保存され、実行のたびに再び注入されるためである(Kuehn のセッションで、エージェントが AGENTS.md に記録した運用の規則)。

4.3 いつ読み出されるか

表 7: 読み出しの契機

読む動き	契機	読むもの
常設ファイルの注入	毎ターン	AGENTS.md、SOUL.md、IDENTITY.md、USER.md、MEMORY.md、TOOLS.md、HEARTBEAT.md、PROACTIVE_PREFERENCES.md。要約された会話と食い違うときは、ファイルが優先
記憶の検索	エージェントが必要と判断したとき	memory_search(MEMORY.md と ~/memory/ の意味検索)、memory_get(窓の読み)、memory_explain(由来、置き換えた履歴、確信度)
会話の圧縮	文脈が大きくなったとき	会話を要約する。完全な履歴は、クライアントと記憶に残る
cron と hooks	実行のたび	保存された本文を、ワーカーに再び注入
フォローアップの選別	6 時間ごと	FEEDBACK.md と、最大 48 時間の見える会話
記憶のジョブ	毎時	直近の活動の窓
Dreaming、Studying	毎晩、毎日	直近の会話、目標
Relationships	毎時(最初の実行は、全履歴を読む)	メッセージ、写真、メモリ
フィードの執筆	1 日 24 枠	利用者の反応から学習した好みの要約。接続したメールやカレンダーは材料にしない、と書かれている

Kuehn の観測では、memory_search はエージェントが呼ぶ道具として記述されており、全ターンでの自動の検索は確認できなかった。一方、Adwankar は、デーモンの memory_search と、推論の前の想起の段階(pre-inference recall step)が、全文検索とベクトル検索の両方を使うと書いている(出典 8)。ただし、この記述は、データベースのスキーマ、ディスク上のモデルのファイル、バイナリの文字列からの、著者の読みに基づく。実行中に想起の段階が動く様子を示した観測は無く、バイナリの段階の一覧(スキルの読み込み、プロンプトの組み立て、文脈の圧迫、圧縮)にも、想起は含まれていない。起動の条件、全ターンで動くか、検索の結果をプロンプトにどう入れるかは、確かめられていない。

4.4 メモリの構造

Kuehn が観測した、人が読めるメモリは、Markdown のファイルである(~/USER.md、~/MEMORY.md、~/FEEDBACK.md、~/AGENTS.md、~/memory/ の下の日付つきの記録、人物、グループ、bank/ の world、experience、opinions)。ベクトルのデータベースではない。読む道具は memory_search、memory_get、memory_explain で、書く専用の道具は無く、ファイルの編集で書く(観測。出典 7)。

Adwankar は、これに加えて、PostgreSQL の索引があると報告した。memory のスキーマに entries、claims、embeddings などがあり、全文検索(tsvector)とベクトル検索(pgvector、384 次元)を併用し、検索の結果には、path#L<行番号> の形の根拠の位置が付く。埋め込みと再順位付けは、仮想マシンの中の小型モデルで行う(観測。出典 8)。すべての書き込みがファイル起点か、データベースへの二重の書き込みがあるかは、確かめられていない。

つまり、人が参照し編集する永続の記憶は Markdown を中心に構成され、PostgreSQL は、検索の索引に加えて、構造化された記憶関連の状態(entries、claims、embeddings など)も持つと報告されている。両者の書き込みの順序、再構築できるか、整合の取り方、およびすべての記憶関連の状態にとっての最終的な正本は、確かめられていない。

図 8: メモリの書き込みと検索の流れ(観測と、ジョブの段階名からの再構成)

4.5 Mem0 との比較

Mem0 の資料によると、Platform v3 は、単一パスの LLM による抽出で「追加のみ」の事実を作り、既存の事実を上書きも削除もせず、新旧を並存させる。エンティティを抽出してリンクし、時間の情報を別の処理で抽出し、検索では、ベクトル、キーワード(BM25)、エンティティ、時間の 4 つのスコアを並列に出して、順位を融合する(出典 14)。ベンチマークの結果は、マネージド版のもので、オープンソース版には含まれない独自の最適化がある、と書かれている。v3 に明示的な更新と削除の API が残るかは、取得したページに記載が無く、確かめられなかった。

表 8: Muse と Mem0 のメモリの比べ

観点	Muse(観測)	Mem0(公式の資料)
責務	エージェントと密に結び付いた、個人の長期の状態	外のアプリから呼ぶ、メモリの API
人が参照・編集する主な永続の表現	人が読める Markdown(最終的な正本は未確認)	設定で選ぶデータベースとベクトルストア
抽出	LLM による定期のメモリの処理(プロンプトの観測。出典 10。本文は未確認)	単一パスの LLM、追加のみ(v3)
検索	全文 + ベクトル + 再順位付け	ベクトル + キーワード + エンティティ + 時間
説明のしやすさ	path#L<行> の根拠の位置、memory_explain	メタデータと履歴

Muse の記憶を、単なるベクトルのメモリ API に置き換えると、ユーザーやエージェントが全文を見て編集できること、行番号に基づく参照と監査、目標やタスクと一体の状態の更新が、失われうる。逆に、Mem0 は、汎用の API、範囲の分離、抽出と検索の処理の再利用が強みで、Muse が常に Mem0 より優れているという証拠は無い。

4.6 LangMem との比較

LangMem は、記憶を、semantic(事実)、episodic(過去の経験)、procedural(振る舞いの方針)に分け、記憶の形成を、会話の中で能動的に書く hot path と、会話のあとに振り返って抽出する background に分ける。hot path は、応答の遅延を増やす、と書かれている(出典 15)。ReflectionExecutor は、取得した概念のページには無く、API リファレンスに書かれているもので、確かめていない。

Muse の対応は、次のように読める。USER.md と MEMORY.md が semantic、日付つきの記録が episodic、AGENTS.md や TOOLS.md が procedural、毎時の記憶の整理が background にあたる。ただし、これは筆者の対応づけで、Muse の設計者の分類ではない(仮説)。Muse の独自性は、記憶の抽出の方法そのものより、個人のエージェントの状態、定期のジョブ、編集できるファイル、プロアクティブな通知を、1 つにまとめている点にある可能性が高い。

4.7 忘却と、残るもの

「忘れて」の流れは、道具の定義と、内部の文書(forget のスキル)から、次のように読める(出典 10)。

• 記憶のメモは編集される。会話の記録は、利用者が別に削除しない限り、残る
• 会話から派生した、要約、チェックポイント、フォローアップの好みなどは、消す対象になる
• 中央に公開された埋め込み、fleet-learning の outbox、コミュニティのカードは、仮想マシンの外にあり、仮想マシンの中のエージェントには、消せない可能性がある
• テレメトリ、ジャーナル、WAL、スナップショット、バックアップは、通常のメモリではない。権威のある確認なしに、物理的に消えたと言ってはならない、と書かれている

Futuresocietyの解析は、「忘れて」と頼むと、要約のメモは編集されるが、会話そのものは残り、その会話が、エージェント本体、コンテキストの要約、バックグラウンドの記憶ジョブに読み続けられる、と指摘している(再構成。ページのハイライトで確認)。Meta は、メモリの編集と削除の能力を説明するが、メモリから消すこと、会話の履歴を消すこと、バックアップや派生した索引まで消すことは、別の操作である。

同じ解析は、記憶の埋め込みや、フリート全体の学習のための出力の箱(outbox)が、利用者ごとの仮想マシンの外の中央に公開される、と指摘している。Meta が「意図した動作」と説明したのは、利用者が自分の仮想マシンのファイルシステムを書き出せた件についてである(出典 10)。これを、記憶の埋め込みなどの派生データの中央への転送についての Meta の見解と、混同してはならない。中央への転送に対する Meta の説明は、確かめられていない。また、公式の「仮想マシンが正本」という説明と、派生データの外部への転送は、別の論点である。指摘の根拠として取得したファイルにあるのは、削除の対象を列挙した内部の一覧(forget のスキルの在庫)と、データベースの定義(feed の fleet_engagement_outbox の列で、識別子の持ち主は「この VM のデータベースの外」とされる)である。名前や出力先の定義があることと、実際の送信が完了したことは、別である。個別の本文は未確認である。

5 プロアクティブの仕組み

利用者が頼んでいないときに、Muse が動き出す仕組みを扱う。まず動きを 4 つの型に分け、起動の仕組み、公式の説明、道具の定義、製品の内部ジョブの順に、証拠を並べる。

5.1 プロアクティブの 4 つの型

一口にプロアクティブと言っても、起点が違う 4 つの動きがある。

表 9: プロアクティブの 4 つの型

型	起点	例
A 非同期の完了通知	利用者が頼んだ作業	予約の処理が終わったことの通知
B 明示した継続の監視	利用者の監視の依頼、目標	配送の状況の監視
C 会話からの暗黙のフォローアップ	過去の発言、メモリ	「先週の件はどうなりましたか」
D 初期の設定だけからの発見	製品のブートストラップ、接続したデータ	頼んでいない請求書のリマインド

A と B ができても、D ができるとは限らない。最も知りたいのは、D の探索の範囲を誰が決め、どの程度を LLM で処理しているか、である。

5.2 起動の仕組み

表 10: 観測された起動の仕組み

仕組み	起動するもの	観測された動き	LLM の使用	区分
cron	スケジューラ	保存された定期や単発のジョブから、ワーカーを起動。定義は ~/workspace/cron.d/ に Markdown で保存し、管理は 8 つの関数。実行の履歴が実際の記録	ジョブによる	観測(出典 7)
hooks	軽い監視のスクリプト	条件に合ったときだけエージェントを起こす。連続のストリームではなく、一定間隔のポーリング。管理は 10 の関数	条件が成立しなければ不要	観測(出典 7)
heartbeat	内部のスケジューラ	30 分ごとに ~/HEARTBEAT.md を読む。確認の項目がなければ、推論を始めずに終わる	空なら使わない	観測(出典 7)
製品の内部ジョブ	製品	6 時間のフォローアップの選別、毎時の記憶の抽出と人物の記録、買い物の自己改善、毎日の Studying、毎晩の Dreaming、1 日 24 枠のフィード	LLM を使う処理の設計を示唆する。毎回呼ぶかは未確認。選別は、候補が無ければ nothing_to_do で終わる	再構成(出典 10)。定義と一部の実行例を、データ内の引用で確認(原ファイルは未検証。表 11)
外部のイベント	コネクタ、端末	同期や更新の検知	購読と起動の経路は未確認	未確認
利用者の発言	利用者	現在の依頼	通常のエージェント起動	公式

図 9: プロアクティブの起動の流れ。赤は LLM を使う段階、青は使わない段階

図 10: バックグラウンド処理の概念モデル。heartbeat の推論なしのスキップ、hooks の条件の監視、cron によるワーカーの起動など、個別に観測された動きを統合して再構成したもの。すべての内部ジョブが同じ軽い判定や通知の判定を通ることは、未確認

Kuehn は、heartbeat のログに「HEARTBEAT.md に指示がないので、heartbeat をスキップした。推論は始めていない」と記録されることを報告した。hooks は、「連続のストリームはなく、条件が成立しない限り黙っている」と書かれている。PROACTIVE_PREFERENCES.md という、通知の話題、時刻、表現を誘導するファイルは、Kuehn のセッションでは空のテンプレートだった(観測。出典 7)。

メールが届くことは、メールサービスの側の出来事である。購読、ポーリング、時間のジョブ、既存の目標のどれかで取り込まれて初めて、エージェントの側の出来事になる。メールの新着が、そのままエージェントの起動になる証拠は、見つかっていない。

5.3 Meta の公式の説明

Meta の設計記事は、バックグラウンドの作業を、スケジュールに従って、また関連する出来事に応じて続ける、と書く。結果を表に出す価値があるかを評価し、利用者に知らせるのは、本当に新しいことや入力が必要なときだけにする。プロアクティブなメッセージは、送る基準を高く保つ必要がある、とも書く。プロアクティブな連絡は、会話で、減らす、増やす、止めるよう頼める(公式。出典 4)。

製品の設計者本人が、子どもの新学期に備えて学校のメールと学区のサイトを Muse に見張らせ、締切の近いスポーツの選抜の申込みを拾った、という例も、同じ記事にある。ただし、これは、監視を頼んだ例で、頼まれていない初期の探索の例ではない(出典 4)。

トリガーの具体的な条件、評価の方法、判断に使うモデルやルールは、この記事に書かれていない。メールをつなぐと重要なものを日々選別する、という趣旨の説明が Meta の別のページにあるとされるが、そのページの本文は取得できず、確かめられなかった(出典 6)。

5.4 道具の定義に残る記述

Kuehn の文書の全体を読み直すと、エージェントに与えられた道具の定義に、プロアクティブに関わる記述があった(原文は表 3)。user_goal の説明に、チャットに届く先回りの手紙(Proactive Letters)は、目標から作られる、とある。目標ごとに、先回りの通知を止める設定(pushable)がある。期日までに条件が満たされないときの対応(escalation)は、利用者が述べた条件に限って設定し、経過した時間や緩い期限から推測して作ってはならない、とある。hooks は、条件が成立して wake が呼ばれたあと、ワーカーが、本体に知らせるかを決める(観測。出典 7)。

これらは、探索の範囲と通知の判断が、目標と利用者の言及に結び付いていることを示す、補助的な状況証拠である。escalation の制約は、期日までに条件が満たされないときの対応に限った記述で、通常の hooks、目標の生成、初期の探索、フォローアップの候補の生成の全体にも適用されるかは、確かめられていない。目標が空の初期状態で何が起きるかは、これらの記述から分からない。

5.5 初期の探索を誰が決めるか

利用者の会話、メモリ、目標、利用者が作ったジョブがすべて空で、メールだけが読める状態を考える。このとき、メールから重要なことを探す動きを始めるには、製品があらかじめ与えた命令が、少なくとも 1 つ要る。考えられる方式は、4 つある。

• 固定のカテゴリ(請求書、移動、予定の変更、配送など)を製品が実装し、静的な検索と分類器、少数の LLM で候補を作る
• 広いメールの履歴を、LLM に読ませて、何が重要かを LLM 自身に判断させる。計算量と初期の遅延が大きい
• 製品の規則で許したソースと種別だけを調べ、学習した関心や会話から探索を増やす。重い LLM の実行は、候補があるときだけにする
• 初期探索は存在しない、または、利用者の目標と会話に限られる。メールは、利用者の依頼、目標、会話から始まった作業の中でだけ読まれる

どれが正しいかは、公開された資料からは決められない。ただし、本文の証拠は、4 つ目を支持するものが多い。フィードは接続したメールやカレンダーを材料にしない、6 時間の選別が読むのは見える会話と FEEDBACK.md、先回りの手紙は目標から作られる、Studying は目標と会話が土台、という記述である。3 つ目を支持するのは、空のアカウントで買い物の自己改善のジョブが動いた例と、Studying が明示されない目標を提案しうるという記述にとどまり、メールを走査する証拠は無い。以前は 3 つ目を暫定の最有力としていたが、取り下げ、4 つ目と 3 つ目を並べて、4 つ目をやや優勢とする(仮説)。ただし、取得した範囲に無いことは、存在しないことの証明にならない。

設計の型は、次の 3 つに分けて読む。

• 事前に定義した処理の流れ: 製品が決めたトリガー、選別の規則、既定のジョブ。スクリプトだけの場合も、LLM を含む場合もある
• 動的な流れ: 利用者との対話や外部の出来事のあとに、エージェントが目標、tracking、hooks、cron、メモリを追加、更新、削除する
• 未知の初期探索: 空のメモリ、空の目標の状態で、外部の情報から、どこまで汎用に探索を始めるか

「初期の処理はすべて軽い規則である」「出来事の処理を、必ず LLM がコードとして生成する」「メールが届くと、必ず Muse がエージェントを起動する」は、いずれも未確認として扱う。

初期の状態でも、製品のジョブが動くことを示す第三者の報告はある。新しいアカウントで、買い物に関する自己改善のジョブが毎時動き、サブエージェントを 1 つ作り、作業するだけの情報が無く「不足」で終わった、という記録である。これが示すのは、製品が管理するジョブが初期状態でも動きうることで、接続したメールの全体を初回に意味で走査する証拠ではない(再構成。出典 10。本文は未確認。この実行の記録は 1 つのアカウントの報告で、モデルへの実際のリクエストがあったかは、確かめられていない)。

5.6 製品の内部ジョブ

ジョブについての証拠は、次の 4 つの段階を分けて読む。取得したファイルの引用で支えられるのは、主に 1 つ目である。

1. ドキュメント、設定、スクリプトに、ジョブの定義がある
2. 特定のアカウントで、そのジョブの実行の記録がある
3. その実行に、モデルへの実際のリクエストがあった
4. 現在のすべての利用者で、常に同じ頻度で実行される

1 つ目がデータ内の引用で確認できても、2 つ目から 4 つ目は、自動的には言えない。空のアカウントでの買い物の自己改善とサブエージェントの起動は、2 つ目にあたる観測例の 1 つとして、限定して扱う。

Futuresocietyの解析は、エクスポートした VM のファイルとセッションの記録から、47 件の指摘を、ファイルの名前と行の引用つきで公開している(高 5 件、中 14 件、低 28 件)。このページは、指摘を別のデータ(report_data.json)から読み込むため、最初は本文を取得できなかった。データを直接取得して、プロアクティブに関わる指摘の引用を確認した(原ファイルは未検証)。いずれも、解析の著者が取得した 1 つの VM の、特定の日付のファイルに基づく(出典 10)。

表 11: 製品の内部ジョブについて、データ内の引用で確認した記述(原ファイルは未検証)

ジョブ	周期	内容	出所(VM の中のファイル)
会話のフォローアップの選別	6 時間ごと	直近 48 時間の見える会話と FEEDBACK.md を読む。候補が無ければ、conversation_follow_up.nothing_to_do を呼んで終わる	skills/forget/references/artifact-inventory.md、実行バイナリの文字列
記憶の抽出	毎時	直近の活動の窓を選び、抽出の規則に従って、主張の束を 1 回で出す。窓が空か目立たないときは no_change で終わる	記録されたセッションのステップの指示
人物とグループの記録(Relationships)	毎時	関係のある人物とグループの頁を、メッセージ、写真、メモリから更新する。新しいテスト用のアカウントでは「不足」と報告した	docs/self_improvement.md
買い物の自己改善	毎時	新しい空のアカウントでも動き、サブエージェントを 1 つ起動して「不足」で終わった(周期は hourly、起動の元は internal.self_improvement)	workspace/self_improvement/objectives/shopping/CURRENT.md
Studying	毎日、夜間	目標の調査と進捗の知らせを作り、ときどき「利用者が示唆したが明示しなかった目標」を提案する	docs/self_improvement.md
Dreaming	毎晩	直近の会話を振り返り、「何が破綻したか、この利用者がどうなりつつあるか」を、日付つきの記録と補修のスレッドに書く	docs/self_improvement.md
フィードの生成	1 日 24 枠(各時間に 1 枠。feed pulse 00〜23)	利用者の反応から学習した好みの要約を読んで、投稿を書く	docs/feed.md、ジョブのプロンプト

図 11: 1 日の定期ジョブの周期。heartbeat と利用者のジョブは Kuehn の観測、そのほかはFuturesocietyの再構成

通知については、解析が次のことを引用している。静かな時間帯の設定は無く、承認は後回しにできず、夜に動いている作業も通知を出しうる。頼まれた作業の予定は、別の時刻に動かせる。利用者がプロアクティブな連絡を減らしたいと言ったときは、「止まると約束せず」、好みのファイルを更新する(docs/calls-texts-notifications.md)。通常のプロアクティブな項目は、同じ資料によると、1 日に 1 件程度に限られる、と解析の注記にある。

プロアクティブに関わるそのほかの記述は、次のとおりである。ブラウザの通常のフォームの送信は、現在、既定で許可され、利用者に承認を求めない(docs/privacy-and-credentials.md)。ログイン、購入、投稿のような、状態を変える操作には承認が要る。カレンダーの予定の削除は、明確な依頼なら、追加の確認なしに進められる(skills/google-calendar/SKILL.md)。

これらの周期は、処理の段階名(window_summary、extract、verify_claims、apply_claims、reconcile_memory、select_notification_suggestions、verify_proactive_notifications、publish、gate など)とともに、ジョブが LLM を使う処理として設計されていることを示唆する。個々の段階で何回モデルが呼ばれたか、条件が成立しない周期にも推論するかは、推論のトレースが無ければ確定できない。また、処理の段階の数と、LLM の呼び出しの回数は別のもので、段階名から呼び出しの回数を数えてはいけない。1 日 24 枠のフィードのジョブは、24 種類のジョブ定義でも、24 件の生成物でもなく、毎時 1 枠のスケジュールである。1 人の利用者が毎時 24 回 LLM を呼ぶ証拠ではない。

6 エージェントの実行系

実行の基本の流れ、Claude Agent SDK との対応、状態の種類、workflow、サブエージェントの同時起動の試験を扱う。

6.1 基本の流れは同じ

Muse の Hatch、Claude Agent SDK、そのほかのエージェントの SDK は、基本の流れが同じである。モデルが道具を呼び、道具の結果を観測して、またモデルに戻る。Claude Agent SDK は、Claude Code を動かすのと同じ道具、エージェントの流れ、文脈の管理を、Python と TypeScript のライブラリとして使えるようにしたものである(公式。出典 16)。したがって、「Muse はエージェントの SDK とは、原理から違う」という言い方は、正確ではない。違いは、流れの外側にある。

Hatch のバイナリのシンボルから、1 回の実行は、受け付け、推論の前処理(スキルの読み込み、プロンプトの組み立て、文脈の圧縮)、モデルのストリーム、道具の実行(承認の意図を伴う)、道具のあとの継続、終了処理、という段階を踏むと示唆されている(観測。出典 8)。シンボルは、制御の全体のソースコードではない。

図 12: エージェントの 1 回の実行の内部の流れ(第三者のバイナリのシンボルからの再構成)

6.2 機能の対応

表 12: Muse と Claude Agent SDK の機能の比べ

機能	Muse(観測)	Claude Agent SDK(公式)
エージェントの流れ	Hatch のデーモンと道具	Claude Code と同じ流れ
道具	shell、ファイル、連携	ファイルの読み書き、コマンド、ウェブ検索、MCP
サブエージェント	spawn、list、send、resume、close	専門のエージェントを、焦点を絞った作業のために起動
スキル	ファイルのスキル、遅延の読み込み	プロジェクトと ~/.claude/ から自動で読み込む
文脈の管理	圧縮、常設のファイル、メモリの想起	文脈を保ち、再開と分岐ができるセッション
hooks	外部の状態を調べ、条件で起こす	エージェントの流れの要所で、独自のコードを動かす
権限	Sentinel と承認	どの道具を自動で動かし、どれに承認が要るかの制御
スケジューラ	cron を、エージェントが呼べる	公式の概要に記載がない
目標、案件の追跡	user_goal、tracking を標準で提供	公式の概要に記載がない
長期の個人のメモリ	Markdown + 検索の索引	プロジェクトの指示ファイル

Codex SDK、OpenAI の Agents API との対応は、OpenAI の公式の資料を読んでおらず、確かめていない。

SDK に「記載がない」ことは、その基盤で実現できないという意味ではない。その名前の長期の状態の仕組みが、SDK の中核として共通に提供されていることを、確認できなかった、という意味である。

6.3 tracking、user_goal、todo

Kuehn が観測した道具の区分では、todo は現在のエージェントのターンの作業のチェックリスト(in_progress は 1 件だけ)、tracking は複数のターンにまたがる具体的な案件(配送、予約、約束、継続のプロジェクト)、user_goal は長期の目標で、~/workspace/goals/<名前>/ に GOAL.md などを置く。tracking にはステータスと活動のタイムラインがある(観測。出典 7)。これらは、探索の範囲を永続化し、個々の出来事がどの責務に対応するかを判断する土台になる。

6.4 workflow

Muse には、保存して実行できる workflow がある。Kuehn によると、バイナリの boa_engine-0.21.1 という文字列から、Rust 製の JavaScript エンジンを使うと観測され、関数は 14 個(create、update、delete、list、view、launch、launch_async、list_runs、view_run、pause、resume、stop、stop_agent、save_run)である。使えるグローバルは args、phase、agent、parallel、pipeline、log の 6 つで、Date.now() と Math.random() が無いので、決定的に動く。agent() が子のエージェントになる実行の経路は、バイナリの中に隠れていて、未確認と断られている(観測。出典 7)。

設計上の意味は、LLM で見つけた手順を、毎回 LLM に考え直させず、決まったプログラムとして保てることにある。ただし、workflow の中で agent() を多用すれば、そのたびにモデルの費用がかかる。スクリプトにすることは、推論が 0 になることではない。また、workflow を持つことは、LLM が自動で workflow を作ることや、すべての動的な規則が workflow にまとめられることを、示さない(仮説)。

6.5 hooks という語の違い

同じ名前でも、起点が違う。Muse の hooks は、外の世界の状態を定期に調べ、条件が成立したらエージェントを起こす仕組みである。Claude Agent SDK の hooks は、エージェントの流れの内側の要所(道具の実行の前後など)で、独自のコードを動かす仕組みである(出典 7、16)。比べるときは、外の世界の監視と、エージェントの内側への割り込みの 2 つの軸に分ける。

6.6 サブエージェントの同時起動の試験

Cygankiewicz は、自分の Muse のセッションで、各サブエージェントに「30 秒待って 1 行返す」だけの作業を与えて、同時起動の試験をした。

表 13: サブエージェントの同時起動の試験(各条件 1 回)

条件	起動の要求	作成された数	失敗	失敗率	同時の活動のピーク
PROBE-40(一斉)	40	39	1	2.5%	39
BURST-80(一斉)	80	75	5	6.25%	72
BURST-120(一斉)	120	33	87	72.5%	33
STAGGERED-80(分散)	80	80	0	0%	38

エラーの内容を回収できた 6 件(PROBE-40 の 1 件と BURST-80 の 5 件)は、すべて PostgreSQL の「canceling statement due to lock timeout」(ロックの待ちの時間切れ)だった。BURST-120 では、作成された 33 件のうち 32 件の作業の完了が確認され、親は running のまま、最終の結果は利用者に届かなかった。著者は、当初の報告にあった「親が失敗しても子は動き続けた」という記述を、トレースが裏付けないとして、のちに修正している。

注意点は、次のとおりである。各条件は 1 回だけで、ピークは活動の区間の重なりで、モデルの推論の同時の数ではない。分散の条件は、間隔だけでなく親子の構造も変えたため、間隔の効果は切り分けられていない。原因となるロックやクエリは特定されておらず、Meta が認可した評価でもない(出典 11)。

プロアクティブな機能を増やすと、推論の費用だけでなく、エージェントの生成、データベースの競合、再開、結果の集約、通知の取りこぼしが、支配的な問題になりうる(筆者の考え)。

7 ブラウザ操作

ブラウザの作業を、道具の経路、タスクの流れ、ページの読み方、ラベルと DOM の対応、同意の扱い、手数の測り方の順に整理する。

7.1 4 つの経路

ブラウザに関わる道具は、目的で使い分けられる(観測。出典 7)。

表 14: ブラウザに関わる道具

道具	目的	備考
browser.search	質問、話題、キーワードで情報を探す	URL や貼られたリンクは、検索ではない
browser.open	ページの文字を取得する	利用者のブラウザでページを開くのではない。URL を推測して作らない
browser.spawn_task	生の Chromium で、サイトに行く、操作する(購入、サインイン、フォーム)	非同期。購入は、サイトを名指ししなくても、これに当たる
深い調査	署名していないブラウザで、調査の専用のエージェントを送る	ウェブの調査を頼まれたときだけ

7.2 ブラウザのタスクの流れ

図 13: ブラウザの作業の処理フロー(Kuehn の道具の定義と、Peter James の再構成の合成)

browser.spawn_task の定義には、次のことが書かれている(観測。出典 7)。

• 呼び出しは非同期で、受け付けの控え(browser_task_id)が返るだけである。完了は、終わったときか、利用者の対応が要るときに、自動で届く。ポーリングや待機をしない。「すぐ終わる」と約束しない
• ブラウザのタスクは、会話を見られない。エージェント本体は、実行に必要なものをすべて含む、自己完結の指示を渡す。ファイルは、パスではなく、タスクの中だけの不透明な許可として渡す
• 汎用のサブエージェントは、ライブのブラウザを使えない。ブラウザの仕事を、サブエージェントに渡してはならない
• 続きの指示、承認、訂正は、steer_task で、同じタスクに送る。新しいタスクを起こし直さない
• list_tasks と peek_task が、タスクの状態、題、指示の全文、手数、作成、更新、完了の時刻、実行中の時間を返す
• 利用者が頼んだ場合だけ、スクリーンショットを渡す。この値は、タスクが引き渡すときに強制される
• ブラウザを使っても、利用者の依頼は広がらず、購入、サインイン、承認の規則も迂回されない

7.3 ページの読み方: VLM か

Meta の公式の説明は、ブラウザのサブエージェントに、アクセシビリティ木の写しを渡し、ページの生の構造や、ページの中のスクリプトの実行は渡さない、というものである(公式。出典 1)。Peter James は、実行ファイルの文字列から、次のように再構成した(再構成。出典 9)。

• エージェントは、要素の役割と名前を持つ、構造化された見え方を受け取り、「ref 42 をクリック」と指定する
• ブローカーが、要素を探し、操作を送る場所を決める。画面の画像を眺めて、座標を推測する必要がない
• 画面の画像で押す操作は、有用な要素が公開されていないページのために、まだ使える。一部の画面には、それが要る

表 15: VLM かを判断する材料

材料	内容	区分
アクセシビリティ木の写しを渡す	ページの生の構造も、画面の画像も、主な入力ではない	公式(出典 1)
「ref 42 をクリック」	要素を参照で指定する	再構成(出典 9)
画像で押す操作の残存	要素が見つからないページ用	再構成(出典 9)
visual_browser_screenshot_guard	ブラウザの画面の画像を検査する分類器が存在する。画像が処理される経路がある	観測(出典 8)
muse.visual_grounding	画像の中の物体の位置、ラベル、数を出す、常時使える機能(領域、点、数)。ブラウザの操作で使われるかは、定義から分からない	観測(出典 7)

結論として、主な経路は、アクセシビリティ木のテキストを LLM が読む形で、VLM が毎手の判断の中心ではない、と読める。画像の経路は、補助としてあり、どの程度使われるかは、確かめられていない。筆者が以前に予想した、VLM か、HTML の構造を LLM が読むか、のうち、HTML の生の構造は渡されず、画像も主ではない、というのが、公式の説明である。

7.4 ラベルと DOM の対応づけ

アクセシビリティ木は、LLM が中身を理解するための、ラベルとして使われる。実際の DOM(ページの実体)は、ブローカーが、ラベルとの対応表として持つ。エージェントは、「購入ボタンを押そう」とラベルの世界で判断して、参照の番号で指示し、実体への変換は、ブローカーが機械的に行う(図 14)。

図 14: アクセシビリティ木のラベルと、実際の DOM の対応づけ。上から、LLM が見る世界、ブローカーが持つ対応、ページの実体。矢印の ①〜④ は処理の順

表 16: 誰が何を見て、何を決めるか

担当	見るもの	決めること
LLM(ブラウザのサブエージェント)	ラベルの木(参照の番号、役割、名前)だけ。DOM も座標も見ない	何を押すかの意図の判断。参照を指定する
ブローカー(セルの外)	参照と、DOM の要素の識別番号(backendDOMNodeId)の対応表	参照を実際の要素に解決する。位置を決める。CDP で操作を送る
同意の判定	操作の種類(購入、ログイン、認証コードの入力など)	承認が要るか。LLM の判断とは別

処理の順は、次のとおりである。

1. ブラウザが、DOM から、アクセシビリティ木を作る。各ノードは、元になった DOM の要素の識別番号(backendDOMNodeId)を持つ(CDP の Accessibility ドメインの一般的な仕組み。一般の知識で、公式の仕様のページは取得していない)
2. ブローカーが、木の写しを取り、ノードごとに参照(ref 42 など)を振って、対応表を作る。LLM には、参照、役割、名前だけを渡す
3. LLM が、「ref 42 をクリック」と指定する
4. ブローカーが、対応表から識別番号を引き、DOM.resolveNode で要素に解決する。画面の中にスクロールして、DOM.getBoxModel で座標を得て、同意の判定と直前の確認を経て、CDP の Input.dispatchMouseEvent で、中心の座標をクリックする

Muse については、Peter James が、実行ファイルの文字列から、AxSnapshot(木の写しを取る)、AxResolve(参照を要素に解決する)、AxRead(内容を読む)という名前の部品と、解決した要素が期待した領域にあるかを確かめる expected_content_quad という名前を見つけた(再構成。出典 9)。上の ①〜④ の、どの API を、どの順で呼ぶかの細部は、名前からの再構成で、確かめていない。

この仕組みには、次の性質がある。

• ラベルは、ページの作り手が決める。ボタンの名前が「購入する」でも、そのボタンが、本当に購入の処理を行うかは、ラベルからは保証されない。悪意のあるページが、別の動作のボタンに、「購入する」と名前を付けることも、理屈の上ではありうる(筆者の考え)
• 買うかどうかの最終の判断は、LLM に任せていない。購入の承認は、財布の側の別の承認で、決済のボタンは、支払いの経路ではない、と道具の定義にある(観測。出典 7)。LLM が「押す」と決めても、確認は、ブローカーと承認の仕組みが受け持つ。これは、断る判断をモデルに頼らず、境界をモデルの外に置く、という設計のブラウザ版である
• 木に出ない要素(名前の無いアイコン、canvas の中の描画)は、対応づけるものが無い。画像で押す操作が、補助として残る理由と考えられる(再構成。出典 9)
• 木を取ってからクリックするまでに、ページが変わることがある。識別番号が古くなるため、解決のときと、操作の直前に、確認が要る。expected_content_quad は、このための確認と考えられる(筆者の読み)
• 要素が別の要素の下に隠れていると、座標をクリックしても、上の要素に当たる。iframe や Shadow DOM では、対応づけが複雑になる(一般の知識)

7.5 同意と、ブロックの扱い

• ブラウザの通常のフォームの送信は、現在、既定で許可され、承認を求めない。ログイン、購入、投稿のような、状態を変える操作には承認が要る(Futuresociety の引用。出典 10)
• 購入は、ブラウザのタスクが、決済の直前の確認まで進めて止まり、財布の承認が、最後の購入の確認になる。決済のボタンは、支払いの経路ではない(観測。出典 7)
• 認証コードは、不透明な参照として扱い、入力には、毎回、新しい 1 回限りの承認が要る(観測。出典 7)
• CAPTCHA の扱いは、利用者の設定(解く、利用者が引き継ぐ、確認する)で、サイトや作業ごとに保存される。1 回限りの許可は、1 回限りである。壁に当たったときは、ライブのブラウザの引き継ぎを申し出る(観測。出典 7)
• 429 などの流量制限は、その提供者に対して、作業の中の、これ以上の再試行を止める合図として扱う(観測。出典 7)

7.6 手数と時間の測り方

list_tasks と peek_task が、手数と時刻を返すという定義から、筆者の試行(出典 18)の遅さを、次のように測れる可能性がある。

• 1 つのブラウザの作業の、作成から完了までの全体の時間と、手数の合計を、Muse に、原文のまま出してもらう。1 手あたりの平均は、この 2 つから出せる
• 手数が多い予約の流れと、手数が少ない検索で、比べる

ただし、道具を呼ぶのは、エージェント本体である。出力は、Muse 自身の整形ではなく、返された値の原文で確認する。これらの値が、利用者の画面にも出る形かは、確かめていない。

8 外部通信とコネクタ

ブラウザ以外の外への通信と、コネクタの実体を扱う。

8.1 ブラウザ以外の外部通信

図 15: 実行セルから外へ出る経路。①〜④ は Sentinel を通る。⑤〜⑦ は、道具の名前からの筆者の整理で、実行される場所は確かめていない

表 17: 外部通信の経路

経路	内容	区分
コネクタの CLI	スキルが使い方を示し、CLI を、道具ごとに別の権限のワーカーが実行する。/run/hatch/privsep に約 60	観測(出典 8)
外への HTTP(S)	curl、requests、wget、Git など。強制的に egress のプロキシを通り、プラットフォームの CA が配られる。セルの DNS は、直接の外への通信ができないよう、意図的に無効	観測(出典 7)
ブラウザのブローカー	CDP の接続の管理。Sentinel の判定を通る	公式(出典 1)
推論とテレメトリの中継	中核の LLM への、制約された経路	公式(出典 1)
サーバー側の道具(と思われる)	browser.search、browser.open(ページの文字)、shopping(商品の検索)、social(SNS の検索)、map(地図)、深い調査	道具の名前からの整理。実行される場所は未確認
財布(wallet)	list_providers から connect_provider、決済手段の一覧。接続も一覧も、支払いの許可ではなく、支払いの承認は、決済の画面で別に出る。カード番号は、会話で扱わない	観測(出典 7)
通信の経路	channel(メッセージの経路)、device(つないだ端末)、電話の代行	道具の名前から

スキルにも道が無いとき、エージェントは、設定画面や連携の手順を勝手に作らず、スキルのファイル、公開 API、ブラウザ、コードを書く、という実際の経路で続ける。それでも詰まったら、利用者に戻る、と指示されている(観測。出典 7)。

エージェント自身が、新しいスキルを作る道もある。スキルが見つからなければ、シェルとブラウザの検索で、必要なものを探し、導入するか作り、試して、再利用できるなら、skill_creator で作業領域のスキルとして保存する(観測。出典 7)。

8.2 コネクタは MCP か

主要なコネクタの実装の経路は、MCP ではなく、CLI と権限分離のワーカーだと観測されている。MCP の併用の可能性は、確かめられていない。

• Adwankar は、Muse のツールは、Instinct と同じく、MCP のサーバーではなく CLI だと書く。Instinct と違い、Muse のツールは仮想マシンの上で動き、それぞれが、別の権限のワーカー(spawnd ensure-worker-accounts が、ツールごとに hatch-w-<ツール名> の利用者を作る)として動く(観測。出典 8)
• 同じ著者が、実行ファイルの文字列を、langgraph、langchain、rmcp、modelcontextprotocol で検索して、0 件だった。文字列が見つからないことは、Muse の内部のどこにも MCP の実装が無いことの証明にはならない。LLM のクライアントとして、複数のモデルを 1 つの口で扱う genai という部品を使っていることは、確認されている(観測。出典 8)
• /run/hatch/privsep の一覧には、healthkit-cli、instagram-cli、outlook-mail、peloton、philips-hue、places、plaid、printify、spotify-api、stripe-link、tailscale、tessie-api、threads-cli、ticketmaster、tts などが並ぶ(観測。出典 8。一覧の一部)
• 仮想マシンが見るツールとスキルは、配信のチャンネルごとに、設定ファイル(skill-scopes.conf)で絞られる。その一覧に、ads_mcp という名前のスキルがある(観測。出典 8)。名前に MCP を含むが、Muse のコネクタが MCP で動くことを示すものではなく、このスキルの中身は、確かめていない

Meta の技術記事は、セルの中の CLI が、型つきの引数を解析して、権限分離のワーカーに渡す、と説明している(公式。出典1)。

つまり、Muse のコネクタは、スキル(使い方の説明)と、CLI(実際の呼び出し)と、権限分離のワーカー(実行)の組として観測され、MCP の上に載っている証拠は見つかっていない。ほかの経路で MCP を併用している可能性は、確かめられていない。コネクタの追加は、API か CLI のある外部サービスについて、利用者や開発者が作れる、と Meta は説明している(出典17)。

9 先行する設計と学術の文献

Muse に先行する実装と、関連する学術の文献を並べ、対応を整理する。対応は、筆者が構成の類似から読んだもので、設計の因果を示すものではない。

9.1 OpenClaw

OpenClaw のドキュメントによると、エージェントの作業領域は、AGENTS.md(操作の指示とメモリの使い方)、SOUL.md(人格、口調、境界)、USER.md(利用者の情報)、HEARTBEAT.md(heartbeat の短いチェックリスト)、MEMORY.md(長期の記憶)、memory/YYYY-MM-DD.md(日付ごとの記録)で構成される(出典 19)。heartbeat は、既定で 30 分ごとに動く。現在のドキュメントでは、heartbeat が、通常の「自動化のジョブ」に置き換えられており、最初の設定で、30 分ごとの「先回りの確認」のジョブが 1 つ作られる(出典 20)。

Muse の構成と、一致する点が多い。

表 18: OpenClaw と Muse の対応

OpenClaw	Muse(観測)
AGENTS.md、SOUL.md、USER.md、MEMORY.md、memory/ の日付の記録	同じ名前のファイルが、Kuehn と Adwankar の観測にある(出典 7、8)
HEARTBEAT.md と、30 分ごとの heartbeat	30 分ごとの heartbeat と、HEARTBEAT.md が空なら推論を始めない(出典 7)
空のチェックリストのときは、実行をスキップ	同じ動き(出典 7)。ただし OpenClaw の現在の仕様は、チェックリストが明示的に空のときだけスキップ(出典 20)
通知は、利用者のメッセージに届く	通知は、作られたチャットに届く

Muse の設計が、OpenClaw の作業領域の考え方を引き継いだか、同じ着想から別に作ったかは、確かめられない。Meta は、どちらも述べていない。

OpenClaw のリポジトリのライセンスは MIT である(出典 29。確認日 2026-10-24)。SOUL.md の最初の行が同一であることについて、帰属表示の要否が論点になりうるが、Muse 側の表示や契約は確かめていない。

違いもある。OpenClaw は、利用者の環境で動く、自分で運用する仕組みで、利用者ごとの仮想マシン、Sentinel のような許可の仕組み、PostgreSQL の索引は、Muse の製品としての追加部分に見える。

9.2 ほかの先回りするエージェント

Grok Bot の公式のドキュメントには、Bot が自分で必要を見つけて動く記述が見つからず、定期の仕事は、利用者が設定するルーチンである、と読める(出典 21)。Dots には、利用者の指示なしに、接続したアプリを読み取り専用で調べて、メモを残す先回りの調査が、公式のヘルプにある(出典 21)。Muse の公式の説明、予定と関連する出来事に応じて動く、結果を出す価値を評価する、は、この 2 つの中間に位置するが、仕組みの詳細は、公開されていない。

9.3 関連する学術の文献

表 19: 関連する学術の文献。いずれも、arXiv のページで題名、著者、日付を確かめた

文献	内容	Muse との関係
Yaxi Lu ほか(15 名), "Proactive Agent: Shifting LLM Agents from Reactive Responses to Active Assistance", arXiv:2410.12361, 2024(ICLR 2025 の論文集に掲載。arXiv のページには掲載先の記載がなく、論文集のページは検索結果で確認)(出典 22)	人の実際の活動から、先回りの提案の候補を作り、採用か却下かを注釈して、報酬モデルで評価する。ProactiveBench には 6,790 件の出来事がある	先回りを、反応的なエージェントとの違いとして定義する。Muse の類型 C と D の評価の枠組みに使える
Yuanbo Tang ほか, "ProAgentBench: Evaluating LLM Agents for Proactive Assistance with Real-World Data", arXiv:2602.04482, 2026(出典 23)	先回りの支援を、介入のタイミングの予測と、支援の内容の生成に分ける。500 時間以上の実利用から、28,000 件超の出来事を集めた。長期の記憶と過去の文脈が、予測の精度を高めると報告	「いつ知らせるか」と「何を知らせるか」を分ける考え方が、Muse の「結果を出す価値の評価」に対応する
Charles Packer ほか, "MemGPT: Towards LLMs as Operating Systems", arXiv:2310.08560, 2023(出典 24)	文脈の窓の限りを、記憶の階層で補う「仮想的な文脈管理」	Muse の、standing ファイルと、検索で引く記憶の二層に通じる
Joon Sung Park ほか, "Generative Agents: Interactive Simulacra of Human Behavior", arXiv:2304.03442, 2023(出典 25)	経験を自然言語で保存し、振り返りで高次の記憶に統合し、計画に使う	Muse の夜間の振り返り(Dreaming)と、記憶の整理の発想に近い
Prateek Chhikara ほか, "Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory", arXiv:2504.19413, 2025(出典 26)	会話から重要な情報を、抽出、統合、検索する記憶の仕組み	Muse の記憶の抽出と検索の比較対象(4.5 節)
Edoardo Debenedetti ほか, "Defeating Prompt Injections by Design"(CaMeL), arXiv:2503.18813, 2025(出典 27)	LLM の外側に保護の層を置き、制御の流れとデータの流れを分け、機能の仕組みで、許可されないデータの流れによる流出を防ぐ	Muse の、セルの外の Sentinel、データを読んだプロセスに印を付ける「汚れた送信」と、考え方が近い
Luca Beurer-Kellner ほか, "Design Patterns for Securing LLM Agents against Prompt Injections", arXiv:2506.08837, 2025(出典 28)	プロンプトインジェクションに論理的に耐える、エージェントの設計パターン群	同上

Meta は、これらの文献のどれを土台にしたかを述べていない。対応は、筆者が構成の類似から読んだもので、設計の因果を示すものではない。

10 コストの見積もり

この節は、計算上の例で、Muse の実測ではない。

初回に、メールを全件、意味で走査する場合を考える。100 通/日 × 30 日 × 1 通あたり 1,000 トークン = 300 万入力トークン/利用者になる。利用者数 U、通数 N、1 通のトークン数 L、LLM で評価する割合 p、付加する文脈 C とおくと、全件の走査は U × N × (L + C)、候補を絞った走査は U × N × p × (L + C) になる。U = 100 万、N = 3,000、L = 1,000、C = 0 なら、全件で 3 兆入力トークンである。出力、推論、複数の段階、API と検索の費用は、これに加わる。

日本の有料プランのうち、パワーが週 5 億トークンという、筆者がアプリの画面で確認した値(出典 18)と並べると、300 万トークンは、その 0.6% にあたる。ただし、画面の表示のトークンが、推論の入力のトークンと同じ数え方かは、確かめていない。1 人あたりの初回の走査としては収まる量だが、利用者の数を掛けると大きい。

ここでの論点は、過去のメールを毎回読み直すことではない。メモリも目標も空で、メールの閲覧権限だけがある状態で、初回に 1 度だけ広く走査する場合でも、探索の対象が限られていなければ、意味の判断の費用が大きい、ということである。上の 300 万トークンは、1 日 100 通、1 通 1,000 トークンという仮定の値である。現実には、Gmail の検索、メタデータ、ヘッダー、既存の分類器、埋め込み、小型のモデル、あらかじめ定義したカテゴリで、候補を狭められる。その代償は、未知のカテゴリの取りこぼしである。Muse が実際にどの方式で処理しているかは、確かめられていない。また、メールにアクセスできることと、メールの全件を意味で探索する製品の方針があることは、別のことである。

費用の設計には、3 つの型がある。定義済みのカテゴリに絞る型は安いが、定義の外の重要事項を見逃す。汎用の探索の型は、広く見つけられるが、初回の負荷が大きい。LLM が監視の規則を作り、あとは差分を軽く調べる型は、最初の理解に重い推論を使い、あとは起動を減らす。ただし、新しい種類の重要性を見つけるには、別の探索のきっかけが要る。候補を絞ることは、計算量を減らすと同時に、探索できる範囲も削る。何を捨ててよいかを決める段階が、すでに価値判断である。

LLM の呼び出しの回数は、利用者の発言、cron によるエージェントの起動、条件が成立した hooks、記憶のジョブ、フィードとフォローアップ、道具のあとの継続、ブラウザのサブエージェント、再試行の合計として分けて考えられる。1 回の起動から、複数の呼び出しが出ることも、段階が必ず 1 回の呼び出しとは限らないことにも注意する。

11 中心の問いに対する証拠の整理

中心の問いは、利用者の会話もメモリも目標も空で、メールだけがつながっているとき、最初の探索の範囲を誰が決めるか、である。

表 20: 中心の問いに関わる証拠

証拠	区分	この問いへの影響
先回りの手紙は、目標から作られる(Kuehn、道具の定義)	観測	目標が探索の範囲を作る経路が存在する。空の初期状態は説明しない
escalation は、利用者が述べた条件に限り、推測で作らない(同上)	観測	期日未達時の対応の設定に限った制約。hooks、目標の生成、初期の探索の全体に及ぶかは未確認で、補助的な状況証拠にとどまる
cron は、作られたチャットに届け、何を届けるかはワーカーが決める(同上)	観測	実行のたびに、届けるかの判断がある
hooks は、条件が成立したときだけエージェントを起こし、本体に知らせるかをワーカーが決める(同上)	観測	軽い判定のあとに、もう 1 段の判断がある
heartbeat が空なら、推論を始めない(Kuehn)	観測	既定で、LLM を常時回しているわけではない
初期のアカウントで、買い物に関する自己改善のジョブが毎時動き、サブエージェントを 1 つ起動して「不足」で終わった(Futuresociety の指摘 template-bugs の引用)	再構成。データ内の引用で確認(原ファイルは未検証)	製品が管理するジョブが、初期状態でも動きうる、と示唆する。メールの全件走査ではない
6 時間の選別、毎時の記憶の抽出、毎晩の Dreaming、毎日の Studying の定義と、一部の実行例がある。Studying は、利用者が明示しなかった目標を提案することがある(Futuresociety の指摘の引用)	再構成。データ内の引用で確認(原ファイルは未検証)	製品が管理する定期ジョブが存在し、暗黙の目標の提案もしうると記述されている。実際に動くか、毎回モデルを呼ぶかは、引用からは分からない。会話もメモリも空の状態で、ジョブがメールをどう扱うかは、これらの引用からは分からない
公式: 予定と関連する出来事に応じて動き、結果を出す価値を評価する(設計記事)	公式	予定と出来事の両方で動く。条件の詳細は、書かれていない
メールの連携だけで、初回に何を、何件、どのモデルで調べるか	未確認	公開された証拠では、決められない

今回の読み直しで、5.5 節の 4 つの方式のうち、4 つ目(初期探索は存在しない、または利用者の目標と会話に限られる)を支持する証拠が、3 つ目を支持する証拠より多いことが分かった。以前に最有力としていた 3 つ目は、取り下げる。escalation の制約が観測されたが、これは期日未達時の対応に限った記述で、「会話から、利用者の言及のない監視を勝手に作る」方式の可能性を下げる補助的な状況証拠にとどまる。一方、Futuresociety の指摘の引用で、製品が管理する定期ジョブの定義と一部の実行例、Studying が暗黙の目標を提案しうるという記述が、データ内の引用で確認できた(原ファイルは未検証)。つまり、探索の範囲は、利用者が述べた条件と、製品の定期ジョブの両方で決まる可能性がある(筆者の読み)。メールだけがつながった初期状態で、内部ジョブが何を調べるかは、確かめられていない。

表 21: 初期探索の方式ごとの、支持する証拠と、支持しない証拠

方式	支持する証拠	支持しない証拠、未確認の点
1 固定のカテゴリを、静的な検索と分類器、少数の LLM で処理する	製品が管理する定期ジョブの定義、候補が無ければ nothing_to_do で終わる選別	メールに対して、そのような処理があるという記述は無い
2 広いメールの履歴を、LLM に読ませる	無い	計算量と初期の遅延が大きい(10 章)。記述も無い
3 許した範囲を、段階的に探索する	空のアカウントで買い物の自己改善のジョブが動いた例。Studying が、明示されない目標を提案しうる記述	メールを走査する証拠は無い
4 初期探索は存在しない、または目標と会話に限られる	フィードは接続したメールを材料にしない。6 時間の選別が読むのは、見える会話と FEEDBACK.md。先回りの手紙は目標から作られる。Studying は目標と会話が土台	取得した範囲に無いだけで、存在しないことの証明にならない

12 筆者の試行との対応

筆者が日本で試した結果(出典 18)と、ここまでの構成の対応を、次のように読む。

• 通知: Muse 自身は、設定した予定の時刻になると Muse が起動し、Gmail やカレンダーを確認して文章を作り、アプリが閉じているときにスマホへ通知として出すのは、システム側の仕組みだ、と説明した。cron による起動と、システムの通知の配信の分担という構成と、矛盾しない。ただし、Muse 自身の説明は、実装と違うことがある
• 頼んでいない提案: 映画の予約の話題の文脈から、関連する展示やトークショーの提案が、会話に届いた。表 11 のフォローアップの選別と整合するが、確かめていない
• ブラウザ: 作業中は、そのときの操作の名前と画面の縮小表示が出ていた。画面を見て 1 手ずつ判断するように見える、という筆者の印象は、公式の説明(アクセシビリティ木の写しを渡す)と並べると、読んでいるのは画像ではなく、ページの構造の要約だと考えられる(7.3 節)。1 手ごとに木を読み、操作し、新しい木を受け取る繰り返しなので、手数が多い予約ほど遅くなるという筆者の考えと、設計は合う。手数や状態を返す list_tasks と peek_task があることも、画面の表示と整合する。ただし、縮小表示がどの経路の画像かは確かめておらず、1 手の時間と手数は測っていないので、遅さの原因は切り分けられていない(7.6 節)
• メールの認証コード: 3D セキュアの認証のメールを、Muse が利用者の操作なしに拾って入力した。メールの連携は、1 回限りのコードをモデルから隠す、と公式は説明している。この 2 つは、Futuresocietyが採録した内部の文書で、つながる。文書には、利用者が頼んだサインインや決済の途中で、サイトが送られたばかりのコードを、接続したメールやメッセージで待っていると確認できたとき、エージェントは、利用者に頼まれなくても、保護された検索を行う、とある。コードは「不透明な参照」として扱い、モデルには見せず、入力には、改めての承認が要る(docs/privacy-and-credentials.md。図 16)。つまり、メールの連携がコードを隠すことと、決済のための保護された検索でコードを探すことは、別の経路である。筆者の試行で、入力が利用者の目に見える承認なしに進んだように見えた点は、文書の「改めての承認」との関係が、確かめられていない。考えられる説明は 2 つある。最初の決済の依頼への承認が、そのまま引き継がれた可能性と、Sentinel 側の別の画面で承認が出ていたが、筆者が気づかなかった可能性である(仮説)。確かめるには、支払いを伴わない手段が要り、現時点では未実施である

図 16: 決済で、サイトが認証コードを待つときの処理フロー(筆者の試行と、第三者が採録した内部の文書の記述の合成)

13 検証の実験案

次の実験は、筆者の判断で、まだ実施していない。条件は、実際のメール、他人の個人情報、実際のカードを使わないこと、自分が管理するテスト用のアカウントとデータだけを使うこと、承認や隔離の境界を回避しないこと、サービスの規約の範囲内で行うこと、である。支払いを伴う操作は、繰り返すとカードが止まるかもしれないと筆者が思うので、試さない。

表 22: 実験案

番号	実験	見るもの	確かめたいこと
E1	新しいアカウントで、メモリと目標が空、連携なし	活動のログ、最初の通知、内部のジョブの見える範囲	製品の固定のジョブの最小の集合
E2	テスト用のメールだけを連携し、何も頼まない	初回の動き、メモリと目標の変化、通知、許可の申請	初期の広い探索の有無(中心の問い)
E3	会話で「XX を重要視する」とだけ伝え、同じ種類のメールを届ける	監視の対象が、頼まなくても広がるか	対話による探索の範囲の拡大
E4	配送の監視を頼み、意味が同じで形の違うメールを届ける	hooks、cron、tracking の変化、実行のログ	規則の作成か、毎回の LLM の再判断か
E5	同じ外部のデータを、定刻、即時、更新なしで投入	提案の時刻の分布	6 時間の選別、フィード、cron、hooks のどれと整合するか
E6	ダミーの事実を保存して、忘れるよう指示し、次の定期の処理を待つ	派生した記憶の再生成	忘却の範囲
E7	既知と未知のカテゴリのメールを 10、100、1,000 件投入	準備から通知までの時間、操作の履歴の増加	未知のカテゴリの網羅と、費用の曲線
E8	低負荷で、非破壊の複数の作業を並列に頼む	子の終了、親の集約、再試行	回復の動き。大量の起動の試験は、他の利用者に影響しうるので、許可された環境以外では再現しない

推論の呼び出しの回数や、トークンの数は、内部のトレースへの許可されたアクセスが無ければ、推定したと断定しない。外から測れる時間だけで、LLM の呼び出しの回数は測れない。

手数と時間の測定(7.6 節)は、支払いを伴わない検索や予約の途中までの作業で試せる。支払いを伴う操作は、条件の外とする。

14 確かめられなかった点と、今後の調査の論点

14.1 未確認の点

未確認のうち、優先順位の高い 5 点は、次のとおりである。

1. 空のメモリ、空の目標で、メールの閲覧権限だけがあるとき、探索の範囲を誰が決め、どこで LLM を起動するか(最重要の問い)
2. 定期ジョブの実行の頻度と、モデルへの実際のリクエストの有無。すべての利用者で有効か
3. メモリ、目標、tracking、cron、hooks のうち、何が正本か。更新をまたぐ整合の取り方
4. 1 通の新着メールが、エージェントの起動につながる条件
5. escalation の制約が、hooks、目標の生成、初期の探索の全体に及ぶか

そのほかの未確認の点は、次のとおりである。

• 利用者の会話もメモリも空で、メールだけを連携したとき、最初に何が起動するか。初回のメール探索が、全件なのか、カテゴリによる検索なのか、特徴量だけなのか
• ブートストラップの規則が、製品のコード、スキル、プロンプトのどこに定義されているか
• 1 通の新着メールが、エージェントの起動につながる条件
• メールの分類と重要度の評価に、規則、小型のモデル、LLM のどれを使うか。6 時間の選別が、空の候補のときにもモデルを使うか
• 会話から、hooks、cron、tracking を自動で登録するか、明示の許可が要るか
• フィード、アイデア、プロアクティブなメッセージの候補の共通化と、重複の抑制
• 製品のジョブごとの LLM の経路、トークンの数、遅延。6 時間の選別が、小型のモデルか大きな LLM か。nothing_to_do を呼ぶ前に、モデルが毎回動くか
• 日本版と北米版の実行環境とコネクタの差。Muse Wonder への切り替えと、プロアクティブの制御の関係
• 認証コードの入力に、利用者に見える承認があったか。内部の文書にある「改めての承認」が、筆者の試行で、どの形で現れたか(12 章)
• 仮想マシンの資源(2 vCPU、約 7.7 GiB)が、すべてのプランに共通か
• 第三者の解析は、1 つの環境、特定の日付のもので、現在の版や日本版に当てはまるかは、確かめられない
• Codex SDK、OpenAI の Agents API との比較
• 記憶の検索が、毎ターンの推論の前に自動で動くか
• 画像で押す操作(VLM)が、どの程度、どの条件で使われるか。muse.visual_grounding が、ブラウザの操作で使われるか
• サーバー側の道具(shopping、social、map、browser.search)が、実行される場所と、通信の経路
• ads_mcp という名前のスキルの中身
• list_tasks と peek_task の値を、実際に取得できるか

14.2 取得できなかった文献と、次の調査

• Futuresociety の個別の指摘: ページ本体には含まれず、report_data.json から取得して、47 件を確認した(1.6 節)。ジョブのプロンプトの原文の全体(システムプロンプト)は、解析自身も取得できておらず、規則が別に存在する可能性がある
• Kuehn の付録 A と B(プロンプトの抜粋)。取得した本文に含まれていなかった
• Meta の Muse for Productivity のページの本文、The Verge の記事
• OpenAI の ChatGPT Pulse の公式のページ(取得できなかった)。Dots は、出典 21 の記事が引く公式のヘルプによる
• Codex SDK、OpenAI の Agents API の公式の資料
• OpenClaw の旧 heartbeat の仕様(HEARTBEAT.md の空のときの扱い)の、現在のドキュメントとの差
• 追加の調査の候補は、Kuehn の付録のプロンプトの原文、6 時間の選別の道具 conversation_follow_up の定義(モデルが呼ぶか)

14.3 今後の調査の論点

以下は、これからの調査の論点であり、現時点の結果ではない。

• 初期の規則の実体: 空のメモリ、空の目標で、サービスの連携だけを許可したとき、探索の対象を設定するのは、固定の規則、最初のシステムプロンプト、スキル、LLM による探索、何も起動しない、のどれか
• メモリとタスクの整合: 更新をまたぐトランザクション、二重の登録、失敗したときの再試行、取り消し、完了したときの監視の解除
• LLM の呼び出しの会計: 起動の出来事、軽い判定、LLM、道具、LLM、通知の判定の連なりのうち、実測で分かる範囲。通知のない周期にも推論したか
• 競合: cron の重複した起動、複数のサブエージェントからの目標の更新、仮想マシンの入れ替え時に進行中だったジョブの扱い
• プライバシー: メモリの編集と忘却が、会話の記録、派生した索引、通知の候補の再生成と、整合するか

15 設計への示唆

エージェントを設計する立場から見た、観察の使いどころを挙げる。いずれも、観察された構成についての筆者の考えで、Muse の設計者の意図を述べるものではない。

• 資格情報の本物を、実行セルの外に置き、セルの中には代理のトークンだけを置く(3.5 節。公式)。エージェントが操られても、本物の資格情報を持ち出されにくい。代わりに、外の部品が、承認、判定、秘密の保管という責務を負う
• ブラウザの判断と実行と承認を分ける(7.4 節)。LLM はラベルだけを見て意図を述べ、位置の解決と操作はブローカーが行い、購入やログインの承認は、LLM の判断の外に置く。ラベルが実際の動作と一致する保証が無い点は、設計の弱点として残る
• 記憶の中心を、人が読める Markdown に置き、検索の索引をデータベースに置く(4.4 節)。人が見て直せ、行番号で根拠を示せる。一方、データベースが記憶の状態も持つため、正本と整合の取り方は、設計で決めておく必要がある
• 軽い判定を、推論の前に置く(5.2 節)。heartbeat は、点検の項目が空なら推論を始めない。すべての内部ジョブが同じ軽い判定を通るかは、未確認である
• 予定や見張りを、目標に結び付ける(5.4 節)。目標を持ち主にすると、目標が終わったときに、予定と見張りも整理しやすいと考えられる(筆者の考え)。会話から自動で作るかは、未確認である
• 先回りの機能を増やすと、推論の費用より、サブエージェントの生成、データベースのロックの競合、再開、結果の集約、通知の取りこぼしが問題になりうる(6.6 節。Cygankiewicz の試験は、1 条件 1 回で、原因は特定されていない)
• 「忘れて」の範囲を、設計に含める(4.7 節)。記憶のメモを直しても、会話の記録や派生した索引が残るため、忘却の対象と範囲を、先に決めておく必要がある

出典

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

1. Tarek Sheasha (Meta Superintelligence Labs), "How We Built Safety Into Muse", 2026-09-08. https://research.meta.ai/blog/security-and-safety-for-ai-agents-our-approach-with-muse
2. Meta, "Introducing Muse: The World's First Personal AI Agent Built for Everyone", 2026-09-08. https://about.fb.com/news/2026/09/introducing-muse-personal-ai-agent/
3. Meta, 「Meta、パーソナルAIエージェント『Muse』を日本で提供開始」, 2026-10-23. https://about.fb.com/ja/news/2026/10/muse-personal-ai-agent-launches-in-japan/
4. Mona Sarantakos ほか (Meta), "How We Designed Muse", 2026-09. https://introducing.muse.ai/
5. Meta, "Muse Wonder: A Frontier Model For Personal & Professional AI Agents", 2026-10-12. https://research.meta.ai/blog/muse-wonder
6. Meta, "Muse for Productivity: Email, Calendar, and Files". 本文を取得できず、確かめられなかった。 https://ai.meta.com/muse/productivity/
7. Jules Kuehn, "Muse Agent Architecture: An Interface Tour", 2026-09-24 の観測(Gist は 2026-10-08 作成)。全体(約 42 万字)を取得して読んだ。付録 A と B は取得した本文に含まれていなかった。 https://gist.github.com/juleskuehn/480139a0ea9509e9b085459a045e03dd
8. Rohan Adwankar, "What's in a Muse?". https://rohanadwankar.github.io/posts/sandbox2.html
9. Peter James, "Inside Muse's browser stack", 2026-09-28. https://mouse.dev/blog/muse-browser
10. Futuresociety, "Muse, in its own files", 2026-09-26(AI で生成されたレポートと自ら断っている)。指摘のデータは https://futuresociety.ch/muse-findings/report_data.json から取得した。 https://futuresociety.ch/muse-findings/
11. Cygankiewicz, "I stress-tested Meta Muse until its agent control plane started timing out", 2026-09-13. https://blog.cygankiewicz.com/en/meta-muse-black-box-testing/
12. mahdi-salmanzade, "meta-muse-teardown"(macOS、Android、iOS の静的解析)。 https://github.com/mahdi-salmanzade/meta-muse-teardown
13. The Verge, "Muse will apparently let you download its entire filesystem", 2026-09-24. 取得できず、確かめられなかった。 https://www.theverge.com/ai-artificial-intelligence/1000222/meta-muse-ai-filesystem
14. Mem0, "Memory Evaluation"(Platform v3 の構造)。 https://github.com/mem0ai/mem0/blob/main/docs/core-concepts/memory-evaluation.mdx
15. LangMem, "Conceptual Guide". https://github.com/langchain-ai/langmem/blob/main/docs/docs/concepts/conceptual_guide.md
16. Anthropic, "Agent SDK overview". https://code.claude.com/docs/en/agent-sdk/overview
17. 筆者, 「Muse の使われ方と安全設計」(Qiita). https://qiita.com/hisashi-ito/items/ffe164ae4aa88abb293e
18. 筆者, 「日本で始まった Meta の Muse を早速試した！」(Qiita), 2026-10-23. https://qiita.com/hisashi-ito/items/c212e2d34c4b5d3c47fe
19. OpenClaw, "Agent workspace"(作業領域のファイルの構成)。 https://docs.openclaw.ai/concepts/agent-workspace.md
20. OpenClaw, "Heartbeat"(自動化のジョブへの置き換え後の仕様)。 https://docs.openclaw.ai/gateway/heartbeat
21. xAI, "Grok Bot" のドキュメント(skills-routines-and-automations ほか). https://docs.x.ai/grok-bot/skills-routines-and-automations と、Search Engine Journal, 2026-09-30(OpenAI のヘルプセンターの記述を引く記事). https://www.searchenginejournal.com/openai-dots-read-only-proactive-research/591565/
22. Yaxi Lu, Shenzhi Yang ほか, "Proactive Agent: Shifting LLM Agents from Reactive Responses to Active Assistance", 2024-10(v3 は 2024-12). arXiv:2410.12361. https://arxiv.org/abs/2410.12361
23. Yuanbo Tang ほか, "ProAgentBench: Evaluating LLM Agents for Proactive Assistance with Real-World Data", 2026-02. arXiv:2602.04482. https://arxiv.org/abs/2602.04482
24. Charles Packer ほか, "MemGPT: Towards LLMs as Operating Systems", 2023-10. arXiv:2310.08560. https://arxiv.org/abs/2310.08560
25. Joon Sung Park ほか, "Generative Agents: Interactive Simulacra of Human Behavior", 2023-04. arXiv:2304.03442. https://arxiv.org/abs/2304.03442
26. Prateek Chhikara ほか, "Mem0: Building Production-Ready AI Agents with Scalable Long-Term Memory", 2025-04. arXiv:2504.19413. https://arxiv.org/abs/2504.19413
27. Edoardo Debenedetti ほか, "Defeating Prompt Injections by Design", 2025-03. arXiv:2503.18813. https://arxiv.org/abs/2503.18813
28. Luca Beurer-Kellner ほか, "Design Patterns for Securing LLM Agents against Prompt Injections", 2025-06. arXiv:2506.08837. https://arxiv.org/abs/2506.08837
29. OpenClaw, GitHub のリポジトリ(ライセンス: MIT). https://github.com/openclaw/openclaw