microsandboxの使い方——AIエージェントのコードをmicroVMに閉じ込める。入れ方・msb run・Python SDK

2026年9月16日 07:03

AIエージェントが書いたコードを、そのまま手元で走らせていませんか。

「まあ大丈夫でしょ」で走らせて、大丈夫だった日が続いているだけ、というのが正直なところだと思います。うちもそうでした。

microsandboxの使い方を調べたのは、ここを構造で塞ぎたかったからです。microsandboxは、信用できないコードを手元のmicroVM（小さな仮想マシン）の中で動かすためのOSS。Dockerに似た手触りで、中身はコンテナではなくVMです。

この記事では、GitHubの公式READMEを根拠に、何をするものか、動く条件、入れ方、CLIの msb、Python SDK、そしてAIエージェントにどう当てるかを書きます。確認日は2026年9月15日で、その時点で8.3k starsです。

microsandboxとは：信用できないコードを「手元のmicroVM」で動かす

READMEの1行目はこうです。Easy, fast, local microVMs for untrusted workloads。簡単で、速くて、手元で動く、信用できないワークロードのためのmicroVM。

誰のためのものか。READMEは対象をこう列挙しています。「untrusted workloads inside fast, local microVMs: AI agents, user code, plugins, CI jobs, dev environments, scrapers, and automation」。AIエージェント、ユーザーのコード、プラグイン、CIのジョブ、開発環境、スクレイパー、自動化。

先頭にAIエージェントが来ている。ここがこのOSSの立ち位置です。

Dockerと何が違うのか。READMEの特徴の1つ目は「Hardware-level isolation with microVM technology」。コンテナはホストのOSの中核（カーネル）を共有するのに対し、microVMは仮想マシンとしてハードウェアの段で隔離する。一般に、コンテナから抜け出す穴はカーネル共有に由来するものが多いので、隔離の段が1つ深い、という理解でいいと思います。

でも、VMって遅いでしょ？

READMEの答えは「Average boot times under 100 milliseconds」。起動が平均100ミリ秒未満。VMを1回立ててコマンドを1つ走らせて捨てる、が現実的な速さになっている。

もう1つ、手触りの話。「Runs standard container images from Docker Hub, GHCR, or any OCI registry」。中で動かすのは、普通のコンテナイメージです。Docker Hubの python をそのまま引ける。だから覚え直すことが少ない。

動く条件：Apple Silicon・KVM・WHPのどれか

入れる前に、動く条件です。VMなので、ホストの仮想化支援が要ります。

READMEの条件は3つ。macOSは Apple Silicon。Linuxは KVM が有効なこと。Windowsは WHP（Windows Hypervisor Platform） が有効なこと。

Intel Macは対象外です。ここで落ちる人が一定数いるので、先に書いておきます。

Linuxのクラウド上で使うなら、その仮想マシンでKVMが使える（入れ子の仮想化が許されている）かを先に確かめる。使えない環境では、入れても起動しません。

STEP1：入れ方は1行。パッケージ管理からも入る

入れ方は、READMEにそのままあります。

macOSとLinuxは1行。

curl -fsSL https://install.microsandbox.dev | sh

Windowsは PowerShell で irm https://install.microsandbox.dev/windows | iex。

普段使っているパッケージ管理からも入ります。Homebrewなら brew install superradcompany/tap/microsandbox、npmなら npm i -g microsandbox、Rustの環境があるなら cargo install microsandbox。

入ったら msb コマンドが使えるようになる。それだけです。常駐サーバーを立てる手順はありません。READMEの言い方だと「Spawn VMs right within your code. No setup server」。コードの中から直接VMを立てる。準備用のサーバーは無い。

STEP2：msb run で1回走らせ、create と exec で使い回す

CLIの覚え方は、Dockerと同じ並びで頭に入ります。

まず、使い捨てで1回走らせる。

msb run python -- python3 -c "print('Hello')"

python はイメージの名前。-- の後ろが、VMの中で走らせるコマンド。これでVMが立ち、コマンドが走り、終わったら消える。

次に、名前を付けて残す。

msb create --name app python
msb exec app -- curl https://example.com

create で app という名前のサンドボックスを作り、exec でその中にコマンドを送る。AIエージェントに何度もコマンドを打たせる用途なら、こちらです。毎回VMを立て直さない。

残りは片付けと確認。msb stop app msb start app msb rm app が寿命の管理。msb pull python でイメージを先に取っておく。msb ls で一覧、msb ps app で状態、msb metrics app でCPUやメモリの消費を見る。

READMEにある特徴の1つに「Sandboxes can run in detached mode」があります。切り離して長く動かせる。開発サーバーを中で立てっぱなしにする使い方は、これで賄う。

STEP3：Python SDKで、コードの中からVMを立てる

CLIで手触りを確かめたら、コードから呼びます。ここがAIエージェント向けの本体です。

SDKは4言語。TypeScript（npm i microsandbox）、Rust（cargo add microsandbox）、Python（uv add microsandbox）、Go。

PythonのクイックスタートはREADMEにこうあります。

import asyncio
from microsandbox import Sandbox

async def main():
    sandbox = await Sandbox.create(
        "my-sandbox",
        image="python",
        cpus=1,
        memory=512,
    )
    output = await sandbox.exec("python", ["-c", "print('Hello!')"])
    print(output.stdout_text)
    await sandbox.stop()

asyncio.run(main())

読み方は3行です。Sandbox.create で名前・イメージ・CPU数・メモリ（MB）を指定してVMを作る。sandbox.exec でコマンドと引数を渡し、stdout_text で標準出力を受け取る。stop で止める。

AIエージェントの側から見ると、「生成したコードを文字列で持っている」状態から、exec に渡すだけで隔離実行になる。ホストのファイルにも、ホストの鍵にも触れない。

鍵の話は、READMEの特徴に1行あります。Unexploitable secret keys that never enter the VM。秘密鍵はVMの中に入らない。中で動くコードがどれだけ好き勝手しても、鍵そのものは外にある、という設計です。

AIエージェントにどう当てるか：うちの提案

うちでは、AI社員が生成したスクリプトの実行を、まだmicroVMには閉じ込めていません。権限の線引きと、実行前の承認で止めています。

だから、ここは提案として書きます。

当てる場所は2つ。1つ、AIが「その場で書いて、その場で走らせる」コード。データ変換の一回きりのスクリプトなど。これは msb run の使い捨てで足りる。終わったら消えるので、後始末が要らない。

2つ、AIが「何度もコマンドを打って試す」作業。テストを回しながら直す、のような往復。これは create で1つ作って exec を繰り返す。SDKなら Sandbox.create を1回、exec を必要な回数。

READMEには「Agent-ready with Skills and MCP server」という特徴もあり、エージェント側からmicrosandboxを道具として呼ぶ口が用意されている。つまり「エージェントに、隔離された実行環境という道具を1つ渡す」形が、最初から想定されている。

判断が要るのは1点。ホストのファイルを読ませたい時です。隔離した中からは、ホストのファイルが見えない。見せたいなら、ボリュームとして明示的に渡す。READMEの言い方では「image, command, shell, and volume workflows」がDocker風に用意されているので、渡し方はDockerと同じ感覚です。何を渡すかを決めるのが、人の仕事になる。

ライセンスと、始める前に見ておくこと

ライセンスはApache License 2.0。商用でも使えて、改変も配布もできる緩い方のライセンスです。

READMEには「backed by Y Combinator」とあり、個人の実験ではなく会社として作られている。採用例としてフレームワークやツールへの組み込みも挙げられています。

始める前に見ておくのは3つ。動く条件（Apple Silicon・KVM・WHP）。中で使うイメージがOCI互換で引けること。そして、ホストに見せるファイルを先に決めること。

まとめ：microsandboxの使い方は、msb run から始めて SDK へ

まとめます。

microsandboxは、信用できないコードを手元のmicroVMで動かすOSS。隔離はハードウェアの段、起動は平均100ミリ秒未満、中で動くのは普通のコンテナイメージ。

動く条件は、Apple Silicon・KVM・WHPのどれか。入れ方は1行か、brew・npm・cargo。

CLIは msb run の使い捨てと、create と exec の使い回し。SDKはPythonなら Sandbox.create → exec → stop の3行。

秘密鍵はVMに入らない。ホストのファイルは、渡したものだけ見える。

まず今日、msb run python -- python3 -c "print('Hello')" を1回だけ叩いてみてください。100ミリ秒の話が本当かどうかは、それで分かります。

OSS活用の型をまとめた6大特典は 👉 オープンソース研究所の6大特典を受け取る