Vercel Sandbox Driveで作る永続クラウド開発環境：導入と検証ガイド

まず押さえるべき要点

Drive.getOrCreate()でDriveを一度作成し、Sandbox.create()の絶対マウントパス（/dataなど）に渡します。残したいファイルはすべて、そのパス以下に置きます。別のサンドボックスから読み書きする前に、最初のサンドボックスを停止してください。テストやレビューを並列実行する場合は、代わりにdrive.snapshot()をマウントします。各リーダーが見るのは固定された時点の状態であり、その後の書き込みは反映されません。

Driveは、1台のマシンに内蔵された大容量ディスクというより、取り外して使えるプロジェクトルームに近い存在です。サンドボックスは一時的に集まる作業員と作業場、Driveは作業員が退出しても残り、次の作業場へ接続できる施錠済みの保管室だと考えると分かりやすいでしょう。

Vercelは、エージェントのワークスペース、ディスク上のメモリ、依存関係ツリー、データセット、モデル、ビルド成果物をDriveの主な用途に挙げています。初期ユーザーからも、エージェントごとにDriveを用意することで、再接続時の依存関係の再インストールを省けたとの報告があります。検証すべき効果は、単なる容量の追加ではなく、セットアップ作業の削減です。

Vercel Sandbox Driveで永続クラウド開発環境を構築する

まずVercelプロジェクトを用意し、ローカル認証を設定します。Vercelはローカル開発にOIDCトークンを推奨しています。vercel env pullを実行すると、開発用トークンが.env.localに書き込まれます。このトークンの有効期限は12時間です。外部CIでは、代わりにチームID、プロジェクトID、アクセストークンを利用できます。

公開時点の安定版npmパッケージは@vercel/sandbox 3.5.0です。古いVercel SDKの説明には、まだプライベートベータと記され、ベータチャンネルの利用を勧めるものもあります。しかし、現在のDriveの概念ページと9月23日のリリース情報では、3つのプランすべてでパブリックベータとされています。

npm install @vercel/sandbox@3.5.0
npx vercel link
npx vercel env pull

次にDriveを作成してマウントし、目印となるファイルと小さなキャッシュを書き込みます。そのサンドボックスを停止したら、新しいサンドボックスから両方のファイルを読み取ります。

import { Drive, Sandbox } from '@vercel/sandbox';

const workspace = await Drive.getOrCreate({
  name: 'agent-workspace',
  region: 'iad1',
});

const first = await Sandbox.create({
  persistent: false,
  region: 'iad1',
  mounts: { '/data': workspace },
});

await first.runCommand('bash', [
  '-lc',
  "mkdir -p /data/.cache/demo && printf 'ready\\n' > /data/marker.txt && printf 'cached\\n' > /data/.cache/demo/package.txt",
]);
await first.stop();

const next = await Sandbox.create({
  persistent: false,
  region: 'iad1',
  mounts: { '/data': workspace },
});

const check = await next.runCommand('bash', [
  '-lc',
  'cat /data/marker.txt /data/.cache/demo/package.txt',
]);
console.log(await check.stdout());
await next.stop();

persistent: falseを指定することで、この例ではDriveの動作だけに焦点を当てています。永続サンドボックスにはスナップショットを使った独自の再開機能があります。一方、Driveは別々のサンドボックス間を移動できる独立したディレクトリです。再利用可能な基本環境と、個別に更新されるプロジェクトフォルダの両方が必要なら、2つを組み合わせられます。

運用前に確認すべき4つのテスト

基本動作の確認で永続性は検証できます。さらに次の4項目を試すことで、複数のジョブが同じワークスペースにアクセスしたときの挙動を確認できます。

1. 新しいサンドボックスにもワークスペースが残ることを確認する

目印となるファイルとキャッシュの両方を/data以下に書き込み、書き込み側を停止します。その後、同じDriveを接続した別のサンドボックスを作成し、/dataからファイルを読み取ります。最初のサンドボックス内でも、マウント先以外にあるファイルはDriveの永続性を示す証拠にはなりません。

実際のジョブでは、最初のサンドボックス作成、初回の依存関係インストール、最初の停止、新しいサンドボックスの作成とキャッシュ再利用について、それぞれ時間を記録してください。重要なのは、2回目の実行で削減できたセットアップ時間です。ファイルが残っても実処理が短縮されないなら、Driveには利便性があっても、コンピュート予算は変わっていません。

2. 既存のリーダーが古い状態のままであることを確認する

最初の目印を書き込んでライターを停止し、mounts: { '/data': workspace.snapshot() }を指定してリーダーを作成します。このリーダーは起動したままにします。別のサンドボックスでDriveを読み書き可能としてマウントし、目印を置き換えてからライターを停止します。既存のリーダーは、マウント時点で状態が固定されているため、元の目印を返すはずです。更新後の目印を見るには、新しいスナップショットリーダーを作成します。

ここでのイメージは、ライブミラーではなく写真です。snapshot()の呼び出しは読み取り専用マウントを定義し、リーダーのサンドボックスがマウントした時点の状態が固定されます。また、スナップショットをマウントするには、Driveに少なくとも一度は書き込む必要があります。未書き込みのDriveではdrive_not_initializedが返されます。

3. 2つ目のライターが拒否されることを確認する

1つの読み書き用サンドボックスを起動したまま、同じDriveを読み書き可能として別のサンドボックスを作成してみます。Vercelで同時に許可される読み書きマウントは1つだけです。想定どおりの失敗に対して、無制限にリトライしないでください。ライターの前段にリースまたはキューを設け、所有者を正常に停止します。接続先を調べる必要がある場合は、Drive.list()またはcurrentSandboxNameを使います。

取得済みのVercelドキュメントでは、この2つ目のライターに対する安定したエラーコード名は示されていません。サンドボックスの作成失敗そのものを契約上の挙動と捉え、推測したコード文字列を本番ロジックの分岐条件にしないでください。

4. メインリージョンが一致することを確認する

Driveをiad1に作成し、メインリージョンがsfo1のサンドボックスへのマウントを試します。Vercelはこの不一致をdrive_region_mismatchとして説明しています。Driveのリージョンは作成後に変更できません。また、同じ名前に異なるリージョンまたは最大サイズを指定してgetOrCreate()を呼ぶと、conflictエラーになります。

デフォルトがiad1であっても、両方のオブジェクトにリージョンを設定してください。明示的に指定しておけば、後でプロジェクトのデフォルトが変わっても、通常の再起動がリージョンエラーに変わる事態を防げます。

使い捨てテストの終了後は、すべてのライターとリーダーを停止し、Drive.list()またはcurrentSandboxNameでDriveが切り離されていることを確認してから、await workspace.delete()を呼び出します。削除するとファイルは永久に失われます。また、サンドボックスが接続中の場合、Vercelは削除を拒否します。

料金は4つの項目に分けて考える

Driveストレージはサンドボックスのコンピュートを置き換えるものではありません。既存のコンピュート料金に、3つのストレージ関連メーターが加わります。iad1で現在公開されている料金は次のとおりです。

料金はリージョンによって異なります。npmパッケージやGitリポジトリなど、インターネットからのダウンロードは無料ですが、インストール時に使うCPUとプロビジョニング済みメモリには課金されます。この違いが、依存関係キャッシュに価値を持たせます。削減できるのはダウンロード転送量ではなく、繰り返し発生するセットアップ作業です。

以下はProまたはEnterprise向けの試算例であり、ベンチマークではありません。10 GBの依存関係ツリーを1か月保存すると$0.50です。100回の実行ですべてを読み取ると、論理読み取り量は1,000 GBになり、料金は$1.50です。10 GBを一度書き込む料金は$0.04です。Drive部分の合計は$2.04で、コンピュート、メモリ、転送、後続の書き込み料金は含まれません。

Vercel自身の料金例では、iad1で2-vCPU、4 GBを使う5分間のAIコード検証をCPU使用率100%で実行した場合、約$0.03とされています。その全額をDriveで節約できるとは考えないでください。実際に省けるインストール工程を計測し、削減できるコンピュート料金と待ち時間を、Driveのストレージ、読み取り、書き込み料金と比較します。

Hobbyには、15 GBのDriveストレージに加え、読み取りと書き込みがそれぞれ月30 GB含まれます。一方、Hobbyの個々のDriveの最大サイズはデフォルトで1 GiBです。Hobbyでは超過料金が発生せず、上限を超えると新しいサンドボックスを作成できなくなります。有料プランでは、maxSizeを省略するとDriveの最大サイズはデフォルトで1 TiBとなり、デフォルトの上限は最大16 TiBまで設定できます。

効果が大きい順に見る7つのユースケース

1. 継続利用されるプロジェクトを扱うコーディングエージェント製品

各エージェントのワークスペースに専用Driveを割り当て、リポジトリ、生成ファイル、タスクメモ、パッケージキャッシュをマウント先に保存します。次のターンでは、新しいサンドボックスにそのDriveを接続します。製品チームは、サンドボックスのライフサイクルが切り替わるたびに同じワークスペースを再構築せずに済み、ユーザーはコンピュートを起動し続けなくても作業を継続できます。

再起動の頻度とセットアップの繰り返しが積み重なるため、最も効果が大きい用途です。1ワークスペースにつきアクティブなエージェントは1つ、という形なら単一ライターの制約にも無理なく対応でき、プレビューやテストには固定リーダーを利用できます。

2. 同じ依存関係を何度もインストールするビルドチーム

管理された1つのライターからDriveへデータを投入し、後続のジョブでは依存関係ツリーの読み取り専用スナップショットをマウントします。繰り返し発生するインストールのCPU時間と待ち時間を、1つの保存済みコピーと読み取り料金に置き換えられます。依存関係が大きく、ジョブの実行頻度より更新頻度が低く、キャッシュパスをソースツリーから分離できる場合に特に有効です。

3. 複数エージェントによるレビューパイプライン

1つのコーディネーターに候補リポジトリを書き込ませた後、セキュリティレビュー、テスト、リント、ドキュメント確認をスナップショットリーダーへ分散します。すべてのレビュアーが同じ開始状態を参照し、共有ソースを変更することもありません。ただし、この制約は意図的なものです。コーディネーターによる後の編集が必要なレビュアーは、新しいスナップショットから作り直す必要があります。

4. 準備済みデータセットを再利用するデータチーム

1つのライターでデータセットをダウンロード、正規化、インデックス化し、短時間だけ動く分析用サンドボックスにスナップショットをマウントします。コストの高い準備は一度で済み、並列リーダーには一貫した入力を渡せます。再現可能な評価には適していますが、すべてのリーダーがインプレース更新を期待するライブデータセットには向きません。

5. 複数セッションにわたってファイルを蓄積するリサーチエージェント

出典、抽出したテキスト、中間テーブル、ローカル検索インデックスをDriveに保存します。新しいサンドボックスは、同じ情報源を再びスクレイピングしてインデックス化する代わりに、そのフォルダから作業を続けられます。再現可能な作業資料を残せる点が利点ですが、別のバックアップや来歴管理なしにファイルを永続的な正解として扱うのは危険です。

6. 不定期ジョブ向けのモデルまたはツールチェーンキャッシュ

モデルの重み、コンパイラ、その他の大容量入力をあらかじめDriveに配置し、ジョブが到着したときだけコンピュートを起動します。最初のキャッシュミス時は、Vercelが永続ストレージから取得するため、読み取りが遅くなることがあります。その後のキャッシュヒットによる読み取りはNVMe速度で動作します。アイドル状態のコンピュート料金が、使用中のバイトを保存する料金より高くなる場合に適したパターンです。

7. 学習プロジェクトを再開できるトレーニングプラットフォーム

各プロジェクトにDriveを割り当て、セッションごとに新しいサンドボックスへマウントし、終了時に切り離します。受講者のファイルを保持しつつ、プラットフォームはコンピュートを解放できます。単一ライター制約は、2つのアクティブなセッションが同じプロジェクトを同時編集するのを防ぐうえで役立ちます。ただし、ID管理、バックアップ、保存期間のルールは製品側で別途用意する必要があります。

事業化を検討できる2つの製品

検索ボリュームは需要を示す材料であり、売上予測ではありません。重要なのは、すでに解決策を探している層の面倒な作業を、この機能で取り除けるかどうかです。

最有力：エージェントワークスペースのリースブローカー

各エージェントまたはユーザープロジェクトをDriveに対応付け、期限付きの単一ライターリースを付与し、テストやプレビュー用に固定リーダーのサンドボックスを作成する小規模なコントロールプレーンを構築します。リージョン、接続状態、削除状態も確認できるようにします。生のストレージ機能だけではライターの所有者を決められないため、コーディングエージェントを開発するチームは、この調整レイヤーに対価を払う可能性があります。

米国のキーワードデータでは、「ai powered coding agent」の月間検索数は約8,100で、検索意図は商用です。隣接市場では、すでにプラットフォーム料金が受け入れられています。E2BのProは月$150に従量料金が加わる価格設定で、数日間継続する永続セッションはカスタムEnterpriseプランに含まれます。直接比較できる価格ではありませんが、エージェント基盤を購入するチームの予算感を示す有力な目安です。

販売可能な最小構成には、ワークスペースごとのDrive対応付け、有効期限付きライターキュー、スナップショットリーダーの作成、使用量表示、安全なクリーンアップが必要です。課題は競争優位性です。薄いラッパーならVercelやエージェントフレームワークに取り込まれる可能性があります。単に見栄えのよいgetOrCreate()ボタンを作るのではなく、運用ポリシー、監査履歴、復旧機能、プロバイダー間の可搬性まで備える必要があります。

クラウド開発環境向けのウォームスタート層

リポジトリテンプレート、Driveを使った依存関係パス、キャッシュウォーマー、明示的なリージョンポリシー、セットアップ時間の前後比較を行うテレメトリをまとめ、プラットフォームチーム向けに提供します。完全な開発環境としてではなく、既存のVercel環境におけるコールドスタート短縮策として販売します。

米国のキーワードデータでは、「cloud integrated development environment」の月間検索数は約1,900、CPCは$9.03です。この検索広告単価から、ベンダーがこの層を獲得しようと競っていることがうかがえます。MVPは対象を絞れます。まずNodeとpnpmに対応し、リージョンとキャッシュポリシーはそれぞれ1つに限定します。ダッシュボードでは、ストレージ、読み取り、書き込み、Active CPU、メモリを分けて表示します。

課題は対象範囲です。Driveが提供するのは1つの永続ディレクトリです。IDE、シークレット管理、共同作業、イメージ管理、バックアップ、リージョン間レプリケーションは提供しません。この機能だけで完全なクラウドワークステーションを約束すれば、購入者の期待を裏切ることになります。

設計を左右する制約

• ライターは1つ、つまり所有者も1つです。 変更処理は直列化します。スナップショットリーダーは処理の分散には使えますが、共同編集には使えません。
• リーダーの状態は固定されます。 実行中のリーダーに後続の書き込みは反映されません。新しいスナップショットから作り直してください。
• 最初のスナップショットには書き込みが必要です。 リーダーのサンドボックスを起動する前にDriveを初期化します。
• メインリージョンを一致させる必要があります。 Driveは1つのリージョンに固定され、移動できません。リージョンを明示的に設定してください。
• 1つのサンドボックスで使えるマウントは4つです。 各パスは絶対パスでなければならず、マウントパス同士を重ねることはできません。
• Driveはマシン全体ではありません。 環境全体にはサンドボックスのスナップショットを使います。Driveは、独立して更新したいディレクトリに使います。
• コールド読み取りは遅くなる場合があります。 キャッシュヒット時の読み取りと書き込みはNVMe速度ですが、永続ストレージでキャッシュミスが起きた場合は異なります。
• 削除は取り消せません。 Vercelはdrive.delete()による削除を永久的なものと説明しています。Driveを唯一のバックアップにしないでください。

現在公開中のドキュメントには矛盾もあります。9月23日のリリース情報では、Driveをマウントするサンドボックスはフェイルオーバーリージョンを利用できないとされています。一方、9月22日付のリージョンページには、読み取りレイテンシーは高くなるものの、フェイルオーバーによってリージョンをまたいでDriveを読み込めるとあります。Vercelが記述を統一するまでは、アーキテクチャ上でDriveのフェイルオーバーを未対応として扱い、依存する前に再検証してください。

1回の実行中に一時領域を増やしたいだけなら、Driveを最初に選ぶべきではありません。関連ガイドのVercel Sandboxで大規模なエージェント処理に使えるスクラッチディスクを読み、設計に永続性を持ち込まないようにしてください。

来週まず実行すること

再起動の多いエージェントワークフローを1つ選びます。プロジェクトファイルと依存関係キャッシュだけを1つのDriveに置き、ライターを1つに保ち、前述の4項目を検証してください。セットアップ時間の前後差を記録し、Driveのストレージ、読み取り、書き込み、Active CPU、メモリを別々の項目として測定します。再起動時間の短縮が、追加のストレージ料金と調整ルールに見合う場合にだけ、対象を広げます。

永続的なエージェントワークスペースを本番向けに設計し、計測できる状態まで整えたい場合は、AIプロダクションシステムの構築をご相談ください。