エッジでのPython：高速でサンドボックス化され、WebAssemblyによって動作する

243日前原文(wasmer.io)

概要

AIワークロードの増加に伴い、WebAssembly上でのPythonサポート需要が急増
Wasmer Edge（Beta）でWebAssemblyとWASIXによるフルPythonサポートを実現
numpyやpandasなどのネイティブモジュール対応、動的リンクやlibffiもサポート
FastAPIやDjangoなど主要フレームワークがそのまま動作、パフォーマンスもほぼネイティブ
CloudflareやAWS Lambdaと比較し、互換性・速度・コストで優位性

Wasmer EdgeによるWebAssembly上のPythonフルサポート発表

AIワークロード の増加により、 WebAssembly上でのPythonサポート 需要が急拡大
numpy や pandas などの ネイティブモジュール 対応が必須条件
pyodide はブラウザ向けであり、 サーバーサイド用途には制約 が多い
Wasmer Edge（Beta） で WebAssemblyとWASIX により、主要Pythonフレームワークの フルサポート を発表

技術的課題と解決策

動的リンク（dlopen/dlsym） 対応による WASIX拡張
libffiサポート 追加で ctypes利用ライブラリ も動作
ソケット通信・スレッド対応 の強化
独自Python Package Index 公開、人気の Pythonネイティブライブラリ を WASIX用にビルド
Heroku Buildpacks/Nixpacks/Devbox代替 の自動プロジェクト検出・デプロイ機能を開発

パフォーマンス・ベンチマーク

従来リリースより大幅な高速化、 py2wasm よりも速い
pystoneベンチマーク で ネイティブPython に近い速度を実現
初回実行時はコンパイルに数分必要、今後の改善予定
最適化技術 により 95%ネイティブ性能 を目指す

対応可能なワークロード例

FastAPI、Django、Flask、Starlette などの APIサーバー
MySQL自動接続、 WebSockets対応FastAPI、 MCPサーバー
画像処理（pillow）、 ffmpeg統合、 streamlitやlangchain
pypandoc などの多様なPythonアプリ
近日中に curl_cffi、polars、gevent/greenlet、Pytorch もサポート予定

他プラットフォームとの比較

Wasmer Edge は ネイティブモジュール/マルチスレッド/WSGI/ASGI/WebSocket に幅広く対応
Cloudflare Workers（Pyodideベース） は ネイティブモジュール不可・スレッド不可・WebSocket非対応
AWS Lambda は ラッパー必須・WebSocket不可・セットアップ複雑
Wasmer Edge は コード変更不要・コールドスタート高速・コストも安価

Cloudflare Workers（Pyodide）との違い

Pyodide は ブラウザ用途特化、 サーバーサイドでは制限多数
- uvloop/uvicorn非対応
- スレッド/マルチプロセス不可
- 生HTTPソケット不可
- Pythonバージョン固定
- コールドスタート遅い
Wasmer Edge は WASIX上で本物のPython が動作、 制約なし・高速起動

AWS Lambdaとの違い

AWS Lambda は WSGIアダプタ必須、 WebSocket非対応、 セットアップ複雑
Wasmer Edge は コード変更不要 で 任意のPython HTTPサーバー がそのまま動作

Wasmer Edgeの優位性

Pyodideよりもネイティブに近いPython、 JS不要
Cloudflare Workersより高速・高互換性
AWS Lambdaより高い互換性・低コスト
多彩なテンプレート を用意、 すぐにデプロイ可能

はじめ方・テンプレート紹介

MCPサーバー テンプレートで ChatGPT連携サイト を簡単作成
- https://wasmer.io/templates/mcp-chatgpt-starter?intent=at_vRxJIdtPCbKe
- Github連携・テンプレートからリポジトリ作成・即デプロイ
- ソースコード: https://github.com/wasmer-examples/python-mcp-chatgpt-starter
Django + Uvicorn テンプレートも用意
- https://wasmer.io/templates/django-starter?intent=at_WK0DIkt3CeKX
- MySQL自動作成・マイグレーション実行
- ソースコード: https://github.com/wasmer-examples/django-wasmer-starter

まとめ・今後の展望

WebAssembly + Wasmer で Pythonアプリがポータブル・サンドボックス化・高速化
AIワークロード/API/エッジ用途 に最適な新しいPython実行環境
ベータ段階 のため、問題があれば フィードバック歓迎
公式テンプレート・ドキュメント・コミュニティ も充実
Python on Wasmer Edge で、 あらゆるPythonアプリがエッジでネイティブ級に動作

Hackerたちの意見

これ、期待できそうだね！brew install wasmer して、wasmer run python/python@=0.2.0 を実行したら、なんとPython 3.12のシェルがWebAssemblyのサンドボックス内で動いてるみたい！数年前から、ブラウザの外でWebAssemblyでPythonプロセスを動かすための堅牢で信頼できる簡単な方法を探してたんだ。

└

Pyodideって、もう数年前からあるんじゃないの？

└

ありがとう！記事に書くのを忘れちゃったけど、最新のPythonを動かすにはWasmerのrc.5が必要だよ！(最終リリースはもうすぐ来るよ) curl https://get.wasmer.io -sSfL | sh -s "v6.1.0-rc.5" で、wasmer run python/python だね。

└

╰─ wasmer run python/python
error: Spawn failed
╰─▶ 1: compile error: Validate("exceptions proposal not enabled (at offset 0x191a)")

└

毎日、BlazorがRazorを使ってWASMにビルドするみたいな、Python用のWASMベースのテンプレートエンジンを持つ夢に近づいてる。帰ったらこれで遊んでみようかな。

└

数年間、ブラウザの外でWebAssemblyでPythonプロセスを実行するための堅牢で信頼性が高く、簡単な方法を探しているんだけど。返信：使い道は何なの？サンドボックス化が目的？コンテナでPythonを実行するより簡単なの？

└

C/C++拡張を持つパッケージ（例：numpyやscipy）でも使えるの？

WASMは、goroutinesやPythonのasyncioループ、各言語のGCの特性みたいな言語特有の機能をどう置き換えたり実装したりするの？

└

言語によっては、GCはユーザースペースで線形メモリを使って実装されているか、WebAssemblyの新しいGC拡張を使って実装されています。後者にはいくつかの制限があって、すべての言語が使えるわけではないし、簡単に統合できるわけでもない（かなりの作業が必要です）。でも、今ではWASMのネイティブGCを使っている実装がいくつかあります。WASMのネイティブGCを使うと、オブジェクトはWASMランタイム（ブラウザではJSランタイム）によって管理されます。ゴルーチンのようなものは、例外処理などのWASMプリミティブを使ってエミュレートすることになります。ホストがネイティブでスタックスイッチングを行うためのシステムコールを提供していない限りはね。（確か、スタックスイッチングは提案されているけど、まだどのプロダクションWASMランタイムにも組み込まれていないはず - 詳しくは https://webassembly.org/features/ を見てね）私がサクッと調べた限りでは、Goは各ゴルーチンを状態変数に基づいたスイッチ文として生成しているので、適切な状態変数を使ってスイッチを呼び出すことでゴルーチンを「再開」できるってことです。

└

現在、CPythonのWASIビルドは、デフォルトでasyncioをサポートしてないみたい（少なくとも[0]によると）。これは、標準ライブラリのasyncio実装がソケット周りのプリミティブから構築されていることに起因してると思う。そして、WASIはソケットをサポートしてない。ブラウザ環境では、理論的にはネイティブエコシステムのasyncサポートを利用する方法があるけど、CPythonは特定のシステム向けに書かれてるから、CPythonのパッチの話になるよ。でも、素晴らしいのは、自分のasyncioイベントループを持ち込めるってこと！例えば、Pyodideは独自のasyncioイベントループを提供してる[1]。これは、Pythonのasyncインフラがそのジェネレーターの概念に基づいて構築されているおかげだよ。async/await自体はI/Oを「要求する」ものではなく、ただasyncioがそうなんだ。[0]: https://docs.python.org/3.13/library/asyncio.html [1]: https://pyodide.org/en/stable/project/release-notes/v0.17.0....

FFIサポート（彼らが持ってるやつ）は、代替のPythonが価値を持つためには必須だよ。だって、今のPythonを便利にしてるのはnumpyやkerasみたいなものが多いからね。それに、分岐の多い純粋なPythonのワークロードを加速する必要もあるし、PyPyで大きな違いが出たrdflibの仕事もたくさんしたから、そういうワークロードを加速できるランタイムも必要だよ。

依存関係のインストールは簡単なの？それとも、純粋なwheelサポートがあるパッケージだけにしか対応してないの？

いいね、でもWASMを調べるたびに、コンテナや軽量VMの方がシンプルで制限が少ないんじゃないかって思っちゃう。マイクロカーネルやカスタムランタイム（いろんなErlangのやつ）を忘れちゃったみたいだし…それでも、ネイティブに近いPythonが使えるのは面白いところだね。

https://docs.wasmer.io/ で https エラーが出る：net::ERR_CERT_AUTHORITY_INVALID

SQLデータベースに任意のスクリプトを保存して、ホスト言語（Pythonかもしれないし、そうでないかもしれない）から安全にPythonサンドボックス内で引数を使って実行し、その値を呼び出し元に返すことができる段階に来てるの？顧客が提供する変換スクリプトをデータのエクスポートに実装したいんだけど、このPythonは完全にサンドボックス化されていて、私が与えたデータだけで動作する必要があるんだ。

└

まあ、厳密に言えば、Pyodideはこれをしばらく前から持ってるよね：使い道については https://developer.nvidia.com/blog/sandboxing-agentic-ai-work... を見てみて。Wasmerのアプローチは、より速いコールドスタートと全体的なパフォーマンス向上を示唆してるけど、Pyodideとのベンチマークはちょっと不明瞭だし、これがこの使い道の実現可能性にどう影響するかは私にははっきりしない。でも、これが可能にすることの一つは、もしあなたの任意のスクリプトが実際には永続的なサーバーなら、それをエッジサーバーにデプロイして、安全でサンドボックス化された方法でネットワーク越しにそのスクリプトとやり取りできるってことだね！

└

それ、ほぼ私がやりたいことと同じだよ。これのためにQuickJSを少し試してみたんだけど、ここに結構堅牢そうなPythonモジュールがあるよね https://pypi.org/project/quickjs/ 。でも私の理想はWebAssemblyサンドボックスで、今のところそれが世界で最も広くテストされたサンドボックスだからね。

よく分からないんだけど、これはVercelやFly.ioと競合する新しいサーバーレスのサービスで、技術や価格戦略が違うってこと？それに、wasmコンテナを使えば、DockerのオーバーヘッドやStreamlit Cloudの遅さなしに、FastAPIのETLアプリをデプロイできるってこと？

アプリは他のエンドポイントからデータを引っ張るために、アウトバウンドネットワークアクセスがあるのかな？例えば、Flaskベースのアプリみたいな感じ？（コードはクソだけど、当時AIのサポートを受けながらPythonを学んでたシステム管理者だから）。 https://github.com/jgbrwn/my-upc/blob/main/app.py それと、WasmerがStarletteをサポートしてるなら、FastHTML（Starletteを使ってるウェブフレームワーク）もサポートしてると思うんだけど？

└

うん、Starlette/ASGIをサポートしてるから、FastHTMLは問題なく動くはずだよ。

└

実際、スケジューリングはWasmerでは全然動かないんじゃないかな？

これを使ってJavaScriptからnumpyをどうやって使うの？

└

Wasmer-JSを使えばできるはず！新しいバージョンをリリースする必要があるけどね！

ハクソク