eve の紹介：エージェント構築・実行・スケーリングのためのオープンソースフレームワーク

本日、私たちはエージェントの構築、実行、スケーリングのためのオープンソースフレームワーク「eve」をご紹介できることを誇りに思います。eve は、生産環境で動作させるために必要なすべての部品を組み立てるのではなく、エージェントが何をするかを定義することこそが重要であるという考えに基づいて設計されています。代わりに、eve にはすでに生産環境向けの機能が組み込まれています： 永続的な実行（Durable execution） サンドボックス化された計算リソース（Sandboxed compute） 人間による承認（Human-in-the-loop approvals） サブエージェント（Subagents） 評価機能（Evals） その他多数の機能 eve は、私たちが自社のエージェントを構築・実行するために使用するフレームワークです。 現在のアージェントは、ウェブがフレームワーク登場前の状態だったようなもので、誰もが同じ基盤部分を独自に作り上げており、次のプロジェクトへ引き継ぐものがありません。Next.js がウェブのこの状況を終焉させたように、eve もアージェントの世界で同様の役割を果たします。 エージェントとはディレクトリのことです これが eve のエージェントです。 各ファイルはエージェントの構成要素の一つを記述しており、一目見ただけでツリー構造から、そのエージェントが何者であり、何をし、どこに存在し、いつ自律的に行動するかを知ることができます。 数分で eve エージェントを作成 すべてのエージェントは定義から始まります。 agent.ts ファイルでは、エージェント自体の設定を行います。モデルは一行で定義でき、AI Gateway を通じてプロバイダーのフォールバックもサポートされています。また、コンパクションやモデルオプション、その他の任意フィールドも必要な時に用意されています。 エージェントに仕事と個性を与えることは、instructions.md ファイルを作成するだけで簡単です。このファイルは、eve がすべてのモデル呼び出しの前に配置するシステムプロンプトとして機能します。 あなたは、エージェントが行う作業のためにファイルを作成します。例えば、ツールやスキルには post_chart.ts や revenue-definitions.md といったファイルがあり、eve はこれらをボイラープレートや管理用の配管コードなしで動作するエージェントに接続します。あなたは、エージェントが「どのように」行うかではなく、「何を」行うかに集中できるのです。 なぜ eve を作ったのか 私たちは Vercel で長年、v0 なども含めてエージェントを構築してきました。しかし、コーディングエージェントによって誰にでもエージェントを作れるようになると、誰もがそれを行うようになりました。私たちは数百のエージェントと社内アプリをリリースし、まるで生産性の革命が起きたかのような状況でした。 しかしその裏側では、各チームはエージェントが何らかの作業を開始する前に、同じ配管コードを何度も構築・再構築しており、あるユースケースから次のユースケースへ引き継ぐものは一つもありませんでした。各エージェントは異なるタスクのために設計されていましたが、必要な要件や構造は共通しており、それに応えるための同じパターンが繰り返し現れていました。エージェントには一定の形状があるのです。 eve とは、その形状をフレームワーク化したものです。ソフトウェアのどの世代も、十分な数の人が同じものを苦労して構築した時点で、その抽象化を獲得します。そして今、エージェントにもそれが訪れています。 標準装備された機能 プロダクションでエージェントが必要とするものはすべて、このフレームワークに同梱されています。 すべての会話に対する永続的なセッション エージェントは人間を待機し、低速なシステムを呼び出し、数時間から数日、あるいは数週間実行されることがあります。eve では、すべての会話が永続的なワークフローとして扱われ、各ステップがチェックポイントされます。これにより、セッションは一時停止したり、クラッシュやデプロイを生き延びたり、停止した場所から正確に再開したりできます。この耐久性は、オープンソースの Workflow SDK を基盤としています。 すべてのエージェントに対するサンドボックス エージェントが作成するコードは信頼できないものとして扱うべきであるため、eve はエージェント生成のコードをアプリケーションランタイムから完全に排除します。各エージェントには独自のサンドボックスが用意され、シェルコマンド、スクリプト、ファイルの読み書きのための隔離された環境となります。これは、エージェントを制御するハーンとは別のセキュリティコンテキストで実行されます。このサンドボックスの背後にあるバックエンドはアダプターです。デプロイ時には Vercel Sandbox 上で動作し、ローカルでは Docker、microsandbox、または just-bash で動作します。また、他のプロバイダー向けに独自のアダプターを作成することも可能です。 人間による承認（Human-in-the-loop approvals） エージェントは実際のシステムに対してアクションを実行しますが、その一部には人の承認を必要とするものがあります。eve 内のあらゆるアクションは承認を必須に設定可能であり、エージェントはその時点で一時停止して待機します。必要な場合は無期限に待機し、計算リソースは一切消費しません。承認が行われれば、eve は中断した地点からすぐにタスクを再開します。 ツール、データ、サービスへの安全な接続 エージェントはバックエンド、データ、およびその他のサードパーティ製サービスへ接続する必要があります。eve において、接続とは MCP サーバーまたは互換性のある OpenAPI ドキュメントを持つ任意の API を指し示すファイルです。 eve はリモートツールを発見し、モデルに手渡し、認証を仲介しますが、モデルは接続の URL や資格情報を決して知りません。Vercel Connect は、同意とトークンリフレッシュが組み込まれたインタラクティブな OAuth を処理します。ローンチ時点では、eve エージェントは Slack、GitHub、Snowflake、Salesforce、Notion、Linear に接続でき、OAuth、API キー、または MCP サーバーを介して到達可能な他のあらゆるものにも接続できます。 すべてのチャネルで同じエージェント ほとんどのエージェントはちょうど 1 つの場所にしか存在しません。なぜなら、新しい表面（サーフェス）ごとに独自の統合を構築する必要があるからです。eve では、同じエージェントがすべての表面を担当し、各チャネルは小さなアダプターファイルに過ぎません。HTTP API はデフォルトで有効になっており、Slack、Discord、Teams、Telegram、Twilio、GitHub、Linear が含まれており、defineChannel でカスタムチャネルを定義できます。1 つのチャネルが別のチャネルへハンドオフすることも可能なので、インシデント Webhook が Slack 内で調査スレッドを開くことができます。 組み込みのトレーシングと評価 エージェントが何かを間違えた場合、最初の質問は「実際にエージェントは何をしたのか」です。eve では、すべての実行でトレースが生成されます。各モデル呼び出しとツール呼び出しは、その入力と出力とともに順序立てて表示され、サンドボックス内でエージェントが実行したコマンドに至るまで詳細に記録されるため、ログから断片的に組み立てるのではなく、実行を再生することができます。 スパンは標準的な OpenTelemetry 形式であり、Braintrust、Honeycomb、Datadog、Jaeger など、すでに運用中の任意のトレーシングサービスへエクスポートできます。Vercel では、これらは「Observability」セクション内の「Agent Runs」タブに表示され、すべてのセッションを一元で監視し、特定のランを詳細に調査できる場所を提供します。Evals を利用すればさらに先へ進み、ローカルで実行したり CI に組み込んだりできる、スコアリング付きのテストスイートを作成できます。 残されたのは、どのフレームワークも代わりに記述できない部分です：つまり、あなたのエージェントが実際に何を行うかという点です。 エージェントをファイルごとに拡張する エージェントに機能を持たせる最も一般的な方法は、ツールを与え、スキルを使ってその機能を教えることです。今日では、これはツールの構築、スキルの記述、そしてそれら両方をエージェントループを実行する環境に接続することになります。eve では、ツールは 1 つの TypeScript ファイルで、スキルは 1 つの Markdown ファイルとして定義されます。 欠けているものにご注意ください。これらの接続や登録のためにすべてのボイラープレートコードを書く代わりに、eve がそれを代行してくれます。 ファイルの名前とツリー内での位置がその定義となります。eve はビルド時にツールとスキルを認識し、モデルにそれらの説明を手渡し、あとはモデル自身で処理を進めます。Next.js がルーティングを管理することでフォルダをルートに変えるように、eve もエージェントループを管理することでファイルを機能へと変換します。 人間による承認プロセスの追加 アクションに対する承認の要求は、ツールにおける 1 つのフィールドに過ぎません。 これで、高コストなクエリや破壊的な書き込み、あるいは監督なしで実行したくないあらゆる操作を保護できるようになりました。 エージェント自身にコードを書かせる 定義したツールが上限ではありません。eve はエージェントに実際のコンピュータとシェルを提供し、bash や grep、ターミナルで実行するあらゆるものを動かすことができます。ジョブに必要なコードが存在しない場合、エージェントはそれを記述して実行します。 あなたのエージェントは、安全なサンドボックス内で独自に問題を解決できます。データセットの再構築や単発分析の実行、あるいは既存のツールではカバーできない必要なコードの作成が可能です。 作業をサブエージェントに委任する eve エージェントは作業の委任も可能です。サブエージェントは、1 レベル下の同じ形状を持ち、`subagents/` ディレクトリ内のディレクトリとして存在し、独自の指示、ツール、サンドボックスを備えています。親エージェントは、ツールを呼び出すようにしてこれを呼び出します。 子エージェントはクリーンなコンテキストウィンドウと、あなたが与えたツールのみで開始され、作業を実行して結果を親エージェントに返します。 エージェントの起動と対話 ここからが、すべての開発者が楽しみにしている部分、つまりエージェントのテストです。従来はプロセスを開始し、質問を行い、ログを読み取る必要があり、どのツールが使用されたか、モデルが何を読み込んだか、なぜそのように回答したのかを簡単に把握できる表示はありませんでした。あなたはエージェントと対話し、その作業を見たいと考えていましたが、得られたのは標準出力（stdout）だけでした。eve では開発ループは 1 つのコマンドで完結します。 ローカルでエージェントを実行する eve エージェントを開始するには、その開発サーバーを実行します。 エージェントが行ったすべての操作は、TUI（ターミナルユーザーインターフェース）上で確認できます。エージェントはスキルを読み込み、クエリを実行し、チームのルールに基づいて回答しました。これらの各行は、永続的なセッションにおけるチェックポイントされたステップです。ターミナル UI は単なるクライアントであり、エージェントは同じ構造化イベントを HTTP を介して提供します。したがって、curl やテストスクリプト、CI（継続的インテグレーション）システムを使用して、エージェントが何を行ったかを正確に駆動・検証することが可能です。 評価（evals）によるエージェントのテスト エージェントとの対話は一度の実行ごとに確認するものです。一方、評価はプロジェクト内の他のすべての要素と同様にファイルに記述された採点チェックを用いて、ソフトウェアの残りの部分をテストする方法と同じように、あなたのエージェントをテストします。 eve eval をローカルで実行するか、デプロイ済みアプリケーションを指すことで、ユーザーが問題に気づく前に、プロンプトの変更やモデルの切り替えによって何が壊れたかを確認できます。 リリースする このエージェントはすでに十分に長い間、あなたのラップトップ上で稼働しています。通常、リリースするステップでは、エージェントの開発作業が終了し、インフラストラクチャの構築が始まります。しかし、eve においてはプロビジョニング（環境設定）は不要です。なぜなら、エージェントは通常の Vercel プロジェクトであり、他のフロントエンドやバックエンドと同じ方法でデプロイされるからです。 エージェントをデプロイしても、その設定は変更されません。eve はアダプターを意識してゼロから設計されているためです。リリース時には Vercel へのデプロイが行われ、他のプラットフォームへの対応も進行中です。同じディレクトリが、ローカル環境で動作していたのと同じように本番環境でも実行されます。サンドボックスはコード変更なしで Vercel Sandbox に切り替わり、開発中に会話していたエージェントは、公開 URL でアクセス可能になります。デプロイによってエージェントの稼働が中断されることもありません。プッシュ時にタスクの途中だったセッションは、開始したバージョン上で完了します。 これらすべてにダッシュボードでの手順は不要です。エージェントを構築した同じコーディングエージェントが、その出荷と作業検証も担当します。 しかし、デプロイされたからといって、完了したわけではありません。本番環境では、エージェントには対応すべきユーザーがおり、独自のスケジュールで業務を行う必要があります。 eve をチームに紹介する 以前は Slack にエージェントを導入するには、まず Slack アプリを構築する必要がありました。アプリの設定、ボットトークン、イベント購読、Webhook エンドポイント、署名シークレットなど、エージェントが一言も発する前にこれらすべてを整える必要があったのです。eve では、チャンネルへの追加はコマンド 1 つで済みます。 コマンドを実行すると、channels/slack.ts という単一ファイルが生成され、他のコード変更と同様に配信されます。こうしてデプロイされたエージェントは、Slack で回答します。プラットフォームの機能はチャンネルに付随するため、承認は Slack ボタンとして表示され、質問は選択メニューとして表示され、作業中はタイプインジケーターが表示されます。認証情報を Vercel Connect を経由でルーティングすれば、.env ファイルにコピーするボットトークンも不要です。discord や teams で同じコマンドを再度実行すれば、同じエージェントが利用可能になります。チャンネルごとに 1 つのファイルです。 チャンネルはエージェントのユーザーインターフェースであり、セッションはそれらをまたいで移動します。Slack で質問された内容は Web 上で継続でき、HTTP を経由して到着するインシデント webhook は Slack で調査スレッドを開始し、チームがすでに作業している場所で完了できます。 エージェントをスケジュールに設定する 月曜日の収益レポートは、誰かが尋ねるのを待つ必要はありません。スケジュールはもう一つのファイルであり、cron 式と、独自のクロックでエージェントを開始するハンドラーです。 Vercel では、各スケジュールが Vercel Cron Job（cron ジョブ）としてデプロイされるため、誰も忘れることなく、毎週月曜日にレポートが投稿されます。 他のソフトウェアと同様にエージェントを実行する チームが依存しているエージェントは本番環境のソフトウェアであり、その指示への変更はコードへの変更と同じように機能を破綻させる可能性があります。eve エージェントはディレクトリ内のファイルであるため、他のコードと同様に Git に存在し、新しいプロンプト、ツール、またはスキルは、差分（diff）付きのコミットとしてレビューされ、履歴が残ります。 eve の評価機能を CI に組み込み、あなたが作成したスイートをデプロイゲートとして機能させます。これにより、すべてのコミットがスコアリングされ、回帰問題は本番環境ではなく CI 内で検出・阻止されます。 すべてのコミットには独自のプレビューデプロイも付随し、エージェントのチャネルも一緒に引き継がれます。チームは、毎日使用している Slack ボットを置き換える前に、次のバージョンと直接対話することができます。 そして、評価で捕捉できなかった形で変更が失敗した場合でも、本番環境を直ちに前のバージョンにロールバックできます。 Vercel における eve の運用方法 Vercel では、本番環境で 100 以上のエージェントを稼働させており、これらは会社の日常業務の一部となっています。各エージェントはビジネス上の特定の役割を担っています。以下にいくつか例を示します。 データアナリスト Vercel で最も頻繁に使用されている社内ツールはエージェントであり、月間 30,000 件以上の質問に対応しています。Slack で d0 に何を聞いても、データウェアハウスから回答が得られます。すべてのクエリは質問者の権限範囲に限定されるため、d0 があなたに見せるテーブルは、あなたがすでにアクセスできるもの以外にはなりません。 自律型 SDR（営業開発担当者） Lead Agent は、当社の最優秀担当者のプレイブックを 24 時間体制で実行します。新しいリードが到着した瞬間に即座に処理し、自らフォローアップを行うため、夜間にリードが冷めてしまうことはありません。年間約 5,000 ドルの運用コストで、その 32 倍の収益を生み出し、エンジニアがパートタイムで 1 名のみ維持管理しています。 営業コックピット RevOps はエンジニアを介さず、6 週間で Athena を構築しました。Snowflake と Salesforce のパイプラインおよび予測に関する質問に自然言語で回答し、稼働後はパイプラインのカバレッジがほぼ倍増しました。 サポートエンジニア Vertex は、ヘルプセンター、ドキュメント、Slack 全体を 24 時間 365 日対応する当社のサポートエージェントです。いつでも問い合わせが来ても迅速な回答を提供し、チケットを読み込んで適切な回答を見つけ、92% のチケットを単独で解決します。残りのチケットはサポートチームへエスカレーションされ、彼らは最も注意が必要な問題に集中できます。 コンテンツエージェント Vercel にはコンテンツチームだけでなく、誰でも執筆が可能です。draft0 は完全なレビューパイプラインを実行し、到達する前に最も明らかな問題を捕捉し、その記事が実際に何についてのものであるかの分析を構築します。私たちに届く頃には、基本的な作業は完了しており、必要なものが何かを明確に把握しています。これにより、小さな記事は迅速に進み、このように注力が必要なものに対しては全力で対応できます。 ルーティングエージェント 私たちは毎日何百ものエージェントを利用していますが、どのエージェントがどのような負荷を担当しているかを追跡するのは非効率的です。そのため、タスクを自分でルーティングするのではなく、すべてまず Slack の V へ送られます。V が実際にそのタスクに対応できるエージェントを特定し、そこにルーティングします。これにより、一〇〇もの異なる選択肢ではなく、一つのエージェントのように全体 fleet が機能します。 これらのエージェントはすべて、異なるスタック上の別々のプロジェクトとして始まりました。それぞれに独自のステート保持方法、認証情報の仲介方法、ログ出力方法があり、多くのチームが2番目または3番目のエージェントを作成した後に直面するのがこの状況です。今日では、これらは1つのモノレポ内にあり、どのチームが所有しているかに関わらず、同じ方法で構築・監視・アップグレードされています。すべてのエージェントが同じ形状を共有しているため、100 個のエージェントが同じツールと同一の規約を用いて、まるで一つの存在のように動作しています。 始め方 1 年前、Vercel のデプロイメントのうち、エージェントによってトリガーされるものは 3% 未満でした。現在では約 29% を占めており、近い将来にはすべてのデプロイメントの半分がエージェントから発生すると予想されています。すでにあなたもエージェントを構築しているかもしれませんが、次のプロジェクトはゼロから始める必要はありません。 パブリックプレビューは本日より開始され、CLI ウィザードがモデルの選択から実行中の開発サーバーまで、1 分未満で最初のエージェント作成をサポートします。 コーディング用エージェントにはプロンプトが必要です: eve ができることはすべて docs.eve.dev で確認でき、開発は github.com/vercel/eve で公開されており、課題・議論・貢献を歓迎しています。 Vercel ではすでに数百個のエージェントが eve 上で稼働しています。あなたは何を構築しますか？ 続きを読む

eve の紹介：エージェント構築・実行・スケーリングのためのオープンソースフレームワーク

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト