Vercel eve 徹底解説 - ファイルシステム中心の新しいAIエージェントフレームワーク

AIエージェントを本番で動かそうとすると、モデルの選定よりも「その周辺」で手が止まります。セッションの永続化、ツールの実装、承認フロー、サンドボックス、スケジュール実行、可観測性。これらを毎回自作していると、肝心のエージェントの振る舞いに集中できません。

Vercelが2026年6月17日に公開した eve は、この「周辺」を一気に引き受けるオープンソースのエージェントフレームワークです。最大の特徴はファイルシステム中心（filesystem-first）という設計思想にあります。この記事では、eveが何を解決するのか、どう書くのか、既存フレームワークとどう違うのかを、公式ドキュメントとリポジトリで確認できた範囲で整理します。

eve とは何か

eveは、耐久性のあるバックエンドAIエージェントを構築するためのTypeScriptフレームワークです。Vercelの公式ブログとchangelogによれば、2026年6月17日にオープンソースとして公開されました。npmパッケージ名は eve で、ライセンスはApache-2.0、リポジトリは github.com/vercel/eve で公開開発されています。

現時点（本記事執筆時点）での提供状況はベータ（public preview）です。READMEにも「eveは現在ベータであり、フレームワーク・API・ドキュメント・挙動はGA前に変更される可能性がある」と明記されています。GitHubのリリースを見ると、2026年7月上旬時点でバージョンは 0.22.3 前後で活発に更新が続いています。バージョン番号は日々動くため、実際に使う際は最新のリリースを確認してください。

エージェント基盤としては、Vercel AI SDKやCloudflare Agents SDK、OpenAI Agents SDKなどが既にあります。eveはこれらと競合しつつ、後述する「ファイル＝機能」という独自の切り口を打ち出しています。

何が新しいのか: ファイルシステム中心という発想

eveの核は、エージェントを1つのディレクトリとして表現する点です。設定オブジェクトやデコレータでエージェントを組み立てるのではなく、agent/ ディレクトリの下に決められた名前でファイルを置くと、eveがそれを自動的に発見・検証し、マニフェストにコンパイルして実行可能なアプリとして提供します。

考え方はシンプルです。

• 能力（ツール）を1つ増やしたい -> agent/tools/ にTypeScriptファイルを1つ足す
• 手順（スキル）を持たせたい -> agent/skills/ にMarkdownファイルを1つ足す
• Slack連携を足したい -> agent/channels/ にチャネルファイルを足す

ディレクトリツリーを眺めるだけで「このエージェントは何ができて、どこで動き、いつ動くのか」が把握できる、という設計です。ファイル名がそのままランタイム上のツール名になるなど、命名規約が実装に直結します。

もう1つの柱が耐久ワークフロー（durable workflow）です。eveのセッションは Vercel Workflows の上で動き、進行状況をイベントログとして永続化し、それを決定論的にリプレイして状態を復元します。これにより、会話の各ステップがチェックポイントされ、コールドスタート・再デプロイ・長時間の待機をまたいでも、止まったところから正確に再開できます。承認待ちで数時間止まっても、次のメッセージが来たら続きから動く、という挙動が標準で得られます。「落ちても復旧できる」を前提にする点は、Cloudflare Agents SDKの永続チャットとも通じる発想です。

内部的には、eveはAI SDK v7で追加された AgentHarness の上に構築されているとされ、skills・instructions・hooksといったAI SDKの設定の多くが eve のオプションとして引き継がれます。モデル呼び出しやツール管理はAI SDKに、耐久・再開可能なセッション状態はWorkflowsに、それぞれ担わせる構成です。

ディレクトリ構成とコードの例

eveのプロジェクトは npx eve@latest init my-agent で雛形を生成できます（既存プロジェクトへ追加する場合は npx eve@latest init .）。生成されるのは、おおむね次のような agent/ ディレクトリ構成です。

my-agent/
├── package.json
└── agent/
    ├── agent.ts          # モデルとランタイム設定（defineAgent）
    ├── instructions.md   # 常時有効なシステムプロンプト
    ├── tools/            # ツール（1ファイル＝1ツール）
    ├── skills/           # 必要なときだけ読み込む手順・知識
    ├── subagents/        # 委譲用の子エージェント
    ├── channels/         # HTTP・Slack などの入口
    ├── connections/      # 外部サービスとの型付き連携
    ├── schedules/        # 定期実行（cron）ジョブ
    └── sandbox/          # 隔離された実行環境

公式ドキュメントのリファレンス（Agent Files）では、必須なのは agent/instructions.md だけで、agent/agent.ts は省略可能（省略時はフレームワークのデフォルト設定を使用）とされています。モデルを明示したい場合は agent/agent.ts の defineAgent で指定します。

import { defineAgent } from 'eve';
 
export default defineAgent({
  model: 'openai/gpt-5.4-mini',
});

モデル文字列はVercelのAI Gateway経由で解決されるため、デプロイ後はプロバイダのAPIキーを直接管理する代わりにVercel OIDCを使えます。プロバイダのフォールバックやコンパクション等のオプションも用意されています。

ツールは agent/tools/ に1ファイル1ツールで置きます。Zodで入力スキーマを定義し、execute に処理を書く形です。

import { defineTool } from 'eve/tools';
import { z } from 'zod';
 
export default defineTool({
  description: 'Get the weather for a city.',
  inputSchema: z.object({ city: z.string() }),
  async execute({ city }) {
    return { city, condition: 'Sunny' };
  },
});

一方でスキルはMarkdownファイルとして書きます。スキルは「必要になったときだけ読み込む」大きめの手順書や参照資料で、常時プロンプトに載せたくない多段手順やドメイン知識を切り出しておく用途です。この進行的開示の考え方は、Cloudflare Agents SDKのAgent SkillsやClaude系のSkillとよく似ています。

セッションはHTTP経由でも起動できます。POSTでメッセージを送るとセッションが作られ、レスポンスの x-eve-session-id ヘッダに含まれるIDでストリームへ再接続できます。ここでも「セッションIDで後からつなぎ直せる」という耐久設計が効いています。

既存フレームワークとの位置づけ

eveは、Vercel AI SDK・Cloudflare Agents SDK・OpenAI Agents SDK、さらにLangGraphやCrewAI、AutoGenといった既存のエージェント基盤と比較されます。役割の違いを整理すると次の通りです。

eveは内部的にAI SDKを使っているため、両者は競合というよりレイヤーが異なる関係です。AI SDKが「モデルとツールを扱う部品」だとすると、eveは「その部品を使って本番エージェントを丸ごと組み上げる枠組み」です。

Vercel自身は、eveの差別化ポイントとして「耐久実行・サンドボックス化されたコード実行・組み込みの評価（evals）・承認・スケジュール・デプロイを、ファイルシステムを軸にした1つのフレームワークへ統合した」点を挙げています。個々の機能は他のフレームワークにもありますが、それらを規約ベースで束ねているのが特徴です。

Vercelの各機能との関係

eveは単体で完結するというより、Vercelの各プリミティブの上に乗る形で本番運用を支えます。公式ドキュメントで確認できた関係は次の通りです。

• AI Gateway: モデル文字列の解決とフォールバックを担う
• Workflows: セッションの耐久実行とリプレイによる状態復元
• Vercel Functions / Fluid Compute: 長時間・逐次ストリーミングなエージェントのターンを実行
• Vercel Sandbox: モデル生成コマンドを隔離実行するmicroVM（ローカルではDocker、本番ではVercel Sandbox）
• Vercel Connect: ユーザー/チーム資格情報の委譲
• Agent Runs: Vercelダッシュボード上でセッション・ターン・ツール呼び出し・トークン使用量を可視化

チャネルはHTTPやSlackのほか、Discord・Teams・Telegram・GitHubなどに対応し、connectionsは MCP サーバーやOpenAPI仕様を扱えます。Slack・GitHub・Snowflake・Salesforce・Notion・Linearといった事前統合も用意されています。

どんな時に向くか・現時点の注意点

eveが向いているのは、次のようなケースです。

• Vercel上でエージェントを本番運用したい（デプロイ・可観測性・サンドボックスを自前で組みたくない）
• 会話やタスクが長時間にわたり、途中で落ちても再開できることが重要
• ツールやスキルを継続的に増やしていく前提で、コードベースを見通しよく保ちたい
• 承認フローやスケジュール実行、サブエージェントへの委譲を標準機能で使いたい

一方で、現時点の注意点も明確です。

• ベータである点。API・挙動・ドキュメントはGA前に変更されうるため、本番投入は変更追従のコストを見込む必要があります
• Vercelのプリミティブ（Workflows・Functions・Sandbox・AI Gateway等）に強く結びついており、他基盤への移植を前提にすると恩恵が薄れます
• 料金は利用するVercelリソースに依存するため、サンドボックスや長時間ターンのコストは事前に見積もっておくべきです

TypeScriptとZodが前提になるため、型の基礎を固めておくと導入がスムーズです。エージェント設計そのものの考え方は、LangChain/LangGraph系の実践書などで補うと、フレームワークをまたいで応用が効きます。

まとめ

eveは、「エージェント＝ファイルの集まり」というシンプルな規約と、Workflowsによる耐久・再開可能なセッションを組み合わせた、Vercel製のオープンソースエージェントフレームワークです。ツールは1つのTypeScriptファイル、スキルは1つのMarkdownファイルとして表現し、ディレクトリを見ればエージェントの全体像がわかる設計は、コードベースが育っても見通しを保ちやすいのが魅力です。

一方でまだベータであり、Vercel基盤への依存も強いため、採用は「Vercel上での本番エージェント運用」という文脈で検討するのが現実的です。Vercel AI SDKとの役割の違い、そしてCloudflare Agents SDKやOpenAI Agents SDKといった競合との比較も踏まえつつ、自分たちのユースケースに合うかを見極めてください。最新の仕様は必ず公式ドキュメント（eve.dev/docs、vercel.com/docs/eve）とGitHubのリリースで確認することをおすすめします。