Python Workers が正式リリースされました

2年前、私たちは Python Workers を発表し、Cloudflare Workers ランタイムで Python アプリケーションを動かす手段を提供した。狙いは、Python で Workers を書くのを TypeScript と同じくらい簡単にし、Python のパッケージやフレームワークのエコシステムを「そのまま使える」ようにすることだった。そして今日、Python Workers が正式に GA となった。

GA とは何を意味するのか。Python が Cloudflare 開発者プラットフォームの一級市民となり、完全なサポートを受けるということだ。使い慣れた Python のコード、ライブラリ、設計パターンをそのまま持ち込み、Workers AI、R2、D1、Hyperdrive、Durable Objects、Queues、Workflows、その他 Cloudflare プラットフォームの各部分にシームレスに接続できる。Python Workers 上で FastAPI、Django、Flask といった人気の Python フレームワークを動かすこともできる。さらに Dynamic Workers を使えば、ある Worker の中から別の Python Worker を作り出せる。

from fastapi import FastAPI, Request
from workers import asgi, WorkerEntrypoint

app = FastAPI()

@app.get("/")
async def root(request: Request):
 env = request.scope["env"]
 return await env.AI.run(
 "@cf/openai/gpt-oss-120b",
 {
 "instructions": "You are a friendly assistant.",
 "input": "What is the origin of the phrase Hello, World?",
 },
 )

Default = asgi.entrypoint(app)

Python Workers が歩んできた道

Python を Cloudflare Workers に持ち込むのは自然な流れだった。Workers は 2018 年から WebAssembly をサポートしており、Wasm にコンパイルした Python インタープリタを動かすのに理想的な環境がすでにあった。Pyodide のおかげで、さまざまな Python アプリケーションを Cloudflare Workers でサポートできるようになるまでに時間はかからなかった。

私たちが目指したのは、Python アプリケーションを無限にスケールできる最初のプラットフォームを作ること、しかも開発体験と性能は、どこで Python アプリケーションを書くときと比べても遜色ないものにすることだった。

今回紹介する機能は、長年の取り組みの成果だ。すでに多くの開発者が Python Workers 上でアプリケーションを構築している。ここでその能力を本番運用できる水準まで磨き上げ、すべての人に開放する。

Python は Cloudflare Workers ランタイムの一級言語になった

Python Workers は Cloudflare 開発者プラットフォームのバインディングをネイティブにサポートする。以前は、Python Workers でこれらのバインディングを使うには、RPC の境界で Python オブジェクトを明示的に TypeScript オブジェクトへ変換する必要があった。たとえば、Python の辞書を Cloudflare Queue に送るには、次のようなグルーコードがないと動かなかった。

from pyodide.ffi import to_js
import js

self.env.QUEUE.send(to_js({"key": "value"}, dict_converter=js.Object.fromEntries))

このため、Python 開発者は Python Workers を書くときにも JavaScript 環境とそのコードを常に意識しなければならず、人にとっても AI エージェントにとってもよくあるエラーの温床になっていた。そこで私たちは型変換のプロセス全体をWorkers ランタイムと Python SDK に封じ込めた。今ではすべての Cloudflare バインディングを Python らしい書き方で使え、JavaScript のコードは一行も書かなくていい。次のようなコードがそのまま動く。

self.env.QUEUE.send({"key": "value"})

Web フレームワーク：FastAPI、Django、Flask

Python Workers 上で、普段使っている Python フレームワーク、たとえば FastAPI、Django、Flask を動かし、Python で API サーバーを構築できる。Web アプリケーションを Python Workers に簡単に接続するためのコネクタを組み込みで用意した。

シンプルな FastAPI の Web アプリケーションがあるとしよう。

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
async def root():
 message = "Hello, world!"
 return {"message": message}

ネイティブ環境なら、uvicorn のような Web サーバーでこのアプリケーションを動かすだろう。

$ uvicorn main:app

Python Workers では、用意した workers.asgi パッケージを使えば同じアプリケーションを動かせる。次のコードを追加するだけでいい。

from workers import asgi

class Default(WorkerEntrypoint):
 async def fetch(self, request):
 return await asgi.fetch(app, request, self.env)

# or equivalently
Default = asgi.entrypoint(app)

同様に、workers.wsgi パッケージを使えば Django のような同期 Web アプリケーションを動かせる。

from workers import WorkerEntrypoint, wsgi
from your_django_app.wsgi import app

Default = wsgi.entrypoint(app)

裏側で何が起きているのか

Python には、Web アプリケーションが Web サーバーと通信する方法についての標準的な取り決めがある。Web Server Gateway Interface（WSGI）と、その現代的な非同期版である ASGI だ。この標準があるおかげで、開発者が作るアプリケーションは特定のサーバーに依存しなくて済む。従来のデプロイでは、Uvicorn や Gunicorn といった Web サーバーが大量のクライアント接続とスレッドを処理してトラフィックを支え、FastAPI のような Web フレームワークはアプリケーションのロジックそのものに集中できる。

Cloudflare Workers では、Workers プラットフォーム自体が Web サーバーだ。私たちのグローバルネットワークがすでに負荷分散と無限のスケールを処理しているので、Python Workers の中でもう一つサーバーを動かして車輪を再発明する必要はない。

私たちの workers.asgi と workers.wsgi のコネクタは、軽量で最適化された橋渡しの役割を果たす。入ってくるネイティブな JavaScript リクエストを、Python アプリケーションが期待する標準の WSGI/ASGI 構造に変換し、レスポンスを極めて低いオーバーヘッドで返す。これにより Python 開発者はいいとこ取りができる。慣れた Web フレームワークでコードを書き、整理しつつ、Cloudflare Workers プラットフォームが API を瞬時に世界中へスケールさせ、しかもサーバーの設定は一切不要だ。

これらのコネクタは FastAPI、Django、Flask だけでなく、WSGI や ASGI インターフェースを使うあらゆる Python Web フレームワークで動作します。

各 Web フレームワークでの具体的な使い方については、Python Workers のドキュメントに詳しい情報があります。

Hyperdrive で PostgreSQL と MySQL を使う

PostgreSQL や MySQL のようなリレーショナルデータベースで Python アプリを構築しているなら、Hyperdrive を Python Workers に統合できるようになりました。

これまで Python Workers は TCP socket をサポートしておらず、データベースドライバを使えませんでした。これがなぜ障害になるのかを理解するには、WebAssembly の仕組みを見る必要があります。aiomysql や asyncpg といった Python のデータベースドライバは、標準ライブラリの socket モジュールに依存して接続を確立します。標準的な環境では、このモジュールが基盤となるオペレーティングシステムに対して POSIX システムコールを発行します。ところが WebAssembly サンドボックスでは、こうした POSIX のネットワークシステムコールはたいてい常に失敗するスタブで、標準 socket を開こうとする試みは即座に失敗します。この問題を解決するため、私たちは Workers の connect API を使って socket システムコールを実装しました。

データベースドライバが TCP 接続を開こうとすると、私たちが独自に実装した socket システムコールが呼ばれます。これは接続の確立やバイトの読み取りといった標準的な Python socket 操作を、Workers ランタイムが使う対応する JavaScript 呼び出しに変換します。この変換はシステムコールのレベルで行われるため、データベースドライバは下層の実装を一切知る必要がありません。

この socket ブリッジがあるからこそ、Hyperdrive の統合が可能になりました。Python Workers で Hyperdrive を使うには、まず Hyperdrive でデータベースに接続し、Wrangler の設定でバインディングを指定します。

"hyperdrive": [
 {
 "binding": "HYPERDRIVE_MYSQL",
 "id": "",
 }
]

あとは使い慣れたデータベースドライバで Hyperdrive に接続するだけです。

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()
 await cur.close()
 conn.close()

Python Workers で Hyperdrive を使う方法や、現在サポートされているパッケージについては、Hyperdrive の Python Workers ドキュメントを参照してください。

WebAssembly パッケージエコシステムを広げる

Python Workers は WebAssembly サンドボックス上で動作するため、ネイティブの C/C++/Rust 拡張を含むパッケージは、Python Workers で動かすには WebAssembly にクロスコンパイルしなければなりません。しかしこれまで、任意の Python パッケージを WebAssembly にクロスコンパイルする標準的な方法は存在しませんでした。そのため私たちのチームは手作業でカスタムの WebAssembly パッケージをコンパイルしてホストするしかなく、Python Workers で実際に使えるパッケージはごく限られていました。

私たちはこの問題を解決し、より多くの種類のパッケージを使えるようにしたいと考えました。ただし、Python Workers でしか使えないパッケージを作るつもりはありません。それではコミュニティの利益になりません。Python Workers は Pyodide の上に構築されているので、エコシステムの進化が Pyodide と Python-on-WebAssembly コミュニティ全体の利益になることを望んでいます。

そこで私たちは PEP 783 を提案し、ブラウザランタイムで Python を動かすための標準プラットフォームを PyEmscripten として定義しました。1 年以上の議論と練り直しを経てこの提案は承認され、パッケージメンテナは PyEmscripten プラットフォーム向けにパッケージをビルドして公開できるようになりました。こうしたパッケージは、PyEmscripten を実装するあらゆる環境で利用できます。

私たちは既存の Pyodide ビルドツールチェーンも安定化させ、すべてのパッケージメンテナが使える形に進化させました。これにより開発者は PyEmscripten プラットフォーム向けのパッケージを簡単にビルドできます。さらに cibuildwheel に PyEmscripten プラットフォームのサポートを追加し、他の人たちもこのプラットフォームへの対応を進めやすくしました。

エコシステムはまだこの標準を採用している途中ですが、将来はすべての Python パッケージに WebAssembly で使える wheel が用意されることを期待しています。私たちは主要パッケージのメンテナとも積極的に協力し、PyEmscripten ビルドの追加を進めています。まだ対応していないパッケージがあれば、Discord か GitHub で知らせてください。私たちのチームがビルドに取りかかります。

私たちがこれをどう実現したかは、EuroPython 2026 での講演「Python Everywhere: The State of Python on WebAssembly」でもご覧いただけます。

Python で AI agent と pipeline を構築する

データサイエンスや機械学習のパッケージエコシステムは大きく、Python でインテリジェントな agent や AI pipeline を構築するのは自然な選択です。しかし、それらを Python Workers に持ち込むには長らく課題がありました。openai や langchain といったライブラリは requests や httpx などの HTTP クライアントに依存して外部 API と通信しますが、Python Workers には低レベルの socket 操作のサポートがなく、これらの HTTP クライアントは動作しません。

そのために私たちは上流に変更を送り、これらの HTTP クライアントが WebAssembly 環境で JavaScript の fetch API を通じて直接リクエストを送れるようにした。前節で触れた低レイヤの socket 操作への新たな対応と合わせ、ネットワークスタック全体が Python Workers 上で問題なく動くようになっている。

これにより、openai、langchain、mcp といった AI ライブラリがそのまま Python Workers で動く。Workers AI と組み合わせれば Cloudflare ネットワークの GPU 上でサーバーレス推論を実行でき、Cloudflare AI Gateway 経由でリクエストをプロキシすることもできる。

次の例は、langchain-cloudflare パッケージを使って langchain で Workers AI のモデルを動かす方法を示している。

from langchain_cloudflare import ChatCloudflareWorkersAI
from langchain_core.output_parsers import StrOutputParser
from langchain_core.prompts import PromptTemplate
from workers import Response, WorkerEntrypoint

class Default(WorkerEntrypoint):
 async def fetch(self, request):
 prompt = PromptTemplate.from_template(
 "In one sentence, describe a great day in the life of an {profession}."
 )
 llm = ChatCloudflareWorkersAI(
 model_name="@cf/meta/llama-3.3-70b-instruct-fp8-fast",
 binding=self.env.AI,
 max_tokens=64,
 )
 chain = prompt | llm | StrOutputParser()

 result = await chain.ainvoke({"profession": "electrician"})
 return Response.json({"result": result})

今すぐ作れるもの

python-workers-examples リポジトリに、そのまま本番で使えるパターンをまとめた。以下は Python Workers と Cloudflare エコシステムを組み合わせた使い方の一部だ。

非同期 AI オーケストレーション

フルスタックの AI アプリを作るには、ストレージ、キュー、推論といった複数のサービスをつなぐ必要があることが多い。このサンプルでは、AI による画像生成ツールを Python Workers だけで構築する方法を示している。ユーザーのリクエストを受け取り、Cloudflare Queue に投入し、Workflows で Workers AI を経由した画像生成の各ステップをオーケストレーションし、生成された画像を R2 バケットに保存する。

Bluesky Jetstream によるリアルタイムストリーム処理

リアルタイムのイベント洪水を消費するには、通常は接続を維持するための専用サーバーが要る。このサンプルでは、Python Worker で ATProto/Bluesky Jetstream の WebSocket に接続する。この接続を Durable Object が支えることで、Python Worker は長期にわたる状態を保ち、WebSocket 接続を切らさずに済む。

その他のサンプル

Model Context Protocol（MCP）Server

公式の Python MCP パッケージを使って MCP server を構築・デプロイする。AI アシスタントからエッジのデータにアクセスできるようになる。

Vectorize による検索拡張生成（RAG）システム

Workers AI と、Cloudflare のベクトルデータベースである Vectorize を使って RAG システムを構築する。

Cloudflare 開発者ドキュメントの Python コード例

Cloudflare 各製品のドキュメントを更新し、Python のサンプルコードを追加した。TypeScript でのやり方を示すコード例はほぼすべて、対応する Python 版を備えている。今後も全製品に Python の例を追加していく。開発者ドキュメントでは、JavaScript、TypeScript、Python の間でコードスニペットを切り替えられる。

次のステップ

正式リリースはあくまで始まりにすぎない。パフォーマンスとメモリ効率の改善、対応パッケージの拡充など、Python Workers をより良くするための計画は数多くある。

Python Workers で何を作りたいか、引き続き教えてほしい。私たちも可能性の境界を広げ続ける。さっそく Python Workers のドキュメントを読んで、最初の Python Worker を作ってみよう。