MicroPythonとWASMでPythonサンドボックスを実現
Simon Willison氏がMicroPythonをWebAssembly上で動作させ、Pythonコードを安全に実行するサンドボックス「micropython-wasm」をalpha公開。Datasette Agentのプラグインとして利用可能。
プラグインシステムを採用するソフトウェアには共通の悩みがある。サードパーティのコードをフル権限で実行させるリスクだ。この問題に対して、Simon Willison氏が新たなアプローチを打ち出した。同氏はMicroPythonをWebAssembly（WASM）に移植し、micropython-wasmというalphaパッケージを公開した。このパッケージは、同氏が開発するDatasette Agentのコード実行サンドボックスプラグインとして活用されている。
なぜサンドボックスが必要か
Simon Willison氏の主要なオープンソースプロジェクト（Datasette、LLM、sqlite-utils）はすべてプラグインをサポートしている。プラグイン機構は拡張性の面で優れており、コアアプリケーションに影響を与えることなく新機能を追加できる。しかし、PluggyベースのプラグインはPythonコードをフル権限で実行するため、バグや悪意のあるコードがシステム全体を破壊したり、プライベートデータを漏洩させたりするリスクがある。
この問題はプラグインだけに留まらない。Datasette Enrichmentsのように、テーブル内の値を変換する任意コード実行機能も存在する。さらにWillison氏は、スケジュールに従って承認済みのURLからJSONを取得し、小さなコードでリスト変換した上でSQLiteの行として挿入するといった機能を構想している。こうしたユースケースでは、安全なコード実行環境が不可欠となる。
サンドボックスに求められる要件
Willison氏は自身のサンドボックスに以下の要件を課している。
第一に、依存関係がPyPIからクリーンにインストールできること。バイナリホイールを含むマルチプラットフォーム対応が必要で、ユーザーは追加の手順を踏まずにPythonパッケージをインストールできる必要がある。
第二に、実行コードにメモリ制限とCPU制限を課すこと。無限ループやメモリを消費し続けるコードがアプリケーションやコンピュータをクラッシュさせないようにする。
第三に、ファイルアクセスの厳格な制御。完全にファイルシステムにアクセスできないか、読み取り・書き込み可能なファイルを明示的に定義できる必要がある。
第四に、ネットワークアクセスの制御。サンドボックス内のコードはネットワーク接続を自由に行えないようにする。
WebAssemblyがもたらす可能性
WebAssemblyはもともとブラウザ上で安全にコードを実行するために設計された仕様であり、セキュリティ面で多くの利点を備えている。メモリは線形メモリで隔離され、システムコールへのアクセスはホスト側で明示的に提供する必要がある。この特性をサーバーサイドのサンドボックスに応用する試みはこれまでも行われてきたが、WASMランタイムの成熟とPython処理系の移植が進み、現実的な選択肢になりつつある。
Willison氏はこのWASMの性質に着目し、MicroPythonをWASMにコンパイルすることで、軽量かつ制限可能なPython実行環境を実現した。MicroPythonは組み込み向けに最適化されたPython実装であり、フル機能のCPythonと比べてフットプリントが小さい。WASM上で動作させることで、メモリやCPUの制限、ファイルシステムやネットワークへのアクセス制御がシームレスに実装できる。
技術的な特徴
micropython-wasm は、MicroPythonをEmscriptenなどのWASMツールチェーンでビルドしたものと推測される。これをPythonアプリケーション内でWASMランタイム（Wasmtimeやwasmerなど）を用いて実行する仕組みだ。サンドボックス化されたコードは、ホスト側で定義した関数のみを呼び出せるため、ファイルI/Oやネットワーク操作を厳密に制御できる。
Willison氏はこのパッケージをalphaとして公開し、Datasette Agentのコード実行サンドボックスプラグイン（datasette-agent-micropython）として実際に利用している。Datasette AgentはAIエージェントであり、エージェントが生成したPythonコードを安全に実行するためにこのサンドボックスが使われる。同氏のブログでは「Should you trust my vibe-coded sandbox?」という見出しもあり、AI（vibe coding）を使ってサンドボックス自体を生成した可能性を示唆している。これにより、開発速度とセキュリティのバランスをどう評価するかという興味深い問いも浮かび上がる。
現時点での制約と今後の期待
alphaバージョンであるため、まだ実運用に耐える完成度には達していない可能性がある。MicroPythonはCPythonのサブセットであるため、標準ライブラリの一部が使えない、あるいはパフォーマンスが低下するといった制限がある。また、WASMランタイムのオーバーヘッドや、スレッド・非同期処理の扱いなども課題として残る。
とはいえ、依存関係のインストールがpipで完結し、追加のランタイムを用意する必要がないという点は、エンドユーザーにとって大きな利点だ。これまでのサンドボックス手法（subprocessでの隔離、gVisorやFirecrackerのようなコンテナベース、pyodideベースのアプローチ）と比較して、導入の容易さで優位に立つ可能性がある。
編集部の見解
短期的には、このサンドボックスアプローチがDatasette Agentに限らず、他のPythonアプリケーションのプラグイン機構にも応用される可能性がある。プラグインのセキュリティに悩む開発者にとって、導入が容易なWASMベースの選択肢が増えることは朗報だ。特にAIエージェントが生成したコードを安全に実行するニーズは高まっており、サンドボックスとAIエージェントを組み合わせたソリューションは今後3〜6ヶ月で競争が激化すると見られる。
長期的には、Pythonエコシステム全体におけるコード実行の安全な手段として、WebAssemblyが標準的な基盤となる可能性がある。CPythonのWASM移植（Pyodide）も存在するが、MicroPythonの軽量性はリソース制限の厳しい環境や、高速な起動が必要なシナリオで優位に立つ。将来的には、プラグイン実行環境の標準仕様として、WASMベースのサンドボックスがOSSコミュニティで採用される流れも予想される。一方で、MicroPythonとCPythonの互換性の差がどの程度実務上の障壁になるかは、今後の実運用データを待つ必要がある。
編集部としては、このサンドボックスが本当に「vibe coding」で作られたものかどうか、またその品質保証プロセスに興味がある。AIが生成したコードをサンドボックス自体に使うという自己言及的なアプローチは、セキュリティと開発効率のトレードオフを再考させる。読者の皆さんは、AI生成コードをセキュリティクリティカルな部分に使うことにどの程度抵抗があるだろうか。ぜひ議論の材料にしてほしい。
参考
よくある質問
- micropython-wasmはどのように動作するのですか？
- 内部でMicroPythonがWebAssemblyにコンパイルされており、PythonコードはWASMランタイム内で実行されます。ファイルシステムやネットワークへのアクセスはホスト側で制御できるため、安全なサンドボックス環境が実現します。現時点ではalpha版です。
- 通常のCPythonと比べてどのような制限がありますか？
- MicroPythonはCPythonのサブセット実装であるため、一部の標準ライブラリや高度な機能（asyncioの一部など）が使えない可能性があります。また、WASMランタイムのオーバーヘッドにより実行速度が低下する場合があります。ただし、サンドボックス用途が前提のため、多くのユースケースでは十分と見られます。
- Datasette Agent以外でも利用できますか？
- 現時点ではDatasette Agent向けのプラグインとして公開されていますが、パッケージ自体は汎用的な設計であるため、他のPythonアプリケーションに組み込むことも可能です。ただしalpha版である点に留意が必要です。
コメント