How to think about agent frameworks｜エージェントフレームワークをどう捉えるべきか | AIニュース最前線

**TL;DR:** - 信頼性の高いエージェントシステムを構築する上で難しい部分は、各ステップにおいて LLM（大規模言語モデル）が適切なコンテキストを持っていることを保証することです。これには、LLM に含める内容を正確に制御することと、関連するコンテンツを生成するために適切なステップを実行することが含まれます。 - エージェントシステムは、ワークフローとエージェント（およびその間のあらゆるもの）の両方から構成されます。 - 多くのエージェントフレームワークは、宣言型または命令型のオーケストレーションフレームワークではなく、単なるエージェントの抽象化のセットに過ぎません。 - エージェントの抽象化は始めやすくする一方で、しばしば複雑さを増し、各ステップで LLM が適切なコンテキストを持っていることを保証することを困難にする可能性があります。 - 形状や規模が異なるあらゆる形態のエージェントシステム（エージェントまたはワークフロー）は、フレームワークによって提供されるか、ゼロから構築されることとなる、同じセットの便利な機能から恩恵を受けます。 - LangGraph は、宣言型と命令型の両方の API を備えたオーケストレーションフレームワークとして捉えるのが最も適切であり、その上に一連のエージェント抽象化が構築されています。 OpenAI は最近、エージェントの構築に関するガイドを公開しましたが、そこには以下のような誤った見解が含まれています： ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69cbad01d2a13d9d604fd53d_Go0FliaXoAANDWD.jpeg) この呼びかけは当初私を怒らせましたが、回答を書くことを始めてから気づきました：エージェントフレームワークについて考えるのは複雑なのです！おそらく 100 種類以上の異なるエージェントフレームワークがあり、比較するための軸も多数存在します。時にはそれらが混同され（例えばこの引用のように）、過度な宣伝やポーズ、ノイズが溢れています。しかし、エージェントフレームワークに関する精密な分析や思考はほとんど行われていません。このブログはその試みです。以下をカバーします： - 背景情報 エージェントとは何か？ - エージェント構築の難しさ - LangGraph とは何か？ - エージェントフレームワークの種類 「エージェント」対「ワークフロー」 - 宣言型 vs 非宣言型 - エージェント抽象化 - マルチエージェント - よくある質問 フレームワークの価値とは何か？ - モデルが向上すれば、すべてがワークフローではなくエージェントになるのか？ - OpenAI はその見解で何を間違えたのか？ - すべてのエージェントフレームワークはどのように比較されるか？ 本ブログ全体を通じて、いくつかの資料を繰り返し参照します： - エージェント構築に関する OpenAI のガイド（私は特に良いとは思っていません） - 効果的なエージェント構築に関する Anthropic のガイド（これは非常に気に入っています） - LangGraph（信頼性の高いエージェントを構築するための私たちのフレームワーク） ## 背景情報 本ブログの残りの部分を準備するための有益な文脈。 ## エージェントとは何か エージェントには一貫した定義がなく、しばしば異なる視点から提示されます。 OpenAI は、エージェントを定義する際に、より高レベルで思想的リーダーシップを発揮するアプローチを取っています。 **エージェントとは、あなたの代わりに独立してタスクを完了するシステムです。 私は個人的にこの定義を好んでいません。これは実際にはエージェントが何かを理解するのに役立たない曖昧な声明であり、単なる思想リーダーシップであって、実用的ではありません。 これを Anthropic の定義と比較してみましょう: 「エージェント」は複数の方法で定義できます。ある顧客は、エージェントを、さまざまなツールを使用して複雑なタスクを完了するために、長期間にわたって独立して動作する完全に自律的なシステムとして定義します。他の人々は、この用語を、事前に定義されたワークフローに従うより指示的な実装を説明するために使用しています。Anthropic では、これらのすべてのバリエーションを**アジェンティック・システム**と分類しますが、**ワークフロー**と**エージェント**の間には重要なアーキテクチャ上の区別を設けます:**ワークフロー**とは、LLM とツールが事前に定義されたコードパスを通じてオーケストレーションされるシステムです。 一方、**エージェント**は、LLM が自身のプロセスやツールの使用を動的に指示し、タスクをどのように完了するかについて制御を維持するシステムです。 私は Anthropic の定義をいくつかの理由で好んでいます: - エージェントの定義がはるかに精密で技術的です。 - また、「アジェンティック・システム」という概念にも言及しており、ワークフローとエージェントの両方をそのバリエーションとして分類しています。これは素晴らしいと思います。 💡 実際に運用されている「アジェンティック・システム」のほとんどは、**ワークフロー**と**エージェント**の**組み合わせ**です。 ブログ記事の後半部分で、Anthropic はエージェントを「通常は環境からのフィードバックに基づいてツールを使用する LLM のループ」と定義しています。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69cbad01d2a13d9d604fd540_58d9f10c985c4eb5d53798dea315f7bb5ab6249e-2401x1000.webp) 冒頭でエージェントに対して壮大な定義を掲げているにもかかわらず、これは基本的に OpenAI が意味するところとほぼ同じです。 これらの種類のエージェントは、以下のパラメータによって特徴づけられます： - 使用するモデル - 使用する指示（システムプロンプト） - 使用するツール ループ内でモデルを呼び出します。モデルがツールの呼び出しを決定した場合、そのツールを実行し、何らかの観測結果やフィードバックを取得して、それを LLM に戻します。LLM がツールの呼び出しを行わないと判断するまで（または停止基準を満たすツールを呼び出すまで）、この処理を続けます。 OpenAI と Anthropic の両社は、ワークフローがエージェントとは異なる設計パターンであることを明確に指摘しています。ここでは LLM の制御は弱く、フローはより決定論的になります。これは有益な区別です！ OpenAI と Anthropic はどちらも、必ずしもエージェントが必要であるわけではないことを明示的に述べています。多くの場合、ワークフローの方が単純で、信頼性が高く、コストが安く、高速であり、パフォーマンスも優れています。Anthropic の記事からの素晴らしい引用： **LLM を用いてアプリケーションを構築する際は、可能な限り最もシンプルな解決策を見つけることを推奨し、必要が生じた場合にのみ複雑さを増すようにしてください。これは、エージェントシステム自体を構築しないことにもなり得ます。エージェントシステムは、より優れたタスクパフォーマンスのためにレイテンシとコストをトレードオフすることが多く、このトレードオフがどの時点で妥当となるかを検討する必要があります。 より多くの複雑さが正当化される場合、ワークフローは明確に定義されたタスクに対して予測可能性と一貫性を提供しますが、大規模な柔軟性とモデル駆動型の意思決定が必要となる場合はエージェントの方が優れた選択肢となります。 OpenAI も同様の見解を示しています: エージェントの構築を決定する前に、ユースケースがこれらの基準を明確に満たすことを検証してください。そうでない場合、決定論的な解決策で十分である可能性があります。 実際には、「エージェントシステム」のほとんどはワークフローとエージェントの組み合わせであることがわかります。そのため、私は実際に「それがエージェントかどうか」という議論よりも、「システムがどの程度エージェント的か」という議論を好みます。この考え方の提案者である素晴らしいアンドリュー・ン氏に感謝します [こちら](https://x.com/AndrewYNg/status/1801295202788983136?ref=blog.langchain.com) をご覧ください: **何かがエージェントかどうかを二元的に選択する必要があるのではなく、システムは異なる程度で「エージェント的」であると考えた方がより有用だと考えました。名詞の「エージェント」とは異なり、「エージェント的（agentic）」という形容詞を用いることで、そのようなシステムを考察し、これらすべてをこの成長中のムーブメントに含めることができます。 ## エージェント構築の難しさとは何でしょうか？ 私は、ほとんどの人がエージェントを構築するのは難しいと同意するだろうと思います。あるいは——プロトタイプとしてのエージェントを作るのは簡単ですが、ビジネスに不可欠なアプリケーションを支える信頼性の高いものを作ることは難しいのです。 その難しさの本質はまさに「信頼性を高めること」にあります。Twitter で見栄えのするデモを簡単に作れるかもしれません。しかし、それをビジネスに不可欠なアプリケーションの基盤として運用できるでしょうか？多くの労力なしにはできません。 数ヶ月前、エージェント構築者たちに対して調査を行い、「生産環境でより多くのエージェントを導入する際の最大の制限は何ですか？」と尋ねました。圧倒的に多かった回答は「パフォーマンスの質」でした——依然としてこれらのエージェントを機能させるのは非常に難しいのです。 *なぜエージェントの性能が時折低下するのでしょうか？* 大規模言語モデル（LLM）が誤作動を起こすからです。 *なぜ LLM は誤作動を起こすのでしょうか？* 2 つの理由があります：(a) モデル自体が十分ではない、(b) モデルに渡されるコンテキストが不適切（または不完全）であること。 私たちの経験則では、後者のケースが非常に頻繁に見られます。これを引き起こす要因は何でしょうか？ - 不十分または短すぎるシステムメッセージ - 曖昧なユーザー入力 - 適切なツールへのアクセス権がない - ツールの説明が不明瞭である - 正しいコンテキストが渡されていない - 不適切にフォーマットされたツールのレスポンス 💡 信頼性の高いエージェントシステムを構築する上で難しい部分は、各ステップにおいて LLM が適切なコンテキストを持っていることを保証することです。これには、LLM に入力される内容を正確に制御することと、関連するコンテンツを生成するために適切なステップを実行することが含まれます。** エージェントフレームワークについて議論する際、この点を心に留めておくことが役立ちます。LLM に渡される**正確な**内容を制御しにくくするフレームワークは、単に邪魔をしているだけです。正しいコンテキストを LLM に渡すこと自体がすでに十分難しいのに、なぜ自らそれを難しくする必要があるのでしょうか？ ## LangGraph とは何か 💡 LangGraph は、宣言型と命令型の両方の API を備えたオーケストレーションフレームワーク（**orchestration framework**: 調整・制御フレームワーク）として考えられ、その上に一連のエージェント抽象化（**agent abstractions**: エージェントの抽象概念）が構築されています。 LangGraph は、エージェントシステムを構築するためのイベント駆動型フレームワークです。これを使用する最も一般的な方法は以下の 2 つです： - 宣言的でグラフベースの構文 - 低レベルフレームワークの上に構築されたエージェント抽象化 LangGraph は [機能的 API](https://langchain-ai.github.io/langgraph/concepts/functional_api/?ref=blog.langchain.com) もサポートしており、さらに基盤となる [イベント駆動型 API](https://langchain-ai.github.io/langgraph/concepts/pregel/?ref=blog.langchain.com) にも対応しています。[Python](https://langchain-ai.github.io/langgraph/?ref=blog.langchain.com) と [Typescript](https://langchain-ai.github.io/langgraphjs/?ref=blog.langchain.com) の両方のバリアントが存在します。 エージェントシステムは、[ノード](https://langchain-ai.github.io/langgraph/concepts/low_level/?ref=blog.langchain.com#nodes)と [エッジ](https://langchain-ai.github.io/langgraph/concepts/low_level/?ref=blog.langchain.com#edges) として表現できます。ノードは作業の単位を表し、一方エッジは遷移を表します。ノードとエッジは単なる通常の Python または TypeScript のコードに過ぎません。つまり、グラフの構造は宣言的な方法で表現されますが、グラフロジックの内部動作は通常の命令型コードです。エッジには [固定](https://langchain-ai.github.io/langgraph/concepts/low_level/?ref=blog.langchain.com#normal-edges) 型と [条件付き](https://langchain-ai.github.io/langgraph/concepts/low_level/?ref=blog.langchain.com#conditional-edges) 型の両方があります。したがって、グラフの構造は宣言的ですが、グラフ内を通過する経路は完全に動的になり得ます。 LangGraph には [組み込みの永続化レイヤー](https://langchain-ai.github.io/langgraph/concepts/persistence/?ref=blog.langchain.com) が備わっています。これにより、[フォールトトレランス](https://langchain-ai.github.io/langgraph/concepts/persistence/?h=fault+to&ref=blog.langchain.com#fault-tolerance)、[短期記憶](https://langchain-ai.github.io/langgraph/concepts/memory/?ref=blog.langchain.com#short-term-memory)、および [長期記憶](https://langchain-ai.github.io/langgraph/concepts/memory/?ref=blog.langchain.com#long-term-memory) が可能になります。 この永続化レイヤーはまた、「人間-in-the-loop」および「人間-on-the-loop」といったパターン、つまり中断、承認、再開、タイムトラベルなどを可能にします。 LangGraph にはトークン、ノード更新、任意のイベントのストリーミング [streaming] に対する組み込みサポートがあります。 LangGraph は、デバッグ、評価、観測のために LangSmith とシームレスに統合されます。 ## エージェントフレームワークの種類 エージェントフレームワークはいくつかの次元において異なります。これらの次元を理解し、混同しないことが、エージェントフレームワークを適切に比較するための鍵となります。 ## ワークフロー vs エージェント ほとんどのフレームワークには、より高レベルなエージェント抽象化が含まれています。一部のフレームワークには、一般的なワークフローのための抽象化も含まれています。LangGraph は、エージェントシステムを構築するための低レベルのオーケストレーションフレームワークです。LangGraph は [ワークフロー、エージェント、およびその間のあらゆるもの](https://langchain-ai.github.io/langgraph/concepts/agentic_concepts/?ref=blog.langchain.com) をサポートしています。私たちはこれが重要だと考えています。前述したように、生産環境で稼働しているほとんどのエージェントシステムは、ワークフローとエージェントの組み合わせです。本番環境対応のフレームワークは両方をサポートする必要があります。 信頼性の高いエージェントを構築する際の難しさ、つまり LLM に適切なコンテキストを提供することについて思い出しましょう。ワークフローが有用な理由の一部は、LLM に対して適切なコンテキストを渡すことを容易にする点にあります。データの流れをあなたが完全に決定できるのです。 アプリケーションを「ワークフロー」から「エージェント」までのスペクトラム上のどこに構築するかを考える際、2 つの点を考慮する必要があります： - 予測可能性と自律性のトレードオフ - 低い参入障壁と高い拡張性 **予測可能性と自律性のトレードオフ** システムがよりエージェンシー（自律性）を持つようになるほど、その挙動は予測しにくくなります。 時には、ユーザーの信頼獲得や規制対応などの理由から、システムの挙動を予測可能にしたい、あるいはそうする必要がある場合があります。 信頼性と予測可能性は 100% 一致するわけではありませんが、実務的にはこれらが密接に関連していることが多いです。 この曲線上でどこを目指すかは、アプリケーションごとに非常に具体的になります。LangGraph を用いれば、この曲線上のあらゆる地点でアプリケーションを構築でき、あなたが目指す特定のポイントに移動することも可能です。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69cbad01d2a13d9d604fd547_Screenshot-2025-04-20-at-10.43.31-AM.png) **低い参入障壁と高い拡張性** フレームワークを考える際、その「床（参入障壁）」と「天井（拡張性）」について考えるのは有益です： - Low floor（低い参入障壁）：初心者にも親和性が高く、すぐに使い始められるフレームワーク - High floor（高い参入障壁）：学習曲線が急峻であり、効果的に使用するには相当な知識や専門性が求められるフレームワーク - Low ceiling（低い天井）：実現可能な範囲に制限があり、すぐに限界に達してしまうフレームワーク - High ceiling（高い天井）：高度なユースケースに対して広範な機能と柔軟性を提供し、ユーザーの成長とともに拡張可能となるフレームワーク Workflow フレームワークは高い天井を持ちますが、参入障壁も高いです。エージェントロジックの多くを自分で記述する必要があります。 Agent フレームワークは参入障壁が低く、すぐに使い始められますが、非自明なユースケースには不十分な場合があります。 LangGraph は、低い参入障壁（[組み込みのエージェント抽象化](https://langchain-ai.github.io/langgraph/agents/overview/?ref=blog.langchain.com)によりすぐに使い始められる）と高い天井（高度なユースケースを実現するための [低レベル機能](https://langchain-ai.github.io/langgraph/?ref=blog.langchain.com)）の両方の側面を持つことを目指しています。 ## 宣言的 vs 非宣言的 宣言的フレームワークにはメリットがあります。一方で欠点もあります。これはプログラマーの間で尽きることのない議論であり、人によって好みが分かれます。 「非宣言的」と言う場合、通常は対義語として「命令的」を指しています。 多くの人は LangGraph を宣言的フレームワークと説明しますが、それは部分的にしか正しくありません。 まず、ノードとエッジ間の接続は宣言的な方法で行われますが、実際のノードやエッジ自体は単なる Python や TypeScript の関数に過ぎません。したがって、LangGraph は宣言型と命令型の融合のようなものです。 第二に、推奨される宣言型 API 以外にも他の API を実際にサポートしています。具体的には、[機能的 API](https://langchain-ai.github.io/langgraph/concepts/functional_api/?ref=blog.langchain.com) と [イベント駆動型 API](https://langchain-ai.github.io/langgraph/concepts/pregel/?ref=blog.langchain.com) の両方をサポートしています。宣言型 API が有用なメンタルモデルであると考えていますが、すべての人に適しているわけではないことも認識しています。 LangGraph に関する一般的なコメントとして、「これは Tensorflow（宣言型の深層学習フレームワーク）のようであり、Agents SDK などのフレームワークは Pytorch（命令型の深層学習フレームワーク）のようだ」というものがあります。 これは誤りです。Agents SDK（および元の LangChain、CrewAI など）のようなフレームワークは、宣言型でも命令型でもありません。それらは単なる抽象化です。エージェントの抽象化（Python クラス）を持ち、その中にエージェントを実行する一連の内部ロジックが含まれています。これらは本質的にオーケストレーションフレームワークではなく、単なる抽象化に過ぎません。 ## エージェント抽象化 ほとんどのエージェントフレームワークには、エージェントの抽象化が含まれています。通常は、プロンプト、モデル、ツールを扱うクラスとして始まり、その後いくつかのパラメータが追加され…さらに多く追加され…そしてさらに多くのパラメータが加わります。最終的に、多様な振る舞いを制御する無数のパラメータの羅列となり、すべてがクラスの背後に抽象化されてしまいます。何が起こっているかを確認したりロジックを変更したい場合、クラスの中に入り込んでソースコードを修正する必要があります。 💡 これらの抽象化は、各ステップで LLM（大規模言語モデル）に実際に入力される内容を理解したり制御したりすることを非常に困難にしてしまいます。これは重要です—この制御権を持つことは、信頼性の高いエージェントを構築する上で不可欠です（前述の通り）。これがエージェント抽象化が抱える危険性です。 私たちは痛い目を見てこれを学びました。これが元々の LangChain のチェーンやエージェントにおける問題でした。それらは邪魔になる抽象化を提供していたのです。2 年前のその中の一つの抽象化として、モデル、プロンプト、ツールを受け取るエージェントクラスがありました。これは新しい概念ではありません。当時十分な制御権を返すものではなかったし、現在も同様です。 明確に言っておきますが、これらのエージェント抽象化にはある程度の価値があります。始めるのが容易になるからです。しかし、信頼性の高いエージェントを構築するには、これらのエージェント抽象化はまだ十分ではないと考えています（おそらく永遠にそうではないでしょう）。 これらのエージェント抽象化を捉える最良の方法は、Keras のように考えることです。これらは簡単に始められるためのより高レベルな抽象化を提供しますが、それらが下位レベルのフレームワークの上に構築されており、将来的に使いこなせなくなることを防ぐことが極めて重要です。 そのため、私たちはエージェント抽象化を LangGraph 上に構築しました。これにより、エージェントを簡単に始めることができますが、必要に応じて下位レベルの LangGraph に容易に切り替えることも可能です。 ## マルチエージェント 多くの場合、エージェントシステムは単一のエージェントだけでなく、複数のエージェントを含みます。OpenAI はそのレポートで次のように述べています： **多くの複雑なワークフローにおいて、プロンプトやツールを複数のエージェントに分割することで、パフォーマンスとスケーラビリティの向上が図れます。エージェントが複雑な指示に従えなかったり、誤ったツールを継続的に選択したりする場合は、システムをさらに細分化し、より明確に区別されたエージェントを導入する必要があります。 💡 マルチエージェントシステムの鍵となる部分は、それらがどのように通信するかです。再び言いますが、エージェント構築における難しい点は、LLM に対して適切なコンテキストを提供することです。これらのエージェント間のコミュニケーションは非常に重要です。 これを行う方法は数多くあります！ハンドオフはその一つです。これは私が実際に非常に気に入っている Agents SDK のエージェント抽象化の一つです。 しかし、これらのエージェントが通信するための最良の方法は、場合によってはワークフローであることもあります。Anthropic のブログ記事にあるすべてのワークフロー図を抽出し、LLM 呼び出しをエージェントに置き換えてみてください。このワークフローとエージェントの融合は、しばしば最も高い信頼性をもたらします。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69cbad01d2a13d9d604fd543_7418719e3dab222dccb379b8879e1dc08ad34c78-2401x1000.webp) 再び申し上げますが、エージェントシステムは単なるワークフローでもなければ、単一のエージェントでもありません。それらはしばしば両者の組み合わせとして機能します。Anthropic のブログ記事で指摘されているように： これらのパターンを組み合わせ、カスタマイズする**これらのビルディングブロック（構成要素）は指針となるものではありません。開発者が異なるユースケースに合わせて形状を変え、組み合わせることのできる一般的なパターンです。 ## 一般的な質問 評価すべきフレームワークの異なる軸を定義し、探求したところで、次にいくつかの一般的な質問に答えてみましょう。 ## フレームワークの価値とは何か？ エージェントシステムを構築するためにフレームワークが必要かどうかを疑問視する人々をよく見かけます。エージェントフレームワークはどのような価値を提供できるのでしょうか？ **エージェント抽象化（Agent Abstractions）** フレームワークは、始めるのに容易にし、エンジニアがプロジェクトを構築・保守するための共通の手段を提供するという点で汎用的に有用です。これはオンボーディングとメンテナンスを容易にします。上記でも言及した通り、エージェント抽象化には実際のデメリットも存在します。ほとんどのエージェントフレームワークにおいて、これが提供する唯一の価値となっています。しかし、LangGraph については、このようにならないように非常に努力しました。 **短期記憶（Short-term memory）** 今日の多くのエージェント型アプリケーションには、何らかのマルチターン（例：チャット）コンポーネントが含まれています。LangGraph は、[マルチターン体験（スレッド）を可能にするための本番環境対応ストレージ](https://langchain-ai.github.io/langgraph/concepts/memory/?ref=blog.langchain.com#short-term-memory) を提供しています。 **長期記憶** まだ初期段階ではありますが、エージェントシステムが経験から学習する（例えば、会話間を跨いで情報を記憶するなど）ことに対して非常に楽観的です。LangGraph は、[スレッド間の記憶のための本番環境対応ストレージ](https://langchain-ai.github.io/langgraph/concepts/memory/?ref=blog.langchain.com#long-term-memory) を提供しています。 **人間ループ（Human-in-the-loop）** 多くのエージェント型システムは、何らかの人間ループコンポーネントを備えることでより良くなります。例としては、ユーザーからのフィードバックを取得する、ツール呼び出しの承認を行う、またはツール呼び出しの引数を編集するなどがあります。LangGraph は、[本番環境システムでこれらのワークフローを可能にするための組み込みサポート](https://langchain-ai.github.io/langgraph/concepts/human_in_the_loop/?ref=blog.langchain.com) を提供しています。 **人間ループ外（Human-on-the-loop）** 実行中のエージェントに対してユーザーが影響を与えることを許可するだけでなく、事後にユーザーがエージェントの軌跡を検査し、さらに以前のステップに戻ってそこから変更を加えて再実行することも有用です。これを「人間ループ外」と呼び、LangGraph はこれのための [組み込みサポート](https://langchain-ai.github.io/langgraph/concepts/time-travel/?ref=blog.langchain.com) を提供しています。 **ストリーミング** 多くのエージェント型アプリケーションは実行に時間がかかるため、エンドユーザーへの更新情報を提供することが、良好なユーザー体験を提供する上で極めて重要になります。LangGraph は、トークン、グラフステップ、および任意のストリームの [組み込みストリーミング](https://langchain-ai.github.io/langgraph/concepts/streaming/?ref=blog.langchain.com) を提供しています。 **デバッグ/観測性** 信頼性の高いエージェントを構築する上で難しい部分は、LLM（大規模言語モデル）に適切なコンテキストを渡していることを確認することです。エージェントが実行した正確なステップや、各ステップにおける入力・出力を調査できることは、信頼性の高いエージェントを構築するために不可欠です。LangGraph は、最高クラスのデバッグと観測性を実現するために [LangSmith](https://docs.smith.langchain.com/?ref=blog.langchain.com) とシームレスに統合されています。なお：[AI 観測性](https://www.langchain.com/resources/ai-observability?ref=blog.langchain.com) は、従来のソフトウェアの観測性とは異なります（これは別の記事で詳しく扱うべきテーマです）。 **フォールトトレランス** フォールトトレランスは、分散アプリケーションを構築するための従来のフレームワーク（Temporal など）における重要なコンポーネントです。LangGraph は、[耐久性のあるワークフロー](https://langchain-ai.github.io/langgraph/concepts/durable_execution/?ref=blog.langchain.com) と [設定可能なリトライ](https://langchain-ai.github.io/langgraph/how-tos/node-retries/?h=retr&ref=blog.langchain.com) を活用することで、フォールトトレランスの実装を容易にします。 **最適化** 手動でプロンプトを微調整するのではなく、評価用データセットを定義し、それに基づいてエージェントを自動的に最適化した方が簡単な場合もあります。LangGraph は現時点ではこれを標準機能としてサポートしていませんが、まだ時期尚早だと考えています。しかし、これは考慮すべき興味深い次元であり、常に注視している事項であるため、あえて記載しました。現在、これに最適なフレームワークは dspy です。 💡 これらの価値提案（エージェントの抽象化を除く）は、すべてエージェント、ワークフロー、およびその間のあらゆるものに対して価値を提供します。 **では、本当にアジェンティック・フレームワークが必要なのでしょうか？** あなたのアプリケーションがこれらすべての機能を必要としない場合、または自分で実装したい場合は、フレームワークを必ずしも必要としないかもしれません。一部の機能（例えば短期記憶など）はそれほど複雑ではありません。一方で、他の機能（例えば人間によるループ制御や LLM 固有の観測性など）はより複雑です。 そしてエージェントの抽象化については、Anthropic の投稿で述べられている内容に同意します： **フレームワークを使用する場合は、その背後にあるコードを理解してください。内部構造に関する誤った仮定が、顧客のエラーの一般的な原因となっています。** ## モデルが向上すれば、すべてがワークフローからエージェントへと移行するのか？ エージェント（ワークフローと比較して）を支持する共通の議論の一つに、「現時点では機能しないが、将来は機能するようになるため、結局は単純なツール呼び出し型のエージェントだけで十分になる」というものがあります。 私は複数のことが同時に真実になり得ると考えています： - これらのツール呼び出しエージェントのパフォーマンスは向上する - LLM に何を入力するかを制御できることは依然として非常に重要である（ゴミを入れればゴミが出る） - 一部のアプリケーションでは、このツール呼び出しループだけで十分である - 他のアプリケーションでは、ワークフローの方が単純で、安価で、高速であり、より良いものになる - ほとんどのアプリケーションにおいて、本番環境のエージェントシステムは、ワークフローとエージェントの組み合わせとなるだろう OpenAI や Anthropic がこれらの点について議論するとは思わない。Anthropic の投稿から： LLM を用いてアプリケーションを構築する際は、可能な限り最も単純な解決策を見つけることを推奨し、必要な場合にのみ複雑さを増すようにしてください。これは、エージェントシステム自体を構築しないことにもなり得る。エージェントシステムは、しばしばレイテンシとコストを犠牲にしてタスクパフォーマンスを向上させるが、このトレードオフがどの時点で妥当であるかを検討すべきだ。 そして OpenAI の投稿から： エージェントの構築に着手する前に、ユースケースがこれらの基準を明確に満たすことを検証せよ。そうでなければ、決定論的な解決策で十分かもしれない。 この単純なツール呼び出しループだけで十分なアプリケーションが存在し得るだろうか？私は、これはおそらく、あなたのユースケースに特化した大量のデータを用いてトレーニング/ファインチューニング/強化学習されたモデルを使用している場合にのみ真実となるだろう。これは 2 つの方法で起こり得る： - あなたのタスクはユニークです。多くのデータを収集し、独自のモデルをトレーニング/ファインチューニング/強化学習します。 - あなたのタスクはユニークではありません。大規模モデルラボが、あなたのタスクに代表されるデータでトレーニング/ファインチューニング/強化学習を行っています。（補足：もし私が、自分のタスクがユニークではない分野で垂直統合型スタートアップを構築していたなら、そのスタートアップの長期的な存続可能性についてかなり心配するでしょう）。 あなたのタスクはユニークです ほとんどのユースケース（特にエンタープライズユースケース）がこのカテゴリに当てはまると私は確信しています。AirBnb がカスタマーサポートをどのように処理するかは、Klarna のそれとは異なり、Rakuten のそれとも異なります。これらのタスクには非常に多くの微妙な違いがあります。カスタマーサポート分野で先駆的なエージェント企業である Sierra は、単一のカスタマーサポート*エージェント*を構築しているのではなく、むしろカスタマーサポートエージェント*プラットフォーム*を構築しています： **Sierra Agent SDK を使用すると、開発者は宣言型プログラミング言語を用いて、合成可能なスキルを組み合わせて手続き的知識を表現することで、強力かつ柔軟なエージェントを構築できます。 各企業の顧客対応体験はユニークすぎて汎用的なエージェントではパフォーマンスが十分でないため、彼らはそうする必要があります。 特定のタスク用にトレーニングされたモデルを使用した単純なツール呼び出しループを持つエージェントの一例：[OpenAI の Deep Research](https://www.sequoiacap.com/podcast/training-data-deep-research/?ref=blog.langchain.com)。つまり、これは可能であり、素晴らしいエージェントを生み出すこともできます。 もし特定のタスクに対して SOTA モデルを訓練できるのであれば、確かに任意のワークフローを可能にするフレームワークは不要であり、単純なツール呼び出しループを使用するだけで済みます。この場合、エージェントがワークフローよりも好まれることになります。 私の頭の中にある非常にオープンな問いがあります：自社のタスクに対して SOTA モデルを訓練するためのデータ、ツール、あるいは知識を持っているエージェント企業はどれくらいあるのでしょうか？現時点では、大規模モデルラボのみがこの作業が可能だと考えています。しかし、これは変わるでしょうか？小さな垂直特化型スタートアップが自社のタスク向けに SOTA モデルを訓練できるようになるでしょうか？この問いに対して非常に興味を持っています。現在これに取り組んでいる方がいらっしゃいましたら、ぜひご連絡ください！ あなたのタスクはユニークではない** 一部のタスクは十分に汎用的であり、大規模モデルラボがこれらの非汎用的なタスクにおける単純なツール呼び出しループを適切に実行できる十分な品質のモデルを提供できると考えています。 OpenAI は API を通じて Computer Use モデルをリリースしました。これは汎用的なコンピュータ操作データでファインチューニングされたモデルであり、その汎用的なタスクにおいて十分に良好な性能を発揮することを目的としています。（補足：まだ十分に良い状態には至っていないと考えています） コードはこれに関する興味深い例です。コーディングは比較的汎用的であり、これまでエージェントにとっての突破的なユースケースとなってきました。Claude Code と OpenAI の Codex CLI は、この単純なツール呼び出しループを利用するコーディングエージェントの 2 つの例です。基盤モデルが膨大なコードデータとタスクでトレーニングされていることは確実だと断言できます（Anthropic がこれを行っているという証拠は [こちら](https://docs.anthropic.com/en/docs/build-with-claude/tool-use/text-editor-tool?ref=blog.langchain.com) を参照してください）。 興味深いことに、一般モデルがこのデータでトレーニングされる際、このデータの正確な形状がどれほど重要なのでしょうか。Ben Hylak は先日、多くの人々の共感を呼んだように思える [興味深いツイート](https://x.com/benhylak/status/1912922457012572364?ref=blog.langchain.com) を投稿しました。 **モデルはもうカーソルの使い方を知らない。すべてターミナル向けに最適化されているのだ。だから 3.7 や o3 は Cursor 内ではひどく、それ以外では驚異的に素晴らしいのである。 これは二つのことを示唆している可能性があります： - あなたのタスクは、一般モデルが学習済みのタスクと非常に非常によく似ている必要があります。あなたのタスクが類似している度合いが少ないほど、一般モデルがあなたのユースケースに十分対応できる可能性は低くなります。 - 一般モデルを他の特定のタスクでトレーニングすると、あなたのタスクにおけるパフォーマンスが低下する可能性があります。Cursor のユースケースに似たデータが、新しいモデルのトレーニングにも同程度（あるいはそれ以上）使用されていることは間違いありません。しかし、わずかに異なる形状の新規データの流入がある場合、それは他のあらゆる種類のデータを上回る影響力を持ちます。これは現在、一般モデルが多数のタスクで本当に驚異的なパフォーマンスを発揮することが難しいことを示唆しています。 💡 エージェントがワークフローよりも好まれるアプリケーションであっても、低レベルなワークフロー制御とは無関係なフレームワークの特徴から恩恵を受けることになります：短期記憶ストレージ、長期記憶ストレージ、人間によるループ（human-in-the-loop）、人間による監視ループ（human-on-the-loop）、ストリーミング処理、フォールトトレランス、デバッグ/観測機能。 ## OpenAI はどこを間違えたのか？ OpenAI の立場を再検討すると、それは「エージェントフレームワーク」の異なる次元を混同する誤った二項対立に基づいていることがわかります。これは彼らの単一の抽象化の価値を誇張するために用いられています。具体的には、「宣言型 vs 命令型」と「エージェント抽象化」、ならびに「ワークフロー vs エージェント」を混同しています。 💡 結局のところ、これは生産環境向けのエージェントシステム構築における主な課題や、フレームワークが提供すべき本質的な価値を見失っています。その主な課題とは、開発者が LLM に到達するコンテキストを明示的に制御できつつ、永続化、フォールトトレランス（耐障害性）、人間を介したインタラクションといった生産環境上の懸念事項をシームレスに処理できる、信頼性の高いオーケストレーション層です。 私が問題視する具体的な部分を分解してみましょう: ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69cbad01d2a13d9d604fd53d_Go0FliaXoAANDWD.jpeg) "宣言的グラフと非宣言的グラフ" LangGraph は完全に宣言的ではありませんが、それなりに宣言的であるため、それが私の主な不満点というわけではありません。私が本当に問題視するのは、「非宣言的」という表現が過度な役割を担い、誤解を招いている点です。通常、人々が宣言的フレームワークを批判する際によりインペラティブ（命令型）なフレームワークを望むものです。しかし、Agents SDK はインペラティブフレームワークではありません。それは抽象化です。より適切なタイトルは、「宣言的 vs インペラティブ」や「オーケストレーションフレームワークが必要か」、あるいは主張したい内容に応じて「エージェントの抽象化こそがすべて必要である理由」や「ワークフロー対エージェント」となるはずです（彼らは以下で両方の主張をしているように見えます）。 "このアプローチは、ワークフローがより動的かつ複雑になるにつれて、すぐに煩雑で困難なものになり得る" 翻訳全文 これは宣言型か非宣言型かという問題とは何の関係もありません。この問題はワークフローとエージェントの違いに関わるものです。Agents SDK でエージェントロジックを宣言的なグラフとして容易に表現でき、そのグラフは Agents SDK と同じく動的で柔軟です。 そして、ワークフロー対エージェントの点について。多くのワークフローには、このようなレベルの動的性や複雑さは必要ありません。OpenAI も Anthropic もこれを認めています。できる限りワークフローを使うべきです。ほとんどのエージェンシーシステムは組み合わせです。はい、ワークフローが本当に動的で複雑な場合はエージェントを使用すべきです。しかし、すべてにエージェントを使うべきではありません。OpenAI は論文の前半でも実際にこう述べています。 **"しばしば専門的なドメイン固有言語の学習を必要とする"** 再び言いますが、Agents SDK は命令型フレームワークではありません。それは抽象化です。また、ドメイン固有言語（その抽象化）も持っています。現時点では、Agents SDK の抽象化を学び、それに対応して作業する必要があることは、LangGraph の抽象化を学ぶ必要があることよりも悪いと主張します。主に、信頼性の高いエージェントを構築する上で難しいのは、エージェントが適切なコンテキストを持っていることを確認することであり、Agents SDK は LangGraph よりもはるかにそれを隠蔽しているからです。 **"より柔軟である"** これは厳密に真実ではありません。むしろその逆です。Agents SDK でできることはすべて、LangGraph でもできます。Agents SDK が許容するのは、LangGraph でできることの 10% に過ぎません。 **"コードファースト"** Agents SDK では抽象化を記述しますが、LangGraph では通常のコードを大量に記述します。Agents SDK の方がコードファーストであるという点について、私はその理由がわかりません。 **「慣れ親しんだプログラミング構文を使用する」** Agents SDK を使うには、全く新しい抽象化のセットを学ぶ必要があります。一方、LangGraph では通常のコードを大量に記述します。これほど馴染み深いものはありません。 **「より動的で適応性の高いエージェントオーケストレーションを可能にする」** これもまた、宣言型か非宣言型かの問題ではありません。これはワークフローとエージェントの違いに関する話です。上記のポイントを参照してください。 ## エージェントフレームワークの比較 私たちはエージェントフレームワークのさまざまなコンポーネントについて議論してきました： - 柔軟なオーケストレーション層なのか、それとも単なるエージェント抽象化なのか？ - もし柔軟なオーケストレーション層であるなら、宣言型かそれ以外か？ - このフレームワークは（エージェント抽象化以外の）どのような機能を提供しているのか？ これらの次元をスプレッドシートにリストアップしてみるのは面白いだろうと思い、試みました。この作業においては可能な限り公平になるよう努めました（[Twitter でフィードバックを求め、多くの良い意見をいただきました](https://x.com/hwchase17/status/1913662736963412365?ref=blog.langchain.com)）。 現在、この比較には Agents SDK、Google の ADK、LangChain、Crew AI、LlamaIndex、Agno AI、Mastra、Pydantic AI、AutoGen、Temporal、SmolAgents、DSPy が含まれています。 もし特定のフレームワークを漏らした場合や、何らかの誤りがある場合は、コメントを残してください！ 💡 スプレッドシートのライブ版は[こちら](https://docs.google.com/spreadsheets/d/1B37VxTBuGLeTSPVWtz7UMsCdtXrqV5hCjWkbHN8tfAo/edit?usp=sharing&ref=blog.langchain.com)で見つけることができます。 ## 結論 - 信頼性の高いエージェントシステムを構築する上で難しい部分は、各ステップで LLM（大規模言語モデル）が適切なコンテキストを持っていることを保証することです。これには、LLM に取り込む内容を正確に制御することと、関連するコンテンツを生成するために適切なステップを実行することが含まれます。 - エージェントシステムは、ワークフローとエージェント（およびその間のあらゆるもの）の両方から構成されます。 - ほとんどのエージェントフレームワークは、宣言型または命令型のオーケストレーションフレームワークではなく、単なるエージェント抽象化のセットです。 - エージェント抽象化は始めやすくする一方で、各ステップで LLM が適切なコンテキストを持っていることを保証するのが難しくなり、かえって複雑さを増すことがあります。 - 形状や規模が異なるあらゆる形態のエージェントシステム（エージェントまたはワークフロー）は、フレームワークによって提供されるか、ゼロから構築されることとなる、同じセットの便利な機能から恩恵を受けます。 - LangGraph は、宣言型と命令型の両方の API を備えたオーケストレーションフレームワークとして捉えるのが最も適切であり、その上に一連のエージェント抽象化が構築されています。

エージェントフレームワークをどう捉えるべきか

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

関連記事

調べる

選ぶ

サイト