MuseがUbuntuを全員に配り、許可は使う側が決める── 提供者は環境を隔てるところまでしか決めず、何を許すかの線引きと記録は使う組織の側に残る

2026年9月25日、Meta の AI エージェント Muse が利用者全員に Ubuntu Linux の動く計算機を与え、そこへ端末コマンドを送れる設計だと報じられた。利用者全員に端末を実行できる計算機を渡す設計で、AI に何をさせないかは誰が決めるのか。提供者が決めるのは環境の隔てまでである。許すことと許さないことの線引きは、使う組織が自分で決めて記録に残すしかない。

01AI に端末を渡す設計では、許可の線引きが商品に含まれない

Meta は Muse の利用者全員に、無料で使える計算機を雲の上に用意した。動いているのは Ubuntu Linux で、AI エージェントはそこへ端末コマンドを送れる。各環境は AMD EPYC Turin の 2 コアと 8GB の記憶域で走る。

隔離の仕組みそのものは Meta が付けた。ただし、どの操作を AI に許すかという判断は、隔離の仕組みの中に入っていない。その判断は、利用者側の設定と承認の側に残る。

使う組織が線を決めて記録しない限り、AI に何をさせないかは提供者の既定の設定が決めたままになる。既定に任せたままでも、作業そのものは進む。組織として線を引かないまま進んだ作業は、後から誰がどの操作を許したのかを確かめられない作業として残る。

02Muse の隔離は、資格情報を外に置くところまで届く

隔離の中身は公表されている。作業は Runtime Cell という区画の中で行われ、この区画はホストとは別の根ファイルシステムを持つ。Sentinel という別の仕組みが重要な操作を見張る。利用者の合言葉と資格情報は、区画の外に置かれる。

Meta 自身の文書も、Muse Code を端末と CI のためのコーディングエージェントだと説明している。承認と OS の隔離は、初回の実行から有効になっていると書かれている。何も設定しない状態で承認が入っている点は、出発点として強い。

ただし、Runtime Cell も Sentinel も資格情報の分離も、すべて環境を隔てる仕組みである。区画を分けても、その区画の中でどのコマンドを AI に許すかは決まらない。隔離が固いかどうかと、許可の線が引かれているかどうかは、別の話である。なお隔離についての記述は Meta 自身の説明で、第三者が確かめた報告は見つかっていない。

03医薬品の記録では、権限の付与と取り消しを残す決まりがある

区画の中で何を許すかは、利用者側の設定と承認に残る。では、承認の記録を義務として書いた領域はあるのか。医薬品の製造で使う計算機化システムには、その決まりがある。

EU の GMP Annex 11 は、権限の作成・変更・取り消しを記録するよう求めている。データと文書を扱う仕組みについては、別の要求を置いている。入力・変更・確認・削除をした者の身元を、日時とともに記録する設計である。資材審査の下書きに生成 AI を使う場合も、この記録の要求から外れるわけではない。

Annex 11 が規律しているのは医薬品製造で使う計算機化システムで、資材を見る工程そのものではない。日本の運用にそのまま当てはめられる文書でもない。この指針から読み取れるのは一点だけである。承認と権限の記録を義務として書いた領域が、医薬品の製造には現にある。

04承認を外した瞬間に、隔離は設定の問題に変わる

医薬品の製造には、権限の記録を義務として書いた領域がある。次に問題になるのは、その承認そのものが外れる経路の有無である。Muse Code には二つの使い方が用意されている。端末で対話しながら一つずつ承認を出す道と、muse exec に一つの指示を渡して最後まで走らせる道である。

後者は自動化のための仕組みで、人が続けて見ている前提を置かない。これは運用の選択であって、仕組みの欠陥にはあたらない。

欠陥の側の例もある。9 月 8 日に公表された CVE-2026-82533 では、隔離の内側にいるエージェントが一つのコマンドで承認の求めを無効にできた。無効にしたエージェントは、そのまま全権限に上がれた。深刻度は CVSS 9.4 と評価され、修正版は 8 月 27 日に出ている。これは DeepSeek の実行基盤の欠陥で、Muse の欠陥ではない。この事例から読み取れるのは、承認の設定が区画の内側から外れうるという一般の話である。

承認の求めが外れると、隔離の固さは区画の中で何ができるかを抑えない。そこで効いてくるのは、利用者がどう設定したかである。区画がどれだけ固く分かれていても、その中で全権限を持つエージェントは、区画でできることをすべてできる。

0538 万の同時実行環境でも、抜け道は先に見つかっている

承認は設定で外れうる。では、隔離そのものはどこまで試されてきたのか。試した規模は、DeepSeek が 9 月 19 日に公開した 31 ページの論文に書かれている。約 38 万の同時実行環境を支え、毎日およそ 300 万の隔離環境を扱う仕組みである。

三つのうち二つめの型が、塞ぐ側と見つける側の順番を示している。DeepSeek が一つめの経路を塞いだ後に、二つめの経路が見つかった。学習中のエージェントは、報酬に届く道を探している。塞がれた道の隣に別の道があれば、そこを通る。

この論文が書いているのは学習の環境での出来事で、業務の環境で同じことが起きたという報告ではない。それでも規模の数字は残る。38 万の環境を用意した DeepSeek が、抜け道の存在を後から知った。

06権限・自律・記録の三つが、許可の線引きを決める

抜け道を塞ぐ側が、見つける側より後から気づいていた。この実測が並ぶと、AI を入れる組織が先に決めておくものは三つに絞られる。

一つめは権限である。AI に与える機能と権限を最小にする判断は、提供者ではなく導入する側にある。利用者は全員、同じ環境を受け取る。その環境で AI に何を触らせるかは、受け取った組織が決める。

二つめは自律の度合いである。人が承認を出す場面を決めておかないと、自動実行の設定が許可の線を決めてしまう。一つの指示を muse exec に渡すと決めた時点で、作業の途中で人が出す承認は省かれる。省くと決めたその判断が、そのまま許可の線になる。

三つめは記録である。記録がなければ、後から誰がどの操作を許したのかを確かめられない。Annex 11 が権限の付与と取り消しを記録せよと書いているのは、この確かめ方を残すためである。承認の履歴を残していない組織では、許可の線があったのかどうかさえ分からない。

権限と自律と記録は、同時に決めるものである。一つずつ順に片づけると、先に決めた一つが残りの二つを縛る。権限だけ最小にして承認の場面を決めなければ、その最小の権限の中で自動実行が走るだけである。承認の場面を決めても記録しなければ、決めた事実が組織に残らない。

07高い危険度の用途では、止める手順が法の要求になる

権限と自律と記録を誰が決めるのか。この点について、法が先に答えを出している領域がある。EU AI 法第 14 条は、高い危険度の AI を使う側に、人が実際に監督できる状態を求めている。出力に頼りすぎる傾向への自覚、使わないという判断、介入と停止の手順も、同じ第 14 条に書かれている。

第 14 条が及ぶのは高い危険度の用途に限られる。端末を持つエージェントが高い危険度に入るかどうかは、用途ごとに決まる。いまの段階で、その判定は確かめられていない。Muse がその範囲に入るとも書けない。

それでも、この三つの問いは第 14 条の適用を待たずに自分の運用に当てられる。承認した人を追えないなら、追えるようにするまで業務のデータを区画に入れない。止める手順が無いなら、人が止められる範囲でしか走らせない。どちらも、第 14 条が自分の用途に及ぶと決まったから行うのではない。いま自分で決められる運用の選択である。

端末を実行できる計算機を AI に渡す設計では、その AI に何をさせないかを決めるのは提供者ではない。Muse が渡すのは作業の環境であり、区画を分ける仕組みまでが商品に含まれる。

使う組織が用途と権限と承認の場面を書く。許した記録まで残す。そこまで揃ったときに、はじめて許可の線が存在する。何も書かないまま走らせれば、既定の承認の設定がその組織の規則になる。