Webサイトは、公開して終わりではありません。お知らせの追加、デザインの調整、ライブラリの更新、フォームの修正など、公開後も小さな変更を重ねていきます。
最近はAIによる実装支援が広がり、コードの変更やプレビュー環境の作成を短いサイクルで繰り返しやすくなりました。変更を素早く確認できる一方で、デプロイ履歴も増えていきます。

そうした中、Vercelは2026年10月9日、Proプランのデプロイ保存期間とストレージ課金について変更を発表しました。
この記事では、何が変わるのかを整理したうえで、企業サイトやJamstackサイトの保守運用で確認したいポイントを考えます。

2026年10月のVercel Pro変更点

Proチームの標準保存期間は30日に

公式発表によると、新しく作成するProチームでは、デプロイ履歴の保存期間が標準で30日になりました。必要に応じて、チーム設定からより長い保存期間を選ぶこともできます。

既存のProチームについても、保存期間は30日に変更されます。2026年10月23日から、30日を超えたデプロイが順次削除される予定です。長い履歴を残したい場合は、それまでに保存ポリシーの設定で変更を適用しない（オプトアウトする）必要があります。すでに30日以下の設定を使っている場合、その設定は変わりません。

なお、これは「すべてのデプロイが一律30日で必ず消える」という意味ではありません。保存ポリシーはProduction、Preview、Canceled、Erroredごとに設定でき、直近の本番デプロイや現在公開中のデプロイのように保護される対象もあります。実際の保持状況は、チーム・プロジェクトの設定と公式ドキュメントで確認してください。

ストレージ課金も確認が必要

あわせて、ProチームのDeployment StorageとFunctions Storageについて、それぞれ1GB・1か月あたり0.10米ドルの課金が案内されています。

既存Proチームの課金開始日は、各チームに届く案内メールで確認するよう説明されています。10月23日は古いデプロイの削除開始予定日であり、すべてのチームの課金開始日と同じとは限りません。

保守費用を考えるときは、月々の基本料金だけでなく、何をどれだけ保存しているかも把握しておきたいところです。

なぜWebサイトの保守に関係するのか

過去の状態へ戻す選択肢が減る可能性がある

本番公開後に表示崩れや不具合が見つかった場合、以前のデプロイに切り戻す方法があります。Vercelにも、過去の本番デプロイへ戻すInstant Rollbackの仕組みがあります。

ただし、削除済みのデプロイは復元できず、ロールバック先としても利用できません。必要な履歴が残っていなければ、Gitの過去コミットから再ビルドするなど、別の復旧手段が必要になります。

ここで注意したいのは、Gitの履歴が残っていることと、当時のデプロイをそのまま復元できることは同じではない点です。依存パッケージ、環境変数、外部API、CMSのデータなどが変わっていれば、同じコードをビルドしても完全に同じ状態になるとは限りません。

プレビューURLを長期保管の代わりにしない

制作中は、確認用のプレビューURLをクライアントに共有することがあります。しかし、そのURLが何か月後も必ず見られるとは限りません。

「半年前のデザインと比較したい」「以前の確認画面を見直したい」という要望が想定されるなら、プレビュー環境とは別に、承認済みの画面キャプチャ、デザインデータ、変更履歴などを保管しておくと安心です。
プレビューURLは確認のための手段であり、恒久的な成果物の保管庫とは分けて考えたいところです。

運用担当者が確認したい4つのこと

1. 保存ポリシーと適用日を確認する

まずはVercelのチーム設定・プロジェクト設定で、Production、Preview、Canceled、Erroredそれぞれのデプロイ保存期間を確認します。既存Proチームなら、課金開始日の案内メールも確認しておきましょう。

必要な履歴を何日分残したいかは、障害対応やクライアントの確認サイクルから決めます。単純に長くすればよいわけではなく、保存コストとのバランスが必要です。

2. 障害時の戻し方を決めておく

障害が起きてから復旧手順を調べるのではなく、通常時に「誰が判断し、何を確認して、どう戻すか」を整理しておきます。

直前の本番デプロイへのロールバックで済むのか。CMSで公開した内容も戻す必要があるのか。外部サービスの設定変更を伴うのか。これらは別の問題です。
少なくとも、本番公開後の動作確認、ロールバックの担当者、復旧後の再確認項目は決めておきたいところです。

3. デプロイを増やすだけでなく、品質確認を自動化する

AIで実装が速くなると、小さな修正を何度もデプロイしやすくなります。しかし、デプロイ回数が増えること自体が品質向上を意味するわけではありません。

型チェック、Lint、テスト、必要に応じたVRT（画面差分の検証）などをCIに組み込み、公開前に検出できる問題を減らすことが重要です。
人が確認すべき仕様や使い勝手と、機械で検出できる不具合を分ける。これは、ブラキオが重視するFrontend Opsの考え方にもつながります。

4. ストレージ使用量と不要な成果物を見直す

Vercelの公式案内では、不要なビルドファイルの削減、大きなアセットの保管場所の見直し、Functionバンドルの縮小などが、ストレージ使用量を抑える方法として挙げられています。使用量はプロジェクトごとにUsageページで確認できます。

ただし、必要な復旧履歴まで削ってしまっては本末転倒です。先に保守要件を決め、そのうえで削減できるものを整理する順番がよいでしょう。

Jamstackでも「静的だから保守不要」ではない

Next.jsとヘッドレスCMSを使った企業サイトでは、静的にページを生成する構成を選ぶことがあります。静的配信は運用上の利点がありますが、デプロイ履歴の保存、CMSコンテンツの管理、依存関係の更新、障害時の復旧まで自動的に解決するわけではありません。

とくに企業サイトでは、制作担当者が変わったあとも運用が続きます。担当者が交代しても復旧できるように、リポジトリ、公開手順、権限、監視、バックアップ対象を整理しておくことが大切です。

まとめ：保存期間の変更を、保守の見直しにつなげる

今回のVercel Proの変更は、料金だけを見て終わらせる話ではありません。
確認したいのは、どの履歴を残す必要があるか、問題が起きたらどこまで戻せるか、その判断と作業を誰が担当するかという点です。

AIを使って制作を速くできる時代だからこそ、公開後の運用まで含めた設計が重要になります。サイトを安全に更新し続けるために、デプロイの保存設定と復旧手順を一度見直してみてはいかがでしょうか。

「自社サイトのVercel設定がどうなっているか分からない」「障害時の戻し方を整理したい」といったお悩みがあれば、株式会社ブラキオにご相談ください。公開後の運用・保守まで含めてサポートします。

参考情報

• Vercel公式：Deployment Storage billing begins for existing Pro teams（2026年10月9日）
• Vercel公式：New Pro teams now default to 30-day deployment retention（2026年10月9日）
• Vercel公式：Deployment Retention
• Vercel公式：Performing an Instant Rollback on a Deployment

※記事内の仕様・料金は2026年10月13日時点の公式発表に基づきます。最新の内容はVercel公式ドキュメントをご確認ください。