Cloudflare が、Workers 上で Python を本格運用できる「Python Workers」を一般提供に切り替えました。これまでも試せはしたものの、今回は「実験」から「正式な選択肢」へ格上げされた形です。TypeScript だけでなく Python でも、Cloudflare のエッジ実行基盤にそのまま乗せられるようになったのが大きい。しかも D1、R2、Workers AI など周辺サービスとも JavaScript の接着コードなしでつなげる、と Cloudflare は強く打ち出しています。
元記事が伝えているのは、Cloudflare が Python Workers を generally available、つまり一般提供にしたという発表だ。Python Workers は、Cloudflare Workers の実行環境の中で Python アプリを動かす仕組みで、Cloudflare によれば、これで Python は Developer Platform の「first-class」、つまり最初からきちんと支える言語になった。単に Python が動くという話ではなく、すでに Python で書いているコード、ライブラリ、開発の流儀をそのまま持ち込めるのが売りになっている。
Cloudflare は具体的に、Workers AI、R2、D1、Hyperdrive、Durable Objects、Queues、Workflows などと自然につながると説明している。要するに、実行環境だけでなく、保存先や非同期処理、AI 推論まで含めて、Cloudflare の各サービスを Python からまとめて扱えるということだ。さらに、FastAPI、Django、Flask といった定番の Python フレームワークも Python Workers の中で動かせるとしている。Web アプリの作法を大きく変えずに、Cloudflare のエッジに載せられる点を強調しているわけだ。
記事には簡単なコード例もある。FastAPI で / にアクセスしたとき、request.scope["env"] から環境を取り出し、env.AI.run(...) を呼んでいる。モデル名として @cf/openai/gpt-oss-120b を指定し、「You are a friendly assistant.」という instruction と、「What is the origin of the phrase Hello, World?」という入力を渡している。ここでのポイントは、Python の API からそのまま Workers AI を呼べることだ。Cloudflare は「JavaScript glue code」、つまり Python と Cloudflare 側のサービスをつなぐための余計な JavaScript を書かなくてよいとも述べている。
背景として、Cloudflare は Python Workers を 2 年前に導入したと振り返っている。Workers が 2018 年から WebAssembly をサポートしていたため、Wasm にコンパイルした Python interpreter を動かす土台があった。そこに Pyodide を使うことで、幅広い Python アプリを比較的早く動かせたという。Cloudflare はこの取り組みを、多段階の開発を経てきた結果として今回ようやく production-ready、つまり本番利用できる状態にしたと位置づけている。簡単に言えば、「Python をちょっと動かせる」から「Python を主要言語として預けられる」段階へ進めた、という発表だ。
私がまず面白いと思ったのは、Cloudflare が Python Workers を単なる言語追加として扱っていないことだ。この記事の書き方はかなり明確で、Python を Workers の上に載せるのではなく、Cloudflare の開発プラットフォーム全体の入口を増やす、という発想になっている。TypeScript に慣れた人だけでなく、Django や Flask に慣れた人にも「そのまま来ていい」と言っているわけで、これはかなり営業的でもあるし、同時に本気のプラットフォーム戦略でもあると思う。
特に効いているのは、AI とストレージ、ジョブ管理をひとまとめにしている点だ。Python の強みは、もともと Web フレームワークだけでなく、機械学習やデータ処理の周辺に厚いことにある。Cloudflare はそこを見ていて、Python を使う人が欲しがる周辺部品を、R2 や D1、Workers AI、Queues、Workflows としてまとめて差し出している。つまり「Python を使う理由」と「Cloudflare を使う理由」を重ねようとしている。これはかなり筋がいい。
元記事がさらっと触れている WebAssembly と Pyodide の組み合わせも、実は重要だと思う。Cloudflare は最初からネイティブな Python 実行環境を作ったのではなく、Workers が持つ Wasm の土台を使って Python interpreter を載せた。こう書くと遠回りに見えるが、エッジで安全に、しかもスケール前提で動かすにはかなり現実的な選び方だ。ブラウザ由来の技術をうまく流用しているのも Cloudflare らしい。
ここで注目したいのは、Cloudflare が「Python を速く動かす」ことだけを前面に出していないことだ。もちろん性能は大事だが、記事全体のトーンはむしろ「既存の Python の書き方を壊さずに持ち込めるか」に寄っている。開発者は速さそのものより、移植のしやすさや、既存資産をどこまで再利用できるかを気にすることが多い。Pyodide を使った選択は、その不安を減らすための設計に見える。完璧なネイティブ実装を待つより、今ある Python の世界と接続することを優先した、ということだろう。
コード例で FastAPI からそのまま Workers AI を呼んでいたのも象徴的だった。これは単なるデモではなく、Cloudflare がどこに利用シーンを見ているかをかなりはっきり示している。最近の Python Web アプリは、画面を返すだけでなく、裏で LLM を呼んだり、要約したり、分類したりする処理を抱え込みやすい。そうなると、アプリの中核が「HTTP を受けて、AI に投げて、結果を返す」になっていく。Cloudflare はその中心をエッジに置かせたいのだと思う。
ここで JavaScript glue code を不要だと強調しているのは、見た目以上に効く。言語をまたぐと、認証、型、データの受け渡し、デプロイ時の設定で地味な摩擦が増える。Python アプリがそのまま Workers AI や R2 に触れれば、そうした摩擦が減る。これは開発者体験の改善に直結するし、特に小さなチームや個人開発では大きいはずだ。逆に言えば、Cloudflare は「便利だから試す」段階を超えて、「本番でも面倒が少ないから残る」状態を狙っているのではないか。
とはいえ、ここは少し冷静に見たほうがいい。記事はかなり前向きだが、Python Workers が本当にどこまで Python らしく動くのかは、実際の制約で印象が変わる。Wasm ベースである以上、C 拡張に強く依存するライブラリや、環境に深く寄るパッケージはそのままでは動かない可能性がある。Cloudflare は「幅広い Python applications」と言っているが、Python の世界は広すぎるので、万能という意味には受け取らないほうがいいと思う。
ただ、その制約があっても価値はある。むしろ Web アプリの本体、API、軽い AI オーケストレーション、ワークフローの入り口のような用途なら、十分に実用圏に入る可能性が高い。Cloudflare が GA にしたことは、少なくとも「試作向け」から「本番候補」へ一段上がった合図だ。今後は性能のベンチマークよりも、どの Python パッケージがどこまで素直に動くか、既存の Django/FastAPI/Flask 資産をどれだけ持ってこられるかが評価の中心になるはずだ。そこを突破できれば、Cloudflare は JavaScript 以外の開発者をかなり広く取り込めると思う。
