2026/09/10AI業務効率化
AIエージェントセキュリティ料金・コスト比較

Meta Museとは|できること・料金・日本で使えるか

Meta Museとは|できること・料金・日本で使えるか

「AIが勝手にメールを送ったり、買い物をしたりして大丈夫なのか」——エージェント型のAIが実際にお金を動かし始めると、誰もがこの不安を抱えます。

結論から言うと、Metaが2026年9月8日(米国時間)に公開した個人向けAIエージェント「Muse」は、日本からはまだ使えません。提供は米国限定で、日本語版・日本提供の時期は公式に発表されていません。それでも見ておく価値があるのは、この製品が「エージェントに何を許すか」ではなく「承認する仕組みをエージェントの外側に置く」という作り方を、消費者向け製品の既定にしてきたからです。

株式会社Fyveは、中小企業のAI活用を月額で伴走する立場から、この手の新製品を「今すぐ使えるか」ではなく「自社の業務に入れるとき何を確認すべきか」の観点で読んでいます。私自身も無人で走るAIジョブを毎日運用しているので、本記事では公式発表と設計文書を突き合わせたうえで、実運用側から見た読みどころも添えます。

Meta Museとは|3行でわかる要点

Museは、Metaが2026年9月8日に発表した個人向けのAIエージェントです。質問に答えるだけのチャットAIではなく、実際に手を動かして作業を終わらせることを目的にしています。

  • 何をするか:メールの送信、旅行の予約、買い物の決済まで実行する。長期的な目標を渡すと計画に落として自分で進める
  • どこで動くか:利用者ごとに割り当てられた専用のクラウドコンピュータ「Muse Secure VM」の中。ブラウザも中に入っている
  • どこで使えるか:米国のみ。iOS・Android・muse.ai、そしてWhatsAppから。AIグラス対応は「近日」

Metaの発表文では、Museを動かしているのは同社の「Muse Spark」というモデルだと説明されています。Muse Sparkは2026年4月8日に発表されたMeta Superintelligence Labsの大規模言語モデルのシリーズ名で、今回の安全設計文書ではバージョン「Muse Spark 1.3」がMuseを動かしていると明記されています。

「答える」から「終わらせる」へ

公式発表の書き出しは 「It doesn't just answer questions, it actually does the work.(質問に答えるだけでなく、実際に作業をする)」 です。ここが従来のアシスタントとの分かれ目になります。

具体例として挙げられているのは、ブラウザを開いてフォームを埋め、利用者の代わりに交渉するところまで。時間のかかる作業ではアプリを閉じたあとも動き続け、状況が変わったときや承認が必要なとき——メールを送る前、購入する前——に戻ってくる、という設計です。

記憶についても踏み込んでいて、一度しか言わなかった好みを覚えて先回りで提案する、Instagramで保存したレシピのリール動画を買い物リストに変える、友人の食事制限を覚えていて招待状を送る前に反映する、といった例が公式に挙げられています。

支払いの仕組みまで用意されている

エージェントが買い物をするなら、決済をどう通すかが問題になります。MuseはStripeが開発した「Link」で決済でき、MetaはLinkの購入保護の対象になる初のAIエージェントだと説明しています。破損・紛失の補償、値下がり対応、手数料なしの返品、対象購入への返金保証が挙げられています。

加えて、Link側でエージェント用のウォレットが使い捨てのカード番号を発行するため、実際のカード情報は伏せたまま決済できる、という作りです。Shop Payへの対応と、既存のログイン情報をMuseが使えるようにする1Password対応も「近日」とされています。

料金|無料枠と2つの有料プラン(2026年9月10日時点)

ここは注意して読む必要があります。公式発表そのものには、価格が1つも書かれていません。

Metaのニュースルーム記事にある記述は 「It's free for most of what people need, with subscription plans for people who want to do more.(必要なことのほとんどは無料で、もっと使いたい人向けにサブスクリプションのプランがある)」 の一文だけです。金額は出てきません。

価格ページが公開されていない、という事実

では公式サイトを見ればよいかというと、muse.ai はログインしないと中身が見られません。2026年9月10日時点で muse.ai および muse.ai/pricing にアクセスすると、いずれも認証画面へ転送されます。米国限定の提供なので、日本から価格表を自分の目で確認する手段が現時点では事実上ありません。

この「価格が公開ページに無い」こと自体が、今のMuseの立ち位置をよく表しています。使う人を米国の一般消費者に絞り、まずアプリの中で完結させる設計です。法人が比較検討のために価格表を並べる、という使われ方はまだ想定されていません。

報道が伝えている3段階

金額について現在確認できるのは、発表当日の説明会をもとにした報道です。CNBCは2026年9月8日の記事で、MetaのAI部門を率いるWang氏の説明として、Museには無料枠に加えて月額20ドルと月額100ドルのプランがある(利用量に応じて選ぶ)と伝えています。

プラン

月額

位置づけ

無料枠

0ドル

「必要なことのほとんど」をカバーすると公式は説明

有料(下位)

20ドル

報道ベース。利用量が多い人向け

有料(上位)

100ドル

報道ベース。同上

⚠️ この表のうち20ドル・100ドルは公式ページで確認したものではなく、報道を出所とする数字です。契約前には、その時点で公式に案内されている価格を必ず確認してください。他社サービスの料金は、公式で自分の目で確認した数字だけを判断材料にするのが安全です。

無料枠は「週1億トークン」——多いのか少ないのか

無料枠の中身について、実機で使った海外メディアの報告では、Museの無料枠は週あたり1億トークンで、週次でリセットされると案内されたとしています。同メディアの記者が丸1日かけて意図的に使い込んだ結果でも、消費は週次枠の11%程度だったと書かれています。

ここから読み取れるのは2つです。1つは、普通の使い方をする限り無料枠に当たるのは難しいということ。もう1つは、Metaが料金を「席数」ではなく「計算量」で設計しているということです。人数課金ではなく消費量課金なので、業務で使うことを考えるなら「何人使うか」ではなく「どれだけ回すか」で見積もる発想に切り替わります。

この考え方は法人向けのエージェント製品でも同じ方向に進んでいます。席の料金と実行時のトークン課金が二階建てになっている例については、こちらで整理しています。

ChatGPT Workspace Agentsとは|対応プランと使い方

Museの料金は出所の強さが3段に分かれている(公式発表・報道・実機レポート・確認できないこと)

Museの設計|「エージェントは攻撃されている」前提で作られている

Museでいちばん読む価値があるのは機能一覧ではなく、Metaが同時に公開した安全設計の文書です。そこにはこう書かれています——「どれだけモデルが強くても、この種のエージェントは間違いを犯すし、読み込んだデータ経由で攻撃されることがある。だから我々は、エージェントが攻撃を受けうる前提でシステムを設計し、被害の範囲を限定した」

この前提の置き方が、そのまま構造に出ています。

1人に1台の専用コンピュータという単位

Museは利用者ごとに専用のクラウドコンピュータ(Muse Secure VM)を持ちます。ブラウザ・ストレージ・CPU・メモリを備えた隔離されたLinux環境で、接続したサービスのデータと資格情報はすべてこの中に保存されます。他人のエージェントからは到達できません。

設計文書はこのVMを「system of record(記録の正本)」と呼んでいます。推論とテレメトリのために限定的なデータだけが外に出る、という但し書き付きです。「クラウドに預ける」という言葉が指す範囲が、従来のチャットAIとは違います。

Sentinel|許可を出せるのはエージェントではない

ここが本題です。VMの中にはSentinelという別のエージェントが、Muse本体とはシステムレベルで切り離されて動いています。役割は1つ、コネクタ経由の操作とネットワーク通信に対する唯一の許可権限者であることです。

公式の言い方は明快です。「Muse proposes actions, but only Sentinel can grant permission to perform action.(Museは操作を提案するが、実行を許可できるのはSentinelだけ)」。そしてMuse側からSentinelを上書きすることはできません。

Museが何かをしようとすると、対象のコネクタ・呼ぼうとしているメソッド・操作の種類・範囲・利用者が何を頼んだかという文脈が、リクエストとしてSentinelに提出されます。Sentinelは利用者が設定したポリシーに照らして可否を決めます。ネットワーク通信も同様で、宛先ホスト名・解決後のIP・ポート・プロトコル・HTTPメソッド・パス・復号後のリクエスト本体まで見て判断します。

承認画面を「会話の外」に置いた、という判断

私がこの文書でいちばん重要だと思ったのは、実装の詳しさではなく次の一点です。

Sentinelが「利用者に確認が必要」と判断したとき、承認のダイアログはMuseとの会話の中ではなく、クライアントのUIに直接表示され、利用者の答えは直接Sentinelに返ります。設計文書はわざわざ「not via their conversation with Muse(Museとの会話経由ではなく)」と書き添えています。

なぜここまで書くのか。会話の中で承認を取ると、承認そのものが、エージェントの手の届く場所に置かれてしまうからです。読み込んだWebページやメールに攻撃者の指示が仕込まれていた場合、その指示は会話の文脈に混ざります。承認のやり取りが同じ文脈にあれば、確認の文面が書き換えられたり、承認したつもりのない操作が承認済みとして扱われたりする余地が残ります。

だから承認は会話の外に出す。答えは agent を経由せず、判定する側に直接届く。これは「機能」ではなく「置き場所」の設計で、あとから足すのが最も難しい種類のものです。

さらに、承認は会話上のニュアンスではなく厳密な権限として扱われます。付与できる範囲は、1回限り・セッション単位・タスク単位・期限付き・恒久の5種類。Sentinelはどの種類を選ばせるかを決め、以後の呼び出しが与えられた範囲と正確に一致することを確認します。

エージェントは本物の鍵を一度も見ない

資格情報の扱いも同じ思想です。VM内の authd という別サービスが、接続先サービスのOAuthトークンなどを保管します(Metaの中央基盤ではなく利用者のVMの中に置く、と明記されています)。

そしてエージェント側が受け取るのは本物ではない代理トークンです。実際の通信が許可されたあと、Sentinelがネットワークの境界で代理トークンを本物の資格情報に差し替えます。文書はこう結んでいます——「エージェントは本物のトークンを見ることがない。つまり、プロンプトインジェクション等でエージェントに秘密を吐かせようとしても無駄である」

ブラウザでのログインも同じで、利用者が入力したIDとパスワードはクライアントから直接安全な保管領域へ送られ、必要な瞬間だけブラウザに注入されます。エージェント本体からは見えません。

「カレンダー担当がメールの鍵を要求できない」という作り

組み込みコネクタの処理は、エージェントが動く領域の外側で実行されます。ワーカーごとに使える資格情報の許可リストが決まっていて、設計文書は具体的にこう書いています——「カレンダーのワーカーが、リクエストのパラメータを変えるだけでメールの資格情報を要求することはできない」

判断の責任も3つに割れています。どこで資格情報を扱うコードを動かすかは権限分離が決め、呼び出し元がどの資格情報を使えるかは authd が決め、その操作を実行してよいかは Sentinel が決める。1つを突破しても次で止まる形です。

メールは「乗っ取りの入口」として特別扱いされている

実務的にいちばん唸ったのはここでした。設計文書は、メールを繋ぐことの危険をこう説明します。メールの受信箱にはワンタイムのパスコードが届くし、そのアカウントは「パスワードをお忘れですか」から他の大半のサービスのパスワードを再設定できてしまう。だからメールを繋ぐことが、他サイトでの本人なりすましを許すことになってはいけない、と。

そこでMuseのメールコネクタは、ワンタイムトークン・パスワード再設定リンク・ログイン用のマジックリンクを、決定的なフィルタと分類モデルの両方で除去します。エージェントには最初から届きません。

これは「AIに何を任せるか」の議論では出てこない発想です。任せる範囲の話ではなく、任せた範囲の中に危険物が混ざらないようにする話だからです。

lethal trifecta とプロンプトインジェクション

設計文書は、Simon Willison氏が2025年6月に名付けた 「lethal trifecta(致命的な三要素)」 を引いています。①私的データへのアクセス ②信頼できないコンテンツへの接触 ③外部へ通信する能力——この3つが揃うと、攻撃者はエージェントを騙して私的データを盗み出せる、というものです。

Museの対策は多層です。モデル自体をプロンプトインジェクション耐性を含めて訓練し、外部由来のデータは「信頼できない入力」としてラベル付けし、複数の検出分類器を並列で走らせ、VMの外へデータが出る操作には人間の承認を挟む。そして、そのすべてが破られてもなお、実行領域の制限・権限分離・authdのACL・Sentinelの判定という決定的な境界が残る、という構成です。

ブラウザ側も同様に、操作するサブエージェントが見るのは生のDOMではなくアクセシビリティツリーのスナップショットで、ページ内でJavaScriptを実行する手段は無く、開発者ツールも無効化されています。利用者がブラウザの操作を代わったときや、保管された資格情報がフォームに入力されている間は、エージェントは完全に停止します。

Museの構造図:提案するMuseと許可するSentinelが分かれ、承認ダイアログは会話の外に出る

バグバウンティ最大30万ドルが意味すること

Metaは発表と同時に、Museのバグバウンティを一般に開放しました。金額が具体的です。

  • 有効な報告に対して最大30万ドル
  • そのうち、1人の利用者に影響するプロンプトインジェクションの成功に最大13万ドル

「1ユーザーへのインジェクション成功」に13万ドルの値札を付けたという事実は、そのまま「まだ破られうると考えている」という自己申告です。ここまで作り込んだうえで、なお破られる前提で報奨金を積んでいる。

これは読者にとって重要な補助線になります。安全設計が丁寧であることと、安全であることは別です。設計文書自身も冒頭で「Museは今後も間違いを犯す。ただし頻度と被害は大きく減るはずだ」と書いています。エージェントを業務に入れるかどうかの判断は、「安全と言っているか」ではなく「間違える前提でどこまで被害を限定してあるか」で行うのが実務的です。

私が無人運用でたどり着いた結論と、同じ形をしていた

ここからは実運用側の話です。私は別のマシンで、毎日決まった時刻に無人で走るAIジョブを運用しています。人が見ていない時間に文章を書き、画像を作り、公開まで進めるものです。そこで学んだことが、Museの設計と驚くほど同じ形をしていました。

指示文は境界にならない

最初は、AIへの指示文に「ここより外のファイルは触らないこと」と書いていました。守られないことがありました。悪意があるわけではなく、目の前の作業を進めるうえで自然に見える判断が、書いた境界を跨いだだけです。

解決したのは、指示を強くしたときではありません。ジョブを起動するシェル側に関所を置き、決めた範囲から外れた変更は保存せずに破棄して、その事実を通知するようにしたときです。AIに読ませる文章ではなく、AIが通れない場所に置いた。Sentinelが「Museが上書きできない場所」にいるのと同じ考え方です。

そして、この関所はそのシェルを通るジョブにしか効かないという限界も同時に持ちます。境界を持つということは、境界の外側に例外がどこにあるかを把握し続けることでもあります。

判定は、書いた本人ではなく別のプロセスに出す

もう1つは検品です。書いたAIに「この記事は公開してよいか」と同じ会話の中で聞くと、まず通ります。自分が書いた文章を自分で採点しているので当然です。

いまは、執筆の文脈から切り離した別プロセスの監査役を起動し、判定できなければ公開しない(判定不能は不合格として扱う)運用にしています。判断を下す主体を、判断される主体の外に置く。Museが承認ダイアログを会話の外に出したのと、動機は同じです。

この設計は実際にコストも払っています。監査が通らずに公開を見送った記事は複数あり、その中には「内容は正しいが、裏取りの証跡が検品役から見える場所に残っていなかった」という理由のものもありました。検品する側から見えない証跡は、無いのと同じ——これはMuseの設計とは別の話ですが、境界を機械に守らせるときに必ず出てくる副作用です。

「担当を決めた」は、仕組みではない

もう1つ、痛い形で学んだことがあります。ある工程について「これは別の担当が週次でやる」と手順書に書いていたのですが、その週次の作業には実体(起動する仕組み)が無く、書いてあるだけでした。結果、その工程は2週間動かず、後段が空回りし続けました。

人が読む文書に責任者を書くことは、仕組みを作ることではありません。いま同じ轍を踏まないために、未処理の件数を毎回自動で通知に出すようにしています。

エージェント導入の文脈でこれを言い換えるとこうなります。「運用ルールで縛ります」は対策として弱い。 ルールが守られたかどうかを機械が確認して、守られていなければ止まる形になっているかを見るべきです。Museの設計文書が全編にわたって「どのプロセスが」「どのレイヤーで」止めるかを書いているのは、そういうことです。

何を渡すか・何を渡さないかという「権限の中身」の決め方については、常時稼働のエージェントを題材にこちらで詳しく書いています。本記事は「決めた権限を誰が守らせるか」に寄せているので、あわせて読むと全体像がつながります。

Grok Botとは|常時稼働AIエージェントに渡す権限の決め方
AI業務効率化Grok Botとは|常時稼働AIエージェントに渡す権限の決め方

日本の中小企業は、いまMuseをどう扱えばいいか

いまは使えない。それでも見ておく理由

繰り返しますが、2026年9月10日時点でMuseは米国限定です。日本からの利用可否・日本語対応・提供時期について、Metaは公式に何も発表していません。今日の業務判断に組み込む対象ではありません。

それでも見ておく理由は、この設計が「個人向け製品の当たり前」になると、法人側の期待値が動くからです。従業員が個人で使うエージェントが「承認は会話の外」「鍵はエージェントに見せない」を標準搭載している世界では、社内に入れるツールに同じ水準を求めるのが自然になります。逆に、その水準を満たさないツールを「便利だから」で入れると、比較されたときに説明できません。

個人向けと業務向けは、まだ層が違う

Museは個人のアカウント・個人の資産・個人の買い物を前提にした製品です。組織で使うために必要な要素——管理者による統制、誰がどの権限を持つかの一元管理、監査ログの組織単位での保全、契約上のデータ取り扱い——は、今回の発表の主題ではありません。

業務でエージェントを使うなら、現状は法人向けに設計された製品を見るのが筋です。管理者側の統制や権限設計がどう組まれているかは、こちらで整理しています。

AIエージェントの権限管理|業務導入で押さえる3層設計
Claude CodeAIエージェントの権限管理|業務導入で押さえる3層設計

使えるようになったときに確認する5点

提供地域が広がったときに備えて、確認すべき点を挙げておきます。これはMuseに限らず、エージェント型のツール全般に使えます。

  1. 承認はどこに出るか:AIとの会話の中か、それとは独立した画面か。会話の中だけなら、そのAIが読んだ外部データの影響を受けうる
  2. 資格情報をAIが見るか:APIキーやパスワードがAIの文脈に入る設計だと、漏れる経路が増える
  3. 読み取りと書き込みを分けられるか:まず読むだけで数日運用し、効いた書き込みだけを1種類ずつ開けるのが安全な順番
  4. 取り返しのつかない操作が混ざっていないか:送信・購入・削除は、失敗したときに戻せない。ここだけは人が押す形を残す
  5. 何をしたか後から読めるか:監査ログが操作単位で残り、組織として保全できるか

メールとカレンダーという、最も繋ぎたくて最も危ない対象について境界を引く具体的な手順は、こちらにまとめています。

AIにメール・予定を任せる境界の作り方
AI業務効率化AIにメール・予定を任せる境界の作り方

よくある質問

Q. Museは日本でいつ使えるようになりますか

公式に発表されていません。2026年9月10日時点の公式発表は「米国でiOS・Android・muse.aiに展開中、AIグラス対応は近日」までで、他地域の時期には触れていません。時期を断定する情報を見かけたら、出所が公式かどうかを確認してください。

Q. 料金はいくらですか

公式発表には金額の記載がなく、「必要なことのほとんどは無料、もっと使いたい人向けにサブスクリプションがある」とだけ書かれています。発表当日の説明をもとにした報道では、無料枠に加えて月額20ドルと月額100ドルのプランがあるとされています。muse.aiは認証が必要で日本から価格表を直接確認できないため、契約時点の公式価格を必ず確認してください。

Q. Metaの広告に自分のデータが使われませんか

公式発表では、Museの会話やVM内のデータをMetaの広告システムと共有しない、と明記されています。あわせて、やり取りをMetaのAIモデルの学習に使うことをオプトアウトできること、覚えた内容を個別に「忘れて」と指示できることも書かれています。さらに年内には、利用者だけが鍵を持つ形でVM全体を暗号化する「Muse Confidential VM」を導入予定で、その場合はMetaもアクセスできないとしています。

Q. これまでのチャットAIと何が根本的に違うのですか

チャットAIは答えを返すところで止まりますが、Museはブラウザを開き、フォームを埋め、決済まで実行します。間違いのコストが「変な答えが返ってくる」から「実際に何かが起きてしまう」に変わるのが最大の違いです。だからMuseの設計文書の大半が、性能ではなく被害の限定に割かれています。

Q. 自社でエージェントを使うなら、まず何から見るべきですか

機能一覧より先に、止め方を見てください。承認がどこに出るか、取り返しのつかない操作が人の手に残っているか、後から何をしたか読めるか。この3点が確認できないツールは、便利さに関係なく業務の本流には置かない方が安全です。私たちが顧問先で最初に決めてもらうのも、ここです。

まとめ|新しいのは能力ではなく、承認の置き場所

Museの発表で本当に新しいのは、エージェントがメールを送れることでも、買い物ができることでもありません。承認する仕組みをエージェントの外側に置き、エージェントには本物の鍵を見せないという作り方を、個人向け製品の既定にしてきたことです。

この構造はこれまで、自分で組める人だけが持てるものでした。私が無人運用の失敗を経て「指示文ではなく機械の関所」「自己採点ではなく別プロセスの監査」に行き着いたのと、Metaが専用VMとSentinelに行き着いたのは、規模がまるで違うだけで同じ結論です。

日本から使えるようになるのはまだ先ですが、ツールを選ぶときの目線はいまから変えられます。「何ができるか」ではなく「間違えたときにどこで止まるか」で見る。株式会社Fyveは、この観点で中小企業のAI導入の判断材料を整理しています。

参照した一次情報

  • Meta「Introducing Muse: The World's First Personal AI Agent Built for Everyone」(2026年9月8日)
  • Meta AI Research「How We Built Safety Into Muse」(Muse Secure VM・Sentinel・authd・権限分離・プロンプトインジェクション対策の設計文書)
  • Meta「Introducing Muse Spark」(2026年4月8日・Muse Sparkシリーズの発表)
  • CNBC(2026年9月8日・料金体系と提供範囲についての報道)
  • Gizmodo(2026年9月・無料枠の実機レポート)

AIを使う会社と、使わない会社。
その差は、開き始めています

ここ数年でAIは急速に進化し、正しく導入できている企業とそうでない企業とでは、業務効率や人件費に大きな差が生まれ始めています。「AI導入に興味はあるが、実際に何ができて、どこから手をつければいいか分からない」——そんな方は、まずこの無料プレゼントに目を通してみてください。

無料プレゼント:様々な業種にAIを導入して分かった、成功の型と失敗パターン ― 無料でダウンロードする
← 記事一覧に戻る