engineer.notes

try / verify / log

2026.11.06

engineer.notes
engineer.notes // programming, servers, networks, security, AI — engineer's working notes, indexed for later lookup.
検索
フレームワーク ソフトウェア 公開日 2026.04.12 更新日 2026.10.24

Vercelとは？何ができる？Next.jsとの相性・向いている案件・注意点を解説

Vercelとは何か、何ができるのか、AWSやレンタルサーバーとどう違うのかを整理し、Next.jsとの相性や向いている案件、Preview運用の注意点まで実務目線でまとめた解説記事です。

目次（23項目）

先に要点

  • Vercel は、フロントエンドや Web アプリの公開、プレビュー、運用をまとめて扱いやすいデプロイ基盤です。
  • Next.js と特に相性がよく、Preview / Production を分けた運用が回しやすいのが大きな強みです。
  • 公開サイト、プロダクトサイト、会員向けフロント、画面中心の Web アプリに向きますが、重い業務ロジックや長時間バッチを全部任せる設計には向きません。
  • 実務では「どこまでを Vercel に置くか」「環境変数をどう分けるか」「Preview を誰に見せるか」を先に決めると事故が減ります。

Vercel って結局なにができるの？ AWS やレンタルサーバーと何が違うの？

フロントエンド寄りの開発をすると、Vercel という名前がかなり早く出てきます。
ただ、紹介記事の多くは 簡単にデプロイできます で止まりがちで、どんな案件に向くのか どこからが限界なのか 実務で何を気にするべきか まで見えにくいことも多いです。

この記事では、2026年10月時点の Vercel 公式ドキュメント（Environments、Functions、Deployment Protection、プラン、リージョン）を確認しながら、Vercel の特徴、向いている案件、始め方、注意点を初心者向けに整理します。
Next.js を軸にした構成と相性がよいことも多いので、Next.jsは他のフレームワークと何が違う？｜React単体・Nuxt・バックエンド系との比較で整理 も合わせて読むと立ち位置が見えやすいです。

Vercelとは何か

Vercel(バーセル)は、フロントエンドや Web アプリのデプロイ、プレビュー、配信、サーバー処理をまとめて扱いやすくした基盤です。 特に Next.js の開発元が提供しているため、Next.js の機能を素直に活かしやすいのが大きな特徴です。

読み方と開発元

読み方や開発元(Vercel社)の成り立ちが気になる場合は、Vercelを作っている会社とは？歴史と背景 にまとめています。

公式ドキュメントでも、Vercel には Local / Preview / Production の環境があり、ブランチやプルリクごとに Preview を作れる運用が標準になっています。
この Preview を前提にした運用 が、Vercel の便利さの中心です。

Git の更新から本番反映まで Local 手元で開発 Preview 確認URL Production 本番反映 ブランチやプルリクごとに Preview を作れる 本番より前に確認できるのが強み
ただの静的ホスティングではない

初心者向けにかなりざっくり言うと、フロントエンド寄りの開発で、Git の更新から確認URLの発行、本番反映までを細かく手作業せず回しやすくする土台 です。ただの静的ホスティングではなく、SSR、SSG、API 的な処理、画像最適化なども含めて一体で扱えるのがポイントです。

Vercelで何ができる？（主な機能）

結局、どこまでできるの？ ── ここが一番知りたい所だと思うので、Vercelの主な機能を用途別に整理します（2026年10月時点の公式ドキュメントで確認）。

分類できること
デプロイ・運用Gitにpushするたびの自動デプロイ／ブランチ・PRごとのプレビュー環境／本番・プレビュー・カスタムの環境分離／即時ロールバック／段階的に配信するRolling Releases
配信・表示速度51か国・126以上の拠点を持つVercel の CDN／画像最適化／ページを自動で再生成するISR
サーバー処理API的な処理を書けるFunctions（Fluid compute）／リクエストの前に挟むRouting Middleware
AI関連UIを生成するv0／AI SDK／複数モデルを1つの窓口で扱うAI Gateway／隔離実行のSandbox／MCPサーバー
セキュリティプレビューの閲覧制限Deployment Protection／WAF／Bot Management・BotID／DDoS対策
チーム・監視画面上で指摘できるToolbar・Comments／下書き確認のDraft Mode／Observability
ドメイン独自ドメインの割り当てとDNS管理。SSL（HTTPS）は自動

ひとことで言えば、「Gitにpushすれば世界中に速く公開され、プレビューで確認でき、必要ならサーバー処理やAIまで足せる」——これがVercelでできることです。

注意：古い機能一覧が出回っています

解説記事には Vercel KV や Vercel Postgresを「Vercelの機能」として挙げるものが残っていますが、どちらも提供を終了しています。2026年10月時点の公式ドキュメントでは、Vercel 自身のストレージは Blob と Global Config で、データベースは Marketplace から Neon・Upstash・Supabase などを連携する形です。製品構成は変わるので、採用判断では必ず公式で確認してください。

2026年はAIが前面に

近年のVercelは AI関連（v0・AI SDK・AI Gateway・Sandbox）を大きく打ち出しています。単なる「デプロイ屋」からAIアプリの実行基盤へ広がっているのが今の姿です。

Vercelを使うと何が楽になるのか

実務で効いてくるポイントを絞ると、次の3つです。

1. プレビュー環境が標準

ブランチやプルリクごとに Preview URL が自動発行されるので、レビューや検証がかなり速く回ります。

2. Git連携が前提

Git の変更とデプロイの流れが自然につながるので、公開作業の属人化を減らしやすいです。

3. 画面配信と処理を近い場所で扱える

静的配信だけでなく Functions も使えるので、画面中心のアプリを比較的整理しやすいです。

特に、SSR や SSG を使った公開サイトでは、Vercel の配信基盤と相性がよいです。
CDN 前提の配信と、プレビューの回しやすさが噛み合います。

実務でありがたい場面

  • デザイナーや非エンジニアにも Preview URL を見せながら詰めたい
  • コーポレートサイトやオウンドメディアを素早く更新したい
  • フロントエンド主導で会員画面やダッシュボードを育てたい
  • 小さめの API やサーバー処理も同じ流れで置きたい

逆に、OS レベルの制御が必要 重いバッチがある 閉域網前提 業務ロジックが巨大 のような案件は、Vercel 単体で押し切るより役割を分けた方が整理しやすいです。

向いている案件 / 向きにくい案件

観点 向いている 向きにくい
サイト種別 公開サイト、オウンドメディア、LP、プロダクトサイト 社内の重い基幹システム
アプリ構成 画面中心の Web アプリ、会員ページ、BFFに近い軽い処理 大量バッチ、長時間処理、複雑な業務ロジックを持つアプリ
運用 Preview を回しながら素早く改善したい オンプレ前提、社内ネットワーク限定の運用

つまり、公開サイト + 画面中心 の構成が強みです。
逆に、重いバックエンドや社内専用の構成は、API サーバーや別基盤を組み合わせた方が整理しやすいです。

他の基盤とどう役割分担するか

ここは実務でかなり大事です。
Vercel を使うかどうかより、Vercel に何を置き、何を別に出すか の方が設計に効きます。

置き場所 任せると相性がよいもの
Vercel フロントエンド、公開ページ、軽い API、Preview を回したい画面
別の API サーバー 重い業務ロジック、長い処理、細かい権限制御、社内DB直結
別ストレージ / SaaS 大きいファイル、永続データ、認証基盤、監視基盤

この分け方を先に決めると、なんでも Vercel に載せようとして苦しくなる のを避けやすいです。 インフラ全体の選び方から見直したい場合は、クラウド、VPS、レンタルサーバーの違いは？コスパ比較と実務での使い分けを解説 もつながります。 AWS Amplify・Netlify・Cloudflare Pages など他のデプロイ基盤との使い分けは、Vercelと他のデプロイ基盤の比較 で整理しています。

実務での始め方

「とりあえず動かす」だけなら簡単ですが、実務で詰まりにくくするには次の順が現実的です。

実務で詰まりにくい Vercel の始め方

  1. 1
    リポジトリと連携する

    GitHub / GitLab / Bitbucket のリポジトリと連携する。

  2. 2
    プロジェクトを作成する

    Vercel 側でプロジェクトを作成する。

  3. 3
    環境変数を分ける

    Local / Preview / Production の環境変数を分けて整理する。

  4. 4
    ローカルとのずれを減らす

    vercel link や vercel env pull でローカルとのずれを減らす。

  5. 5
    Preview で確認してから反映

    Preview で動作確認してから Production に反映する。

  6. 6
    アクセス保護をかける

    必要なら Preview へのアクセス保護をかける。

Preview / Production を分けられるのが強みなので、最初からこの分離を前提にした方が事故が減ります。 ステージングとは何か まで含めて整理したい場合は、ステージング環境とは？本番環境との違いと必要性を解説 もつながります。 アカウント作成から最初のデプロイまでの具体的な手順は、Vercelの始め方・最初のデプロイ で追えます。

実務で見ておきたい設定

  • Preview と Production で環境変数を分ける
  • Webhook、OAuth、外部APIの向き先を環境ごとに確認する
  • 認証前の Preview を外部へ見せてよいか決める
  • Functions に重い処理を載せすぎていないか確認する

本番より前に確認できる のが強みなので、ただデプロイするだけで終わらせるのはもったいないです。
レビュー、QA、顧客確認まで Preview に乗せられると、Vercel の価値がかなり出ます。

よくあるつまずき

Preview と Production を混ぜない

Preview で環境変数や外部APIの向き先を間違えると、検証中に本番を触ってしまう事故が起きやすいです。

  • Preview / Production の環境変数を整理していない
  • API を同じ環境に向けたまま検証してしまう
  • 認証や管理画面のアクセス制御を後回しにする
  • Functions へ重い処理や長い処理を載せすぎる
  • ローカルでだけ動いて本番が落ちる

特に Preview の扱いは、Vercel の強みであり、同時に事故ポイントにもなります。 最初に どの環境で何を確認するか を決めるのが大事です。 また、Functions や配信量の使い方によっては料金が想定外に膨らむことがあります。料金体系と無料枠は Vercelの料金プランと無料枠、高額請求になりやすい原因と対策は Vercelで高額請求になる原因と防ぎ方 で整理しています。

実務で困りやすい場面

例えば、フロントエンドは Vercel、API は別サーバーという構成では、次のようなずれが起こりやすいです。

  • Preview だけ API の向き先が本番のまま
  • OAuth のコールバックURLを Preview 分まで考えていない
  • 画像やファイルの保存先をローカル想定のまま実装している

Vercel 自体が悪いというより、公開URLが増える前提 の設計をしていないと詰まりやすい、というイメージです。

どんなチームに相性がよいか

Vercel は、インフラを細かく触りたいチームより、公開と改善の速度を上げたいチーム と相性がよいです。
特に次のようなチームだと強みが出やすいです。

  • フロントエンド主導で改善を回す
  • デザイナーや企画担当と Preview を見ながら進める
  • 公開サイトや会員画面を短いサイクルで触る
  • サーバー運用を必要以上に抱え込みたくない
別構成の方が安心な場合

逆に、サーバー内部を細かく制御したい、ネットワーク制約が強い、ジョブや業務処理が重い、という場合は別構成の方が安心です。

Vercelに関するよくある質問

Vercelは無料で使える？

個人開発や小さな検証目的なら、無料プランの Hobby から始められます。 ただし Hobby は、公式のフェアユースガイドラインで個人・非商用の利用に限られています。商用サイトや業務用途、チームでの共同作業には有料の Pro / Enterprise が前提です。2026年10月時点の Hobby の無料枠は、月100GBのデータ転送や100万回の関数呼び出しなどで、上限を超えると多くの機能は30日たつまで使えなくなります。最新の制限やプラン内容は必ず公式のプランページで確認してください。

VercelとNext.jsはどんな関係？

Next.js は Vercel が開発しているフレームワークで、Vercel 上でデプロイすると SSR、SSG、画像最適化、Functions などの機能が素直に動くよう調整されています。 Vercel は Next.js 以外（Astro、SvelteKit、Nuxt、Remix、純粋な静的サイトなど）にも対応しますが、Next.js の組み合わせがもっとも事例が多く、つまずきにくい構成です。

VercelとAWS、レンタルサーバーの違いは？

Vercel は フロントエンド寄りのアプリを公開・更新するための専用基盤 です。 AWS は EC2、S3、CloudFront、Lambda などを自分で組み立てる汎用クラウドで、自由度は高い分、設計と運用の手間も大きくなります。レンタルサーバーは PHP や WordPress を中心とした古典的な共有環境で、JavaScript フレームワーク前提の SSR / Preview 運用とは噛み合わせが弱めです。詳しくは クラウド、VPS、レンタルサーバーの違いは？ も合わせて読むと整理しやすいです。

Vercelに向かないシステムは？

長時間バッチ、社内ネットワーク限定の業務システム、巨大なバックエンド処理、ハードウェア寄りの制御を要する構成は、Vercel 単体ではなく別の API サーバーや専用基盤と組み合わせた方が無難です。 Vercel は 画面と軽い API を素早く回すための場所、と割り切るのが現実的です。 2026年からは Dockerfile のコンテナや常駐ワーカー（Daemons）も動かせるようになりましたが、どちらもベータで、実行時間の上限や永続ストレージが無いといった制約があります。詳しくは Vercelと他のデプロイ基盤の比較 の「Vercel で動かせるようになったもの」を見てください。

Vercelに日本リージョンはある？

静的コンテンツは、世界中にある Vercel の CDN の拠点から、利用者に近い場所で配信されます。 Vercel Functions を実行するリージョンには東京（hnd1）と大阪（kix1）があります。ただし新規プロジェクトの既定はワシントンD.C.（iad1）なので、日本向けならプロジェクトの設定や vercel.json の regions で変更します。選べるリージョン数は Hobby が1つ、Pro が最大5つです（2026年10月時点）。DB や外部 API の所在に近いリージョンを選ぶのが基本です。

まとめ

Vercel は、フロントエンド中心の開発で、公開・確認・改善を速く回しやすいデプロイ基盤です。 Preview / Production を前提にした運用がしやすく、Next.js を使う案件では特に相性がよいです。

一方で、重いバックエンドや社内限定の構成は、Vercel 単体より別の基盤と組み合わせた方が整理しやすいです。 実務では どこまでを Vercel に任せるか を最初に切ることが、いちばん大事です。

参考リンク

あとで見返すならここで保存

読み終わったあとに残しておきたい記事は、お気に入りからまとめて辿れます。