エージェント開発の課題をどう解決したか — Andrew Qu, Vercel
AAI Engineer
Computing/SoftwareSmall Business/StartupsInternet Technology
Transcript
00:00:00皆さん、お越しいただきありがとうございます。私はVercelのチーフ・オブ・ソフトウェアを務めているアンドリューです。本日は
00:00:20Vercelでどのようにエージェント構築の問題を解決したかについてお話しします。私はチーフ・オブ・ソフトウェアとして
00:00:26社内エンジニアリング、外部向けの実証実験、そして全般的な
00:00:30フロンティア領域での活動や、新しいライブラリ、フレームワーク、テクノロジーの構築を担当しています。Vercelを
00:00:36ご存知ない方のために説明すると、Vercelは人々が次のものを構築できるように、エージェント向けインフラを構築しています。私たちは
00:00:42ウェブの世界からスタートし、人々がアプリの価値を高めないインフラストラクチャの管理に悩むことなく、
00:00:47ウェブサイトやウェブアプリを公開できるよう支援してきました。100万規模へのスケールも、
00:00:50ゼロへのスケールダウンも手間なく行えます。しかし、人々の作りたいものの変化が見られます。最初は
00:00:56ページを構築していましたが、現在ではエージェントを構築したいという要望が多くなっており、私達も同じような
00:01:01歩みを始めています。誰もがエージェントやエージェントアプリケーションを簡単に構築できるようにするために、私たちは
00:01:08AI SDKというものを構築しました。これにより、300〜400行ものプロバイダー固有のコードを書き換える必要がなくなり、
00:01:13たった1行のコードを書き換えるだけで済みます。これら異なるすべてのプロバイダーに対して、背後で共通のモデルインターフェースが
00:01:19提供されます。他にも、モデルのフォールバック、安全なコード実行、非アクティブで応答を待っている間のコスト削減を容易にするためのツールや、
00:01:25耐久性や再開可能性のためのツールを数多く構築してきました。
00:01:30そして本日は、約1年前に私が取り組んだ狂気のような実験についてお話しします。それがVercelでの
00:01:38エージェントの爆発的な普及につながり、最近私たちが開発した非常にクールな成果を生み出すことになりました。
00:01:461980年頃のことですが、私が生まれる前、ビル・ゲイツはすべてのデスクに、そしてすべての家庭に
00:01:53コンピュータが存在する未来を想像しているという名言を残しました。当時はかなり異端な意見だったでしょうが、今日では
00:01:59それがごく当たり前のことのように思えます。そこで私とCTOはこう考えました。「すべてのデスクにコンピュータを置く代わりに、
00:02:07すべてのデスクにエージェントを置くことはできないだろうか？」現在、エージェントは主にコーディングや技術的な
00:02:15ワークロードで使用されていますが、デザインやプロダクトマネジメントなどの他の
00:02:20分野へも拡大し始めています。これは1年ほど前のことなので、私はかなり早い段階から取り組んでいたと言えます。しかし当時は
00:02:27Sonnet 4の時代であり、現在ほど洗練されていませんでした。私はこれを実際に探索し、何ができるか
00:02:33試してみることにしました。Vercel内の様々な職種、マーケティング、営業、財務、法務などを回り、
00:02:42仕事で一番嫌いなことは何かと尋ねました。そこで最も魅力的だと感じたユースケースがあったのがデータチームです。彼らは人数が少なく、
00:02:50精鋭チームでしたが、Vercelの成長スピードはそれを上回っていました。顧客、アナリティクス、指標、売上などに関する膨大なデータがあり、彼らは常にデータを集約し、自分たちで利用できるように準備し続けなければなりませんでした。
00:03:02当時、データサイエンス部門の業務を考えてみると、マーケティングや営業の担当者から顧客やプロダクトに関する質問が来るたびに、
00:03:11データサイエンスチームは作業をすべて中断し、クエリを書いて処理し、分析を行い、今後どうすべきかについての
00:03:19推奨事項を持って戻ってくる必要がありました。これは生産性にとって非常な痛手でした。データチームは作業をすべて中断して一日中クエリを書きたいわけではなかったのです。そこで私はデータ担当VPと協力して、より良い方法を築こうとしました。
00:03:31彼らがこのような業務を進められる、より良い方法を作ろうと試みました。AIを使って問題を解決しようとする際に
00:03:40最初に思いつくことといえば、巨大なメガプロンプトを構築することかもしれません。質問を用意してLLMに渡し、応答を得る、それだけです。最初のバージョンは正直、まさにそのような見た目でした。
00:03:52私はSnowflakeスキーマのダンプを求め、それを質問と一緒にシステムプロンプトに貼り付けました。そしてSQLが生成されると、実際に
00:04:01それをコピー＆ペーストして自分で実行していました。適切な構造が与えられたとき、現在のモデルは有効なSQLを書くのに十分な性能があるのかを確認したかったのです。
00:04:09この方法により、現在のモデルはそれほど性能が高くなくても、プロンプトエンジニアリングを行ったり周辺のコンテキストを少し改善したり、より良く動作させるためのガードレールを与えたりすれば何とかなるかもしれない、という少しばかりの確信が得られました。
00:04:21データサイエンティストが質問を受け取ったときに実際に行うべき作業を考えてみると、まず質問を処理する必要があります。
00:04:28セマンティック層を探索し、結合パターンを実際に把握しなければならない場合もあります。そして実際にSQLを実行します。
00:04:35SQLが実行されなかった場合やコストが高すぎる場合は、戻ってもう一度やり直すこともあります。最終的にはデータの視覚化を含めてレポートを作成し、
00:04:42いくつかの段落を書いたり、振り返りを行ったり、その他の作業を行ったりします。こうしたさまざまなフェーズを考慮し、私とデータ担当VPは
00:04:50それらを特定のエージェントワークロードに落とし込んでいきました。そうしてできた第2世代のデータサイエンス
00:04:57エージェントは「D0」と呼ばれ（今後はD0と呼びます）、質問を投げると、クエリを担当するエージェントが
00:05:05プランニングエージェントにクエリを渡し、さらにそれが実行エージェントへと渡る、という仕組みになっています。これらをすべて連鎖させると、
00:05:11このような形になります。各エージェントには、その機能に特化した専用のシステムプロンプトがあり、その機能に厳密にスコープされたツールが与えられています。
00:05:20ここでの例を見ると、最初のプランニングエージェントには、YAMLのエンティティ読み込みやスキーマ検索といったツールが用意されていることがわかります。そのため、
00:05:31プランニングエージェント、SQLエージェント、そしてレポート機能へと渡すための回答が得られるまで、それらの機能のみを使用します。これにより状況は
00:05:38改善されました。SQLをコピー＆ペーストして戻ってきてからレポートを作成するという手間が省け、
00:05:44質問から回答までのエンドツーエンドのループを実際に実行できるようになりました。しかし、このアーキテクチャではいくつかの壁に突き当たり始めました。
00:05:54そしてこの頃、私たちが行き着いた結論は、実際に必要とされるのは、
00:06:01すべての巨大なコンテキストを内包し、独自のメモリを自分で管理する単一のエージェントである、ということでした。これは、
00:06:07エージェントに自分の行った作業を振り返らせ、リフレクションを行って、
00:06:13ここまでたどり着いた手順を把握させたいと気付いた時期でもありました。前のモデルでは、
00:06:19次のエージェントに渡されるのは、前に行われた処理の要約と小さなスニペットだけだったことにお気づきかもしれません。しかし今回の方法であれば、
00:06:251つの巨大なエージェントが存在し、その内部で独自のステートを管理していると想像できます。ある時点では計画を立て、
00:06:30ある時点では構築を行い、ある時点では実行を行い、ある時点ではレポートを作成します。このような形に
00:06:36なっていました。1回の大規模なAI呼び出し（最大ステップ数100など）を行い、実行のどの段階にいるかに応じて、
00:06:43自分自身のステートを管理する能力をそれに与えるのです。ご覧の通りツールの面では
00:06:48似たような形状をしていますが、この最大の利点は、実行や結合の際にエラーが発生した場合に、
00:06:54戻ってもっと探索を行ったり、追加で読み込みを行って何が間違っていたのかを把握したりできる点でした。
00:07:00この時点で非常に優れたものになっていました。手元の実際のシステムにかなり自信が持てたため、
00:07:06社内の信頼できる一部のメンバーに展開しました。これは非常に強力なツールであり、
00:07:11不適切な人たちや、非常にクリティカルなワークロードで使用している人たちの手に安易に渡したくなかったからです。一部の人に使ってもらったところ、その直後の
00:07:17反応は最悪なものでした。自分たちではうまくいっていると思っていました。評価（evals）の30%を達成できていると考えていたのです。
00:07:23しかし、投げられる質問の中には予想もつかないものが含まれていました。そうしたシナリオのいくつかを手作業でマッピングし直すことに多くの時間を費やすのは、
00:07:28あまりスケーラブルなやり方には思えませんでした。
00:07:33その頃、Claude CodeとOpus 4.5がリリースされました（正確にはOpus 4.5がリリースされ）、それがClaude Codeと相まって圧倒的に強力でした。
00:07:44それらはファイルシステムエージェントというコンセプトの扉を開いてくれました。私たちも傍らで、「Claude CodeとOpus 4.5は、以前のものと比べたら実質AGIだ」と驚嘆していました。
00:07:56自分たちで自作したエージェントとは比べ物にならず、ほとんどの質問に少しも詰まることなく答えてくれたのです。
00:08:04何が間違っていて、なぜあんなにも優れていたのかを一歩引いて考え直したとき、最大のブレイクスルーは「単なるファイルシステムである」という点だと気づきました。
00:08:13ツールセットが極めて最小限（ファイル一覧の取得、ファイルの読み込み、bashの実行）に抑えられており、データエージェントのユースケース向けにいくつか追加されているだけでした。
00:08:24しかし最大のポイントは、エージェントが十分に訓練されているツールを使用でき、必要な場所を自ら探索して作業を行えたという点です。
00:08:32私たちはClaude Codeのように、指示通りのガチガチに規定されたツールセットを与えていたわけではありません。
00:08:37いわば自由に動き回らせ、創発的な振る舞いを探索させていたのです。
00:08:41この経験から、ファイルシステムをそのまま活用すればいいのだと学びました。
00:08:44Claude Codeから得た学びや、ローカルで実行されるだけであれほど強力になるという事実を目の当たりにし、
00:08:50私たちはClaude Code風の方式でシステムを再構築しようと試みました。
00:08:54サンドボックス内で実行させるようにしたのです。
00:08:57そのサンドボックスにはセマンティック層全体のデータを丸ごと投入します。
00:09:00エージェントが必要な情報を把握するため、bash、ファイルの読み込み、ファイルの書き込みなどを自由に使えるようにしました。
00:09:05そしてVercel固有の処理を確実に行えるよう、いくつかのツールを上に少し付け加えただけです。
00:09:10これが実際、これまでにない最大のブレイクスルーとなりました。
00:09:14単一エージェントからClaude Code SDKへ、そしてClaude Code SDKから、私たちのユースケースに特化・微調整されたファイルシステムエージェント全般への飛躍は、驚くべきものでした。
00:09:27この段階で、Vercel内のさらに多くの人々に提供する準備を始めました。
00:09:31そしてこの時点で、評価スコアが実質的に倍増しました。
00:09:36私がこれを書いたのですが、仕組みは基本的にこのようになっています。
00:09:39非常にシンプルです。
00:09:40bashツールを渡すだけです。
00:09:41NPMには「bash tool」という便利なヘルパーもあります。
00:09:44それをサンドボックスにアタッチします。
00:09:45サンドボックスにファイルをアタッチすれば、エージェントが読み込み、書き込み、実行を行えるようになります。
00:09:50この発見の後、以前なら失敗していた多くの質問に合格できるようになったのを確認し、私は素晴らしいブログ記事を書きました。
00:09:59現在も公開されています。
00:10:00この記事を書いた週には、Vercel.comのトラフィックの70%をこの記事が占めました。
00:10:05いかに素晴らしい記事であるかがお分かりいただけるでしょう。
00:10:07その次に論理的なステップとして、私たちが直面した共通のユースケースを洗い出したいと考えました。
00:10:14その頃には、すでに社内全体でエージェントを自由に使える状態にしていました。
00:10:18顧客の指標、売上指標、数値の指標、NPMのダウンロード数など、あらゆるものを求める人々から毎日何千ものクエリが寄せられていました。
00:10:27そして、これらのクエリの多くは実際には同じような形状をしていることが判明しました。
00:10:30集約のやり方には自ずと限界があります。
00:10:33プロダクトを検索する方法にも限界があります。
00:10:35請求情報を調べる方法にも限界があります。
00:10:37そこで現在、直近のクエリを取得し、それらを「スキル」として昇華させる定期ジョブを運用しています。
00:10:43現在、さまざまな集約処理から特定個人の詳細データの検索に至るまで、約100個のスキルを備えています。
00:10:50そして、これが非常に効果的であることがわかりました。
00:10:52なぜなら、新しいエージェントの実行ごとに、
00:10:56意味的レイヤーやシステムプロンプトのほかには、事前に関連付けられたコンテキストがほぼ存在しないためです。
00:11:01しかしスキルがあれば、すでに構築済みの膨大なコンテキスト知識を活用した状態で開始できます。
00:11:09これが、そのおおまかな構造です。
00:11:11先ほどの構成と非常に似ています。
00:11:12ですが、skillsフォルダーの存在が非常に強力なのです。
00:11:15私たちはVercelで「Skills SH」というツールも構築しました。
00:11:18エージェントスキルを見つけて自分で実行するための、最も一般的な方法となっています。
00:11:22私がこのような話をするのは、この変遷の道のりは皆さんも時折直面する可能性のあるものだからです。
00:11:28つまり、シンプルなものから始めて徐々に複雑さを増していき、最終的に本番環境へデプロイできるシステムに到達するという流れです。
00:11:34そして、このエージェントを構築するあらゆる段階で、Vercelの誰かが常にエージェントに関心を持っていました。
00:11:42皆、私のD0エージェントから分岐させて、独自のエージェントを構築しようと試みたのです。
00:11:46その各段階で、従来は知られていなかった方法で物事をより良く進める手段を見出すことができました。
00:11:50そこで私たちは考えました。もし現在の開発者が、単純なプロンプトや第一原理からのベストプラクティスの再発明からではなく、まさに最後のインサイトからスタートできたらどうなるだろうかと。
00:12:04そこで、「エージェントのためのNext.jsを作れないか」と考えました。
00:12:09ご存じない方のために説明すると、Next.jsはVercelが開発した人気のWebフレームワークで、ファイルシステムに基づくフレームワーク定義のインフラストラクチャという概念を発明しました。
00:12:18どこにファイルを配置するか悩む必要はありません。
00:12:20適切な規約に従ってファイルを記述するだけでよいのです。
00:12:23それにより、どこに配備されるべきかが自動的に宣言されます。
00:12:26ページはCDNに配置されます。
00:12:27サーバーレス関数も適切な場所に配置されます。
00:12:29キャッシングは中間層で行われます。
00:12:31私たちは、エージェントの構築もこれほどシンプルであるべきだと考えました。
00:12:34skillsフォルダー、toolsフォルダー、channelsフォルダーを作成するだけでよいはずです。
00:12:38そして、これらを非常に簡単に宣言できるようにするべきです。
00:12:40フレームワーク側が、それをもとにエージェントを正確に構築する方法を把握するべきなのです。
00:12:44だからこそ、2週間前に私たちは「Eve」をリリースしました。
00:12:47EveはエージェントのためのNext.jsのようなフレームワークであり、サンプルテンプレートから開始するだけで、エージェントの準備を完全に整え、独自のカスタム知識やカスタムツールを簡単に追加できます。
00:12:59さらには、使い慣れたチャネルへと統合することすら可能です。
00:13:03私たちが考えるエージェントの姿は、おおむねこのようなものです。
00:13:06エージェントにはランタイムがあり、チャネルが存在します。
00:13:09そのランタイムにおいて、処理の耐久性が必要になります。
00:13:11処理を隔離された環境で実行したいという要望もあるでしょう。
00:13:13さまざまなモデルを呼び出す必要もあります。
00:13:15そして、外部との接続も必要です。
00:13:17私たちはオープンソースを念頭に置いてこれを構築しました。
00:13:19Postgres、OpenAIのResponses API、Docker、その他のコネクター用など、独自のオープンソースアダプターをプラグインできるようにEveを設計しています。
00:13:29同時に、Vercelへのデプロイも信じられないほど簡単にしました。
00:13:31ここで異なる点といえば、これらすべての体験を簡単に構築できるようにするため、私たちが長年開発してきたVercelのプロダクトを活用している点だけです。
00:13:39耐久性のための「Vercel Workflows」、安全な実行のための「Sandbox」、そして接続用の短命なOADCトークンの生成を容易にするために最近リリースした「Vercel Connect」などがあります。
00:13:51また、Eveの構築を進める中で、D0エージェント全体をEveで書き直しました。
00:13:55コードの裏側にあって普段見えない複雑な構造と比べて、実際のファイルシステムはこのようにおおむねシンプルです。
00:14:01非常にシンプルです。
00:14:02いくつかのシステム指示、いくつかのスキル、いくつかのツールがあり、これらを組み合わせて本物のエージェントを簡単に作成できます。
00:14:09また、イテレーションを回すのも非常に簡単です。
00:14:11ロンドンでのイベントで2週間前に正式リリースする前にも、少数のベータ顧客に提供していました。
00:14:17私たちと密接にパートナーシップを結んでいるAuraという企業では、人々のサービスをテストするための「ミニクロウ」のような独自エージェントを再構築しました。
00:14:26Webサイトにアクセスし、インストールを行い、実際に使ってみるというものです。
00:14:29市販のクラウドコードを使用する場合と比較して、Eveゼロから独自のエージェントを構築することで、信じられないほどの成功を収めています。
00:14:38ステップ数が減り、成功率が向上し、さらに優れたインサイトが得られました。
00:14:42そしてEveをVercelにデプロイすると、最初からオブザーバビリティ（可観測性）が組み込まれています。
00:14:49ここに見るように、すべてのエージェントの実行、すべてのツール呼び出し、実行された各ステップ、さらには推定コストや導入可能な最適化のヒントを確認できます。
00:15:00Eve.devにアクセスすれば、今すぐ始められます。
00:15:02クローンしてテンプレートを開始し、簡単にデプロイしたり、必要に応じてセルフホストしたりすることが可能です。
00:15:07このような話を持ち出すのは、ビジネス特化型のユースケースを持つエージェントが今後ますます増えてほしいと願っているからです。
00:15:14私たちがD-Zeroを構築する前にも、こうした垂直統合型エージェントを手がけている、資金調達に成功した多くの業界スタートアップを実際に試して検証しました。
00:15:23Snowflakeインスタンスを利用し、エージェントがそれに対してSnowflakeクエリを実行できるようにすることに特化した企業です。
00:15:30しかし、そうしたエージェントを本当に優れたものにするのは、社内固有の膨大な知識であることがわかりました。
00:15:38VercelはWebベースの企業であり、WebサイトやWebプロパティを持つ多くの顧客を抱えています。
00:15:45それは、「いつ何をクエリすべきか」や「どの要素が何にリンクしているか」という点において、より一層深く関わってきます。
00:15:51したがって、市販されている既存のエージェントも素晴らしいし試す価値はありますが、最大限の成果を得たいのであれば、
00:15:58やはり自社独自のエージェントを構築し、可能な限り企業固有の知識を盛り込むべきだと考えています。
00:16:03現在、Vercelにはプロダクトマーケットフィット（PMF）を達成したエージェントがおおむね20個ほど存在します。マーケティングの振り返りから連絡先の特定まで、
00:16:14法務部門が新しい交渉を確認した際の初回の契約書赤入れ、さらにはデータクエリを支援するデータサイエンスエージェントに至るまで、多岐にわたります。
00:16:24これは、私たちVercelがいかにエージェントを活用してきたかを示しています。
00:16:28こうした仕組みの数々が、実際にかかる時間を大幅に削減してくれています。
00:16:32データチームの生産性はかつてないほど高まっています。
00:16:34Snowflakeのパフォーマンスを向上させたり、不足していた新しいデータソースを追加したりするための時間をより多く確保できるようになりました。
00:16:40以前はクエリの記述に追われて手が回らなかったギャップを埋めることができるようになったのです。
00:16:46大規模、中小を問わず、あらゆる企業において、やりたくない業務や、
00:16:55あるいは時間をかけすぎている作業を自動化することが、今ほど容易になった時代はありません。
00:16:58人事、財務、営業などの多くの業務はエージェントによってある程度自動化できると考えており、現代においてそうしたエージェントを構築する最良の方法こそがEveだと確信しています。
00:17:09こちらが私のSNSアカウントです。
00:17:11ご来場いただき、お聴きいただきありがとうございました。
00:17:13私はアンドリューです。外でお話ししたい方は、ぜひお声がけください。
Community Posts
No posts yet. Be the first to write about this video!
Write about this video