Vercel Servicesで、PythonバックエンドはVPSからサーバーレスへ移るのか

はじめに

Vercelが2026年6月30日に発表したVercel Servicesは、かなり重要な転換点だと感じています。

一言でいうと、Vercelの1つのProjectの中で、Next.jsのフロントエンド、FastAPIのようなPythonバックエンド、GoやRustのサービスなどをまとめて扱えるようにする機能です。

これまで日本国内でPythonのAPIサーバーを動かそうとすると、現実的にはいくつかの選択肢に分かれていました。

VPSを借りて、Ubuntu、nginx、systemd、uvicorn、証明書更新、監視を自分で見る
AWS Lambda、Google Cloud Run、Azure Functionsなどの大手クラウドを使う
PaaSやコンテナ基盤を使い、フロントエンドとは別の運用面を持つ

もちろん、AWS LambdaやGoogle Cloud Runには、すでに日本リージョンでPythonを動かす選択肢があります。したがって、Vercel Servicesを「日本リージョンのPythonサーバーレスが初めて」と表現するのは正確ではありません。

ただし、Vercel Servicesが面白いのはそこではありません。

面白いのは、Vercelのプレビュー、デプロイ、ログ、ルーティング、内部通信の体験に、Pythonバックエンドが自然に乗ってくることです。

この記事では、Vercel Servicesの発表を、日本国内でPythonバックエンドを動かす実務の視点から整理します。

Vercel Servicesは何を変えるのか

Vercel Servicesは、複数のサービスを1つのVercel Projectとして構成するための仕組みです。

公式記事では、Next.jsフロントエンドとFastAPIバックエンドを例に、次の価値が説明されています。

フロントエンド、バックエンド、その他サービスを同時にデプロイ・ロールバックできる
Pull Request単位のPreview Deploymentで、複数サービスを含む変更を確認できる
サービス間通信をpublic internetへ出さず、Vercel内部ネットワークで扱える

これは、地味ですがかなり大きいです。

従来の構成では、フロントエンドはVercel、Python APIは別のVPSや別クラウド、ログも別、プレビューも別、環境変数も別、という形になりがちでした。

その場合、ユーザーから見ると1つのアプリでも、開発者から見ると2つ以上の運用面を持つことになります。

Vercel Servicesは、その分離を小さくします。

フロントエンドとバックエンドを同じProjectの中に置き、vercel.jsonのservicesで各サービスを宣言し、rewritesで公開ルートを制御します。バックエンドを外部公開せず、フロントエンドから内部binding経由で呼び出す構成も取れます。

つまり、Vercel上で「Webフロントだけ」ではなく、「Webアプリ全体」を扱う方向へ踏み込んだ発表です。

これはサーバーレスなのか

実務的には、はい。サーバーレスとして捉えてよいと思います。

ただし、昔ながらの「1リクエストごとに短命な関数が起動する」だけのイメージよりは、VercelのFluid Compute上で動くmanaged backendに近いです。

VPSのように、サーバーOSへSSHして、プロセスを常駐させ、nginxやsystemdを自分で守る形ではありません。Vercel側がビルド、デプロイ、ルーティング、自動スケールを担います。

一方で、何でもVPSの代わりになるわけではありません。

たとえば、次のような用途は引き続きVPS、EC2、ECS、Kubernetes、専用のコンテナ基盤の方が合うことがあります。

OSレベルで細かく制御したい
任意の常駐デーモンを長時間動かしたい
ローカルディスク永続化に依存している
特殊なネットワーク構成やミドルウェアを前提にしている
既存のクラウド構成と深く結合している

しかし、次のような用途なら、Vercel Servicesはかなり現実的です。

Next.jsやAstroのフロントエンドに付随するPython API
FastAPIで書いたAIバックエンド
社内業務アプリの軽量API
フロントエンドからだけ呼ばせたいinternal backend
Queue、Workflow、Cronと組み合わせる非同期処理の入口

このあたりは、VPSを立てるよりも運用負荷をかなり下げられる可能性があります。

日本リージョンでPythonを動かす選択肢として見る

日本国内向けのサービスでは、実行リージョンは無視できません。

ユーザーからのレイテンシだけでなく、データベース、外部API、セキュリティ要件、データ所在地の説明にも関わります。

Vercelの公式ドキュメントでは、compute-capable regionとしてTokyo hnd1 とOsaka kix1 が掲載されています。一方で、Vercel Functionsのデフォルト実行リージョンはWashington, D.C.の iad1 です。

つまり、日本向けにPythonバックエンドを置きたいなら、何もしないで「日本で動く」と考えるのではなく、ProjectやFunctionのregion設定を確認する必要があります。

これは記事としても重要なポイントです。

Vercel Servicesは、日本リージョンのPythonサーバーレスを新しく発明したわけではありません。

AWS LambdaはTokyo ap-northeast-1 で使えます。Google Cloud RunもTokyo asia-northeast1、Osaka asia-northeast2 を提供しています。Azure FunctionsもJapan EastやJapan Westで利用できる構成があります。

それでもVercel Servicesに価値があるのは、Vercelの開発者体験の中で、Pythonバックエンドを同じプロジェクトに入れられるからです。

これまでVercelを使っていたチームにとって、これはかなり意味があります。

VPSとの違いは、サーバーを持たないことより運用面が減ること

VPSは自由です。

好きなPythonバージョンを入れ、好きなプロセスマネージャを使い、好きなミドルウェアを立てられます。小規模なら月額も安く、使い慣れていれば速い。

ただし、自由には運用責任がついてきます。

OSアップデート
セキュリティパッチ
process restart
SSL証明書
reverse proxy
log rotation
disk監視
backup
障害時の切り分け

「とりあえずPython APIを1つ動かしたい」だけでも、これらの周辺作業が発生します。

Vercel Servicesが価値を出すのは、この周辺作業を減らせるところです。

特に、フロントエンドがすでにVercelにある場合、Python APIのためだけに別のVPSや別クラウドを持つと、開発と運用の境界が増えます。Preview環境、本番環境、環境変数、ログ、権限、デプロイ手順が分かれます。

Vercel Servicesでは、そこを同じProjectの中に戻せます。

これは「サーバーが見えないから楽」という単純な話ではありません。変更を確認し、戻し、観測する単位が揃うことが大きいです。

AIアプリではPythonバックエンドを持ちたくなる

AIアプリケーションを作っていると、Pythonを使いたい場面は多くあります。

モデル呼び出しだけならTypeScriptでも十分ですが、次のような処理ではPythonのエコシステムが強いです。

データ前処理
ドキュメント解析
embeddingや検索周辺の処理
評価スクリプト
notebook由来のロジックのAPI化
Python SDKしか整っていない外部サービス連携

これまでは、フロントエンドをVercelに置きながら、Python APIだけ別に立てる構成が自然でした。

しかし、別に立てると運用面が増えます。

Vercel Servicesがうまく機能すれば、Next.jsやAstroのフロントエンド、Python/FastAPIのAI API、必要に応じたQueueやWorkflowを、1つのVercel Projectとして扱いやすくなります。

これは、AIプロダクトを小さく作って速く検証するチームにとって価値があります。

特に、日本国内向けの業務アプリやAI伴走サービスでは、最初から重いクラウド構成を組むより、フロントエンドとバックエンドを同じ開発体験に乗せて、必要になったところだけ分離する方が現実的な場面があります。

どの構成を選ぶべきか

Vercel Servicesが出たからといって、すべてをVercelへ寄せるべきだとは思いません。

構成選定では、次のように考えるのがよいと思います。

Vercel Servicesが合うケース

フロントエンドがVercel中心
Python APIをFastAPIなどで小さく始めたい
PRごとにフロントエンドとバックエンドをまとめてpreviewしたい
バックエンドをpublic internetへ直接出したくない
VPS運用の細かい面倒を増やしたくない
AIアプリのプロトタイプから初期本番までを速く回したい

AWSやGoogle Cloudが合うケース

すでにAWS/GCP上にデータベース、認証、ネットワーク、監視が集約されている
Lambda、Cloud Run、ECS、Step Functions、Pub/Subなどの既存資産がある
IAM、VPC、PrivateLink、Cloud SQL、BigQueryなどと深く連携する
インフラチームがクラウド標準構成を持っている

VPSや専用サーバーが合うケース

とにかく低額で常時稼働サーバーを1台持ちたい
OSやミドルウェアを細かく制御したい
既存の運用がVPS前提で安定している
サーバーレスの制約より、自分で面倒を見る自由度を優先したい

Vercel Servicesは、AWSやGCPを置き換えるというより、Vercelを中心に開発しているチームが、Pythonバックエンドのためだけに運用面を増やさなくてよくなる選択肢として見るのが自然です。

日本の中小チームにとっての意味

日本の中小チームや事業会社では、フルタイムのインフラ専任者がいないまま、Webアプリ、AI機能、管理画面、業務APIを作ることがよくあります。

このとき、VPSは手軽ですが、積み重なると属人化しやすい。

AWSやGCPは強力ですが、小さなチームには設定面や権限設計が重く感じることがあります。

Vercel Servicesは、その間に入る可能性があります。

フロントエンドの変更とバックエンドの変更を同じPull Requestで確認し、同じPreview Deploymentで動作を見て、同じProjectのログで切り分ける。必要ならPython APIを内部サービスにして、外部公開面をフロントエンドに絞る。

これは、AI時代の小さなプロダクト開発にはかなり相性がよいです。

AI機能は、試作から本番までの距離が短いほど価値が出ます。一方で、APIキー、外部サービス、ユーザーデータ、非同期処理など、雑に扱うと危険な要素も多い。

だからこそ、デプロイとpreviewの体験を保ちながら、バックエンドを同じプロジェクトに閉じ込められる選択肢は重要です。

まとめ

Vercel Servicesは、単なる新しいデプロイ設定ではありません。

Vercelを「フロントエンドを置く場所」から、「複数サービスをまとめて動かすフルスタック基盤」へ広げる発表です。

日本国内でPythonを動かすサーバーレス環境は、AWS Lambda、Google Cloud Run、Azure Functionsなどですでに存在していました。したがって、Vercel Servicesを「初めての選択肢」と言うのは正確ではありません。

しかし、Vercelのプレビュー、デプロイ、ルーティング、内部通信、ログの体験の中で、Python/FastAPIバックエンドを同じProjectに置けることには大きな意味があります。

特に、Vercel中心でWebアプリを作っているチーム、AIアプリでPython APIを持ちたいチーム、VPS運用を増やしたくないチームにとって、Vercel Servicesは有力な選択肢になります。

サーバーを持つか、クラウドを組むか、Vercelに寄せるか。

その判断は、単に「どこでPythonが動くか」ではなく、変更をどの単位でpreviewし、deployし、rollbackし、観測できるかで考える時代になってきたと思います。