結論：Vercel Eveは「Next.js以来の衝撃」と呼ばれるに値する
2026年6月、Vercelが突如公開したオープンソースのAIエージェントフレームワーク「Eve」が開発者コミュニティに大きな波紋を広げている。「Next.js for agents」と評されるこのフレームワークの核心は、エージェントをファイルシステムで表現するという発想の転換にある。
従来のエージェントフレームワークがコードベースやグラフ定義に依存していたのに対し、Eveはinstructions.md、tools/、skills/といった普通のファイルとフォルダでエージェント全体を構成する。この発想は、Next.jsがpages/ディレクトリでルーティングを革命したのと同じ設計哲学だ。
本記事では、Vercel Eveのアーキテクチャ、クイックスタート、主要フレームワークとの比較、本番運用のポイントまでを網羅する。
Vercel Eveとは — 「エージェント = フォルダ」の発想
Vercel Eveは、2026年6月中旬にApache 2.0ライセンスでGitHubで公開されたTypeScriptベースのAIエージェントフレームワークだ。Vercel自身が社内で100以上のエージェントを本番運用しており、その実績を土台にしている。
最大の特徴はfilesystem-first（ファイルシステム駆動）アーキテクチャ。エージェントの定義・ツール・スキル・サブエージェント・スケジュール・メモリまで、すべてがディレクトリ内のファイルとして表現される。
VercelのCEO Guillermo Rauchは発表ブログで「エージェントはソフトウェアプロジェクトであり、単なるプロンプトではない」と述べており、この哲学がEveの設計全体を貫いている。
Vercel社内の実績として、データアナリストエージェントが月間3万件以上のSlack質問を処理、サポートエージェントがチケットの92%を自律解決、営業エージェントが明確なROIを出しているという。これらはPoCではなく実運用の数字である点が重要だ。
なぜファイルシステムなのか
この設計には3つの明確な理由がある：
- LLMはファイルシステム操作が得意 — モデルはMarkdownの読み書き、TypeScriptの解釈、シェル操作に習熟している。ファイルシステムはLLMにとって最も自然なインターフェースの一つだ。
- Git/PRで管理できる — エージェントの変更がコードレビュー可能、差分追跡可能、ポータブルになる。プロンプト変更もツール追加も、すべてコードレビューの対象になる。
- デバッグが「ファイルを読むだけ」 — 状態・チェックポイント・実行ログがすべてファイルとして可視化される。ベンダーロックインされた管理画面やデータベースに隠された状態を持たない。
ディレクトリ構造 — エージェントの全貌がここにある
Eveでエージェントを初期化すると、以下のようなディレクトリが生成される。この構造自体がエージェントの「仕様書」だ：
my-agent/
├── agent.ts # モデル、温度、メタデータ
├── instructions.md # システムプロンプト/ペルソナ
├── tools/ # 1ファイル = 1ツール
│ ├── query-db.ts
│ ├── create-linear-issue.ts
│ └── analyze-pr-diff.ts
├── skills/ # 参照用ナレッジベース
│ ├── coding-standards.md
│ └── company-policies.md
├── subagents/ # 委譲用の子エージェント
│ ├── code-reviewer/
│ └── qa-reviewer/
├── channels/ # Slack/Discord/GitHub統合
├── schedules/ # cron的定期実行定義
├── sandbox/ # サンドボックス実行ポリシー
├── evals/ # 評価スイート
└── memory/ # 永続メモリ・チェックポイント
重要なのは、ファイル名と場所が仕様そのものである点。ツールを追加したければ tools/ にTypeScriptファイルを置くだけ。スキルを追加したければ skills/ にMarkdownを置くだけ。中央レジストリや巨大な設定ファイルは不要だ。
また、状態もファイルとして永続化される。エージェントの実行チェックポイント、サブエージェントのセッション情報、サンドボックスの出力、監査ログ——これらすべてがディスク上のファイルとして残る。データベースや専用ストレージへの依存がないため、バックアップも移行も標準的なファイル操作で完結する。
クイックスタート — 3コマンドでエージェント起動
Eveの開発体験は極限までシンプルに設計されている。以下3ステップでエージェントが動き始める：
# 1. プロジェクト初期化
npx eve@latest init my-agent
cd my-agent
# 2. ローカル開発（TUI + 開発サーバー付き）
eve dev
# 3. 本番デプロイ
vercel deploy
eve dev を実行すると、ターミナルUIと開発サーバーが立ち上がり、instructions.md を編集しながらリアルタイムでエージェントの動作を確認できる。プロンプトエンジニアリングのイテレーションが驚くほど速い。
コミュニティからはAtlas Eve StarterのようなTurborepoベースのテンプレートも登場しており、Zodスキーマ、Biome/Vitest/Husky、AIコンテキストファイルを同梱した本格的な開発環境が整備されつつある。
ツール定義の実例
tools/ 配下のファイルは型安全に記述する。以下はLinearでIssueを作成するツールの最小実装例だ：
// tools/create-linear-issue.ts
import { tool } from "eve";
import { LinearClient } from "@linear/sdk";
export const createLinearIssue = tool({
name: "create_linear_issue",
description: "Linearに新しいIssueを作成する",
parameters: {
title: { type: "string", required: true },
description: { type: "string" },
teamId: { type: "string", required: true },
},
async execute({ title, description, teamId }) {
const linear = new LinearClient({ apiKey: process.env.LINEAR_API_KEY });
const issue = await linear.createIssue({ title, description, teamId });
return { id: issue.id, url: issue.url };
},
});
このファイルが tools/ に置かれていれば、Eveランタイムが自動的に検出し、エージェントから呼び出し可能になる。登録作業ゼロ。Next.jsのpages/と同じ発想だ。
サブエージェントによるタスク委譲
Eveでは複雑なタスクをサブエージェントに委譲できる。各サブエージェントは独立したinstructions.mdとtools/を持ち、親エージェントから「ファイルとして」タスクを受け取り、結果をファイルとして返す：
// 親エージェントがコードレビューを委譲する例
// instructions.md 内で定義
When asked to review a PR:
1. Write the PR diff to subagents/code-reviewer/task.md
2. Invoke the code-reviewer subagent
3. Read the result from subagents/code-reviewer/result.md
この「ファイルを介した委譲」パターンは、デバッグのしやすさと監査証跡の自動生成という副次的効果ももたらす。
主要フレームワークとの比較 — Eve vs LangGraph vs CrewAI
2026年のAIエージェントフレームワークは大きく3つのアプローチに分かれる。それぞれ設計思想が異なるため、ユースケースに応じた選択が重要だ。
| 観点 | Vercel Eve | LangGraph | CrewAI |
|---|---|---|---|
| パラダイム | ファイルシステム駆動 | グラフベース | ロールベース |
| 言語 | TypeScript | Python（JSも対応） | Python |
| 学習曲線 | 低（ファイルを書くだけ） | 中〜高（グラフ定義） | 低（ロール定義） |
| 永続実行 | ◎ 組み込みチェックポイント | ◎ カスタマイズ可能 | △ 追加実装必要 |
| サンドボックス | ◎ デフォルト搭載 | △ 別途実装 | × 非搭載 |
| HITL | ◎ 標準機能 | ◎ interrupt/resume | △ 基本のみ |
| 可観測性 | ◎ OpenTelemetry内蔵 | ◎ LangSmith連携 | △ 限定的 |
| 運用環境 | Vercel最適化 | 環境非依存 | 汎用Python環境 |
| 成熟度 | 新規（2026年6月〜） | 高い（Uber等で実績） | 中程度 |
どれを選ぶべきか
- Vercel Eveを選ぶ場合：TypeScript/Next.jsエコシステムにいる。プロトタイプから本番までスピード重視。永続実行・サンドボックス・HITLをフレームワークに任せたい。エージェントをGit管理しPR文化に乗せたい。
- LangGraphを選ぶ場合：複雑な条件分岐・循環フローが必要。状態管理を細かく制御したい。Pythonエコシステムが必須。Uber、Klarna、LinkedIn級の本番信頼性を求める。詳細はLangGraph公式ドキュメントを参照。
- CrewAIを選ぶ場合：ロールベースのマルチエージェントを手軽に試したい。開発者以外のメンバーもエージェント定義に関わる。短期プロトタイピングが目的。詳細はCrewAI公式ドキュメントを参照。
本番運用で光る5つの機能
Eveの真価は「プロトタイプがそのまま本番になる」点にある。以下の5機能が、それを可能にしている。
1. 永続チェックポイント実行
長時間実行エージェントの状態が自動的にファイルシステムにチェックポイントされる。クラッシュ・再起動・再デプロイ後も中断箇所から再開する。これはVercel Workflowsとの統合で実現されており、手動でのステート管理実装が不要になる。
具体的には、エージェントが複数ステップのタスクを実行中にプロセスが終了しても、次の起動時に最後のチェックポイントから自動的に再開する。データベース障害やネットワーク断が発生しても、冪等性のある復旧が保証される。
2. サンドボックス実行
エージェントが生成・実行するコードはsandbox/のポリシーに従って隔離実行される。ファイルシステムアクセス、ネットワーク、プロセス起動などを細かく制限できる。信頼できない入力を扱うエージェントに必須の機能だ。
3. Human-in-the-Loop承認
副作用のある操作（デプロイ、支払い、外部APIの破壊的変更）に対して、自動的に人間の承認を要求する。ツール定義にrequiresApproval: trueを追加するだけで有効になる。承認待ちの間はトークンを消費しない設計だ。
4. 組み込み評価（Evals）
evals/ディレクトリにテストケースを置くだけで、エージェントの品質を継続的に検証できる。プロンプト変更時のリグレッションテストとして機能し、CIパイプラインに組み込める。
5. チャネルとスケジュール
Slack、Discord、GitHub webhook、メールなどをchannels/で宣言するだけで統合できる。schedules/ではcronライクな定期実行を定義。エージェントが「常駐のチームメイト」として自律的に動き続ける。朝9時に日次レポートをSlackに投稿、PR作成時に自動コードレビュー、といったユースケースが設定ファイルなしで実現できる。
実運用ユースケース — Vercel社内の数字
Vercelが公式ブログで公開している社内導入事例は、Eveの説得力を裏付ける：
- データアナリストエージェント：月間30,000件以上のSlack質問に対応。Lookerやデータベースへのクエリ実行からグラフ生成まで自律処理
- サポートエージェント：チケットの92%を自律解決。エスカレーションが必要なケースのみ人間の担当者に転送
- 営業エージェント：明確なROIを達成。CRM更新、フォローアップメール、商談準備を自動化
- デプロイエージェント：Vercelのデプロイのかなりの部分がエージェント経由で実行されている
注意点と制約
Eveは強力だが、以下の制約を理解した上で採用判断すべきだ：
- Vercelエコシステム依存：本番機能の多くがVercelランタイム（Sandbox、Workflows）に依存する。コアはオープンソースだが、フル機能を使うにはVercelへのデプロイが前提
- TypeScript限定：Python版やコミュニティ移植は存在するが、本家はTypeScript。Pythonエコシステム中心のチームには学習コストが発生する。ただし、LangGraph向けにEveのファイルシステム駆動パターンを移植した「Leve」プロジェクトも登場しており、設計思想の波及は始まっている
- リリース直後：公開から2週間程度のため、コミュニティ資産・ベストプラクティス・エッジケース対応はこれから蓄積される段階
- 大規模マルチエージェントの実績不足：社内100+エージェントの実績はあるが、数千エージェント規模の公開事例はまだない
まとめ — エージェント開発の民主化
Vercel Eveは「ファイルを書く = エージェントを作る」というシンプルさで、AIエージェント開発の参入障壁を大きく下げた。Next.jsがWebアプリ開発を民主化したように、Eveはエージェント開発を民主化する可能性を秘めている。
特に以下のようなチームに強く推奨する：
- Next.js/TypeScriptスタックで開発している
- 社内向けツール・サポート・営業エージェントを素早く本番化したい
- エージェントをGit管理し、コードレビュー文化に乗せたい
- 永続実行・サンドボックス・承認フローを自前実装したくない
一方、Python中心のチームや複雑なグラフ型ワークフローが必要な場合は、LangGraphの方が適している。EveとLangGraphは競合というより補完関係にある。実際、Eveのファイルシステム駆動パターンをLangGraph上に再現するLeveプロジェクトも登場しており、この設計思想の影響力は広がっている。
Vercel Eveは公開からまだ間もないが、「エージェントをファイルとして扱う」という発想は、この分野のデファクトスタンダードになる可能性が高い。今のうちに触っておく価値は十分にある。
関連記事
- AIエージェントガードレール比較2026｜選び方完全ガイド
- AIエージェントメモリ比較2026｜Mem0・Letta・Zep選び方ガイド
- Grokマルチエージェント実装ガイド｜4/16エージェントの使い分け【2026】
この記事を読んでAIエージェントの導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。フレームワーク選定から本番運用設計まで、開発チームに合わせた支援を提供します。
Eveの内部動作 — チェックポイントと状態管理の仕組み
Eveの永続実行を支える技術的な仕組みを理解しておくと、トラブルシューティングやカスタマイズに役立つ。
チェックポイントの粒度
Eveのチェックポイントはツール実行の前後で自動的に作成される。具体的には：
- ツール呼び出し前：現在の状態（メッセージ履歴、メモリ内容、サブエージェントの状態）をJSONファイルとして
memory/checkpoints/に保存 - ツール実行：サンドボックス内でツールを実行
- ツール実行後：結果と更新された状態を再度チェックポイント
この仕組みにより、ツール実行中にクラッシュしても、前回のチェックポイントから安全に再開できる。チェックポイント間隔はagent.tsでカスタマイズ可能だ。
メモリの階層構造
Eveのmemory/ディレクトリは以下の3層で構成される：
- ワーキングメモリ（
memory/working/）：現在のセッションのコンテキスト。タスク完了時にクリア - エピソードメモリ（
memory/episodes/）：過去のタスク実行履歴。日付ベースのファイル名で自動管理 - セマンティックメモリ（
memory/knowledge/）：永続的に保持すべき知識。skills/と連携して動的に更新
各層が独立したファイルとして管理されるため、不要になったメモリの削除や、特定エピソードの検索が極めて容易だ。
他フレームワークからの移行ガイド
既存のLangGraphやCrewAIで構築したエージェントをEveに移行する場合のポイントを整理する。
LangGraphからの移行
LangGraphのグラフ定義をEveに移行する際の基本的な考え方は「ノード→ツール」「エッジ→指示」の変換だ：
- StateGraphの各ノード →
tools/ディレクトリ内の独立したツールファイルとして実装 - 条件付きエッジ →
instructions.md内の条件分岐として自然言語で記述 - Checkpointer → Eveのビルトインチェックポイントに置き換え（コード削減）
- LangSmithによる可観測性 → EveのOpenTelemetry + Vercel Observabilityに移行
移行の最大のメリットは、LangGraphで数百行必要だった状態管理・エラーリカバリ・永続化のコードがほぼゼロになる点だ。
CrewAIからの移行
CrewAIのロールベース設計はEveのサブエージェントと自然に対応する：
- Agent（役割定義） →
subagents/<role>/instructions.md - Task（タスク定義） → 親エージェントの
instructions.mdに委譲ルールとして記述 - Crew（チーム編成） →
subagents/のディレクトリ構造そのものがチーム定義になる
エコシステムとコミュニティの現状
公開から2週間で、Eveのエコシステムは急速に形成されつつある。注目すべき動きを紹介する。
コミュニティテンプレート
Atlas Eve Starterは最も充実したコミュニティテンプレートだ。Turborepoによるモノレポ構成、共有Zodスキーマ、Biome/Vitest/Huskyによる品質管理、AIコーディングエージェント向けのコンテキストファイルまで完備している。Eveの学習を始めるなら、このテンプレートから始めるのが効率的だ。
言語拡張
EveはTypeScriptネイティブだが、設計思想の波及はPythonエコシステムにも及んでいる。LangChainのHarrison Chaseが公開したLeveは、Eveのファイルシステム駆動パターンをLangGraph上に移植したPythonライブラリだ。Eveのコアアイデアが「ファイルシステム駆動エージェント」という新しいカテゴリを形成しつつある。
導入前に確認すべき5つの質問
Eveの採用を検討する前に、以下の質問に答えておくと判断がブレない：
- チームはTypeScript/Next.jsに習熟しているか — YesならEveの学習コストは極小。NoならLangGraphの方が馴染む可能性が高い
- エージェントの実行時間は数分を超えるか — 長時間実行が必要ならEveのチェックポイント機能が真価を発揮する
- Vercelへのデプロイは許容されるか — フル機能を使うにはVercel前提。オンプレミス要件がある場合は注意
- エージェント定義を非エンジニアも触るか — Markdownベースの
instructions.mdは非エンジニアにも編集しやすい - マルチエージェントの複雑さはどの程度か — シンプルな委譲ならEveで十分。複雑な循環依存があるならLangGraph
実践ワークフロー — PRレビューエージェントを30分で構築する
Eveの真価を理解するには、実際に手を動かすのが一番だ。ここではGitHubのPRを自動レビューするエージェントを構築する手順を解説する。
ステップ1：プロジェクト初期化（2分）
npx eve@latest init pr-reviewer
cd pr-reviewer
ステップ2：instructions.mdの作成（10分）
エージェントの「人格」と「仕事の進め方」を定義する：
# PR Reviewer Agent
You are an expert code reviewer. When a new PR is opened:
1. Read the PR diff from the GitHub webhook payload
2. Analyze the changes for:
- Code quality and readability
- Potential bugs or edge cases
- Security vulnerabilities
- Performance implications
- Test coverage adequacy
3. Write your review to a comment on the PR
4. If critical issues found, request changes; otherwise approve
## Review Guidelines (from skills/coding-standards.md)
Always check against our team's coding standards.
ステップ3：ツール実装（10分）
GitHub APIを呼び出すツールをtools/に追加する。PRのdiff取得、レビューコメント投稿、承認/変更要求の3つが必要だ：
// tools/get-pr-diff.ts
import { tool } from "eve";
export const getPRDiff = tool({
name: "get_pr_diff",
description: "指定されたPRのdiffを取得する",
parameters: {
owner: { type: "string", required: true },
repo: { type: "string", required: true },
prNumber: { type: "number", required: true },
},
async execute({ owner, repo, prNumber }) {
const res = await fetch(
`https://api.github.com/repos/${owner}/${repo}/pulls/${prNumber}`,
{ headers: {
Authorization: `Bearer ${process.env.GITHUB_TOKEN}`,
Accept: "application/vnd.github.v3.diff"
}}
);
return { diff: await res.text() };
},
});
ステップ4：サブエージェントの追加（5分）
セキュリティレビューは専門性が高いため、専用のサブエージェントに委譲する：
# subagents/security-reviewer/instructions.md
You are a security-focused code reviewer.
Analyze code changes for:
- OWASP Top 10 vulnerabilities
- Injection risks (SQL, command, etc.)
- Authentication/authorization issues
- Sensitive data exposure
- Insecure dependencies
Report findings with severity: CRITICAL/HIGH/MEDIUM/LOW
ステップ5：GitHubチャネルの設定（3分）
channels/ディレクトリにGitHub webhookの設定を追加する。PRのopenイベントとsynchronizeイベントをトリガーに設定し、エージェントが自動的に起動するようにする。
ステップ6：デプロイと動作確認
vercel deploy
デプロイ後、GitHubリポジトリのWebhook設定にVercelのデプロイURLを登録すれば完了だ。実際にPRを作成すると、30秒以内にレビューコメントが自動投稿される。
このワークフロー全体で書いたコードはツール定義のTypeScript約30行と、instructions.md約15行。残りはすべてファイルを置くだけの宣言的設定だ。LangGraphで同様のエージェントを構築する場合に比べて、コード量は約5分の1に抑えられる。
コスト試算 — Eve vs 自前実装
Eveの採用判断で重要なのがコストだ。自前で永続実行・サンドボックス・HITL・可観測性を実装した場合と、Eveに任せた場合の開発工数を比較する。
| 機能 | 自前実装の概算工数 | Eve利用時の工数 |
|---|---|---|
| 永続チェックポイント（クラッシュ復旧） | 3〜5人日 | 0（標準機能） |
| サンドボックス実行環境 | 5〜10人日 | 0（標準機能） |
| Human-in-the-Loop承認フロー | 2〜3人日 | 0（標準機能） |
| OpenTelemetry可観測性 | 3〜5人日 | 0（標準機能） |
| Slack/Discord連携 | 1〜2人日 | 0（channels/設定のみ） |
| 評価パイプライン | 2〜3人日 | 0（evals/設定のみ） |
| 合計 | 16〜28人日 | 0人日 |
Vercel Proプラン（月額20ドル〜）にEveを載せるだけで、上記のインフラ工数が丸ごと削減できる。小規模チームほど、この「運用インフラの丸投げ」効果は大きい。
今後の展望 — Eveが変えるエージェント開発の未来
Eveの登場は、AIエージェント開発における「Next.jsモーメント」だと多くの開発者が評している。その理由を3つの軸で整理する。
1. エージェント開発の「フルスタック化」
Next.jsがフロントエンドとバックエンドの境界を溶かしたように、Eveは「プロンプト」と「コード」の境界を溶かしつつある。instructions.mdという自然言語と、tools/*.tsというコードが、同じディレクトリ内でシームレスに共存する。これはプロンプトエンジニアとソフトウェアエンジニアの協業を根本から変える可能性がある。
2. 「エージェント = プロジェクト」の標準化
Gitリポジトリをクローンすれば誰でも同じエージェントを動かせる。この再現性の高さは、オープンソースのエージェントテンプレートやマーケットプレイス的なエコシステムの土台になる。実際、Atlas Eve Starterのようなコミュニティテンプレートは、この方向性を強く示唆している。
3. 運用負荷の構造的削減
永続実行・サンドボックス・HITL・可観測性が「デフォルトでついてくる」ことで、エージェント開発者が本質的な設計（どのようなツールを与えるか、どのような判断を任せるか）に集中できるようになる。これは、HerokuがPaaSの概念を確立した時のような、運用パラダイムの転換だ。
