クライアントが去年の月曜日の朝に電話をくれました。メッセージではなく、電話です。それは決していい兆候ではありません。彼は前週の木曜日にVercelのProプランでNext.jsマーケティングサイトをデプロイし、週末に製品ローンチを実施し、340ドルの請求書が受信トレイに届いているのに目が覚めました。サイトは素晴らしくパフォーマンスを発揮していました。トラフィックが急増しました。そしてVercelは彼らのネットワークから出ていくすべてのギガバイトのデータを静かに計測していたのです。彼は支出上限を設定していませんでした。アラートも設定していませんでした。何もありませんでした。
その電話通話が理由で、本番環境レベルのものをデプロイする前に、すべてのクライアントとVercel請求の衛生管理に20分を費やすようになりました。
Vercelが帯域幅に対してどのように課金するのか、なぜそれが人々を不意打ちするのか、そして実際に何をすべきかを理解する必要があります。
---
Vercelにおける「エグレス」が実際に意味すること
Egressとは、Vercelのネットワークからエンドユーザーへ転送されるデータのことです。画像、JavaScriptバンドル、APIレスポンス、フォントファイル。すべてです。エッジから出てブラウザに到達するものはすべてカウントされます。out of Vercel's network to the end user. Every image, every JavaScript bundle, every API response, every font file. If it leaves their edge and hits a browser, it counts.
Hobbyプランでは月100GBの帯域幅が含まれます。Proなら1TBです。多く聞こえますね。ただし、大きな画像を配信している場合、重いJSONペイロードを持つページでサーバーサイドレンダリングを行っている場合、またはアプリが突然のトラフィックスパイクに見舞われた場合、予想より速く1TBを超過する可能性があります。Vercelは現在のところProでの超過分に対して1GBあたり$0.15を請求します（常に彼らの現在の料金ページを確認してください。これは変わります）。their current pricing page because this moves).
そのため、制限を500GB超過すると$75です。壊滅的ではありません。しかし、バイラルな瞬間、画像最適化設定の失敗、またはスクレイパーがAPIルートを叩きまくる場合は、数千ドルになることもあります。
なぜ人々を意表をつくのか
問題は、ローカル開発では何の警告も得られないということです。高速に構築し、高速にデプロイし、すべてが問題ないように感じられます。Vercelのダッシュボードは帯域幅の使用状況を表示しますが、注意喚起をしてくれません。事前に課金アラートを設定していない場合、請求書が到着して初めて気付きます。
---
あなたの請求を台無しにしそうな設定
Seahawkで多くのデプロイメントを監査してきました。何度も繰り返し見かける4つの犯人がいます。
1. next/imageをバイパスする最適化されていない画像
next/imageは本当に優れています。サイズを変更し、WebPに変換し、キャッシュします。しかし、開発者がS3バケット内のフル解像度ファイルを指す<img>タグから直接画像を引っ張ってきて、Vercel APIルートを通してプロキシしているプロジェクトを見てきました。すべてのリクエストが4MBのJPEGをVercelのネットワークを通して引っ張ってきていたのに対し、200KB WebPはCDNエッジから来ていました。これに50,000ページビューを掛けて計算してみてください。 is genuinely good at what it does. It resizes, converts to WebP, and caches. But I've seen projects where developers were pulling images straight from an <img> tag pointing at full-resolution files in an S3 bucket, proxied through a Vercel API route. Every request was pulling a 4MB JPEG through Vercel's network instead of a 200KB WebP from a CDN edge. Multiply that by 50,000 page views and do the maths.
Always use next/image with a proper remotePatterns config. If the image source is external, make sure it's hitting the CDN cache and not making a round trip through your serverless functions.next/image with a proper remotePatterns config. If the image source is external, make sure it's hitting the CDN cache and not making a round trip through your serverless functions.
2. 大量のペイロードを返すAPIルート
2021年、私はイギリスの小売業者向けにeコマース商品カタログを構築しました。彼らのAPIルートはデータベースから商品リストを取得し、フロントエンドが使用しないフィールドを含む商品オブジェクト全体を返していました。説明、内部SKUノート、バリアントメタデータ、その他もろもろです。各レスポンスは80KB程度でしたが、実際に必要なのは12KBでした。entire product object, including fields the front end never used. Description, internal SKU notes, variant metadata, the lot. Each response was around 80KB instead of the 12KB it needed to be.
APIレスポンスを削減してください。クライアントが実際に使用するフィールドだけを返します。Prismaのような何かを使用している場合、selectを使って取得するものを制限してください。サードパーティのAPIを使用している場合、ペイロードを変換して縮小した上でダウンストリームに送信してください。select to limit what you pull. If you're using a third-party API, transform and slim the payload before sending it downstream.
4. 高トラフィックルートの短い再検証ウィンドウを使用したISR
Incremental Static Regenerationは理論上は優れています。実際には、1分あたり10,000ヒットを受けるページにrevalidate: 30を設定した場合、キャッシング自体は正しく機能しています。しかし、ほぼリアルタイムの更新が必要だからという理由でrevalidate: 1に設定してから変更し忘れた場合、基本的には余分なステップを踏んだSSRを実行しており、キャッシュミスが近い場合はすべてのレスポンスでエグレスを支払っていることになります。revalidate: 30 on a page that gets 10,000 hits per minute, you're still caching correctly. But if you set it to revalidate: 1 because you wanted near-real-time updates and forgot to change it... you're basically doing SSR with extra steps and paying for the egress on every near-miss cache response.
再検証ウィンドウについて意図的に考えてください。ほとんどのコンテンツは毎秒再検証する必要はありません。
5. キャッシュヘッダーのないサーバーレス関数
これは微妙です。サーバーレス関数のレスポンスにCache-Controlヘッダー（またはVercelのs-maxage / stale-while-revalidateの組み合わせ）が含まれていない場合、レスポンスはエッジでキャッシュされません。すべてのリクエストが関数にヒットしてフルラウンドトリップを移動します。CDNの利点を完全に失い、すべてのレスポンスでエグレスを支払うことになります。Cache-Control header (or Vercel's s-maxage / stale-while-revalidate combo), the response is not cached at the edge. Every request hits the function and travels the full round trip. You lose the CDN benefit entirely and pay egress on every single response.
`` Cache-Control: s-maxage=3600, stale-while-revalidate=86400 `` Cache-Control: s-maxage=3600, stale-while-revalidate=86400 ``
そのヘッダーだけでクライアントに実際の節約をもたらしています。本当です。Vercelの公式キャッシングドキュメントがそのヘッダーの動作を詳しく説明しています。一度きちんと読んでください。Vercel's own caching docs explain the header behaviour in detail. Read them once properly.
---
請求アラートの設定方法（必要になる前に）
これはプロダクションデプロイの前に、最初のステップとして行うべきです。7番目ではなく。
- Vercelチームの設定に移動します。
- 「Billing」の下で「Spend Management」を見つけます。Billing , find Spend Management.
- 支出上限を設定します（ハードキャップ：上限に達するとVercelがリクエストの配信を停止）、または通知閾値を設定します（ソフトアラート：数値に達するとメールが届きます）。spend limit (hard cap, where Vercel stops serving requests after the limit) or a notification threshold (soft alert, emails you when you hit a number).
- 痛いと感じる金額の50%で通知を設定し、予想される月額請求の約120%でハードリミットを設定することをお勧めします。
ハードキャップは両刃の剣です。これに達するとサイトがダウンします。ですから慎重に検討してください。マーケティングサイトなら問題ありません、厳しくキャップしてください。有料ユーザーがいるSaaSの場合は、寛大な通知を設定してダッシュボードを監視してください。
---
重い処理を他の場所にオフロードする
Vercelは静的アセット用のCDNではありません。CDNを持っていますが、ギガバイト単位で料金がかかります。大量の静的アセットの場合は、より安い場所に置きましょう。
約18ヶ月間、大容量メディアファイルをCloudflare R2経由でルーティングしています。R2は出力料金がゼロです。ストレージと操作費は払いますが、データ送出料は発生しません。画像の多いサイトでは大きな節約になります。私のクライアントが運営している写真ポートフォリオプラットフォームはVercel出力料に月約180ドル払っていました。フル解像度画像とギャラリーアセットをすべてR2に移動し、サムネイルはnext/imageを通す設定にしたところ、Vercelの請求が40ドル未満に下がりました。Cloudflare R2 for about eighteen months now. R2 has zero egress fees. You pay for storage and operations, not for the data going out. For image-heavy sites this is a serious saving. A client of mine runs a photography portfolio platform and was paying around $180/month in Vercel egress. We moved all the full-res images and gallery assets to R2, kept the thumbnails going through next/image, and the Vercel bill dropped to under $40.
検討する価値のある代替案：
- Vercelのエッジ機能が不要な静的デプロイメント向けのCloudflare Pages。手厚い無料枠があり、出力料金がありません。 for static deployments where you don't need Vercel's edge features. Generous free tier, no egress fees.
- AWSのエコシステムをすでに使っている場合はS3の前段にAWS CloudFrontを配置。転送コストはVercelの超過料金よりも大規模時に低くなります。 in front of S3 if you're already in the AWS ecosystem. Transfer costs are lower than Vercel's overage rates at scale.
- BunnyCDNは純粋なアセット配信なら安くて高速です。アセット量が大きなWordPress-to-Next.jsマイグレーション案件で何度か使っています。 is cheap and fast for pure asset delivery. I've used it on a few high-traffic WordPress-to-Next.js migrations where the asset volume was large.
ポイントは：VercelはNext.jsアプリケーションロジックを実行するのに適した場所です。ギガバイト単位のメディアを配信するのに常に適した場所とは限りません。
---
リアルタイムで使用状況を監視する
月末にダッシュボードをチェックするだけではいけない。そうやって私のクライアントは月曜日に私に電話をかけることになった。
実際に私が使っているものはこれだ：
- Vercel Analyticsはページレベルのデータを提供し、どのルートが最もトラフィックを生成しているか（つまり最もエグレスを生成しているか）を特定するのに役立つ。 gives you page-level data and is useful for spotting which routes are generating the most traffic (and therefore the most egress).
- Axiomはvercelのログドレインときれいに統合でき、時系列でリクエストサイズをクエリできる。2022年後半から使い始めたが、大規模なプロジェクトではトラフィックスパイクとエグレスジャンプを相関させるのに役立っている。 integrates cleanly with Vercel's log drains and lets you query request size over time. I started using it in late 2022 and it's been useful on bigger projects for correlating traffic spikes with egress jumps.
- シンプルなcron（Vercelは今ネイティブcronサポートを持っている）をセットアップして、そのAPIを叩き、帯域幅がしきい値を超えたときにSlackチャネルに投稿する。私はSeahawk自身のインフラのための軽量版を構築した。2時間で作れて、多くの不安を解消できる。
Vercel REST APIはデプロイメントと使用データを公開している。世界で最も洗練されたAPIではないが、基本的なアラートに必要なことはできる。Vercel REST API exposes deployment and usage data. It's not the most elegant API in the world but it does what you need for basic alerting.
---
誰も話さないアーキテクチャの決断
十分に議論されていないものがある：時にVercelは間違ったデフォルトである。
あなたのプロジェクトが本当の動的機能を持たない静的マーケティングサイトなら、Vercelは必要ない。Cloudflare PagesやNetlifyの無料ティアはエグレスの心配なしに仕事をこなせる。あなたはVercelを「無駄にしている」わけではなく、単にそのワークロードに適したツールにいないだけだ。
逆に、エッジミドルウェア、サーバーコンポーネント、実際の処理を行うAPIルートを備えた適切なNext.jsアプリを構築しているなら、Vercelに支払う価値がある。DXは本当に優れているし、エッジネットワークも高速だ。ただし、最初からきちんとアーキテクチャを設計すること。
キャリアの初期段階（2016年頃、Vercelが存在する前、HerokuやNetlifyでのデプロイメント方法を模索していた時代）に私が犯した誤りは、デプロイメントプラットフォームを無料の事後対応として扱ったことだ。プラットフォームの選択は、データベースの選択と同じくらいコスト構造に影響を与える。真摯に考えるべきだ。
---
FAQ
Hobbyプランで100GBを超えた場合、エグレス料金は発生しますか？
いいえ。HobbyプランではVercelはオーバーチャージを請求せず、制限に達するとデプロイメントをスロットルするか一時停止する。どちらにしろ良くはないが、予期しない請求は来ない。予期しない請求が発生するのはProとEnterpriseで、含まれる量を超えた使用量が従量制で課金される場合だ。
Vercelの画像最適化はエグレスに含まれますか？
はい。next/imageを通じて提供される最適化画像もエグレスとしてカウントされる。節約は ファイルサイズにある。3MBのJPEGではなく180KBのWebPを提供しているので、画像あたりのエグレスは大幅に低い。最適化自体がコストを削減するのであり、特別な除外があるわけではない。next/image still count as egress. The saving is in file size: you're serving a 180KB WebP instead of a 3MB JPEG, so the egress per image is much lower. The optimisation itself is what reduces the cost, not some special exemption.
エグレスを削減するために、Vercelの前にカスタムCDNを使用できますか？
CloudflareのプロキシをあなたのVercelデプロイメントの前に置くことができる。Cloudflareはエッジでレスポンスをキャッシュするため、CloudflareのキャッシュにヒットするリクエストはVercelに到達しない。これはエグレスと関数呼び出し両方を大幅に削減できる。プレビューデプロイメントとヘッダー処理に関していくつか注意点があるが、本番環境ではこれは一般的で正当なアプローチだ。Cloudflareのプロキシに関するドキュメントはセットアップをカバーしている。Cloudflare's documentation on proxying covers the setup.
Vercelの予期しない請求の最大の原因は何ですか？
私の経験では、画像処理です。最適化なしでフル解像度の画像が配信されているか、画像最適化ルートがリクエストのたびに呼び出されているのに適切なキャッシュがないかです。まず画像パイプラインを整理して、他のすべてはその後です。
使用量が急増した場合、Vercelは自動的に通知してくれますか？
デフォルトではありません。自分で設定する必要があります。「帯域幅の80%を使用しました」と言うすぐに使えるアラートはありません。それがギャップです。支出管理の閾値は、本番デプロイメントをセットアップしたその日に設定してください。後からではなく。
---
Vercelは素晴らしいプラットフォームです。私も使っていますし、Seahawk Mediaも使っていますし、適切なプロジェクトには引き続き推奨します。しかし、これは実際のインフラストラクチャ上で実行されるメーター制サービスであり、価格設定はそれを反映しています。予期しない請求に悩まされている開発者は、ほぼ例外なく、これを無料のCDNのように扱い、請求設定を一度も見なかった人たちです。デプロイ時に5分間の設定をするだけで、非常に不快な月曜日の朝の電話をかけられることを避けられます。