先に要点
- Vercel の Edge Function は世界中の Edge ロケーションで動く軽量ランタイム、Serverless Function は AWS Lambda 系の従来型サーバレスで、速度・制約・料金軸がそれぞれ別物 です。
- Edge は 低レイテンシ・コールドスタートほぼなし ですが、Node.js の標準モジュール(`fs`, `child_process` 等)が使えない / 実行時間とメモリの上限が厳しい。
- Serverless は Node.js フル機能 + 任意の npm パッケージ可。代わりに 初回のコールドスタートが発生、起動場所はリージョン固定。
- 使い分けの目安は ` ユーザーの近くで素早く返したい認証・ロケーション判定・軽い書き換え系 → Edge`、`重い処理 / 通常の DB 接続 / Node.js API を多用する処理 → Serverless`。
Vercel で API ルートを書くとき、Edge と Serverless どっちを選べばいいの？ Edge Runtime に変えたら DB 接続でエラーになった コールドスタートが気になるけど、Edge にすれば全部解決？ ── Vercel の基礎用語 に少し触れた人ほど、このあたりで詰まりがちです。
Vercel の Function は表面的には どちらも関数を1個書くだけ ですが、裏で動いているランタイムも、実行場所も、料金構造も別物 です。
適当に Edge を選ぶと、Node.js の API が使えなくて動かない DB 接続でハマる 料金が想定外に上がる といった事故が起きやすいので、最初に両者の違いを整理しておくと運用が楽になります。
この記事では、2026年5月時点の Edge Function と Serverless Function の違い、どんな処理をどちらに置くべきか の判断軸、典型的なハマりどころと回避策をまとめます。
まずざっくり比較
最初に全体像をつかんでおきます。
| 軸 | Edge Function | Serverless Function |
|---|---|---|
| 実行場所 | 世界中の Edge ロケーション(ユーザー近傍) | 指定したリージョン(例: iad1 / hnd1) |
| ランタイム | Edge Runtime(V8 isolates ベース、Web 標準 API 中心) | Node.js(完全な Node 環境) |
| コールドスタート | ほぼなし(常時温まっている) | あり(初回 100〜数百 ms) |
| 使える npm | Web 標準 API ベースのものに限定 | ほぼ全部使える |
| Node.js API | `fs` `path` `child_process` 等は使えない | すべて使える |
| 実行時間上限 | 短め(プランによる) | 長め(Pro で数十秒〜分単位の設定可) |
| 料金単位 | 呼び出し数 + ミリ秒単位の実行時間 | GB-hour(メモリ × 実行時間) |
| 典型用途 | 認証チェック、ルーティング、A/B、地理判定、軽い API | DB 操作、画像処理、PDF 生成、外部 API 連携 |
要点は ユーザーの近くで動くがランタイム制約が厳しい Edge vs 決まったリージョンで動くが Node.js を自由に使える Serverless という分け方です。
どちらが新しい / どちらが優れている ではなく、用途で使い分ける道具立て と捉えるのが正しい付き合い方になります。
Edge Function の中身
Edge Function は、世界中に分散配置された Edge ロケーション(CDN ノードに近い小さな実行環境) で動きます。 中身は V8 isolates という Chrome / Node.js の中で使われている JavaScript エンジンを軽量に切り出した仕組みで、Cloudflare Workers と同じ系譜のアーキテクチャです。
向いていないこと
`fs.readFile` でローカルファイルを読む、`child_process` で外部コマンドを叩く、巨大な npm パッケージを使う処理。`Node.js でしかできない` ことは全般に不向き。
速いと言われる理由
① ユーザーから物理的に近い、② コールドスタートが事実上ない、の2点。重い処理に向くわけではなく、`軽い処理が世界中で速い` という強みです。
Next.js では export const runtime = 'edge' を Route Handler / API Route の先頭に書くだけで Edge ランタイムに切り替わります(App Router の場合)。
ミドルウェア(middleware.ts)は 標準で Edge ランタイムで動きます。
Serverless Function の中身
Serverless Function は、いわゆる従来型の AWS Lambda 系のサーバレス で、Vercel が裏で AWS インフラを使って提供しています。
コールドスタートの実態
関数を一定時間呼び出さないとインスタンスが破棄され、次回に 100ms〜数百ms の起動時間 がかかる。ホット状態なら数 ms。`常に使われる API` ほど体感の影響は小さい。
Next.js の API Route は、特に runtime 指定をしなければデフォルトで Serverless Function として動きます。
普通の Node.js のコード を意識せずに書けるのが強みで、既存の Node.js 資産をそのまま持ち込みやすい運用感です。
どんな処理をどちらで動かすか
実務的な判断軸を、ユースケース別に整理します。
① 認証ミドルウェア・ルーティング
Edge が圧倒的に向く。
ユーザーのリクエストごとに毎回走るので、どこで動くか のレイテンシ差がそのままユーザー体感速度に影響します。
Cookie のチェック、ログインしていないユーザーのリダイレクト、A/B 振り分け、地理ベースの言語切り替えなどは Edge の典型タスクです。
② DB 操作のある API
多くの場合 Serverless の方が安全。
理由はシンプルで、多くの RDB ドライバや ORM が Node.js ネイティブモジュールに依存 していて、Edge では動かないからです。
Prisma も Edge 対応版がありますが、対応 DB / 設定の制約があります。Vercel Postgres / Supabase / Neon のような HTTP / WebSocket ベースの DB であれば Edge から扱えますが、いったんは Serverless で書き始めるのが無難です。
③ 重い計算・外部 API 連携
Serverless。
画像のサムネイル生成 PDF レンダリング 数十秒待つ外部 API へのコール のような処理は、Edge の実行時間上限を超えやすいです。
Serverless 側で maxDuration を伸ばす設定ができるので、長時間処理は基本こちら。
④ AI モデル呼び出し(LLM)
ストリーミング応答は Edge が向く / 重い前処理がある場合は Serverless。
OpenAI などの LLM API はストリーミングを返すケースが多く、Edge と相性が良いです。
ただし 事前にデータベースから過去履歴を引っ張ってくる といった処理が絡む場合は、その部分だけ Serverless にして AI 呼び出し本体は Edge という分割もありえます。
⑤ 静的ファイル配信や ISR
これは そもそも Function ではない。
静的アセットは Vercel の Edge Network が直接配信し、ISR で生成されたページもキャッシュされて Edge から返るので、Function を意識する必要はありません。
Vercel の請求が高くなる原因と対策 で触れたとおり、ISR の revalidate 設計 の方が課金の主役になります。
Edge で詰まりやすい3つのポイント
Edge にすると速くなる、と思って切り替えると、よくぶつかる壁を整理します。
① 既存 npm パッケージが動かない
Node 標準モジュールに依存しているパッケージは ImportError になる。Edge Runtime 対応を謳っているか をパッケージの README で確認する。
② 通常の DB ドライバが使えない
TCP コネクションを直接使う MySQL / PostgreSQL クライアントは Edge で動かないことが多い。HTTP / WebSocket 対応の DB プロキシを挟むのが定石。
③ 実行時間とメモリの上限が厳しい
長時間処理を Edge に置くと FUNCTION_INVOCATION_TIMEOUT になる。`数秒以内に終わる軽い処理` の前提を超えそうなら Serverless 側に逃がす。
特に DB が絡む API を全部 Edge にしてしまう のは事故が起きやすい構成です。
基本は ミドルウェアと、認証チェックと、ストリーミング系だけ Edge に寄せ、DB を触る本体は Serverless という棲み分けが、現時点では最も安全な現実解です。
料金構造の違い
両者は 課金単位そのものが違う ので、Edge は安い / Serverless は高い という単純比較はできません。
| 軸 | Edge | Serverless |
|---|---|---|
| 主な課金軸 | 呼び出し数 + 実行時間(ミリ秒) | GB-hour(メモリ × 実行時間) |
| 軽い処理を大量に | 得意。Edge の方が単価メリットが出やすい | 呼び出し回数で課金されやすい |
| 重い処理を少量 | 実行時間上限で頭打ちになりがち | 得意。長時間処理はこちらの土俵 |
実際の細かい単価は Vercel Pricing で確認するのが安全ですが、ざっくり 軽くて多い → Edge、重くて少ない → Serverless の方がコスパが良くなりやすい と覚えておけば十分です。
どう移行・選択するか
実務で 今書いてる API、Edge にすべきか Serverless のままか を判断するときの簡易チャートです。
判断に迷ったら、 まず Serverless で書いて、必要が出てから Edge に切り替える のが安全 です。
最初から Edge を狙うと、Edge で書いていたら DB が繋がらないことに後から気づく というハマり方をしがちで、リファクタの方が時間を食います。
AI 時代の Edge と Serverless 観
v0 で UI を作る や AI 連携を Vercel に寄せる流れ を見ても、AI が出した応答をストリーミングで返す UI が増えています。
このユースケースでは LLM API への呼び出しを Edge から行い、ストリーミング応答をそのまま返す 構成が一般的になりつつあり、Edge の存在感はじわじわ大きくなっています。
一方で、AI に何を答えさせるかの前段で、ユーザーの過去履歴を DB から引いてくる ような処理は Serverless 側で持つほうが現実的です。
AI 時代の Vercel 設計は Edge と Serverless を組み合わせる 前提 になっていて、どちらか一方で全部やる という発想だと、どこかで無理が来ます。
Vercel Edge / Serverless に関するよくある質問
Q. Edge Function は本当にコールドスタートゼロですか？
A. 厳密にはゼロではありませんが、Serverless と比べて体感できないほど小さい(数 ms 単位)というのが実態に近いです。常時温まっているコンテナ のような状態が世界中に分散している、と理解しておけば十分です。
Q. Next.js の API Route はデフォルトでどちらで動きますか？
A. Serverless です。App Router の Route Handler、Pages Router の API Route、いずれも明示的に export const runtime = 'edge' を書かない限り Serverless で動きます。middleware.ts だけは Edge がデフォルトです。
Q. Edge ランタイムで Prisma は使えますか？
A. 一部の構成では使えますが、Prisma Accelerate や Prisma Data Proxy のような HTTP プロキシ経由が前提になり、対応 DB / 設定の縛りがあります。普通の PostgreSQL 直接接続を Edge から行うのは現状難しいので、Edge で Prisma を使うなら専用の設定が必要 と認識しておくのが安全です。
Q. Edge と Serverless を1つのプロジェクトで混在できますか？
A. 可能ですし、むしろ そうしている案件が多い です。ファイル単位で runtime を指定するため、ミドルウェアと一部 API は Edge、DB を触る API は Serverless のような構成が普通に組めます。
Q. Serverless Function のリージョンはどう選ぶべきですか？
A. DB と同じリージョン が基本です。東京の DB を使うなら hnd1、米国東部の DB を使うなら iad1、というように DB の物理位置に揃えると接続レイテンシが減り、関数の実行時間も短くなります(=料金も下がる)。
Q. Vercel の Edge Function と Cloudflare Workers は何が違いますか？
A. アーキテクチャは近い(V8 isolates ベース)ですが、料金体系、ランタイム、エコシステムが別物 です。Vercel の Edge は Next.js / Vercel エコシステムに最適化されており、Cloudflare Workers はより低レベルかつ Cloudflare の各種サービス(R2 / D1 / KV)と統合されているのが特徴です。どちらを選ぶかは Vercel 全体で固めるか、Cloudflare の他サービスも使うか という戦略の話になります。
Q. Edge にしたら必ず速くなりますか？
A. 軽い処理ではほぼ確実に速くなりますが、重い処理だとむしろ遅くなる可能性もあります。Edge の魅力はレイテンシの低さで、CPU パワーやネットワーク帯域は Serverless より控えめです。軽くて多い処理 は Edge、重くて少ない処理 は Serverless、と用途で見極めるのが結局いちばん安定します。
参考リンク
- Vercel Docs: Functions Overview
- Vercel Docs: Edge Runtime
- Vercel Docs: Edge Functions Limitations
- Vercel Docs: Configuring Serverless Functions
- Next.js: Route Handlers - runtime
- Prisma: Edge Function support