4分でわかるLangGraph (LangGraphチュートリアル)

Q: LangGraphとは何か？

LangGraphは、LangChainのコンポーネントが動作するランタイムを提供するPythonフレームワークで、AIエージェントをグラフとして表現し、ループ、分岐、待機、中断からの再開を可能にします。[0]

Q: LangGraphはどのような問題を解決するのか？

LangGraphは、LangChainエージェントの「状態管理の失敗」（コンテキスト喪失、ステップ繰り返し、クラッシュなど）という、生産環境でのエージェントインシデントの60%以上を占める問題を解決するために構築されました。[4]

LangGraphは、AIエージェントの状態管理の失敗というLangChainの課題を解決するために開発されました。従来のネストされたif文の代わりに、グラフ構造でエージェントのフローを視覚化し、条件分岐やループを容易にすることで、複雑なAIエージェント開発を劇的に簡素化します。

1. LangGraphとは：AIエージェント開発におけるLangChainの課題解決 [0]

LangGraphは、LangChainのAIエージェントが抱える「状態管理の失敗」という課題を解決するために開発されたPythonフレームワークである。

1.1. LangGraphの概要とLangChainとの関係 [0]

LangGraphはAIエージェント構築のためのPythonフレームワークである [0]
1. LangChainと同じ開発チームによって構築され、両者は連携して機能する。
LangChainとLangGraphの役割分担 [1]
1. LangChainはAIエージェントの「コンポーネント」を提供する。
2. LangGraphはそれらのコンポーネントが実際に動作する「実行環境（ランタイム）」を提供する。
AIエージェントの表現方法 [2]
1. LangGraphはAIエージェントを直線的な「チェーン」ではなく、「グラフ」として表現する。
2. 各ステップは「ノード」であり、次のアクションに関する決定は「エッジ」として表現される。
3. グラフ構造により、ループ、分岐、待機、中断した場所からの再開が可能となる。

1.2. LangGraphが普及した理由：状態管理の失敗の解決 [4]

LangChainにおける状態管理の課題 [4]
1. LangChainの調査によると、本番環境でのエージェントのインシデントの60%以上が「状態管理の失敗」に起因する。
2. 具体的には、ワークフローの途中でエージェントがコンテキストを失う、完了したステップを繰り返す、回復手段なくクラッシュするといった問題が発生していた。
3. LangGraphは、この状態管理の問題を解決するために特別に構築された。
LangGraphの導入事例 [7]
1. LinkedIn：候補者のソーシング、マッチング、メッセージングを処理するAIリクルーターを構築した。
2. Uber：社内開発者ツールにLangGraphを使用している。
3. Korona：顧客サポートにLangGraphエージェントを導入し、平均解決時間を11分から2分に短縮した。

2. LangGraphを使わないAIエージェント開発の課題 [11]

LangGraphを使わない従来の方法では、複雑なAIエージェントのロジックがネストされたif文の連続となり、保守が困難になる。

2.1. 従来のスクリプト作成方法の複雑さ [11]

リサーチエージェントの例 [11]
1. 質問を受け取り、ウェブを検索し、結果を読み込み、回答を生成するリサーチエージェントを想定する。
従来のスクリプトの構造 [13]
1. 検索APIを呼び出し、URLリストを取得する。
2. 各URLをループ処理し、ページをスクレイピングする。
3. コンテンツが有用かどうか（誤情報やクリックベイトでないか）を確認する。
4. 有用でない場合、別のクエリを試すためのロジック分岐を記述する。
5. 「再試行」「スキップ」「停止」といった各決定が、前のif文の中にさらにネストされたif文となる。
保守性の低下 [17]
1. このようにネストされたif文の構造は、6ヶ月後には開発者自身を含め、誰も触りたくない「忌まわしいもの」となる。

3. LangGraphによるAIエージェント開発の簡素化 [18]

LangGraphは、AIエージェントのロジックをグラフ構造で視覚化し、条件分岐やループを容易にすることで、複雑な開発を劇的に簡素化する。

3.1. グラフ構造によるロジックの可視化 [18]

グラフとしてのロジック表現 [18]
1. 従来の複雑なロジックを、検索（search）、スクレイピング（scrape）、評価（evaluate）の3つのノードとして定義する。
2. 再試行ロジックを関数内にネストする代わりに、評価ノードから検索ノードへ「エッジ」を引く。
3. このエッジは、評価結果が不十分な場合にのみ発火する。
制御フローの可視化 [21]
1. これにより、コード内に埋もれていた制御フローが、視覚的な構造として明確になり、理解しやすくなる。
条件付きエッジの導入 [22]
1. 評価ノードから検索ノードへ引かれるエッジは「条件付きエッジ（conditional edge）」と呼ばれる。
2. これはLangGraphが通常のLangChain呼び出しと異なる点である。
3. 各ステップが次の1つのステップにのみつながるのではなく、条件付きエッジは現在の状態を見て次にエージェントをどこに送るかを決定する小さなルーター関数を実行する。
4. 例えば、評価が十分であれば「終了（finish）」にルーティングし、不十分であれば洗練されたクエリで「検索（search）」に戻る。
5. これは通常if-elseブロックに埋もれる分岐決定と同じだが、グラフ構造の第一級の部分となる。

3.2. チェックポインターによる耐久性のある実行 [28]

自動的な状態保存 [28]
1. LangGraphはグラフに「チェックポインター（checkpointer）」をアタッチし、すべてのノード実行の状態を自動的に保存する。
クラッシュからの回復 [29]
1. 例えば、5ステップのプロセス中、3ステップ目でサーバーが再起動したり、プロセスがクラッシュしたり、新しいコードがデプロイされたりした場合を想定する。
2. チェックポインターがない場合、エージェントは最初からやり直すことになる。
3. チェックポインターがアタッチされていれば、エージェントはすべての状態を保持したまま、中断したノードから正確に再開できる。
耐久性のある実行 [32]
1. これが「耐久性のある実行（durable execution）」である。

4. LangGraphを使用すべきでないケース [33]

LangGraphは強力なツールだが、すべてのプロジェクトに適しているわけではない。単純なタスクでは、LangChain単体やAPI呼び出しの方がシンプルで効率的である。

4.1. LangGraphの適用範囲 [33]

LangGraphが不要なケース [33]
1. すべてのプロジェクトでLangGraphを使用する必要はない。
2. 自身のドキュメントに対する単純な質疑応答パイプライン（1回の呼び出し、1回の応答）を構築する場合、LangChain単体、あるいはプレーンなAPI呼び出しの方が、よりシンプルで、維持費が安く、次の開発者にとって読みやすい。
LangGraphが有効なケース [35]
1. エージェントがループする、実際の条件に基づいて分岐する、または続行する前に人間の介入（human in the loop）が必要となる場合に、LangGraphの複雑さが報われる。
不必要な複雑さの回避 [36]
1. 上記の条件を満たさない場合、LangGraphを使用することは、まだ必要のない構造を追加することになる。