世界を動かす技術を、日本語で。

マイクロサンドボックス:コンテナのように感じ、動作する仮想マシン

概要

microsandbox は、信頼できないユーザーやAI生成コードを安全かつ高速に実行するための 超軽量仮想化環境 を提供。 microVM による堅牢な分離、 200ms未満の即時起動自己ホスト型 の柔軟性を実現。 OCI対応 で標準コンテナイメージ利用可能、 AI統合 も容易。 SDK・プロジェクト管理機能 で開発・運用が効率化。 多様なユースケースに最適な セキュリティと利便性 を両立。

microsandboxとは?

  • 信頼できないコード (AI生成、ユーザー投稿、実験用コードなど)の安全な実行基盤
  • 従来手法の課題
    • ローカル実行: 悪意あるコードでシステム全体が危険
    • コンテナ: カーネル共有による高度な攻撃リスク
    • 従来VM: 10秒以上の起動遅延で生産性低下
    • クラウド: 柔軟性や独立性に欠ける
  • microsandboxの特徴
    • microVMによる真の分離 とセキュリティ
    • 200ms未満の高速起動 で即時利用
    • 自己ホスト でインフラ完全管理
    • OCI準拠 で標準コンテナイメージ対応
    • MCP対応 でAIツールとの連携が容易

SDK クイックスタート

  • サーバー起動

    • インストール: curl -sSL https://get.microsandbox.dev | sh
    • サーバー起動: msb server start --dev
    • MCPサーバーとして Claude・Agno等 のAIツールと連携可能
    • 必要に応じてイメージ取得: msb pull microsandbox/python
  • SDKインストール

    • Python:pip install microsandbox
    • JavaScript:npm install microsandbox
    • Rust:cargo add microsandbox
    • 他言語SDKも順次拡充中
  • コード実行例

    • Python
      import asyncio
      from microsandbox import PythonSandbox
      async def main():
          async with PythonSandbox.create(name="test") as sb:
              exec = await sb.run("name = 'Python'")
              exec = await sb.run("print(f'Hello {name}!')")
              print(await exec.output())  # Hello Python!
      asyncio.run(main())
      
    • JavaScript
      import { NodeSandbox } from "microsandbox";
      async function main() {
          const sb = await NodeSandbox.create({ name: "test" });
          try {
              let exec = await sb.run("var name = 'JavaScript'");
              exec = await sb.run("console.log(`Hello ${name}!`)");
              console.log(await exec.output()); // Hello JavaScript!
          } finally {
              await sb.stop();
          }
      }
      main().catch(console.error);
      
    • Rust
      use microsandbox::{SandboxOptions, PythonSandbox};
      #[tokio::main]
      async fn main() -> Result<(), Box<dyn std::error::Error>> {
          let mut sb = PythonSandbox::create(SandboxOptions::builder().name("test").build()).await?;
          let exec = sb.run(r#"name = "Python""#).await?;
          let exec = sb.run(r#"print(f"Hello {name}!")"#).await?;
          println!("{}", exec.output().await?); // Hello Python!
          sb.stop().await?;
          Ok(())
      }
      
    • 初回起動時はイメージ取得のため時間がかかるが、以降は高速実行

プロジェクト管理機能

  • パッケージマネージャ風ワークフロー

    • msb initSandboxfile 作成・環境定義
    • msb add app --image python --cpus 1 --memory 1024 --start 'python -c "print(\"hello\")"'
      • appという名のsandboxをSandboxfileに登録
    • Sandboxfile例
      sandboxes:
        app:
          image: python
          memory: 1024
          cpus: 1
          scripts:
            start: python -c "print(\"hello\")"
      
    • msb run --sandbox appまたはmsr appでsandbox起動
    • プロジェクト内のsandboxは ./menvに永続化、再起動しても状態維持
  • 一時的なsandbox実行

    • msb exe --image pythonまたはmsx python
    • 実験・単発用途に最適、終了時に完全削除
  • システムワイドなsandboxインストール

    • msb install --image alpineまたはmsi alpine
    • 任意のターミナルからsandbox名で即起動
    • msi alpine:20250108 slim-linuxのように 複数インスタンス管理用途別命名 が可能
    • インストール済みsandboxは 状態維持、毎回同じ作業環境

主なユースケース

  • コーディング・開発環境

    • AIエージェントが本格的な開発ツールでアプリ構築
    • Git操作・依存管理・テストまで 完全分離環境 で安全実行
    • ミリ秒単位の起動 で高速フィードバック
    • AIペアプログラミング、教育、コード自動生成基盤
  • データ分析

    • AIによる 安全なデータ処理・分析・レポート生成
    • NumPy・Pandas・TensorFlow等の強力ライブラリ利用
    • プライバシー重視の金融・医療・研究用途
  • Webブラウジングエージェント

    • AIによる 安全なWeb自動操作・データ抽出
    • 価格比較、調査、フォーム自動入力など
    • テスト・自動化・情報収集ツール基盤
  • 即時アプリホスティング

    • AIが生成したツール・プロトタイプを 即座に共有・公開
    • ゼロセットアップ、 自動リソース管理・クリーンアップ
    • 教育・デモ・ユーザー向け即時価値提供

サーバーアーキテクチャ概要

  • クライアント側
    • ビジネスロジック→microsandbox SDK
  • サーバー側
    • microsandbox serverが 信頼できないコードをmicroVMで実行
    • microVMごとに Python/Node等の独立環境 を提供

開発・ライセンス

  • 開発参加歓迎
    • セットアップ・ビルド・テスト・リリース方法はDevelopment Guide参照
    • 貢献ガイドラインはCONTRIBUTING.md
  • ライセンス
    • Apache License 2.0 採用
  • GitHub Star History
    • 多くの支持・成長を記録

microsandbox は、AI時代の 安全・高速・柔軟なコード実行基盤 として、開発者・AIエージェント・自動化ツールに最適な選択肢。

Hackerたちの意見

シェアしてくれてありがとう!私はmicrosandboxのクリエイターです。プロジェクトについて知りたいことがあれば、気軽に聞いてください。このプロジェクトは、あなたのマシンからマイクロVMを作成するのを、Dockerコンテナを使うのと同じくらい簡単にすることを目的としています。何でも聞いてくださいね。

いい感じですね。もし私の理解が正しければ、これを使ってバックエンドをすぐに立ち上げられるってことですか?サポートする言語のリストがすごく野心的ですね。https://github.com/microsandbox/microsandbox/tree/main/sdk 追記:新しい言語をサポートするための詳細な貢献者ガイドがあると助かります。https://github.com/microsandbox/microsandbox/blob/main/CONTR...

READMEをざっと見ただけなんですが、いくつか質問があります。どうしてこんなに速いんですか?従来のVMと比べて何かトレードオフがあるんですか?VMの隔離が危うくなる可能性はありますか?中でGUIを動かせますか?これを新しいVagrantだと思いますか?データの入出力はどうすればいいですか?

すごくいいですね!これは私が作っている分散型/非中央集権的なソフトウェアテストネットワーク(Valet Networkって呼んでます)にめっちゃ役立ちそうです… 質問ですが、ネットワーキングはどうなってますか?マイクロVMを制限して、公共のIPアドレスだけにアクセスできるようにすることはできますか?(つまり、マイクロVMがローカルネットワークのIPアドレスにアクセスできないようにしたいんです)

macOSのサポートについてはどうなってますか?

DockerでできることはMicrosandboxでも全部できるの?それとも、コンテナの方が理にかなってる場合もあるのかな?発表おめでとう!

俺は中程度のスペックのノートパソコンを使ってて、時々遅いか高いインターネット環境でUbuntuを動かしてるんだ。ほぼネイティブスピードで「コピー」を動かせるようにしたいんだ。1. 各コピーは独自のネットワーク設定を持ってほしい、例えばWireGuardやVPNを使えるように。2. 信頼できるツール(Firefox、Zoom、Citrixなど)のために、ホストへのGUIパススルーが必要。3. 軽量であること。例えば、Gnome Boxesは設定が超簡単で動くけど、リソース使用量はネイティブより明らかに高かった。4. オプション - もっとセキュリティがあればいいな(例えば、GitHubリポジトリやnpmからの半信半疑のソフトウェアを動かすかもしれないから)、でも奇跡は期待してないし、エスケープの可能性は受け入れてる。5. オプション - COWを使ってホストとディスクを共有できればいいな、そうすれば環境特有のパッケージだけインストールすれば済むから、フルOSをインストールする必要がなくなる。今、Podmanのソリューションに取り組んでるけど、うまくいくと思ってる(でも再構築するとネットワークが厳しくなるみたいで、レイヤーを調整してこれを減らせることを願ってる)。Microsandboxはこの用途に何か利点がある?

今これを試してるんだけど、すごく期待できるよ。Pythonライブラリで一つ問題があって、サンドボックスを数分間動かしておきたいんだ。変数を一度設定して、数回後にそれを使いたいから。時々このエラーが出るんだ:エラー: サンドボックスが開始されていません。最初にstart()を呼んでください。サンドボックスを長く維持するための提案はある?ドキュメントにあるコードパターンはこれだよ:async def main(): async with PythonSandbox.create(name="my-sandbox") as sb: exec = await sb.run("print('Hello, World!')") print(await exec.output())。私のコードの仕組み上、特定のクラス用にサンドボックスを一度だけインスタンス化して、その後クラスメソッドから何度も呼び出したいんだけど、「async with」パターンにはうまく合わないんだ。何かおすすめある?

ちょっと横道にそれた質問ですが、従来のVMを起動するのにそんなに時間がかかるのはなぜですか?少なくともWindowsでは、従来のVMを起動すると、何かを実行するまでに数秒かかります。追記:何かと言っても、ユーザープログラムのことではなくて、ファームウェアの最初の命令が実行される前、つまり仮想ディスクファイルがゼロにされる必要がある場合のことです。この間、VMを一時停止することはできません。ウィンドウがまだ表示されていないからです。表示されても、何も実行されていないので、しばらくは一時停止できません。だから、カーネルやファームウェアの初期化の遅さは私の質問には関係ありません。なぜなんでしょう?

まあ、基本的にはコンピュータをゼロから起動してるわけだから、納得できますね。メモリを割り当てて、仮想CPUを起動して、デバイスを初期化して、BIOS/UEFIチェックを実行して、ハードウェアの列挙をして… そのすべてをエミュレートしながらやるので、実際の実装よりも遅くなることが多いです。セキュリティのためのプロセスもいろいろあって、ページをゼロにするようなことに追加の時間がかかるんでしょうね。VMが私のハードウェアの大部分を使うと、起動からログインプロンプトまで数秒かかりますが、これは私のArchデスクトップがボタンを押してからログインプロンプトが表示されるまでの時間と同じです。

Linuxカーネルを1秒以内で起動するために多くを最適化できますが、標準のカーネルを使っている場合、タイムアウトやポーリングの試行があって、カーネルが起動するのに無駄な時間がかかります。また、VMがUEFI/CSMシステムで仮想ハードウェアを準備して、ブートローダーのためにシステム環境を初期化するのにもそれなりの時間がかかります。WSL2は不必要なオーバーヘッドを避けるために特別なカーネルを使っていると思います。OSサービスを起動したり、ファイルシステムを設定したり、キャッシュを準備したり、ネットワーキングを設定したりする必要もあります。UKIやそれに類似したツールを起動していない場合、ブートローダーを読み込んでからinitramfsをメモリに読み込み、メインOSを読み込んで実際に必要なサービスを起動する必要があります。それぞれのステップには特定のデーモンやハードウェアプローブが正しく動作する必要があります。この問題を解決するためのツールもあります。AmazonのFirecrackerは、基本的にVMの初期化された状態を保存して、それをメモリに読み込むことで、コンテナと同じくらいの時間(ミリ秒単位)でLinux VMを起動できます。https://firecracker-microvm.github.io/ Windowsでは、使うハイパーバイザーによると思います。Hyper-Vはかなり遅いUEFI環境を持っていて、ハードディスクのアクセスもいつも遅い気がしますし、ほとんどのLinuxディストリビューションはそれ用の専用のミニマルカーネルをパッケージしていないようです。

どのVMソフトを使ってるのか、もうちょっと詳しく教えてほしいな。VirtualBoxだと、君が言ってることはすごく目立つし、古いバージョンではそんな遅延はなかったから、単にそのVMソフトの問題かもしれないね。一般的な「従来のVM」の問題じゃないと思うよ。

VM自体を作るのは速いよ。中で何を動かすかによるけどね。ユニカーネルVMは数ミリ秒で起動できるよ。例えば、OSvをチェックしてみて。

それはVirtualBoxの問題っぽいね。俺はHyper-Vを使ってるけど、XRDPを通してGUIのUbuntu 22に10秒で接続できるし、Ubuntu 22のサーバーには起動後3秒でSSH接続できるよ。

答えは、必ずしもそうである必要はないってこと。実際には、仮想マシンは互換性のためにあまり必要のないものをエミュレートしようとしてるんだ。起動速度に最適化されたハイパーバイザーを構築して、一般的なレガシーソフトウェアをサポートしなくて済むなら、こうなるよ:> 従来のVMは起動に数秒かかることがあるけど、Firecracker VMはわずか125msで起動できる。

これめっちゃいいね!最近の超軽量でほぼ使い捨てのVMオプションの数はすごいよね。昔はVMって遅くて、使いづらくて、ほんとに苦痛だったのを覚えてるよ。これ、macOSのOrbstackの技術スタック、特に「Linuxマシン」機能と比べてどうなんだろう?Orbは単一のVMを再利用してるのかな?

発表おめでとう!ミリ秒でVMを起動できるのは確かに重要だけど、CloudHypervisorやFirecrackerでも実現できるよね。コンテナがVMに勝るのはランタイムパフォーマンスだよ。VMの場合、IOデバイスのエミュレーションからくるオーバーヘッドがあるから、AIエージェント的な用途ではそのオーバーヘッドが目立つと思う。パフォーマンスの問題に対処する計画はある?

君の言う通りだね。私たちはlibkrunを活用してるよ。Libkrunは、ブロック、vsock、virtio-fsのためにvirtio-mmioトランスポートを使って、オーバーヘッドを最小限に抑えてるから、基本的には上流で行われたパフォーマンス改善に依存してるんだ。Firecrackerも同じで、E2BはそれをエージェントAIのワークロードに使ってるよ。とりあえず、今はファイルシステムの問題を修正する以外に大きな計画はないんだ。

これいいね!正式なコンテナセキュリティグレードがあったら面白いと思う。具体的には、1) 既知の(コンテナ)エクスプロイトのリストを作る 2) セキュリティが増す環境でそれぞれのエクスプロイトを実行する(権限ベース、ジャイル、Docker、エミュレーターなど) 3) 防げたエクスプロイトの割合が0〜100%のスコアになるって感じ。これだと、権限やジャイルを使った単純なコンテナ化は0%くらいになりそうで、Dockerは50%以上、Microsandboxは100%に達する可能性があると思う。この考え方は「なんでジャイルを使わないの?」みたいな疑問にも答えてくれるかもね。それに、コンテナはオープンウェブ上のサイトでハニーポットとして運用できて、奪取したら現金や暗号通貨の賞金がもらえるってのも面白いかも。どのコンテナが100%達成するかを「証明」するためにね。あと、「安全」とは何かを再定義する必要があるかもしれない。RowhammerやSpectreみたいなエクスプロイトがあるから、ほとんどの従来のクラウドコンピューティングが不安定になる可能性があるし。もしかしたら、64ビットの暗号化がかつては安全とされていたけど、今は128ビット以上が必要みたいに、移り変わるものかもしれない。追記:このアイデアの背景には、エミュレーションなしで100%安全なコンテナを見つけることがある。パフォーマンスやコスト削減のメリットがあるし、さまざまなサービスをコンテナ化することでOSのセキュリティを向上させるヒントも得られると思う。

悪意のあるコンテナに対抗する安全なコンテナランタイムは作れないよ。根本にはLinuxカーネルがあるからね。Linuxコンテナを意味のあるサンドボックスにする唯一の方法は、サンドボックスに提供するシステムコールAPIの範囲を大幅に制限することだけど、そうするとその価値がすぐに減っちゃう。もはや「どんなワークロードも投げ込める汎用プラットフォーム」じゃなくて、毎回調整や再構成が必要な特注のものになっちゃう。だから、仮想化が必要なんだ。しっかりとハードニングされてメモリ安全なOSができるまでは、それが唯一の方法だと思うし、もしそんなOSを作ったとしても、Linuxホスト上でMicroVMを動かすより速いかどうかは不明だね。

問題は、少なくともマルチテナントのワークロードに関しては、「コンテナの脆弱性」そのものじゃなくて、標準のコンテナがカーネルを共有することに基づいているから、すべてのカーネルLPEが潜在的なコンテナの脱出につながるってことだよ。そういうバグの歴史は長いし、ほとんどの場合「コンテナの脱出」としてはフラグが立てられない。カーネルのLPEがコンテナを壊すってのは、なんとなく理解されてることなんだ。

ある意味、コンテナはすでに現金や暗号通貨の賞金を持つハニーポットとして機能してるよね。これを「プロダクションコード」って呼ぶんだけど、昼夜問わず穴を探してる人がたくさんいる。こういう仕組みは概念的にはいいアイデアだけど、実際に提供される金銭的インセンティブは本当のターゲットに比べたら微々たるものだろうね。

重要なのは、マシンの設定を見たいってこと。Dockerやsystemdのスパンには、セキュリティレベルを大きく変えることができる要素がたくさんある。これがあれば、何をすべきか、どの設定がどんなリスクにつながるかがはっきりすると思う。基本的に、巨大なアブレーションを見てみたいな。

すごく良さそうで、試してみるのが楽しみ!CodeSandbox SDKやE2Bを使って成功したこともあるけど、比較や今後の方向性について何か考えを共有してくれない?Firecrackerも使ってるの?

Firecrackerを使ってるかどうかは分からないけど、それが一番の疑問だよね。Microsandboxが維持されるのか、ちゃんと監査が行われるのかも気になる。代替案は大歓迎だよ。FirecrackerやOCIイメージとの格闘は大変だったし、Kataコンテナも難しい。

比較や今後の方向性について何か考えを共有してくれない?Microsandboxはクラウドソリューションを提供していないよ。自己ホスト型で、E2Bがやってることを簡単にするために設計されてる。Linux、macOS、Windows(予定)でマイクロVMベースのサンドボックスを使いやすくして、プロダクションにスムーズに移行できるようにね。 > Firecrackerも使ってるの?libkrunを使ってるよ。

こういう話題にはいつも興味津々。コンテナのいいところは、すぐに何かを実行できることだよね。例えば、docker run --rm ...って感じで、ディスクサイズやCPUコア数を指定しなくてもいいし。実行中のプログラムが何をしたかを、コンテナの状態をイメージと比較して確認できるのが好き。だから、同じことを小さなVMでやって、より良いサンドボックスを持ちたいんだ。たまにbwrapも使うけど、あれはコマンドラインで使うためのものじゃないしね。

YAMLの設定フォーマットがあって、それを一度宣言すればいいから、テンプレート化したり、リアルタイムで生成したり、リモートから取得したり、いろんな方法があるよ。

完全に信頼できないコードを実行する必要があったことある? それなら、インストール手順にはリモートスクリプトを直接Bashにパイプするっていうのが含まれてるよ… ああ、皮肉だね… とはいえ、そのコンセプト自体は興味深い。

最初はあなたの発言がよく分からなかった。ごめんね、笑。インストーラスクリプトをダウンロードして、自分で監査することもできるよ。後でちゃんとした配布を設定するつもり。

私の感覚では、コンテナ技術はOSを押し進めすぎてると思う。mountって入力すると、すぐに何を言いたいか分かるよ。隠れるべきものが目の前に出てきて、シンプルなシステムコマンドの有用性を壊してる。さらに悪いことに、ユーザーがデータ構造をいじれるんだ。ユーザーにpeekやpokeコマンドを与えるようなもんだね。コンテナのアイデアはいいけど、カーネルが再設計されるまではハックだよ。

これにはPythonとNodeの環境があるから、OSや任意の実行ファイルをホストできる意味でのVMではないの?

それはLinuxのVMで、そこに動作する任意の実行ファイルをホストできるよ。見えているPythonやNodeの環境は、SDKが動作するための一部なんだ。実際、使い方はDockerにすごく似てるよ。