Cloudflare Workers は 2026 年 9 月 21 日に Python を正式サポート(GA) しました1。いまは Python Workers を本番で使ってよい段階です。uv と pywrangler で雛形を作れば、FastAPI のアプリも KV・D1 などのバインディングもそのまま Python で書けます。料金と上限は JavaScript の Workers と同じです。この記事では、2026 年 10 月 7 日に筆者が手元(macOS)で実行したコマンドと出力をもとに、始め方、FastAPI・KV・D1 の使い方、仕組み(Pyodide とメモリスナップショット)、使えるパッケージと制限、JavaScript の Workers や AWS Lambda との使い分けをまとめます。
Python Workers は、Python で書いたコードを Cloudflare Workers の上で動かす仕組みです。CPython を WebAssembly にした Pyodide が V8 isolate の中で動きます。ビルドや事前のコンパイルは要りません2。設定ファイル(wrangler.jsonc)の main に .py ファイルを書き、互換性フラグ python_workers を付けるだけで Python の Worker になります。
entry.py と依存パッケージを pywrangler が集めて wrangler に渡し、Cloudflare の V8 isolate 内の Pyodide で動く流れ図: 筆者作成(Cloudflare 公式ドキュメントをもとに作図)
できることは JavaScript の Workers とほぼ同じです。2026 年 10 月時点で、次のものが Python から使えます13。
| 分類 | 使えるもの |
|---|
| HTTP の入口 | fetch ハンドラ、FastAPI・Starlette(ASGI)、Django・Flask(WSGI) |
| データ | KV、D1、R2、Durable Objects、Hyperdrive(PostgreSQL / MySQL) |
| 非同期処理 | Queues、Workflows、Cron トリガー |
| AI | Workers AI、Vectorize、openai・langchain・mcp などのパッケージ |
| 連携 | サービスバインディング(RPC。JavaScript の Worker との相互呼び出しも可) |
関連するツールのページ: Python、FastAPI、Django、Flask
理由は、2026 年 9 月に GA になり、それまで足りなかった機能がこの 1 年でそろったからです。Python Workers は 2024 年 4 月にオープンベータとして公開されました4。その後、コールドスタートの改善、パッケージ管理、Web フレームワーク対応が順に入り、Birthday Week 2026 の初日に GA が発表されました1。
| 時期 | 出来事 |
|---|
| 2024-04 | Python Workers をオープンベータで公開4 |
| 2025-08-14 | ハンドラを WorkerEntrypoint クラスで書く形に変更5 |
| 2025-12-08 | pywrangler と uv 中心の流れが登場。メモリスナップショットでコールドスタートを短縮6 |
| 2026-08-03 | Python と JavaScript の Worker が RPC で呼び合えるように7 |
| 2026-09-02 | Django・Flask(WSGI)などの Web フレームワークに対応8 |
| 2026-09-08 | 互換性日付 2026-09-08 以降は Python 3.14 が既定に9 |
| 2026-09-16 | Hyperdrive(PostgreSQL / MySQL)に対応10 |
| 2026-09-21 | GA。Python を「完全にサポートする言語」と発表1 |
GA の発表で特に効くのは次の 3 点です1。
- バインディングの型変換が自動になった: 以前は
to_js() で Python の dict を JavaScript のオブジェクトに変換していました。いまは self.env.QUEUE.send({"key": "value"}) とそのまま書けます
- TCP ソケットが使える:
asyncpg や aiomysql のような DB ドライバが、Hyperdrive 経由で PostgreSQL・MySQL につながります
- AI 系のパッケージが動く:
openai・langchain・mcp が、HTTP クライアントの上流への修正によってそのまま動きます
ただし表記には揺れがあります。2026 年 10 月 7 日時点で、雛形を作る create-cloudflare v2.73.3 は言語の選択肢に「Python (beta)」と表示しました(筆者が実行して確認)。GA の判断は公式ブログの発表を基準にしてください。
始め方は、uv を新しくする → pywrangler init で雛形を作る → pywrangler dev で動かす → pywrangler deploy で公開する、の 4 段階です36。pywrangler は Python のパッケージを Worker に同梱する CLI です。sync 以外のコマンドはすべて wrangler にそのまま渡します。
uv で pywrangler init を実行して雛形を作り、pywrangler dev を起動して curl で Hello World! が返るまでのターミナル操作筆者が 2026-10-07 に実行した出力をもとに再現(一部省略)
前提(筆者の環境、2026 年 10 月 7 日):
- uv 0.12.23、workers-py(pywrangler)1.17.7、wrangler 4.148.0、Node.js 24.6.0
- Cloudflare アカウント(デプロイするときだけ必要。ローカルで試すだけなら不要)
pywrangler は uv 0.12.3 以上を求めます。古い uv のままだと dev で止まります。筆者の環境では uv 0.8.17 で次のエラーが出ました。
$ uv run pywrangler dev
ERROR uv version at least 0.12.3 required, have 0.8.17.
ERROR Update uv with `uv self update`.
先に更新しておきます。Homebrew で入れた uv は brew upgrade uv で更新します。
uv self update
uv --version
公式の手順は uvx --from workers-py pywrangler init です3。対話で言語やテンプレートを選びます。CI やエージェントから使うときは、選択をフラグで渡します。
uvx --from workers-py pywrangler init hello-py --type hello-world --no-git --no-open -y
cd hello-py
実行すると次のファイルができます。
hello-py/
├── wrangler.jsonc # main = src/entry.py、compatibility_flags = ["python_workers"]
├── pyproject.toml # 依存パッケージ(dependencies)と開発用の workers-py
├── package.json # dev / deploy のスクリプト(中身は uv run pywrangler ...)
├── .python-version
└── src/
├── entry.py
└── submodule.py
src/entry.py の中身は次のとおりです。WorkerEntrypoint を継承した Default クラスの fetch がリクエストを受けます5。
from workers import Response, WorkerEntrypoint
from submodule import get_hello_message
class Default(WorkerEntrypoint):
async def fetch(self, request):
return Response(get_hello_message())
wrangler.jsonc の要点はこの 3 行です。
{
"main": "src/entry.py",
"compatibility_date": "2026-10-06",
"compatibility_flags": ["python_workers"]
}
--agents を付けると、AI コーディングエージェント向けの AGENTS.md も作られます(pywrangler init --help で確認)。Claude Code や Codex で開発を続けるなら付けておくとよいでしょう。
uv run pywrangler dev
初回は Pyodide(約 7.2 MiB)を取得し、Worker 用の仮想環境 .venv-workers と、同梱するパッケージを置く python_modules/ を作ります。そのあと wrangler dev に処理を渡します。筆者の環境での出力(抜粋。筆者は別のポートで起動したため、ポート番号だけ既定の 8787 に置き換えています)です。
Downloading pyodide-3.14.2-emscripten-wasm32-musl (download) (7.2MiB)
Creating virtual environment at: .venv-workers/pyodide-venv
INFO Installing packages into python_modules...
INFO Passing command to npx wrangler: npx --yes wrangler dev
⛅️ wrangler 4.148.0
│ Vendored Modules │ │ 107.52 KiB │
│ Total (31 modules) │ │ 107.57 KiB │
[wrangler:info] Ready on http://localhost:8787
[wrangler:info] GET / 200 OK (4124ms)
[wrangler:info] GET / 200 OK (4ms)
別のターミナルから確かめます。
$ curl -s http://localhost:8787/
Hello World!
最初のリクエストだけ約 4 秒かかり、2 回目からは 4ms でした。最初の 4 秒は手元で Pyodide を読み込む時間です。本番のコールドスタートとは別物なので、性能の判断には使わないでください。
uv run pywrangler login
uv run pywrangler deploy
deploy は、パッケージの同梱(sync)を済ませてから wrangler deploy を実行します。デプロイのときにトップレベルのコードが一度実行され、そのメモリの状態がスナップショットとして保存されます(後述)6。筆者はこの記事のためにデプロイしていないので、本番の応答時間は測っていません。
FastAPI は、from workers import asgi と Default = asgi.entrypoint(app) の 2 行で Worker になります111。バインディング(KV や D1)は、FastAPI のリクエストの request.scope["env"] から取り出します。以下は筆者が手元の pywrangler dev で動かしたコードです。
uv add fastapi
pyproject.toml の dependencies に追加されます。次の dev か deploy のときに、Worker 用のパッケージが python_modules/ に入ります。筆者の環境では、FastAPI 0.142.2 が入りました。pydantic のネイティブ部分(pydantic-core)は、PyEmscripten 向けの wheel(pyemscripten_2026_0_wasm32)が自動で選ばれました。
wrangler.jsonc に KV と D1 を足します。ID はデプロイ時に本物に置き換えます。ローカルでは仮の値で動きます。
{
"name": "fastapi-py",
"main": "src/entry.py",
"compatibility_date": "2026-10-06",
"compatibility_flags": ["python_workers"],
"kv_namespaces": [{ "binding": "KV", "id": "local-dev-kv" }],
"d1_databases": [
{ "binding": "DB", "database_name": "py-demo", "database_id": "local-dev-d1" }
]
}
ローカルの D1 にテーブルを作ります。
uv run pywrangler d1 execute DB --local \
--command "CREATE TABLE todos (id INTEGER PRIMARY KEY AUTOINCREMENT, title TEXT NOT NULL)"
import sys
from fastapi import FastAPI, Request
from workers import asgi
app = FastAPI()
@app.get("/")
async def root():
return {"message": "Hello from FastAPI on Workers", "python": sys.version}
@app.put("/kv/{key}")
async def kv_put(key: str, request: Request):
env = request.scope["env"]
await env.KV.put(key, (await request.body()).decode())
return {"stored": key}
@app.get("/kv/{key}")
async def kv_get(key: str, request: Request):
return {"key": key, "value": await request.scope["env"].KV.get(key)}
@app.get("/todos")
async def list_todos(request: Request):
db = request.scope["env"].DB
result = await db.prepare("SELECT id, title FROM todos ORDER BY id").all()
return {"todos": result.results}
@app.post("/todos")
async def add_todo(request: Request):
body = await request.json()
db = request.scope["env"].DB
await db.prepare("INSERT INTO todos (title) VALUES (?)").bind(body["title"]).run()
return {"ok": True}
Default = asgi.entrypoint(app)
D1 の .all() の results は、Python の list と dict としてそのまま JSON で返せました。GA でバインディングの型変換が自動になったためです1。
$ curl -s localhost:8787/
{"message":"Hello from FastAPI on Workers","python":"3.14.2 (main, Aug 25 2026, 05:50:55) [Clang 23.0.0git ..."}
$ curl -s -X PUT --data 'こんにちは KV' localhost:8787/kv/greeting
{"stored":"greeting"}
$ curl -s localhost:8787/kv/greeting
{"key":"greeting","value":"こんにちは KV"}
$ curl -s -X POST -H 'Content-Type: application/json' -d '{"title":"Python Workers を試す"}' localhost:8787/todos
{"ok":true}
$ curl -s localhost:8787/todos
{"todos":[{"id":1,"title":"Python Workers を試す"}]}
FastAPI の /docs(Swagger UI)と /openapi.json も 200 で返りました。Worker の中の Python は 3.14.2 です。
ネット上の記事には古い書き方が残っています。2026 年 10 月時点で正しいのは右の列です。
| 項目 | 古い書き方 | 現在の書き方 |
|---|
| ハンドラ | async def on_fetch(request, env) | class Default(WorkerEntrypoint) の fetch5 |
| FastAPI | import asgi → asgi.fetch(app, request.js_object, self.env) | from workers import asgi → Default = asgi.entrypoint(app)11 |
| バインディングへの dict | to_js({...}) で変換 | そのまま渡す1 |
| パッケージ | requirements.txt | pyproject.toml + uv add6 |
Python Workers は、デプロイ時にトップレベルのコードを一度実行し、その時点の WebAssembly のメモリを保存しておくことで起動を速くしています6。リクエストが来たら、import をやり直さずにスナップショットから復元します。Cloudflare によると、fastapi・httpx・pydantic を読み込む Worker は、スナップショットなしで約 10 秒、ありで約 1 秒で起動します6。
Cloudflare が 2025 年 12 月に公開したベンチマークでは、同じ 3 つのパッケージを読み込むアプリの平均コールドスタートは次のとおりでした6。
fastapi・httpx・pydantic を読み込むアプリの平均コールドスタート(秒)データを表で見る
fastapi・httpx・pydantic を読み込むアプリの平均コールドスタート(秒)| 環境 | 平均コールドスタート(秒) |
|---|
| Cloudflare Python Workers | 1.027 |
|---|
| AWS Lambda(SnapStart なし) | 2.502 |
|---|
| Google Cloud Run | 3.069 |
|---|
出典: Cloudflare Blog「Python Workers redux」(2025-12-08)のベンチマーク。Cloudflare 自身による計測で、AWS Lambda は SnapStart なしの値
この数字を読むときの注意が 2 つあります。
- Cloudflare 自身の計測で、Lambda は SnapStart(Lambda の起動スナップショット機能)を使っていない条件です
- 第三者からは異論も出ています。InfoQ の記事は、Wasmer の創業者が「Wasmer Edge は約 60ms、Cloudflare は約 900ms」と指摘したことを紹介しています12。これは競合企業の主張です
スナップショットには、次の制約があります6。
- トップレベルで乱数を使えない: スナップショットに乱数の種が残らないよう、デプロイ時の乱数の生成は禁止されています。乱数はハンドラの中で使います
- トップレベルで JavaScript のオブジェクトを抱え込まない:
globalThis からたどれない JavaScript のオブジェクトをトップレベルに保持すると、デプロイに失敗します
逆に言えば、重い import やモデルの読み込みはトップレベルに書くほど得です。その分はスナップショットに入り、リクエストのたびには実行されません。
pywrangler dev の出力に出る同梱サイズを、筆者の 2 つの Worker で比べました。FastAPI を入れると 424 モジュール、約 8.6 MiB になります。上限(圧縮前 64 MiB)にはまだ余裕があります13。
同梱モジュールのサイズ(KiB、pywrangler dev の出力)データを表で見る
同梱モジュールのサイズ(KiB、pywrangler dev の出力)| Worker | サイズ(KiB) |
|---|
| Hello World | 107.57 |
|---|
| FastAPI 版 | 8,840.77 |
|---|
出典: 筆者計測(2026-10-07、pywrangler 1.17.7・wrangler 4.148.0 の dev 出力の Total)
使えるパッケージは、純粋な Python のパッケージ、PyEmscripten 向けの wheel が PyPI にあるパッケージ、Pyodide に同梱されたパッケージの 3 種類です14。PyEmscripten は、WebAssembly 向けの Python パッケージの形式です。PEP 783 として 2026 年 4 月に承認されました15。
C 拡張を含むパッケージは、PyEmscripten 向けの wheel が無いと入りません。uv add は通っても、dev の sync で失敗することがあります。入れる前に、PyPI のファイル一覧に pyemscripten を含む wheel があるかを確かめると早いです。
標準ライブラリにも、動かないものがあります16。
| 状態 | モジュール |
|---|
| 使えない | curses、dbm、ensurepip、fcntl、grp、pwd、resource、syslog、termios、tkinter、venv など |
| import はできるが動かない | threading、multiprocessing |
| import できない | pty、tty |
ファイルシステムはメモリ上の一時領域だけで、isolate が消えると中身も消えます。ファイルを残したいときは R2 か D1 を使います。
料金と上限は、JavaScript の Workers と共通です。Python だけの料金はありません1317。2026 年 10 月時点の主な値は次のとおりです。
| 項目 | Free プラン | Paid プラン(月 5 ドルから) |
|---|
| リクエスト | 1 日 10 万回 | 月 1,000 万回込み。超過は 100 万回あたり 0.30 ドル17 |
| CPU 時間 | 1 回 10ms | 月 3,000 万 ms 込み。1 回の上限は既定 30 秒、最大 5 分1317 |
| メモリ | 1 isolate 128 MB(WebAssembly の分も含む)13 | 同じ |
| Worker のサイズ | 圧縮前 64 MiB13 | 同じ |
| 起動時の処理 | グローバルスコープの実行は 1 秒以内13 | 同じ |
Python で気をつけたいのは CPU 時間とメモリです。メモリの 128 MB には Pyodide 本体と読み込んだパッケージも含まれます。Free プランの 1 回 10ms の CPU 上限に収まるかは、自分のアプリを wrangler tail やダッシュボードの CPU 時間で確かめてから決めてください。
結論は、Python の資産(ライブラリ・既存コード・チームの得意言語)を活かしたい API なら Python Workers、起動の速さと軽さを最優先するなら JavaScript / TypeScript の Workers、重い計算や AWS のサービスと深くつながる処理なら Lambda です。
| 観点 | Python Workers | JavaScript / TypeScript の Workers | AWS Lambda(Python) |
|---|
| 実行環境 | V8 isolate の中の Pyodide(WebAssembly)2 | V8 isolate | Firecracker の microVM |
| 起動 | スナップショットで約 1 秒(FastAPI 等を読む場合)6 | isolate を作るだけ | SnapStart の有無で変わる |
| ネイティブ拡張 | PyEmscripten 向け wheel があるものだけ14 | なし(npm の純 JS / Wasm) | Linux 向け wheel がそのまま使える |
| スレッド | 使えない16 | 使えない | 使える |
| 料金の軸 | リクエスト+CPU 時間17 | 同じ | リクエスト+実行時間×メモリ |
1 つのアプリの中で混ぜる手もあります。2026 年 8 月から、Python と JavaScript の Worker はサービスバインディングの RPC で互いのメソッドを呼べます7。たとえば、画面と認証は TypeScript、データの集計や AI の前処理は Python、と分けられます。Workers と Lambda の上限や料金の詳しい比較は、Cloudflare Workers vs AWS Lambda:料金と上限にまとめています。
AI コーディングエージェントに Python Workers を書かせると、学習データにある古い書き方(on_fetch、to_js、requirements.txt)を出しがちです。最初に、現在の書き方をプロジェクトの指示ファイルに書いておくと外れにくくなります。
pywrangler init で --agents を付け、Cloudflare 向けの AGENTS.md を作る(Claude Code では CLAUDE.md から @AGENTS.md で読み込める)
- 次のような Python Workers 用のルールを足す
## Python Workers のルール
- ハンドラは `from workers import WorkerEntrypoint` の `class Default` に書く。`on_fetch` は使わない
- FastAPI は `from workers import asgi` と `Default = asgi.entrypoint(app)`。バインディングは `request.scope["env"]`
- バインディングには Python の dict / list をそのまま渡す。`to_js` は使わない
- 依存は `uv add`。`requirements.txt` は作らない
- トップレベルで乱数・threading を使わない。重い import はトップレベルに置く
- 動作確認は `uv run pywrangler dev` と curl。`deploy` は人が実行する
なお、筆者の環境では wrangler dev が「AI エージェントの中で動いている」ことを検出し、ローカルの KV・D1・ログを読むための API(/cdn-cgi/local/explorer/api)の案内を出しました。エージェントが自分でバインディングの中身やログを確かめられるので、デバッグの往復が減ります。Workers 全般を Claude Code で作る流れは Claude Code で Cloudflare Workers を作る全手順も参考にしてください。
| 症状 | 原因 | 対処 |
|---|
uv version at least 0.12.3 required | uv が古い | uv self update(Homebrew なら brew upgrade uv) |
uv add は通るのに dev でパッケージの導入に失敗 | C 拡張に PyEmscripten 向け wheel が無い | 純 Python の代替を探すか、Pyodide 同梱のパッケージを使う14 |
| デプロイで乱数のエラー | トップレベルで random などを使っている | 乱数はハンドラの中で使う6 |
手元の .venv と Worker でパッケージの版が違う | Worker 用は .venv-workers に別に入る | 版を合わせたいものは pyproject.toml で固定する |
| Python の版の表記がばらばら | 雛形の .python-version は 3.12、Worker の中は 3.14 | Worker の中の版は compatibility_date で決まる9。手元の版と分けて考える |
threading を使うライブラリが固まる | スレッドが動かない16 | 非同期(asyncio)版のライブラリに替える |
筆者の環境では、FastAPI を入れたとき、手元の .venv には pydantic 2.13.5、Worker には 2.12.5 が入りました。Worker 側は PyEmscripten 向けの wheel がある版に合わせて選ばれるためです。手元のテストだけで判断せず、pywrangler dev で動かして確かめてください。
- Cloudflare Workers の Python 対応は 2026 年 9 月 21 日に GA。料金と上限は JavaScript の Workers と同じ
- 始め方は
uv self update → uvx --from workers-py pywrangler init → uv run pywrangler dev → uv run pywrangler deploy
- FastAPI は
Default = asgi.entrypoint(app)、バインディングは request.scope["env"]。dict はそのまま渡せる
- 起動はメモリスナップショットで速くなる。重い import はトップレベル、乱数はハンドラの中
- C 拡張は PyEmscripten 向け wheel があるものだけ。
threading は使えない
次にやることとして、手元で pywrangler init を実行し、普段使っているパッケージを uv add して dev が通るかを確かめてみてください。通れば、そのまま Workers に載せられます。
2026 年 9 月 21 日に GA(一般提供)になりました。Cloudflare は Python を完全にサポートする言語と発表しています1。ただし、雛形を作る create-cloudflare は 2026 年 10 月 7 日時点でも「Python (beta)」と表示します。判断は公式ブログの発表を基準にしてください。
compatibility_date が 2026-09-08 以降なら Python 3.14 が既定です9。筆者が 2026 年 10 月に確かめた Worker の中の版は 3.14.2 でした。手元の Python の版とは別に、互換性日付で決まります。
動きます。FastAPI・Starlette は ASGI、Django・Flask は WSGI のつなぎ込みが用意されています811。FastAPI は from workers import asgi と Default = asgi.entrypoint(app) の 2 行で Worker になります。
Pyodide に同梱されているか、PyEmscripten 向けの wheel が PyPI にあるパッケージなら使えます14。C 拡張を含むパッケージは、その wheel が無いと入りません。使う前に uv add して pywrangler dev が通るかを確かめるのが確実です。
違いません。リクエスト数と CPU 時間で課金され、Free プランは 1 日 10 万リクエスト、Paid プランは月 5 ドルからです17。ただし Free プランは 1 回あたりの CPU 時間が 10ms までなので、パッケージを多く使うアプリは収まるかを確かめてください13。
Cloudflare の計測では、fastapi・httpx・pydantic を読み込むアプリの平均コールドスタートは Python Workers が 1.027 秒、SnapStart なしの Lambda が 2.502 秒でした6。これは Cloudflare 自身の計測で、SnapStart ありの Lambda とは比べていません。自分のアプリで測って判断してください。
-
Python Workers are now generally available — Cloudflare Blog, 2026-09-21(2026-10-07 参照) ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9
-
How Python Workers Work — Cloudflare Docs, 2026-07-09 更新(2026-10-07 参照) ↩ ↩2
-
Python Workers — Cloudflare Docs, 2026-09-17 更新(2026-10-07 参照) ↩ ↩2 ↩3
-
Bringing Python to Workers using Pyodide and WebAssembly — Cloudflare Blog, 2024-04-02(2026-10-07 参照) ↩ ↩2
-
Python Workers handlers now live in an entrypoint class — Cloudflare Changelog, 2025-08-14(2026-10-07 参照) ↩ ↩2 ↩3
-
Python Workers redux: fast cold starts, packages, and a uv-first workflow — Cloudflare Blog, 2025-12-08(2026-10-07 参照) ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11
-
Python and JavaScript Workers can now call each other via RPC — Cloudflare Changelog, 2026-08-03(2026-10-07 参照) ↩ ↩2
-
Python Workers now support WSGI web frameworks like Django and Flask — Cloudflare Changelog, 2026-09-02(2026-10-07 参照) ↩ ↩2
-
Python 3.14 for Python Workers — Cloudflare Changelog, 2026-09-08(2026-10-07 参照) ↩ ↩2 ↩3
-
Hyperdrive support for Python Workers — Cloudflare Changelog, 2026-09-16(2026-10-07 参照) ↩
-
FastAPI · Python Workers — Cloudflare Docs, 2026-08-28 更新(2026-10-07 参照) ↩ ↩2 ↩3
-
Python Workers Reach GA on Cloudflare, with Questions about Cold Starts and Upstream Maintenance — InfoQ, 2026-09-29(2026-10-07 参照) ↩
-
Limits · Cloudflare Workers — Cloudflare Docs, 2026-09-05 更新(2026-10-07 参照) ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7
-
Packages · Python Workers — Cloudflare Docs, 2026-09-18 更新(2026-10-07 参照) ↩ ↩2 ↩3 ↩4
-
PEP 783 – Emscripten Packaging — Python Software Foundation, 2026-04-06 承認(2026-10-07 参照) ↩
-
Standard Library · Python Workers — Cloudflare Docs, 2026-06-22 更新(2026-10-07 参照) ↩ ↩2 ↩3
-
Pricing · Cloudflare Workers — Cloudflare Docs, 2026-10-02 更新(2026-10-07 参照) ↩ ↩2 ↩3 ↩4 ↩5