著者 Matt Connor
VPSでFirecracker microVMは実行できますか？
Firecrackerには/dev/kvmが必要ですが、VPSでは多くのプランが未提供です。3つのコマンドで確認し、権限エラーやnested virtualizationの結果に応じた対処法を解説します。
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/cpuinfomicroVM をホストできる環境では、次のように表示されます。
crw-rw---- 1 root kvm 10, 232 Aug 10 09:12 /dev/kvm
kvm
161 行目は 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 を選択してください。
microVM エージェントホストに必要なもの
Nehemiah はこの種の構成の現行例です。Apache-2.0 ライセンスのデーモンで、要求に応じて AI に実際の Linux マシンを割り当てます。1 台につき 1 つの Firecracker microVM を使用します。2026 年 8 月 10 日時点の README には、要件が明確に記載されていました。「/dev/kvm を備えた Linux box」、より正確には「/dev/kvm（bare-metal、または nested virtualization を備えた VM）上の Ubuntu 24.04、x86_64 または arm64 で、root-SSH 接続できること」です。
その後、この要件は変更されました。2026 年 8 月 11 日、プロジェクトはセルフサービスのセットアップ手順を、管理対象ホスト向けの運用手順に置き換えました。2026 年 10 月 11 日に確認した README には、要件の記載もワンコマンドインストールもありません。現在、ホストは infra/latitude/provision.sh を備えた Latitude.sh の bare-metal サーバーに、署名済みのリリースアーティファクトからプロビジョニングされます。これは、承認済みホストに対してオペレーターが手動で実行し、その後プロジェクトの control plane が登録する手順です。運用手順の canary は、使用可能な /dev/kvm がないホストを現在も拒否します。つまり、要件がなくなったわけではありません。bare metal に移されたのです。
この変更前は、対象ホストに対して次の 1 コマンドを実行するセットアップが文書化されていました。
git clone https://github.com/boringcomputers/nehemiah
cd nehemiah && npm install
NEHEMIAH_ANTHROPIC_KEY=sk-ant-... ./infra/setup.sh root@YOUR_BOX_IP現在の main では、このコマンドは何もインストールしません。infra/setup.sh は対象外として扱われ、最初のステップで、セルフサービスの bootstrap はサポートされなくなったというメッセージを表示して終了します。preflight やインストールの処理は実行されません。README には、以前のセルフサービスインストーラーが managed runbook への参照を表示して終了するようになったと記載されています。
この投稿が最初に基づいていた commit では、infra/setup.sh が SSH 経由で preflight を実行し、ホストが要件を満たさない場合は早い段階で停止していました。ハードウェアに関する拒否メッセージは次の 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 プランでは、期待どおりの回答は得られませんでした。managed runbook でも同じ確認が行われます。
preflight を通過すると、ホスト全体へのインストールが実行されました。Firecracker とその jailer、Go toolchain、guest kernel と root filesystem、Python guest image、ブラウザーを含むオプションの desktop image、そして nehemiahd.service と boring-net.service という 2 つの systemd unit がインストールされます。health check に失敗すると /healthz didn't return ok が表示され、SKIP_DESKTOP=1 を指定すると desktop image のインストールが省略されました。当時の README によれば、このイメージのビルドには約 8 分かかりました。これらの処理、メッセージ、スイッチは、現在の main からは実行されません。デーモン自体は、デフォルトで引き続き port 8080 で応答します。
コマンドを貼り付ける前に注意点を確認する
新しいホストで root SSH を要求しました。 セルフサービスインストーラーは、root としてシステムパッケージ、systemd unit、ネットワーク設定を書き込みました。サポート対象外のその commit を実行する場合は、すでにサイトを運用しているサーバーではなく、完全に再構築してもよいマシンを指定してください。
デーモンはデフォルトで 0.0.0.0:8080 に bind します。 そのポートに到達できるユーザーは誰でもマシンを作成でき、作成したマシンはホストに渡した model key を消費します。認証を必須にするには NEHEMIAH_TOKEN を設定してください。または NEHEMIAH_ADDR=127.0.0.1:8080 を設定してください（デーモンは -addr 127.0.0.1:8080 も受け付けます）。これにより 127.0.0.1 のみで bind し、ssh -N -L 8080:127.0.0.1:8080 root@YOUR_BOX_IP を使用した tunnel 経由で接続できます。旧インストーラーの BIND_LOCALHOST=1 switch はデーモンから読み取られないため、その script の外では何も起こりません。この key は、ホスト上の他の secret と同じように慎重に扱ってください。AI agent から secret を除外する場合も同様です。
すべてのマシンは、インターネットにアクセスでき、agent が事前インストールされたコンピューターです。 README には、node、python、git とともに、guest 内の claude、codex、cursor、pi が記載されています。プロジェクトによると、guest は egress firewall の背後にあり、分離境界自体も実在します。ただし、guest は設計上ネットワークに到達できます。パッケージを取得できない coding agent は役に立たないためです。air gap だと想定せず、その前提で計画してください。
tag 付きの release はありません。 2026 年 10 月 11 日時点で、repository には tag も release もありません。そのため main を clone すると、その日の朝に追加された内容が取得されます。現在は managed 専用の code です。commit を固定してください。以下の commit は、self-serve installer が撤回される前日の 2026 年 8 月 10 日に、この投稿が書かれた時点で使用されていたものです。そのため、この commit の infra/setup.sh は引き続き install できます。プロジェクトはこの経路をサポートしていないため、サーバー上で root として実行する前に script を確認してください。
git clone https://github.com/boringcomputers/nehemiah
cd nehemiah
git checkout ae743fd5c05aecb6ae4bb52bac6bce198b01ebaa
less infra/setup.shrepository は 2026 年 6 月末に作成され、6 週間後に self-serve install を撤回しました。そのため、サポート対象の経路が変更される可能性のある新しい software として扱ってください。これより新しいものを pull する前に、README と runbook をもう一度確認してください。承認するのは library version の更新ではなく、マシンへの 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 を割り当てます。ホストは自身、daemon、イメージビルド用に 3 GB を固定で確保します。これは daemon のデフォルト予約量です（NEHEMIAH_MEM_RESERVE_MB、3072 MB）。この予約量を使い切る新しいマシンの起動を daemon は拒否するため、ホストの容量が不足している場合はメモリ不足になる前に上限へ達します。
このグラフのデータ
[
{
"label": "1 headless guest",
"guests": 1,
"guest_ram_gb": 1,
"host_ram_gb": 4
},
{
"label": "4 headless guests",
"guests": 4,
"guest_ram_gb": 1,
"host_ram_gb": 7
},
{
"label": "4 desktop guests",
"guests": 4,
"guest_ram_gb": 2,
"host_ram_gb": 11
},
{
"label": "8 desktop guests",
"guests": 8,
"guest_ram_gb": 2,
"host_ram_gb": 19
}
]ヘッドレスマシンを 1 台ずつ実行する場合、必要な容量は約 4 GB です。KVM を提供する中規模 VPS であれば収容できます。4 台では 7 GB が必要です。デスクトップマシンを 8 台実行すると、ディスクを 1 GB も含めない段階で、同じ計算により 19 GB が必要になります。
これらの数値の算出方法
ゲストのメモリに同時実行するゲスト数を掛け、daemon のデフォルトであるホスト予約量 3 GB を加えています。4 行すべてで、ゲスト 1 台あたりのサイズは同じ 2 種類を使用しています。この予約量は、オペレーティングシステム、daemon、ゲスト内にブラウザーをインストールするイメージビルドをまかないます。スナップショットとキャッシュ済みイメージはメモリではなくディスクを使用するため、この計算には含めていません。マシンの実行中に、ホスト上で free -m を使って自分のゲストを測定してください。ホストが swap を使用する状態では高速動作できません。高速な起動こそが microVM を使う理由だからです。
誰も計画に入れないのがディスク容量です。ホストには、ゲストカーネル、ベース root ファイルシステム、ゲストの種類ごとに 1 つのイメージ、実行中のマシンごとに 1 つのスナップショットが保存されます。ブラウザーを含むデスクトップイメージが大きな容量を占めます。README にディスク容量の記載はないため、推測を信頼せず、最初のビルド中に df -h / を確認してください。
Firecracker を実行できる VPS はどれかという問いに対する正直な答えが、「別のクラスのマシン」であることが多い理由はここにあります。ベアメタルでは、ハイパーバイザーを介さずに CPU フラグを利用できます。これは、VPS と専用サーバーのどちらを選ぶか におけるトレードオフです。仮想プランで nested virtualisation を公開しているプロバイダーもあります。料金を支払う前に確認する方法は、VPS での nested virtualisation で説明しています。すでにハードウェアを所有している場合は、Proxmox と通常の VPS の比較 がハイパーバイザー側から同じ問題を考えたものです。
サーバーは費用の安い側でもあります。エージェントに渡した各マシンは、実行中ずっと model token を消費します。そのため、アイドル状態の 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 を返します。選択肢は、プランでネスト仮想化を提供するプロバイダーを利用するか、自分でハイパーバイザーを管理できるマシンを使うことです。
コーディングエージェントのサンドボックス化にコンテナだけで十分ですか？
多くの場合は十分です。コンテナはカーネルを共有するため、カーネルレベルのエスケープが発生するとホストに到達します。ただし、重要な認証情報を保持していないマシン上で使い捨てのコンテナを実行すれば、実際に直面するリスクの大半を取り除けます。エージェントが未レビューのコードを対象に長時間、無監視で実行され、/dev/kvm を備えたホストを用意できる場合は、microVM を選択してください。それができない場合は、起動を管理できない microVM より、タスクごとに破棄するコンテナの方が適しています。
microVM エージェントのホストにはどれくらいの RAM が必要ですか？
まずゲストのサイズから計算します。1 GB のヘッドレスゲスト 1 台では、ホストの予約分 3 GB を含め、合計で約 4 GB が必要です。2 GB のデスクトップゲスト 8 台では、約 19 GB が必要です。ディスクは別に必要で、過小評価しやすい項目です。ホストにはカーネル、root ファイルシステム、ゲストの種類ごとのイメージ 1 個、実行中の各マシンのスナップショットが保存されるためです。