何が検証されたか
Simon Willison氏が、smolmachines（smolvm）をサンドボックス基盤として評価しました。テーマは明快です。ユーザーから預かった「信用できないコード」を、どこまで安全かつ高速に走らせられるか。
smolvm 1.8.3で意図通りに機能したのは次の機能群です。オフラインのローカルイメージ、ネットワーク遮断実行、CPU／RAM上限、ゲスト側で強制されるタイムアウト、ストレージのクォータ、入力の読み取り専用マウント、出力の書き込み可能マウント、そして --unprivileged フラグ。性能はコールドスタートが約0.6〜1.5秒、ウォーム実行が約50ミリ秒でした。
結論として、カーネルを共有するコンテナではなく、ハードウェアで分離されたVMを使うアプローチが、信用できないPython／JavaScriptのデータ変換に適している、という評価です。
なぜ「コンテナではなくVM」が論点になるのか
検証で挙がった機能リストを並べ替えると、狙いが見えてきます。CPU／RAM上限とゲスト強制タイムアウトは「while true を書かれても巻き添えを食わない」ための備え。ネットワーク遮断は、預かったデータを外部へ持ち出させないため。読み取り専用の入力マウントと書き込み可能な出力マウントは、ファイルシステムへの接触面を「指定したファイルだけ」に絞るためのものです。
つまり、悪意あるコードを検知して弾くのではなく、「動かしても何もできない箱」を先に用意する発想です。カーネル共有型のコンテナでは、この境界の強度がカーネルの脆弱性に引きずられます。ハードウェア分離のmicroVMなら境界が一段硬い。そのぶん重いはずの起動コストが、ウォームで50ミリ秒台に収まっている点が実務上の鍵です。ユーザーのリクエストごとに使い捨てのVMを立てる設計が、レイテンシ予算に乗るかどうかがここで決まります。
検証を阻んだ「入れ子の壁」と迂回策
興味深いのは、この検証プロセス自体です。著者はタスクをClaude Code for web上のClaude Fable 5に割り当てました。指示は「smolmachines.comを高速かつ安全なサンドボックスとして試し、RAMとCPU時間に上限をかけ、ネットワークなし、指定ファイルのみアクセス可という条件で信用できないコードを走らせるには何が必要かを探る」。目的はデータ変換のようなユーザー提供タスクの実行です。
ところが実行環境が壁になりました。Claude Codeのコンテナ自体がFirecrackerのゲスト（Linux 6.18.5-fc-v20、4 vCPU、15GB RAM）であり、/dev/kvm もvmx／svmのCPUフラグも持たない。ネスト仮想化が使えないため、smolvm machine run は「kvm not available」で失敗します。VMの中でVMを立てられない、という素直な行き止まりです。
エージェントはここでプランBに切り替えます。/dev/kvm を公開しているGitHub Actionsのubuntuランナーを使い、対象ブランチに一時的なワークフローを置いてテスト一式を実行、ログを回収し、最終コミットでそのワークフローを削除する。著者はこれを、Claude Code for webの環境的制約に対する創造的な回避策であり、Fableが徹底して能動的であることのもう一つの例だと評しています。
💼 事業会社視点：これは自社にどう効くか
AIエージェントに「ユーザーが書いたコード」や「LLMが生成したコード」を実行させる機能は、いまや珍しくありません。ECの分析ダッシュボードでCSVを整形する、SaaSの管理画面でユーザー定義の変換ルールを走らせる、社内BIで自然言語からPythonを生成して集計する——どれも入り口は同じです。そこで実行基盤をどうするかを、多くの現場が「とりあえずコンテナ」で済ませています。
役員が確認すべきは一点、顧客データを扱う実行環境の境界がカーネル共有かどうかです。マルチテナントのSaaSで、A社のデータを処理中のプロセスがカーネル脆弱性経由でB社の領域に触れうる構成なら、それは技術課題ではなく契約・監査上の課題になります。smolvmの検証が示すのは、ハードウェア分離を選んでもウォーム50ミリ秒、コールド0.6〜1.5秒という現実的なコストで済む可能性です。「安全な分離は遅いから無理」という前提は、いま検証し直す価値があります。
受託開発事業者にとっては提案材料です。生成AI機能のPoCが実装フェーズに入る段階で、実行サンドボックスの設計は見積もりに載せやすく、後付けが最も高くつく領域でもあります。
もう一つ。今回の検証ではClaude Code for webの環境がネスト仮想化不可で行き止まりになり、エージェントがGitHub Actionsへ移して完遂しました。自社でAIエージェントに開発作業を任せる際、エージェントが動く環境のケイパビリティ（KVMの有無、権限、ネットワーク）が成果物の上限を決めるという実例です。CI環境の権限設計を、エージェント前提で見直す時期に来ています。