【翻訳】エージェントフレームワークの考え方

この記事は、以下の内容をマークダウン化&LLMによる翻訳を行ったものです。

https://blog.langchain.dev/how-to-think-about-agent-frameworks/

翻訳内容の正確性は十分検証できていません。ご注意苦ださい。

エージェントフレームワークの考え方

TL;DR:

• 信頼性の高いエージェントシステムを構築する上で難しいのは、各ステップでLLMに適切なコンテキストを確保すること。これには、LLMに入力される正確な内容の制御と、関連コンテンツを生成するための適切なステップの実行の両方が含まれる。
• エージェントシステムは、ワークフローとエージェント（およびその中間）の両方で構成される。
• ほとんどのエージェントフレームワークは、宣言的でも命令的でもなく、単なるエージェント抽象化の集合体である。
• エージェント抽象化は簡単に始められるが、LLMに適切なコンテキストを各ステップで確保することを難しくする場合が多い。
• あらゆる形態のエージェントシステム（エージェントもワークフローも）は、フレームワークが提供する、または一から構築できる同じ有用な機能の恩恵を受ける。
• LangGraphは、エージェント抽象化が上に構築された、オーケストレーションフレームワーク（宣言的APIと命令的APIの両方を持つ）として考えるのが最適。

OpenAIは最近、以下のような誤解を招く見解を含むエージェント構築ガイドをリリースしました：

この指摘に最初は怒りを感じましたが、返答を書き始めて気づきました：エージェントフレームワークについて考えるのは複雑なのです！おそらく100種類以上のエージェントフレームワークがあり、比較すべき軸がたくさんあり、時にはこの引用のように混同されることもあります。多くの誇大宣伝、ポーズ、ノイズがあります。エージェントフレームワークについての正確な分析や思考はほとんど行われていません。このブログはそれを行う試みです。以下の内容を取り上げます：

• 背景情報
  • エージェントとは何か？
  • エージェント構築の難しさは何か？
  • LangGraphとは何か？
• エージェントフレームワークの種類
  • 「エージェント」vs「ワークフロー」
  • 宣言的 vs 非宣言的
  • エージェント抽象化
  • マルチエージェント
• よくある質問
  • フレームワークの価値は何か？
  • モデルが改善されるにつれて、すべてがワークフローではなくエージェントになるのか？
  • OpenAIの見解の何が間違っているのか？
  • すべてのエージェントフレームワークはどのように比較されるのか？

このブログでは、以下の資料を繰り返し参照します：

• OpenAIのエージェント構築ガイド（特に良いとは思いません）
• Anthropicの効果的なエージェント構築ガイド（これはとても気に入っています）
• LangGraph（信頼性の高いエージェントを構築するための私たちのフレームワーク）

背景情報

ブログの残りの部分の舞台を設定するための有用なコンテキストです。

エージェントとは

エージェントの一貫した定義はなく、しばしば異なる視点から提供されます。

OpenAIはエージェントを定義するにあたり、より高レベルで思想的なアプローチを取っています。

エージェントはあなたに代わって独立してタスクを達成するシステムです。

個人的にこれは好きではありません。これはエージェントが何であるかを理解するのに役立たない曖昧な声明です。単なる思想的リーダーシップであり、実用的ではありません。

これをAnthropicの定義と比較してみましょう：

「エージェント」はいくつかの方法で定義できます。一部の顧客は、エージェントを複雑なタスクを達成するために様々なツールを使用して長期間独立して動作する完全に自律的なシステムと定義しています。他の人々は、事前定義されたワークフローに従うより規範的な実装を指すためにこの用語を使用しています。Anthropicでは、これらすべてのバリエーションをエージェントシステムとして分類していますが、ワークフローとエージェントの間に重要なアーキテクチャ上の区別を設けています：

ワークフローは、LLMとツールが事前定義されたコードパスを通じてオーケストレーションされるシステムです。

一方、エージェントは、LLMが自身のプロセスとツールの使用を動的に指示し、タスクの達成方法を制御するシステムです。

私がAnthropicの定義を好む理由はいくつかあります：

• エージェントの定義がはるかに正確で技術的です。
• 彼らは「エージェントシステム」という概念にも言及し、ワークフローとエージェントの両方をその変種として分類しています。これが大好きです。

💡

実運用で見られる「エージェントシステム」のほぼすべては、「ワークフロー」と「エージェント」の組み合わせです。

ブログ記事の後半で、Anthropicはエージェントを「...通常、環境からのフィードバックに基づいてループでツールを使用するLLMに過ぎない」と定義しています。

冒頭での壮大なエージェント定義にもかかわらず、これは基本的にOpenAIが意味することでもあります。

これらのタイプのエージェントは以下によってパラメータ化されます：

• 使用するモデル
• 使用する指示（システムプロンプト）
• 使用するツール

ループでモデルを呼び出します。モデルがツールを呼び出すと決定した場合、そのツールを実行し、観察/フィードバックを取得し、それをLLMに戻します。LLMがツールを呼び出さないと決定するまで（または停止基準をトリガーするツールを呼び出すまで）実行します。

OpenAIとAnthropicの両方が、ワークフローはエージェントとは異なる設計パターンであると指摘しています。LLMの制御が少なく、フローがより決定論的です。これは有用な区別です！

OpenAIとAnthropicの両方が、常にエージェントが必要なわけではないと明示的に指摘しています。多くの場合、ワークフローの方がシンプルで信頼性が高く、安価で、速く、パフォーマンスが良いです。Anthropicの記事からの素晴らしい引用：

LLMでアプリケーションを構築する際、可能な限り最もシンプルなソリューションを見つけ、必要な場合にのみ複雑さを増すことをお勧めします。これはエージェントシステムを全く構築しないことを意味するかもしれません。エージェントシステムは多くの場合、レイテンシーとコストをタスクパフォーマンスの向上と引き換えにしており、このトレードオフがいつ意味を持つかを検討する必要があります。

より複雑さが必要な場合、ワークフローは明確に定義されたタスクに予測可能性と一貫性を提供し、一方エージェントは柔軟性とモデル駆動の意思決定が大規模に必要な場合に適しています。

OpenAIも同様のことを述べています：

エージェントの構築に取り組む前に、ユースケースがこれらの基準を明確に満たすことができるかを検証してください。そうでなければ、決定論的なソリューションで十分かもしれません。

実際には、ほとんどの「エージェントシステム」はワークフローとエージェントの組み合わせです。これが、何かがエージェントであるかどうかについて話すことを嫌う理由であり、システムがどれだけエージェント的かについて話すことを好む理由です。Andrew Ngの考え方に感謝します：

二項対立的に何かがエージェントであるかどうかを選択するのではなく、システムが異なる程度でエージェント的であると考える方が有用だと思いました。名詞「エージェント」とは異なり、形容詞「エージェント的」を使うことで、そのようなシステムを考察し、この成長する動きにすべてを含めることができます。

エージェント構築の難しさは何か？

ほとんどの人はエージェントの構築が難しいことに同意すると思います。あるいは、プロトタイプとしてのエージェント構築は簡単ですが、ビジネスクリティカルなアプリケーションを支える信頼性の高いものを構築するのは難しいのです。

厄介な部分はまさにそれ - 信頼性を確保することです。Twitterで見栄えの良いデモを作るのは簡単です。しかし、ビジネスクリティカルなアプリケーションを動かすために実行できますか？多くの作業なしではできません。

数ヶ月前にエージェント開発者を対象に調査を行い、「より多くのエージェントを本番環境に導入する上での最大の制限は何ですか？」と尋ねました。圧倒的に多かった回答は「パフォーマンスの質」でした - これらのエージェントを機能させるのはまだ本当に難しいのです。

エージェントが時々うまく機能しない原因は何ですか？ LLMが失敗します。

なぜLLMは失敗するのですか？ 2つの理由：(a)モデルが十分に良くない、(b)間違った（または不完全な）コンテキストがモデルに渡されている。

私たちの経験から、非常に頻繁に2番目のケースが原因です。何が原因ですか？

• 不完全または短いシステムメッセージ
• あいまいなユーザー入力
• 適切なツールへのアクセスがない
• 貧弱なツールの説明
• 適切なコンテキストが渡されていない
• 形式の悪いツールレスポンス

💡

信頼性の高いエージェントシステムを構築する上で難しいのは、各ステップでLLMに適切なコンテキストを確保すること。これには、LLMに入力される正確な内容の制御と、関連コンテンツを生成するための適切なステップの実行の両方が含まれる。

エージェントフレームワークについて議論する際、これを念頭に置くと役立ちます。LLMに渡される内容を正確に制御することを難しくするフレームワークは、単にあなたの邪魔をしているだけです。LLMに正しいコンテキストを渡すのは既に十分難しいのに、なぜそれをさらに難しくするのでしょうか？

LangGraphとは

💡

LangGraphは、エージェント抽象化が上に構築された、オーケストレーションフレームワーク（宣言的APIと命令的APIの両方を持つ）として考えるのが最適です。

LangGraphはエージェントシステムを構築するためのイベント駆動型フレームワークです。最も一般的な使用方法は以下の2つです：

• 宣言的なグラフベースの構文
• エージェント抽象化（低レベルフレームワークの上に構築）

LangGraphは関数型APIや基礎となるイベント駆動型APIもサポートしています。PythonとTypeScriptの両方のバリアントが存在します。

エージェントシステムはノードとエッジとして表現できます。ノードは作業単位を表し、エッジは遷移を表します。ノードとエッジは通常のPythonまたはTypeScriptコード以外の何物でもありません - グラフの構造は宣言的な方法で表現されますが、グラフのロジックの内部機能は通常の命令型コードです。エッジは固定または条件付きのいずれかです。つまり、グラフの構造は宣言的ですが、グラフを通るパスは完全に動的になり得ます。

LangGraphには組み込みの永続化レイヤーが付属しています。これによりフォールトトレランス、短期メモリ、長期メモリが可能になります。

この永続化レイヤーは、割り込み、承認、再開、タイムトラベルなどの「ヒューマンインザループ」および「ヒューマンオンザループ」パターンも可能にします。

LangGraphにはストリーミングの組み込みサポートがあります：トークン、ノード更新、任意のイベントのストリーミングが可能です。

LangGraphは、デバッグ、評価、観測性のためにLangSmithとシームレスに統合されています。

エージェントフレームワークの種類

エージェントフレームワークはいくつかの次元で異なります。これらの次元を理解し、混同しないことが、エージェントフレームワークを適切に比較するための鍵です。

ワークフロー vs エージェント

ほとんどのフレームワークには高レベルのエージェント抽象化が含まれています。一部のフレームワークには一般的なワークフローの抽象化も含まれています。LangGraphはエージェントシステムを構築するための低レベルのオーケストレーションフレームワークです。LangGraphはワークフロー、エージェント、およびその中間のものをサポートしています。これは重要だと考えています。前述のように、本番環境のほとんどのエージェントシステムはワークフローとエージェントの組み合わせです。本番環境対応のフレームワークは両方をサポートする必要があります。

信頼性の高いエージェントを構築する上で難しいのは、LLMに適切なコンテキストを確保することを思い出しましょう。ワークフローが有用な理由の一部は、LLMに適切なコンテキストを渡すことを容易にするからです。データがどのように流れるかを正確に決定できます。

「ワークフロー」から「エージェント」のスペクトルのどこにアプリケーションを構築したいかを考える際、考慮すべき2つのことがあります：

• 予測可能性 vs エージェンシー
• 低い敷居、高い天井

予測可能性 vs エージェンシー

システムがよりエージェント的になるにつれて、予測可能性は低くなります。

時には、ユーザーの信頼、規制上の理由、またはその他の理由で、システムが予測可能であることが望ましいか必要な場合があります。

信頼性は予測可能性と100％一致するわけではありませんが、実際には密接に関連していることがあります。

このカーブのどこにいたいかは、アプリケーションによって非常に特定的です。LangGraphはこのカーブのどこでもアプリケーションを構築するために使用でき、望む点に移動することができます。

高い敷居、低い天井

フレームワークを考える際、その敷居と天井について考えると役立ちます：

• 低い敷居：低い敷居のフレームワークは初心者に優しく、簡単に始められます
• 高い敷居：高い敷居のフレームワークは、効果的に使い始めるために大きな学習曲線と重要な知識や専門知識を必要とします。
• 低い天井：低い天井のフレームワークは、それで達成できることに制限があります（すぐに成長の限界に達します）。
• 高い天井：高い天井のフレームワークは、高度なユースケースのための広範な機能と柔軟性を提供します（あなたと共に成長します）。

ワークフローフレームワークは高い天井を提供しますが、高い敷居も伴います - エージェントロジックの多くを自分で書く必要があります。

エージェントフレームワークは敷居が低いですが、天井も低いです - 簡単に始められますが、些細でないユースケースには十分ではありません。

LangGraphは、敷居が低い側面（簡単に始められる組み込みのエージェント抽象化）と天井が高い側面（高度なユースケースを達成するための低レベル機能）の両方を持つことを目指しています。

宣言的 vs 非宣言的

宣言的フレームワークには利点があります。欠点もあります。これはプログラマーの間で終わりのない議論であり、誰もが自分の好みを持っています。

人々が非宣言的と言うとき、通常は代替として命令型を暗示しています。

ほとんどの人はLangGraphを宣言的フレームワークとして説明するでしょう。これは部分的にしか真実ではありません。

まず - ノードとエッジの間の接続は宣言的な方法で行われますが、実際のノードとエッジはPythonやTypeScriptの関数以外の何物でもありません。したがって、LangGraphは宣言的と命令的の混合のようなものです。

第二に - 実際には推奨される宣言的API以外のAPIもサポートしています。具体的には、関数型とイベント駆動型APIの両方をサポートしています。宣言的APIが有用な精神モデルだと考えていますが、それがすべての人に適しているわけではないことも認識しています。

LangGraphについてよくある意見は、それがTensorflow（宣言的なディープラーニングフレームワーク）のようであり、Agents SDKなどのフレームワークはPytorch（命令的なディープラーニングフレームワーク）のようだということです。

これは単に間違っています。Agents SDK（および元のLangChain、CrewAIなど）のようなフレームワークは宣言的でも命令的でもなく、単なる抽象化です。エージェント抽象化（Pythonクラス）を持ち、エージェントを実行する多くの内部ロジックが含まれています。これらは実際にはオーケストレーションフレームワークではありません。単なる抽象化です。

エージェント抽象化

ほとんどのエージェントフレームワークにはエージェント抽象化が含まれています。通常はプロンプト、モデル、ツールを含むクラスとして始まります。そして、さらにいくつかのパラメータを追加し...さらにいくつか...さらにもっと追加します。最終的には、クラスの背後に抽象化された多数の動作を制御する多数のパラメータが生まれます。何が起こっているのかを見たり、ロジックを変更したりしたい場合は、クラスに入ってソースコードを修正する必要があります。

💡

これらの抽象化により、すべてのステップでLLMに何が入力されるかを正確に理解または制御することが非常に難しくなります。これは重要です - この制御を持つことは信頼性の高いエージェントを構築するために不可欠です（上記で説明したように）。これがエージェント抽象化の危険性です。

私たちはこれを苦い経験から学びました。これが元のLangChainのチェーンとエージェントの問題でした。それらは邪魔になる抽象化を提供していました。2年前のそれらの元の抽象化の1つは、モデル、プロンプト、ツールを取り込むエージェントクラスでした。これは新しい概念ではありません。当時は十分な制御を提供せず、今でもそうではありません。

明確にしておくと、これらのエージェント抽象化にはいくつかの価値があります。簡単に始めることができます。しかし、これらのエージェント抽象化は信頼性の高いエージェントを構築するのに十分だとは思いません（そしておそらく今後もそうではないでしょう）。

これらのエージェント抽象化について考える最良の方法は、Kerasのようなものだと思います。簡単に始めるための高レベルの抽象化を提供します。しかし、それらが低レベルのフレームワークの上に構築されていることを確認することが重要です。そうすれば成長の限界に達することはありません。

そのため、LangGraphの上にエージェント抽象化を構築しました。これによりエージェントを簡単に始める方法が提供されますが、低レベルのLangGraphに移行する必要がある場合も簡単にできます。

マルチエージェント

多くの場合、エージェントシステムは1つのエージェントだけでなく、複数のエージェントを含みます。OpenAIはレポートで次のように述べています：

多くの複雑なワークフローでは、プロンプトとツールを複数のエージェントに分割することで、パフォーマンスとスケーラビリティが向上します。エージェントが複雑な指示に従えなかったり、一貫して間違ったツールを選択したりする場合は、システムをさらに分割し、より明確なエージェントを導入する必要があるかもしれません。

💡

マルチエージェントシステムの重要な部分は、それらがどのようにコミュニケーションするかです。繰り返しますが、エージェント構築の難しい部分はLLMに適切なコンテキストを提供することです。これらのエージェント間のコミュニケーションは重要です。

これを行う方法はたくさんあります！ハンドオフはその一つです。これはAgents SDKからのエージェント抽象化で、実際に気に入っています。

しかし、これらのエージェントが通信する最良の方法は、時にはワークフローかもしれません。Anthropicのブログ記事のすべてのワークフロー図を取り、LLM呼び出しをエージェントに置き換えてみてください。このワークフローとエージェントの組み合わせが、しばしば最高の信頼性を提供します。

繰り返しますが - エージェントシステムは単なるワークフローでも、単なるエージェントでもありません。それらは - そして多くの場合 - 両方の組み合わせです。Anthropicがブログ記事で指摘しているように：

これらのパターンの組み合わせとカスタマイズ

これらの構成要素は規範的ではありません。それらは開発者が異なるユースケースに合わせて形作り、組み合わせることができる一般的なパターンです。

よくある質問

フレームワークを評価すべき異なる軸を定義し探索したところで、いくつかの一般的な質問に答えてみましょう。

フレームワークの価値は何か？

エージェントシステムを構築するためにフレームワークが必要かどうか疑問に思う人をよく見かけます。エージェントフレームワークはどのような価値を提供できるのでしょうか？

エージェント抽象化

フレームワークは一般的に、始めやすくするための有用な抽象化を含み、エンジニアが構築するための共通の方法を提供するため、プロジェクトのオンボーディングと保守を容易にするという点で有用です。上述のように、エージェント抽象化には実際の欠点もあります。ほとんどのエージェントフレームワークでは、これが提供する唯一の価値です。LangGraphではこれが当てはまらないように懸命に取り組みました。

短期メモリ

今日のほとんどのエージェントアプリケーションには、マルチターン（例：チャット）コンポーネントが含まれています。LangGraphはマルチターン体験（スレッド）を可能にする本番環境対応のストレージを提供します。

長期メモリ

まだ初期段階ですが、エージェントシステムが経験から学ぶこと（例：会話間で物事を覚えること）に非常に期待しています。LangGraphはスレッド間メモリのための本番環境対応のストレージを提供します。

ヒューマンインザループ

多くのエージェントシステムは、ヒューマンインザループコンポーネントによって改善されます。例としては、ユーザーからのフィードバックの取得、ツール呼び出しの承認、ツール呼び出し引数の編集などがあります。LangGraphは本番システムでこれらのワークフローを可能にするための組み込みサポートを提供します。

ヒューマンオンザループ

ユーザーが実行中のエージェントに影響を与えることを許可するだけでなく、後からエージェントの軌跡を検査し、さらに以前のステップに戻って（変更を加えて）そこから再実行することも有用です。これをヒューマンオンザループと呼び、LangGraphはこれのための組み込みサポートを提供します。

ストリーミング

ほとんどのエージェントアプリケーションは実行に時間がかかるため、エンドユーザーに更新を提供することは良いユーザー体験を提供するために重要です。LangGraphはトークン、グラフステップ、任意のストリームの組み込みストリーミングを提供します。

デバッグ/観測性

信頼性の高いエージェントを構築する上で難しいのは、LLMに適切なコンテキストを確実に渡すことです。エージェントが取った正確なステップと、各ステップでの正確な入出力を検査できることは、信頼性の高いエージェントを構築するために不可欠です。LangGraphは最高クラスのデバッグと観測性のためにLangSmithとシームレスに統合されています。注：AI観測性は従来のソフトウェア観測性とは異なります（これは別の投稿に値します）。

フォールトトレランス

フォールトトレランスは、分散アプリケーションを構築するための従来のフレームワーク（Temporalなど）の重要なコンポーネントです。LangGraphは耐久性のあるワークフローと設定可能なリトライでフォールトトレランスを容易にします。

最適化

プロンプトを手動で微調整するのではなく、評価データセットを定義してからこれに基づいてエージェントを自動的に最適化する方が簡単な場合があります。LangGraphは現在これをすぐに使えるようにはサポートしていません - これにはまだ少し早いと考えています。しかし、これは考慮すべき興味深い次元であり、常に注目しているものなので、含めたいと思いました。現在、これに最適なフレームワークはdspyです。

💡

これらの価値提案（エージェント抽象化を除く）はすべて、エージェント、ワークフロー、およびその中間のすべてに価値を提供します。

では、本当にエージェントフレームワークが必要ですか？

アプリケーションがこれらの機能をすべて必要としない場合、および/またはそれらを自分で構築したい場合は、必要ないかもしれません。一部（短期メモリなど）はそれほど複雑ではありません。他のもの（ヒューマンオンザループやLLM特有の観測性など）はより複雑です。

そしてエージェント抽象化に関しては：Anthropicの投稿で述べられていることに同意します：

フレームワークを使用する場合は、基礎となるコードを理解していることを確認してください。何が内部で行われているかについての誤った仮定は、顧客エラーの一般的な原因です。

モデルが改善されるにつれて、すべてがワークフローではなくエージェントになるのか？

エージェント（ワークフローと比較して）を支持する一般的な議論は、現在は機能しなくても将来的には機能するようになり、したがって単純なツール呼び出しエージェントだけが必要になるというものです。

私は複数のことが真実だと思います：

• これらのツール呼び出しエージェントのパフォーマンスは向上するでしょう
• LLMに何が入力されるかを制御することは依然として非常に重要です（ゴミを入れればゴミが出る）
• 一部のアプリケーションでは、このツール呼び出しループで十分でしょう
• 他のアプリケーションでは、ワークフローの方がシンプルで、安価で、速く、より良いでしょう
• ほとんどのアプリケーションでは、本番環境のエージェントシステムはワークフローとエージェントの組み合わせになるでしょう

OpenAIやAnthropicもこれらの点に異論はないでしょうか？Anthropicの投稿から：

LLMでアプリケーションを構築する際、可能な限り最もシンプルなソリューションを見つけ、必要な場合にのみ複雑さを増すことをお勧めします。これはエージェントシステムを全く構築しないことを意味するかもしれません。エージェントシステムは多くの場合、レイテンシーとコストをタスクパフォーマンスの向上と引き換えにしており、このトレードオフがいつ意味を持つかを検討する必要があります。

そしてOpenAIの投稿から：

エージェントの構築に取り組む前に、ユースケースがこれらの基準を明確に満たすことができるかを検証してください。そうでなければ、決定論的なソリューションで十分かもしれません。

このシンプルなツール呼び出しループで十分なアプリケーションはあるでしょうか？これはおそらく、ユースケースに特化した多くのデータでトレーニング/微調整/強化学習されたモデルを使用している場合にのみ当てはまるでしょう。これは2つの方法で起こり得ます：

• あなたのタスクはユニークです。多くのデータを収集し、独自のモデルをトレーニング/微調整/強化学習します。
• あなたのタスクはユニークではありません。大手モデルラボがあなたのタスクを代表するデータでトレーニング/微調整/強化学習を行っています。

（余談：タスクがユニークでない領域で垂直型スタートアップを構築している場合、そのスタートアップの長期的な実行可能性についてかなり心配するでしょう）。

あなたのタスクがユニークな場合

ほとんどのユースケース（特に企業のユースケース）はこのカテゴリに該当すると思います。AirBnbがカスタマーサポートを処理する方法はKlarnaの方法とは異なり、それはRakutenの方法とも異なります。これらのタスクには多くの微妙な点があります。カスタマーサポート分野の主要なエージェント企業であるSierraは、単一のカスタマーサポートエージェントではなく、カスタマーサポートエージェントプラットフォームを構築しています：

Sierra Agent SDKは、開発者が宣言型プログラミング言語を使用して、手続き的知識を表現するための構成可能なスキルを使用して、強力で柔軟なエージェントを構築できるようにします

これが必要なのは、各企業のカスタマーサポート体験が十分にユニークであり、汎用エージェントでは十分なパフォーマンスが得られないからです。

特定のタスク用にトレーニングされたモデルを使用する単純なツール呼び出しループであるエージェントの例：OpenAIのDeep Research。これは可能であり、素晴らしいエージェントを生み出すことができます。

特定のタスクに最先端のモデルをトレーニングできる場合、おそらく任意のワークフローを可能にするフレームワークは必要なく、単純なツール呼び出しループを使用するでしょう。この場合、エージェントはワークフローよりも好まれるでしょう。

私の心の中で非常に開かれた質問は：どれだけ多くのエージェント企業がタスクに特化した最先端モデルをトレーニングするためのデータ、ツール、または知識を持つでしょうか？現時点では、大手モデルラボだけがこれを行うことができると思います。しかしそれは変わるでしょうか？小さな垂直型スタートアップがタスクに特化した最先端モデルをトレーニングできるようになるでしょうか？この質問に非常に興味があります。現在これを行っている場合は、ぜひ連絡してください！

あなたのタスクがユニークでない場合

一部のタスクは十分に一般的であり、大手モデルラボはこれらの非一般的なタスクに対して単純なツール呼び出しループを行うのに十分に良いモデルを提供できるでしょう。

OpenAIはAPI経由でComputer Useモデルをリリースしました。これは一般的なコンピュータ使用データで微調整されたモデルで、その一般的なタスクに十分に良くなることを目指しています。（余談：まだ十分に良いとは思いません）。

コードは興味深い例です。コーディングは比較的一般的であり、コーディングはこれまでエージェントの突出したユースケースでした。Claude codeとOpenAIのCodex CLIは、この単純なツール呼び出しループを使用するコーディングエージェントの2つの例です。基本モデルが多くのコーディングデータとタスクでトレーニングされていると強く賭けるでしょう（Anthropicがこれを行っている証拠を参照）。

興味深いことに - 一般モデルがこのデータでトレーニングされるにつれて、このデータの正確な形状はどれほど重要でしょうか？Ben Hylakは最近、多くの人に共感された興味深いツイートを投稿しました：

モデルはもうカーソルの使い方を知らない。

すべてがターミナル用に最適化されている。だから3.7とo3はCursorでは非常に酷く、外では素晴らしいのだ。

これは2つのことを示唆しています：

• あなたのタスクは一般モデルがトレーニングされたタスクに非常に近い必要があります。タスクの類似性が低いほど、一般モデルがあなたのユースケースに十分に良い可能性は低くなります。
• 一般モデルを他の特定のタスクでトレーニングすると、あなたのタスクのパフォーマンスが低下する可能性があります。Cursorのユースケースに似たデータが新しいモデルのトレーニングに使用されているのと同じくらい（またはそれ以上）あると確信しています。しかし、少し異なる形状の新しいデータが大量に流入すると、他のタイプのデータよりも重要になります。これは現在、一般モデルが多数のタスクで本当に素晴らしいパフォーマンスを発揮することが難しいことを示唆しています。

💡

ワークフローのようなものよりもエージェントが好まれるアプリケーションでも、低レベルのワークフロー制御に関係のないフレームワークの機能の恩恵を受けるでしょう：短期メモリストレージ、長期メモリストレージ、ヒューマンインザループ、ヒューマンオンザループ、ストリーミング、フォールトトレランス、デバッグ/観測性。

OpenAIの見解の何が間違っているのか？

OpenAIの立場を再検討すると、それは「エージェントフレームワーク」の異なる次元を混同して、彼らの単一の抽象化の価値を誇張するための誤った二分法に基づいていることがわかります。具体的には、「宣言的 vs 命令的」と「エージェント抽象化」、そして「ワークフロー vs エージェント」を混同しています。

💡

最終的に、本番エージェントシステムを構築する上での主な課題と、フレームワークが提供すべき主な価値を見誤っています。それは：開発者がLLMに到達するコンテキストを明示的に制御しながら、永続性、フォールトトレランス、ヒューマンインザループのような本番環境の懸念をシームレスに処理する信頼性の高いオーケストレーションレイヤーです。

問題があると思う特定の部分を分解しましょう：

「宣言的 vs 非宣言的グラフ」

LangGraphは完全に宣言的ではありませんが、十分に宣言的なのでそれが主な不満ではありません。主な不満は「非宣言的」が多くの作業をしており、誤解を招いていることです。通常、人々が宣言的フレームワークを批判する場合、より命令的なフレームワークを好むでしょう。しかしAgents SDKは命令的フレームワークではありません。それは抽象化です。より適切なタイトルは「宣言的 vs 命令的」または「オーケストレーションフレームワークが必要ですか」または「エージェント抽象化だけで十分」または「ワークフロー vs エージェント」でしょう（彼らが何を主張したいかによります、下記では両方を主張しているようです）。

「このアプローチは、ワークフローがより動的で複雑になるにつれて、すぐに煩雑で困難になる可能性があります」

これは宣言的か非宣言的かとは何の関係もありません。これはすべてワークフロー vs エージェントに関するものです。Agents SDKのエージェントロジックを宣言的グラフとして簡単に表現でき、そのグラフはAgents SDKと同じくらい動的で柔軟です。

そしてワークフロー vs エージェントの点について。多くのワークフローはこのレベルの動的性と複雑さを必要としません。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では大量の通常のコードを書きます。それよりも馴染みのあるものは何でしょうか？

「より動的で適応性のあるエージェントオーケストレーションを可能にする」

繰り返しますが - これは宣言的か非宣言的かとは関係ありません。これはワークフロー vs エージェントに関するものです。上記の点を参照してください。

エージェントフレームワークの比較

エージェントフレームワークの多くの異なるコンポーネントについて話してきました：

• 柔軟なオーケストレーションレイヤーなのか、単なるエージェント抽象化なのか？
• 柔軟なオーケストレーションレイヤーである場合、宣言的かそれ以外か？
• このフレームワークは（エージェント抽象化以外に）どのような機能を提供するか？

これらの次元をスプレッドシートにリストアップしてみるのも面白いと思いました。できるだけ公平にしようとしました（Twitterから多くの良いフィードバックを求め、得ました！）。

これには現在、Agents SDK、GoogleのADK、LangChain、Crew AI、LlamaIndex、Agno AI、Mastra、Pydantic AI、AutoGen、Temporal、SmolAgents、DSPyとの比較が含まれています。

フレームワークを省略した（またはフレームワークについて何か間違えた）場合は、コメントを残してください！

💡

スプレッドシートの最新版はこちらで見ることができます。

結論

• 信頼性の高いエージェントシステムを構築する上で難しいのは、各ステップでLLMに適切なコンテキストを確保すること。これには、LLMに入力される正確な内容の制御と、関連コンテンツを生成するための適切なステップの実行の両方が含まれる。
• エージェントシステムは、ワークフローとエージェント（およびその中間）の両方で構成される。
• ほとんどのエージェントフレームワークは、宣言的でも命令的でもなく、単なるエージェント抽象化の集合体である。
• エージェント抽象化は簡単に始められるが、LLMに適切なコンテキストを各ステップで確保することを難しくする場合が多い。
• あらゆる形態のエージェントシステム（エージェントもワークフローも）は、フレームワークが提供する、または一から構築できる同じ有用な機能の恩恵を受ける。
• LangGraphは、エージェント抽象化が上に構築された、オーケストレーションフレームワーク（宣言的APIと命令的APIの両方を持つ）として考えるのが最適。