AI agentのコードを隔離するVercel Sandbox、Firecrackerを開発者APIへ

Vercel Sandboxは、AI agentや信頼できないコードをFirecracker microVMで隔離して実行するSDK・CLIです。

各sandboxに独立したfilesystem、kernel、networkを与え、VercelのFluid compute上で短命な実行環境を提供します。出典

Guillermo Rauchが率いるVercelは、web applicationをdeployするplatformから、AI agentが生成したコードを実行するruntimeへ境界を広げた。出典

Vercel Sandboxの公式説明は、これを「The safest way to run code you didn’t write」と表現し、任意コードを安全に動かすことを中心課題に置いている。出典

deployの外側にある実行問題

通常のweb deployは、信頼できるアプリケーションを継続稼働させる仕組みだ。

しかしAI agentやcode interpreterは、毎回異なるコードを生成し、filesystemやnetworkへ触れる。

アプリのprocessへそのまま載せると、失敗や悪意ある命令の影響範囲が広い。

Vercelはこの差分をruntimeの問題として切り出した。出典

containerではなくmicroVM

Vercel Sandboxは各環境をFirecracker microVMとして作る。

公式READMEは、sandboxを独立したLinux systemとして説明し、専用kernel、filesystem、networkを持つ境界を示す。出典

ここで重要なのは、利用者にmicroVMの構築手順を渡すのではなく、Sandbox.createとrunCommandへ圧縮したことだ。出典

AI agentの実行場所へ

examplesにはAI applicationからsandboxを作成し、コードを実行してlogsを返す流れが用意されている。出典

これによりSandboxは、単なるisolated shellではなく、agentのtool callを受け止めるexecution layerになる。

snapshotやfilesystem、network policyをSDKに含めたのも、agentの試行錯誤を再現可能にするためだ。出典

platformへの拡張

地域配置、failover、vCPU、port、observabilityを提供することで、短命な実験環境から運用可能なplatformへ進もうとしている。出典

Vercelが選んだのは、AI agent専用製品を別ブランドで作ることではなく、既存のdeploy・compute・developer workflowの延長に安全な実行境界を置く道だった。

この選択は、AIの出力を信頼するのではなく、信頼しなくても使えるruntimeを先に用意する設計思想だと言える。

AI agentが生成したコードを実行するチームは、既存のcontainerやVMを毎回用意し、filesystem・network・credentialの境界を自分で設計する負担を抱えます。

Vercel Sandboxは、各実行をFirecracker microVMへ閉じ込め、SDKから短いコードで作成・実行・停止できる形にしました。出典

対象がAI coding、computer-use、教育用runner、CIのように「任意コードを実行したいが、アプリ本体と混ぜたくない」場面なら、security boundaryとdeveloper experienceを同時に提供する点がPMFになります。出典

moatはFirecrackerそのものではなく、microVM、SDK、snapshot、region、logs、Vercelのdeploy workflowを一つの実行体験にまとめる統合面です。出典

AI agentの実行履歴とアプリ運用が同じplatformに集まるほど、移行時のworkflow再構築コストが上がります。

直接のnetwork effectは弱いです。

Sandboxの価値は利用者同士の接続より、実行の安全性と運用の一貫性から生まれます。

一方、SDK利用例やimage、snapshot、AI agent向けの知見が増えるほど、間接的なecosystem効果は強まります。出典

AI coding agent、computer-use agent、code interpreter、CI runner、教育・検証環境を作る開発チームが主対象です。

特にVercel上のweb applicationから、任意コードを短時間だけ実行したいチームに向きます。出典

一方、長時間のstateful server、完全なprivate cloud、低レイヤーのkernel制御が必要な用途には向きません。

第一に、containerより強い隔離をFirecracker microVMとして抽象化したことです。出典

第二に、TypeScript SDKとCLI、snapshot、filesystem、network policyを一つのworkflowにまとめたことです。出典

第三に、Vercelのdeploy・observability・region設計と接続できることです。出典

microVMはcontainerより起動・運用コストが高く、CPU、memory、egress、port公開を利用量として管理する必要があります。出典

また、Vercelのmanaged infrastructureに依存するため、完全なself-hostingや特殊なnetwork境界を必須とする組織には制約があります。

AI agentが実行するコードのprompt injectionやsecret流出は、隔離だけでは解消せず、credential設計と監査が残ります。出典

Vercelの既存developer ecosystemから、AI code executionという新しいruntime需要へ拡張する戦略です。

homepageでSDK・CLI・examplesを直接提示し、Node.jsなどの実行例から導入させます。出典

その後、region、failover、observability、Fluid computeをenterprise運用へ接続し、単発のsandboxからplatform利用へ広げます。出典

主要チャネル: content, developerCommunity, documentation, partners, sales, events

AI agent時代のruntimeでは、モデル性能だけでなく、生成物をどこで実行し、どの境界で止めるかがproduct valueになります。

Vercel Sandboxは、securityを別の運用作業にせずSDKのcreate・run・stopへ埋め込みました。出典

ただし、隔離の強さはコストと複雑さを伴います。

日本で同様の基盤を作るなら、実行環境の安全性だけでなく、費用上限、監査ログ、credentialの最小権限を最初からUXに含めるべきです。

日本では、社内業務agentや開発自動化で生成コードを実行する際、個人情報・ソースコード・顧客環境の境界説明が導入条件になります。

region選択、egress制御、ログ保持期間、snapshotの削除を管理者向けに明示し、金融・製造・SIer向けの監査テンプレートと組み合わせると、単なる「安全なsandbox」からenterprise infrastructureへ翻訳できます。出典