MuseのSentinelは標準アーキテクチャになるかもしれない｜実行と承認を分けるAI

AIに仕事を任せるなら、実行するAI自身に、最終的な権限判断まで任せない。 MuseのSentinel（センチネル）を読んで、みやっち🧑‍💻が最も重要だと感じたのは、この原則です。こうした分離は、これからのパーソナルAIエージェントの標準アーキテクチャになるかもしれません。

MuseのSentinelとは Sentinelは、MetaのパーソナルAIエージェント「Muse」と同じ専用VM内で、Museの実行領域から分離して動く監督エージェントです。Metaの説明では、コネクタを使った操作とネットワーク出口の許可を管理します。

Metaの公開設計を簡略化した概念図。実画面ではなく、認証管理やブラウザなどの補助機構は省略しています。

Sentinelは、いつ公表された仕組みなのか

Sentinelは、2026年9月8日のMuse発表時の公式技術記事「How We Built Safety Into Muse」に説明されています。10月23日のニュースは日本での提供開始です。Sentinelが10月に初めて発表されたわけではありません。

みやっち🧑‍💻は、SOUL.md・IDENTITY.md・MEMORY.mdで人格や記憶を手入れできることも面白いと感じています。ただ、普及の土台としては、Sentinelの方が本質的かもしれない。自分をよく理解するAIでも、どこまで任せてよいか分からなければ、任せる仕事は広がりにくいからです。

VM・Sandbox・Sentinelは何が違うのか

VMは、物理コンピューター上にソフトウェアで作る仮想的なコンピューターです。Museでは、利用者ごとに専用のクラウドVMを用意します。Sandbox（サンドボックス）は、プログラムが触れるファイルや通信などに境界を設ける仕組み。Sentinelは、その上で操作の許可を判断する役割を担います。

たとえば「このサービスのAPIへ接続できる」という許可と、「この顧客情報を送ってよい」という許可は別です。これは説明のための仮定ですが、同じ通信先でも、公開情報の取得と個人情報の送信では意味が違います。接続先だけでなく、何をするかまで扱う。 そこに監督層の価値があります。

MuseのSentinelは、何を分離しているのか

Metaの製品発表では、MuseとSentinelをシステムレベルで分離し、認証情報をMuseから隠し、重要な操作には本人の承認を挟む構成を説明しています。

技術記事で特に注目したのは、ユーザーデータを読んだプロセスの外部通信を、同じようには自動許可しないことです。Metaはこれを「Tainted Egress」と呼び、LinuxのeBPFなどで追跡しています。機密と判定された情報だけが対象ではありません。追跡できない場合も自動許可から外し、通常の承認処理へ戻す設計です。

もう一つは、操作の承認をMuseとの会話上の約束だけにしないこと。ユーザーが承認した範囲を別の権限主体が管理し、実行経路に制約をかけます。独立したAIの判断に、OS・通信・認証の境界を組み合わせる構成だと読めます。

ただし、「全通信を管理する」は「全通信のたびに別のLLMが推論する」と同じ意味ではありません。また、データ追跡があるから漏洩を完全に防げる、と証明されたわけでもありません。

Claude Code・Codexにも独立した審査はあるのか

あります。実行するAIと審査する仕組みを分ける発想は、Museだけのものではありません。 今回、公式資料を調べ直して、比較で残すべき違いは「審査機構の有無」より「何を、どの境界で審査するか」だと考えました。

Anthropicは2026年3月25日の技術記事でauto modeの分類器を説明しています。Codexの公式Auto-reviewドキュメントも、サンドボックスの境界を越える承認要求などを別エージェントへ渡すと明記しています。Codexでは、設定や組織ポリシーにより利用条件も変わります。

クラウド環境の隔離も別の軸です。Claude Codeのクラウド公式説明には、隔離VM・ネットワーク制限・GitHub認証の安全なプロキシが記載されています。ただし、製品一般の審査機能の説明を、すべてのクラウド環境で同じ設定・同じ範囲に適用される保証として読むことはできません。

ここで比べたのは、2026年10月24日に確認した公開仕様の審査単位です。防御性能を実測して順位を付けたものではありません。記憶・先回り・実行力から製品を選ぶ全体像は、4大パーソナルAIエージェントの比較で整理しています。

OpenClawからMuseへ、何が変わるのか

OpenClawからMuseへの流れを、自律的に働く相棒を広く使える製品にしていく動きとして見るのは面白いと思います。ただし、「OpenClawは自由に動くだけ、Museが初めて安全装置を付けた」という歴史にはできません。OpenClawにも実行承認の仕組みがあります。

みやっち🧑‍💻がMuseで注目するのは、独立した監督、認証情報の隔離、データを読んだプロセスの追跡を、一つのパーソナルエージェントの設計として示した点です。この組み合わせを「世界初の発明」と断定するには、先行研究・製品との詳しい比較が必要です。

人格・記憶・権限の3層が、標準になるかもしれない

みやっち🧑‍💻は、パーソナルAIエージェントを次の3層で見ると、これからの違いが分かりやすくなると考えています。これはMeta公式の分類ではなく、この記事での整理です。

人格と記憶を育てるほど、AIに任せたい仕事は増えます。そのとき、提案を作るところから、許可した範囲で実行を進めるところへ広げられるか。たとえば予定の確認は任せ、予定変更には対象と期間を限った承認を使う。こうした分担ができれば、人は細かな操作のたびに立ち会う負担を減らせます。これは設計から考える使い方で、今回の実測結果ではありません。

標準になるとしても、すべての製品がSentinelという名前のAIを載せる必要はありません。ルールに従って許可・拒否するポリシーエンジンでもよい。実行するAIが、自分の都合で最終的な権限境界を広げられないこと。 みやっち🧑‍💻は、そこが普及に必要な原則になると考えています。

モデルが賢いことに加え、任せる範囲を具体的に決められることが製品選びの軸になる。MuseのSentinelは、その競争を考えるうえで重要な実装です。

実際に業務で使う際の許可範囲は、扱う情報・契約・社内規定でも変わります。情報システム担当者などと確認し、小さな範囲から始めてください。本記事は法的助言ではありません。

自分の資料や手順に合わせて仕事を組み立てたいなら、Claude Code・Codexで業務を任せる範囲を設計する学びにもつながります。AIに何を任せ、どこで自分が判断するかを考えたい方は、まず無料セミナーでお会いしましょう。