Meta Museの公開後、CNN、Yahoo Finance、The Verge、WIREDなどが実際の用事を任せて検証しました。引っ越し業者への連絡や旅行計画は進んだ一方で、閉店した店の推薦や架空の電話番号も報告されています。本稿では、これらの結果をAIエージェントを作る側のチェック項目に変換します。筆者自身がMuseを再検証した記録ではなく、末尾に挙げた公開レポートの整理です。
13件を「どこで失敗し得るか」で整理する
| タスク | 報告された結果 | 設計上の論点 |
|---|---|---|
| 引っ越し見積もり | 4社へ連絡し、2社から約2分以内に電話 | 複数社との連絡を継続できる |
| デートの予約 | 候補選定から予約まで進めた | 予約内容と日時の確認 |
| ファンタジーフットボール | 選手の入れ替えを実行 | アカウント内の書き込み権限 |
| 友人との旅行 | メールの返信を待ち、候補を文書化 | 非同期の状態管理 |
| 荷造り計画 | 制約付きの日程表を作成 | 入力条件と出力の照合 |
| Gmail整理 | 大量の販促メールを削除 | 削除対象と復旧手段 |
| 買い物 | カート内の別商品に気づき、確認した | 購入直前の差分確認 |
| レストラン検索 | 閉店済みの店を提案 | 外部データの鮮度 |
| ビールの販売店検索 | 閉店済みの店と架空の電話番号 | 連絡先の出典確認 |
| ジャケット購入 | 表示された割引が使えなかった | 価格・在庫の再取得 |
| Marketplaceの交渉 | 宣伝と異なり、送信用文面の作成まで | 実際の機能範囲の表示 |
| ベーカリーの注文 | 注文内容を作ったがチップを「なし」に設定 | 社会的判断の承認 |
| iCloudメール接続 | カスタムツールが保持されず再認証が必要 | 接続状態と秘密情報の扱い |
この表は各レポートの結果を短く要約したものです。成功・失敗を単一のスコアにはしません。データの鮮度、権限、実行結果は別々に検証する必要があります。
実装で分けたい4つのゲート
1. 検索結果を「行動可能な事実」に昇格させる前に検証する
レストランの住所、電話番号、営業時間、商品価格は変わります。エージェントが回答を生成しただけでは、その値は検証済みになりません。電話・予約・購入の前に、一次情報または現在の掲載ページを取得し、出典URL、取得時刻、確認できた項目を一緒に提示します。確認できない値は推測せず保留にします。
候補を検索 → 原典を開く → 住所・価格・連絡先を照合
→ 不一致なら再検索または人に確認 → 実行
Yahoo Financeの検証では、閉店した店を案内した後、Museが古いデータに頼ったと認めています。これはモデルの文章表現だけでなく、行動前の情報確認の問題です。
2. 「読む」と「書く」を別の権限にする
メールを要約する権限と、メールを送信する権限は異なります。最初は読み取り専用にし、送信・削除・購入は別の操作として許可する設計が妥当です。デスクトップエージェントなら、OS側のFull Disk Accessとアプリ内のMessagesコネクターも別々に監査します。
Inc.のJason Atenは、Messagesへのアクセスを断ったつもりだったのに、後で大量の履歴が同期されたと報告しました。Metaは両方の権限が必要と説明しています。公開情報だけで原因を断定せず、ユーザーに見える設定と実際のアクセスを一致させることを設計要件にします。
3. 副作用の承認画面には「全体」を見せる
「合計金額はこれでいいですか」だけでは足りません。商品、数量、配送先、チップ、受信者、送信文、キャンセル条件を確認できるようにします。WIREDのベーカリー注文では、Museがチップを「なし」にしました。合計額には表れない判断も、実行前レビューの対象です。
4. 実行ログと復旧経路を残す
エージェントのログには「何を提案したか」だけでなく、参照したページ、実際に呼んだツール、送信・削除・購入の結果を残します。取り消せる操作は復旧方法を示し、コネクターは切断できるようにします。Gmailの一括削除のような成功例でも、対象の確認と復旧手段があって初めて安心して任せられます。
最小の受け入れテスト
自分のエージェントに次の4つを試すと、境界が見えやすくなります。
- 数年前に閉店した店を候補データに混ぜ、原典確認で除外できるか。
- 電話番号の掲載がない店を渡し、番号を作らず「確認できない」と返せるか。
- 読み取り専用のメール接続で、送信ツールを呼べないか。
- 注文にチップやカート内の別商品があるとき、全明細を示して承認を待てるか。
これはMuseの内部実装を推測するテストではありません。外部のエージェントにも適用できる、ユーザーから見える受け入れ条件です。
まとめ
13件の検証では、AIエージェントが連絡や調整を進められる価値と、古い情報・広すぎる権限・承認不足のリスクが同時に見えました。実行能力を強めるほど、出典確認、権限の分離、行動前の承認、事後の監査を明示する必要があります。
BeatAPIでは、エージェントが行動前に公開Webやソーシャル情報を確認するためのMCP接続を提供しています。これは情報鮮度を改善する一層であり、権限管理や人による承認を代替するものではありません。設定例は BeatAPI MCP にあります。
参照したレポート
- Meta Newsroom：Museの紹介
- Yahoo Finance：Daniel Howleyによる実地検証
- CNN：Lisa Eadiciccoによる実地検証
- The Verge：Emma Rothによる実地検証
- WIRED：Reece Rogersによる実地検証
- Inc.：Jason AtenによるMessagesの報告
- Taylor Arndt：アクセシビリティとiCloud接続の検証
報告・機能・価格は2026年9月26日時点。13件の個別経緯と追加の出典は英語版の完全ガイドを参照してください。