VercelがロンドンのShipイベントで披露したのは、オープンソースのエージェントフレームワーク「Eve」と、企業向け統制機能「Vercel Passport」である。狙いはエージェント開発の入口を広げるにとどまらない。Vercel上で作られるアプリやエージェントを、企業のID、監査、実行環境、クラウド管理の下へ戻すことにある。
背景にあるのは、AIコーディングが生む新しいシャドーITだ。The Registerは典型例として、従業員がAI支援で作ったアプリがVercelにホストされ、組織の管理外に置かれる状況を挙げている。会社のデータを扱う小さなアプリが、ID管理、アクセス権、監査ログ、モデル利用費、クラウド接続の統制から外れて増える。VercelはEveで作成を容易にし、PassportやConnect、Directory Sync、BYOCで統制を追いつかせようとしている。
Eveはエージェントをディレクトリとして扱う
Eveは、エージェントをコードと文書が混在するディレクトリとして定義する。Vercelは「WebアプリにおけるNext.jsのようなもの」と説明している。常時読み込まれる指示はinstructions.md、再利用する手順はskills/、モデルやランタイム設定はagent.ts、ツールはTypeScriptファイルとして置く。Slack、Discord、Teams、Webチャットなどへ出すチャンネル、外部サービスへ認証する接続、専門タスクを任せるサブエージェント、定期実行するスケジュールも、それぞれファイルで追加する。
プロンプトを画面に貼り付けて動かすエージェントとは構造が違う。EveのGitHub READMEは、典型的な構成としてagent/agent.ts、instructions.md、tools/、skills/、channels/、schedules/を示し、npx eve@latest init my-agentで新規作成できるとしている。リポジトリはApache 2.0ライセンスで公開され、GitHubのリリース欄では2026年6月19日時点でeve@0.11.7が最新と表示されていた。READMEはベータであり、APIや挙動は一般提供前に変わり得ると明記している。
The Registerの取材に対し、Vercel CTOのMalte Ubl氏は、Eveの狙いを「空欄を埋める」ような手軽さにあると説明した。開発者はライフサイクル全体を細かく理解しなくても、正しい場所にファイルを置けばフレームワークが動かすという考え方である。Eveのプロジェクトはローカルでnpx eve devとして動かせ、VercelへのデプロイはWebアプリと同じvercel deployで行えるとされる。
作りやすさの裏側に隔離、永続実行、評価を組み込む
EveがVercelらしいのは、エージェントの構成ファイルにとどまらず、周辺の実行基盤まで自社スタックに寄せている点である。VercelのEveページは、AI Gateway、Sandbox、Workflow、ConnectをEveが利用する基盤として並べている。エージェントはモデルを呼び、外部サービスへ接続し、生成したコードを実行し、人の承認を待ち、数時間から数カ月にわたって処理を続ける。Vercelはその各段階を、同一プラットフォーム上の構成要素として扱わせたい。
実行の安全性を担うのがVercel Sandboxである。VercelのドキュメントはSandboxを、AIエージェントの出力、ユーザーアップロード、第三者スクリプトのような信頼できないコードを本番環境から切り離して動かす計算基盤として説明している。各Sandboxは独自のファイルシステムとネットワークを持つFirecracker microVMで動き、Amazon Linux 2023、node24、node22、python3.13を利用できる。AIが生成したコードをそのまま本番環境で実行するのではなく、ログ、ファイル編集、ライブプレビューを見ながら隔離環境で確認する設計である。
長く続く処理はVercel Workflowが受け持つ。Workflowは、AIエージェントやアプリが一時停止、再開、状態保持をできる管理基盤で、Vercel Functions、Queues、永続化ストアを組み合わせる。ドキュメントは、ワークフローがデプロイやクラッシュをまたいで再開でき、ステップにはリトライがあり、待機中は計算資源を消費しないと説明している。人間の承認を待つフックも用意される。Eveのエージェントは一回の応答で終わるチャットボットではなく、業務処理を途中で止めながら進めるソフトウェアとして設計されている。
モデル呼び出しはAI Gatewayに集約される。Vercelのドキュメントによれば、AI Gatewayは単一エンドポイントで数百のモデルへアクセスし、予算設定、利用監視、ロードバランス、フォールバック、プロバイダー間の再試行を扱う。社内で多数の小さなAIアプリが生まれる場合、どのアプリがどのモデルをどれだけ使ったか、失敗時にどこへ切り替えるか、費用をどこで止めるかが管理課題になる。Eveはこの課題を作成時から同じプラットフォームの中に置く。
PassportはシャドーAIをID管理へ戻す
Passportは、Vercel上で作られたアプリやAIエージェントを企業のIDプロバイダーの背後へ置く機能である。VercelのEnterpriseページは、PassportによってOkta、Microsoft Entraなど既存のIdPを通じ、誰がアプリやエージェントをデプロイし、アクセスできるかを制御できると説明している。The Registerは、Passportが強く求められた理由として、従業員がAI支援で作ったVercelホストのアプリが組織の管理外に置かれる問題を挙げている。
ここでの統制は、ログイン画面を追加するだけでは足りない。VercelのEnterpriseページは、Vercelで管理されるアプリ、エージェント、ワークフローを企業向け管理面から管理、監視、統制すると説明し、監査ログではすべてのアクション、ツール呼び出し、開始者、戻り値を確認できるとしている。モデルアクセス、支出上限、RBACをチーム、プロジェクト、ユーザー、エージェントへまたがって設定できる。AIが作ったアプリをVercel上で運用するほど、問題は「誰が作ったか」ではなく「誰が使い、何を呼び、どのデータへ届いたか」に移る。
Directory Syncも同じ線上にある。Vercelのドキュメントでは、EnterpriseチームがGoogle DirectoryやOktaなどの外部IDプロバイダーからチームメンバーを同期し、ディレクトリ側の変更をVercelのメンバー管理へ自動反映できる。グループをVercelのロールへ対応させることもできる。従業員が退職したり部署を移ったりしたとき、Vercel上の小規模アプリやエージェントのアクセス権だけが残る事態を減らすには、こうしたライフサイクル管理が欠かせない。
Vercel Connectはサービス接続側の答えである。Enterpriseページは、Slack、GitHub、SnowflakeなどのOAuthサービスへ、20ミリ秒未満で発行される短命トークンを使ってアプリやエージェントが到達できると説明している。固定の長期シークレットをアプリごとに持たせるのではなく、接続ごとに短命の認証情報を発行する。AIで作られたVercel上のアプリが増えるほど、静的なAPIキーや環境変数の散在はリスクになる。Connectは、その接続部分をVercelの管理対象にする部品である。
BYOCはAWS直利用との境目を曖昧にする
企業向けにもう一つ効く要素が、Bring Your Own Cloudである。VercelのEnterpriseページは、BYOCを「顧客自身のAWSアカウント内でVercelを動かし、IAMルールと直接のリソースアクセスを自然に使える」機能として説明している。Vercelの開発体験を使いたいが、クラウド資産やIAM管理は自社AWSアカウントに残したい企業への提案である。
ただし、BYOCはVercelを完全に消す仕組みではない。The Registerの取材でUbl氏は、Vercelは顧客の計算処理にAWSロールを直接引き受けさせない一方、各呼び出しにOIDCトークンを発行するため、それをAWSポリシーに使えると説明している。同氏はまた、BYOCではVercelが管理ベンダーになり、顧客AWSインフラの該当部分へアクセスを持つことになるとも述べた。企業はAWSアカウントの所有権を保ちながら、運用面ではVercelの管理層を受け入れる形になる。
VercelのOIDC for AWSドキュメントがこの考え方を裏づける。AWS側にOIDCアイデンティティプロバイダーを作り、IAMロールの信頼ポリシーでaudやsubクレームを条件にする。条件には、チーム、プロジェクト、環境を含められる。プロダクションだけを許可し、開発環境を除外する、といった制御も書ける。Vercel上のエージェントやアプリがAWS資源へ触れる場合、長期キーではなく実行元の文脈を持つトークンで制御する方向である。
コスト面では、Vercelの主張は攻めたものになっている。The Registerによれば、Ubl氏はVercelを経由してAWSを使う場合のプレミアムは、低スケールやLambdaとの比較では効率の良さで相殺されると述べ、AWS顧客がVercel価格に並ぶには35%を超える利用率が必要だと主張した。Vercelは2025年にも、待機中のインスタンス再利用でLambda費用を最大95%削減したと説明している。これらはVercel側の主張であるが、EveとPassportの話が実行コスト、待機時間、長時間エージェント処理と切り離せないことを示している。
プラットフォーム中立の約束は、次の検証点になる
Eveをめぐる最大の確認点は、Vercel外でどこまで自然に動くかである。The Registerは、Eveのプロバイダーやサンドボックスは設定可能で、Vercelはどこでも動くようにする姿勢だとUbl氏が述べた一方、Vercel以外のモデルプロバイダーを使う設定でもVercelログインを求められるという初期の指摘があったと報じている。公開直後のベータであれば不具合の可能性もあるが、企業が採用する際にはこの部分が目立つ。エージェントの形式がオープンでも、実行、認証、デプロイがVercelに強く寄るなら、移植性の評価は変わる。
VercelはNext.jsでも同じ緊張を抱えてきた。Next.js 16.2では、アプリのルート、プリレンダー、静的資産、ランタイム対象、依存関係、キャッシュ規則、ルーティング判断を型付きで表す安定したAdapter APIが導入された。Next.jsチームは、Vercel自身のアダプターも同じ公開契約を使い、プライベートなフックは使わないとしている。Netlify、Cloudflare、AWS Amplify、Google Cloud、OpenNextとの作業も進められている。Vercelが自社最適だけでなく公開契約を求められていることの表れである。
Eveにも同じ問いが来る。Markdownの指示、TypeScriptのツール、チャンネル、接続、サブエージェント、スケジュールという構成は、人間にもエージェントにも読みやすい。だが、Vercel Workflow、Sandbox、AI Gateway、Connect、Passport、BYOCまで含めて採用したとき、ユーザーが得るのは移植しやすいエージェント形式なのか、それともVercelのAIアプリ基盤なのか。おそらく答えはその中間にある。Vercelは開発速度と統制をまとめて売り、企業はその便利さとロックインの境目を見極めることになる。
企業のAIアプリ管理は、発見から統制へ移る
AIで誰でもアプリを作れる状態が進むほど、企業に必要になるのは作成ツールにとどまらない。作られた後の発見、ID連携、監査、接続管理、実行隔離、コスト制御である。Eveは作る側の作法をディレクトリへ落とし込み、Passportはその成果物を組織のID管理へ結び直す。Connect、Sandbox、Workflow、AI Gateway、BYOCは、アプリやエージェントが実際に動くときの危険箇所を埋める。
Vercelは、AIで作られる小さなアプリやエージェントを自社プラットフォームへ集め、管理者が後から追える形に変えようとしている。成否は、Eveが開発者に受け入れられるかだけでは決まらない。Passportが既存のIdPとどこまで滑らかにつながるか、BYOCが顧客AWS環境でどれだけ納得できる運用になるか、AI Gatewayのモデル統制が実際の費用管理に効くか、そしてVercel外での実行が言葉通りに成熟するかが、次の判断材料になる。