OpenAI、エージェント指向の認知アーキテクチャに賭ける方針を表明

3 週間前、OpenAI は長年待ち望まれていたデベロッパーデイを開催し、数々の新機能を発表しました。私にとって最も興味深かったのは「Assistants API」と「GPTs」の 2 つです。これらは本質的に同じ賭け、つまり特定の「認知アーキテクチャ（cognitive architecture）」に焦点を当てたエージェント型のクローズドなシステムへの賭けだと私は捉えています。

両者は異なるエンドユーザーを想定していますが、いずれも OpenAI がアプリケーションをこの特定の認知アーキテクチャへと誘導しようという野望を示しています。一方、LangChain では LLM を駆使した真に変革をもたらすエージェント型システムの未来を信じていますが、その実現への道筋は企業が自社の認知アーキテクチャを制御できるものだと考えています。

そのための手段として、すでに OpenGPTs のようなプロジェクトがあります。これは Assistants API（および GPTs）のオープンで編集可能、かつ設定可能なバージョンです。

GPTs と Assistants API

この 2 つのうち、GPTs はインターネット上でより頻繁に議論されている方でしょう。コードをほとんど書かずに自分専用の「GPT」を作成できるのが特徴です。

これらの GPT は、カスタムインストラクション（指示）、カスタムナレッジ（知識）、そしてカスタム関数を用いて独自にカスタマイズすることが可能です。これらは、プラグイン（Sam Altman 自身の言葉によれば 製品市場適合（PMF）を果たせなかった）に続く、いわばアプリストアの第 2 弾として位置づけられているように見えます。

「Assistants API」は、このアイデアをより開発者視点に特化させたバージョンです。この API は状態を保持するもので、過去のメッセージの保存やファイルアップロードが可能で、組み込みツール（コードインタプリタ）へのアクセスも提供します。また、関数呼び出しを通じて他のツールの制御も可能です。これは開発者が呼び出すべき関数を定義し、それをクライアント側で実行できる仕組みです。

認知アーキテクチャ

これらはいずれも、裏側では同様の「認知アーキテクチャ」を備えています。ここでいう認知アーキテクチャとは、LLM アプリケーションのオーケストレーション（調整・制御）を指す用語です。この言葉を最初に使用したのは、自律型エージェント企業「Lindy」の創設者である Flo Crivello 氏です。私はこの言葉が非常に優れた表現だと考えています。

💡

最も興味深い LLM アプリケーションは、「文脈を意識した推論アプリケーション」として記述できます。ここには主に 2 つの要素があります。(1) アプリケーションにどのように文脈を提供するか、(2) アプリケーションがどのように「推論」を行うか。これら 2 つの要素が組み合わさって、アプリケーションの認知アーキテクチャを構成します。

LangChain では、以前からこの認知アーキテクチャについて議論してきました。最近の TedAI のトーク（動画はまだ公開されていません）では、開発者が構築している認知アーキテクタの異なるレベルについて話しました。具体的には以下のようなものがあります：

LLM を 1 回呼び出すだけで、アプリケーションの出力を決定するケース。

LLM の呼び出しチェーンを用いて、依然としてアプリケーションの出力のみを決定するケース。

LLM をルーターとして使い、どのアクション（ツール、検索機能、プロンプト）を使うかを選択させるケース。

状態機械：LLM を用いてステップ間の遷移をルーティングし、何らかのループを形成するが、遷移オプションはコード上で列挙されたものに限られるケース。

エージェント：多くの骨組みを取り除き、遷移オプションを LLM が完全に決定するケース。

*現在の認知アーキテクチャに関する私たちのメンタルモデルを示す表。

エージェント

Assistants API や GPTs は、上記で説明した「エージェント」という認知アーキテクチャの具体例です。サム・アルトマン氏も発表の際にこの用語（"agent"）をそのまま使用しました。エージェントという用語は多義的で、さまざまなアプリケーションを指すために使われることもありますが、OpenAI が用いる意味は、私たちの理解とほぼ一致しています。つまり、遷移オプションを LLM 単独で定義するアプローチです。

このようなアプリケーションは、実際にはどのようなものなのでしょうか。これはループとして考えると最もわかりやすいでしょう。

ユーザーからの入力を受け取ると、このループが開始されます。まず LLM（大規模言語モデル）が呼び出され、その結果は「ユーザーへの応答」か「実行すべきアクション」のいずれかになります。

もし応答が必要と判断された場合は、それがユーザーに返され、一連のプロセスは完了します。一方、アクションが必要だと判断された場合は、まずそのアクションを実行し、その結果（観測値）を取得します。

このアクションとその結果を再度プロンプトに戻します（これを「エージェントのスクラッチパッド」と呼んでいます）。そしてループがリセットされ、更新されたスクラッチパッドを含めて LLM が再び呼び出されます。

高レベルで言えば、これが GPTs が行っていることです。ユーザーが指定したツール（あるいは検索やコード実行といった組み込みツール）を呼び出す際、画面上には回転するウィジェットが表示されます。これはアクションが実行されていることを示しており、GPT はその結果（観測値）を待機しています。

そして最終的にテキストで応答し、実行すべきアクションはなくなることで、このループは完了します。

Assistants API の仕組みは同じです。唯一の違いは、API が自動的にツールを呼び出さない点にあります（検索やコード実行など組み込みツールの場合は例外）。代わりに、API は特定のメッセージタイプを返します。これは「どのツールを呼び出すべきか」および「その入力値はどうあるべきか」を示すものであり、その後、クライアント側でツールを呼び出して結果を戻すまで待機します。

この「エージェント型」の認知アーキテクチャは、過去 1 年半かけて進化を続けてきました。AI21 Labs は約 1 年半前に MRKL パーパー を発表しました。また、約 1 年前に公開された ReAct プロンプティング戦略 は、この種のアーキテクチャを実現する特定の手法です。LangChain ではほぼ 1 年前に ReAct を採用し、すぐにより汎用的なゼロショットプロンプティング戦略へと展開しました。約 9 ヶ月前には AutoGPT が登場し、同じ認知アーキテクチャを採用しつつ、利用可能なツールの数を増やし、永続的なメモリ機能を追加し、より大規模なタスクを処理できるようにしました。

OpenAI が賭けているもの

OpenAI がエージェントにどれほど注力しているか、その姿勢には非常に興味を惹かれました。なぜなら、この認知アーキテクチャは信頼性が十分でなく、本格的な実用にはまだ適さないという見方が一般的だからです。しかし、基盤となるモデルを自社が制御している以上、OpenAI こそがこの仕組みを成功させる最有力候補と言えます。

それでもなお、これは「賭け」です。時を経てエージェントに付随する諸問題が解消されていくと、OpenAI は確信しているのです。

現在、実際に有用な「自律型エージェント」として認識されているものの多くは、以下の2点において本質的な違いがあります。

第一に、それらの多くはこの「エージェント」認知アーキテクチャそのものではなく、むしろ複雑で洗練された処理チェーン、あるいは「状態機械（ステートマシン）」に近い仕組みを採用しています。この傾向を象徴する公開プロジェクトの好例として、GPT-Researcher や Sweep.dev が挙げられます。

GPT-Researcher については、LangChain のブログで何度も取り上げてきました。先週も同社と協力し、LangChain テンプレート を公開しました。このツールは、LLM（大規模言語モデル）を活用した複雑なアプリケーションの中でも、特に価値ある成果を生み出す数少ない存在です。

しかし、その認知アーキテクチャ（cognitive architecture）を詳しく見ると、それはむしろ複雑な「チェーン」に近い構造をしています。下の図を見ていただくと、処理の流れが一方通行であることがわかります。確かに多くの複雑なステップを実行しますが、手順は明確に定義されています。まずサブクエリ（下位質問）を生成し、それぞれのリンクを取得します。次に各リンクの内容を要約し、最後にそれらを統合して研究レポートを作成するのです。

GPT-Researcher の認知アーキテクチャは、同社の GitHub リポジトリから引用したものです。

また、Sweep.dev も優れた事例です。彼らは今夏、自社の認知アーキテクチャについて解説するブログ記事（こちら）を公開しており、そこには非常に分かりやすい図解も含まれています。

Sweep.dev のブログから引用した、同社の認知アーキテクチャには明確な遷移とステップが存在します。まず検索を行い、次に計画を生成し、その計画を実行します。その後、検証ステップが待っています。ここを通過すれば PR が作成され Sweep は完了です。もし失敗すれば、新しい計画を立てます。これは異なる状態間の遷移が明確に定義された、非常に分かりやすい状態機械と言えます。

私たちが協力している多くのビルダーやチームも、アプリケーションを支えるために複雑な連鎖や状態機械を活用しています。

💡

これらの認知アーキテクチャの利点はシンプルです。より高い制御性です。問題ごとに性質は異なり、その問題領域に最適な認知アーキテクチャを選ぶことが、良好な体験を提供するために不可欠です。

このエージェントアーキテクチャに近いものを利用するアプリケーションでは、GPT と異なる点があります。それは、エージェントへコンテキストをどのように提供するかという点です。

私は Flo Crivello 氏と認知アーキテクチャについて議論しましたが、彼はエージェントアーキテクチャにおける重要な違いとして、コンテキストの提供方法に言及しました。覚えておいてください。私たちが「興味深い LLM アプリケーション」として最もよく説明するのは、「文脈を認識した推論アプリケーション」です。

💡

コンテキストはプル（Pulling）またはプッシュ（Pushing）によって提供されます。パフォーマンスと信頼性の高いエージェントでは、コンテキストの多くがプッシュ方式で提供されているのが一般的です。

エージェントがコンテキストを「プル（pull）」するとは、何を意味するのでしょうか。これは、エージェント自身が必要なコンテキストを判断し、それを要求するという行為を指します。通常、このプロセスはツールを通じて行われます。

具体的な例として、SQL データベースと対話するためのエージェントを考えてみましょう。このエージェントは、データベース内にどのようなテーブルが存在するかを知る必要があるかもしれません。そこで、データベース内のテーブル一覧を返すツールを用意し、エージェントが開始時にそのツールを呼び出せるようにします。

一方、コンテキストが言語モデルへ「プッシュ（push）」される場合、特定のコンテキストを取得してプロンプトに挿入すべきかどうかが、アプリケーションのロジックの中に組み込まれます。前述の SQL エージェントの例で言えば、事前に SQL テーブルを自動的に取得し、プロンプトに埋め込むことに相当します。

エージェントアーキテクチャを採用している多くのアプリケーションでは、コンテキストのプッシュが大量に行われています。例えば、LangChain の SQL エージェントや Pandas エージェントでは、テーブルスキーマがシステムメッセージの一部として含まれています。また、Rubrics チーム が Cal.com のために構築したエージェントも、大量のユーザー情報をプロンプトにプッシュしています。

このコンテキストの「プッシュ型」と「プル型」の使い分けにより、開発者はより大きな制御権を手にできます。これによって、LLM が行動を決断する際にどのコンテキストが関連するかを強制することが可能になります。具体的には、「どのコンテキストが最も重要か」「どのようにそのコンテキストを取得するか」「どう提供すべきか」といった小さな判断の積み重ねが、品質とパフォーマンスに大きな影響を与えます。

GPTs や Assistant API は、必要に応じてコンテキストを引き出すことに依存する制約のないエージェントアーキテクチャをアプリケーションに提供しています。これは素早く始めたい場合や単純なタスクには素晴らしいアプローチですが、より複雑なユースケースにおいては、目の前の問題に適した認知アーキテクチャを制御できることが何にも代えがたく重要です。

オープンかクローズドか

認知アーキテクチャの選択に加え、Assistant API や GPTs のもう一つの大きな特徴は、その認知アーキテクチャ自体がクローズド（非公開）である点です。内部で何が起きているのか分かりません。正確なアルゴリズムも不明です。チャット履歴のコンテキストをどう管理しているかも分かりません。検索処理についても同様です。

現在はこれらの仕組みについて推測することはできます。しかし、機能が追加され続け複雑さが増すにつれて、それは次第にブラックボックス化していくでしょう。

💡

オープンソースとクローズドソースをめぐる議論の多くは、モデルそのものを中心に展開されています。しかし、もう一つ考慮すべき重要な要素があります。オープンソースの認知アーキテクチャとクローズドソースの認知アーキテクチャです。

このテーマが、モデル自体に関する議論よりも大きな話題になる日が必ず来ると私は確信しています。1 年前であれば、新機能や社内の注力のほとんどは「より良いモデル」の開発に向けられていました。しかし現在では、コアとなるモデルの改良と、それらをエージェントとしてどう連携させるかの最適化という 2 つの方向性が半々ずつに焦点が移ってきています。

この傾向の重要性を示す証拠の一つとして、AGI（汎用人工知能）に関する決定版の読書リストを提供している Karpathy の Twitter フィードが、LLM を OS（オペレーティングシステム）と捉える考え方に徐々にシフトしていることが挙げられます。先週末には、まさにそのテーマについて素晴らしい動画も公開されました。

私はこの流れが継続し、OpenAI や他の研究機関も、モデル単体の開発だけでなく、モデルを取り巻くプラットフォームやツールへの投資をさらに強化していくだろうと考えています。AGI への道は、より優れたモデルだけにあるのではありません。それらを周囲の環境とどう結びつけるかが鍵となります。これらの研究所の焦点がシフトするにつれ、オープンソース対クローズドソースに関する議論も、モデルだけでなく認知アーキテクチャについても活発化していくことを期待し、願っています。

認知アーキテクチャはビールの味を良くするのか？

ジェフ・ベゾスには「ビールの味を良くすることに集中せよ」という有名な言葉があります。これは産業革命初期の醸造所が自前で発電を行っていた時代を指しています。優れたビールを作る能力は、その電力供給がどれだけ独自化されているかに依存するわけではありません。むしろ、発電を外注して醸造に専念した企業が有利になったのです。

では、認知アーキテクチャにおいても同様のことが言えるのでしょうか？自社の認知アーキテクチャを完全に制御することが、本当に「ビールの味」を良くすることにつながるのでしょうか？現時点では、私は明確に「イエス」と答えます。その理由は二つあります。

第一に、複雑なエージェントを実際に機能させることは非常に困難だからです。もしあなたのアプリケーションがエージェントの動作に依存しており、かつエージェントを動かすことが課題であるなら、それをうまくこなせる時点で、あなたはすでに競合他社に対して明確な優位性を持っていることになります。

第二に、生成 AI アプリケーションの価値は、認知アーキテクチャのパフォーマンスと密接に結びついているケースが多いからです。現在、多くの企業がコーディング支援やカスタマーサポート用のエージェントを販売しています。そのような場合、認知アーキテクチャそのものが製品なのです。

この最後の理由こそが、企業が単一企業に支配された認知アーキテクチャに縛り付けられることに懐疑的な理由でもあります。これはクラウドや LLM の場合とは異なる種類のロックインです。それらのケースでは、特定のアプリケーションを構築・稼働させるためにクラウドリソースや LLM を利用します。しかし、認知アーキテクチャがそれ自体で完全なアプリケーションになりつつあるなら、それを他社に縛り付けられることは望ましくありません。

LangChain の役割

LangChain では、LLM が真に変革をもたらすエージェントのようなシステムを動かす世界を実現できると信じています。しかし、その道筋は企業が自らの認知アーキテクチャをコントロールできるものだと考えています。

💡

LLM を活用したアプリケーションを開発するチームとの協業を通じて得た経験から言えるのは、エージェントのようなシステムを確実に動作させることがいかに難しいかです。汎用的なエージェントアーキテクチャを使えばデモや単純なおもちゃのようなアプリは作れますが、パフォーマンス向上や大規模運用が必要な段階では、必ず自社のアプリケーションとユースケースに合わせてカスタマイズする必要があります。

これには多大なエンジニアリングの労力が必要です。私たちはその支援のためにツールを開発しています。

LCEL を使えば、チェーンを柔軟に組み合わせる方法が得られます。また LangChain には 600 以上の統合機能 が用意されており、使用するモデルやベクトルストア、データベースを自由に選べます。

LangSmith では、チームの多くが直面するデバッグ体験の向上に注力しました。さらに、本番環境への移行を支援するため、回帰テストやモニタリング、データアノテーション、プロンプトハブといった管理ツールも追加しています。

また最近では OpenGPTs もリリースしました。これは Assistants API や GPTs と同じ体験を再現しようとした試みです（私たちが実装した GPTs は、Assistants API の上にシンプルな UI を乗せたものです）。オープンソース化されており、現在は 4 つの異なるモデルプロバイダーで設定可能です。また、使用される検索方法も容易に変更できます。

これはまだ始まりに過ぎません。