2025-03-20 AI Engineer Summit 2025: The Bitter Lesson Applied - スケーラブルAIエージェント設計への転換点

※本記事は、AI Engineer Summit 2025のAgent Engineering Session Dayで行われたRahul Sengottuvelu氏による講演「Rethinking how we Scaffold AI Agents」の内容を基に作成されています。講演の詳細情報は https://ai.engineer でご覧いただけます。本記事では、講演の内容を要約しております。なお、本記事の内容は講演者の見解を正確に反映するよう努めていますが、要約や解釈による誤りがある可能性もありますので、正確な情報や文脈については、オリジナルの講演動画（https://www.youtube.com/watch?v=-rsTkYgnNzM ）をご覧いただくことをお勧めいたします。

登壇者について Rahul Sengottuvelu氏は、RampでHead of Applied AIを務めています。以前は、高度なAIを活用してサポートチケットをより正確に解決するカスタマーサポート自動化プラットフォームCohere.ioを共同創設しました。Cohere.ioは2023年5月にRampに買収されました。また、LLMのための制約付きデコーディングライブラリであるJsonformerの作者でもあります。

1. 発表者の背景とAI開発の進化

Rahul Sengottuvelu：私について少しお話しします。私はRampでHead of AIを務めており、LLMに4年間取り組んでいます。これはLLM界では長い期間と言えるでしょう。すべては実際にChatGPTが登場してから始まりました。私は当時、現在人々がAIエージェント企業と呼ぶようなものを構築しようとしていましたが、その頃は単にカスタマーサポートをやっていただけでした。私たちはチャットボットをより賢くしようとし、どのモデルを使うべきか、どの技術を使えば顧客により良い対応ができるかを見つけ出そうとしていました。

当時私たちはGPT-2やBERTなどのモデルをいじっていましたが、これらのモデルは本当にイライラするほど愚かでした。コンテキストウィンドウは小さく、推論能力も高くありませんでした。本当に信じられないほど煩わしい状況でした。そのため、私たちはこれらのモデルを少なくともある程度信頼性をもって動作させるために、大量のコードをモデルの周りに書きました。そして、モデルが賢くなっていく過程で、私たちはそのコードの多くを削除する必要がありました。

この経験を通じて、どのようなコードを削除する必要があるか、より多くの知能でスケールするエージェントをどのような方法で構築するかについて、多くのパターンを見ることができました。明らかに私たちは今後さらに多くの知能を得ることになるでしょう。

私はまた、JSONformerという構造化抽出ライブラリも構築しました。これは最初のものだったと思います。完全に確信はありませんが、タイミング的には他の主要なものより前でした。これも、モデルが愚かすぎてJSONを出力できなかったため、モデルの周りにスキャフォールディングを施したものでした。私たちは本当にモデルに懇願し、嘆願し、私たちが望む方法で動作するよう強制していました。

2. 核心思想：The Bitter Lessonとスケーラブルシステム

Rahul Sengottuvelu：先ほど述べたように、今日は一つの核心的なアジェンダがあります。それは一つのアイデアを伝えたいということです。皆さんはおそらくBitter Lessonのエッセイを読んだことがあると思いますが、それが何かを簡単に説明しましょう。

非常にシンプルに言うと、このアイデアは「計算量でスケールするシステムが、スケールしないシステムを打ち負かす」ということです。つまり、二つのシステムがあったとして、何の努力もしなくても、そのシステムのうち一つがより多く思考したり、何らかの方法でより多くの計算を使用できるとしたら、そのシステムは勝つ傾向があります。一方で負ける傾向があるのは、硬直的で固定され、単に決定論的なシステムです。

このアイデアから、もしあなたがシステムを構築しているなら、より多くの計算で改善するシステムを構築した方が良いという、かなり明白な結論が導かれます。

この考えをさらに一歩進めると、なぜこれが真実なのかというと、指数関数的な成長というものは稀だからです。それらは単に存在しないのです。世の中のほとんどのものは指数関数的ではありません。だから、指数関数的なものを見つけたときは、それに乗っかるべきです。ストラップを締めて、無料パスを取って、その流れに乗るべきです。そして、おそらくあまり頑張りすぎる必要はありません。

このことを反映する歴史的な例はたくさんあります。チェスや囲碁、コンピュータビジョン、Atariゲームなど、人々は多くのシステムを構築し、大量のコードを書こうとしてきました。硬直的なシステムについての私の考え方は、週末を犠牲にして多くの時間を費やし、非常に巧妙なソフトウェアを書き、よく抽象化し、人間の推論や思考プロセスを特徴として合成し、それらを巧妙な方法で使用し、人間がどのように考えるかを近似しようとすることです。

実際に計算量を固定すれば、このアプローチが勝利するでしょう。しかし、どれだけの探索を行うかをスケールアウトしていけば、汎用的な手法が常に最終的に勝利することが判明します。これはAtari、囲碁、コンピュータビジョンなど、すべてのケースで起こりました。

3. Rampでの実践：Switching Reportエージェントの3つのアプローチ

Rahul Sengottuvelu：Rampについて少し説明します。Rampは、企業が経費、支払い、調達、出張、簿記をより効率的に管理するのを支援する金融プラットフォームです。私たちは製品全体にわたって大量のAIを持っており、財務チームや従業員が行う多くの退屈な作業を自動化しています。経費報告書の提出、フライトやホテルの予約、払い戻し申請の提出など、すべてです。舞台裏での多くの作業は、他のシステムとの相互作用であり、レガシーシステムを支援し、従業員がより迅速に作業を完了できるよう支援することです。

今日Rampで持っているシステムの一つについて実際に話し、システムの異なるバージョンと時間とともにどのように進化したかを説明しましょう。私たちが話すのは「switching report」と呼ばれるものです。これは非常にシンプルなエージェントで、やることは一つだけです。任意の形式のCSVを取り込むことです。つまり、スキーマはインターネットから来る本当に何でもあり得ます。

私たちはこれらのCSVをサードパーティのカードプロバイダーから取得したいと考えています。人々がRampにオンボーディングする際、私たちは彼らに素敵なチェックリストを提供し、「あなたが他のプラットフォームで持っているすべての取引がここにあります。これらを移行するのを手伝いましょう」と言いたいのです。より多くの取引がRampに来れば来るほど、私たちはより多くの支援ができ、あなたはより多く私たちのソフトウェアを使用し、みんなが利益を得ます。

switching reportは実際にはただのチェックリストですが、人々のCSV取引を読むために、私たちはそれらを理解する必要があります。他のプラットフォームはあらゆる種類のクレイジーなスキーマを持っているのです。ここで私たちが抱えている問題の説明は、任意のCSVに対して、どのようにそれを解析し、私たちが理解できる形式にサポートできるかということです。

シンプルなアプローチから始めましょう。最も一般的な50のサードパーティカードベンダーを取って、それらすべてに対して手動でコードを書くということです。明らかに、これは単に機能します。多少の作業は必要ですが、大量の作業ではありません。ただし、50の異なるプラットフォームに行って、それらのCSVをダウンロードし、どのようなスキーマを持っているかを確認し、コードを書く必要があります。もし彼らがある日フォーマットを変更することを決めたら、あなたのものは壊れるでしょうが、それは大丈夫です。ページを受け取って、起きて修正できます。

ここにいくつかのLLMを導入してみましょう。10万行書くことになったかもしれない過度にエンジニアリングされたコードから、より汎用的なシステムを望んでいます。ここで少しのLLM、少しのAIを導入しましょう。決定論的なフローで、または古典的なスクリプティングランドのスクリプティングで、OpenAIへの呼び出しやセマンティック類似性を行いたい埋め込みモデルのようなものを追加してみましょう。

そこで、入ってくるCSVの各列を取って、それがどのような種類の列かを分類してみましょう。それは日付なのか、取引なのか、取引金額なのか、マーチャント名なのか、ユーザーの名前なのか。そしてそれをマッピングし、おそらく私たちが満足するスキーマに終われるでしょう。再び、計算の大部分は古典的な土地で実行されており、一部はファジーなLLMの土地で実行されていますが、これはより汎用的なシステムのように見えています。

別のアプローチを試してみましょう。完全に進んで、CSVをLLMに文字通り渡して、「あなたはコードインタープリターを持っているので、望むコードを何でも書けます。pandasでも、すべての高速なRustベースのものでも。これらすべてのPythonパッケージがあります。CSVのヘッド、テール、望む行を見ることができます。そして、この特定の形式でCSVを提供してほしいのです。ここにユニットテスト、ここに動作しているかどうかを確認するために使用できるベリファイアーがあります」と言うのです。

実際のところ、このアプローチは一度だけ実行する場合は機能しません。私たちは試してみました。しかし、代わりに並列で50回実行すると、実際に非常にうまく機能し、多くの異なる形式にわたって汎用化する可能性が非常に高いことがわかりました。ここでの計算量は実際に、最初に思いついたアプローチより10,000倍多いと思いますが、繰り返しますが、世界で本当に希少なのはエンジニアの時間です。少なくとも今日は、そしてしばらくの間はそうかもしれません。私たちは本当によく機能するシステムを持ちたいと思っており、10,000倍多い計算でさえ、おそらく1ドル未満のコストで済みます。切り替えられるすべての取引、失敗するすべてのCSVは、この正確なアーキテクチャで費やすお金よりもRampにはるかに多くのお金をかけることになります。

4. アーキテクチャパターンの一般化と将来展望

Rahul Sengottuvelu：これは非常に具体的な例ですが、これが私たちが皆構築するエージェントや私たちが皆取り組んでいるシステムにどのように適用されるのでしょうか。実際、このようなことは汎用化されることがわかります。3つのアプローチを見てみると、黒い矢印を古典的な計算とし、青い矢印をファジーランドとしましょう。つまり、ニューラルネットに入り、あらゆる種類の奇妙な行列乗算が起こり、潜在空間にいて、すべてがエイリアンの知性になり、そして古典的な土地に戻ってくるのです。

第1のアプローチでは、AIはありませんでした。私たちはただコードを書き、それは主に機能しました。制約されたエージェントである第2のアプローチでは、類似性スコアか何かが欲しいと決めたときに、古典的な土地からファジーランドに分岐しました。第3のアプローチは実際に反転しており、LLMが古典的な土地に行く必要があると決断します。つまり、いくらかのコード、いくらかのpandasやPythonコードを書き、必要なときに古典的な土地に分岐することを決定しますが、計算の大部分は実際にファジーです。

実際、これは最も正確なグラフではないかもしれません。私たちが50回実行することを提案したので、実際にはもっとこのような感じです。しかし、一般的にバックエンドを見ると、それらはすべてリクエスト-レスポンスです。何らかのメッセージが入ってきて、それはPOSTリクエストやGET、更新、読み取り、あらゆる種類のCRUD操作のようなものです。私たちは本当にバックエンドに対して、この情報を取り、それで必要なことを何でも行い、望むミューテーションを実行し、レスポンスを返すよう求めているだけです。

人類として私たちがこれまでに構築したほぼすべてのシステムは最初のもののようですが、より多くの人がOpenAIを使用しており、OpenAIは何十億ドルも稼いでいます。おそらく、それらを使用するシステムの多くは2番目のように見えます。通常のプログラミング言語がOpenAIサーバーに呼び出しを行い、いくらかのファジー計算を実行しています。

Rampのコードベースのますます多くの部分で、私たちは第3のアプローチに移行していることを目にしています。なぜなら、それは単にうまく機能する傾向があるからです。すべての青い矢印について、あなたが何もしなくても、私たち全員が来年一年間休暇に行っても、大手ラボは依然として働いており、それらのモデルをより良くするために何十億ドルも費やしています。つまり、青い矢印は良くなるでしょう。あなたのコードベースでどれだけの青い矢印を使用しているかが、実際にあなたの会社を、あなたの側からの多くの努力なしに直接助けることになります。これが私が言っているBitter Lessonの力強さであり、指数関数的トレンドの力強さです。あなたは単に乗っかることができるのです。

この考えをさらに進めて、実際に完全に進んでみましょう。何かクレイジーなことをしてみましょう。左側には伝統的なWebアプリが見えます。通常の動作方法は、gmail.comを開くと、何らかの静的ファイルサーバーがあり、GoogleがあなたにJavaScript、HTML、CSSの束を送信します。あなたのブラウザがそれをレンダリングし、ユーザーフレンドリーな素敵なUIを表示します。おそらくいくつかのメールが見え、そのうちの一つをクリックします。フロントエンドがバックエンドにリクエストを行い、バックエンドがフロントエンドに問い合わせます。フロントエンドがバックエンドに「このIDのメールの内容を教えて」と依頼し、バックエンドがデータベースにヒットして結果を返します。彼らはおそらくコード生成やGmailを作るために利用可能なすべてのコード生成ツールを使用したでしょう。LLMはソフトウェアエンジニアがコードを書いているときにのみ機能しましたが、コードが書かれてプロダクションにプッシュされると、それは単に古典的な計算です。

右側では、実際に異なるモデルを提案しています。バックエンドがLLMなのです。それは生成されたものではありません。このLLMが実行を行っています。それがバックエンドです。LLMはコードインタープリターのようなツールにアクセスでき、それを通してネットワークリクエストを行う可能性があり、また、DBへのアクセスも持っています。

実際に、この原理で動作するメールクライアントを持っています。これは私のテスト用メールなので、皆さんが私に送ったメールを数分で見たい場合は、私にメールを送ることができますが、どうか優しくしてください。

[ライブデモ開始] おそらく十分な時間が経ったと思うので、進みましょう。このメールクライアントがあります。LLMをブラウザに接続するための通常のJavaScriptはまだ多少ありますが、ログインするとき、私のメールを表示しています。遅いのは、このページを開いてGmailにログインすると、Gmailトークンが実際にLLMに送信されているからです。文字通り、これはLLMチャットセッションであり、画面に表示されているものは「こんにちは、LLM、あなたは実際にGmailクライアントをシミュレートしています。あなたはすべてのメールにアクセスできます。あなたはRahulのGmailトークンとコードインタープリターにアクセスできます。だから、Gmailクライアントのホームページに合理的だと思うUIをレンダリングしてください」と言っているのです。

マークダウンとしてレンダリングすることに決めたようです。実際には、マークダウンとしてレンダリングするよう指示していると思います。ここから私に送られたすべてのメールをレンダリングしています。「カリフォルニアからこんにちは」というのが見えるので、それをクリックしてみます。

それをクリックすると、実際にはバックエンド呼び出しやそういったものを実行しているわけではありません。この場合は「カリフォルニアからこんにちは」というテキストとID番号をユーザーがクリックしたとLLMに伝えているだけです。LLMは今、ユーザーがクリックしたものの情報を持っており、Webフレームワークがするように、ページをレンダリングするチャンスを持っています。再び、おそらくその特定のメールのGETリクエストを実行し、本文を引き出します。

このエージェントが何をするかを見ています。LLMがGmailクライアントにとって適切なUIだと決めたものです。LLMが合理的だと思った他の機能もあります。未読にマークしたり、必要に応じてメールを削除したりできるように見えます。それほど良いメールではないので削除してみましょう。すみません。たくさんのことをやっているのでとても遅いのですが、皆さんをこの方向に押し進めたかったのです。

このような種類のソフトウェアは今日はかろうじて動作しており、将来動作しないという意味ではありません。指数関数的トレンドのようなもの、物事はこれが単に離陸するかもしれません。だから、皆さん全員にこの方向で考えてもらいたかっただけです。より多くのソフトウェアがこのように見えるでしょうか？わかりません。見てみましょう。