世界を動かす技術を、日本語で。

AIモデルには仮想マシンが必要です

2025年8月30日原文(blog.sigplan.org)

概要

AIモデルを活用するアプリケーションが増加し、セキュリティや拡張性などOSレベルの品質が求められる状況 AIモデルとシステムの間に標準的な「仮想マシン」層を設ける必要性の提案 Java Virtual Machine(JVM)に着想を得て、AI Model Virtual Machine(MVM)構想を提示 既存の取り組みやプロトコルを整理し、標準化の利点と課題を解説 将来のAIシステムの信頼性・移植性・セキュリティ向上に向けた議論の出発点

AIモデルに仮想マシンが必要な理由

  • AIモデル活用アプリケーション の増加により、セキュリティやプライバシー、拡張性が重要課題
  • 従来のチャットボット は単純なREPL構造だったが、モデルの進化とMCP等の拡張プロトコルにより制御ソフトウェアが複雑化
  • AIソフトウェア にはOS同等の品質(セキュリティ、アイソレーション、拡張性、移植性)が求められる
  • ファイルアクセス等の権限制御 も必要となり、AIモデルの安全な利用環境構築が不可欠
  • AIモデルと制御層の標準化 により、モデル開発と統合ロジックの分離・再利用性向上を目指す

Model Virtual Machine(MVM)構想

  • MVMはAIモデルと外部環境の仲介層 として機能
  • ユーザー入力や履歴、システムプロンプト をAIモデルへ安全に受け渡し
  • ツール呼び出しや権限制御 もMVMが仲介・検証し、不正なアクセスや操作を防止
  • MVMが提供すべき操作例
    • モデルの認証、ロード、初期化、アンロード
    • モデルへのコンテキスト付き呼び出し
    • モデル出力やツール呼び出し結果の解析
    • ツールやデータの権限制御、メモリ管理
    • ユーザーへの入力要求や履歴管理
    • 条件分岐や逐次実行などの制御構造

既存の関連取り組み

  • OpenAI Structured Tool Calling
    • JSONベースのAPIで関数呼び出しを構造化
    • OpenAPI仕様によるプラグイン連携
  • Anthropic Model Context Protocol(MCP)
    • AIアシスタントと外部ツール・データを接続する共通プロトコル
    • USB-Cのような「共通インターフェース」志向
  • セキュアオーケストレーター:FIDES & AC4A
    • FIDES:データ機密ラベルで情報流通を制御
    • AC4A:ファイル・フォルダ階層で権限管理、全操作をランタイムで監視・制限
    • AIモデルの推論的な抜け道 への新たなセキュリティ対策も必要
  • オープンソースエージェントランタイム
    • langchainやSemantic Kernel:AIアプリ開発用の共通ランタイムサービス
    • AICI(現llguidance):モデル動作を細かく制御できる軽量VM統合

AI Model VM標準仕様の利点

  • 分離と交換性
    • モデルロジックと統合ロジックの明確な分離
    • モデルやプラットフォームの入れ替え容易化
  • 組込型セーフティ・ガバナンス
    • ツール利用や外部アクセスをVM経由で一元管理
    • 権限チェック・監査・フェイルセーフの実装容易化
    • セキュリティ要件の標準化やサプライチェーン全体の安全性向上
  • パフォーマンス・リソースの可視化
    • 実行後の診断情報やリソース消費のレポート化
    • モデル間・プラットフォーム間のベンチマーク容易化
  • モデル出力の検証性
    • ゼロ知識証明等の形式手法による出力検証・信頼性強化の可能性

結論と今後の展望

  • AI Model VMの標準仕様 策定は、AIシステムの信頼性・移植性・セキュリティ・相互運用性向上に不可欠
  • 複雑性削減と相互運用性向上 による技術的・戦略的なメリット
  • 旧来のソフトウェア仮想化の教訓 を活かし、AI分野でもポータビリティと安全性を確保
  • コミュニティ全体での議論と合意形成 が今後の重要課題

著者略歴(抜粋)

  • Shraddha Barke :Microsoft Research、AIによる証明生成やAIエージェントの信頼性向上
  • Betül Durak :Microsoft Research、セキュリティ・プライバシー・プロトコル設計
  • Dan Grossman :University of Washington、プログラミング言語・解析の専門家
  • Peli de Halleux :Microsoft Research、LLMアプリ開発効率化
  • Emre Kıcıman :Microsoft、Copilot Tuning責任者、AIセキュリティ・社会的影響研究
  • Reshabh K Sharma :University of Washington、LLMベースシステムの信頼性向上研究
  • Ben Zorn :Microsoft Research、プログラミング言語設計・責任あるAI技術

※本記事は著者個人の見解であり、ACM SIGPLANやACMの公式見解ではありません。

Hackerたちの意見

AIの時間で言うと100万年前、つまり昨日、ジョン・カーマックがXROSを作るのにメタがどれだけ無駄な時間とお金を使ったかについてHNに投稿してたんだよね。最近、新しいOSを書くのは意味がないって。で、今日のこの投稿はそれに対してすごく強い主張をしてる。(そう、VMは完全なOSじゃないし、完全なOSよりも軽量になるだろうし、業界全体で使われるだろうし、既存のOSやコードベースを使うことになるだろうし、ニュアンスもあるよね。)

主な違いは、LLMのツールやデータへのアクセスをサンドボックス化して簡素化するのが基本機能であるのに対し、XRはパフォーマンスや開発者体験に重点を置いているところだと思う。LLMが自分を動かしているコードを誤って上書きしたり、顧客データを間違っていじったり、実装の詳細に圧倒されないようにするために、かなりの労力をかけるつもりだし、これに関する標準があればずっと楽になるし、他の人のモデルのトレーニングに頼れるようになる。もしただXR SDKのトレーニングを開発者にさせるだけなら、彼らに給料を払ったり、学校に教えさせたりすればいいし。AIにはR&Dプロジェクトのためのチームと計算時間が必要で、高額になることもあるからね。

この記事は新しいオペレーティングシステムを書くことの正当性を示していない。AIが動作するための実行環境を構築するのは、AIのユースケースに最適化された新しいオペレーティングシステムをゼロから作るのとはまったく違うことなんだ。

WebAssemblyはデフォルトでサンドボックス化されるパラダイムを持っていて、ほぼその状態にあるんだ。あとは、インスタンス間でデータやアクセス権を転送するための明確なインターフェースと、他のインスタンスから新しいインスタンスを作成することが必要だね。

全然違うことだよね。しかも、関係ないって分かってるのに、なんでか無理に比較しようとしてるし…

そして今日のこの投稿は、それに対してすごく強い主張をしてる。 この投稿を読んでも、VMの強い主張なんて何も見当たらなかったし、新しいOSなんて全然。彼らが求めてるのはアクセスコントロールだけだよ。

最も進んだ商業モデルがどのように展開されているかを見ると、すでに多くの要素が含まれていて、隔離もその一部だよ。この投稿は、私がすでに存在することを知っている多くのことを概説しているようなもの。文字通りのOSの意味ではなく、提案されたすべての機能の観点からね。それでもまだ不十分なんだ。エージェントは、仕事をするために気にかけているものに強力にアクセスできる必要がある。気にかけているものに対して十分な権限を与えるのは、LLMを制御するよりもずっと難しいし、それ自体も難しい。LLMのセキュリティに適したモデルは、完全な「OS」ではなく、信頼できないユーザースペースなんだ。

信頼できないユーザースペースってのはその通りだね。こういうアプローチが少しは役立つと思うけど、著者たちは「保証する」みたいな言葉を使って過剰に主張してるよ。OSがファイルの権限を強制するように、ツールへのアクセスを制御すべきだと思う。メタファーだってわかるけど、OSの実績ってあんまり良くないよね? 予約ツールを使う許可があるか確認するって、つまりウェブブラウザってこと? ブラウザって結構強力な汎用ツールだし、脱獄のリスクもあるよね。> そのため、セキュリティ研究者は、仮想マシンの制約があってもAIモデルが敵対的な行動を取らないように新しい対策を考えなきゃいけない。これは、アラインメントを本当に解決する必要があるっていう控えめなリマインダーだね。

この記事を読み始めた瞬間から、AIが書いたんじゃないかって思うくらい、毎日ちょっと冷めてきてる気がする。記事が話しているホスティングの観点からすると、AIエージェントを機能させ続けることが大きな課題だと思うし、AIを使うのは素晴らしいけど、基本的な使い方での安定性は私にとっては厳しい。開発者の視点から見ると、私はwsl経由でルートレスのdockerを使ったdevcontainersを使ってるけど、これをバイパスできるマルウェアがあるかもしれない(このVMアプローチの方がずっと強力だろうけど)けど、ホストOSで動かすよりはずっと安全だと感じてる。それに、再現性や関心の分離といった同じ利点も得られるし、AIが環境で何かを壊した時には、単にコンテナを再構築すればいいからね。

FuchsiaはAIモデルの操作を制約するための実用的なOSになりそうだね。オブジェクト能力オペレーティングシステムとして、各コンポーネント(つまり、それがインスタンス化されるプロセス)は、明示的に付与された能力にしかアクセスできない。

その気持ちはめっちゃわかるし、Fuchsiaのデザインも好きなんだけど、実現するとは思わなかったな。新しいOSが必要ってわけじゃなくて、WASMやWASIコンポーネントに基づいたFuchsiaみたいなシステムが、クラウドからスマホまでホストできる形になるんじゃないかな。

ChatGPTを使ってコードを実行する時、例えばCSVファイルで何かをさせると、特定のツールやライブラリが使えるVM内で動いているみたいで、サンドボックス化されたディスクアクセスもあるけど、インターネットにはアクセスできないんだ。だから、もうすでにその状態に近いよね。

それもDevinやOpenHandsのやり方だね。エージェントがVM内で動くのは、少なくともデフォルトでは、数ヶ月前に私が実施したAIパイロットの重要な機能だった。

Hacker Newsで議論の続きを見る