Meta MuseのSentinelに見る、AIの実行と認可の分離

Metaは2026年9月8日、個人向けのAIエージェント「Muse」を発表しました。

メールを送り、旅行を手配し、買い物を済ませる——利用者に代わって実際に操作を行うエージェントです。

同社が8月に発表したコーディング向けの「Muse Code」とは別の製品で、こちらは個人の日常タスクを扱います。

本稿が扱うのは、この製品が公表した「実行」と「認可」の分け方と、そこから企業のAIエージェント設計に引ける論点です。

ここでいう認可とは、ある操作を実行してよいかを、与えられた権限や条件に照らして判定することを指します。

「その買い物が利用者にとって良い選択か」という業務上の判断とは別の問いで、本稿が扱うのは後者ではなく前者です。

なお本稿の記述は、Metaが公表した発表記事と技術解説に基づくものです。

公開された設計を読むことと、その統制が実際の利用環境でどこまで機能するかを検証することは別で、私たちは独立した動作検証を行っていません。

Museで何が分けられているのか

Metaの技術解説によれば、Museの本体はコンテナ化されたランタイム環境の中で動きます。

そして「Sentinel」と呼ばれる別のエージェントは、そのコンテナの外側、ホスト側で動作します。

同社はこの配置の理由を、実行環境は信頼できないデータを処理する前提で設計しているため、セキュリティ機能をその外側に置く、と説明しています。

Sentinelの役割は、ネットワークへのアクセスと、外部サービスへの操作について唯一の権限を持つことだとされています。

Sentinelは個々の操作に対して、許可する・拒否する・利用者に確認する、のいずれかを判定します。

判定は、利用者が接続先ごとに設定したポリシーに照らして行われる、と説明されています。

つまりMuseの側が「この操作をする」と決めても、それだけでは外部に届きません。

操作が実際に外へ出るかどうかは、Museの外側にある別の仕組みが決めています。

「決定権と実行権」より、「実行と認可」で捉える

この構成を、私たちは「決定権と実行権を分けた」とは表現しません。

業務上の判断と、その操作を許可するかどうかの判定は、別の層にあるからです。

許可された範囲で行われた購入であっても、その商品を選んだことが適切だったとは限りません。

逆に、選択として妥当でも、権限の範囲外であれば実行させるべきではありません。

Museの構成が具体化しているのは後者、つまり認可の側です。

私たちが重視しているのは、重要な操作を行うAI自身に、その操作を許可する権限まで集中させないことです。

人間の承認や、あらかじめ定めたルールを、実行側のAIが自分で書き換えたり迂回したりできない形で適用する。

その境界を、操作の影響の大きさと、取り消しやすさに応じて決めていきます。

これは「承認役のAIをもう一つ足せばよい」という意味ではありません。

システムが二つあること自体が目的ではなく、誰が許可の条件を決め、どの仕組みが実際に操作を止めるのかを分けて設計することが要点です。

私たちはAIの能力評価を軽視しているわけではなく、それに加えて、どの権限を与え、どこで制限するかを設計対象として扱っています。

承認は会話の外側に置かれている

Museの技術解説で目を引いたのは、利用者への確認の届け方です。

確認が必要だとSentinelが判定した場合、実行はいったん止まり、保留中の承認として扱われます。

そのうえで承認のやり取りは、Museとの会話の中ではなく、クライアントの画面上に出る専用のダイアログで行われる、と説明されています。

これは、承認の要求そのものを、エージェントが生成する文章の外に出すということです。

会話の中で承認を求める形にすると、利用者が読んでいる文面自体をエージェントの出力が左右できてしまいます。

デザイン解説の側でも、受け入れと拒否を明示したカード形式の承認画面を用意したと説明されており、会話だけでは足りない領域がある、という判断が示されています。

認可の粒度についても記述があります。

一回限り、セッション単位、タスク単位、期間を区切ったもの、恒久的なもの、といった選択肢が提示され、後続の呼び出しでは許可された範囲と厳密に照合される、とされています。

もう一点、デザイン解説は、確認を出しすぎることの副作用にも触れています。

利用者が「消すために承認する」状態になりうることを課題として挙げ、既定では通常の閲覧は許可したうえで、取り消しにくい操作で止める設計にした、と説明されています。

確認を増やすほど安全になる、という考え方を取っていない点は、企業の設計でも参考になります。

決済に見る、三つの別々の制限

決済まわりの説明は、権限の設計を具体的に読める部分です。

ただし、ここで起きていることは一つではなく、性質の違う三つの制限が重なっています。

一つ目は、認証情報を見せないことです。

Metaは、実際のカード情報をエージェント側に渡さない設計だと説明しています。

二つ目は、決済手段の再利用を制限することです。

新規の加盟店での支払いでは、Museのウォレットが取引ごとに異なる使い切りのカード番号を発行し、利用者のカードそのものではなくその番号が加盟店側に渡る、とされています。

三つ目は、その番号が使える取引の範囲そのものを絞ることです。

技術解説によれば、発行される番号は、特定の加盟店・特定の金額に紐づけられ、限られた期間だけ有効とされています。

Metaは、この限定があるため、仮にプロンプトインジェクション等で使い切りのカード番号が盗まれても、攻撃者にとって有用な範囲は限られる、と説明しています。

この三つを分けて読む必要があるのは、混同すると設計上の含意を取り違えるからです。

たとえば、使い切りであること自体からは、支出の総額が抑えられることは導けません。

同じ仕組みで新しい番号を繰り返し発行できるのであれば、一枚ごとに一度しか使わなくても、合計額は積み上がります。

カード番号に金額を紐づけることは、その取引を制限しますが、それだけで複数の取引にまたがる支出の上限が決まるわけではありません。

累計の上限を設けるなら、それらの取引をまたいで効く別の統制が要ります。

これはMuseにそうした統制が無いという指摘ではなく、使い切りであることと取引ごとの金額指定だけからは、累計の上限までは導けないという整理です。

なお、すでにカード情報が登録済みのサイトでの購入については、決済ページを検出した時点で、購入内容の詳細を示したうえで毎回利用者の承認を求める、と説明されています。

ここから企業設計に引けるのは、次の対比です。

「一定額を超えて支払わない」とAIに指示することと、決済を受け付ける側が許可された条件以外の支払いを拒否することは、別のことです。

指示だけでは、AIがそれに従わなかったときに残る歯止めがありません。

決済を受け付ける側で効かせる制限は、それとは別の歯止めになりえます。

エージェントへの指示や設定だけに頼らず、実行を受け付ける仕組みの側にも制約を持たせる。

この考え方は決済に限らず、社内システムへの操作でも同じ形で使えます。

動作履歴は検証の手掛かりであり、正しさの保証ではない

デザイン解説によれば、利用者はアバターから現在の作業内容を確認でき、そこから全体の活動ログを開けるとされています。

一方で、企業の監査に必要な記録の要件——どれだけの期間保持されるか、誰が閲覧できるか、後から改変されないことをどう担保するか——については、今回参照した資料からは確認できませんでした。

これとは別に、Metaは Muse Confidential VM について、誰でも検証できる継続的な監査を予定していると説明しています。

ただしこれは、Metaが利用者のデータにアクセスできないというプライバシー保護の検証に関するもので、個々の動作記録の保持や改変対策とは対象が異なります。

そのうえで、記録について私たちが企業の設計で強調している点があります。

操作や承認の記録が残っていても、それだけで判断が適切だったとは言えません。

適用したルール、利用者が実際に依頼した内容、そして実行結果を突き合わせて、権限の範囲内だったか、判断に無理がなかったかを確認できる形になっているかが問われます。

記録が「残っている」ことと、記録が「検証に使える」ことは別です。

止める設計についても、同じ整理が要ります。

実行の前に止められることと、実行後に元へ戻せることは、別の機能です。

メールの送信や購入のように、実行してしまえば完全には戻せない操作もあります。

私たちが重視しているのは、必要な場面で実行を止められること、実行後に何が起きたかを確認できること、そして問題があれば可能な範囲で取消しや訂正を行えること、の三つを分けて設計することです。

企業がAIエージェントに権限を与えるときに決めること

Museは個人向け製品で、企業システムに組み込むエージェントとはリスクの種類も責任の所在も異なります。

そのまま持ち込めるものではありませんが、論点の立て方は共通します。

以下は、私たちが自社の設計で使っている整理を、叩き台として示したものです。

共通の推奨設定ではなく、検討の出発点です。適用される法令・契約・社内規程を前提に、業務の影響とリスクに応じて具体化してください。

論点	自社で決めること	実装・運用先の例
実行と認可の分離	実行側が自分で承認状態や許可ルールを変更できないようにする	認可サービス、実行ゲートウェイ、接続先のアクセス制御
重要操作の事前確認	何を承認対象にし、承認後のどの変更で再承認を求めるか	承認画面、承認ワークフロー、実行API
操作・承認の記録	依頼・承認・実行結果をどう結び付け、誰が確認するか	操作ログ、承認履歴、ログ管理基盤
権限の限定	操作・対象・金額・期間・失効条件をどこまで絞るか	認可サービス、接続先API、決済システム

仮の業務例で補います。

取引先へのメール送信であれば、AIは文面を作成し、送信を担うサービスは承認済みの宛先・本文・添付ファイルだけを送る、という分け方が考えられます。

承認の後に内容が変われば再度承認を求め、AI自身には承認状態を変更する権限を与えません。

この形にすると、「承認を挟んだ」という事実だけでなく、何に対する承認だったかが実行内容と結び付きます。

運用に入ったあとの取り決めも、同じ時点で決めておきたいところです。

許可ルールを変更できる担当者、記録を確認する担当者、停止と再開を判断する担当者。

接続先や対象業務を変えたときには、それまでの承認条件と権限の制限で足りるかを見直します。

まとめ

Museが公表したのは、実行するエージェントの外側に認可の仕組みを置き、確認を会話の外に出し、決済では性質の違う複数の制限を重ねる、という構成でした。

私たちがここから引くのは、次の形です。

重要な操作を行うAI自身に、その操作を許可する権限まで集中させない。

許可した対象と実際の操作を結び付け、実行側が自己判断で制限を変更したり迂回したりできないようにする。

そのうえで、記録・確認・停止・実行後の是正を、運用の手順として整える。

構造と運用は、どちらか一方では足りません。

企業がAIエージェントに権限を与えるときも、機能の有無を確認するだけでなく、承認の条件は誰が決めるのか、記録は誰が何のために見るのか、制限はどの仕組みが実際に効かせるのかまで、自社の設計として詰めておく必要があります。

情報確認について

本記事は2026年9月確認時点で、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」（Security and Safety for AI Agents: Our Approach with Muse）、およびデザイン解説「How We Designed Muse」を主要な参照元として作成しています。

製品の構成・機能に関する記述はこれらの公表資料に基づくものであり、MIF LLC が独立して動作や安全性を検証したものではありません。

企業向けの論点整理・表・業務例は、私たちによる分析と提案です。

提供範囲や仕様は変更される可能性があります。

実際の利用・導入にあたっては、最新の公式情報と利用条件をご確認ください。