- AIソフトウェアには、単なるモデル呼び出しを超えて、セキュリティ・分離・拡張性・移植性を提供するOS的な性質が必要であり、そのためにAIモデル専用の仮想マシン(MVM) という概念が提案されている
- Java Virtual Machine(JVM) がメモリ安全性と「一度書けば、どこでも動く」を可能にしたように、AI VMもモデルと統合ロジックを分離し、交換可能性と相互運用性を保証する
- VMは、モデル呼び出し、ツール呼び出し、結果保存、ユーザー入力、条件分岐といった標準命令セットを定義し、モデルの振る舞いを安全に制約し追跡できるようにする
- OpenAIの構造化ツール呼び出し、AnthropicのMCP、MicrosoftのFIDES/AC4A、オープンソースランタイムなどの既存研究は、すでに標準化の方向性を示している
- よく定義されたAI VMは、セキュリティ・プライバシー強化、性能監視、出力検証、クロスプラットフォームのエコシステム構築を可能にし、AIシステムをより信頼でき安全なものにする中核インフラになり得る
紹介
- AIモデルは、アプリケーションのコパイロット、IDE統合、MCPプロトコルを通じたツール利用など、さまざまな用途でソフトウェアに活用されている
- こうした進展は、プライバシー、セキュリティ、正確な動作を保証する必要性を高めている
- セキュリティとプライバシーはシステム設計段階から確保されるべきであり、後付けでは不十分
- Java Virtual Machine(JVM) に着想を得て、AIモデルのための標準化された仮想マシンの重要性が提案されている
- JVMはメモリ安全性、アクセス制御、バイトコード検証を通じて信頼できる実行環境を提供した
- これにより「一度書いてどこでも実行」が可能になった
AIモデル仮想マシン(MVM)の役割
- MVMは、AIモデルと外部環境の間の仲介ソフトウェアとして動作する
- 例: ユーザーが「航空便を予約して」というプロンプトを入力すると、MVMがそれをモデルに渡す(コンテキスト追加を含む)
- モデルが「予約ツールを使う」と応答した場合、MVMは許可されたツール一覧を確認したうえで、ツール呼び出しを行うかどうかを決定する
- これにより、モデルが未承認の呼び出しを行わないよう保証する
- すべての商用AIシステムは、これに類似した制御ソフトウェアを必要とする
- MVMは命令セットを定義し、たとえば次のようなものが含まれる:
- モデルの認証、ロード、初期化、アンロード
- コンテキストを含むモデル呼び出し
- モデル出力のパース
- ツールの認証、ロード、呼び出し、結果のパース、およびメモリ保存
- ユーザー入力の要求、履歴メモリの追加、条件文などの制御構造
既存研究と必要性
- OpenAIの構造化ツール呼び出しプロトコル: JSONベースの関数呼び出しAPIとOpenAPI仕様を通じて、明確なツール統合を提供
- AnthropicのMCP(2024): AIアシスタントと外部データをつなぐオープンプロトコル
- 「AIアプリケーションのUSB-Cポート」にたとえられ、汎用的なインターフェースを提供
- 大企業を含む急速な採用事例がある
- セキュリティオーケストレーター – FIDES & AC4A(2025):
- FIDES(Microsoft Research): 情報フローポリシーを強制し、データ機密性ラベルの追跡と「検査」アクションを追加
- AC4A: OSスタイルでツールとデータを階層構造で管理し、最小権限の運用モードを強制
- これらのプロジェクトは、MVMがセキュリティとアクセス制御を内蔵できる可能性を示している
- オープンソースのエージェントランタイム: langchain, Semantic Kernel, llguidance はランタイムサービスを提供し、安定したAIアプリケーション開発を支援している
- MVM仕様では、モデルの学習データがインターフェース仕様を反映する必要があり、モデルとMVMの共進化が必要
MVMの利点
- 関心の分離: モデルロジックと統合ロジックを分離し、モデルを交換可能なコンポーネントへと変える
- 新しいモデルへの置き換えやプラットフォーム移行時にも相互運用性を維持できる
- 組み込みの安全性とガバナンス: MVMは権限確認、監査ログ、安全装置を通じて安全性を保証する
- AC4Aのように、MVMがゲートキーパーとして機能し、予期しない振る舞いを抑制する
- 透明な性能追跡: ランタイム診断により、モデル性能、リソース消費、データアクセス水準を提供する
- ベンチマークによって、正確性、有用性、応答性を比較可能
- モデル出力の検証: ゼロ知識証明のような技術で出力の完全性を確認し、信頼性と説明責任を強化する
結論
- AIモデル仮想マシンは、AIシステムの複雑さを減らし、相互運用性を高めるために必要
- セキュリティ、プライバシー、移植性、信頼性を強化し、開発速度とエコシステム拡張性を高める
- テクノロジー企業、スタートアップ、学術界の研究を土台として、MVM仕様はAIモデルが安全かつ円滑に相互作用できる標準を提供する
- コミュニティとの協力を通じて、MVM仕様の必要性と含めるべき要素について合意形成を目指す
1件のコメント
Hacker Newsの意見
この記事は具体的な説明が不足していて、正確に何を提案しているのか分からないと感じる。VM（Virtual Machine）というのは、いずれにせよ命令セット、制御フロー、レジスタなどに関わるものだが、この記事は認可（authorization）にしか焦点を当てていない。結局のところ「モデルが外部世界と相互作用できるようにする sandbox、jail、container のような何か」を語っているように見える
本当にVM実行エンジン、あるいはLLM向けのDockerの話をしているのか疑問がある。全体としては包装だけされた話に見える。パッケージングシステムの設計が雑だと大惨事になり得ると思う。Pythonのさまざまなパッケージングの経験を見れば分かる
VMという言葉を見て、すぐにsandboxとかなり近いものだと感じた。記事でも「隔離」と言っているので、曖昧だとか情報不足だとは感じなかった。ただ、著者の主張はあまりに自明で、解決策も不完全だ。OSやハードウェアレベルのsandboxに入れても、エージェントがIAM設定の誤ったAWS CLIのようなものを見つければ厄介なことになる。リモート境界も複雑だ。新しい洞察は見つからなかった。用語選びが問題だとは思わない
記事で定義している意味なら、現在のAI agentもすでにVMで動いていると言える。たとえばMCP hostでユーザーの実行同意を求めたり、Claude codeのように特定パターンのコマンドを自動承認するルールを置いたりできる
LLMにどんなツールを与えるかではなく、どんな行動をできるようにするかが本質的な問題だと思う。たとえば航空券予約のシナリオで、LLMにさまざまなWebサイトで価格比較から決済までしてほしいとする。しかし、無駄に3ドル安い37時間の航空券のようなものを選んではほしくない。福利厚生情報の照会も本人のものだけ見られればよく、同僚のものは見られないべきだ。同じツールでも権限の範囲は異なる。HR担当者なら自分が管理する従業員情報は当然見られるが、その場合は監査記録などの問題が追加される。つまり、行動よりも意図（intent）の方が重要だ。LLMをユーザーの代理人として、同じ権限の箱の中に入れるのが望ましい
結局言っているのは capability security model だ。ソフトウェアエージェントがアクセスできる capability を明示的に渡し、このリストの外の行動は物理的にできないようにすべきだ。しかし実際に、このモデルを実装した mainstream OS は存在しない。いくつかの研究（OS EXAMPLES: EROS, Fuchsia, Sandstorm）や試みは多かったが、市場ではあまり成功しなかった。だから実際に最も近い方法はVMを使って、必要な道具だけをVM内に置くやり方だ。これは完璧ではないが、ツール自体が本物の capability に比べて汎用的すぎる。最小権限の原則で作られたソフトウェアは、市場ではしばしば失敗する
ツールがどんな行動をできるかが重要なのではなく、ツールがアクセスできるデータと行動の組み合わせの方が重要だ。LLMの行動は完全には予測できないので、信用すべきではない。たとえばLLMには航空券予約サイトへのアクセスだけ許可し、SSNや銀行口座情報などは渡さないようにすべきだ。これはデータの出所（provenance）と権限の問題だ。機密データを持つタスクほどより多くの制約が必要で、逆に機密性が低ければより多くの行動を許可できる。データは権限情報を持つべきで、mediator が新たに spawn されるタスクにどのデータ・行動を持たせるかを制限しなければならない。例として、旅行計画タスクが下位タスクである航空券検索を spawn する場合、mediator は下位タスクには日程の一部のような非機密データだけを渡し、機密データへのアクセスは防ぐべきだ
LLM agent は、ユーザーと同じもう一人の user と見なせばよい。コンテキストごとに異なる権限を持つ。たとえば、あるソースコードフォルダには読み書き権限、別のフォルダには読み取り専用権限だけを持つ。各プロジェクトごとにLLM agentが持つ権限は異なり、それはユーザーの権限の範囲内での共通部分または部分集合になる。基本的には Allow、Deny、そして Ask（許可要求）の3種類の権限タイプがあり、必要に応じてユーザーに許可の可否を尋ねる。問題は、既存のOSおよびアプリ／データ権限が十分に細分化されていないことだ。gitですら全体アクセスではなく、特定コマンドだけ許可されるよう設計されるべきだ。今はアプリケーションがそれぞれユーザー空間でこれを真似し、ぎこちない方法で実装している。ワークフローは sudo に似ている。自分のLLM Agent userとしてアプリを起動すれば、そのコンテキストに応じて権限が付与・制限される。自分が要求したときだけ、自分の許可範囲内で行動できる。しかし現在は各agenticアプリがこのプロセスを自前で実装しなければならないので、体系的なOSサービスにすべきだ。暫定的には、agentコンテキストごとに一時的なユーザーアカウントを作成・削除し、IPCやネットワークだけで通信する形で回避できる
こうしたモデルが本当に機能するのか疑問だ。LLMが何かできたとしても、Webサイト側はそれを検知して価格を調整したり、意思決定ツリーを壊したりできる。それなら最初から、すべてのサイトがLLM向けAPI、あるいは「rss + json」を使う方がはるかに良い。BBSやSMSメニューシステムのように、単純なデータと選択肢だけ与えればLLMにも最適だ。広告も同様だ。LLMにわざわざ広告を見せる必要はなく、むしろLLMをだまそうとする広告の方が効果的だ。たとえば航空券検索時に、広告がLLMを誘惑して自社商品が最高だと誤認させられる。実際、AIがまだ単純なので、AI専用広告が出てくれば面白そうだ
「良い応答」の定義と執行が可能なら、そもそもLLM自体が不要かもしれない。HR担当者のケースでは意図を直接尋ねられるが、LLMには意図がないという点で難しいと思う
以前、John CarmackがMetaでXROSを作る際に時間と金だけ浪費したという HN投稿 を見たことがある。今日見たこの記事は逆に、「新しいOSの必要性」を強く主張している。VMは完全なOSではないが、既存のOSやコードベースを活用して軽量に作れる点が違う
その2つの記事はまったく別の話だ。実際のところ、この記事がVMや新しいOSの必要性を強く主張しているようにも見えない。結局は access control の話がすべてだ
XRでは performance と dev experience が中心だった一方で、LLMの側では tool/data へのアクセスをどう sandbox して単純化するか自体が核心だ。LLMが実行環境を壊したりデータを破壊したりしないようにすべきことが多く、標準があれば再学習の負担を減らせるし、他人のモデル活用もしやすくなる。XRはSDK程度ならトレーニングで解決できるが、AIは研究開発と compute のコストがはるかに大きい
WebAssemblyは基本的にsandboxを提供するので、半分ほどは到達していると思う。残っているのは、instance 間でデータや権限を移すための明確なインターフェースと、instance 同士がどう相互生成するかという方法だ
この記事が新しいOSを書く根拠になるとは思わない。AI向けの実行環境を構築することと、AIに最適化されたOSをゼロから設計することはまったく別だ
記事を詳しく読み、参考リンクも見た結果、この記事は単なる「AI向けVM」以上に、もっと根本的な問題を指摘していると感じた。VMだけではLLMワークフローのセキュリティを担保するには不十分だ。最上位のワークフローはネットワーク、PII、credentials などの機密性の高い作業やデータにアクセスしなければならず、LLMは prompt injection と整合性の問題に脆弱だ。単にLLMをVMに入れても解決しない。作業単位でワークフロー、データ、計算をパーティショニングし、最小限の下位 task だけが制限された情報にアクセスできるようにする「情報フロー管理」が必要だ。機密作業を担う subset だけを別途信頼・検証すべきだ。この記事が言及する「Secure Orchestrators」と、FIDES論文 が核心だ。「VM」とは結局、制限された権限／データだけを与えたコンテナで task を実行することだ。orchestrator がこのコンテナを作り、適切な権限を与え、生成されたデータにも機密度（taint-tracking）ラベルを付けるべきだ。全体として、「VM for AI」という表現よりも「partitioning」や「isolation」、そしてデータの問題を強調する方が適切だと思う
Microsoft Wassette に似ているように聞こえる
ワークフローという概念自体をなくすことが目標になるべきだ。LLM+VMの組み合わせでは、tool をLLMに提供すること自体がワークフローだ。この方式はすでにしばしばうまく機能するが、事前定義されていない例外状況や、道具そのものが必要な作業には限界がある。しかもワークフローベースでは、常に線形的（あるいはDAGやloopを含む）な限界を超えにくい。次の段階は、ツールを最初から提供せず、LLMが必要になった時点でその場でツール自体を作り出すことだ。問題によっては brute-force 的なアプローチが必要だ
この記事を読みながら、最近の文章はAIが書いたように見えることがあると思った。ホスティング側の立場からすると、どんな環境であれAI agentを安定して動かすこと自体が大きな挑戦だ。開発者として wsl の rootless docker devcontainer を使っているが、一部のマルウェアには突破されるかもしれないとしても、VMアプローチよりこちらの方が安全に感じる。しかも再現性や環境分離といった利点もあり、AIが自分の環境を壊してもコンテナを立て直せばいいだけなので気が楽だ
商業的に最も進んでいるモデルデプロイの方式を見ると、隔離などこの記事で言及されているほぼすべての特徴はすでに実装されている。OSそのもののレベルではないが、機能としては似ている。とはいえ、この程度でも十分ではない。エージェントがまともに働くには重要なリソースへのアクセス権が必要で、その権限を本当に必要な分だけ与えるのは、LLM自体を隔離することよりはるかに難しい。LLMセキュリティの正確なモデルは「untrusted userspace」だ。OS全体を設計する必要はない
LLMの隔離は、VM設計レベルで徹底すべきだという意見に同意する。これは従来のOSでこうした振る舞いを厳格に適用するのと同じ理由による。最近、このブログ にアイデアをまとめてみた。LLMの動作方式と従来のOSプロセス／タスクを比較する形で考えており、主要な抽象化は実装が難しくない。— 8つのLLM backendの chat/tool interface を統合して、tool approval を中央管理できる。capabilities model はまだ実装していないが、過去のOS（VSTa）の経験からすると自然なやり方だ。一つのLLMが保有する権限の subset を別のLLMに委譲できるべきで、そのための delegation ツールもすでに作ってある
VMのような新しい抽象マシンを作るのは、かえって複雑さを増すだけだと思う。既存のアカウント、ファイルの読み取り／書き込み／実行権限、そして一時的またはリモートアクセスは access token で十分カバーできる。あらゆる capabilities model はこうした概念で十分実装できると思う。私は既存のツールを単純化する方が望ましいと考える。ソフトウェア全体の根本的な変化を期待して皆が新しいことを試している今こそ、むしろ無駄な複雑さを減らしてシンプルにする時期にすべきだ。たとえば、MCPサーバーをClaudeで簡単なCLIツールに変えるのに10分もかからない。それでも十分実用になると感じる
現代のデスクトップOSのセキュリティモデルは、この時代にはあまりにも不十分だ。ユーザーに大した警告や確認もなくすべての権限を渡してしまうのは、ほとんど狂気に近い。本当に無制限の環境を望むなら、その選択肢を与えるべきだが、デフォルトは最小権限であるべきだ。プログラムごとにドメイン単位の権限だけを与える必要がある。たとえばディスク使用量を可視化するツールなら、ファイルシステム全体へのアクセスは必要かもしれないが、ローカルネットワークやインターネットへのアクセスは不要だ
VMの最大の強みは、被害範囲を限定できることだ。優秀なagentはシステム内で zero day を使って簡単にシステムを突破できる。ユーザー権限だけでも十分危険であり、エージェントの知識をファイアウォールで制限するのは非常に難しく、インターネット上には回避手段が多い。こうしたシステムクラッキングに非常に長けるようになるはずなので、非常に堅牢なセキュリティ装置が必要だ
LLM環境では、一回限りの読み取り（temporary read）というものは成立しない。一度コンテキストに入った瞬間、エージェントが死んでコンテキストが削除されるまで、接続されたあらゆる場所にデータが漏えいしうると考えるべきだ。これはVMであろうとなかろうと同じで、VMだけではセキュリティソリューションにはならない
大筋では同意する。多くのセキュリティリスクは、VMの有無に関係なく発生する。今後は defense in depth がより重要になるだろうが、現時点では攻撃者がAI agentを使ってユーザーに害を与えられる簡単な手段が多すぎる
ファイル編集ツールだけでも許可された瞬間、実質的にあらゆるセキュリティを失うことになる
Fuchsiaは、AIモデルの動作制御において現実的なOSになりうると思う。object capability OS なので、各コンポーネント（プロセス）は明示的に与えられた capability にしかアクセスできない
ChatGPTがコードを実行するとき（たとえばCSV処理の依頼）、特定のツールとライブラリにだけアクセス可能なVM、sandbox化されたディスク、そしてインターネット非接続の環境で実行されているように見える。結局、すでにこういう構造に近づいている
DevinやOpenHandsも似ている。私が数か月前に進めたAIパイロットプロジェクトでも、「agentをVMで実行（デフォルト）」が中核要素だった
AKS（Azure Kubernetes）ベースのKubernetesにgvisorとJupyterが載った形だ
必ずしもそうではない。たとえば1台のマシンで2つのAI（ChatGPTなど）を動かすと仮定しても、協調動作や相互運用性に関する標準がまったく存在しない