エージェントフレームワークとエージェントの可観測性について

LLMが向上するたびに、同じ疑問が戻ってきます：「エージェントフレームワークはまだ必要ですか？」これは当然の質問です。モデルの性能が向上し進化するにつれて、エージェントを構築する最良の方法は変化しますが、根本的に、エージェントはモデルを囲むシステムです。ですから、エージェントは消え去ることはありません――ただ、同様に進化する必要があるだけです。私たちは現在、3世代のエージェントフレームワークを構築してきましたが、それぞれが前の世代とは異なる様相を呈していました。そこで、私たちが確信していることをお伝えします： エージェントフレームワークは、モデルと同じ速さで進化する場合にのみ、依然として有用です。 エージェントの可観測性は、どのように構築したかに関わらず機能すべきです。それが、私たちのオープンソース（LangChainやLangGraph）を使用していなくてもLangSmithが機能する理由です。 この記事は、その両方の確信について述べています。 なぜ2026年においてエージェントフレームワークが依然として関連性を持つのか エージェントのパターンは、チェーニングからワークフローオーケストレーションへ、そしてファイルシステムとメモリを伴うループ内ツール呼び出しへと移行してきました。私たちはそれらすべてのためのフレームワークを構築し、ユースケースに基づいてそれぞれに存在意義があると信じています。以下にその進化の過程を示します： オリジナルのLangChainは2023年に人気を博しました。それは、LLMを実用的に活用する方法を知っている人がほとんどいなかったためです。このフレームワークは、一連の統合と中核的な抽象化を通じて、基盤モデルをデータやAPIに接続する最も簡単な方法の一つを提供しました。当初は確かに独断的すぎたかもしれません――本番環境対応のツールというよりは、プロンプティングやRAGについて学ぶための「簡単ボタン」に近いものでした。その夏までに生成AIの第一波が落ち着き始めると、エージェントフレームワークは無意味だという批判が高まりました。 私たちはその批判を耳にしましたが、実際の使用状況で目にしていたこととは相容れないものでした。LLMアプリを構築するチームの大多数は、完全に独力で進めるよりも迅速に動くための方法を必要としていました。優れたフレームワークは： ベストプラクティスをフレームワーク自体にエンコードする ボイラープレートコードを削減する より高い品質レベルに到達することを容易にする 大規模なチーム全体で標準と可読性を生み出す 本番環境へのよりクリーンな道筋を整備する そこで、私たちは強化に乗り出しました。ただし、別のフレームワークでです。 オーケストレーションとランタイム LangGraphはより低レベルで柔軟性が高いものでした。耐久性と状態保持をサポートするランタイムを含んでおり、これは人間とエージェント、およびエージェント間のコラボレーションにとって重要であることが判明しました。これは、人々がLangChainについて提起していた多くの制御上の懸念に対処しました。私たちは最終的に2025年にオリジナルのLangChainをより合理化されたものに書き換えましたが、異なる問題には異なるツールが必要であることも認識しました。 より最近では、DeepAgentsを構築しました：これは、より高性能で柔軟性の高い、バッテリー内蔵型のエージェントハーネスです。長期的なタスクの計画、ループ内ツール呼び出し、ファイルシステムへのコンテキストのオフロード、サブエージェントのオーケストレーションをサポートします。エージェントハーネスが今機能するのは、LLMの推論能力が向上しており、多くのオーケストレーションパターンをハードコーディングするのではなく、より多くの決定をLLMに委任できるためです。概念的にはClaude Agent SDKに最も似ていますが、モデルに依存しません。私たちの知る限り、これは特定のLLMやアプリケーションスタックに縛られていない唯一のエージェントハーネスです。 今日、私たちは異なるユースケースに対してこれらの異なるフレームワークを推奨しています。LangChainとDeepAgentsは、長時間実行のためのLangGraphのランタイム上に構築されています。 劇的に聞こえるかもしれませんが、私たちは3年間で3世代のエージェントを目にしてきました：RAGとして始まったものがエージェント的ワークフローになり、それがより自律的なループ内ツール呼び出しエージェントへと進化したのです。 フレームワークに対する最大の批判は、AI分野の進化が速すぎて標準が形成されないという点です。そこには真実があります。しかし、私たちはまた、AIの競争から身を引き、物事が落ち着くのを待つことは敗北の戦略であるとも信じています。フレームワークは、飛び込み、より速く構築し、成功の確率を高めるのに役立ちます。そのことを理解していても、ツールは変化し続けるでしょう。また、すべてのものにフレームワークが必要なわけでもありません。単純なLLMリクエストであれば、フレームワークを追加することは過剰かもしれません。 なぜLangSmithはLangChainオープンソースから独立しているのか 初期の段階で、私たちは品質がエージェントを本番環境に投入する上での最大の障壁であると認識しました。私たちは、目的に特化したエージェントの可観測性と評価がツールキットの必須部分であると信じていました（今も信じています）。 私たちはそれをLangSmithと名付けました。なぜなら、エージェントフレームワークは一つだけではないだろうという直感があったからです。また、たとえ支配的なフレームワークがあったとしても、初期バージョンが認識できないほどの速さで進化しなければならないだろうと考えました。私たちは、誰もが私たちのフレームワークを使うわけではないことを認めましたが、それでもこのプラットフォームを使えるようにしたいと考えました。 そこで、私たちはLangSmithを、LangChainを使っているか、私たちの他のフレームワークを使っているか、あるいは全く使っていないかに関わらず動作するように構築しました。これは当時、自明な決定ではありませんでした。私たちは、自社のNext.jsを超えて多くのフロントエンドフレームワークをサポートするVercelのような企業からインスピレーションを得ました。 今日、LangSmithは多数のフレームワークとすぐに統合できます――AutoGen、Claude Agent SDK、CrewAI、Mastra、OpenAI Agents、PydanticAI、Vercel AI SDKなどです。OpenTelemetryベースのトレーシングをサポートしているため、OTEL仕様を出力するものは何でもLangSmithに取り込むことができます。また、フレームワークを全く使用せずに構築されたエージェントとも連携します。Clay、Harvey、Vantaを含む多くのLangSmith顧客は、私たちのオープンソースフレームワークを使用していませんが、可観測性と評価のためにLangSmithに依存しています。 エージェントエンジニアリングにおける構築とテストの収束 エージェントフレームワークに関わらず、トレースはエージェントの動作を理解する上で重要です。私たちは、エージェントトレースがいかに重要であるかについて書いてきました。なぜなら、それはエージェントのデバッグ、監視、評価などの基礎となるからです。エージェントでは、アプリケーションのロジックはコードではなくトレースに記録されます。エージェントを構築することはほんの第一歩に過ぎません。エージェントは非決定性のシステムであるため、実際にリリースするまで、どのような入力や出力が予想されるかわかりません。そのため、デバッグ、テスト、監視は、エージェントエンジニアリングと構築プロセス自体の重要な部分なのです。 ですから、もし私たちのOSSフレームワークを使用していないのであれば、その理由を聞かせてください！しかし、それによってLangSmithを使ってエージェントがどのように、なぜ失敗しているのかを解明するのを止めないでください。 ニュースレターにご登録ください LangChainチームとコミュニティからの最新情報 お申し込みを処理しています... 成功しました！受信トレイを確認し、リンクをクリックして購読を確認してください。 申し訳ありません。エラーが発生しました。もう一度お試しください。 ![](https://blog.langchain.com/content/images/2026/02/data-src-image-d6a87a95-4aa7-4edd-bf29-fbed61103e87.png)

エージェントフレームワークとエージェントの可観測性について

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

関連記事

調べる

選ぶ

サイト