【ITニュース解説】Langchain and LangGraph

大規模言語モデル（LLM）は、人間のような自然な言葉を理解し生成する能力を持ち、様々なアプリケーションの基盤となっている。しかし、LLMを実際のシステムに組み込み、意図した通りの複雑な振る舞いをさせるのは簡単ではない。そこで登場するのが、LangChainというフレームワークである。LangChainは、LLMを活用したアプリケーション開発を大幅に簡素化するための包括的なツール群を提供する。これは、多様な機能を部品として提供し、それらを組み合わせて複雑なシステムを構築できるようにする仕組みだ。

LangChainの主要な構成要素は多岐にわたる。まず、アプリケーションの「頭脳」となるのがモデルである。これには、テキスト生成を行うLLM自体や、チャット形式の対話に特化したチャットモデルが含まれる。また、テキストの意味を数値のベクトルに変換する埋め込みモデルも重要で、これは意味的に似た情報を検索したり比較したりする際に使われる。次に、LLMに指示を与えるための「言葉」を準備するのがプロンプトの役割だ。プロンプトテンプレートを使えば、「〇〇について教えてください」といった定型文の中に、ユーザーが入力した情報を動的に組み込むことができる。さらに、LLMが生成した自由な形式のテキストを、プログラムで扱いやすいJSON形式や特定のデータ構造に整形するための出力パーサーも用意されている。これにより、LLMの応答を確実に次の処理に引き渡せるようになる。

これらの部品を単独で使うだけでなく、複数の処理を順番に実行したい場合も多い。そのためにチェーンという概念がある。チェーンは、LLMへの呼び出しやその他のユーティリティを連続してつなぎ合わせることで、一連のまとまった処理フローを作る。例えば、あるLLMの出力を次のLLMの入力として渡すシーケンシャルチェーンや、外部の情報を参照してLLMの回答を補強するリトリーバルチェーンなどがある。

外部情報を取り扱うための機能群はリトリーバルと呼ばれる。これは、LLMが学習した知識だけでなく、最新の情報や特定の企業の文書など、外部のデータに基づいて回答できるようにする仕組みである。まず、PDFファイルやウェブサイト、データベースなどからデータを読み込むドキュメントローダーがある。次に、それらの大きな文書をLLMが処理しやすいように小さな塊に分割するテキストスプリッターを使う。これらのテキスト塊は、意味を表す数値ベクトルに変換され、ベクターストアという特殊なデータベースに保存される。そして、ユーザーの質問に関連する情報をこのベクターストアから効率的に検索し、LLMに提供するのがリトリーバーの役割である。これにより、LLMは関連情報を参照しながら、より正確で適切な回答を生成できるようになる。

LangChainにおける究極の目標の一つが、自律的な振る舞いをするエージェントの構築である。エージェントは、LLMをあたかも「推論エンジン」のように利用し、ユーザーの指示に基づいてどの「ツール」を使うべきか、そしてどの順番で使うべきかを自律的に判断する。ツールとは、検索エンジンを呼び出したり、計算を行ったり、外部APIと連携したりするような、LLMが「外部世界」とやり取りするための機能の総称である。エージェントエグゼキューターは、このエージェントの決定に従ってツールを実行し、その結果を再びLLMにフィードバックする。最近のLLMは、直接ツール呼び出しの形式で出力できるようになっており、エージェントとツールの連携がよりスムーズになっている。

LangGraphは、このようなLangChainの豊富なコンポーネント群をさらに高度に「オーケストレーション」するための拡張フレームワークである。LangChainが個々の部品を提供するならば、LangGraphはそれらの部品を組み合わせて、複雑で「状態を持つ」アプリケーションを構築するための「設計図」と「組立ライン」を提供する。LangGraphでは、アプリケーション全体をグラフとして表現する。このグラフの中では、各処理ステップがノードとして表され、ノード間の処理の流れはエッジで定義される。そして、最も重要なのが**状態（State）**という概念である。これは、グラフの実行中にすべてのノード間で共有されるオブジェクトで、現在の対話履歴、ユーザー名、注文IDなど、アプリケーションの文脈となる情報が保持される。各ノードは現在の状態を受け取り、処理を行い、状態を更新して次のノードに渡す。StateSchemaを使うことで、この状態の構造を厳密に定義し、型安全性を確保できる。

LangGraphの機能は多岐にわたる。ノードはPythonの関数やメソッドで実装され、現在の状態を受け取って状態の更新を返す。エッジはノード間の接続を定義し、特に条件付きエッジは、状態に基づいて次に実行すべきノードを動的に決定できるため、エージェントのような複雑な判断ロジックを実装する上で不可欠である。これにより、LLMが「次に何をすべきか」を判断し、その判断に基づいて処理の分岐を制御できる。

さらに、LangGraphは高度なアプリケーション要件にも応える。HumanInLoop（人間参加型）機能を使えば、グラフの特定のポイントで処理を一時停止し、人間が状態を確認したり修正したりしてから再開できる。InMemory機能は開発中に状態をメモリに一時的に保存するのに便利だが、本番環境ではデータベースと連携して永続化される。LLMからの出力を部分的に順次表示するストリーミングが不可欠で、LangGraphもこれをサポートする。複雑なグラフのデバッグを助けるのがブレークポイントであり、特定のノードで実行を停止し、その時点の状態を詳細に検査できる。また、独立した複数の処理を同時に実行する並列処理も可能で、これによりアプリケーションの応答速度を向上させられる。

大規模なアプリケーションを構築する際には、部品化と再利用が重要になる。LangGraphのサブグラフ機能は、一つのLangGraphアプリケーションを、より大きなグラフの中の一つのノードとして扱うことを可能にする。これにより、複雑なシステムを小さなモジュールに分割して開発し、それらを組み合わせて全体を構築できる。また、文書の要約などでよく用いられるMapReduceパターンも容易に実装できる。これは、複数の入力（例：文書の各チャンク）を個別に処理（Map）し、その結果を最後に集約（Reduce）するという手法だ。

LangGraphは、LLMベースのエージェント構築に特に強力な能力を発揮する。例えば、ReAct（Reasoning and Acting）というパターンでは、LLMが「思考」して行動計画を立て、その後「行動」（ツール呼び出し）を行い、その結果を基に次の思考へとサイクルを繰り返す。LangGraphは、このようなサイクリックな処理フローと状態管理を自然に表現できるため、ReActエージェントの実装に理想的である。現代のLLMは、ツール呼び出しの意図を直接構造化された形式で出力する能力を持つようになっており、LangGraphはこのTool Callingの仕組みを最大限に活用し、LLMが判断したツールを呼び出し、その結果を次の処理にスムーズに渡すことを可能にする。

このように、LangGraphはLangChainの上に築かれている。LangChainが提供する多様なLLM、プロンプト、ツール、リトリーバーといった「部品」を、LangGraphは「グラフ」という構造を用いて、状態を持ち、より複雑で動的な、時には自律的なワークフローへと組み立て上げる「オーケストレーション層」として機能する。この二つのフレームワークを組み合わせることで、開発者はLLMの能力を最大限に引き出し、高度で堅牢な対話型アプリケーションやエージェントシステムを効率的に構築できるようになるのだ。