
- MetaがパーソナルエージェントMuseを発表
- 認証情報はMeta中央基盤でなくユーザー専用VMに保存
- バグバウンティを一般公開し最大30万ドルを提示
Metaが、個人向けの自律型AIエージェント「Muse」を発表した。同社の研究ブログによると、MuseはiOSアプリ・Androidアプリ・Web版のクライアントを備え、いずれもユーザー専用の仮想マシン(VM)に直接接続する仕組みになっている。単に質問に答えるチャットボットではなく、ユーザーに代わってサードパーティサービスを操作する「エージェント」として設計されている点が新しい。
このVMは、コードの実行や複数の作業を同時にこなせるだけの計算資源を持つ、隔離されたLinux環境だという。ユーザーとMuseはこの環境を共有し、接続した各サービスの認証情報もここに保存される。ブログはこの認証情報について、Metaの中央インフラではなくユーザーのVM内に保存されると明記している。サードパーティのサービスやInstagram・Facebookなど自社アプリ向けの初期コネクタはMetaが用意しており、それ以外のサービスについてもAPIやCLI(外部から操作するための接続口)さえあればMuseが自分でコネクタを書けるとしている。Meta AIチームは2026年初めからMuseを社内で開発・利用してきたといい、今回の発表はその社内利用から一般ユーザーへの公開に踏み出した動きにあたる。
この種のエージェントが仕事に入り込む先は、メール整理やスケジュール調整のような定型作業にとどまらない。会議の議事録作成や資料の下書きなど、これまで人が「録音や記録を見返しながら」進めていた作業を、エージェントが外部サービスと連携して直接片づけるようになる。エージェントに渡す前段として、録音を後からAIがテキスト化しておくと、何を指示したか・なぜその判断をしたかという経緯を人間側にも残せる。メモリス(AIボイスメモ)のように録音後にAIが文字起こし・要約を作る仕組みは、エージェントが処理した結果だけでなく、その根拠になったやり取りを手元に残す役割を担える。
Museの設計で目を引くのは、機能そのものより認証情報の扱いだ。ユーザーがどのサービスに何の権限を与えるかという「承認」の設計は、パーソナルエージェントが実際に使われるかどうかを左右する要になる。Museは「tainted egress」と呼ぶカーネルレベルのデータフロー追跡を使い、ユーザーデータを読み込んでいない「クリーン」な状態のプロセスからの通信であれば、限定的な自動許可ポリシーに合致する場合は承認を求めずに通す。逆にユーザーデータに触れた時点でそのプロセスは「汚染」された扱いになり、外部への通信には承認が必要になる。許可の与え方も1回限り・セッション単位・時間制限付き・永続的といった複数の粒度に対応しており、毎回の確認で疲弊させない工夫と、無制限の権限委譲を避ける歯止めを両立させようとしている。
外部サービスとつながる製品を作る側から見ると、機能の一覧より先に「認証情報をどこに、誰の管理下に置くか」が設計の土台を決めてしまう。Meta自身が中央インフラではなくユーザー専用VMに認証情報を置いた判断は、この土台を「ユーザー側」に寄せた選択にあたる。
とはいえ、この設計だけでプロンプトインジェクション(外部から与えられたデータに紛れた指示でエージェントを乗っ取る攻撃)が解消されるわけではない。その証拠に、Metaは非公開だったバグバウンティ制度を一般公開し、有効な報告には最大30万ドル、1ユーザーに影響するプロンプトインジェクション攻撃の成功報告には最大13万ドルという高額の報奨を設定した。攻撃者に高額を払ってでも脆弱性を見つけさせる姿勢は、裏を返せばエージェントが外部データを読み込んで行動する限り、この種の攻撃を設計だけで根絶できないとMeta自身が認めていることを示している。
それでも、VMによる隔離・認証情報の非中央保管・taint追跡による承認頻度の制御という3つの仕組みを組み合わせた設計は、評価に値する。攻撃を完全に防ぐことと、攻撃が成功した際の被害範囲をユーザー1人分に閉じ込めることは別の問題であり、Museの設計は後者に軸足を置いている。パーソナルエージェントが個人のメールやカレンダー、業務ツールに触れる以上、「防ぎきる」より「被害を局所化する」設計思想のほうが、実際に使われる製品としては現実的な選択と言える。Meta研究ブログが安全性の詳細を独立した節として公開していること自体、この分野で信頼を得るには機能訴求だけでなく設計の透明性が問われ始めている表れだろう。




