Cloudflare Workers PythonでDjangoとFastAPIを比較：選び方と移行の注意点

Cloudflare Workers PythonでDjangoとFastAPIを選ぶなら？

既存のDjangoアプリがある場合や、製品バックエンドを一式必要とする場合はDjangoが適しています。型を活用したAPI、Webhookサービス、I/O負荷の高いエッジエンドポイントを新規開発するならFastAPIです。 必須パッケージ、プロセスモデル、ステートフルなワークロードのいずれかがWorkersランタイムに収まらない場合は、どちらも現在のオリジンサーバーに残すべきです。

Cloudflareは2026年9月2日、この比較の前提を変えました。Python Workersでは、workersモジュールのアダプターを介してWSGIおよびASGIアプリケーションを直接実行できるようになりました。WSGIは従来型の同期Python Webインターフェースです。後継のASGIは非同期処理を前提とし、I/Oの並行処理、ストリーミング、長時間接続に対応します。Cloudflareのリリース例ではDjangoをWSGI、FastAPIをASGIと明示的に組み合わせていますが、Djangoはどちらのプロトコルも利用できます。

統合された製品機能がすでに事業価値を生んでいるなら、移行先として安全なのはDjangoです。Cloudflareは現在、WSGIとASGIの両エントリーポイントに加え、D1とDurable Objectsを使うdjango-cfの構成も案内しています。

管理画面を備えたWeb製品ではなくAPIを新規開発するなら、FastAPIのほうがすっきりした選択です。ASGIサーバー層はCloudflareが提供するため、Worker側でUvicornを起動したりソケットを管理したりする必要はありません。

CPU時間に差が出るまでは料金も互角

フレームワーク料金による優劣はありません。 料金は2026年9月5日に公開中の一次情報で確認しています。Djangoは無料のオープンソースでBSDライセンス、FastAPIはMITライセンスです。Workers Paidは1アカウント月額$5から利用できます。

この$5には、月間1,000万件のリクエストと3,000万CPUミリ秒が含まれます。超過分は、100万リクエストごとに$0.30、100万CPUミリ秒ごとに$0.02です。Static Assetsへのリクエストは無料で、上限もありません。Workers Freeには1日10万件のリクエストが含まれますが、1回の呼び出しあたりCPU時間が10 msに制限されるため、実用的なフレームワークアプリを比較する基準には向きません。

両フレームワークを同じワークロードにそろえると、結果は当然ながら同じです。月間1,500万件の動的リクエストを平均CPU時間7 msで処理する場合、どちらも月額$8になります。内訳は基本料金$5、リクエスト超過分$1.50、CPU超過分$1.50です。平均CPU時間が同じ7 msなら、月間1億件でも両者とも月額$45.40です。

架空のフレームワークベンチマークより、差分が料金に与える影響を計算するほうが有用です。両アプリが無料枠のCPU時間を使い切った後は、平均CPU時間が1 ms違うごとに、月間1,500万件で$0.30、1億件で$2の差が生じます。したがって、実測差が5 msなら、それぞれ月額$1.50または$10です。この程度の差だけを理由にフレームワークを書き直す合理性はありません。

ベンダー料金だけで損得が逆転するポイントはありません。実測CPU時間、周辺サービス、保守負担のいずれかに差がついたときに初めて、一方が安くなります。データベース呼び出しが遅ければ、どれほど高速なフレームワークを選んでもアーキテクチャは救えません。反対に、統合型フレームワークによって置き換え作業を何週間も省けるなら、マイクロベンチマークでは劣っていても、システム全体では安くなる可能性があります。

移行方法を比較：既存システムはDjango、新規APIはFastAPI

アダプターの変更はわずかでも、アプリケーション移行は小さな作業ではありません。 どちらのフレームワークも薄いエントリーポイントを追加するだけで起動できますが、その背後にあるすべての要素をCloudflareのパッケージ、ストレージ、ファイルシステム、ライフサイクルのモデルに適合させる必要があります。

DjangoをCloudflare Workersへ移行：アダプターは簡単

Djangoは標準のWSGIアプリケーションオブジェクトを維持したまま、Cloudflareのアダプターへ渡せます。

import os

from django.core.wsgi import get_wsgi_application
from workers import wsgi

os.environ.setdefault("DJANGO_SETTINGS_MODULE", "app.settings")
app = get_wsgi_application()
Default = wsgi.entrypoint(app)

これだけで、Workersに届いたリクエストをDjangoのWSGI callableへ橋渡しできます。ただし、データベース、永続ファイル、定期ジョブ、セッション戦略、あらゆるサードパーティ製Djangoパッケージまで移行できるわけではありません。

Cloudflareの新しいDjangoパッケージガイドには、Cloudflareネイティブのストレージ構成が具体的に示されています。django-cfパッケージは、D1とDurable Objects向けのSQLite互換バックエンドを提供します。どちらもDjangoの同期ORMを動かすため、Cloudflareはこの構成をWSGIで提供するよう案内しています。モデル、フォーム、認証、管理画面に依存するCRUD製品なら、これらのレイヤーを温存することで、フレームワーク変更によるランタイムコスト削減をはるかに上回る作業量を省けます。

一方、既存システムが従来型サーバーを前提としていると移行の壁に突き当たります。データベースドライバーがWorkersでは読み込めないネイティブwheelを必要とするかもしれません。ユーザーのアップロードデータはisolateのファイルシステムに置けません。プロセスローカルなスケジューラーやスレッドプールも移せません。Django対応とは、リクエストプロトコルが動くという意味であって、導入済みアプリケーション全体の動作保証ではありません。

FastAPIをCloudflare Workersへ移行：小さなサービスに最適

FastAPIはもともとASGIに対応しているため、直接接続するアダプターはさらに簡潔です。

from fastapi import FastAPI
from workers import asgi

app = FastAPI()
Default = asgi.entrypoint(app)

通常はUvicornが担うASGIサーバーの役割をCloudflareが提供します。FastAPIのルート宣言、Pydanticによるバリデーション、依存性注入、自動生成されるOpenAPIドキュメントはそのまま使えます。そのため、新規のWebhook受信処理、型付きJSON API、バインディングを使うサービスは、Djangoより少ない仕組みで始められます。

その代わり、自分で組み立てる部分が増えます。FastAPIはデータベースもデータモデルも規定せず、Djangoのようなコンテンツ管理画面も備えていません。必要な要素を選び、それぞれのパッケージがWorkers環境で動くか確認し、統合作業まで引き受けることになります。目的を絞ったサービスには利点ですが、運用担当者が初日からバックオフィスを必要とする製品では負担です。

移行面の勝者： 既存のDjangoアプリケーションならDjango、新規APIならFastAPIです。どちらもエッジで動くようになったという理由だけで、稼働中のDjangoシステムをFastAPIへ書き直すのは、取り組むべきプロジェクトではありません。

CloudflareのWSGIとASGIを比較：並行処理はFastAPI、Djangoは選択可能

新規のI/O負荷が高いサービスにはASGIが有利ですが、DjangoのCloudflare ORM連携で公式に案内されているのはWSGIです。 「非同期なら常に高速」という一般論ではなく、ワークロードに合わせてプロトコルを選びます。

WSGIはアプリケーションを同期callableとして扱います。Cloudflareの現行WSGIアダプターは、そのcallableをWorkerの非同期fetchハンドラー内で実行し、JavaScriptのReadableStreamからリクエスト本文を橋渡ししたうえで、アプリケーションのレスポンスiterableをクライアントへストリーミングします。これは成熟した同期アプリケーションを動かす互換レイヤーであり、isolate内で別のWebサーバーを起動する仕組みではありません。

ASGIでは、同期呼び出しでリクエスト処理を占有せずに、ネットワークやストレージの処理完了を待てます。CloudflareのアダプターはASGIのWebSocketイベントもWorkers WebSocketsへ対応付けます。FastAPIはこのモデルを前提に設計されています。Djangoでも利用できるため、「Django」と「WSGI」は同義ではありません。

ただし、ストレージの選択によってプロトコルの結論が逆転することがあります。Cloudflareによると、Django用のD1バックエンドとDurable Objectsバックエンドはいずれも同期ORMを動かすため、WSGIで提供すべきです。Djangoを選ぶ理由がORMにあるなら、同期データ層へ無理にASGIという看板を付けるより、公式のWSGI構成に従うほうが一貫しています。

FastAPIでも、処理を並行して待てる場合に限ってasyncの効果があります。大半の時間を逐次的なバリデーションやCPU負荷の高いPython処理に使うエンドポイントは、やはりCPU時間を消費します。独立した複数のHTTP処理やCloudflareバインディングの完了を待つエンドポイントなら、ASGIを選ぶ理由が明確です。

起動処理を比較：FastAPIのlifespanに潜む注意点

現時点のWorkersでは、WSGI上のDjangoのほうが起動モデルを予測しやすいといえます。 FastAPIも動作しますが、lifespanフックは長時間稼働するUvicornプロセスと同じ挙動にはなりません。

Cloudflareはデプロイ時のスナップショットによって、Pythonのコールドスタート処理を減らします。デプロイ時にV8 isolateを作成し、Pyodideを注入してWorkerのエントリーモジュールとトップレベルimportを実行した後、WebAssemblyメモリをスナップショット化します。リクエスト時はPython環境をゼロから構築せず、そのスナップショットを読み込めます。それでもグローバルスコープのコードは、プラットフォームの1秒の起動上限内に解析・実行を終えなければなりません。Cloudflareはこのライフサイクルを明記しています。

通常のFastAPIのlifespanは、プロセスの生存期間を前提としています。アプリケーションがリクエストを受け付ける前に起動処理を1回実行し、終了後にシャットダウン処理を1回実行する契約です。しかし、現行Cloudflare ASGIアダプターのソースは大きく異なります。fetch関数がASGIアプリケーションを起動してlifespanのstartupイベントを送り、1件のリクエストを処理した後にshutdownを送ります。ソース内のコメントにも、リクエストの前後でstartupとshutdownのサイクルを1回ずつ実行すると説明されています。

つまり、現行アダプターではlifespanのコードがリクエスト単位で動きます。そこにモデルの読み込み、コネクションプールの構築、スキーマのウォームアップ、リモート設定の取得を置くと、isolate全体で償却されず、繰り返し実行される可能性があります。これはFastAPIを退ける理由ではありません。lifespanの処理を軽量かつ冪等にし、安全で決定論的な初期化処理はCloudflareのデプロイスナップショットを活用できる場所へ移すべき理由です。

Cloudflareの例ではDjangoのWSGIアプリケーションをモジュールスコープで生成し、ASGI lifespanのサイクルを使いません。そのため初期化はグローバルな起動処理の一部となり、1秒の上限が制約になります。DjangoのASGIエントリーポイントを選び、lifespan対応コンポーネントを使う場合は、同じアダプター挙動を前提に監査してください。

Python Workersでは両フレームワークが同じパッケージ制約を受ける

この項目も引き分けであり、条件によっては両方とも候補から外れます。 DjangoとFastAPIはいずれもV8内の同じPyodide環境で動くため、パッケージ、メモリ、ファイルシステム、起動時の制限を回避できません。

Cloudflareのパッケージドキュメントによると、pywranglerはpyproject.tomlで宣言された依存関係をバンドルします。対応する配布元には、PyPI上のpure PythonパッケージとPyEmscriptenパッケージ、さらにPyodide同梱パッケージが含まれます。PyEmscriptenはWebAssembly向けのwheel形式です。Cloudflare自身も、このエコシステムはまだ初期段階にあり、互換wheelが存在しないパッケージもあると説明しています。

確認すべきプラットフォームの上限は明確です。

• 展開後のWorkerバンドルは、FreeでもPaidでも64 MiBを超えられません。
• 各isolateのメモリは128 MBです。
• グローバルスコープの起動処理は1秒以内に完了する必要があります。
• Pythonのファイルシステムは一時的で、isolateごとに分離されています。
• threadingとmultiprocessingはimportできますが、WebAssembly VM内では機能しません。

ファイルシステムの制約は、アダプターのシグネチャから想像する以上に多くの移行を阻みます。一時ファイルは使えますが、永続的なアップロード、生成レポート、永続状態として扱うSQLiteファイル、共有ディスクキャッシュは置けません。永続オブジェクトはアクセスパターンに応じてD1、Durable Objects、KV、R2へ保存し、isolateとともに消えるディレクトリへ置かないでください。正確な境界はCloudflareのPython標準ライブラリガイドに記載されています。

性能を論じる前に、パッケージ互換性の可否は決まります。hello world用の一部ではなく、本番で使う依存関係グラフ全体をビルドしてください。デスクトップ版CPythonでimportできても、ネイティブ拡張がPyodideで利用できる証明にはなりません。

運用適性を比較：製品ならDjango、サービスならFastAPI

作る単位が「製品」ならDjango、「サービス」ならFastAPIが有利です。 この違いは、人工的なルートで測ったフレームワークのスループットより長く判断材料として使えます。

管理画面を備えた製品の勝者：Django

Djangoにはユーザー認証、コンテンツ管理、ORM、テンプレート、ミドルウェアなど、Web製品で一般的に使う機能がまとまっています。公式概要でも認証とコンテンツ管理が明記されています。少人数の運用チームが顧客、注文、権限、編集データを管理するなら、フレームワークのオーバーヘッドを数ミリ秒削るより、組み込み管理画面のほうが大きな価値を生みます。

Workersでは、django-cfを介して、この統合モデルをD1またはDurable Objectsへ接続できます。その代わり、同期ORMとの結び付きが強くなり、より大きなフレームワーク全体をランタイム制限内に収める必要があります。

型付きAPIサービスの勝者：FastAPI

FastAPIはOpenAPI、JSON Schema、Pydanticによるバリデーション、依存性注入を中心に設計されています。機能ドキュメントにも、そのトレードオフが明示されています。データベースとデータモデルは自由に選びます。APIゲートウェイ、Webhook受信処理、モデルのエンドポイント、バインディングや外部APIと通信する小規模サービスに適した構成です。

統合型の管理画面とORMがないことは、サービスに不要なら欠点ではありません。技術者ではない運用担当者がバックオフィスを必要とした瞬間、それらを用意するための開発コストになります。

素の速度の勝者：Workersでは未証明

FastAPIのベンチマークページによると、TechEmpowerの独立ベンチマークでは、Uvicorn上のFastAPIが歴史的に最速クラスのPythonフレームワークとされてきました。TechEmpowerは標準化されたJSON、データベース、ORM、テンプレートなどのワークロードを測定していました。しかしCloudflareのPyodideアダプターは対象外であり、同プロジェクトは2026年3月24日に終了しました。この結果は出典付きの過去の参考情報であって、Workersへデプロイした際の予測値ではありません。

Cloudflareは、これらのアダプターを介したDjangoとFastAPIの比較ベンチマークを公開していません。そのためWorkers上の実速度は、バリデーション、バインディング、データベース呼び出し、レスポンス形式、起動挙動、WorkersのCPUメトリクスまで含む代表的なルートで測るまで分かりません。

実際の切り替えコストと、移行すべきでないケース

Cloudflare対応だけを理由にフレームワークを変えてはいけません。いまは両方とも対応しています。 移行によって増える作業より、移行先のフレームワークが減らせる作業のほうが多い場合に限って切り替えます。

DjangoからFastAPIへの書き直しでは、モデル、マイグレーション、管理画面、認証フロー、ミドルウェア、テンプレート、Djangoのリクエストライフサイクルを前提とする各種パッケージを置き換えるか、分離する必要があります。用途を絞ったAPIなら優れた成果を得られますが、単なるデプロイ設定の変更ではありません。管理画面とORMを多用している場合は、新たな利点を得る前に既存の強みを失います。

FastAPIからDjangoへ移る意味があるのは、製品がサービス型アーキテクチャの規模を超え、Djangoの統合型運用機能が必要になった場合だけです。それ以外では、小さなAPIに不要な規約やコンポーネントを追加することになります。

FastAPIはa2wsgi.WSGIMiddlewareを介して、DjangoのWSGIアプリケーションをパス配下へマウントできます。従来型サーバーなら段階的な分割に役立ちます。Workersではパッケージとプロトコル境界が1つずつ増える一方、Cloudflareのスターター構成は各フレームワークを個別に案内しています。統合Workerは、標準的な近道ではなく、検証が必要なカスタム統合として扱ってください。

どちらの方向へ移行する場合も、次の範囲をコストに含めます。

• データ： スキーマ互換性、マイグレーション、トランザクションの挙動、D1、Durable Objects、または接続可能な別ストアへの移行。
• ファイル： 静的アセットにはWorkers Static Assetsを使えますが、永続的なユーザーメディアにはR2などの永続オブジェクトストレージが必要です。
• バックグラウンド処理： プロセスローカルなスケジューラー、スレッドプール、子プロセスを、プラットフォームネイティブの非同期処理へ置き換えます。
• 依存関係： 完全なlockfileをPython Workers上で解決し、64 MiBのバンドル上限と1秒の起動結果を確認します。
• 運用： ログ、エラー通知、デプロイのロールバック、シークレット、ルート単位の性能ベースラインを再構築します。

移行すべきでないのはどのようなケースでしょうか。安定稼働中のDjangoモノリスに実用的なデータベースと充実した管理画面のワークフローがあるなら、流行を理由にFastAPIへ変えるべきではありません。利用できないネイティブwheelに依存するFastAPIサービスも、ドキュメントに対応ページができたというだけでWorkersへ移すべきではありません。レイテンシの大半が遠隔地のデータベースに起因するなら、リクエストフレームワークを変える前にデータ配置を修正すべきです。

来週月曜日にやるべきこと

来週検証するのはアプリケーション全体ではなく、代表的なルート1本です。 本番システムのパッケージ、状態、レイテンシの特性が現れるルートを選び、不適切な選択肢を短時間で除外します。

Cloudflare WorkersのDjangoとFastAPIに関するFAQ