Meta Museは、AI業界がほとんど避けてきた問いに、驚くほど具体的な答えを示しています。パーソナルAIエージェントは、実際にはどこに存在するのか?
Metaの答えは「チャットアプリの中」ではありません。すべてのMuseには、ストレージ、メモリ、ブラウザー、ファイルシステム、バックグラウンドジョブ、独自のセキュリティ境界を備えた専用コンピューターがクラウド上に用意されます。これは重要です。ノートパソコンを閉じた後も作業を続けるエージェントには、強力なモデルだけでは不十分だからです。エージェントが持続的に存在できる場所が必要です。
Meta Museとは何か?どのように動作するのか?
Meta Museは、単に質問に答えるのではなく、作業を実行するよう設計されたパーソナルAIエージェントです。接続サービスを利用したり、承認を得たうえでメールを送信したり購入したり、ユーザーに関する情報を記憶したり、より長期的な目標に向けて作業したり、バックグラウンドでタスクを継続したりできます。
重要なのは、そのアーキテクチャです。Muse Sparkが推論モデルを提供する一方で、エージェント自体はMuse Secure VM上で動作します。このVMはユーザーのファイルと接続サービスのデータを保持し、Museにブラウザー、ツール、コンピューティングリソース、永続的な作業環境を提供します。
これにより、しばしば1つのものとして扱われる2つの概念が分けられます。推論するモデルと、エージェントが存在するコンピューターです。
Muse Secure VMとは何か?
MetaはMuse Secure VMを、各ユーザー向けの専用クラウドコンピューターと説明しています。これは独自のブラウザーを備えた隔離されたLinux仮想マシンで、コードのコンパイル、カスタムSkillの開発、複数のサブエージェントの同時実行、cronジョブの実行に十分なCPU、メモリ、ストレージを備えています。
VMは、ユーザーがMuseに入力した情報の基準となる記録システムでもあります。ファイル、永続的なアプリケーション状態、メモリ関連データ、接続サービスの認証情報は、1つのモデルとの会話内だけに存在するのではなく、この永続的な環境に保持されます。
これは大きなアーキテクチャの転換です。Museは、ユーザーのスマートフォンに別のアシスタントを組み込むというより、AIエージェントに専用のワークステーションを与えるものに近い存在です。
AIエージェントに専用コンピューターが必要なのはなぜか?
チャットボットは回答を返した後に消えても問題ありません。しかし、役に立つパーソナルエージェントはそうはいきません。イベントを待機したり、スケジュールされたタスクを実行したり、未完了の作業を保持したり、ファイルを保存したり、ユーザーが別の場所にいる間に複数のサブエージェントを連携させたりすることがあります。
これらのジョブには、ファイルシステム、プロセス実行、データベース、ネットワークアクセス、ログ、認証情報、永続状態といった一般的なコンピューティングインフラが必要です。基盤となるモデルに大きなコンテキストウィンドウを与えるだけでは、これらの問題は解決しません。
| チャットアシスタント | 常時稼働エージェント |
|---|---|
| プロンプトに回答する | 目標に向けて動作する |
| 一時セッション | 永続状態 |
| 会話履歴 | メモリ、ファイル、データベース |
| 即時アクションは少ない | ツール、スキル、コネクター |
| ユーザーは回答を待つ | バックグラウンドジョブが継続する |
| モデル中心 | ランタイム中心 |
Museから得られる大きな教訓は次のとおりです。常時稼働するAIエージェントは、サーバーワークロードになりつつあります。最先端モデルは別の場所で動作していても、エージェントの周囲には永続的なインフラが必要です。
Meta Museはバックグラウンドで作業を続けますか?
はい。Metaは、すべてのステップでアプリを開いたままにするのではなく、ユーザーが目標を与えるとMuseが作業を進められるよう設計しました。専用VMは、複数のサブエージェントやスケジュール設定されたcronジョブにも対応できます。
これにより、「パーソナルAI」の意味が変わります。タスクは会話から始まり、バックグラウンド処理として続行され、新しい情報を待ち、後で別のアクションを起動し、承認や判断が必要になったときだけユーザーに戻ることがあります。
この方式では、稼働時間が重要です。ユーザーのコンピューターが利用できないときでも、エージェントのコンピューターは利用可能でなければなりません。
Museはファイル、メモリ、エージェントの状態をどこに保存しますか?
Metaによると、ユーザー専用VMはMuseに保存されるすべての情報の基準となる記録システムとして機能します。永続的なアプリケーション状態はメインのエージェントランタイムセル外にあるPostgreSQLに保存され、ファイルやワークスペースデータは専用VM環境内に保持されます。
これは、モデルのコンテキストだけに全面的に依存するのとは異なります。モデルは古いトークンを忘れたり、会話を圧縮したり、新しいモデルに置き換えられたりする可能性があります。永続ファイルやデータベースは、そうした変更後も残ります。
この分離は、パーソナルエージェントにとって今後ますます重要になりそうです。推論は置き換え可能でも、永続的な状態まで置き換える必要はありません。
Museはパスワードと認証情報をどのように保護していますか?
Museは、使用する実際の認証情報を意図的に見られないよう設計されています。OAuthトークンなどの秘密情報は、エージェントのランタイムセル外にある独立した認証サービスによって保管され、認証情報を扱う操作は、より厳格に管理されたプロセスを介して実行されます。
ブラウザーも同じ原則に従います。ユーザーがパスワードを入力すると、そのパスワードは保護された認証情報ストレージへ直接保存され、後からメインのMuseエージェントに公開することなくブラウザーへ挿入できます。
これは、自律型エージェントが作業に必要なすべての秘密情報へ無制限にアクセスする必要はないという点で重要です。認証情報を使用する権限と、認証情報を読み取る権限は異なります。
Meta Muse Sentinelとは何ですか?
Metaは、Sentinelという第2のエージェントをMuseのメインランタイムの外部に配置しています。Sentinelはコネクター操作とネットワーク外向き通信の権限管理を担います。Museは操作を提案できますが、その操作が許可されていると自分だけで判断することはできません。
これにより、何をすべきかを推論することと実際に実行する権限を有意義に分離できます。Museが誤った判断をしても、機密性の高い操作は拒否するか、ユーザーに承認を求める形で差し戻すことができ、決定論的なシステム境界は維持されます。
これは、プロンプトインジェクションが依然として未解決の問題であるため、特に重要です。Webページ、ファイル、ツールの出力には悪意のある指示が含まれている可能性があるため、Metaはモデルが常に攻撃を認識すると決めつけず、外部データを潜在的に信頼できないものとして扱います。
Muse Secure VMは単なるサンドボックスですか?
単一のコンテナよりも多層的な構成です。各VM内では、Museのコアハーネス、ワークスペース、ツール、バイナリが systemd-nspawn ランタイムセル。セル内のrootは権限のないホストユーザーにマッピングされ、一方で危険なカーネル機能やシステムコールは制限されます。
セキュリティ上重要なコンポーネントはランタイムセルの外部に配置されています。認証情報の保存、コネクターの実行、安全性分類器、Sentinel、永続的なPostgreSQL状態、ネットワークプロキシは分離されているため、メインエージェントが侵害されても、すべての保護機構を自動的に制御できるわけではありません。
Metaはこの設計をうまく要約しています。適切な捉え方は、無制限のrootアクセス権を持つAIエージェントではなく、1台のマシン上にある2つの分離されたセキュリティドメインです。
MetaはMuse Secure VM内のデータにアクセスできますか?
ローンチ時点でSecure VMが利用可能であれば、状況によっては可能です。Metaは運用ポリシーによって担当者のアクセスを制限していると説明していますが、現在のアーキテクチャでは、サービスのサポート、セキュリティ確保、運用に必要な場合にMetaがVM内のデータへアクセスすることを技術的には防いでいません。
この違いは重要です。他のユーザーからの分離とクラウドプロバイダーからの分離は、異なるプライバシー保証です。
Metaはまた、会話とVMデータは広告システムと共有されない一方、ユーザーがオプトアウトしない限り、推論の軌跡はサニタイズされたうえでモデルのトレーニングに使用される可能性があると述べています。これらは製品ポリシーであり、暗号学的な保証ではありません。
Muse Confidential VMとは?
Metaは2026年後半に、より強固なMuse Confidential VMを提供する計画です。目標は、Metaでさえ内部のデータにアクセスできないようVMを暗号化することであり、その設計は外部から監査可能になるよう意図されています。
これは、プライバシーに関する重要な階層を示しています:
| アーキテクチャ | インフラストラクチャを管理するのは誰か? | プロバイダーは技術的にデータへアクセスできるか? |
|---|---|---|
| 標準クラウドエージェント | クラウドプロバイダー | 通常は可能 |
| Muse Secure VM | Meta | 定義された条件下では可能 |
| Muse Confidential VM | Meta | アクセスを暗号学的に防止するよう設計 |
| セルフホスト型エージェントサーバー | ユーザー | 使用するサービスとモデル接続によって異なります |
したがって、「クラウド」と「プライベート」は正反対ではありません。本当の問題は、誰がマシンを管理するのか、誰が暗号化キーを管理するのか、何がマシンの外部に出るのか、そしてどのコンポーネントが信頼されているのかです。
ホームサーバーはMuse Secure VMの代替になるのか?
アーキテクチャ上、ホームサーバーは、オンライン状態の維持、ファイルの保持、データベースの実行、RAGインデックスのホスティング、エージェントのメモリ保存、コンテナの実行、自動化のスケジューリング、バックアップの維持など、同じような永続的ジョブの多くを実行できます。ただし、ホームサーバーが自動的にMuseを再現するわけではありません。
Museのセキュリティモデルには、ランタイム分離、認証情報の代理化、ネットワーク送信の制限、独立したポリシー適用、分類器、そして承認ゲートが含まれます。Dockerコンテナにホームディレクトリと複数のAPIキーへのアクセスを与えるだけでは、同等とはいえません。
ホームサーバーの利点は別のところにあります:永続層の所有権と管理権です。ユーザーは、ファイル、データベース、スキル、ログ、サービスをどこに置くか決めながら、最先端レベルの推論が必要な場合にはクラウドモデルを呼び出せます。
クラウドVMとホームサーバー:常時稼働エージェントはどこで動かすべきか?
選択の基準は、AIの生の性能というより、運用上の優先事項です。マネージドVMなら保守の負担がなく、セキュリティを製品と緊密に統合できます。ホームサーバーなら永続データやセルフホストサービスをより自由に管理できますが、分離、アップデート、バックアップ、アクセス方針についてはユーザーが責任を負うことになります。
| 要件 | マネージドセキュアVM | ホームサーバー |
|---|---|---|
| 24時間365日の可用性 | 非常に適している | 非常に適している |
| インフラの保守不要 | 非常に適している | 適合性が低い |
| ローカルファイルの所有権 | プロバイダー管理 | 非常に適している |
| カスタムのセルフホストサービス | プラットフォーム依存 | 非常に適している |
| 統合されたセキュリティ制御 | 非常に適している | ユーザー次第 |
| 最先端クラウドモデル | ネイティブ | リモート接続可能 |
クラウドとローカルのインフラを相反するものとして扱うよりも、最終的にはハイブリッドアーキテクチャのほうが実用的かもしれません。プライベートデータと永続的なサービスはユーザーが管理するインフラに置いたまま、選択したコンテキストだけを、推論の価値がトレードオフに見合う場合に最先端モデルへ送信できます。
常時稼働するAIエージェントに高性能GPUは必要か?
必ずしも必要ではありません。Muse自体が、「エージェントサーバー」と「推論サーバー」を同義語として扱うべきではない理由を明らかにしています。
| エージェントのワークロード | ローカルGPU要件 |
|---|---|
| ファイルストレージ | なし |
| PostgreSQLとメモリ | なし |
| Cronジョブ | なし |
| APIおよびMCPサービス | なし |
| スキルとスクリプト | 通常は不要 |
| RAGのストレージと検索 | 通常は不要または低い |
| 埋め込み | 任意のアクセラレーション |
| フロンティア規模のローカル推論 | 非常に高い可能性 |
エージェント・コンピューターに必要なのは、大規模な推論ハードウェアよりも先に、永続性です。メインの推論モデルがクラウド上にあっても、ストレージ、データベース、ネットワーク、オートメーション、稼働時間は役立ちます。
Meta MuseはパーソナルAIの未来について何を示しているのか?
MetaがMuseのために構築した最も興味深いものは、Muse Sparkではないのかもしれません。エージェント専用のコンピューターを与えるという決断なのかもしれません。
このアーキテクチャは、重要な事実を認めるものです。AIが質問に答える段階から、目標の維持、ツールの操作、記憶の保存、無人での作業へと移行すると、モデルは構成要素の1つにすぎなくなります。エージェントには、その状態やサービスを永続的に置いておく場所も必要です。
したがって、将来のパーソナルAIスタックは、交換可能な2つの層に分かれる可能性があります。推論エンジンとエージェント・コンピューターです。推論エンジンはMeta、OpenAI、Anthropic、またはローカルモデルになるかもしれません。永続的なコンピューターには、マネージドクラウドVM、個人所有のホームサーバー、あるいはその両方を組み合わせたハイブリッド構成を利用できます。
Museの答えは、Metaのクラウド上にある専用コンピューターです。より本質的で長く通用する教訓は、常時稼働するAIには、存在する場所が必要だということです。
よくある質問
Meta Museはローカルで実行されますか?
いいえ。MuseはMetaのクラウド内にある専用仮想マシンで実行されます。MuseアプリまたはWebインターフェースが、そのリモートエージェント環境に接続します。
Meta Museは常に実行されていますか?
Museはバックグラウンド処理や長時間実行される作業向けに設計されており、そのVMではスケジュールされたcronジョブや同時実行されるサブエージェントを実行できます。ただし、個々のタスクは権限、サービスの可用性、Museの実行ポリシーに左右されます。
Muse Secure VMは別の物理コンピューターですか?
いいえ。専用の仮想マシンです。つまり、ユーザーが受け取るのは専用の物理サーバーではなく、分離された仮想コンピューティング環境です。
Meta Museはメモリをどこに保存しますか?
Metaによると、専用VMがMuseのデータの正本です。永続的なアプリケーション状態はPostgreSQLに保存され、その他のファイルやワークスペースデータはユーザーのVM環境内に残ります。
MetaはMuse Secure VM内のデータを見ることができますか?
ローンチ版では、サービスの運用、サポート、セキュリティ確保に必要な場合にMetaがVM内のデータへアクセスすることを技術的に防止していません。Metaは、運用ポリシーによってアクセスを制限していると説明しています。計画中のConfidential VMは、Meta自身がデータを読み取れないよう暗号学的に防止することを目的としています。
Museは私のパスワードを見られますか?
Metaは、メインエージェントが実際のパスワードや接続サービスの認証情報を受け取らないようMuseを設計しました。秘密情報は別の認証情報ストレージに保管され、エージェントに直接公開されることなく、許可された操作に提供されます。
Muse Sentinelは何をしますか?
Sentinelは、コネクタの操作とネットワークアクセスを評価する独立した権限エージェントです。Museは操作を提案できますが、許可、拒否、ユーザー承認の要求のいずれにするかをSentinelが判断します。
個人用AIエージェントをホームサーバーで実行できますか?
はい。ホームサーバーでは、ファイル、データベース、メモリ、RAGシステム、Skills、ツール、オートメーション、バックアップなど、永続的なエージェントコンポーネントをホスティングできます。Museのようなマネージドシステムと同等の分離や認証情報保護を再現するには、追加のセキュリティエンジニアリングが必要です。
AIエージェントサーバーにはGPUが必要ですか?
多くのエージェントワークロードでは、そうとは限りません。ファイル、データベース、メモリ、オートメーション、APIサービス、RAGストレージ、ログ、バックアップは、強力なGPUなしでも実行できます。GPU要件は、サーバーがローカルAI推論も行うかどうかに主に左右されます。
ホームサーバーはMuse Secure VMよりプライバシーが高いですか?
ユーザーはインフラとデータをより強力に管理できますが、ローカルホスティングが自動的に安全またはプライベートになるわけではありません。権限、リモートアクセス、サードパーティAPI、クラウド推論、認証情報、バックアップ、ネットワーク構成によって、どのデータがサーバー外に出るかが決まります。
テック&AIハブ
もっと読む

秘密ブローカーは、プロンプトに認証情報を露出させずにAIエージェントへどのように認証情報を渡すのか?
シークレットレスなホームAIエージェントアーキテクチャを通じて、ワークロードID、ポリシー、トークン発行、リクエストインジェクション、編集、期限切れ、失効を追跡します。

ツールサンドボックスはAIエージェントの副作用をどのように封じ込めるのか?
隔離、機能ゲート、使い捨て状態、送信制御、クォータ、監査ログによって、アクションの安全性を証明することなくAIエージェントの副作用を制限する方法をご覧ください。

制約付きデコーディングはどのようにスキーマ準拠のJSONを生成するのか?
スキーマのコンパイル、トークンマスキング、パーサーの状態、サポートされるサブセット、レイテンシ、切り詰め、そして構造的な有効性が正しい値を保証しない理由を理解する。

