9月21日、Cloudflareが「Python Workers are now generally available」と題した記事を公開した。2年間のベータ期間を経て、PythonがCloudflare WorkersにおいてTypeScriptと同等の「一級市民」として正式サポート(GA)されたことを詳しく伝えている。
2年越しのGA——何がここまで難しかったのか
Cloudflare WorkersはV8アイソレート(GoogleのJavaScriptエンジンV8を用いた軽量な実行環境)上で動作するため、CPythonをそのまま実行できない。Cloudflareはこれを解決するため、CPythonをWebAssemblyにコンパイルしたPyodideを採用してきた。しかしPythonとJavaScript間のデータ受け渡しには型変換処理が必要で、C拡張ライブラリの対応パッケージ数も限られており、実務投入のハードルは低くなかった。
今回のGAはその壁を一気に崩す内容だ。JavaScriptの知識がなくてもPythonだけで完結する開発体験を実現し、FastAPI・Django・Flaskといった既存コードをほぼ変更なしにエッジへ持ち込める。Workers AI、R2、D1、Hyperdrive、Durable Objects、Queues、WorkflowsといったCloudflare Developer Platformの全サービスとのバインディングもPythonから直接利用できるようになった。
Cloudflareバインディングの呼び出しが劇的にシンプルに
GAの目玉の一つが、Cloudflareサービスとの連携時に必要だったJavaScriptとのRPC境界処理の完全隠蔽だ。以前はQueueにPythonの辞書を送るだけで以下のような変換コードが必要だった:
from pyodide.ffi import to_js
import js
self.env.QUEUE.send(to_js({"key": "value"}, dict_converter=js.Object.fromEntries))
GAでは以下の1行で済む:
self.env.QUEUE.send({"key": "value"})
この変更はLLMがコード生成する場面でも誤りを減らせるとCloudflareは説明している。Pythonらしい書き方がそのまま機能するため、AIエージェントによるコード生成との相性も高まる。
FastAPI・Django・Flaskがほぼそのまま動く
実務への影響が最も大きい変更の一つが、主要WebフレームワークのASGI/WSGIサポートだ。workers.asgi / workers.wsgi という薄いブリッジレイヤーが、WorkersへのリクエストをASGI/WSGIの標準インタフェースに変換して渡す。UvicornやGunicornといったサーバーを別途立てる必要なく、Cloudflareのグローバルネットワークがロードバランシングとスケーリングを担う。
たとえばFastAPIアプリは、エントリポイントを追加するだけでWorkers上で動作する:
from workers import asgi, WorkerEntrypoint
from fastapi import FastAPI, Request
app = FastAPI()
@app.get("/")
async def root(request: Request):
env = request.scope["env"]
return await env.AI.run(
"@cf/meta/llama-3.1-8b-instruct",
{
"instructions": "You are a friendly assistant.",
"input": "What is the origin of the phrase Hello, World?",
},
)
Default = asgi.entrypoint(app)
FastAPI・Django・Flaskに限らず、ASGI/WSGIインタフェースに準拠したフレームワークであれば動作する。
PostgreSQL・MySQLにもネイティブ接続
従来のPython WorkersはWebAssemblyサンドボックスの制約でTCPソケットをサポートしておらず、aiomysqlやasyncpgといった主要データベースドライバが動作しなかった。今回、WebAssemblyサンドボックス内でのソケットシステムコールをWorkers connect APIで実装することでこの制約を解消した。
これによりHyperdrive(コネクションプーリングとグローバルキャッシングを提供するCloudflareのデータベースプロキシサービス)との統合が可能になった。Wranglerの設定にバインディングを追記した上で、通常のドライバをそのまま使うだけだ:
import aiomysql
from workers import WorkerEntrypoint
class Default(WorkerEntrypoint):
async def fetch(self, request):
hd = self.env.HYPERDRIVE_MYSQL
conn = await aiomysql.connect(
host=hd.host, port=int(hd.port),
user=hd.user, password=hd.password, db=hd.database, ssl=None,
)
cur = await conn.cursor()
await cur.execute("SELECT username FROM user")
r = await cur.fetchall()
openai・langchain・mcpもそのまま使える
openaiやlangchainが依存するHTTPクライアント(requests、httpx)は、低レベルのソケット操作を前提とするため従来は動作しなかった。Cloudflareはこれらのライブラリにアップストリームコントリビュートし、WebAssembly環境ではJavaScriptのfetch APIを経由してリクエストをルーティングできるよう改修した。
Cloudflare公式のlangchain-cloudflareパッケージを使えば、Workers AI上のモデルをlangchainチェーンの一部として直接組み込める。mcpパッケージも動作するため、MCP(Model Context Protocol)サーバーをPython Workerとして構築・デプロイすることも可能だ。AIエージェント開発の文脈でPythonの需要が急増している中、これは実践的な意味を持つ。
パッケージエコシステムの課題に対しPEP 783を提案
C/C++/Rust拡張を含むパッケージはWebAssembly向けにクロスコンパイルが必要で、対応パッケージ数が制限要因として残っていた。Cloudflareはこの問題をコミュニティレベルで解決するために**PEP 783** を提案した。
PEP 783は「PyEmscripten」というブラウザ・WebAssembly向けPythonの標準プラットフォームタグを定義するもので、採択されればパッケージメンテナが自力でPyEmscripten向けwheelをビルド・公開できるようになる。cibuildwheel(CI/CDでwheelビルドを自動化するツール)への対応も追加されており、既存パイプラインへの組み込みが容易だ。現時点でエコシステムの移行は途上だが、未対応パッケージはDiscordまたはGitHubで申請するとCloudflareチームが対応するとしている。
今すぐ試せるサンプル集
Cloudflareはpython-workers-examplesリポジトリに、本番利用を想定したパターンをまとめている。
- AI画像生成パイプライン: Queue + Workflows + Workers AI + R2を組み合わせた非同期オーケストレーション
- Bluesky Jetstreamのリアルタイム処理: Durable ObjectsでWebSocket接続を長期維持しながらATProtoのイベントを処理
- RAGシステム: Workers AIとVectorize(CloudflareのベクトルDB)を使った検索拡張生成
- MCPサーバー: 公式Python MCPパッケージを使ったエッジ上のMCPサーバー構築
Hacker Newsでもこのリリースに対する議論が活発で、「既存のFastAPIコードがほぼそのまま動く」点への評価が目立つ。一方でPyodideのコールドスタートレイテンシやパッケージ対応範囲への懸念も挙がっており、本番用途では事前の検証が推奨される。
詳細はPython Workers are now generally availableを参照していただきたい。