Cloudflare、Pythonを速さで勝負　引き換えに使えるパッケージは選別制に

Cloudflareが、Python Workersをベータ版から正式サービスに移した。Pythonは、これまでJavaScript Workersを動かしてきたのと同じ基盤で、本番環境向けの実行環境として使えるようになった。

単なる呼び名の変更ではない。正式サービスにするというのは、事業としての約束でもある。安定して使えること、サポートが受けられること、Pythonがこのプラットフォームの主役級の言語であり続けることを意味する。

もっと面白いのは、そこに至った道筋のほうだ。CloudflareはPython用にコンテナのサービスを足したわけではない。

Workersの土台であるアイソレートという仕組みの中にPythonを収めた。この選択が、開発者にできることとできないことを形づくっている。

この記事のポイント

• Python Workersが正式サービスになった。Cloudflareは、ずっと提供し続けるサポート付きの実行環境として位置づけている。
• Pythonは、インタープリターをWebAssemblyにしたPyodide経由で動く。コンテナではなく、V8アイソレートの中で実行される。
• デプロイ時にメモリのスナップショットを取り、Pythonの遅い起動処理をリクエスト時からビルド時に移している。

正式サービス化が意味すること

Workersは、長いあいだJavaScriptを中心にしたプラットフォームだった。Pythonへの対応はあったが、試験的な位置づけだった。

試験的な機能は、仕様が変わることもあれば、静かに打ち切られることもある。その不安のせいで、本番のシステムを載せるのをためらうチームは多かった。

正式サービスになって、その不安が取り除かれた。今後数年そのサービスをどこで動かすかを決めるチームにとって、変わるのは次の3点だ。

• 安定性：APIや動作が、ベータ版のたびに変わらず、一貫していると見込める。
• サポート：企業の利用者は、ほかの本番向け製品と同じ扱いで保守を期待できる。
• 継続性：Cloudflareがこの実行環境を維持し続けるのかという疑問は、ほぼ解消された。

この発表は、技術的な方針への自信も示している。

PythonをWebAssemblyにして動かすことも、インタープリターの状態を保存しておくことも、始めた時点では実績のない発想だった。それを正式サービスに格上げしたのだから、Cloudflareはこの方式が試作の段階を越えたと考えているのだろう。

この約束を支える設計の選択

では、何が難しかったのか。鍵は、プラットフォームの土台にある。

WorkersはV8アイソレートの上に作られている。アイソレートは、1つのプロセスを共有する軽い隔離環境だ。Cloudflareの強みは、ここから生まれている。

• コールドスタート（しばらく使われていなかったコードの初回起動）が非常に速い。ミリ秒単位か、それ以下のことも多い。
• 多くの利用者のコードを、1台のマシンに低コストで詰め込める。

Pythonは、こうした環境を想定して作られた言語ではない。AWS LambdaやGoogle Cloud Runでは、Pythonをコンテナやネイティブの実行環境で動かすのが普通だ。Cloudflareはその道を選ばなかった。

言語が違っても実行の仕組みを1つにそろえる。その価値は、技術的な手間に見合うというのがCloudflareの賭けだ。 もしPythonをコンテナで動かせば、Python Workersはコンテナと同じ起動の遅さと同じ費用構造を抱えることになる。

名前だけ同じで、中身は別の製品になってしまう。Pythonをアイソレートの中に置けば、Workersらしい低い遅延と低いコストを保てる。

図2：V8 Isolates vs. コンテナアーキテクチャの比較（Cloudflare Workers アーキテクチャ設計）

アイソレートの中でPythonはどう動くのか

Python Workersは、CPythonをそのまま動かしているわけではない。使っているのはPyodideだ。

Pythonのインタープリターを、WebAssemblyにして動くようにしたものである。そのWebAssemblyのモジュールが、JavaScript Workersを動かしているのと同じアイソレートの技術の上で走る。

図4：Python Workers の実行フロー - Pyodide と WebAssembly によるメモリスナップショット活用

起動が遅いという問題

Pythonのインタープリターは、起動に時間がかかる。自分のコードがリクエストを処理する前に、インタープリターを初期化し、標準ライブラリを読み込み、外部の依存パッケージも読み込まなければならない。

大きなフレームワークや科学計算のライブラリだと、この準備にかかる時間が、リクエストの処理時間をはるかに上回ることもある。それをコールドスタートのたびに繰り返せば、アイソレートの速さという長所が消えてしまう。

メモリのスナップショットで解決する

Cloudflareは、メモリのスナップショットでこの問題に対処している。流れは次のとおりだ。

1. デプロイ時に、プラットフォームがインタープリターを起動し、宣言された依存パッケージをすべて読み込む。
2. 同じくデプロイ時に、その結果のメモリの状態をスナップショットとして保存する。
3. リクエストを受けたときは、初期化をやり直さず、そのスナップショットを復元する。
4. ハンドラーは、すでに温まった状態のインタープリター上で動く。

重い起動処理は、リクエスト時からビルド時に移る。 初期化の負担は、コールドスタートのたびではなく、デプロイ1回につき1度で済む。

この設計で制約されること

このやり方は、動きが予測しやすい処理にはよく合う。一方で、Pythonのコードにできることは狭くなる。

• インポート時の動作が固定される：インポートの最中に起きたことは、すべてスナップショットに残る。プロセスごとに新しい状態を期待するコードや、インポート時にネットワークを呼んだり乱数を作ったりするコードは、注意深い扱いが必要になる。
• ネイティブ拡張には個別の対応が要る：Cで書かれた部分を含むパッケージは、WebAssembly向けにビルドされ、Cloudflareが対応していなければならない。PyPIのパッケージを何でも入れられるわけではない。
• スレッドが制限される：この環境のWebAssemblyには、一部のPythonライブラリが前提にしているスレッドの仕組みがない。
• 使えるパッケージは選ばれている：NumPyのような主要ライブラリは動く。純粋なPythonだけでできたパッケージも、たいてい動く。Cloudflareが対応する範囲を超えてネイティブの依存を持つパッケージは、動かないことがある。

アイソレートとコンテナの比較

コンテナ型のサーバーレスと並べると、得るものと失うものがよく分かる。次の表は、両者を6つの観点で比べたものだ。

遅延と密度ではアイソレートが勝ち、互換性ではコンテナが勝つ。

Python Workersを選ぶ開発者は、速さと引き換えに、使えるエコシステムの狭さを受け入れることになる。Pythonの世界のあらゆる道具が動くとは考えられない。

プラットフォームのデータ層につなぐ

実行環境は、データに届かなければ役に立たない。Cloudflareの答えは、バインディングだ。

バインディングとは、WorkerとプラットフォームのリソースをつなぐあらかじめWorkerに宣言しておくリンクである。権限のように働き、Workerは自分に結び付けられたものにしかアクセスできない。

Pythonでは、この仕組みが、内部のJavaScriptのインターフェースを包んだPython向けのラッパーとして現れる。開発者は普通のPythonを書けばよく、JavaScriptの層を直接扱わなくて済む。

この節のポイント

• バインディングは、余計なネットワークの経由なしに、WorkersをCloudflare自身のデータサービスにつなぐ。
• FastAPI、データベース、ストレージ、キャッシュ、メッセージキューを、1回のデプロイでネイティブのPythonとして組み合わせられる。
• 外部のシステムにはHTTPクライアントが必要で、遅延も生じる。ロックインが始まるのはこの境目だ。

図6：Python Workers からデータプレーンへのアクセスアーキテクチャ

使えるバインディング

よくある用途に向けて、Cloudflareは主に4種類のバインディングを用意している。

Pythonだけで完結するアプリ

バインディングが大切なのは、Pythonから離れずにWebアプリ全体を作れるからだ。FastAPIなどのフレームワークにも対応している。

1回のデプロイに、次のような部品をまとめられる。

• FastAPIで作ったPythonのAPI
• リレーショナルなデータを扱うD1
• ファイルを置くR2
• キャッシュに使うKV
• リクエストを待たせたくない処理のためのQueues

これらはすべて1つのデプロイ単位に収まり、Python本来の書き方で扱える。

自然な境目

バインディングが使えるのは、Cloudflare自身のサービスだけだ。たとえば、別の場所で動いているPostgresのデータベースにつなぐことも、もちろんできる。

ただし、通常のHTTPやネットワークのクライアントを通すことになり、同じ場所に置かれたリソースならではの低遅延は得られない。

ここから、分かりやすい目安が引ける。

• バインディングを使う：Cloudflare上にあるデータと密に連携したいとき。
• HTTPクライアントを使う：外部のシステムにつなぐとき。その呼び出しには余分な遅延がかかる。

この境目は、ロックインが始まる場所でもある。アプリがバインディングに頼るほど、よそへ移すときの手間は大きくなる。

AIアプリケーションの土台としてのPython

機械学習やデータの仕事では、Pythonが圧倒的に使われている。だからこそ、今回の発表はWebホスティングの便利さにとどまらない意味を持つ。

AIを使ったアプリケーションの基盤は、層に分かれつつある。

エージェントの振る舞いを定めるための仕様を決めるフレームワーク、エージェント向けのインターフェースを備えた部品の仕組み、エージェントに長く続く文脈を持たせる永続化の道具、といった具合に役割が分かれてきた。

そして、これらの部品はどれも、動かす場所を必要とする。

図8：エッジランタイムの比較 - Cloudflare Workers vs. 従来型クラウド（出典：Cloudflare Workers 市場分析、クラウドプロバイダー公式ドキュメント）

Python Workersが合う場面

世界中に分散し、遅延が小さく、使わないときは0までスケールダウンするPython環境は、エージェントまわりの調整役に向いている。典型的な使い道は次のとおりだ。

• ツールのエンドポイント：エージェントがデータの取得や操作のために呼び出す窓口。
• Webhookのハンドラー：ほかのサービスで起きたイベントに反応する処理。
• 検索パイプライン：モデルを呼ぶ前に、必要な文脈を集める処理。
• 軽い推論のルーティング：リクエストをWorkers AIに転送するような処理。

この役割でのPython Workersは、エージェントと外部のシステムのあいだに立つ、薄くて速い実行層になる。すでにエージェントの処理をPythonで書いているチームは、JavaScriptに書き直さずにそのままデプロイできる。

合わない場面

Python Workersは、重いモデルの推論や、長く続くループを回すための計算基盤ではない。アイソレートにはCPUとメモリの上限があり、そうした処理は載せられない。

大きなモデルをメモリに置く処理、持続的な計算、長時間動き続けるプロセスは、別の基盤に任せるのが筋だ。

現実的な使い方は、ステートレスな関数だ。リクエストを受けて振り分けや補強をし、外部のAPIやモデルを呼び、長い処理はQueuesに渡し、結果をD1、R2、KVに保存する。 ストレージやキューへのバインディングがあるので、ステートレスな関数を組み合わせて、状態を持つエージェントのワークフローを作れる。この形が広まれば、分散型のAIアプリの定番になるかもしれない。

ただし、それは、選別されたパッケージの範囲が、AIチームが実際に使うライブラリをどこまで覆えるかにかかっている。

競合との位置関係と、使う前に考えること

Python Workersが入ってきた市場には、すでにAWS Lambda、Google Cloud Run、VercelがPython対応を用意している。これらはPythonをコンテナや完全な実行環境で動かすので、ほとんどのパッケージを手を加えずに使える。

Cloudflareは、別の軸で勝負している。

この節のポイント

• Cloudflareの強みは、低い遅延、費用の面での密度、自社サービスとの密な連携にある。ライブラリの幅広さではない。
• アイソレートの設計は、どんなパッケージでも動く互換性を、速さと安さに替えている。これは意図した選択で、一時的なものではない。
• WorkersでLambdaやCloud Runを置き換えようとせず、処理の性質に合わせて使い分けたほうがよい。

Cloudflareの方式が勝つ場面と負ける場面

Cloudflareの競争上の立ち位置は、次の3つの違いにかかっている。

• 遅延：アイソレートとスナップショットのおかげで、コンテナより速くリクエストを始められる。
• 費用の密度：0までのスケールダウンと、1台あたりの高いリクエスト密度で、量が増えたときの1リクエストあたりのコストが下がる。
• 連携：D1、R2、KV、Queuesへのバインディングがあるので、Cloudflareのサービスは、外部のプラットフォームから使うよりWorkersから使うほうが簡単だ。

引き換えに差が出るのは、ライブラリの対応範囲だ。

ネイティブの依存を持つパッケージは、1つずつ対応していくしかない。そのため、ほとんど何でもそのまま動くLambdaやCloud Runと比べると、Python Workersの対応範囲は常に見劣りする。

Cloudflareは今後もパッケージ対応を広げていくだろうが、アイソレートの設計上、互換性は選別されたままで、すべてには広がらない。これは意図した選択であり、いつか埋めるべき欠点ではない。

本当の問い：JavaScriptのチームの外へ広がれるか

戦略上の試金石は、Python Workersがデータチームやaiチームにとって信頼できるプラットフォームになるのか、それともCloudflareのJavaScriptの環境に慣れた開発者が好んで使う、ニッチな道具で終わるのかだ。

行く手には、3つの壁がある。

• エコシステムへの囲い込み：バインディングのおかげでCloudflareのサービスは使いやすく、離れにくくなる。D1やR2を軸に作ったチームは、移行のコストを負う。
• パッケージの成熟度の差：対応範囲は、標準的なPython環境に追いついていない。pip installがそのまま通ることに慣れたチームには、制約がもどかしく感じられるだろう。
• すでに慣れている人が多い：LambdaやCloud Runを知っているチームは多い。遅延が大きくなっても、その互換性のほうを選ぶ人はいるはずだ。

この壁が問題になるかどうかは、処理の性質で決まる。

APIやWebhook、データパイプライン、AIの調整役のように、遅延と0までのスケールダウンによる料金が最重要の条件になる場面では、Workersの方式には確かな強みがある。

特定のパッケージに頼る処理や、長く動き続ける処理には、LambdaやCloud Runのほうが合っている。

自分の用途で見極めるには

1. 処理の性質を見る：Python Workersが活きるのは、APIやWebhook、データパイプライン、AIの調整役のように、パッケージの幅広さより、遅延と0までのスケールダウンによる料金が大事な場面だ。
2. 依存パッケージを先に調べる：ネイティブのコードを含むパッケージがすべて対応しているか確かめる。プラットフォームを前提に設計する前に済ませておく。
3. インポート時のコードを見直す：ネットワークの呼び出し、乱数、プロセスごとの状態をモジュールのインポートの外に出す。スナップショットが予測どおりに動くようにするためだ。
4. バインディングは意識して使う：すでにD1、R2、KV、Queuesを使っているなら、自然な延長として使えばよい。ただし、それが生むロックインは理解しておく。
5. 重い処理は別の場所で：独自のC拡張、大きなモデル、長時間のジョブは、Lambda、Cloud Run、専用の計算環境のほうが向いている。

ちょっと立ち止まって

サーバーレスのPythonといえば、長いあいだコンテナのことだった。前提は単純だった。Pythonには完全な環境が要るのだから、それを与えて、起動の遅さは受け入れる、というものだ。

Cloudflareは、Pythonに合わせてプラットフォームを作り替えるのではなく、プラットフォームに合わせてPythonの動かし方を作り替えた。それが正しい判断だったかどうかは、何を作るかで変わる。

自分の使っている技術についても、考えてみたくなる問いがある。言語に必要だと思い込んでいるものの、どこまでが本当に必要で、どこからが昔の環境に慣れてきただけの習慣なのだろうか。

アイソレートという方式は、小さなJavaScriptの関数以外には窮屈すぎると、かつては見られていた。それがいま、本番向けのPython実行環境を動かしている。

Workersでは、言語の選択が、設計上の大きな決断ではなく、実用上の判断に近づいてきた。あなたの環境にある「必須条件」のうち、同じように見直しても残るものは、どれだけあるだろうか。

図9：エッジコンピューティングプラットフォームの競争ポジション（Cloudflare Workers市場分析）