Firecracker microVMのVercel Sandbox、AI agentに隔離された実行場所を渡す

Vercelがagentの実行場所をplatform内へ置く

AI agentはコードを書くだけでは終わらない。

生成物をinstallし、commandを実行し、previewを開く。

Vercel Sandboxはその一連をproduction appから隔離したFirecracker microVMで担う。出典

ephemeralではなく状態を扱う

Sandboxは停止時にfilesystemを保存し、次回resumeで戻せるpersistent sandboxを既定にする。

依存関係のinstallやagent workspaceを都度失わないための設計だ。出典

SDKとOIDCで開発workflowへ接続する

VercelはJS/Python SDKとCLIを用意し、Vercel上のproductionではOIDC認証を自動化する。

実行環境を単独販売するより、既存projectからagent機能を出せる導線を優先した。出典

課金と権限が次の論点になる

Active CPU、memory、network、snapshot storageが利用量に応じて発生する。

agentの自律性を上げるほど、隔離だけでなく予算・権限・削除の運用がプロダクト品質を左右する。出典

Vercel Sandboxは、AI agentの実行を外部の一時環境へ逃がすのでなく、web appを届けるplatformの中へ戻す試みだと言える。

AI agentが生成するコード、ユーザーアップロード、第三者scriptを本番環境から分離して実行したい開発チームに向く。

Vercel Sandboxはcommand実行、file操作、live previewをSDKとCLIで扱える。出典

agentをVercel上のappへ組み込む組織にとって、OIDC認証とproject連携が導入摩擦を下げる。出典

Vercelのdeploy、project、OIDC、SDK、CLIと結合している点が防御力である。

microVM単体の提供ではなく、agentが生成した成果物をpreview/deployまで運ぶ開発体験に埋め込まれる。出典

ただし実行基盤は競合しやすいため、継続利用の鍵はplatform統合と運用体験になる。

直接network effectは弱い。

各sandboxのstateやcodeは顧客ごとに隔離される。

一方でSDK、CLI、GitHub公開repo、Vercelのagent ecosystemが広がるほど、サンプルとintegrationが増え導入コストは下がる。出典

主対象は、code generation、interactive playground、AI UI builder、agentによる開発server起動をユーザー向けに提供する開発チーム。出典

低遅延の短命実行だけでなく、filesystem状態を持つagent workspaceを必要とするVercel利用組織に合う。出典

Firecracker microVMでfilesystemとnetworkを分離しつつ、Node.js/Pythonとsystem privilegeを用意した。

sandboxを別のcontainer providerとして扱わせず、Vercelのproject/auth/SDKへ組み込む設計が差別化になる。出典

停止時にfilesystemを自動保存し、resumeとsnapshotを扱えるため、agentの依存関係導入を毎回やり直さない。出典

Sandboxは実行回数だけでなくActive CPU、memory、network、snapshot storageが従量課金となる。

agentのretriesや長時間開発serverを無制御に走らせると、実行境界より先にcost controlが課題になる。出典

Vercel projectとOIDCを軸にした便利さは、既存cloudやself-hosted環境で統一したい組織には依存リスクになる。

機密データ・egress・権限分離の設計を採用前に検証すべきだ。

Vercelは既存のweb開発者へDocs、quickstart、JS/Python SDK、CLIを通じてSandboxを配る。

Vercel上のproduction appではOIDCが自動利用できるため、agent機能を足したい既存顧客が最短の入口になる。出典

無料枠でprototypeを作らせ、concurrency、実行量、persistent stateが必要なチームをPro/Enterpriseのplatform利用へ拡張するモデルと考えられる。出典

主要チャネル: developer_relations, documentation, platform_distribution, open_source

agent runtimeの設計では、modelの能力より先に隔離、filesystem、認証、cost limit、成果物previewを決める必要がある。

Sandboxを単なるcode execution APIにせず、開発workflowのどこでstateを保持しどこで破棄するかを仕様にする。

PMはagentが失敗した時のretry回数、許容network、snapshot寿命をproduct metricとして持つべきだ。

日本の社内業務agentでは、Vercel Sandboxのような隔離実行を使っても、個人情報や社内コードの持ち込み範囲を先に決める必要がある。

sandboxの作成・resume・削除を監査対象にし、preview URLの公開範囲をroleで管理する。

まずは非機密のcode reviewやdocument transformationから試し、CPU時間・memory・networkの実測を予算化してから顧客向けagentへ広げるのが現実的だ。