chot Inc.（ちょっと株式会社）

VercelのPythonサポートが提供開始。FastAPI・Flask・Djangoを載せる前に確認する制約と判断基準

開発

2026年10月15日、Vercel は Python サポートの一般提供（GA）を発表しました。FastAPI・Flask・Django・FastHTML などのフレームワークが自動検出され、CPython 上でゼロコンフィグに近い形で Vercel Functions として動きます。ただし「既存の Python アプリがそのまま全部載る」わけではありません。実行時間の上限、インスタンスをまたぐ状態共有、常駐ワーカーの扱いという3点が、採否を分ける判断軸になります。

GAで何が確定したのか

Vercel の発表によると、プロジェクトの依存ファイル（uv 管理のものを含む）を読み取り、FastAPI、Flask、Django、FastHTML などのフレームワークを自動検出してビルドとルーティングを構成します。ランタイムは Linux 上の標準 CPython で、PyPI の既存パッケージとの互換性を保つ設計です。アプリケーションは Fluid compute 上で動き、同時リクエストを1インスタンス内で処理しながらトラフィックに応じてスケールします。

あわせて、ストレージ（Blob）、キュー（Queues）、永続ワークフロー（Workflows）、隔離実行環境（Sandbox）、AI SDK for Python、外部API資格情報を扱う Connect の Python SDK が揃いました。型アノテーションや async/await、コンテキストマネージャーといった Python の作法に沿ったAPIである点が、Vercel 自身が掲げた設計目標です。フロントエンドと Python バックエンドを1プロジェクトにまとめる Vercel Services、長時間稼働する常駐ワーカー向けの Vercel Daemons（パブリックベータ）も同日に案内されています。Vercel は、すでに15万チームが Python バックエンドを同社上で動かしていると述べています。

「GA」という表現が意味するのは、Python が実験的扱いではなく、サポート対象の本番ワークロードになったということです。裏を返せば、プラットフォームの制約もそのまま本番要件として受け止める必要があります。

設計に効く制約を数字で押さえる

判断材料になるのは主に次の4点です。いずれも Vercel の公式ドキュメントに記載された値です。

  • 最大実行時間：Fluid compute 有効時、Hobby はデフォルト・上限とも300秒。Pro / Enterprise はデフォルト300秒、上限800秒で、1800秒（30分）の拡張上限はベータ扱いです。拡張値は関数単位の設定が必要で、対応ランタイムに限られます。
  • メモリ：Hobby は 2GB / 1 vCPU、Pro・Enterprise は最大 4GB / 2 vCPU。
  • 関数サイズ：非圧縮で250MB、Python は500MB。重い機械学習ライブラリを同梱する構成では事前に見積もりが要ります。
  • Python バージョン：3.12（デフォルト）、3.13、3.14 が選択可能で、pyproject.toml の requires-python、.python-version、Pipfile.lock のいずれかで指定します。

WebSocket については、Vercel Functions のネイティブ対応が2026年6月22日にパブリックベータとなり、Python は同年7月23日に追随しました。FastAPI の @app.websocket()、Django Channels、Flask の flask-sock が Vercel 固有のAPIなしで使えます。ただし接続は1つの関数インスタンスにピン留めされ、関数の最大実行時間に達すると切断されます。クライアント側の再接続処理は前提です。インスタンスをまたぐ共有状態は Redis などの外部ストアに置く必要がある、という点も公式ドキュメントが明示しています。

向いている構成と、設計変更が必要な構成

上の制約を踏まえると、適性は次のように整理できます。

素直に載る構成は、リクエスト単位で完結する FastAPI / Flask の API、外部DBやSaaSを呼ぶ薄いバックエンド、ストリーミング応答を返すLLMアプリ、そしてフロントエンドと同一プロジェクトで運用したい小〜中規模のフルスタックです。Fluid compute のアクティブCPU課金は、外部API待ちの時間に課金しないモデルのため、LLM推論のように待ち時間が支配的なワークロードと相性が良いと言えます。

設計変更が必要な構成は、Celery のような常駐ワーカー前提のジョブ処理、数十分以上かかるバッチ、ffmpeg など OS レベルの依存を持つ処理、多数のクライアントへファンアウトするリアルタイム機能です。これらは「Vercel では動かない」のではなく、置き場所が変わります。常駐ワーカーは Daemons（パブリックベータ）、システム依存はコンテナランタイム、ジョブの受け渡しは Queues、長時間処理のリトライと状態保持は Workflows、という分担です。Vercel 自身も、Dockerfile に ffmpeg を同梱した動画処理ワーカーを Daemons と Queues で動かす例を示しています。ファンアウトや presence は依然として外部の仕組みが必要です。

つまり判断のポイントは「Python が動くか」ではなく、自分のアプリの非同期処理と常駐処理を、Functions・Daemons・Queues・Workflows に切り分けられるかです。切り分けが素直にできるなら移行コストは小さく、モノリス内でワーカーとスケジューラが密結合しているなら、まず分離の設計から着手することになります。

検証を始めるときの順序

いきなり本番移行を試すより、次の順で確認すると判断が早くなります。

  1. 依存とバージョンを固定する。pyproject.toml と requirements.txt が二重に存在する状態は避け、Python バージョンを .python-version などで明示します。デフォルトは 3.12 ですが、固定しておけば将来の既定値変更に影響されません。
  2. エントリポイントを合わせる。Vercel は app.py / index.py / server.py / main.py / wsgi.py / asgi.py（src/・app/ 配下も対象）を探すか、pyproject.toml の tool.vercel.entrypoint の指定に従います。
  3. 最長処理の実測値を取る。プランの上限（Hobby 300秒、Pro 800秒）に収まるかを、最悪ケースのリクエストで測ります。収まらない処理は、この時点でキューやワークフローへ切り出す候補になります。
  4. 関数サイズを確認する。ML系ライブラリを含む場合は500MB制限に対する余裕を見ます。
  5. ワーカーと定期実行の移行先を決める。Vercel のナレッジベースには Heroku・Render・Railway から FastAPI / Flask / Django の API を移行するガイドがあり、設定・データ・ワーカー・スケジュールジョブの移行手順が整理されています。

Daemons と WebSocket、30分の拡張実行時間はいずれもベータ段階です。本番の中核に据える前に、挙動とAPIが変わりうる前提で小さく試すのが安全です。

まとめ

Python on Vercel の GA は、フロントエンドと同じワークフローで Python バックエンドを運用できる選択肢が、正式に増えたということです。採否は、実行時間・状態・常駐処理の3点を自分のアプリに当てはめて判断してください。まずは最長処理の実測と、ワーカーの切り分け可否の確認から始めるのが近道です。

既存の Python バックエンドをフロントエンドと同じ基盤に載せ替えるべきか、どこまでを Functions に残しどこから別の実行モデルに分けるか迷う場合は、お問い合わせから chot Inc. にご相談ください。Web サイト制作・フロントエンド開発・AI アプリケーション開発の立場から、構成の検討をお手伝いします。

出典

この記事をシェア

最新の記事

開発

Vercel Ship 26 サンフランシスコ（2026年10月15日）発表まとめ — Python GA・コンテナ・Daemons・Drives・BYOC

サイト制作

手書きの手紙やDMに効果はあるのか　実験データから分かる「効く条件」

開発

JavaScriptフレームワークの歴史と2026年の現在地 — 仮想DOMからシグナルまでの4つの転換点

コラム一覧