1.52MBのバイナリが3.5msでコンテナを起動する──ルートレスサンドボックス「kern」をAI生成コードの実行にどう使うか

3行まとめ

1. kernは、デーモンなし・1.52MBの単一バイナリで動くルートレスのサンドボックス／コンテナランタイム。READMEはdocker runの297msに対し約3.5msでの起動を実測値として掲げる。
2. AI生成コードなど「信頼できないワークロード」の実行を主眼に据え、--security-profile untrusted一発でseccomp・cgroup v2・名前空間隔離の組み合わせを適用する。
3. インストールスクリプトを実際に確認すると「kern is Linux-only」と明記されており、macOSには対応していない（Windowsは公式にWSL2経由）。

「コンテナ・サンドボックス・リソース分割ツール」を1つにまとめた

READMEはkernの立ち位置を「比較表に単独の行で収まらない」ものだと表現する。理由は、コンテナランタイムであり、サンドボックスであり、リソース分割器であり、スタックランナーでもある機能を、1.52MBのバイナリ・デーモンなしで同時に持つからだ。具体的には次の4つを1バイナリでこなす。

• 実際のOCIイメージを扱えるコンテナ：pull・Dockerfileからのbuild・commit・push・save/loadに対応。イメージからの起動は約3.5ms
• 常にルートレスなサンドボックス：ユーザー・PID・マウント・ネットワーク・UTS・IPCの各名前空間、overlayまたは読み取り専用rootのpivot、拒否優先（deny-by-default）のseccompアローリスト、cgroup v2の制限。--security-profile untrustedフラグ1つで、これら強化策一式をまとめて適用できる
• 隔離だけでなくリソースプロファイル：CPU（vcpu:）・メモリ・ディスク（vdisk:）・デバイス（vgpio:）をkern.tomlに一度定義し、名前で呼び出す。kern runはサンドボックスなしでホスト上のプロセスに同じ上限を適用でき、--landlock-rw <path>はカーネル自身のLSM（Landlock）でそのプロセスの書き込み先を絞り込める
• kern形式・Docker形式どちらのスタックも動かせる：kern compose <file> upはkern-compose.toml（上記のリソースプロファイルを[box.NAME]として書ける）も、既存のdocker-compose.ymlも変換なしでそのまま受け付ける

READMEはkernを「ハイパーバイザーではない」と明言している点も正直だ。隔離の境界はLinuxカーネルであり、カーネルの特権昇格バグはそのまま脱獄経路になる——これはDocker・Podmanも同じ条件で、だからこそgVisorやFirecrackerのようなプロジェクトが存在する、という文脈まで書かれている。裏を返せば「信頼できないコードを、あなたが選んで、その被害範囲を自分で引き受けて動かす」ためのツールという位置づけだ。

実測値：3.5ms vs 297ms

READMEに掲載されているデモの説明によれば、Intel i7-14700KF・Linux 7.0の環境で、kern box app --image alpine -- echo hello from a real containerの起動が約3.5ms、同等のdocker runが約297msだったという。全体を通じて「静止時のRAM使用量0」（デーモンもソケットも起動時に存在しない）という特徴も掲げられている。Rustの依存ツリーは事実上libcだけで、JSON・OCIマニフェストのパースは自前実装、pullはマシンに既にあるcurl・tarを呼び出す形でTLSスタックのリンクを避けている。バイナリサイズはサイズ最適化ビルドで1.52MB、cargo installによるソースからの通常ビルドでは1.91MBになる、とREADMEは注記している。

READMEには2つの比較表がある。1つはkern・Docker・Podmanの機能比較。

もう1つはkern・bubblewrap・runc・podman・dockerの性能比較（README「Performance」節、Intel i7-14700KF・Linux 7.0.0での自分で再実行可能なスクリプトpython3 examples/benchmark.pyによる計測とREADMEは説明している）。

READMEはさらに「3,000個を同時に起動しても約2.2秒、動作中のbox1個あたりのメモリコストは約0.3MB」とも書いている。ただし同じ節に「あなたの環境ではCPU・カーネル・ファイルシステムによって数字は変わる」という発行元自身の注記もある。

周辺ツールとAIエージェント向けの入口

ps・logs・exec・stats・inspect・wait・top（ライブTUI）・doctorといった管理コマンド一式に加え、Python／Node.js向けSDKと、エージェント向けのMCPサーバーが用意されている。Pythonバインディングは2つの使い方があり、1つは通常のコードツールとして、もう1つはLangChainのシェルミドルウェアに対する実行ポリシーとして——Dockerを使う場合の実行ポリシーと対等な選択肢として——組み込める、とREADMEに記載されている。

macOSには対応していない

README本文では対応OSとしてLinux・Windows（WSL2）・ARMボードが挙がっているが、実際にインストールスクリプト（install.sh）を取得して中身を確認すると、冒頭のコメントに次のように明記されていた。

# Linux only - kern is a Linux sandbox.
...
[ "$os" = "Linux" ] || err "kern is Linux-only (detected $os)."

つまりmacOS上でこのインストールスクリプトを直接実行してもエラーで止まる。Windowsは公式にWSL2経由での利用が案内されており、ネイティブのWindowsバイナリは配布されていない。GitHub APIで確認したところ、ライセンスはApache License 2.0、この記事執筆時点でのスター数は301、言語はRust、最終pushは2026年8月29日だった。

kernとgVisor・Firecrackerの使い分け——開発元自身の線引き

SECURITY.mdには「kern or a microVM」という節があり、開発元自身がkernの適用範囲をこう線引きしている。

Reach for kern when the code is yours or semi-trusted and you want speed, density and simplicity: CI jobs, build steps, dev sandboxes, your own agent's tool-calls under your supervision. Reach for a microVM (Firecracker, Kata) or gVisor when you run actively hostile, multi-tenant code from strangers sharing one host, and a hardware-virtualization boundary is worth the startup cost. That is not where kern competes.

（コードが自分のもの、あるいは半信頼できるもので、速度・密度・シンプルさが欲しいならkernを使う：CIジョブ、ビルドステップ、開発用サンドボックス、監督下にある自分のエージェントのツール呼び出しなど。積極的に悪意があり、見知らぬ他人由来のマルチテナントなコードを1台のホストで共有実行し、ハードウェア仮想化の境界がその起動コストに見合うなら、マイクロVM（Firecracker、Kata）かgVisorを使う。そこはkernが競う場所ではない）

つまり開発元自身が「AIエージェントの生成コードを、自分の監督下で動かす」用途をkernの守備範囲として明示する一方、「見ず知らずの他人のコードを多数のテナントで相乗りさせる」ようなマルチテナントSaaS的な用途は、kernではなくgVisorやFirecrackerを使うべき領域として自ら除外している。隔離の境界はあくまでLinuxカーネルであり、カーネルの特権昇格バグがそのまま脱獄経路になるという記事冒頭の説明は、この線引きの裏返しでもある。

OPEN_ITEMS.mdが自認する未解決点──カスタムseccompプロファイルは読めない

getkern/kernはREADMEとは別に、OPEN_ITEMS.mdという「kernがまだできないこと・分かっていないこと」を開発元自身がまとめたドキュメントを公開している。この記事で確認できた項目のうち、AI生成コードの実行という用途に関係が深いものを挙げる。

• ファイルからのカスタムseccompプロファイルには対応していない：Dockerの--security-opt seccomp=<profile.json>に相当する機能はなく、同梱のアローリストか、オプトアウトのデナイリスト（KERN_SECCOMP=denylist）のどちらかしか選べない。OPEN_ITEMS.mdは、任意のOCIプロファイルを解釈するパーサーは実装を誤りやすく「バグがあってもクラッシュせず、本来拒否すべきsyscallを黙って通してしまう」ため、意図的に後回しにしていると説明している
• Landlockの動作はカーネルのビルド設定に依存し、有効化できない場合はfail-closed（安全側に倒して失敗）にする、とOPEN_ITEMS.mdは明記している
• KERN_MAX_CONCURRENTはガードレールであってリソースの上限保証ではないとOPEN_ITEMS.mdは述べている

これらはいずれも「今のところ未対応」という開発元自身の申告であり、この記事の調査で独自に発見した欠陥ではない。

「3.5ms vs 297ms」は1つの実行環境で得られた数字にとどまる

本記事はgetkern/kernのGitHub README・OPEN_ITEMS.md・SECURITY.md・GitHub APIをそれぞれcurlで取得した内容にもとづく。実際にLinux環境でkernを動かし、docker runとの起動時間差や「200 boxes並列で0.11秒」という数字を自分の手元で計測したわけではない。これらの数字は開発者自身が特定のハードウェア（Intel i7-14700KF）・特定のカーネルバージョン（Linux 7.0.0）で計測した1点であり、README自身も「あなたの環境では数字が変わる」と注記している通り、他の環境での再現性までは確認できていない。カーネルの特権昇格バグに対する脆弱性という、README・SECURITY.md自身が明記している限界についても、実際の攻撃耐性（たとえば既知のカーネルCVEに対する挙動）を検証する手段は今回持ち合わせていない。

AI生成コードの実行環境としてのkernへの言及は見当たらない

Zenn・Qiitaともに固有名詞としてのkernへの言及は見当たらなかった（Qiitaの1件はClang診断一覧の記事で無関係）。「AI生成コードをどう安全に実行するか」というテーマ自体は日本語圏でも語られ始めているが、kernという具体的なツール名での紹介はまだない。

関連記事

• AIエージェントにrm -rf ~を打たれても平気にする──macOS向けサンドボックスAgent Safehouseの仕組み
• AIセキュリティリスク──プロンプトインジェクション・データ漏洩対策【2026年】
• MCP（Model Context Protocol）とは──AIとツールをつなぐ共通規格