エージェントフレームワークと観測可能性について
LangChain Blog は、LLM の進化に伴いエージェントフレームワークが不要になるという批判に対し、その必要性と進化の方向性を論じ、3 つの世代(Chaining, Orchestration, Harness)の役割と LangSmith の観測可能性の重要性を明確にしている。
キーポイント
エージェントフレームワークの進化と継続的必要性
モデル性能が向上しても、エージェントはモデルを取り巻くシステムとして不可欠であり、単なる「易しいボタン」から生産性の高い標準化ツールへと進化し続けている。
3 つの世代におけるフレームワークの役割分担
Chaining(学習・RAG)、Orchestration/Run-time(状態管理・協調)、Harness(包括的実装)という 3 つの段階があり、ユースケースに応じて適切なツールを選択する必要がある。
フレームワークに依存しない観測可能性(Observability)
LangSmith は特定のオープンソースライブラリ(LangChain/LangGraph)に縛られず、あらゆる構築方法に対応したエージェントの可視化と監視を提供するべきだと主張している。
影響分析・編集コメントを表示
影響分析
この記事は、業界内で広がりつつある「LLM の進化によりフレームワーク不要論」に対して、実務的な観点から反論し、アーキテクチャの成熟度に応じたツール選定の重要性を再確認させる内容です。特に、特定のベンダー製品に依存しない観測可能性(Observability)の必要性を強調することで、AI エージェント開発における標準化と運用効率化の方向性を示唆しています。
編集コメント
モデルの進化に伴うフレームワークの役割変化を整理した重要な視点であり、開発者が自身のプロジェクト段階に最適なツールを選定する際の指針となる。特に「観測可能性は技術スタックに依存すべきではない」という提言は、長期的な運用コスト削減の観点から極めて示唆に富んでいる。
LLM が向上するたびに、同じ問いが繰り返されます。「それでもエージェントフレームワークは必要ですか?」これは正当な質問です。モデルの性能が向上し進化していくにつれて、エージェントを構築する最良の方法も変化しますが、根本的にエージェントとはモデルを取り巻くシステムであるため、消滅することはありません—むしろそれ自体も進化する必要があります。
私たちはすでに3世代のエージェントフレームワークを構築してきましたが、それぞれは前世代とは異なる姿をしていました。そこで私たちが信じていることは以下の通りです:
- エージェントフレームワークはまだ有用ですが、モデルの進化スピードに合わせて自らも進化する場合に限ります。
- エージェントの観測機能(observability)は、どのような方法で構築しても機能すべきです。だからこそ、LangSmith はオープンソースである LangChain や LangGraph を使用しない場合でも動作します。
この投稿では、これらの2つの信念について解説します。
2026 年におけるエージェントフレームワークの依然としての重要性
エージェントのパターンは、チェーン化からワークフローオーケストレーションへ、さらにループ内でのツール呼び出しとファイルシステム・メモリを組み合わせる形態へと進化してきました。私たちはこれらすべてに対応するフレームワークを構築し、ユースケースに応じてそれぞれが適した場所を持っていると考えています。その進化の過程は以下の通りです:
Chaining
2023 年に langchain が人気を博した理由は、LLM を実用的に活用する方法を知る人が少なかったからです。このフレームワークは、一連の統合とコアな抽象化を通じて、基盤モデルをデータや API に接続する最も簡単な方法の一つを提供しました。当初は意見が強すぎたと言えるかもしれません — 本番環境で使えるツールというよりは、プロンプトや RAG について学ぶための「簡単ボタン」に近いものでした。その夏には第一波の生成 AI が落ち着き始め、エージェントフレームワークは無意味だという批判がより大きくなりました。
私たちはその批判を耳にしましたが、実際の利用状況で見ているものと整合させるのは困難でした。LLM アプリを開発しているチームの绝大多数は、完全に自力で取り組むよりも速く進める手段を必要としていました。優れたフレームワークには以下のような利点があります:
- ベストプラクティスをフレームワーク自体に組み込む
- 定型コード(ボイラープレート)を削減する
- より高い品質レベルへの到達を容易にする
- 大規模チーム間での標準化と可読性を確保する
- 本番環境への移行経路をよりクリーンにする
そこで私たちは、別のフレームワークに注力することを決意しました。
Orchestration and run-time
langgraph はより低レベルで、より柔軟な設計でした。耐久性と状態管理をサポートするランタイムを含んでおり、これは人間とエージェント、あるいはエージェント同士の協業において重要な役割を果たすことが判明しました。langchain に対して人々が指摘した多くの制御に関する懸念にも対応しています。2025 年に元の langchain をより簡素化するために書き換えを行ったこともありますが、異なる課題には異なるツールが必要であることも認識していました。
Harness
より最近、私たちは deepagents を構築しました。これは、パフォーマンスが高く柔軟性の高い、バッテリー内蔵型のエージェントハーンです。長期タスクの計画、ループ内のツール呼び出し、ファイルシステムへのコンテキストオフロード、サブエージェントのオーケストレーションをサポートしています。現在、エージェントハーンが機能しているのは、LLM が推論においてより良くなり、多くのオーケストレーションパターンをハードコーディングする代わりに、より多くの意思決定を LLM に委譲できるようになったからです。概念としては Claude Agent SDK と最も似ていますが、モデルに依存しないものです。私たちの知る限り、特定の LLM やアプリケーションスタックに縛られない唯一のエージェントハーンです。
今日、私たちは異なるユースケースに対してこれらの異なるフレームワークを推奨しています。langchain と deepagents は、長時間実行される実行のために langgraph のランタイムの上に構築されています。

劇的に聞こえるかもしれませんが、私たちは 3 年間で 3 つ世代のエージェントを見てきました:RAG から始まり、エージェントワークフローへと進化し、さらに自律的なループ内ツール呼び出し型エージェントへと発展しました。
フレームワークに対する最大の批判は、AI の分野が標準化されるほどゆっくりと進化していないという点です。これには一定の真実があります。しかし、AI 業界から身を引いて状況が落ち着くのを待つことは、敗北する戦略であると私たちは信じています。フレームワークは、参入を促し、より迅速に構築し、成功の可能性を高めるのに役立ちます。それでもなお、ツールは変化し続けるでしょう。また、すべてにフレームワークが必要というわけではありません。単純な LLM リクエストであれば、フレームワークを追加するのはやりすぎになるかもしれません。
なぜ LangSmith は LangChain オープンソースから独立しているのか
初期の段階で、私たちは 品質 がエージェントを実環境に導入する際の最大の障壁であると認識しました。そして今もそう信じていますが、目的別に設計された エージェント観測性 と評価(evals)は、ツールキットに不可欠な要素であると考えています。
私たちはこれを LangSmith と名付けました。なぜなら、エージェントフレームワークが一つだけになるわけではないという直感があったからです。たとえ支配的なフレームワークが存在したとしても、その進化のスピードは初期バージョンが認識できなくなるほど速いものでなければなりません。すべての人が私たちのフレームワークを使うわけではないことを承知しつつも、それでもこのプラットフォームを利用できるようにしたいと考えました。
そのため、langchain を使用しているか、他のフレームワークを使用しているか、あるいは全く使用していないかに関わらず、LangSmith が動作するように構築しました。これは当時、自明な決断ではありませんでした。私たちは、自社製の Next.js 以外にも多くのフロントエンドフレームワークをサポートする Vercel などの企業からインスピレーションを得ました。
現在、LangSmith は AutoGen、Claude Agent SDK、CrewAI、Mastra、OpenAI Agents、PydanticAI、Vercel AI SDK などをはじめとする多数のフレームワークと標準で統合されています。また、OpenTelemetry ベースのトレーシングをサポートしており、OTEL 仕様(OpenTelemetry specification)を出力するものであれば、LangSmith が取り込むことができます。さらに、全くフレームワークを使用せずに構築されたエージェントとも連携します。Clay、Harvey、Vanta を含む多くの LangSmith の顧客は、オープンソースのフレームワークを使用せず、観測性と評価のために LangSmith に依存しています。
エージェントエンジニアリングにおける構築とテストの収束
どのエージェントフレームワークを使用するかに関わらず、トレースはエージェントの振る舞いを理解するために不可欠です。私たちは、エージェントトレースがいかに重要かについて繰り返し述べてきましたが、それはエージェントのデバッグ、モニタリング、評価(evals)などの基盤となるからです。エージェントにおいては、アプリケーションロジックはコードではなくトレースに記述されます。エージェントを構築することは最初のステップに過ぎません。エージェントは非決定系システムであるため、リリースするまでどのような入力や出力が期待できるか分かりません。そのため、デバッグ、テスト、モニタリングは エージェントエンジニアリング の重要な要素であり、構築プロセスそのものの一部でもあります。
もしあなたが当社のオープンソース(OSS)フレームワークを使用していないのであれば、その理由をお聞かせください!ただし、LangSmith を用いてなぜ・どのようにエージェントが失敗しているのかを解明するのを妨げないでください。
原文を表示
Every time LLMs get better, the same question comes back: "Do you still need an agent framework?" It's a fair question. The best way to build agents changes as the models get more performant and evolve, but fundamentally, the agent is a system *around* the model, so they will not disappear – they just need to evolve too.We've now built three generations of agent frameworks, and each one looked different from the last. So here's what we believe:
- Agent frameworks are still useful, but only if they evolve as fast as the models do.
- Agent observability should work no matter how you build. That’s why LangSmith works even if you don’t use our open source (LangChain or LangGraph).
This post is about both of those bets.
Why agent frameworks are still relevant in 2026
Agent patterns have moved from chaining to workflow orchestration to tool-calling-in-a-loop with file-systems and memory. We’ve built frameworks for them all and believe each has its place based on your use case. Here’s how they’ve evolved:
Chaining
The original langchain got popular in 2023 because few people knew how to make practical use of LLMs. The framework offered one of the easiest ways to connect foundation models to your data or APIs through a set of integrations and core abstractions. It was arguably too opinionated at the start — more of an "easy button" for learning about prompting and RAG than a production-ready tool. As the first wave of generative AI started to settle by that summer, criticism that agent frameworks were pointless grew louder.
We heard the criticism, but it was hard to square with what we were seeing in actual usage. The vast majority of teams building LLM apps needed ways to move faster than going it completely alone. Good frameworks:
- Encode best practices into the framework itself
- Reduce boilerplate code
- Make it easier to reach a higher level of quality
- Create standards and readability across large teams
- Pave a cleaner path to production
So we doubled down. On a different framework.
Orchestration and run-time
langgraph was lower level and more flexible. It included a runtime that supported durability and statefulness, which turned out to be important for human-agent and agent-agent collaboration. It addressed many of the control concerns people had raised about langchain. We did eventually rewrite the original langchain in 2025 to be more streamlined, but we also recognized that different problems need different tools.
Harness
More recently, we built deepagents: a batteries-included agent harness that's more performant and more flexible. It supports planning for long-horizon tasks, tool-calling-in-a-loop, context offloading to a filesystem, and subagent orchestration. An agent harness works now because LLMs are getting better at reasoning and you can delegate more decisions to the LLM vs. hard coding as many orchestration patterns. It's most similar in concept to Claude Agent SDK, but model-agnostic. To our knowledge, it's the only agent harness that is not tied to any specific LLM or application stack.
Today, we recommend these different frameworks for different use cases. langchain and deepagents are built on top of langgraph’s runtime for long running execution.

It sounds dramatic, but we’ve seen three generations of agents in three years: what started as RAG became agentic workflows, which evolved into more autonomous tool-calling-in-a-loop agents.
The biggest knock against frameworks is that the AI space evolves too quickly for standards to form. There's truth to that. But we also believe that sitting out of the AI game waiting for things to settle is a losing strategy. Frameworks help you dive in, build faster, and increase your odds of success. Even knowing that, the tools will keep changing. And you also don’t need a framework for everything. If it’s a simple LLM request, adding a framework may be too heavy handed.
Why LangSmith is independent from LangChain open source
Early on, we recognized that quality was the biggest barrier to getting agents into production. We believed, and still do, that purpose-built agent observability and evals were a required part of the toolkit.
We called itLangSmith, because we had the intuition that there wouldn't be only one agent framework. And even if there were a dominant one, it would have to evolve at a pace that would make early versions unrecognizable. We acknowledged not everyone would use our frameworks, but wanted them still to be able to use this platform.
So we built LangSmith to work regardless of whether you used langchain, any of our other frameworks, or nothing at all. This wasn't an obvious decision at the time. We drew inspiration from companies like Vercel, which supports many frontend frameworks beyond their ownNext.js.
Today, LangSmith integrates witha number of frameworks out of the box — AutoGen, Claude Agent SDK, CrewAI, Mastra, OpenAI Agents, PydanticAI, Vercel AI SDK, and more. It supports OpenTelemetry-based tracing, so anything that emits the OTEL spec can be ingested by LangSmith. And it works with agents built using no framework at all. Many LangSmith customers, including Clay, Harvey, and Vanta, don't use our open source frameworks but rely on LangSmith for observability and evals.
Building and testing converge in agent engineering
Regardless of your agent framework, traces are critical to understanding agent behavior. We've been writing about how important the agent trace is because it's the foundation for agent debugging, monitoring, evals, and more. With agents, your app logic is documented in traces, not code. Building the agent is only the first step. Agents are non-deterministic systems, so you have no idea what inputs or outputs to expect until you ship it. That’s why debugging, testing, and monitoring are critical parts ofagent engineering and the building process itself.
So if you’re not using our OSS frameworks, we’d like to hear why! But, don’t let it stop you from figuring out how and why your agent is failing with LangSmith.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み