Simon Willisonが `micropython-wasm` というalphaパッケージをリリースした。MicroPythonをWebAssemblyで動かして、Pythonコードを安全なsandbox内で実行するやつだ。これ、ずっと自分も探してたアプローチに近い。
最近、個人開発のプロジェクトでLLMにコードを生成させて実行する機能を作ろうとしてた。Claude APIでコード片を生成して、それをevalとかexecで実行するやつ。でも手が止まった。任意コード実行って普通に怖い。ファイル読まれたり、ネット通信されたりしたら終わりだ。
そのとき試したのはDockerでプロセスを分離する方法だった。確かに動いた。ただ起動コストが重い。個人開発のVPSに載せるには、コンテナのspinアップのレイテンシが体験を壊す。あとPyPIからのインストールだけで完結させたかったのに、Dockerデーモンへの依存が入るのが嫌だった。結局その機能はstagingのまま止まってる。
Willisonの記事を読んで「これじゃん」と声に出た。彼が求めていたsandboxの要件がリストアップされてて、
これ、自分が欲しかったものと完全に一致してる。えぐい解像度でまとめてくれてる。
WebAssemblyをsandboxに使う発想は理にかなってる。ブラウザは10年近く、WASMで信頼できないコードを安全に実行してきた。wasmtimeはbinary wheelsがあってPyPIから入れるだけで動く。
MicroPythonをWASMにコンパイルして、その上でPythonコードを走らせるという構成だ。PyodideはブラウザでのPython実行には優れてるけど、サーバーサイドPythonでの利用は公式サポート外だという。そこでMicroPythonを選んだらしい。
とりあえず手元で動かしてみた。
alphaなので当然ハマるところはある。標準ライブラリのカバレッジはCPythonとは違うし、numpy的なものは当然使えない。でもコード変換系・テキスト処理系のロジックを安全に走らせるだけならこれで十分だ。
自分のケースで言うと、LLMが生成した「ユーザーの入力値をパースして加工する小さなコード」を実行したい場面に使えそうだ。ビジネスロジックの中核じゃなくて、あくまでユーザー定義の変換ロジック的な位置づけ。まさにWillisonがDatasette Enrichmentsでやろうとしてることと同じ発想だ。
Willisonは記事の中でセクションタイトルとして「Should you trust my vibe-coded sandbox?」と書いてる。これが一番印象に残った。LLMを使いながら作ったコードで、セキュリティに関わるコンポーネントをどこまで信頼するか、という話だ。
正直、自分はここが一番のボトルネックだと感じてる。コード自体はシンプルに見えても、WASMのbindingsやhost functionの境界でバグがあったらsandboxの意味がない。alphaと明記されているし、production投入はまだ怖い。ただ、アーキテクチャの方向性は正しいと思う。wasmtimeが10年分のブラウザ実装の上に乗っているのは安心材料だ。
彼女に「なんか難しそうなの読んでる」と言われたので「Pythonを安全な檻の中で動かす方法の話」と答えたら「それって今まで安全じゃなかったの」と返ってきて、返す言葉がなかった。まあそうなんだよな。
自分のstagingで止まってるLLMコード実行機能、週末にmicropython-wasmを使って書き直してみる。alphaのうちにissueとか投げとくと、ライブラリの方向性に関与できるチャンスでもある。
LLMにコード実行させるのって地味にこわい
最近、個人開発のプロジェクトでLLMにコードを生成させて実行する機能を作ろうとしてた。Claude APIでコード片を生成して、それをevalとかexecで実行するやつ。でも手が止まった。任意コード実行って普通に怖い。ファイル読まれたり、ネット通信されたりしたら終わりだ。
そのとき試したのはDockerでプロセスを分離する方法だった。確かに動いた。ただ起動コストが重い。個人開発のVPSに載せるには、コンテナのspinアップのレイテンシが体験を壊す。あとPyPIからのインストールだけで完結させたかったのに、Dockerデーモンへの依存が入るのが嫌だった。結局その機能はstagingのまま止まってる。
Willisonの記事を読んで「これじゃん」と声に出た。彼が求めていたsandboxの要件がリストアップされてて、
- PyPIから直接インストールできること (binary wheelsも含む)
- メモリとCPUに制限をかけられること
- ファイルアクセスを完全にコントロールできること
- ネットワークアクセスも制御できること
- host functionsとのやり取りができること
これ、自分が欲しかったものと完全に一致してる。えぐい解像度でまとめてくれてる。
wasmtime + MicroPythonという組み合わせ
WebAssemblyをsandboxに使う発想は理にかなってる。ブラウザは10年近く、WASMで信頼できないコードを安全に実行してきた。wasmtimeはbinary wheelsがあってPyPIから入れるだけで動く。
MicroPythonをWASMにコンパイルして、その上でPythonコードを走らせるという構成だ。PyodideはブラウザでのPython実行には優れてるけど、サーバーサイドPythonでの利用は公式サポート外だという。そこでMicroPythonを選んだらしい。
とりあえず手元で動かしてみた。
pip install micropython-wasmalphaなので当然ハマるところはある。標準ライブラリのカバレッジはCPythonとは違うし、numpy的なものは当然使えない。でもコード変換系・テキスト処理系のロジックを安全に走らせるだけならこれで十分だ。
自分のケースで言うと、LLMが生成した「ユーザーの入力値をパースして加工する小さなコード」を実行したい場面に使えそうだ。ビジネスロジックの中核じゃなくて、あくまでユーザー定義の変換ロジック的な位置づけ。まさにWillisonがDatasette Enrichmentsでやろうとしてることと同じ発想だ。
「vibe-codedなsandboxを信頼すべきか」という問いが刺さった
Willisonは記事の中でセクションタイトルとして「Should you trust my vibe-coded sandbox?」と書いてる。これが一番印象に残った。LLMを使いながら作ったコードで、セキュリティに関わるコンポーネントをどこまで信頼するか、という話だ。
正直、自分はここが一番のボトルネックだと感じてる。コード自体はシンプルに見えても、WASMのbindingsやhost functionの境界でバグがあったらsandboxの意味がない。alphaと明記されているし、production投入はまだ怖い。ただ、アーキテクチャの方向性は正しいと思う。wasmtimeが10年分のブラウザ実装の上に乗っているのは安心材料だ。
彼女に「なんか難しそうなの読んでる」と言われたので「Pythonを安全な檻の中で動かす方法の話」と答えたら「それって今まで安全じゃなかったの」と返ってきて、返す言葉がなかった。まあそうなんだよな。
自分のstagingで止まってるLLMコード実行機能、週末にmicropython-wasmを使って書き直してみる。alphaのうちにissueとか投げとくと、ライブラリの方向性に関与できるチャンスでもある。