LangChainとは

LangChainは、LLMを使ったアプリケーションを組み立てるためのライブラリです。プロンプトテンプレート、複数の処理をつなぐチェーン、会話履歴を保持するメモリ、外部ツールを呼び出すエージェント機能、そして各種LLMプロバイダーやベクトルDB、外部APIへの統合ラッパーが一式そろっています。

要は「LLMまわりの便利オブジェクトを集めたキット」で、OpenAIでもAnthropicでもGoogleでも同じインターフェースで書けることを売りにしていました。

LangChainの問題点

デバッグがしづらい

LCELの|記法は書くときは簡潔なのですが、実行時に中で何が起きているかを追うのが難しく、エラーが起きたときにどのステップで何が渡って失敗したのかが直感的に分からない、もともとはAPI呼び出しの連なりに過ぎないのに、独自の抽象化レイヤーを一枚挟んだことで、素のコードを読むより遠回りになってしまう場面が多い、という指摘がよく見られます。

重い

機能を増やすたびに依存パッケージが積み重なり、シンプルなAPI呼び出し1つのために大きなライブラリを丸ごと抱え込む形になります。加えて、バージョンアップのたびにインターフェースが変わることも多く、追従コストが高い。単純なRAGパイプライン程度であれば、素のAPI呼び出しを直接書いたほうが速くて壊れにくい、というのが2025年後半以降よく聞かれるようになりました。

2026年8月時点のトレンド

2026年に入るとOpenAI/Anthropicなどのモデル提供元自身が構造化出力・ツール呼び出し・会話管理をAPIレベルで吸収したほか、外部ツールとの接続方法自体がMCPという共通規格に集約されたことで、LangChainが担っていた「各社バラバラなAPIの差異を吸収する」という役割の価値が薄れました。さらに複雑な状態管理やマルチエージェントの制御が必要なケースでも、LangGraphという専用ツールでまかなえるようになり、LangChainが元々担っていた便利さの価値そのものが薄れて、生SDK呼び出しへ回帰する動きが加速しているようです。

以下、LangChainが使われなくなっている要因3選です。

MCPでLangChainのツール接続レイヤーが必須ではなくなった

以前は、OpenAIのfunction calling形式とAnthropicのtool use形式で微妙に書き方が違ったため、LangChainのToolオブジェクトがその差異を吸収する役割を担っていました。
ところが2024年にAnthropicが提唱したMCPが2025年末に登場し、OpenAIやGoogle、Microsoftなど主要なプレイヤーが軒並み採用したことで、「ツールをどう繋ぐか」の部分がフレームワーク非依存の共通言語になった。
つまり、LangChainを使わなくても、MCPサーバーとして機能を公開しておけば、どのエージェント実装からでも呼び出せるようになってしまいました。

OpenAI/Anthropicなどモデル提供元の純正ツールの方が体験が良い

2026年になると、モデル提供元自身がエージェント構築用のSDKを出すようになりました。
AnthropicはClaude Codeのエンジンをそのまま切り出した「Claude Agent SDK」を、OpenAIは実験的だったSwarmを本番向けに仕上げた「OpenAI Agents SDK」を提供しています。
これらは自社モデルの拡張思考やツール呼び出しの癖に最適化されたハーネスなので、単一プロバイダーで完結するアプリケーションであれば、LangChainの抽象化を挟むより純正SDKを直接使ったほうが、機能面でも体験面でも素直に扱えます。

複雑なケースはLangGraphでどうにかなる

一方で、複数のモデルプロバイダーを組み合わせたいケース(例えばGPTとClaudeを役割分担させるマルチエージェント構成)や、状態遷移が複雑なワークフローでは、LangChainから独立したLangGraphが実質的な標準になっています。
LangGraphはLangChainのような「便利オブジェクト集」ではなく、ワークフローを明示的なグラフとして自分で組み立てる低レベルのオーケストレーションツールで、月間4700万ダウンロードを超える規模で使われています。プロバイダーを問わず動くため、マルチベンダー構成が必要な場面ではまだ現役の選択肢です。

まとめ

技術の栄枯盛衰がとても早い。二年前には主流だったフレームワークも、二年後には陳腐化してしまうらしいです。早く取り込み、早く吐き出すようにしていかないと、気づいたら何もできない人間になっていそうでとても怖い。

引用