💨

余ったPCパーツで NixOS + microVM のセキュア（だと思われる）な OpenClaw 箱を作った話

に公開
NixOS
Nix
AIエージェント
OpenClaw
tech

はじめに

IPO準備中のベンチャー企業で法務として働いてるわ。仕事はそれなりにできるけど、プライベートは……まあ、察して。

最近の AI エージェント界隈、Mac mini に Docker Sandbox 載せて隔離環境作るのが流行ってるでしょ。気持ちはわかるのよ。でもね、最安構成でも94,800円。しかもメモリ高騰で新しく買うにも組むにも財布が悲鳴を上げる時期。だから余ったパーツで1台組んだの。B360M と RTX 3060 Ti、押し入れに眠ってたやつ。

で、ここからが本題。Docker の公式ドキュメントにこう書いてあるの知ってた？
"MicroVM-based sandboxes require macOS or Windows (experimental). Linux users can use legacy container-based sandboxes with Docker Desktop 4.57."
つまり microVM サンドボックスは Linux では使えないの。残されてるのは namespace と cgroup でホストカーネルを共有する legacy 方式。カーネルの脆弱性一発でホストまで届く構成ね。

それからもうひとつ、その隔離環境、壊れたらどうするの？ 手作業で Docker イメージをこねくり回して、シェルスクリプトで秘密鍵を配置して、動いたからヨシって……それ、再現できる？ ホストの OS アップデートで動かなくなったとき、同じ環境をもう一度作れる自信ある？

私がこの記事で言いたいのはひとつだけ。隔離って「閉じ込める」だけじゃなくて、同じ檻をいつでも、何度でも作り直したくない？宣言的に定義された隔離環境を、コマンド一発で再現する。NixOS と microvm.nix でそれをやった話を、これから書くわ。

なぜカーネル分離 + 宣言的再現性なのか

Simon Willisonさん が「lethal trifecta」って呼んでるものがあるの。私的データへのアクセス、信頼できないコンテンツの処理、外部への通信——この3つが揃ったとき、システムは致命的に危険になる。AI エージェントって、この3条件を構造的に全部揃ってないかしら、、
The lethal trifecta for AI agents: private data, untrusted content, and external communication

だからコンテナで閉じ込めればいいって思うでしょ？ 甘いわ。runc の CVE-2024-21626、CVSS 8.6。process.cwd の処理とファイルディスクリプタのリークを組み合わせて、コンテナの外に出られる脆弱性。しかも2025年11月には runc だけで CVE が3件同時に公開されてる。CVE-2025-31133、CVE-2025-52565、CVE-2025-52881。CNCF のブログで技術解説が出てるけど、どれもコンテナブレイクアウトに繋がるクラスの問題。コンテナはホストとカーネルを共有してるから、カーネル境界の脆弱性ひとつで「閉じ込め」が崩壊する。そういう設計なの。
runc container breakout vulnerabilities: A technical overview

面白いのはね、Docker 自身がそれをわかってるところ。macOS と Windows の Docker Sandbox が microVM を採用したのは、コンテナ隔離では不十分だと Docker が認めたようなものでしょ。なのに Linux だけ legacy コンテナに据え置かれてる。皮肉よね。

じゃあカーネル分離すれば安心かっていうと、そこで終わる話でもないの。隔離は破られる前提で設計するものよ。壊されたときにどれだけ速く復旧できるか、そっちが本当の勝負。

i3 ウィンドウマネージャの作者で知られる Michael Stapelberg が、2026年2月のブログで AI エージェント用の microVM 構成について書いてるんだけど、彼の思想は明快よ。VM は使い捨て。侵害されたら捨てて、また作る。クリーンな状態からの再構築を運用の基本にするの。

でもこれ、再構築が手作業だったら回らないでしょ。壊して、捨てて、30秒で同じものを生やす。それをやるには、環境全体——OS構成からサービス定義、秘密鍵の配置場所まで——が宣言的に定義されてないと無理なの。手順書を読みながらコマンドを打つ復旧じゃ、使い捨てにはできない。だから宣言的再現性が要るのよ。

microvm.nix + Nix で閉じ込めた

構成図

Docker Sandbox が選択肢になること自体は否定しないわ。macOS なら十分実用的よ。でも Linux で同等以上をやるなら、microvm.nix には4つの価値がある。

カーネル分離。 Docker Sandbox が macOS で microVM を使ってやっていること——独立カーネルでの隔離——を Linux でも実現する。Cloud Hypervisor が KVM の上に軽量 VM を立てて、ホストとは別のカーネルで動く。VM 間通信は nftables で制御、OpenClaw VM から gogcli VM への SSH だけを許可、逆方向も含めそれ以外は全部 drop。横移動を構造的に潰してるの。

見える檻。 閉じ込めるだけじゃ足りない。檻の中で何が起きてるか見えないと意味がないでしょ。この構成では3層の監査ログを取ってる。nftables egress チェインが VM の全外部接続を microvm-egress: プレフィクスで syslog に記録。Unbound が全 DNS クエリをログに残す。auditd が secrets ファイルへの読み書きと属性変更を監査する。Docker Sandbox は HTTP/HTTPS プロキシ経由のドメイン単位ログだけで、他プロトコルは一律ブロック。microvm.nix なら L3/L4 全プロトコルの conntrack ログが取れる。何をブロックしたかじゃなくて、何をしようとしたかが見えるの。

宣言的再現性。 ここが一番大事。flake.nix に VM 定義、ネットワーク、シークレット注入、プラグイン、ML サーバーまで全部書いてある。flake.lock が全入力の暗号学的ハッシュを記録してるから、同じロックファイルからは同じ出力が得られる。nixos-rebuild switch 一発でホストも VM もネットワークもファイアウォールも全部再構築。別マシンに git clone して同じコマンドを叩けば、同一の隔離環境が立ち上がるの。Docker の ubuntu:latest が昨日と今日で中身が違うのとは根本的に違う。Nix は「再現できるつもり」じゃなくて、暗号学的ハッシュで再現を保証する仕組みよ。……ただし完璧ではないわ。一部パッケージが upstream バイナリに依存していて、そこは Nix の保証の外。NixOS Discourse でも議論されてる話だけど、正直に言っておくべきでしょ。それでも侵害対応は systemctl stop → nixos-rebuild switch で終わり。状態を持たないから「クリーンかどうか」を悩む必要がない。

使い捨て。 これは宣言的再現性があるからこそ成り立つ話。宣言的に再構築できない環境は「捨てられない」のよ。使い捨て VM の前提条件は、いつでも同じものを生やせること。手塩にかけて育てた環境を壊せないの、わかるわ。私だって観葉植物は枯らすのに。

最後にひとつ。プロンプトインジェクション防御もやってるわ。nyosegawa さんの openclaw-defender が3層防御を提供していて、私はそれを NixOS 向けにパッケージしただけ。詳細は nyosegawa さんの解説記事を読んで。

おわりに

Mac で Docker Sandbox、それは合理的な選択よ。macOS なら microVM ベースのサンドボックスがちゃんと動くし、ほとんどの人にはそれで十分。わざわざ NixOS を入れろなんて言わないわ。

ただ、Linux でカーネル共有のコンテナにAI エージェントの全権限を載せてるの。ちょっと怖いわよね。
カーネル分離をやりたいなら microvm.nix だけが答えじゃない。Firecracker でも QEMU でも、VM を立てればカーネルは分かれる。でも Nix の宣言的モデルと組み合わさったとき、「壊して、捨てて、即座に生やす」が運用として回り始める。手順書を見ながら復旧する VM と、nixos-rebuild switch で再構築できる VM は、同じ「使い捨て」でも意味が違うのよ。

構成は GitHub リポジトリに置いたから参考にして。

これでも全然完璧じゃないから、改善点があれば@ryooo8244311427までくれると助かるわ。

……まあ、余ったパーツで組んだ箱にしては、それなりにマシな檻ができたんじゃないかしら。

参考

Discussion

ログインするとコメントできます