Vercelの固定料金CDN「Flat Rate CDN」──料金の仕組みと切り替え判断のポイント
Vercel は 2026 年 9 月 8 日、CDN の利用料を固定月額にする「Flat Rate CDN」を Pro チーム向けに一般提供しました。従量課金の代わりに月間キャパシティのティア (段階) を購入する方式で、Pro には最小ティアが追加費用なしで含まれます。新規 Pro チームはデフォルトで有効、既存チームは Billing 設定からオプトインします。バズやボットによる一時的なトラフィック増で請求が跳ねるリスクを抑えたいチームには、切り替えを検討する価値があります。ただし固定になるのは CDN の一部リソースだけで、関数実行やオリジン転送は従量のままです。
Flat Rate CDN の料金ティアと対象リソース
ティアは月間の CDN リクエスト数とデータ転送量で区切られています。公式ドキュメントに記載されている構成は次のとおりです (いずれも税抜、USD)。
Pro に含まれる最小ティア: 100 万リクエスト / 1 TB
月 20 ドル: 1,000 万リクエスト / 50 TB
月 100 ドル: 5,000 万リクエスト / 50 TB
月 300 ドル: 1 億 5,000 万リクエスト / 50 TB
ティアに含まれる (=従量請求されなくなる) リソースは、CDN リクエスト (請求画面では Edge Requests と表示)、Fast Data Transfer、Blob Data Transfer、Sandbox Data Transfer、CDN リクエストから生成される Observability イベントです。キャパシティはプロジェクト単位ではなくチーム単位で管理されるため、1 つのプロジェクトのスパイクはチーム全体の枠から消費されます。逆に言えば、プロジェクトごとに枠を配分する運用は不要になります。
重要なのは、ここに挙がっていないメーターは対象外だという点です。Vercel の CDN 課金は Edge Requests、Fast Data Transfer、Fast Origin Transfer の 3 つが基本ですが、Fast Origin Transfer (CDN と関数の間の転送) は固定料金の対象に含まれていません。関数の実行時間や ISR の読み書き、画像最適化なども別メーターです。つまり「Flat Rate CDN にしたから請求額が完全に固定される」わけではなく、固定されるのは配信レイヤーの主要コストという理解が正確です。
スパイクが起きたときの挙動
Flat Rate CDN にはスパイク保護がデフォルトで有効になっています。ティアのキャパシティを超えたトラフィックも通常どおり配信され、性能を落とされることも、その月の請求が増えることもありません (フェアユース規定の範囲内)。請求サイクル中にティアが変わらないため、月内の突発的な増加が請求に反映されない設計です。
一方、恒常的に枠を超えた場合は次の請求サイクルの開始時に上位ティアへ移行します。最上位ティアを超える場合は従量課金へ移されます。ドキュメントには「1 日だけのスパイクではティア変更は起きない」と明記されており、瞬間的なピークではなく月間の定常使用量で評価されるという整理です。ティア変更前に使用量を確認できるよう、ダッシュボードの Usage 画面と vercel usage コマンドで日別の内訳が見られます (コード表記は本文では省略しますが、CLI の usage コマンドです)。
Vercel はブログで、限定ベータ中に急激なトラフィック増を経験したチームの例を挙げ、従量課金なら数万ドル規模になっていた CDN 請求が 20 ドルのままだったと説明しています。ここは公表された事例であり、自社の構成にそのまま当てはまる数字ではない点に注意してください。
適用対象と「使えないケース」
Flat Rate CDN は、フロントエンドのアセット配信や API レスポンスなど、一般的な Web アプリケーションの配信を前提にした料金体系です。ドキュメントでは対象外の使い方として、大容量ファイルの一括配布やダウンロードサービス、帯域の大半をメディア配信が占める用途、CDN をストレージやファイルホスティングとして使う構成、アプリのロジックではなく大量データ転送そのものが主目的のワークロードが挙げられています。
これらに該当する場合、あるいは使用量がティア容量を大幅に超え続ける場合、Vercel は該当プロジェクトを Flex CDN ティアへ移す、より適切なプランや製品への移行を求める、必要に応じてサービスを制限する、といった対応を取り得るとされています。動画配信や大容量ダウンロードを含むサイトを運用しているなら、Flat Rate CDN で固定化する前に、その配信をどこで担うかを設計として決めておくべきです。
なお、業務上重要でないプロジェクトを意図的にキャパシティ計算から外すこともできます。Billing 設定の「Exclude projects from capacity」で対象プロジェクトを指定する方式で、対象プロジェクトは Vercel DNS を使っている必要があります (追加時に検証されます)。
切り替えるかどうかの判断手順
オプトインは Billing から数クリックで完了し、いつでも従量課金に戻せます。無効化した場合、現在のサイクル終了までは現ティアが有効で、その後は従量課金に切り替わります。ティア変更も次の請求サイクルから適用されます。可逆ではあるものの反映に月単位のラグがあるため、次の順で確認してから決めるのが実務的です。
Usage 画面または CLI で、直近数か月の CDN リクエスト数と Fast Data Transfer を月別・日別に取得する
ピーク値ではなく「平常月の合計」でティアを選ぶ。スパイクは保護対象なので、ピークに合わせて上位ティアを買う必要はない
従量課金時に Pro に付く無料枠 (CDN リクエストと Fast Data Transfer) と、Flat Rate CDN の最小ティア (100 万リクエスト / 1 TB) を比較する。リクエスト数が多く転送量は少ないサイトでは、固定化によって上位ティアの購入が必要になるケースがあるため、価格ページで現行の無料枠と単価を必ず確認する
Fast Origin Transfer、関数の Active CPU、ISR の読み書き、画像最適化など対象外メーターの金額を請求書で切り分ける。ここが大きいなら、固定化しても体感するブレは残る
動画・大容量ファイル配信が主用途のプロジェクトがあれば、除外設定や配信先の分離を先に検討する
制作会社のように多数のクライアントサイトを 1 チームで運用している場合、チーム単位のキャパシティという設計は見積もりを立てやすくする一方、あるクライアントのスパイクが他案件と同じ枠を消費します。案件ごとに費用を按分している運用では、Usage のプロジェクト別内訳をどう配分ルールに落とすかを先に決めておくと後で揉めません。
キャッシュ設計とボット対策への影響
Vercel はベータ参加チームの声として、CDN 費用が読めるようになったことでキャッシュ前提の設計 (Next.js の Cache Components など) を採りやすくなった、AI クローラーのボットトラフィックを Observability で頻繁に確認する手間が減った、という 2 点を挙げています。配信コストが固定なら、キャッシュヒットを増やす変更のコスト影響を毎回見積もる必要が薄れる、という因果です。
ただしボット対策そのものを止めてよいという話ではありません。キャッシュされない動的リクエストは Fast Origin Transfer と関数実行を発生させ、これらは Flat Rate CDN の対象外です。WAF のレート制限や Bot 管理も別メーターで課金されます。固定料金で守れるのは配信の帯域とリクエスト数であり、オリジン側の負荷とコストは従来どおり設計と対策で抑える領域だと切り分けて考えてください。
まずは Usage 画面で直近の CDN リクエスト数と転送量を確認し、平常月に合うティアを選ぶ。そして請求書のうち対象外メーターがどれだけあるかを把握する。この 2 つを済ませれば、Flat Rate CDN に切り替えるべきかは自チームの数字で判断できます。キャッシュ設計の見直しやオリジン負荷の削減まで含めて相談したい場合は、chot Inc. のお問い合わせからご連絡ください。Next.js を含むフロントエンド開発と Vercel 上の構成について、実際の使用量を前提にお話しします。
