Vercelのコード サンドボックスが64 GBに──大規模ジョブはどう変わる？

今回の価値は、「64 GB」という数字だけにあるわけではありません。これまでVercel Sandboxの32 GB上限にぶつかっていたリポジトリジョブを、削減・分割したり別の環境へ移したりせず、ひとつのコード サンドボックス内で完了できる可能性が高まったことです。

2026年9月11日、VercelはすべてのSandboxで標準の作業ストレージを32 GBから64 GBへ倍増しました。

コード サンドボックスの作業領域が倍増

Vercel Sandboxは、独自のカーネル、ファイルシステム、ネットワークを備えた小型仮想マシンであり、隔離されたLinux microVMです。リポジトリを渡し、エージェントにコードを編集させ、パッケージをインストールし、テストとビルドを実行して、最後に成果物を取り出せます。

これらの工程は、すべて同じローカルディスクを使います。依存関係ツリーを展開した時点でも、チェックアウト済みのリポジトリは残っています。ビルドキャッシュやコンパイル済みの出力が、一時ファイルと同時に存在することもあります。完成した成果物が小さくても、生成途中では一時的にそれを大きく上回る容量が必要になり得ます。

今回変わったのは、このピーク時の上限です。VercelはSandboxの作業ストレージを32 GBから64 GBへ拡張しました。従来より32 GB増え、容量は倍になります。対象は、Vercel Managed Image、カスタムイメージ、非推奨のruntimeプロパティから作成したSandboxです。

これはSandbox内部の作業容量であり、データベースやオブジェクトストレージの新たな割り当てではありません。Vercelはこれを一時的なNVMeストレージと説明しています。ジョブ終了後もファイルを残す必要があるなら、永続化は引き続き別に判断しなければなりません。

判断基準は、ジョブ全体がひとつの環境に収まるか

本当に問うべきなのは「Vercelのディスク上限はいくつか」ではなく、「このジョブ全体を、特別な削減や受け渡しなしでひとつのSandbox内に収められるか」です。

作業領域は、次の式で見積もれます。

作業領域のピーク = リポジトリとチェックアウト + インストール済み依存関係 + ビルド成果物 + 一時データの最大量

ジョブの実行中に最大使用量を測ってください。最終的なzipファイルの大きさから推測してはいけません。パッケージの展開、コンパイル、テストフィクスチャ、ブラウザバイナリ、キャッシュ、ディスクへ退避したデータが重なるのは数分だけかもしれませんが、その数分で処理を完了できるかが決まります。

Vercelの現在の料金とクォータでは、ストレージ層ごとに予算項目が分かれています。

この違いを押さえると、コスト計算も変わります。作業ディスクが倍になっても、コンピュート単価まで倍になるわけではありません。Vercelが現在示しているiad1の例では、4 vCPUsと8 GBのメモリを使い、CPUをフル稼働させる30分間のビルド・テスト実行は約$0.34です。

ジョブが長時間動いたり、より多くのCPUやメモリを必要としたりすれば、大規模なジョブのコストは上がり得ます。パッケージ、リポジトリ、成果物、データセットなどのダウンロードは無料ですが、Sandbox外へ送信するデータには料金がかかります。

追加ファイルが新たなストレージ料金につながるのは、永続化する場合です。新たに使えるようになった32 GBをすべて使用し、そのまま丸ひと月保持したなら、料金表に基づく計算は、スナップショットひとつにつき32 × $0.08 = $2.56となります。これは試算であり、自動的に発生する料金ではありません。結果を外へ書き出して作業領域を破棄する非永続の実行なら、このスナップショット料金を避けられます。

容量拡大の恩恵を受けるケース

大規模モノレポを扱うスタッフエンジニア

リポジトリ、依存関係グラフ、ビルド出力を以前の上限内に同居させられず、パッケージを間引く、テストフィクスチャを削除する、ビルドを分割するといった対応を続けているスタッフエンジニアもいるでしょう。

実測したピークが64 GBのファイルシステムに収まるなら、チェックアウト、インストール、テスト、ビルドをひとつのジョブへ戻せます。運用上の利点は、受け渡しと部分的な成果物が減り、ビルド失敗時の再試行ポイントを一本化できることです。

だからといって、Vercelが自動的に最適なSandboxプロバイダーになるわけではありません。実行基盤を選定中なら、より広い視点で隔離と課金のトレードオフを扱うAIエージェント向けコードサンドボックス比較が参考になります。今回の変更で動くのは、Vercelのディスク境界だけです。

リポジトリ修復を動かすエージェント基盤エンジニア

コーディングエージェントは、作業を進めるほどストレージを消費しがちです。リポジトリをクローンし、ツールをインストールし、ファイルを変更し、テストスイートを実行して、結果をパッケージ化します。複数の手法を試すエージェントなら、キャッシュや中間出力も残ることがあります。

追加された32 GBにより、この一連の処理をひとつのSandbox内で完了できる余地が広がります。ディスク不足による再試行や、独自のクリーンアップツールをエージェントのワークフローから外せるかもしれません。ただし効果があるのは、失敗原因が本当にディスクだった場合です。メモリ、CPU、ネットワークポリシー、セッション時間がボトルネックなら、ファイルシステムを拡張しても改善しません。

変換処理の途中でディスクへ退避するデータエンジニア

データエンジニアは、ダウンロードしたデータの並べ替え、結合、展開を行う際に、ローカルファイルシステムを一時領域として使えます。ディスクが広がれば、早い段階で処理を分割したりリモートストレージをマウントしたりせず、一時データをローカルに保てる可能性があります。

それでも、出力をどう持ち出すかは決めておく必要があります。残すべき結果は外部へコピーするか、適切なオブジェクトストアへ書き込むか、後の実行でも同じディレクトリが必要ならDriveをマウントします。64 GBの一時ディスクが役立つのは、処理後に破棄できるからです。これを永続ストレージとして扱うと、役割も料金も異なるものを混同してしまいます。

runtimeをまだ使っているチーム

9月11日のリリースでは、非推奨のruntimeプロパティで設定されたSandboxも明確に対象に含まれています。既存コードでも、イメージを移行せずにディスク容量が増えるはずです。

それでも、現在のプラットフォームが向かっているのはイメージです。Sandbox SDKのバージョン3以降、runtimeもimageも指定しないSandboxではvercel/sandbox/universal:latestが使われます。Managedイメージは毎晩更新され、再現可能なビルドが重要ならダイジェストを固定することで不変の環境を使えます。

ワークフローを変える前に、代表的なジョブを測る

今回のリリースで上限は緩和されましたが、自社のイメージとジョブが実際に使える容量までは分かりません。クリーンアップ処理を削除したり、分割ビルドを再び統合したりする前に、実際のジョブをひとつ測定してください。

1. 1

   判断材料になるジョブを選ぶ

   最近ディスク不足になったジョブ、または以前の上限を超えないためだけに分割しているジョブをひとつ選びます。本番と同じリポジトリ、ロックファイル、ビルドコマンド、入力データを使ってください。小さなサンプルリポジトリでは、事業上の判断材料になりません。

2. 2

   イメージベースの新しいSandboxを起動する

   現在のCLIとイメージを使う方法なら、結果を再現しやすくなります。次の手順は、Vercelが文書化しているSandbox CLIの流れに沿い、永続化を無効にしています。そのため、測定でスナップショットが自動作成されることはありません。

   npm i -g sandbox
   sandbox login
   sandbox create --name workspace-check --image vercel/sandbox/node:24 --timeout 30m --non-persistent
   
   tar -czf app.tgz -C ./my-app .
   sandbox copy ./app.tgz workspace-check:/tmp/app.tgz
   sandbox exec workspace-check -- sh -c "mkdir -p /app && tar -xzf /tmp/app.tgz -C /app"

3. 3

   ストレージ使用量を工程ごとに記録する

   チェックアウト後、依存関係のインストール後、可能ならビルドで最も容量を使う最中、そして成果物の完成後にディスクを確認します。.nextとdistは、実際のプロジェクトが出力するパスに置き換えてください。

   sandbox exec --workdir /app workspace-check -- sh -lc 'df -h /; du -sh .git node_modules .next dist /tmp 2>/dev/null || true'
   
   sandbox exec --workdir /app workspace-check -- npm install
   sandbox exec --workdir /app workspace-check -- sh -lc 'df -h /; du -sh .git node_modules .next dist /tmp 2>/dev/null || true'
   
   sandbox exec --workdir /app workspace-check -- npm run build
   sandbox exec --workdir /app workspace-check -- sh -lc 'df -h /; du -sh .git node_modules .next dist /tmp 2>/dev/null || true'

   df -h /を見れば、Sandboxにどれだけ空きが残っているか分かります。duの各行からは、作業領域のどの部分が容量を使っているかを確認できます。完成後だけを見ても、ピークを取り逃す可能性があります。

4. 4

   従来の回避策を外して一度だけ再試行する

   実測した最大使用量が表示された空き容量に収まるなら、依存関係の削減や分割ビルドの受け渡しを外し、同じジョブをもう一度実行します。成功したかどうか、経過時間、Active CPU、割り当てメモリ、転送量、スナップショットやDriveストレージが作成されたかを記録し、その後Sandboxを停止します。

   sandbox stop workspace-check

容量が増えても変わらない限界

ディスクが増えても、メモリ、CPU、時間は増えません。Sandboxセッションの標準時間は引き続き5分です。Hobbyのセッションは最大45分、ProとEnterpriseは最大24時間まで実行できます。

また、64 GB未満のあらゆるワークロードが問題なく収まると保証されたわけでもありません。起動時のイメージがファイルシステムの一部を使い、Vercelが毎晩更新するローリングイメージタグによって使用量が変わる可能性もあります。起動後に実際の空き容量を確認してください。同じビルドを毎回同じ環境から始める必要があるなら、イメージのダイジェストを固定します。

耐久性のある共有データが必要なら、Driveなどの永続ストアを使います。Sandboxが示す作業容量を超えるなら、分割を維持する、大規模な一時データをマウント済みストレージへ移す、別の環境で実行する、という選択肢があります。新しい上限が変えるのは判断の境界であり、選択肢そのものではありません。

月曜日に実行すること

実際のリポジトリ、エージェント、データ処理が以前のディスク上限で失敗した、あるいはその上限を避ける目的だけでクリーンアップ処理を抱えているなら、今週中に動く価値があります。ピークを測っていないなら、まず待つべきです。推測で機能している分割を外しても、次の失敗を先送りするだけです。すでに以前の容量を十分下回っているジョブや、本当のボトルネックがCPU、メモリ、ネットワークアクセス、セッション時間、永続ストレージにあるジョブには影響しません。

月曜日には、代表的なジョブをひとつ選び、新しい64 GBのイメージベースSandboxで上記の測定を行い、従来のストレージ回避策を外して一度だけ再実行してください。実測したジョブが完了し、コンピュートと永続化を合わせた料金にも納得できる場合に限って、より単純な単一ジョブ構成を残します。

運用判断を変えるアップデートを平易に読み解く記事は、ニュースレターでお届けしています。