Vercelが公開した Eve は、AIエージェントを「作る」「動かす」「運用する」ための open-source framework です。InfoQの記事を読んでまず感じたのは、これが単なる新顔の開発ツールではなく、「AIエージェント周りで毎回バラバラに作っていた面倒ごとを、かなりまとめて面倒みる」方向に振り切っていることです。
AIエージェントは、チャットするだけのAIとは少し違います。指示を受けて、外部サービスにつながり、必要ならコードを実行し、途中で止まったら再開し、定期実行までこなす。便利だけれど、裏側はわりと泥臭い。Eveはその泥臭さを、filesystem-first という考え方で整理しようとしています。要するに、エージェントの振る舞いを「フォルダとファイル」で表現する発想です。これ、かなりVercelらしいと私は思います。開発者が触るものを、なるべく普通のプロジェクト構造に寄せるのがうまい。
Eveの面白さは、「AIエージェントの設計図を、コードだけでなくファイル群として扱う」点にあります。
たとえば、エージェントへの指示は Markdown で書く。tool は TypeScript の file として置く。再利用する知識は skill としてまとめる。さらに subagent を別ディレクトリに切り出せる。build 時に framework がそれらを自動で見つけて、エージェントに渡してくれるので、毎回手で登録コードを書く必要が減るわけです。
この設計、地味に見えてかなり大きいと思います。というのも、AIエージェントの実装って、実際には「モデル呼び出し」そのものよりも、その周辺の配線が重いからです。どの tool を使えるのか、どの権限で動くのか、失敗したらどう戻るのか、ログはどこに残すのか。そういう話で時間が溶ける。Eveはそこを最初から面倒みるので、開発者はエージェントの中身に集中しやすくなります。
InfoQの記事で特に目を引くのは、Eveが production 向けの要素をかなり厚く持っていることです。
たとえば durable execution。これは「途中で止まっても、最後まで面倒を見てくれる実行方式」くらいに捉えるとわかりやすいです。エージェントが会話の途中で止まったり、デプロイが入ったりしても、最後に終えた step から再開できる。AIの世界では、ここがかなり重要です。チャットは気軽でも、業務処理は一発勝負では困るので。
さらに sandboxed code execution もある。エージェントが生成したコードを、隔離された安全な環境で動かす仕組みです。local なら Docker など、production なら Vercel Sandbox を使えるとのこと。AIにコードを書かせると「便利だけど怖い」という気持ちがどうしてもつきまといますが、sandbox があると心理的なハードルはだいぶ下がります。
human approval workflows も入っています。これは、人間の承認を挟んでから次に進める仕組みです。勝手に重要な操作をされたら困る場面は多いので、実務ではかなり大事です。AIは万能な自動機械ではなく、まだまだ「人が最後に止める」場面が多い。そこをちゃんと前提にしているのは好感が持てます。
Eveは外部サービスとの連携も最初から考えています。MCP server や OpenAPI specification で定義された API に接続でき、最初の時点で Slack、GitHub、Snowflake、Salesforce、Notion、Linear などが並んでいます。しかも、追加の provider は custom adapter で足せるそうです。
ここで便利なのは、同じ agent を複数の communication channel に載せられる点です。Slack、Discord、Microsoft Teams、Telegram、GitHub、HTTP API などに対応していて、コア実装を変えずに展開できる。これは実務だとかなりありがたいはずです。社内ではSlack、外部向けにはHTTP API、みたいな使い分けが自然に出てきますから。
正直、この「いろんなチャネルに同じ中身を載せられる」という部分は、エージェントを単なる実験で終わらせないために大きいと思います。AIのデモは派手でも、実運用では“どこから呼ばれるか”が地味に重要なので。
Eveは OpenTelemetry ベースの observability も備えています。observability は難しく聞こえますが、要するに「中で何が起きたかをちゃんと見えるようにすること」です。モデルの呼び出し、tool の実行、sandbox command まで trace として記録でき、既存の監視基盤に流せるし、Vercel の observability interface でも見られるそうです。
これ、私はかなり本気度を感じます。AIエージェントの失敗って、普通のWeb APIみたいに単純ではありません。「なぜこの回答になったのか」「どの tool が変な値を返したのか」「途中でどこまで進んでいたのか」が見えないと、改善も再発防止もできないからです。
evaluation suites があるのも重要です。ローカルや CI pipeline で、デプロイ前にエージェントのふるまいを検証できる。AIは“動けばよい”では危ないので、テストに寄せていくのは自然な流れです。ここを最初から持ってくるのは、かなり実用寄りだと思います。
Eve では subagents も定義できます。専門の違うエージェントを別ディレクトリに置き、独自の instructions、tools、execution environment を持たせる。親エージェントが仕事を投げて、subagent が独立して処理し、結果を返す形です。
これは人間の組織に少し似ています。雑務も調査も判断も、全部ひとりに押し込まない。AIでも分業したほうが自然な場面は多いはずです。もちろん、分業すると複雑さも増えるので万能ではありません。ただ、複数の役割を持たせたいなら、subagent という切り方はかなり筋がいいと思います。
加えて、cron-based jobs による scheduled execution もあります。定期的に動くエージェントです。毎朝レポートを作る、毎晩データをチェックする、期限前に通知する。こういう用途は現実に多いので、ここまで入っているのは嬉しいところです。
記事では、Eveは LangGraph、CrewAI、AutoGen、Strands Agents SDK などが並ぶ混み合った市場に入っていく、と説明されています。これらも multi-agent orchestration や tool integration を備えていますが、Eveはそこに durable execution、sandboxed execution、approval、scheduling、deployment まで載せて、filesystem を中心にまとめた点が違う。
率直に言うと、Eveは「AIエージェントのロジック」だけでなく「運用を含めた足回り」を一緒に整理したい人に刺さるはずです。逆に、すでに自前の基盤がしっかりしているチームだと、どこまでVercelの流儀に乗るかは悩みどころでしょう。InfoQでも、コミュニティの反応として portability、つまりVercel外でもどれだけ持ち運べるかを気にする声が出ていました。これはかなりまっとうな懸念です。フレームワークは便利なぶん、囲い込みも起きやすいので。
私は、Eveの“ファイルシステムで組む”発想がいちばん面白いと思いました。AIエージェントって、つい魔法っぽく語られがちですが、実際は設定、権限、観測、再実行、承認、定期処理の集合体です。その現実に対して、「じゃあフォルダとファイルで整理しよう」と持っていくのはかなりわかりやすい。
しかも、Vercel自身が内部で100以上の production agents を使っているというのが強い。単なる理想論ではなく、自分たちの運用から出てきた設計に見えるからです。もちろん、外の現場でそのまま通用するかは別問題ですが、少なくとも机上の空論ではなさそうだ、という信頼感はあります。
AIエージェントの開発は、これから「どう賢くするか」だけでなく、「どう壊れにくくするか」「どう見張るか」「どう止めるか」が本番になります。Eveはその方向にかなり素直に進んでいる。派手さより実務感を優先したフレームワークとして、今後かなり気になる存在ではないでしょうか。
参考: Vercel Introduces Eve, an Open-Source Framework for Building AI Agents
