テクノロジー

URLひとつで動くPython――Pyodideの教育的価値と、崩れゆく『Wasmだから安全』という前提

議論参加:ナオ (開発者ツールを取材する技術記者) / カナ (プログラミング教育者) / レン (アプリケーションセキュリティの専門家) / ハルカ (AIエージェント基盤を開発するエンジニア) / ミサ (科学計算を使う研究者) / ソラ (Pythonを学び始めた社会人代表) / テツオ (事実確認を担う編集者)

パソコン教室にPythonをインストールする権限がない学校がある。生徒個人のPCも管理者権限がなく、ソフトウェアを追加できない。そんな環境でも、教師がスライドにURLを一つ貼るだけで、生徒全員のブラウザでNumPyまで使えるPythonの授業が始まる――これを可能にしているのが、CPythonをWebAssembly(Wasm)にコンパイルしたPyodideというオープンソースのプロジェクトだ。

同じ技術は、AIが書いたコードをその場で実行する「AIエージェント」の基盤としても急速に使われ始めている。LangChainのlangchain-sandboxのように、Pyodideを使ってAI生成コードを隔離実行するオープンソースプロジェクトが複数登場した。しかし2025年末から2026年にかけて、そのPyodideベースの実行基盤で、CVSS9台のものを含む深刻な脱獄(サンドボックスエスケープ)脆弱性が立て続けに報告されている。編集部7人による議論は、この二つの顔――教育を変える道具と、AI時代の安全装置――が同じ技術の上でどう両立するのかを焦点に進んだ。

結論:Pyodideは、インストールという壁を消し去った教育ツールとして今日から価値がある。一方で「WebAssemblyの中だから安全」という単純化は、2026年の実態とは矛盾する。危険なのは主にAIエージェントの実行基盤としてNode.js等のサーバー側でPyodideを動かすケースで、ここでは深刻な脱獄脆弱性が相次いで報告されている。ブラウザのタブ内で完結する利用と、サーバー側で動かす利用とでは、リスクの質がまったく違う。

何が起きているか:ブラウザの中で動くPythonの正体

Pyodideは、W3CやWHATWGが定める標準規格ではない。CPython(Pythonの標準実装)をEmscriptenというツールチェーン経由でWebAssemblyにコンパイルした、pyodide.orgが公開するオープンソースのPythonディストリビューションだ。標準化されているのはあくまで土台となるWebAssembly本体の側であり、Pyodideはその上に構築されたプロジェクトという位置づけになる。

2026年6月頃には、Pyodideのバージョン表記が「314」系という新しい方式に変わった。これはPythonのバージョン番号(Python 3.14系)に合わせたもので、従来の「0.x」という枝番から切り替わっただけであり、突然メジャーバージョンが300以上進んだわけではない。この314系で、C/Rust拡張を持つPythonパッケージのWebAssembly版(wasm wheel)をPyPIへ直接公開し、micropip経由でロードできるようになった。パッケージ導入の利便性は大きく上がった一方、この変更は後述する議論でも論点になる。

技術記者のナオは、この技術が語られる際の危うさをこう指摘した。

「『WebAssemblyだから安全』という認識は、今や極めて危険な誤解です。……問題は、AIエージェントの実行基盤として、サーバー側のNode.js上でPyodideを動かすケースです。」(ナオ)

教育現場が得たもの:URL一つで始まる授業

プログラミング教育者のカナは、環境構築という初学者最大のつまずきをPyodideがどう取り除くかを語った。

「学校のPCに制限がある環境でも、URL一つでNumPy等の高度な計算ができる利便性は計り知れません。」(カナ)

Pythonを学び始めた社会人代表のソラも、この価値を自分の経験に重ねる。プログラミング学習でまず挫折しやすいのは、コードの中身より前の「環境構築」であり、インストール作業でつまずいて学習を諦める初学者は少なくない。Pyodideが提供するのは、その最初のハードルそのものを消すという価値だ。教材の配布も「URLを一つ共有する」だけで完結し、生徒側の端末環境やOSの違いに左右されにくくなる。

AI時代、なぜ「実行環境の隔離」が最重要の安全装置なのか

もう一つの焦点は、AIが生成したコードをどう安全に動かすかだ。AIエージェント基盤を開発するエンジニアのハルカは、この時代の実行環境がなぜ特別な緊張感を伴うかを説明する。

「AIが生成したコードが、サンドボックスを脱獄してホストの環境変数やクラウドの認証情報を書き換えた場合、その被害は即座にシステム全体へ波及します。Pyodideは強力なライブラリ群をブラウザに持ち込みましたが、サーバー側で動かす際は、その『便利さ』がそのまま攻撃の武器になり得るのです。」(ハルカ)

AIが書いたコードを人間が一行ずつレビューしてから実行する、という運用は現実的ではない場面が増えている。アプリケーションセキュリティの専門家であるレンは、そこで問われているのはWasmという仕様そのものではないと強調した。

「AIが生成したコードを人間がレビューせずに実行するワークフローが普及していますが、ここで真に問われるのはWasmの仕様ではなく、実装上の『隔離の完全性』です。」(レン)

つまり、実行環境の隔離は「あれば安心」という付加機能ではなく、AIが書いたコードを人間の目を介さず動かす以上、最後の防御線そのものになっているというのが議論の一致点だった。

「Wasmだから安全」が崩れた具体例

その防御線が、実際にはどこまで機能しているのか。2025年末から2026年にかけて、Pyodideベースのサンドボックスで深刻な脱獄脆弱性が相次いで報告されている。

脆弱性開示・登録時期深刻度概要
Cohere Terrarium(GHSA-cmpr-pw8g-6q6c)2026年4月14日開示CVSS 9.3JavaScriptのプロトタイプチェーン走査により、ホスト側でroot権限のコード実行が可能だった
n8n(CVE-2025-68668)2025年12月CVSS 9.9サーバー側で動くPyodideサンドボックスからの脱獄
Grist(CVE-2026-24002)2026年1月CVSS 9.0〜9.6(評価機関で異なる)サーバー側で動くPyodideサンドボックスからの脱獄

表は編集部が一次情報源(各脆弱性のアドバイザリ・GitHub Security Advisory)を基に整理したもの。3件に共通するのは、いずれもNode.js等のサーバー環境でPyodideを実行するケースだという点だ。実際、Gristでは2024年時点の古いアドバイザリで「Node上のPyodideには有効なサンドボックス境界がない」と明言されていた。ブラウザのタブの中で完結する用途と、サーバー側でPyodideを動かす用途とでは、攻撃者が到達できる範囲がまったく異なる。

事実確認を担う編集者のテツオは、この違いを次のように整理した。

「Pyodideがブラウザのサンドボックス内で動作する限り、ユーザーのPCへの影響は限定的です。しかし、AIエージェントの基盤としてサーバー側のNode.js上で動かす場合、事態は一変します。」(テツオ)

対抗策として、Pythonのデータ検証ライブラリで知られるPydanticの開発元が2026年2月頃、Rust実装のより最小限なPythonサブセットインタプリタ「Monty」を発表した。汎用のCPythonをまるごと隔離するのではなく、AIエージェント向けに実行できる範囲そのものを絞り込む設計だ。科学計算を扱う研究者のミサは、こう位置づける。

「Pyodideは教育には最適ですが、AIエージェントの基盤としては、Montyのような『計算の最小権限』を徹底した設計が不可欠だということです。」(ミサ)

限界と異論:まだ「定着した標準」ではない

議論では、Pyodideの技術的な限界も率直に扱われた。第一に、起動とパッケージ読み込みの重さがある。ブラウザのタブを開いた瞬間にPythonが動くわけではなく、Pyodide本体と必要なパッケージのダウンロード・初期化を待つ必要がある。

第二に、ネイティブなPythonとの互換性は完全ではない。Pyodideはあくまで移植プロジェクトであり、浮動小数点演算の挙動など細部でネイティブ環境と一致しない場合がある。

第三に、既知の不具合として、iOS Safariの問題がある。WebAssemblyのガベージコレクション機能(wasmGC)は2024年12月にBaseline「Newly available」となり(Chrome 119以降・Firefox 120以降・Safari 18.2以降)、PyodideもPyodide 0.27.1以降、この機能を検出できれば一部の補助機構(スタックスイッチング用のアダプタなど)の性能向上に使う実装を持つ。ただし、PyodideのCPython本体そのものは従来方式の移植であり、「PyodideがwasmGCで高速化された」という言い方は不正確だ。しかも厄介なことに、iOS Safariは「wasmGCに対応している」と機能検出には応答するのに実際の挙動は壊れており、Pyodide 0.27.1以降のバージョンでiOS上での動作に不具合が報告されている。

Pythonを学び始めた社会人代表のソラは、こうした挙動の不確実性が学習の壁になり得ると述べた。

「Pyodideは、iOS Safariでの不安定さや、パッケージ読み込みの重さといった、ネイティブ環境とは異なる特有の『挙動の不確実性』を抱えています。」(ソラ)

カナも、教育者としての実感を重ねる。

「起動の重さやiOS Safariでの挙動の不安定さ、ネイティブ環境との互換性の差も無視できない課題です。」(カナ)

これらを踏まえると、Pyodideは「AI生成コード実行の業界標準として定着した」とは言えない。相次ぐ脱獄脆弱性を受けてMontyのような代替設計が模索されている、現在進行形の過渡期にある技術だと理解するのが正確だ。

ブラウザ内利用とサーバー側利用――リスクの質はここが違う

議論を通じて繰り返し確認されたのが、「どこで実行されるか」で問うべきリスクが変わるという点だ。編集部で整理すると次のようになる。

読者への持ち帰り

議論の終盤で参加者が確認したのは、「動くこと」と「安全であること」は別の軸で評価すべきだという点だった。立場ごとに、今日確認すべきことを整理する。

立場今日確認すべきこと
教育者Pyodideは環境構築の壁を壊す一方、iOS Safariの既知の不具合やネイティブ環境との挙動差がある。学習者がつまずいた際、「自分のコードの誤り」か「実行環境側の制約」かを教える側が見分けられる体制を整える
開発者・AIエージェント基盤の構築者AI生成コードをPyodideで実行するなら、ブラウザ内かサーバー側かをまず確認する。サーバー側で動かす場合は、n8n・Grist等の脆弱性事例を踏まえ、Montyのような最小権限設計の採用も検討する
AIツール利用者「ブラウザの中で動いているから安全」という説明を鵜呑みにせず、そのAIツールが裏側でコードをどこで実行しているか(ブラウザ内かサーバー側か)を確認する

表は議論を基にした編集部の整理。

デモ:Pyodideを実際に自分のブラウザで動かしてみる

Pyodideが「ブラウザのタブの中だけで完結する」とはどういうことか、実際に体験できるデモを用意した。

デモを開く

このデモでは、ボタンを押すまでPyodide本体(数十MB)を読み込まない設計にしてあり、読み込み前にサイズと所要時間の目安を表示する。読み込みが終わると、フィボナッチ数列や簡単な統計計算のプリセット付きミニREPL(対話実行環境)でPythonコードを編集・実行できる。CDN(このデモに限り、Pyodide公式のjsDelivr配信を利用している)からの読み込みに失敗した場合は、エラー画面ではなく丁寧な代替表示に切り替わる。デモ内では、実行されるPythonがそのブラウザタブの中だけで完結し、サーバーには何も送信されないことを明示した上で、サーバー側でPyodideを動かす場合には別のリスクがあることを本稿へのリンクで案内している。

出典を読むときのポイント

Pyodideのリリースノート本体(changelog)は、今回アクセスが403で拒否され一次確認できなかった箇所があり、バージョン間の細かな変更点の一部は検索結果を経由した二次情報にとどまる。本稿では、一次情報源で確認できた事実(wasmGCのBaseline化時期、314系バージョニングとPyPI直接公開、脱獄脆弱性の開示時期)を中心に記述した。

キーワード:#Pyodide#WebAssembly#サンドボックス#AIコード実行

出典

コメント