eveとは何か

eveは、Vercelが公開しているAIエージェント向けのオープンソースフレームワークです。公式ドキュメントでは、agent/ディレクトリ配下のファイルからエージェントを発見し、検証し、実行可能なアプリにまとめる「filesystem-first」なフレームワークとして説明されています。

つまり、エージェントをひとつの巨大なTypeScriptファイルや散らばった設定として扱うのではなく、プロンプト、ツール、スキル、チャネル、接続、サンドボックス、定期実行をファイル構成として読めるようにします。

agent/
  instructions.md
  agent.ts
  tools/
    get_weather.ts
  skills/
    troubleshooting.md
  channels/
    slack.ts
  connections/
    github.ts
  sandbox/
    sandbox.ts
  subagents/
    researcher/
  schedules/
    daily-report.md

この形にすると、チームでレビューするときに「このエージェントは何を読み、何を実行でき、どこから呼ばれるのか」を追いやすくなります。AIエージェントを試作コードではなく、運用対象のソフトウェアとして扱うための設計だと考えると理解しやすいです。

なぜAI SDKだけでは足りなくなるのか

Vercel AI SDKは、TypeScriptでAI機能を作るための便利なSDKです。モデル呼び出し、ストリーミング、ツール呼び出し、構造化出力などを扱えます。チャットUIやアプリ内のAI機能なら、AI SDKだけで十分なケースは多いです。

一方で、業務で使うエージェントは「モデルを呼ぶ」だけでは終わりません。Slackから起動し、社内ドキュメントを読み、外部APIを呼び、必要なら人間承認を待ち、処理を再開し、失敗時に後から追跡できる必要があります。

eveが扱うのは、このAI SDKの外側にある運用上の面倒です。公式ドキュメントでも、durable sessions、tools and skills、Agent Runs、Vercel Workflows、Vercel Sandbox、AI Gateway、Vercel Connectなどとの関係が説明されています。

本番運用で重要になる部品

eveの特徴は、AIエージェントを単なるプロンプトとツールの組み合わせではなく、長く動くバックエンド処理として扱う点にあります。Vercel上では、次のような基盤と組み合わせて動かす前提が示されています。

特に重要なのは、処理を止めたり再開したりできることです。業務エージェントは、ユーザーの追加返信、人間承認、外部サービスの応答、長時間処理を待つ場面があります。Workflowsは、処理を一時停止し、デプロイやクラッシュをまたいで再開するための土台になります。

また、エージェントがコードを生成して実行するなら、実行場所の隔離も必要です。Vercel Sandboxは、AIエージェントの出力やユーザー生成コードのような信頼しきれない処理を、プロダクション環境から切り離して動かすための計算環境です。

最小構成のeveエージェント

公式ドキュメントでは、最小構成はかなり小さく示されています。基本の振る舞いはagent/instructions.mdに書きます。

You are a concise assistant.
Use tools when they are available.

モデルなどの実行設定はagent/agent.tsに置きます。

import { defineAgent } from "eve";

export default defineAgent({
  model: "openai/gpt-5.4-mini",
});

新しく始める場合は、CLIでプロジェクトを作れます。

npx eve@latest init my-agent
cd my-agent
pnpm dev

ただし、eveは2026年7月3日時点でbetaです。API、ドキュメント、実行時の挙動は一般提供前に変わる可能性があります。本格導入するなら、小さな用途で試し、バージョン変更に追従できる範囲から始めるのが現実的です。

ツール、スキル、サブエージェントの分け方

eveでは、モデルが実行できる操作をagent/tools/に置きます。各ファイルが1つのツールになり、ファイル名が実行時のツール名になります。

import { defineTool } from "eve/tools";
import { z } from "zod";

export default defineTool({
  description: "Get the current weather for a city.",
  inputSchema: z.object({
    city: z.string().min(1),
  }),
  async execute({ city }) {
    return {
      city,
      condition: "Sunny",
      temperatureF: 72,
    };
  },
});

このファイルをagent/tools/get_weather.tsに置くと、モデルからはget_weatherというツールとして見えます。説明文は人間向けコメントではなく、モデルが「いつ使うべきか」を判断する材料になるので、曖昧にしないほうがよいです。

一方、skills/はツールではなく、必要なときだけ読み込む手順書や知識です。障害調査の手順、文章レビューの基準、SQLを書くときの社内ルールのようなものはskillに向いています。

subagents/は、親エージェントから委譲される別の子エージェントです。skillが「同じエージェントに知識を足す」ものだとすると、subagentは「別のエージェントに仕事を渡す」ものです。調査、レビュー、編集のように責務を分けたい場合に使います。

ChannelsとSchedules

業務エージェントでは、入口がチャット画面だけとは限りません。Slackから呼ばれる、HTTP APIとして呼ばれる、GitHubイベントを受ける、定期実行で毎朝レポートを作る、といった入口が必要になります。

eveでは、こうした入口もagent/channels/やagent/schedules/としてファイルで表現します。同じエージェントの実行単位を、Slack、HTTP、cronのような複数の入口から動かせる点が重要です。

これにより、エージェントを「人間が話しかけたときだけ返すチャットボット」ではなく、「外部イベントや時間をきっかけに継続的に動く業務プロセス」として設計しやすくなります。

観測性がないと運用できない

AIエージェントは、通常のAPIよりも挙動を追いにくくなります。モデルがどの文脈で判断したのか、どのツールを呼んだのか、ツールの引数と結果は何だったのか、人間承認の前後で何が起きたのかを後から確認できないと、業務には載せにくいです。

eveには、Vercelダッシュボード上のAgent Runsという観測画面があります。公式ドキュメントでは、実行回数、トークン使用量、トリガー種別、ターン、ツール呼び出し、推論、処理時間などを確認できると説明されています。必要であれば、agent/instrumentation.tsを追加してOpenTelemetryへ送ることもできます。

ここは単なる便利機能ではありません。エージェントに外部操作を任せるなら、ログ、トレース、トークン使用量、承認履歴を説明できることが、そのまま運用上の安全性になります。

導入時に気をつけたいこと

元稿では「Vercelの基盤に寄る」と書きましたが、ここは少し丁寧に見る必要があります。Vercel公式ドキュメントでは、Vercel上で動かす場合にWorkflows、Sandbox、AI Gateway、Connect、Observabilityを使う構成が示されています。一方で、eve.devは自己ホスト可能性にも触れています。

したがって、実務上の見方としては「Vercel上で使うとAgent Stackと強く統合される。Vercel以外で使う余地もあるが、運用基盤は自分で設計する必要がある」と捉えるのがよさそうです。

まとめ

eveは、AIエージェントをagent/ディレクトリとして定義し、instructions、tools、skills、subagents、channels、connections、sandbox、schedulesをファイル構成で整理するフレームワークです。

AI SDKが「AI機能を実装するためのSDK」だとすれば、eveは「AIエージェントを運用可能なソフトウェア単位として扱うためのフレームワーク」です。長時間実行、再開、隔離、外部連携、人間承認、観測性まで視野に入っている点が、単発のチャットボット実装との大きな違いです。

まだbetaなので、本番の中核にいきなり置くより、まずはSlack通知、PRトリアージ、定期レポートのような小さな業務エージェントから試すのがよいと思います。重要なのは、LLMを呼ぶことではなく、任せても追跡でき、止められ、直せる形にすることです。eveは、その方向性を学ぶうえでもよい題材です。