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

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** のランタイムの上に構築されています。 ![image](https://cdn.prod.website-files.com/65c81e88c254bb0f97633a71/69cba9ec0d1eacf7a3a646f7_data-src-image-d6a87a95-4aa7-4edd-bf29-fbed61103e87.png) 劇的に聞こえるかもしれませんが、私たちは 3 年間で 3 つ世代のエージェントを見てきました：RAG から始まり、エージェントワークフローへと進化し、さらに自律的なループ内ツール呼び出し型エージェントへと発展しました。 フレームワークに対する最大の批判は、AI の分野が標準化されるほどゆっくりと進化していないという点です。これには一定の真実があります。しかし、AI 業界から身を引いて状況が落ち着くのを待つことは、敗北する戦略であると私たちは信じています。フレームワークは、参入を促し、より迅速に構築し、成功の可能性を高めるのに役立ちます。それでもなお、ツールは変化し続けるでしょう。また、すべてにフレームワークが必要というわけではありません。単純な LLM リクエストであれば、フレームワークを追加するのはやりすぎになるかもしれません。 なぜ LangSmith は LangChain オープンソースから独立しているのか 初期の段階で、私たちは [品質](https://www.langchain.com/state-of-agent-engineering?ref=blog.langchain.com#biggest-barriers-to-production) がエージェントを実環境に導入する際の最大の障壁であると認識しました。そして今もそう信じていますが、目的別に設計された [エージェント観測性](https://www.langchain.com/articles/agent-observability) と評価（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 に依存しています。 ## エージェントエンジニアリングにおける構築とテストの収束 どのエージェントフレームワークを使用するかに関わらず、トレースはエージェントの振る舞いを理解するために不可欠です。私たちは、[エージェントトレースがいかに重要か](https://blog.langchain.com/in-software-the-code-documents-the-app-in-ai-the-traces-do/)について繰り返し述べてきましたが、それはエージェントのデバッグ、モニタリング、評価（evals）などの基盤となるからです。エージェントにおいては、アプリケーションロジックはコードではなくトレースに記述されます。エージェントを構築することは最初のステップに過ぎません。エージェントは非決定系システムであるため、リリースするまでどのような入力や出力が期待できるか分かりません。そのため、デバッグ、テスト、モニタリングは [エージェントエンジニアリング](https://blog.langchain.com/agent-engineering-a-new-discipline/) の重要な要素であり、構築プロセスそのものの一部でもあります。 もしあなたが当社のオープンソース（OSS）フレームワークを使用していないのであれば、その理由をお聞かせください！ただし、LangSmith を用いてなぜ・どのようにエージェントが失敗しているのかを解明するのを妨げないでください。

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

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

関連記事

調べる

選ぶ

サイト