- microsandbox は、信頼できないユーザーおよび AI のコード実行に対して、安全な 仮想マシンレベルの分離 を提供
- 超高速起動（200ms 未満）、OCI コンテナ互換性、セルフホスティング などにより、既存の VM・コンテナの欠点を克服
- 多様なプログラミング言語向け SDK と CLI ツールにより、開発者および AI ツールとの統合効率を最大化
- コード実行、開発環境、データ分析、Web 自動化、アプリホスティング など、幅広い AI・開発ユースケースに適している
- すべての作業はプロジェクトベースで管理 でき、システム全体へのインストールやセッション維持／分離実行環境をサポート
- microsandbox は、信頼できないユーザーコードや AI コード（例: AI エージェント、ユーザー投稿コード、実験的コード）の安全な実行のために設計された オープンソースのセルフホスティングプラットフォーム
- 従来のローカル実行にはセキュリティ脆弱性、コンテナにはカーネル共有による不完全な分離、従来型 VM には起動の遅さ、クラウドには柔軟性不足という欠点がある
- microsandbox は、microVM（超軽量仮想マシン）ベースの真のプロセス分離 をサポートしつつ、コンテナ同様の高速起動と開発者フレンドリーな体験を提供
- 初期環境セットアップ後 200ms 以内の起動、コンテナイメージ（OCI）互換性、MCP ベースの AI 統合、自社インフラ利用の制御などで差別化
主な特徴の要約
- Bulletproof Security: microVM ベースで、コンテナの脆弱性（カーネルエスケープ）を根本的に遮断する 仮想マシンレベルのセキュリティ を提供
- Instant Startup: 初回起動時間は 200ms 未満で、VM と比べて圧倒的に短いコード実行開始速度を実現
- Self-Hosting & Full Control: クラウド依存なしで ローカル・自社サーバーに直接構築・運用 が可能
- OCI 互換: 標準コンテナイメージをそのまま実行でき、既存の Docker・コンテナワークフローと互換
- AI-Ready (MCP 対応) : Claude、Agno などの MCP ベース AI と 自然に統合・拡張 可能
高速な開発・実行ワークフロー
1. サーバー起動
- シンプルなコマンドだけで microsandbox サーバーを起動し、開発環境を構築可能
- サーバーは MCP サーバーの役割も兼ねるため、Claude などの AI ツールから直接呼び出して利用できる
2. SDK のインストール
- Python、JavaScript、Rust など主要言語向けの microsandbox SDK を提供
- 追加言語への幅広い対応（SDK 拡張性の提供）により、開発者・AI 統合の可能性を広げる
3. コードを安全に実行
- Python、JavaScript、Rust など複数言語のサンドボックス環境を個別に選択して実行可能
- 各サンドボックスは独立した実行環境であり、外部コード実行時でもシステムの安全性を保証
- SDK のサンプルを通じて、非同期・自動化された安全なコード実行プロセスを容易に実装できる
プロジェクトベースの環境管理
- プロジェクト単位で Sandboxfile（設定ファイル）を作成・管理し、開発者フレンドリーなパッケージマネージャー風ワークフローに近い
- 複数のサンドボックス環境（例: 異なる言語や設定）をプロジェクトに追加し、バージョンや環境ごとに管理可能
- プロジェクトサンドボックス実行時、ファイルおよびインストール変更内容はローカルディレクトリ（./menv）に自動保存
- 一時サンドボックス有効化オプションにより、セッション終了時にすべての記録と状態を完全削除して分離可能
システム全体のサンドボックスインストール
- よく使う環境やアプリを個別の実行ファイルとしてインストール・登録可能
- ターミナルからプロジェクトパスなしでも 1 行コマンドで即座にサンドボックス実行環境に入れる
- サンドボックスごとに名前を付け、異なる設定を複数運用でき、セッション状態も継続して保持される
主な活用事例
AI コード実行および開発環境
- AI が実際のソースコードのビルド・実行・デバッグまで自動化する際、分離され再現可能な開発環境を迅速に提供
- Web アプリ生成・バグ修正・プロトタイプなどのコード自動化に適している
データ分析
- NumPy、Pandas、TensorFlow など主要なデータサイエンスライブラリをサンドボックス内で安全に活用
- 個人情報や機密データなど、保護が必要な分析ワークフローに最適
Web ブラウジングエージェント
- Web サイト探索、フォーム送信、ログイン、データクローリングなどの自動化業務を AI が安全に実行
- コンテンツ収集、価格比較、自動テストなどの用途に有用
インスタントアプリホスティング
- ユーザーが作成したツール、デモ、計算機、可視化などを即座にサービスとして共有可能
- 各アプリは個別の分離空間で動作し、一時環境の高速な作成・終了をサポート
システム構成
- ユーザーは自身の ビジネスロジック から microsandbox SDK を呼び出す
- サーバープロセス（microsandbox server）に 信頼できないコードの受け渡し・実行 をリクエスト
- サーバー内では各実行リクエストが別々の microVM で実行され、相互に分離される
- 各 microVM は独立した Python/Node 環境を構成可能
オープンソースポリシー
- Apache License 2.0 の下でオープンソース配布
1件のコメント
Hacker Newsの意見
こういう方式なら、単純な permission や jail ベースのコンテナは 0% に近く、Docker は 50% 以上、Microsandbox は 100% 近くになるのではと期待している
「なぜ単に jail を使わないのか」のような問いに対する直感的な疑問を解消できそう
また、オープンな Web 上に honeypot コンテナを立てて、ハッキングに成功したら現金やコインで報酬を出す形で、100% を達成するコンテナが何かを“証明”するのも面白そう
最近は Rowhammer や Spectre のような脆弱性のため、従来型・クラウドコンピューティングのセキュリティ自体を再定義する必要もある
結局のところ、完全なエミュレーションなしで 100% 安全なコンテナを開発することと、OS の基本サービスを安全化することについてのインサイトを得たいという動機がある
カーネル LPE(Local Privilege Escalation) 脆弱性があれば、そのままコンテナ脱出につながるため
通常はコンテナ脱出として表示されないが、業界ではカーネル LPE があると言われれば、当然コンテナセキュリティは破られるものと認識される
目に見える代替案は、サンドボックス内部でのシステムコール(API)利用を大幅に制限する方法だが、この場合コンテナはもはや汎用プラットフォームではなくなり、その都度ケース別に新しくチューニングしなければならない不便さがある
そのため仮想化(virtualization)が必要だという立場
メモリセーフで堅牢な OS が出てこない限りこの方法しかなく、そうした OS が出たとしても、MicroVM をホスト Linux 上で動かすより速いかどうかはまだ未知数
Docker や systemd では各種設定によってセキュリティレベルが大きく変わる
どの設定がどのリスク/セキュリティレベルにつながるのか、大規模な実験データセットが必要だと思う
現実には本番環境そのものが無数のハッカーの攻撃対象
こうしたインセンティブモデルは面白いかもしれないが、実際の攻撃対象としての競争力や金銭的インセンティブは、現実の環境よりはるかに小さいだろう
たとえば Windows で VM を実行すると、何かが動き始めるまで数秒以上待たされる
ここで言う「何も実行していない」というのは、ユーザープログラム実行前、ファームウェアの最初の命令すら始まる前の状態
しかも仮想ディスクファイルを空にする作業の前や、VM ウィンドウが開く前にも長く待つ区間がある
なぜなのか気になる
ただし標準カーネルベースだと timeout や polling など、かなり時間のかかる動作が多い
UEFI/CSM システムでは仮想ハードウェア準備、システム環境初期化などにもかなり時間がかかる
WSL2 は不要なオーバーヘッド除去用の特別なカーネルを使っていると推測される
各種 OS サービス起動、ファイルシステム準備、キャッシュ準備、ネットワーク構成なども影響する
従来方式ではブートローダー → initramfs → メイン OS をそれぞれ別々にロードする
起動時間を極限まで縮めるには、Amazon Firecracker のように事前初期化した VM イメージをそのままメモリに載せる方式を使う
Firecracker MicroVM紹介
Windows では HyperV など、どのハイパーバイザーを使うかによって起動速度が異なる
HyperV UEFI はかなり遅く、多くの Linux ディストリビューションは最適化された最小カーネルを提供していない
VirtualBox の場合、質問の現象がはっきり見られ、昔のバージョンにはこうした遅延はなかった
「従来型 VM」の本質的な限界というより、そのソフトウェア固有の問題である可能性がある
一般に VM は不要な要素までエミュレーションするので遅い
もし起動速度重視でハイパーバイザーを作り、レガシー互換性を無視できるなら、Firecracker のように 125ms で起動することも可能
1GB 単位で割り当てれば劇的に速くなる可能性がある
Windows にもおそらく似た仕組みがある
自分は Hyper-V で Ubuntu 22 GUI に XRDP で 10 秒、Ubuntu 22 サーバーに SSH で 3 秒以内に接続した経験がある
それでも基本アイデア自体は非常に興味深い
近いうちに正式な配布方法を整える予定
Docker コンテナのように MicroVM を簡単に作れるようにしたのが目的
気になる点があればいつでも質問歓迎
「Sandbox is not started. Call start() first」のようなエラーが時々出る
公式ドキュメントのパターンは
async withだが、自分の使い方ではクラスごとに一度 instantiate して、複数メソッドから継続利用したいこれについて推奨方法やベストプラクティスが知りたい
ネットワーキングがどう動くのか気になる
たとえば microvm が public IP にだけアクセスできるよう制限できるのか？
つまり、microvm から local network IP にアクセスできないようにできるのか
組み込みの MicroVM 機能が OCI ランタイムインターフェースを提供するのか気になる
runc/crunの代わりに Docker/Podman でも使えるのか知りたいどうしてそんなに速いのか？
従来型 VM と比べたトレードオフは何か？
VM の隔離性が損なわれる余地はあるのか？
GUI を起動できるのか？
新しい Vagrant のようなものと考えているのか？
データの入出力はどうするのか？
もし正しく理解しているなら、これでリアルタイムにバックエンドもサーバーのように立ち上げられるのか？
サポート言語の一覧が印象的 microsandbox サポート言語一覧
貢献ガイドがもっと詳しいとよい contributor guide
以前は VM が遅くて重く、苦労した経験がある
macOS の Orbstack、特に「Linux machines」機能と比較してみたい
Orb では VM を 1 つだけ再利用しているのかも気になる
ミリ秒単位で VM を起動できるのは非常に重要な進歩
ただ、CloudHypervisor や Firecracker でも同様の実装は可能
コンテナが VM より優れているのはランタイム性能
VM が遅くなる要因は IO デバイスのエミュレーションにある
特に AI エージェント系ワークロードでは、アプリケーション側でオーバーヘッドを体感しそう
性能問題をどう解決するつもりなのか気になる
Microsandbox は libkrun を使っており、libkrun は性能オーバーヘッドを減らすために block、vsock、virtio-fs に virtio-mmio を使っている
Firecracker も本質的には似ており、E2B プロジェクトは agentic AI ワークロード処理に Firecracker を使っている
今のところ、ファイルシステム周りの問題以外に大きな性能改善計画はない
mountコマンドを一度打ってみれば何を言っているかわかる本来隠すべき情報がすべて見えてしまい、既存のシンプルなコマンドの有用性が下がっている
より深刻なのは、ユーザーが内部データ構造を直接触れてしまう点
まるでユーザーに peek, poke 権限を全部与えているようだ
コンテナというアイデア自体は良いが、カーネルが再設計されない限り、今の方式は暫定策
コンテナ内で
mountを打つと、何がそんなに致命的なのか説明してほしいHost の mount が実際にコンテナへ露出するのか？
通常は明示的に volume などをコンテナへ接続したときだけ可能だと思っていた
自分も CodeSandbox SDK や E2B でかなり楽しませてもらったが、それらとの違いや今後の方向性が気になる
内部的に Firecracker も使っているのか知りたい
自分でホスティングする構成
E2B のような microVM ベースのサンドボックスをローカル環境(Linux, macOS, Windows(予定))で簡単に実行でき、プロダクション環境への移行も容易
Firecracker の代わりに libkrun を使っている
microVM ソリューションの保守性や、セキュリティ監査が継続的に行われるのか気になる
Firecracker と OCI イメージのセットアップは難しいので、代替の登場自体を歓迎する
Kata container も扱いづらい
コンテナ最大の長所は、ディスクサイズや CPU コア数など具体的なリソースを指定せずに素早く動かせること
その状態を image や diff と比較して、プログラムが実行中のシステムにどんな変化を与えたかも確認できる
こうした手軽さを備えた超小型 VM によって、セキュリティを強化したサンドボクシングが可能になるとよい
たまに bwrap も使うが、コマンドライン向きのツールではない
テンプレート化やリモート/自動生成も可能
microsandbox のおかげで、こうしたコードを安全に分離して動かせるかもしれないという希望がある
200ms の起動遅延もライブサンドボックスプールで解決できる
OCI 互換性があるので、サンドボックス環境全体まで提供できる
これが本当に良いユースケースなのか、あるいはもっと良い代替がないのか気になる
runscエンジンは Docker/Docker Desktop 内でも実行できるただし gVisor はネットワーク並列処理などの性能が docker 比で 1/3 程度
もっと良い代替が見つからなかったので、自分で microsandbox を作った