Vercel 料金の盲点：Hobbyのプレビューは30日以内でも消える

Vercel 料金を検討するうえで、Hobbyのデプロイ履歴が30日間は必ず残るという前提は、もう安全ではありません。2026年9月16日以降、HobbyチームがDeployment Storageの上限10GBを超えると、保持の例外に該当しない古いプレビューや本番環境のロールバック先は、ただちに削除される可能性があります。

現在稼働中の本番デプロイは、引き続き保護されます。条件を満たすエイリアスが付いたデプロイと、アクティブなGitブランチの最新プレビューも同様です。変更の対象は、これらの保護対象から外れたものです。そのため、個人用プロトタイプは動き続けているのに、以前のレビュー用リンクだけがいつの間にか開けなくなることがあります。

30日間は最低保証ではなくなりました

デプロイの保持ルールとは、各デプロイを構成するビルド済みファイルをVercelがどれだけの期間保存するかを決めるものです。保存されたファイルがあるからこそ、古いプレビューを再び開いたり、再ビルドせずに検証済みビルドを昇格させたり、障害時に本番環境をロールバックしたりできます。

Hobbyの通常の保持期間は、今も30日です。新たに加わったのは、上限超過時のクリーンアップルールです。チームのDeployment Storageが10GBを超えると、保護されていないデプロイは30日を待たずに削除対象になり得ます。今回の変更が実務に与える影響はここにあります。無料でデプロイ履歴を残せるかどうかは、ストレージ使用量と後述する例外条件の両方で決まるようになりました。

各Hobbyプロジェクトでは、直近のデプロイに対して次の2つの保護が適用されます。

• 種別を問わず、作成された最新3件のデプロイ
• Readyになった最新3件の本番デプロイ

これは6枠ではなく、2つの集合を合わせた1つの保護対象として考える必要があります。直近の本番デプロイは両方に含まれることがあります。最新3件のデプロイがすべて、Readyになった最新3件の本番リリースでもある場合、この2つのルールで保護されるのは同じ3件だけです。

プレビューデプロイ専用の「直近分」の枠は、すでにありません。最新3件から外れたプレビューは、別の例外条件を満たさない限り保持されません。

Vercelが引き続き保護するデプロイ

このルールは、デプロイの新しさで決まる保護と、デプロイの用途で決まる保護に分けると理解しやすくなります。

これらの例外は、Vercelの現行のデプロイ保持ルールに基づいています。デプロイURLを保存しただけでは、記載された保護条件のいずれにも該当しません。重要なのは、そのデプロイに結び付くエイリアス、ブランチ、本番環境としての状態、または履歴内での新しさです。

この違いは、よくあるワークフローにも影響します。誰かにプレビューを送り、プルリクエストをマージしたあとも、そのリンクは月末まで使えると思いがちです。しかし、ブランチがアクティブでなくなった時点で、最新プレビューとしての例外は終了します。チームがすでに10GBを超え、そのデプロイがどちらの最新3件にも入っていなければ、30日目を迎える前にリンク先が失われる可能性があります。

実際に影響を受けるのは誰か

もっとも分かりやすい例は、複数の個人用プロトタイプを持つ個人開発者です。古いプロジェクトがビルド成果物を保存し続ける一方で、稼働中のプロジェクトでは新しいデプロイが増えていきます。チーム全体の上限を超えると、VercelはそのHobbyチーム内の保護されていない履歴をクリーンアップできます。残しておきたいロールバック先が、最近触っていないプロジェクトのものでも例外ではありません。

非商用のコンセプトを共有するデザイナーには、別のリスクがあります。レビュー中のオープンなブランチにある最新プレビューは保護されますが、以前のデザイン判断で使った古いリンクは保護されない可能性があります。そのビルドを後から確実に確認できる状態にしておく必要があるなら、ブランチを閉じる前に、条件を満たすカスタムエイリアスを付けるか、別の保存方法を用意する必要があります。

デプロイ履歴をロールバック用の棚として使っているメンテナーは、直近の本番デプロイを確認すべきです。Readyになった最新3件の本番デプロイは保護されますが、それより古い既知の正常なリリースは、30日未満だからという理由だけでは安全とはいえません。

フリーランサー、制作会社、企業は、保持期間だけでアップグレードの要否を判断すべきではありません。Hobbyは個人の非商用利用に限定されています。商用案件は10GB未満でもProを利用する必要があるため、今回のデプロイ履歴の変更は、すでに存在するプラン選択の基準を改めて浮き彫りにしたものです。

10GB未満のHobbyチームは、新しい即時クリーンアップの対象ではありません。デプロイには、引き続き通常の30日間ポリシーとその例外が適用されます。ProとEnterpriseのチームも、今回のHobby固有の変更には該当しません。標準の保持期間も、保護される直近デプロイの件数も、Hobbyより多く設定されています。

残すべきデプロイ履歴を監査する

まずチーム単位で確認します。10GBの上限はHobbyチーム全体に適用されますが、判断に必要な情報は各プロジェクトに分散しているためです。

1. 1

   2つのストレージ指標を確認する

   Vercelで対象チームを選び、Usageを開いてからDeployment Storageを選択します。ビルド成果物と静的アセットを含むDeployment Storageと、関数バンドルを含むFunctions Storageの両方を確認してください。各指標のProjectsを開くと、保存データ量の多いプロジェクトを特定できます。

2. 2

   失えないデプロイを書き出す

   容量の大きいプロジェクトごとにDeploymentsを開きます。現在の本番デプロイ、実際にロールバック先として使う本番ビルド、レビューや承認フローでまだ使っているプレビューURL、監査やリグレッション確認に必要な古いビルドを記録してください。この一覧が要件です。デプロイフィードは、その候補を洗い出すための在庫表にすぎません。

3. 3

   残すデプロイを保護条件と照合する

   残す対象が、作成された最新3件、Readyになった最新3件の本番デプロイ、条件を満たすエイリアス付き、またはアクティブなブランチの最新プレビューのいずれに該当するか確認します。同じデプロイが両方に入っている場合、2つの最新3件グループを別々に数えてはいけません。

4. 4

   例外条件か、再現に必要なソースを守る

   最新プレビューが必要な間は、レビュー用ブランチをアクティブな状態に保ちます。ワークフローに合う場合は、必ず残したい本番以外のデプロイにカスタムエイリアスを付けます。それ以外は、再ビルドに必要なソースコミット、設定、外部データを、デプロイ履歴とは別の場所で確保してください。

5. 5

   役目のないストレージを減らす

   削除してよいものを担当者が確認したら、通常のリポジトリ運用に沿って、使われていないカスタムエイリアスを削除し、古いプルリクエストをクローズします。次に、容量がもっとも大きいデプロイのResources画面を確認し、肥大化した静的出力やFunctionバンドルを探します。Usageページで容量の大きいプロジェクトまでは特定できますが、合計容量の原因となっているファイル、デプロイ、バンドルまでは分かりません。

Vercelのストレージ最適化ガイドでは、変更の前後で、同じチーム、両方のストレージ指標、同じプロジェクト、同じ30日間を比較するよう勧めています。保持履歴のクリーンアップとビルド成果物の小型化は、別の問題を解決する施策です。前者は時間の経過とともに保存履歴を減らし、後者は新しいデプロイ自体を小さくします。

Vercel 料金はクリーンアップとProでどう変わるか

個人の非商用プロジェクトなら、クリーンアップはサブスクリプション費用がかからない選択肢です。現在の役目を終えた履歴を手放し、可能な範囲で出力サイズを減らし、Hobbyの上限内に収めます。その代わり、運用面では、確認できる古いプレビューや、ロールバックに使える本番ビルドが少なくなります。

Proは$0.10だけでアップグレードできるプランではありません。ProではDeployment StorageとFunctions Storageがそれぞれ1GB・1か月あたり$0.10と記載されているため、どちらか一方を10GB、1か月保持する料金は$1です。ただし、プランには月額**$20のプラットフォーム料金**があり、デプロイ権限を持つ1席と、毎月$20分のインフラ利用クレジットが含まれます。デプロイ権限を持つOwnerまたはMemberが増えるたびに、さらに1人あたり月額$20が加算されます。Viewer席は無料です。

したがって、判断基準は明快です。「履歴を削除する」と「ストレージ代として$1を払う」を比べるのではありません。クリーンアップと月額$20のプラン全体を比較し、そのうえで追加のデプロイ担当者を全員加算し、チームのストレージやその他のインフラ利用が付与クレジットで賄えるか確認します。請求額の残りの仕組みは、Vercel料金の詳しい内訳で解説しています。

個人用プロトタイプなら、月額$20は履歴を残す価値より高いかもしれません。商用案件では、保持ルールを検討する前に、プランの利用条件だけで答えが決まります。すでにProが必要な1人開発の事業なら、より長い標準保持期間と、より多い直近デプロイの保護も、支払っている料金に含まれる価値です。

次の営業日にやること

Hobbyチームが10GBを超えている、または上限に近い場合は、Usageページを開き、Deployment StorageとFunctions Storageを多く消費しているプロジェクトを特定します。次に、業務やレビューでまだ必要なプレビューリンクとロールバック先を具体的に選びます。必要なものは意図的に保護し、役目を終えた履歴は手放してください。

チームが10GBを十分に下回っているなら、緊急のクリーンアップは不要です。ただし通常の30日間ポリシーは意識しておきましょう。特に、誰かがまだ必要としているプレビューにひも付くブランチを閉じるときは注意が必要です。

商用プロジェクトなら、Hobbyのクリーンアップを長期的な運用策にするのはやめるべきです。Proの料金全体を予算に入れ、デプロイ権限は必要な人だけに付与し、それ以外の人には無料のViewer席を使います。その費用と、失われたレビュー環境やロールバック手順を再構築するコストを比べてください。

このような分かりやすい解説を週1回受け取るには、ニュースレターにご登録ください。