@langchain/langgraph を採用する前に読む、状態を持つエージェントの配線図
Framework to build resilient language agents as graphs.
ひと目でわかる
- これは何？
- LangGraph.js はエージェントの制御フローをグラフとして書き下すための低レベル基盤で、永続実行と人間の介入を軸に据えている。LangChain 本体や Deep Agents との役割の違い、checkpoint の考え方、そして向かないケースまでを README とドキュメントの記述範囲で整理する。
- 誰に向いている？
- 採用を検討すべきなのは、長時間動く処理の途中状態を保存し、失敗した地点から再開させたいチームと、実行の任意の地点で人間が状態を覗いて書き換える経路を設計に組み込みたいチームである。逆に、単発のプロンプト呼び出しや数ステップで終わる短い処理しか書かないなら、この依存を増やす理由は薄い。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に TypeScript です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
LangChain が担う部分と LangGraph が担う部分の境界
README は LangGraph を low-level orchestration framework と位置づけ、LangChain については integrations and composable components を提供するものだと説明している。つまりモデルの呼び出しやツールの接続、出力パーサといった部品は LangChain 側の仕事で、LangGraph が引き受けるのは部品同士の順序、分岐、状態の持ち回りである。この切り分けは、既に LangChain でアプリを書いている人が「置き換え」ではなく「追加」として読むべきものだということを意味する。README には can be used without LangChain という記述もあり、LangChain を挟まずに LangGraph だけを使う構成も想定されている。パッケージ名は @langchain/langgraph で、@langchain/core と一緒に入れる形がインストール例として示されている。
グラフという語が指しているもの、Pregel と NetworkX からの借用
README の Acknowledgements は、LangGraph が Pregel と Apache Beam に着想を得ており、公開インターフェースは NetworkX から影響を受けていると明記している。Pregel は頂点間でメッセージを交換しながら反復計算を進めるモデルで、Beam はデータフローの記述と実行を分ける。この由来を踏まえると、LangGraph のグラフは「ノードを並べたフローチャート」というより、状態を運びながら繰り返し評価される計算の記述だと読める。NetworkX 由来のインターフェースという点も見逃せない。ノードとエッジを宣言し、条件分岐をエッジ側に持たせる書き味は、Python の NetworkX に慣れた読者ほど違和感が少ないはずだ。ただし README は着想元を挙げているだけで、Pregel の全機能を再現しているとは書いていない。この点は各自のドキュメント確認に委ねられている。
永続実行が成立する条件: checkpoint という発想
README が durable execution として挙げているのは、失敗を越えて持続し、長時間走り、中断した正確な地点から自動的に再開する挙動である。これが成り立つには、実行の各段階で状態を外部に書き出す仕組みが要る。README はその語として checkpointing APIs を API Reference の説明に含めているが、具体的なストアの種類や設定キーには踏み込んでいない。設計上の含意ははっきりしている。状態をプロセスのメモリに置いたままにする実装では、この再開は成立しない。プロセスが落ちた時点で状態も消えるからだ。したがって採用判断では、どのタイミングで状態が永続化されるのか、再開時にどのノードから評価が再開されるのかをドキュメントで確認する必要がある。README の記述だけでは、再開の粒度がノード単位なのかステップ単位なのかまでは読み取れない。
human-in-the-loop は割り込みを設計に織り込むということ
README は human-in-the-loop を、実行中の任意の地点でエージェントの状態を検査し変更できる仕組みとして説明し、interrupts というドキュメントページに誘導している。ここで重要なのは、人間の承認を後付けのUIとして足すのではなく、グラフの中断点として定義する発想である。中断がグラフの構造の一部になるということは、再開の経路もまたグラフ上で決まるということだ。承認待ちの状態をどう保存し、誰が何を見て、どの値が書き換わったときにどのエッジへ進むのか。これらはアプリケーション側の設計課題であって、フレームワークが自動で決めてくれるものではない。README は seamless という語を使っているが、実際に必要な作業は状態のスキーマ設計と中断点の選定であり、そこを飛ばすと恩恵は受けられない。
短期記憶と長期記憶を別物として扱う
README は memory の説明で、ongoing reasoning のための短期的な作業記憶と、セッションをまたいで持続する長期的な記憶を分けている。この二つは保存期間も参照頻度も違うため、同じ仕組みで扱うと無理が出る。短期的な記憶は実行中のグラフの状態そのもので、checkpoint と結びつく。長期的な記憶はセッションを越えて残るもので、別のライフサイクルを持つ。README は両方を comprehensive memory という一つの見出しの下に置いているが、実装としては別々の関心事だと考えるべきだ。採用時には、どのデータをどちらに置くかを先に決めておかないと、後から状態スキーマを掘り直すことになる。
導入コマンドと、確認しておきたいパッケージの関係
インストールは README の記載どおり npm install @langchain/langgraph @langchain/core の一行で始まる。@langchain/core が同時に指定されている点は見落とさないほうがよい。LangGraph は単体でも使えると README は述べているが、インストール例では core が並んでいる。バージョンは揃えて固定するのが無難だ。リポジトリのリリース一覧には @langchain/react、@langchain/vue、@langchain/svelte の 1.0.36-rc.1 が並んでおり、これらは RC 版である。UI フレームワーク向けのバインディングを併用する予定があるなら、安定版ではなくリリース候補を掴むことになる点を認識しておきたい。リポジトリの最終 push は 2026-09-09 で、同じ日にこれら RC が公開されている。活発に動いている代わりに、追従のコストはそれなりにかかる。
Deep Agents という上位層があり、そこで足りるなら下位は要らない
README は冒頭の TIP で、素早くエージェントを組みたいなら Deep Agents を見るよう促している。Deep Agents は LangGraph の上に載る高レベルなパッケージで、計画、サブエージェントの利用、ファイルシステムの活用を備えると説明されている。ここから読み取れるのは、LangGraph が想定している利用者層である。制御フローを自分で決めたい、あるいは既存の処理の途中にエージェントを差し込みたい開発者向けであって、汎用的なエージェントを一から組むだけなら上位層で足りる可能性が高い。低レベルを選ぶということは、配線の自由と引き換えに、配線の責任を負うということだ。この交換条件を意識せずに選ぶと、グラフを書くこと自体が目的化する。
向かないケースと、比較対象としての素のループ実装
このフレームワークが過剰になるのは、処理が一回のモデル呼び出しで完結する場合や、再開も中断も不要な短命のバッチ処理である。そうした用途では、状態を外部に永続化する仕組みは持ち込みの負担にしかならない。比較対象として素直なのは、状態をただのオブジェクトとして持ち、while ループでツール呼び出しを回す自前実装だ。違いは再開可能性にある。自前ループはプロセスが落ちれば最初からやり直しで、途中で人間に確認を挟むにもフラグとポーリングを自分で書くことになる。LangGraph はその二点をフレームワークの構造として持ち込む。逆に言えば、その二点が要らないなら自前ループのほうが依存も学習コストも小さい。判断は「途中で止まって、後から続きを走らせたいか」の一点に集約される。
MIT ライセンスと、LangSmith を前提とした観測の話
ライセンスは MIT で、リポジトリはアーカイブされていない。MIT である以上、ソースの改変や再配布の条件は比較的緩い。ただしライセンス条文の解釈はここで扱う範囲を超えるので、実際の利用形態に応じて確認してほしい。もう一点、README はデバッグとデプロイの文脈で LangSmith を繰り返し挙げ、production-ready deployment のリンク先も LangSmith のデプロイメントページになっている。LangGraph 本体は MIT で独立して使えるが、複雑な実行経路の可視化や本番運用の導線は LangSmith 側に寄っている。ここは採用時に見積もっておきたいコストだ。グラフの実行を追う手段を自前で用意するのか、LangSmith に乗るのかで、運用の形が変わる。README はこの点について、LangGraph 単体での観測手段がどこまで揃うかを明示していない。
編集部の結論
採用を検討すべきなのは、長時間動く処理の途中状態を保存し、失敗した地点から再開させたいチームと、実行の任意の地点で人間が状態を覗いて書き換える経路を設計に組み込みたいチームである。逆に、単発のプロンプト呼び出しや数ステップで終わる短い処理しか書かないなら、この依存を増やす理由は薄い。最初に確認すべきは、自分のユースケースで checkpoint をどのストアに置くか、そして中断と再開の境界をどこに引くかである。@langchain/langgraph と @langchain/core のバージョンを固定し、npm install @langchain/langgraph @langchain/core で入る実際の依存ツリーを手元で確認してから本番の設計に入るのが順当だ。
コミュニティノート