暗い基板の上で小型の発光チップを指でつまむ様子。smolvmの小さく強力なマイクロVMを象徴するイメージ

smolvmの概要

smolvm(スモールブイエム)は、ポータブルで軽量な自己完結型VM(仮想マシン)を構築・実行するためのOSSコマンドラインツールです。GitHubのsmol-machinesオーガニゼーションで開発されており、Apache 2.0ライセンスで公開されています。実装言語の84.7%はRustが占め、2026年7月時点で4.3kのGitHubスターを獲得し、85回のリリースを重ねて最新バージョンはv1.4.7に到達しています。活発なリリースサイクルを持つ、勢いのあるプロジェクトと言えます。

smolvmの最大の特徴は、「コンテナの手軽さ」と「VMのハードウェア分離」を両立している点です。Docker Hubなどで配布されているOCIコンテナイメージをそのままマイクロVMのルートファイルシステム(rootfs)として起動でき、しかも各ワークロードは専用カーネルを持つ独立した仮想マシンの中で実行されます。VM起動にかかる時間は200ミリ秒未満と、従来の仮想マシンの常識を覆すサブ秒起動を実現しています。

つまりsmolvmは、「コンテナのようにイメージを引っ張ってきて即座に動かしたいが、共有カーネルによる分離では不安が残る」という、開発チームやSREが長年抱えてきたジレンマに対する、実践的な回答として設計されたツールです。信頼できないコード、とりわけAIエージェントが生成したコードの実行環境(サンドボックス)としての需要が高まる中で、注目を集めています。

登場の背景:コンテナとVMのジレンマ

smolvmが登場した背景を理解するには、コンテナと仮想マシンそれぞれの限界を押さえておく必要があります。コンテナはLinuxカーネルの名前空間(namespace)とcgroupを用いた分離技術であり、起動は約100ミリ秒と高速で、イメージ配布のエコシステムも成熟しています。しかしすべてのコンテナがホストとカーネルを共有するため、カーネル脆弱性を突いたコンテナエスケープが成立すると、ホストや他のワークロードまで危険にさらされます。

一方、従来の仮想マシンはハードウェアレベルの分離を提供しますが、QEMUのような汎用仮想化基盤では起動に15〜30秒を要し、イメージの作成や配布にも手間がかかります。「開発者の日常ツール」として使うには重すぎるのが実情でした。AWSが開発したFirecrackerは125ミリ秒未満で起動するマイクロVMを実現しましたが、KVM前提のためmacOSでは動作せず、ローカル開発環境への適用は困難です。

コンテナ(共有カーネル) アプリ A namespace アプリ B namespace ホストカーネル(全コンテナで共有) ハードウェア カーネル脆弱性 = 全体のリスク smolvm(VMごと分離) アプリ A 専用カーネル microVM アプリ B 専用カーネル microVM ハイパーバイザ(HVF / KVM / WHP) ハードウェア VM単位でハードウェア分離
図1: コンテナの共有カーネルモデルとsmolvmのVMごと分離モデル

smolvmはこのギャップを埋めるために、libkrunという最小構成のVMM(仮想マシンモニタ)を採用し、macOSのHypervisor.framework・LinuxのKVM・WindowsのWHPという各OSネイティブのハイパーバイザ上で直接マイクロVMを起動します。その結果、開発者のラップトップから本番サーバーまで同じ操作感で、200ミリ秒未満のVM起動という体験を提供できるようになりました。

[PR]
[PR]

主要な特徴

smolvmの特徴は多岐にわたりますが、導入検討にあたって特に重要なポイントは次の5点です。

1. OCIコンテナイメージをそのまま利用

Docker HubやGHCR(GitHub Container Registry)で公開されているコンテナイメージ、docker saveで書き出したアーカイブ、展開済みディレクトリを、そのままVMのrootfsとして利用できます。既存のコンテナ資産を作り直す必要がなく、Dockerデーモンも不要です。

2. サブ秒起動と弾性リソース

起動時間は200ミリ秒未満で、対話的な開発フローを妨げません。リソースは既定で4 vCPU・8GiB RAMが割り当てられますが、virtio balloonによる弾性メモリにより、ホストは実際に消費された分のメモリのみをコミットします。アイドル状態のvCPUはスリープするため、複数VMのオーバープロビジョニングもほぼコストなしで行えます。

3. 既定で安全なネットワーク設計

ネットワークは既定で無効であり、明示的に--netを指定した場合も、egress(外向き通信)の許可リストで通信先ホストを制限できます。サンドボックスとしての利用を最初から想定した設計です。詳細はセキュリティ解説を参照してください。

4. 単一ファイルでのポータブル配布

pack createコマンドでVM環境を単一実行ファイル化できるほか、実行状態を含むVMスナップショットを.smolmachine形式の1ファイルとして保存・配布できます。同アーキテクチャのホストであれば、依存関係のインストールなしにそのまま実行可能です。

5. GPUアクセラレーション対応

virtio-gpu/Venus(Vulkan over virtio)により、ゲスト内からGPUを利用できます。macOSではvirglrenderer+MoltenVKが同梱され、追加設定なしに利用できます。機械学習や画像処理ワークロードの隔離実行にも道が開かれています。

3つのワークフロー

smolvmは利用シーンに応じて3つのワークフローを提供します。どのワークフローも同じCLIから操作でき、学習コストは最小限に抑えられています。

1. 一時VM実行 machine run 実行後に自動クリーンアップ 使い捨てサンドボックス CI・検証・AIコード実行 2. 永続マシン管理 create / start / exec 状態が再起動後も維持 インストール済みパッケージ保持 開発環境・常駐サービス 3. ポータブル成果物 pack create 単一実行ファイル化 .smolmachineスナップショット 配布・エアギャップ環境 すべて同一のsmolvm CLIから操作可能
図2: 利用シーン別の3つのワークフロー

一時VM実行は、smolvm machine runでVMを起動してコマンドを実行し、終了後に自動でクリーンアップされる使い捨てモードです。CIジョブや信頼できないコードの検証に適しています。永続マシン管理は、machine create / start / stop / execで名前付きVMを管理するモードで、VM内にインストールしたパッケージは再起動後も維持されます。ポータブル成果物は、環境を単一ファイルとして配布するモードです。それぞれの具体的な操作方法はインストールと基本操作で解説します。

対応プラットフォームと制限事項

smolvmはmacOS・Linux・Windowsの3プラットフォームに対応しています。特にmacOSでネイティブ動作するマイクロVMツールは希少であり、Apple Silicon搭載機を開発標準とする組織にとって大きな意味を持ちます。一方で、以下の制限事項も導入前に把握しておくべきです。

  • ネットワーク: TCP/UDPのみ対応で、ICMP(ping等)は利用できません。
  • ボリューム: 共有できるのはディレクトリのみで、単一ファイルやブロックデバイスのマウントには対応していません。
  • macOS: コード署名とentitlements(ハイパーバイザ利用権限)が必要です。公式バイナリでは設定済みです。
  • Windows: GPUアクセラレーション、fork、スナップショットが未対応です。

check_point

制限の多くは「軽量・安全側に倒す」という設計判断の結果です。ICMP非対応やディレクトリ限定のボリューム共有は、攻撃面(アタックサーフェス)を減らす効果も持っています。要件との適合性は技術比較のページで他技術と併せて検討してください。

[PR]
[PR]

まとめと次のステップ

smolvmは、OCIイメージのエコシステムをそのまま活かしながら、ワークロードごとに専用カーネルを持つハードウェア分離を200ミリ秒未満の起動時間で提供する、新世代の軽量仮想マシンツールです。コンテナ代替のセキュリティ強化策として、またAIコード実行のサンドボックス基盤として、企業の技術部門が評価する価値は十分にあります。

次のステップとしては、まずアーキテクチャ解説でlibkrunを核とした内部構造を理解し、続いてインストールと基本操作で実際に手を動かすことをお勧めします。導入判断に必要な他技術との違いは技術比較に、具体的な適用シーンは企業活用シナリオにまとめています。