エージェントを作るたびに、状態管理や認証、デプロイ用の配管を一から組み立てていませんか。Vercelは2026年6月17日、オープンソースのエージェント向けフレームワーク「eve」を公開プレビューで提供開始しました。Next.jsがWebアプリの定型作業を肩代わりしたように、eveはエージェント開発の定型作業をファイル構成に集約します。
この記事では、eveが何を解決するのか、どんな仕組みで動くのか、どう始められるのかを整理します。
- eveの位置づけと、Next.jsとの類似点
agent/ディレクトリで定義するエージェントの構成- 本番運用向けに内蔵される機能（durable実行、サンドボックス、承認フローなど）
- ローカル開発からVercelへのデプロイ手順
- Vercel社内での実運用事例
エージェント開発の「配管問題」をフレームワーク化
Vercelは公式ブログで、eveを「エージェント版のNext.js」と位置づけています。背景にあるのは、エージェントごとに同じインフラ課題を繰り返し実装している現状です。セッションの永続化、外部サービス連携、サンドボックス実行、承認待ち、ログ追跡。用途は違っても、必要な部品の形は似ています。
eveはこの形をフレームワークとして固定します。エージェント本体は「ただのディレクトリ」として定義し、実行基盤はフレームワーク側が担います。Vercel自身も社内で100超のエージェントをeve上で運用しており、1年前はVercel上のデプロイの3%未満だったエージェント起因のデプロイが、現在は約29%まで増えています。
ファイル構成がそのままエージェント定義になる
eveの中心思想は「filesystem-first」です。TypeScriptプロジェクトのagent/以下に、役割ごとのファイルを置くだけでエージェントが組み上がります。
最小構成は2ファイルです。agent/instructions.mdに常時適用されるシステムプロンプトを書き、agent/agent.tsで利用するAIモデルを指定します。モデル指定はanthropic/claude-opus-4.8のような文字列で行い、Vercel上ではAI Gateway経由でルーティングされます。AI Gatewayは複数プロバイダへのリクエスト振り分けとフォールバックを担うVercelのゲートウェイです。
機能追加もファイル追加で完結します。
agent/tools/*.ts… モデルが呼び出す型付きツール（Zodスキーマ付き）agent/skills/*.md… 必要なときだけ読み込む手順書agent/subagents/… 委譲先の子エージェントagent/channels/… SlackやDiscordなどの接続先agent/schedules/… cronによる定期実行agent/connections/… MCPサーバーやOpenAPI対応APIへの接続
ファイル名と配置がそのまま登録情報になります。ツール名を別ファイルで再宣言するボイラープレートは不要です。Next.jsがフォルダ構成からルーティングを解決するのと同じ発想です。
本番運用の部品が最初から入っている
eveは現在ベータ版です。APIや挙動は一般提供前に変わる可能性があります。それでも、公開時点で本番向け機能が一式そろっています。
durable実行では、会話ごとにワークフローセッションを作り、各ステップをチェックポイント保存します。人の返信待ちや長時間処理のあいだも状態を保持し、クラッシュやデプロイ後も途中から再開できます。基盤にはオープンソースのWorkflow SDKを使います。
サンドボックスでは、エージェントが生成したコードをアプリ本体の実行環境から切り離します。各エージェントに隔離環境を割り当て、シェル実行やファイル操作を安全側に寄せます。本番はVercel Sandbox、ローカルはDockerなどに切り替わります。
Human-in-the-loopでは、ツール定義にneedsApprovalを足すだけで承認待ちを挟めます。承認が来るまで処理を停止し、再開時に消費計算も不要な設計です。
接続管理では、agent/connections/にMCP（Model Context Protocol。AIが外部ツールを呼ぶための共通プロトコル）やOpenAPI定義を置きます。認証はVercel Connectが担い、モデルにURLやトークンを渡しません。公開時点でSlack、GitHub、Snowflake、Salesforce、Notion、Linearなどに対応しています。
マルチチャネル配信では、同じエージェントをHTTP API、Slack、Discord、Teams、Telegram、Twilio、GitHub、Linearへ展開できます。チャネル追加はeve channels add slackのようなCLI操作で、生成されたchannels/slack.tsをデプロイする流れです。
トレースとevalでは、各ターンのモデル呼び出しとツール実行をOpenTelemetry形式で記録します。VercelダッシュボードのAgent Runsタブから確認でき、eve evalでCIに組み込むテストスイートも書けます。
1分で動かし、そのまま本番へ送れる
開発はnpx eve@latest init my-agentから始めます。依存関係の導入、Git初期化、開発サーバー起動までCLIが行い、公式ドキュメントでは1分未満での起動をうたっています。既存プロジェクトへ足す場合はnpm install eve@latestでパッケージを追加します。
ローカルではeve devで対話用TUIが立ち上がり、HTTP APIでも同じイベントを取得できます。セッション作成はPOST /eve/v1/session、ストリーム取得はGET /eve/v1/session/:id/streamです。
本番反映は通常のVercelプロジェクトと同じくvercel deployです。デプロイ中でも進行中セッションは開始時のバージョンで完了し、サンドボックスだけ本番用バックエンドへ切り替わります。プレビューデプロイごとにSlackボットの試験運用も可能です。
Vercel社内で動いている具体例
公式発表で紹介されている社内エージェントは、eveの想定ユースケースを具体的に示しています。
d0はデータ分析エージェントで、Slack経由で月3万問以上を処理します。Lead Agentは新規リードへの自動フォローを担い、年間コスト約5,000ドルで32倍のリターンを報告しています。Athenaは営業向けにSnowflakeとSalesforceを自然言語で横断し、エンジニア不在で6週間で構築された事例です。Vertexはサポートチケットの92%を自律解決し、残りを人へエスカレーションします。draft0は社内コンテンツのレビュー導線を自動化し、VはSlack上で100超のエージェントへタスクを振り分けるルーティング役です。
以前はスタックがバラバラだったこれらが、いまは共通のディレクトリ構造と運用手順に揃えられています。
既存のエージェント基盤との違い
LangChainや独自実装と比べたとき、eveの差は「アプリロジック」より「運用前提の一体設計」にあります。モデル呼び出しライブラリ単体ではなく、セッション永続化、隔離実行、OAuth、チャネル配信、評価までを1つのプロジェクト形状にまとめています。
一方で、ベータ段階のためAPI固定は期待できません。Vercel外へのデプロイはロードマップ上の対応予定で、現時点の第一選択肢はVercel Functions上の実行です。すでに複雑な独自基盤を持つチームは、移行コストと標準化のメリットを比較する必要があります。
エージェント開発の次の標準形か
エージェント開発が増えるほど、フレームワークによる共通化の圧力は強まります。eveは「エージェントはディレクトリ」「本番配管は内蔵」という明快な約束で、その流れの先頭に立とうとしています。
npx eve@latest initで触れ、Git管理とevalをCIに載せ、必要なチャネルを1ファイルずつ足していく。Next.js世代の開発者にとって、この導線は馴染みやすいはずです。ドキュメントはeve.dev/docs、ソースコードはgithub.com/vercel/eveで公開されています。