VPSでFirecracker microVMは実行できますか？

VPS で Firecracker microVM を実行できますか？

VPS で Firecracker microVM を実行できるのは、/dev/kvm が提供されている場合だけです。Firecracker は、Linux 内部の仮想化層である KVM（kernel-based virtual machine）上に構築された VMM（virtual machine monitor）です。KVM には CPU から仮想化命令が提供される必要があります。VPS では、プロバイダーがその命令をゲストにパススルーする場合に限り利用できます。多くのプランでは、この機能は提供されていません。

したがって、最初に確認すべきなのは、どの microVM ツールをインストールするかではありません。現在契約しているマシンで、そもそも microVM をホストできるかどうかです。これはホスティング環境の問題であり、約 1 分で確認できます。

インストール前に /dev/kvm を確認する

VPS 自体で次の 3 つのコマンドを実行します。

ls -l /dev/kvm
systemd-detect-virt
grep -cE '\b(vmx|svm)\b' /proc/cpuinfo

microVM をホストできる環境では、次のように表示されます。

crw-rw---- 1 root kvm 10, 232 Aug 10 09:12 /dev/kvm
kvm
16

1 行目は KVM デバイスノードで、kvm グループが所有しています。2 行目は、このマシン自体が KVM 上で動作するゲストであることを示します。VPS では正常であり、想定される状態です。3 行目は、ハードウェア仮想化フラグを報告する CPU コア数を数えています。Intel では vmx、AMD では svm です。ゲスト内で 0 より大きい値になる場合、ハイパーバイザーが nested virtualization を提供しています。

次に、ユーザーがデバイスを開けることを確認します。これは Firecracker の公式 getting started ドキュメントにあるテストです。

[ -r /dev/kvm ] && [ -w /dev/kvm ] && echo "OK" || echo "FAIL"

デバイスノードが存在する状態で FAIL となる場合、問題はハードウェアではなく権限です。sudo setfacl -m u:${USER}:rw /dev/kvm で自分のユーザーにアクセス権を付与するか、sudo usermod -aG kvm ${USER} で自分をグループに追加して、再度ログインします。

Ubuntu には、これらすべてを 2 行の出力にまとめて確認するコマンドもあります。

sudo apt update && sudo apt install -y cpu-checker msr-tools
sudo kvm-ok

正常なホストでは、INFO: /dev/kvm exists に続いて KVM acceleration can be used と表示されます。利用できないホストでは、INFO: Your CPU does not support KVM extensions に続いて KVM acceleration can NOT be used と表示されます。物理マシンでは、代わりに INFO: KVM (vmx) is disabled by your BIOS と表示される場合があります。この場合はファームウェアで修正できます。VPS では実際のファームウェアを確認しているわけではないため、このメッセージはまれです。

各 /dev/kvm の結果は何を意味しますか？

ノードが存在し、フラグ数が 0 より大きい。 ハードウェア仮想化が有効なので、Firecracker は動作します。残る制約は CPU 機能ではなくメモリです。サイズ設計のセクションに進んでください。

ノードがなく、systemd-detect-virt が kvm または qemu を出力し、フラグ数が 0。 VPS は仮想マシンですが、ホストが仮想化をパススルーしていません。フラグはハイパーバイザーが構成した仮想 CPU の属性なので、ゲスト内に何をインストールしても変わりません。sudo modprobe kvm_intel は modprobe: ERROR: could not insert 'kvm_intel': Operation not supported で失敗し、sudo dmesg | grep -i kvm にハードウェアサポートの不足が記録されます。共有 VPS プランでは、これが一般的な状態です。プロバイダーに、そのプランが nested virtualisation に対応しているか確認してください。対応していない場合は、別のコマンドではなく、別のホスティングが必要です。

systemd-detect-virt が lxc、lxc-libvirt、または openvz を出力する。 プランはコンテナ仮想化であり、ホストのカーネルを共有しています。読み込む独自のカーネルがないため、/dev/kvm は表示されません。この場合も、パッケージをインストールして解決することはできません。

フラグは存在するが、ノードがない。 単にモジュールが読み込まれていません。sudo modprobe kvm_intel を実行してください（AMD では kvm_amd）。その後、ls -l /dev/kvm を再度確認します。ノードが表示されたら、再起動後も読み込まれるようにモジュール名を /etc/modules-load.d/kvm.conf に記述します。

arm64 を使用している。 vmx と svm は x86 用の名前なので、動作している arm64 マシンでも、そうでないマシンでも grep の数は 0 です。arm64 では、デバイスノードと読み取り・書き込みテストの結果を確認してください。

エージェントの作業にコンテナではなく microVM を使う理由

コンテナは、namespace と cgroup で隔離した、あなたのカーネル上のプロセスです。カーネルは 1 つしかなく、そのカーネルはホストのものなので、カーネルレベルのエスケープが発生するとホストに到達します。microVM はハードウェア仮想化境界の内側で独自のカーネルを起動し、ホストの完全なシステムコールインターフェースではなく、小さなエミュレートデバイスモデルと通信します。Firecracker はこのモデルを意図的に小さく保っています。エミュレートするデバイスが少ないほど、脱出経路も少なくなるためです。

この違いはコーディングエージェントにとって重要です。エージェントが実行するコードは、誰も事前に確認していないコードだからです。エージェントはパッケージをインストールし、ビルドスクリプトを実行し、失敗するとマシンの速度で再試行します。カーネルを分離すれば、問題のある処理による被害を、削除できるマシンだけに限定できます。

要件は、この仕組みから直接決まります。ハードウェアによる分離にはハードウェア仮想化が必要であり、VPS プランによってはハードウェア仮想化が提供されません。コンテナにはこの機能が不要です。そのため、コンテナはこれまで販売されたあらゆるプランで実行できます。

したがって、/dev/kvm がない場合は、コンテナベースの コーディングエージェント用の使い捨て VM が適切な選択です。これは妥協案ではなく、実効性のある制御です。重要な認証情報を保持していないホスト上で使い捨てコンテナを実行し、問題が起きるたびに snapshot から復元すれば、実際に起こる問題の大半を防げます。VPS 上でコーディングエージェントを実行するという、より単純な構成でも同じことが言えます。エージェントを未確認のコードに対して数時間、自動実行する場合で、ホストを自由に提供できる場合は、microVM を選択してください。

マイクロVMエージェントホストに必要な要件

Nehemiah は、この種のソフトウェアの現行例です。Apache-2.0 ライセンスのデーモンで、要求に応じて AI に実際の Linux マシンを提供します。1 台のマシンにつき 1 つの Firecracker microVM を使用します。README には要件が明記されています。「/dev/kvm を備えた Linux ボックス」、より正確には「/dev/kvm を備えた Ubuntu 24.04、x86_64 または arm64（ベアメタル、または nested virtualization を有効にした VM）で、root で SSH 接続できること」です。

記載されているセットアップは、そのホスト上で実行する 1 つのコマンドです。

git clone https://github.com/boringcomputers/nehemiah
cd nehemiah && npm install
NEHEMIAH_ANTHROPIC_KEY=sk-ant-... ./infra/setup.sh root@YOUR_BOX_IP

infra/setup.sh は SSH 経由で事前チェックを実行し、要件を満たさないホストでは早い段階で停止します。ハードウェアに関する拒否メッセージは次の 2 つです。

/dev/kvm missing — the box needs hardware/nested virtualization
box arch is ${ARCH}; nehemiahd needs x86_64 or aarch64

最初の文字列が、この投稿の要点です。インストーラーは、ls -l /dev/kvm で確認したものと同じ項目を確認します。多くの VPS プランでは、結果も同じく期待外れになります。

事前チェックを通過すると、インストール対象はホスト全体になります。Firecracker とその jailer、Go ツールチェーン、ゲストカーネルと root ファイルシステム、Python ゲストイメージ、ブラウザーを含むオプションのデスクトップイメージ、そして nehemiahd.service と boring-net.service という 2 つの systemd unit を導入します。デーモンはポート 8080 で応答し、ヘルスチェックに失敗すると /healthz didn't return ok を出力します。SKIP_DESKTOP=1 を指定するとデスクトップイメージを省略できます。README によると、このイメージのビルドには約 8 分かかります。

コマンドを貼り付ける前に注意点を確認する

新しいホストで root SSH 接続を要求します。 インストーラーは root としてシステムパッケージ、systemd unit、ネットワーク設定を書き込みます。何もない状態から再構築してもよいマシンを指定してください。すでにサイトを運用しているサーバーは指定しないでください。

デーモンはデフォルトで 0.0.0.0:8080 に bind します。 このポートに到達できるユーザーは誰でもマシンを作成でき、そのマシンはインストーラーに渡した model key を消費します。NEHEMIAH_TOKEN を設定して認証を必須にするか、BIND_LOCALHOST=1 を設定してデーモンを 127.0.0.1 のみに bind し、ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP を使用するトンネル経由でアクセスしてください。キーは、AI エージェントから Secret を除外する場合と同様に、ホスト上の他の Secret と同じように厳重に管理してください。

各マシンは、インターネットにアクセスでき、エージェントが事前インストールされたコンピューターです。 README には、node、python、git とともに、ゲスト内の claude、codex、cursor、pi が記載されています。プロジェクトの説明では、ゲストは egress firewall の背後にあり、分離境界自体も実際に機能します。ただし、ゲストは設計上ネットワークにアクセスします。パッケージを取得できない coding agent は役に立たないためです。air gap であると想定せず、この点を前提に計画してください。

タグ付きの release はありません。 2026 年 8 月 10 日時点で、repository にはタグが 1 つもありません。そのため、main を clone すると、その日の朝に追加された内容が取得されます。commit に pin し、サーバー上で root として実行する前に script を確認してください。

git clone https://github.com/boringcomputers/nehemiah
cd nehemiah
git checkout ae743fd5c05aecb6ae4bb52bac6bce198b01ebaa
less infra/setup.sh

repository は 2026 年 6 月末に作成されたため、まだ新しい software と考えて扱ってください。取得した update ごとに infra/setup.sh を読み直してください。承認する対象は library の version bump ではなく、マシンへの root access だからです。

インストーラーを疑う前に KVM が動作することを確認する

セットアップに失敗し、原因が KVM かどうかを確認したい場合は、Firecracker を単独でテストします。以下は upstream のダウンロード手順です。

ARCH="$(uname -m)"
release_url="https://github.com/firecracker-microvm/firecracker/releases"
latest=$(basename $(curl -fsSLI -o /dev/null -w %{url_effective} ${release_url}/latest))
curl -L ${release_url}/download/${latest}/firecracker-${latest}-${ARCH}.tgz | tar -xz
./release-${latest}-${ARCH}/firecracker-${latest}-${ARCH} --version

バージョンが表示されれば、バイナリが対象アーキテクチャに一致し、実行できることを確認できます。ただし、KVM へのアクセスまで確認できるわけではありません。そのため、前述の /dev/kvm に対する read および write テストも組み合わせて実行します。この 2 つを組み合わせると、ホスティング環境の問題とパッケージングの問題を切り分けられます。結果として、実際には正常だったインストーラーを調査し続けずに済みます。

複数の microVM にはどの程度のサーバーが必要ですか？

各 microVM は実際のゲストカーネルと割り当てたメモリを保持し、そのメモリはマシンの稼働中ずっと確保されます。そのため、ホストはゲストのサイズと同時に稼働させる台数を基準に選定します。以下の数値は測定値ではなく、計算値です。ヘッドレスゲストには 1 GB、ブラウザーを使用するデスクトップゲストには 2 GB を割り当てます。ホスト自身、デーモン、イメージのビルド用に、ホスト側で一律 2 GB を確保します。

[
  {
    "label": "1 headless guest",
    "guests": 1,
    "guest_ram_gb": 1,
    "host_ram_gb": 3
  },
  {
    "label": "4 headless guests",
    "guests": 4,
    "guest_ram_gb": 1,
    "host_ram_gb": 6
  },
  {
    "label": "4 desktop guests",
    "guests": 4,
    "guest_ram_gb": 2,
    "host_ram_gb": 10
  },
  {
    "label": "8 desktop guests",
    "guests": 8,
    "guest_ram_gb": 2,
    "host_ram_gb": 18
  }
]

ヘッドレスマシンを 1 台稼働させる場合、必要なメモリは約 3 GB です。KVM を提供する中規模の VPS であれば収容できます。4 台では 6 GB が必要です。デスクトップマシンを 8 台稼働させると、ディスク容量を 1 GB も加算しない段階で、同じ計算により 18 GB が必要になります。

ディスク容量は、計画から漏れやすい要素です。ホストには、ゲストカーネル、ベース root filesystem、ゲストの種類ごとのイメージ、稼働中の各マシンのスナップショットが保存されます。ブラウザーを含むデスクトップイメージが最も大きくなります。README にはディスク容量の数値がないため、推測に頼らず、最初のビルド中に df -h / を監視してください。

そのため、「どの VPS で Firecracker を実行できますか」という質問への正直な答えは、「別のクラスのマシンが必要です」になることがよくあります。ベアメタルでは、ハイパーバイザーに妨げられずに CPU フラグを利用できます。これは、VPS と専用サーバーのどちらを選ぶかにおけるトレードオフです。仮想プランで nested virtualization を提供するプロバイダーもあります。VPS で nested virtualization を使用する方法では、料金を支払う前に利用可否を確認する方法を説明しています。ハードウェアをすでに所有している場合は、通常の VPS と Proxmox の比較として、ハイパーバイザー側から同じ問題を検討できます。

サーバーは、費用の安い側でもあります。エージェントに渡した各マシンは、稼働中ずっとモデルのトークンを消費します。そのため、アイドル状態の microVM はメモリを消費し、負荷の高い microVM はメモリと API 利用料を消費します。1 GB のプランではホストを収容できません。ホストを収容できるプランでも、鍵の費用までは賄えません。

FAQ

VPS で Firecracker を実行できるか確認するにはどうすればよいですか？

VPS で ls -l /dev/kvm、systemd-detect-virt、grep -cE '\b(vmx|svm)\b' /proc/cpuinfo を実行します。kvm グループが所有するデバイスノードがあり、フラグ数が 0 より大きければ、Firecracker を実行できます。ノードがなく、カウントが 0 の場合は、ハイパーバイザーが仮想化機能をパススルーしていません。cpu-checker パッケージの sudo kvm-ok を KVM acceleration can NOT be used で実行すると、この状態を確認できます。arm64 では、vmx と svm は x86 の名称なので、カウントを無視してください。

VPS の内部からネストした仮想化を有効にできますか？

できません。ネストした仮想化はホスト側で、ハイパーバイザー自身のカーネルモジュール内で有効にします。その設定は、割り当てられた仮想プロセッサの CPU フラグとしてゲストに渡されます。ゲスト内では、仮想 CPU に使用できる VMX がないため、sudo modprobe kvm_intel は modprobe: ERROR: could not insert 'kvm_intel': Operation not supported を返します。選択肢は、プランでネストした仮想化を提供するプロバイダーを選ぶか、自分でハイパーバイザーを所有するマシンを使うことです。

コーディングエージェントをサンドボックス化するにはコンテナで十分ですか？

多くの場合は十分です。コンテナはカーネルを共有するため、カーネルレベルのエスケープが発生するとホストに到達します。ただし、重要な認証情報を保持していないマシン上で使い捨てのコンテナを使用すれば、実際に直面するリスクの大半を取り除けます。エージェントがレビュー前のコードを対象に長時間 unattended で実行され、/dev/kvm を備えたホストを用意できる場合は、microVM を選択してください。用意できない場合は、起動を管理できない microVM よりも、タスクごとに破棄するコンテナのほうが適しています。

microVM エージェントのホストにはどの程度の RAM が必要ですか？

まずゲストのサイズから考えます。1 GB のヘッドレスゲスト 1 台と 2 GB のホスト予約領域には、合計で約 3 GB が必要です。2 GB のデスクトップゲスト 8 台には、約 18 GB が必要です。ディスクは別に必要で、見積もりを誤りやすい項目です。ホストにはカーネル、root ファイルシステム、ゲストの種類ごとのイメージ 1 つ、実行中のマシンごとのスナップショットが保存されるためです。