AIに毎回説明し直さなくていい？
過去の会話を覚えて仕事を進める
「Muse Wonder」

会話を切り替えるたびに「誰向けか」「何を後回しにしたか」「なぜその判断をしたか」を書き直す。必要な文脈が渡らないと、AIの案を前提から直す作業が増えます。Muse Wonderで確かめたいのは、合意した前提を拾い、変更点から検討を再開できるかです。

架空案件の説明例 社内タスク管理の試作で、昨日は「招待限定・CSV出力は後回し・外部連携なし」と決定。今日、PMが「担当者を変更できるようにしたい」と伝えた場面を考えます。以下は期待する振る舞いの例で、実行結果ではありません。

開発元の説明 MetaはActive Memoryを、会話をまたぐ重要な文脈を持ち、今の課題に関連する詳細を取り出す能力として説明しています。[2] [3] PM・開発者の仕事なら、対象者・制約・以前の判断理由を、現在の変更要求と結び付ける使い方が考えられます。

モデルの文脈利用と、履歴を正しく保存・取り出す仕組みは別々に評価します。履歴が取得できなかった失敗を、すべてモデルの「忘却」にしないことが大切です。

開発元の説明 Active Focusは、難しい目標に対して別の手段を試し、障害を乗り越え、新しい情報に対応しながら取り組む能力です。必要な説明を求め、重要な操作の前には確認することも含めて説明されています。[2] [3]

1. 現在の目標を確認担当者変更を検討。招待限定と外部連携なしの前提を確認。
2. 案とテストを作る変更箇所と、既存の制約を守る試験を提案。
3. 失敗から案を更新試験が失敗したら原因を記録。別案や追加の確認を検討。
4. 重要操作で確認権限の変更・公開・外部送信は、範囲と承認を確認してから。

上の流れは編集部提案の業務例です。モデルが実装・試験・承認をすべて実行した記録ではありません。

Metaの評価にはFocusBenchとSWE-Marathonがあります。評価結果を、そのまま自社案件の完了率や作業時間に換算しません。[7]

公式提供情報 / 2026-10-13確認 名前が似ていても、使えるモデルと提供経路は同じではありません。10月12日の発表と現行ドキュメントでは次の範囲です。

Active Memoryという名称から、無期限の保存や完全な想起は保証されません。モデルカードも誤った回答や複数段階の推論の失敗、言語・ツール・実行構成による性能差を挙げています。[7]

引き継ぎに使う記録が増えるほど、誤りの訂正、削除の反映、参照範囲、送信の承認を確かめる必要があります。以下は採用前の確認項目で、Wonder単体にすべて備わると確認した機能一覧ではありません。

Museのシステム設計 公式安全記事は、モデルとは別のSentinelがコネクター操作と外向き通信を許可・拒否・確認する設計を説明しています。これは一般向けMuseのシステムの説明で、Wonder APIに同じ仕組みが自動付属するという意味ではありません。[8] モデルカードも用途に合う追加の制御を推奨しています。[7]

評価計画 / 編集部提案・未実施 最初は架空の社内タスク管理を一つ用意し、現行手順と同じ仕様・変更要求で比べます。実在する顧客情報や秘密を使わず、履歴が渡る条件と渡らない条件を分けます。