先に要点
- Vercel を初めて触るときに迷いやすいのは、機能そのものより用語の定義が原因のことが多いです。
- まず Project / Deployment / Environment の3つだけ押さえれば、ダッシュボードや公式ドキュメントが一気に読みやすくなります。
- その先は Function(Node.js / Edge)、Domain、Environment Variables、プランの4つを順に押さえれば実務に入れます。
- 初心者が実際に詰まるのは用語ではなく落とし穴です。Edge Runtimeで
cryptoが動かない、Hobbyのまま商用運用して規約違反になる、Preview保護を入れ忘れて非公開ページが漏れる、の3つはこの記事で具体的に潰します。
「Vercelに登録して画面を開いたけど、ProjectとDeploymentって何が違うの?」「Edge Functionと普通のFunctionは別物?」「Production と Preview って?」
Vercelの公式ドキュメントは充実していますが、初心者がまず詰まるのは機能の使い方より 用語の意味 です。言葉が分からないと、ダッシュボードのメニューも公式ドキュメントも読めません。
この記事では、2026年6月時点のVercel公式ドキュメントを確認しながら、初心者がまず押さえるべき基礎用語を「最初に覚える3つ」「次に覚える4つ」「あとで覚えればよいもの」の順で整理します。あわせて、用語を覚えただけでは防げない「実際に踏む失敗」を、エラー文言・確認手順つきで後半にまとめます。
Vercel そのものの全体像は Vercelとは?何ができる?Next.jsとの相性・向いている案件・注意点を解説、流行の背景は Vercelが流行っている理由は?AIの影響もあるのか実務目線で整理、他サービスとの違いは Vercelと他デプロイ基盤の違いは? もあわせて読むとつながりやすいです。
この記事は2026年6月時点の情報をもとに書いています。Vercelは仕様や料金が変わりやすく、特にEdge Runtimeのように扱いが変わった機能もあります。本番採用前は公式ドキュメントの最新情報も必ず合わせて確認してください。
まず覚える3つ:Project / Deployment / Environment
この3つは Vercel のすべての画面で出てきます。最初の理解さえ固めれば、その後の用語が一気に読みやすくなります。
1. Project(プロジェクト)
Vercel上での 1つのアプリケーション単位 です。通常は「1つのGitリポジトリ = 1つのProject」の関係で作ります。
- ドメイン設定はProject単位
- 環境変数はProject単位
- メンバー権限もProject単位
my-blog company-lp のように、サービス名やリポジトリ名がそのままプロジェクト名になることが多いです。
2. Deployment(デプロイメント)
Projectに対して 1回コードを反映した結果 です。つまり「git push やマージのたびに作られる、1つの公開された結果物」です。
- 各 Deployment には固有のURLがつく(
my-app-abc123.vercel.appのような形) - 過去の Deployment にも個別にアクセスできる
- 失敗した Deployment は履歴に残る
- 任意のDeploymentを本番にロールバックできる
「Project = アプリ本体」「Deployment = そのアプリの履歴ある1版」と覚えると自然です。
3. Environment(環境)
Vercel には 3つの環境 があります。
| 環境 | いつ使う | 公開範囲 |
|---|---|---|
| Production | 本番ブランチ(通常 main)に push したとき | 一般公開 |
| Preview | Production以外のブランチや PR を push したとき | URLを知っていれば誰でも(保護を入れない限り) |
| Development | ローカルで vercel dev を実行したとき |
自分の PC のみ |
「同じコードでも、どの環境で動かすかで使う環境変数や設定が変わる」というのが、Vercelの設計の中心です。なお Preview の公開範囲は「URLを知っている人」ではなく「URLを知っていれば誰でも見られる」が正確で、ここが後述の事故の入口になります。ステージング環境との違いは ステージング環境は小規模サイトでも必要? でも整理しています。
次に覚える4つ:Function / Domain / Environment Variables / プラン
Project / Deployment / Environment を押さえたら、次はこの4つで実務に入れます。
4. Function(関数)
Vercelで「動的な処理を動かす場所」です。ボタンを押した、フォームを送信した、APIを叩いた、というときに動くサーバーサイドコードがこれにあたります。
Functionは、どの ランタイム(実行環境) で動かすかを選べます。大きく2つあります。
| ランタイム | 動く場所 | 使えるAPI | 主な用途 |
|---|---|---|---|
| Node.js Runtime(デフォルト) | リージョン | Node.jsのフルAPI、npmパッケージ全般 | DB接続、外部API、複雑処理 |
| Edge Runtime | 各リクエストに近い場所 | Web標準API中心の限定セット | 認証チェック、リダイレクト、軽量処理 |
ここは2026年時点で重要な変化があります。Edge Runtime は現在「非推奨」扱い で、公式ドキュメントにも「パフォーマンスと信頼性の向上のため edge から Node.js への移行を推奨する」と明記されています。新規はまず nodejs(デフォルト)で始めるのが無難です。Edge Runtimeは今も Middleware では使われ続けますが、APIルートやページの処理で積極的に選ぶ理由は薄くなっています。
ランタイムの指定は、Next.js App Routerなら次のように書きます。
| 書き方 | 意味 |
|---|---|
export const runtime = 'nodejs'; |
Node.js Runtime(省略時もこれ) |
export const runtime = 'edge'; |
Edge Runtime |
「Edgeは速いが制約が多い」「Node.jsは何でも使えるが起動はリージョン1か所」と、ざっくりはこの理解で合っています。ただし後述するとおり、Edgeの「制約」は速さの代償として軽く見られがちで、初心者が一番派手に詰まる箇所です。
5. Domain(ドメイン)
Vercelには「自動で配布されるドメイン」と「自分で持ち込むドメイン」があります。
- 自動配布:
your-project.vercel.appのサブドメイン(無料、すぐ使える) - 独自ドメイン: 自分で持っているドメイン(
example.comなど)を Project に紐づけ
独自ドメインを使うときは、ドメインの管理画面(お名前.com、Cloudflareなど)で Aレコード/CNAMEレコード、またはネームサーバー を変更します。DNS の話なので、ドメイン移管そのものとは別物です。ドメイン移管で失敗しやすいポイントは? も区別して読むと混乱しません。
6. Environment Variables(環境変数)
APIキー、DB接続情報、外部サービストークンなど、「コードに直書きしたくない値」を保管する場所です。
Vercel では環境変数を Production / Preview / Development の3環境別に設定できる のが大きな特徴です。
のように分けて設定し、コード側はキー名(DATABASE_URL)で参照します。Vercel CLIで vercel env pull するとローカルに .env.local 形式で取得できるので、PCを換えても再設定が楽です。
7. プラン(Hobby / Pro / Enterprise)
無料で個人開発を始めるなら Hobby、商用で使うなら Pro、企業の本格利用は Enterprise、というのが基本です。
| プラン | 月額 | 主な制限 | 主な対象 |
|---|---|---|---|
| Hobby | 無料 | 商用利用不可、メンバー1人、使用量に上限(超過分の購入不可) | 個人開発、学習、ポートフォリオ |
| Pro | $20/メンバー | 商用利用OK、使用量上限が大きく超過分も購入可 | スタートアップ、小〜中規模商用 |
| Enterprise | 個別見積 | SLA、SSO、専用サポート、本番ドメインの保護など | 大企業、規制業界 |
ここで一番事故が多いのが「商用利用の線引き」です。Vercelの定義では 「制作に関わった誰か(コードを書いた有給の従業員や受託の開発者を含む)の金銭的利益のためのデプロイ」はすべて商用利用 とされ、ProまたはEnterpriseが必要です。静的なサイトでも、それが自分の商売を宣伝するものなら商用扱いです。この線引きの具体的な落とし穴は後半の「ありがちな勘違い」で詳しく扱います。
ダッシュボードでよく見るメニュー
ここまでの用語が分かると、ダッシュボードもかなり読みやすくなります。最初に開くと出てくる主要メニューはこんな感じです。
| メニュー | 何を見られる |
|---|---|
| Overview | 直近のDeployment、サマリー |
| Deployments | 過去のDeployment一覧、ステータス、ログ |
| Analytics | アクセス数、流入元、ページごとの数値 |
| Speed Insights | Core Web Vitalsなどの体感速度指標 |
| Logs | Functionの実行ログ、エラー |
| Settings | Project全体の設定(Domains、Environment Variables、Deployment Protection、Build、Membersなど) |
「デプロイがうまくいかない」ときは Deployments のログ、「本番が遅い」ときは Speed Insights、「Functionがエラー」のときは Logs、と見るところが分かれているのがポイントです。そして見落とされがちなのが Settings の中の Deployment Protection で、ここを一度も開かないまま公開してしまうのが後述の漏えい事故の典型です。
ありがちな勘違い(と、実際に踏む失敗)
ここからがこの記事の本題です。用語を覚えただけでは防げない、初心者が実務で実際に踏む失敗を、現象→原因→確認手順→回避の形で具体化します。
1. Project = ドメインだと思ってしまう
Projectは「アプリ本体」であって「ドメイン」ではありません。1つのProjectに複数のDomainを紐づけることもできますし、Domainを持たない vercel.app 配信のままでもProjectとして成立します。
2. Deploymentは履歴ではなく「今見ているもの」だと思ってしまう
「今のmain」に見えているDeploymentは、「Production Deployment として現在割り当てられているもの」です。過去のDeploymentもURL付きで残っていて、Deployments一覧から「Promote to Production」で簡単にロールバックできます。リリースとデプロイの違いは リリースとデプロイの違いは?コードを置くこととユーザーに出すことを整理 も合わせて読むと整理しやすいです。
3. Edge Functionなら何でも速い、と思って詰まる(DBドライバが動かない)
これが新規で一番多い詰まりです。Edge Runtimeは Node.jsでもブラウザでもない、Web標準API中心の限定ランタイムです。「速いから」と何も考えずに export const runtime = 'edge'; を付けたり、Next.jsのMiddleware(middleware.ts)に普通のライブラリを読み込んだりすると、ビルドや実行時に止まります。
現象
デプロイや起動時にエラーで落ちる。典型的な文言は The edge runtime does not support Node.js 'crypto' module や A Node.js API is used (...) which is not supported in the Edge Runtime。Prismaを使っていると The Edge Function "..." is referencing unsupported modules: - .prisma のような形で出ます。
原因
Edge Runtimeでは require が使えず(import のみ)、ファイルシステムも読み書きできず、多くのDBドライバ(従来のTCP接続を張るもの)やネイティブNode.jsモジュールに依存したパッケージが動きません。「速い」の正体は、この制約と引き換えに軽量化されている点にあります。
確認手順
該当ファイルに runtime = 'edge' や config.runtime 指定が無いか確認します。Middlewareは初期状態でEdge寄りに動くため、そこにDB処理を書いていないかも見ます。エラー文中に出るモジュール名(crypto や .prisma など)が、Edgeで非対応のものか公式の対応表で照合します。
回避
DB接続や既存ライブラリを使う処理は runtime = 'nodejs'(デフォルト)に戻すのが基本。前述のとおりEdge Runtime自体が非推奨なので、迷ったらNode.jsで揃えて問題ありません。どうしてもEdgeで使いたい場合は、HTTP経由でアクセスできるエッジ対応のドライバ(各DBが提供するサーバーレス向けクライアント)に差し替えます。
加えてEdge Runtimeにはコードサイズ上限があり、gzip後で Hobby 1MB / Pro 2MB / Enterprise 4MB です。重いライブラリを読み込むとこの壁にも当たります。
4. Hobbyのまま商用運用して規約違反になる
「動いているからこのままでいい」が一番危ない判断です。Hobbyは 個人の非商用利用 専用で、商用にあたるデプロイはすべてPro以上が必要です。問題は「商用」の範囲が思ったより広いことです。
現象
個人開発のつもりのサイトが、ある日Vercelから商用利用にあたる旨の通知を受ける、もしくは利用が制限される。AdSenseやアフィリエイトで少額でも収益が出ている、フリーランスとして受託したサイトをHobbyで上げている、といったケースで起きます。
原因
Vercelの定義では「制作に関わった誰かの金銭的利益のためのデプロイ」が商用です。報酬を受け取って書いたコードや、自分の事業を宣伝する静的サイトも対象。「無料の趣味アプリ」のつもりでも、収益化や受託が絡んだ瞬間にHobbyの枠を外れます。
確認手順
そのProjectに「誰かがお金を受け取る要素」が一つでもあるかを点検します。広告・課金・アフィリエイト・問い合わせ獲得目的のLP・受託案件のいずれかに当てはまれば商用です。判断に迷う場合はVercelのFair Use GuidelinesとTerms of Serviceの最新版を確認します。
回避
商用要素が出る前にProへ切り替える(メンバーあたり$20/月)。「収益化したら上げる」ではなく「収益化を試す前に上げておく」方が、停止リスクも超過時の購入可否の面でも安全です。学習・ポートフォリオ・完全無料の個人アプリはHobbyのままで問題ありません。
5. Preview保護を設定し忘れて、非公開のはずのページが漏れる
これは見落とすと実害が大きい事故です。Preview Deploymentは「ブランチごとに生える確認URL」ですが、初期状態では保護が掛かっておらず、URLを知っていれば誰でも閲覧できます。社内確認用・公開前の新機能・取引先向けのドラフトなどを、保護を入れずにPreviewへ上げると、URLの推測や共有経由で外部に見えてしまう恐れがあります。
現象
「PR用に上げただけ」の未公開ページが、検索やリンク共有を経由して関係者以外に閲覧される。リリース前の価格やキャンペーン、未発表機能が外に出てしまう。
原因
Previewは「URLを知らなければ大丈夫」と思われがちですが、URLが秘密になる保証はありません。Deployment Protectionを有効にしない限り、Preview URLは認証なしで開けます。
確認手順
Settings → Deployment Protection を開き、Vercel Authentication(Standard Protection)がオンになっているか確認します。Standard Protectionは全プラン(Hobbyを含む)で有効化でき、Previewと各Deployment URLを保護します。なお本番ドメイン自体まで認証で守る運用はPro / Enterprise向けです。
6. Preview = ステージングと完全に同じ意味だと思ってしまう
Preview Deploymentは「ブランチ単位で生える確認URL」です。従来のステージング環境のように「常に同じURL」「常に同じデータ」というわけではなく、ブランチごとに別物が立ちます。固定URLでの確認や常設の検証環境が欲しい場合は、運用ルールやドメイン割り当て、上記のDeployment Protectionと組み合わせて設計する必要があります。
あとで覚えればよい用語
最初は知らなくても困らない、けれど中規模以降で出てくる用語をまとめておきます。
| 用語 | ざっくり何か |
|---|---|
| ISR | Incremental Static Regeneration。一定時間ごとに再生成する静的ページ |
| Edge Config | グローバルに配信される高速な設定値ストア |
| Cron Jobs | 定期実行(時間割で動かしたい処理) |
| Webhooks | 別サービスにイベント通知 |
| Vercel KV / Postgres / Blob | Vercelが提供するDB / KVS / ストレージ |
| Image Optimization | 画像の自動リサイズ、WebP変換 |
| Deployment Protection | Preview等の閲覧制限(上で扱った重要設定) |
| Speed Insights | Core Web Vitals 計測 |
| Web Analytics | プライバシー配慮のアクセス解析 |
| Team | 複数人での共同作業設定 |
これらは「必要になってから公式ドキュメントを引く」で十分です。最初から全部覚えようとすると、本来やりたいアプリ開発が止まります。
学ぶ順番のおすすめ
最後に、初心者が「何から触っていけば良いか」の順番を1つだけ示します。
この順で触ると、Project / Deployment / Environment / Function / Domain / Environment Variables の関係が手を動かしながら自然に体に入ります。5番目のDeployment Protectionを早めに体験しておくと、前述の漏えい事故をそもそも踏まなくなります。
まとめ
Vercelの基礎は、機能の数ではなく 用語の関係 で整理すると一気に分かりやすくなります。
最初に押さえるべきはこの順番です。
- Project / Deployment / Environment(全体の骨組み)
- Function(動的処理の置き場。新規はNode.js Runtimeが基本)
- Domain(公開の入口)
- Environment Variables(秘密情報の置き場)
- プラン(無料の範囲と商用の境目)
そのうえで、用語を覚えただけでは防げない3つの実害 — Edge Runtimeで crypto やDBドライバが動かない、Hobbyのまま商用運用して規約違反になる、Preview保護を入れ忘れて非公開が漏れる — を先に知っておくと、最初の数週間の事故をまとめて避けられます。
ISRやEdge Config、Cron Jobsは便利ですが、必要が出てから読むでまったく問題ありません。最初からすべての用語を完璧に覚えようとせず、今動かしているアプリの中でどの言葉が出てきたかを起点に少しずつ広げていくのが、結果的に一番早い学び方になります。
Vercel基礎用語に関するよくある質問
Q. ProjectとDeploymentの違いを一言で言うと?
A. Project = アプリ本体、Deployment = そのアプリの1回ぶんの公開結果。Project は固定、Deployment は履歴、という関係です。
Q. Production と Preview の使い分けは?
A. Productionは本番ブランチに紐づく1つの環境、Previewはブランチやプルリクエストごとに毎回生える確認用環境です。常時1つあるのが Production、頻繁に増減するのが Preview、と覚えると自然です。Previewは保護を入れない限り公開状態なので、非公開確認に使うときはDeployment Protectionをオンにします。
Q. Edge Function と Node.js、最初はどっちを使うべき?
A. 迷ったらNode.js Runtime(デフォルト)です。Edge Runtimeは2026年時点で非推奨扱いになっており、DBドライバや既存ライブラリが動かない制約に当たりやすいためです。Edgeは軽量な処理に絞って、必要になってから検討すれば十分です。
Q. Edgeで「The edge runtime does not support Node.js 'crypto' module」と出ます
A. Edge RuntimeがNode.jsの一部APIに非対応なために出るエラーです。該当ファイルの runtime = 'edge' 指定を nodejs に戻すか、Middlewareにそのモジュール依存の処理を書かないようにします。Prismaなどでは referencing unsupported modules: .prisma という形で出ることもあり、対処は同じくNode.js Runtimeへ寄せるのが基本です。
Q. Hobbyプランで個人開発の収益化(AdSense、アフィリエイト)はOK?
A. 商用扱いになります。Vercelは「制作に関わった誰かの金銭的利益のためのデプロイ」を商用と定義しており、広告・アフィリエイト・受託・自社宣伝の静的サイトはいずれもPro以上が必要です。収益化を試す前にPro($20/メンバー/月)へ切り替えるのが安全です。完全に無料の趣味アプリや学習用はHobbyで問題ありません。
Q. Preview URLは関係者しか見られない?
A. いいえ。初期状態のPreviewはURLを知っていれば誰でも開けます。非公開で確認したい場合はSettings → Deployment Protectionで Vercel Authentication(Standard Protection)を有効にします。これは全プランで利用でき、PreviewとDeployment URLを保護します。本番ドメインそのものを認証で守る運用はPro / Enterprise向けです。
Q. デプロイが失敗したときはどこを見る?
A. Deployments → 失敗したデプロイをクリック → Build Logs。エラーメッセージはほぼここに出ています。どのコマンドで・どの行で失敗したかをログから読み取り、ローカル環境で再現してから直すのが安全です。
参考リンク
- Vercel: Documentation
- Vercel: Projects
- Vercel: Deployments
- Vercel: Functions / Edge Runtime
- Vercel: Environment Variables
- Vercel: Deployment Protection
- Vercel: Fair Use Guidelines
- Vercel: Pricing