Vercel Blobのストア数上限が全プランで撤廃。ストアを分ける判断基準と実装時の注意点
2026年9月23日、VercelはVercel Blobのストア作成数の上限を全プランで撤廃しました。これまでのHobby 100、Pro 500、Enterprise 1,000という制限はなくなり、必要なだけストアを作れます。代わりに、ストアの作成が「Advanced Operations」1回としてほかの使用量と一緒に課金されます。削除は無料です。
コスト面のインパクトはほぼ無視できる水準です。したがって実務で考えるべきは「いくつまで作れるか」ではなく、パス(pathname)の命名規約で足りるのか、ストアという硬い境界が必要なのかという設計判断に移りました。
何が変わり、何が変わっていないか
変わったのは3点です。ストア数の上限が全プランで撤廃されたこと、ストア作成が課金対象のAdvanced Operationになったこと、作成回数が使用量ページとObservabilityダッシュボードのBlob Advanced Operationsに表示されるようになったことです。
変わっていない点のほうが重要です。ストレージ容量・オペレーション・データ転送はこれまで通り使った分だけの従量課金で、同じデータを複数のストアに分割しても合計コストは変わりません。つまりストアを分ける動機は、コスト最適化ではなく分離にあります。
ストア作成のコストを具体的に見積もる
Advanced Operationsは、Proで100万回あたり$5.00です。ストアを1,000個作っても$0.005相当にしかなりません。Proでは月額クレジットから消費され、超過分がオンデマンド課金になります。
注意が必要なのはHobbyです。Advanced Operationsの無料枠は月2,000回で、ここにはput()・copy()・list()に加えてダッシュボードでのブラウズやアップロード操作も計上されます。個人開発でストアを量産すると、ファイル操作に使える枠を圧迫します。ストア作成そのものより、作成後に走るlist()やput()の回数のほうが枠を消費しやすい点も押さえておくべきです。
金額よりも現実的な制約はレート制限です。Advanced Operationsの上限はHobbyが900回/分、Proが4,500回/分、Enterpriseが7,500回/分です。ユーザー登録と同時にストアを同期作成する設計は、バースト時にここで詰まります。作成処理はキューに逃がすか、初回アップロード時の遅延生成にするのが安全です。
ストアを分けるか、パス規約で済ませるか
ストアを分ける価値があるのは、次のいずれかに該当する場合です。
- 資格情報の境界が欲しい:本番・ステージング・プレビューでそれぞれ別のストアを持たせれば、あるプロジェクトの資格情報で他環境のデータに触れる経路がなくなります
- 削除・エクスポートの単位を揃えたい:マルチテナントで1テナント分のデータを一括削除・書き出しする要件があるなら、ストアごと消せる構造は運用コストを大きく下げます
- リージョンやアクセスモードを分けたい:公開アセットと非公開ドキュメントを混在させない、データ所在地の要件を満たす、といったケースです
一方で、単に画像の種類を整理したい程度であればimages/のようなプレフィックスで十分です。ストアを増やすと、テナントIDとストアIDのマッピング管理、使用量の横断集計、プロジェクトへの接続作業といった運用の手間が増えます。list()はストアをまたげないため、「全テナント横断で古いファイルを棚卸しする」ような処理はストア数ぶんのループになります。
設計上、後戻りできない点が2つあります。アクセスモード(public/private)とリージョンは作成後に変更できません。ストアを分ける方針にするなら、この2つは最初に決め切っておく必要があります。
テナントごとにストアを作る場合の実装上の注意
ストアはCLIのvercel blob create-store <名前> --access public|private、またはREST APIのPOST /storage/stores/blobで作成できます。動的に増やす設計では、以下の点が実装の分かれ目になります。
- ストアIDを環境変数で持たない:環境変数はプロジェクトの1環境あたり1,000個が上限です。テナント数に比例して増える値は、アプリケーション側のデータベースにテナントID→ストアIDとして保持します
- 認証方式を先に決める:プロジェクトに接続したストアはOIDC(短命トークンの自動発行・自動更新)がデフォルトで、
BLOB_STORE_IDとVERCEL_OIDC_TOKENをSDKが自動で読みます。動的なストアではSDKのstoreIdオプションで対象を指定しますが、oidcTokenを自前で渡すと自動更新が効かず、期限切れ後に403で失敗します - ブラウザ直アップロードは別扱い:
handleUploadによるクライアントアップロードのトークン署名にはOIDCが使えず、read-writeトークンが必要です。テナント別ストアとクライアントアップロードを併用する構成では、ここが最も設計が崩れやすい箇所です - 認可チェックを省かない:ストアが物理的に分かれていても、どのテナントのストアに書き込むかを決めるのはアプリケーションのコードです。セッション検証をアップロード経路の手前に必ず置きます
プレビュー環境と移行作業での使いどころ
上限撤廃でいちばん導入しやすいのは、使い捨てのストアです。プレビューブランチやデータ移行のために一時ストアを立て、終わったら削除する。削除は無料なので、残置コストはストレージ課金だけです。移行時は旧ストアと新ストアを並走させ、切り替え後に旧ストアを消す手順が取れます。
ただしプレビュー用ストアも、アクセスモードとリージョンは本番と揃えておかないと挙動の差が検証に現れません。作成数や操作数はObservabilityのBlobセクションで確認できるので、一時ストアの作りっぱなしが増えていないかは定期的に見ておくとよいでしょう。
まず確認すべきこと
すでにVercel Blobを使っているなら、次の順で見直すのが実務的です。第一に、本番とプレビューが同じストアを共有していないか。共有しているなら、環境ごとの分離が今回の変更でいちばん低コストに実現できる改善です。第二に、マルチテナント構成でテナントのデータ削除依頼にプレフィックス走査で対応していないか。第三に、Hobbyで運用しているなら月2,000回のAdvanced Operations枠に対して、ダッシュボード操作を含めた実使用がどの程度かを使用量ページで確認することです。
ストア分割は「増やせるから増やす」ものではなく、資格情報とライフサイクルの境界をどこに引くかの判断です。既存のNext.jsアプリケーションでのマルチテナント設計やストレージ構成の見直しでお困りの際は、お問い合わせからchot Inc.までご相談ください。
