第4章 LangChainとLangGraphの使い分けと連携

4.1 LangChain単体とLangGraphの選定基準

新しいAIプロジェクトを立ち上げる際、LangChain単体で開発すべきか、それともLangGraphを導入すべきかは重要な判断基準となります。基本的には、開発したいシステムの複雑さと、処理の流れに「ループ（繰り返しや軌道修正）」が存在するかどうかで判断します。

ユーザーからの入力に対して、いくつかの情報を検索（RAG）し、プロンプトを組み立ててLLMに渡し、その回答を画面に表示する、といった一方通行の処理であれば、LangChain単体が最適です。LCELを用いたシンプルな構成にすることで、コード量も少なく済み、動作のデバッグも容易になります。

一方で、以下のような場合にはLangGraphの導入を強く推奨します。まず、エラーが発生した際に「何がダメだったのか」をAI自身に評価させ、プログラミングコードやクエリを修正して再実行させるようなループ処理がある場合です。また、ユーザーが途中で処理に介入し、中身を確認してから「実行を許可する」といったインタラクティブな動き（Human-in-the-loop）が必要な場合や、複数のAIが役割分担して共同でタスクを進める場合も、LangGraphの強力な状態管理が必須となります。

プロジェクトの初期段階ではLangChain単体で試作（プロトタイピング）を行い、システムの機能要件が複雑化して状態の管理やループ制御が必要になった段階で、LangGraphへとスムーズに移行していくというアプローチが賢明です。

4.2 既存のLangChainコンポーネントをLangGraphのノード内で再利用する方法

LangGraphはLangChainの上に構築されているため、両者は非常に高い親和性を持っています。これは、これまでLangChainで構築した既存のコードやコンポーネントを、捨てることなくそのままLangGraphのパーツとして組み込めることを意味します。

具体的には、LangChainで定義した「LLMとプロンプトをLCELで繋いだチェーン（prompt | llm）」や、検索エンジンや計算機などの「ツール（Tools）」は、LangGraphの「ノード」の関数内部で直接呼び出して実行できます。ノードの役割は「現在の状態を受け取って、更新された状態を返す」という非常にシンプルなインターフェースになっているため、関数の内部で既存のLangChainの invoke メソッドを実行し、その出力を状態に格納するだけで連携が完了します。

これにより、ライブラリの移行コストを最小限に抑えながら、既存の単純なチェーンを、自律してループ動作する高度なエージェントへと段階的に拡張していくことができます。LangChainで部品を作り、LangGraphでそれらを束ねて複雑な動きを作る、というのが現在のLLMアプリケーション開発におけるベストプラクティスです。