--- title: "LangChainとLangGraphの違い｜v1.0で逆転した関係と使い分け" url: "https://www.issoh.co.jp/tech/details/4059/" published: 2024-11-04 updated: 2026-09-27 categories: ["AIエージェント・MCP"] publisher: "株式会社一創" --- # LangChainとLangGraphの違い｜v1.0で逆転した関係と使い分け LangChainとLangGraphの違いを検索すると、「LangGraphはLangChainの上に構築されたフロー管理レイヤー」という説明が今も多く出てきます。この説明は2024年時点のものです。2025年10月22日にLangChain 1.0とLangGraph 1.0が同時リリースされ、両者の上下関係は逆転しました。現在はLangGraphが低レベルのランタイムで、LangChainのエージェントがその上で動きます。本記事は2026年7月時点の一次情報（LangChain 1.3.13／LangGraph 1.2.9）に基づき、処理構造の違い、コードの書き分け、どちらを選ぶかの判断基準を整理します。 ## まとめ：LangChainとLangGraphの違いと選び方 - **関係**：競合する2製品ではなく、同じLangChain Inc.が出す2層。LangGraph＝ステートフルなエージェントを動かす低レベルのオーケストレーション・ランタイム、LangChain＝その上に載る高レベルAPI（モデル抽象・ツール・エージェント）。 - **v1.0での変化**：LangChain 1.0の`create_agent`はLangGraph上で動く。「LangGraphがLangChainの上」という旧来の説明は逆で、依存の向きはLangChain → LangGraph。 - **処理構造**：LangChainのチェーンは入力から出力へ一方向に流れる。LangGraphのStateGraphはNodeとEdgeで条件分岐とループを表現し、共有Stateを更新しながら循環できる。 - **選び方**：単発のRAG・要約・分類のような直線的な処理はLangChainだけで完結する。ループ・分岐・人手承認・長時間実行の永続化が要るならLangGraphに降りる。 - **LangGraph単体でも使える**：LangGraphの利用にLangChain本体は必須ではない（公式ドキュメントが明記）。OpenAI SDKなど他のクライアントと組み合わせても動く。 ## LangChainとLangGraphの関係：v1.0で逆転した依存の向き ### 2024年までの「LangChainの上のLangGraph」という説明 LangGraphが公開された2024年当時、LangGraphはLangChainのLCEL（LangChain Expression Language）を拡張し、チェーンにサイクルを追加する拡張パッケージとして紹介されました。当時の解説記事はほぼこの構図で書かれており、日本語の比較記事は2026年になってもこの説明を引き継いでいるものが多く残っています。検索上位の記事が「LangGraphはLangChainの上に乗るフロー管理レイヤー」と書いていたら、v1.0以前の情報だと考えて読み替えてください。 ### 現在の階層：LangGraphがランタイム、LangChainが高レベルAPI 2025年10月22日のv1.0で構成は整理されました。LangChain公式ドキュメントはLangGraphを「長時間実行されるステートフルなエージェントを構築・管理・デプロイするための低レベルなオーケストレーション・フレームワークかつランタイム」と定義しています。そしてLangChain側のドキュメントは「LangChainのエージェントは、永続化・ストリーミング・human-in-the-loopを提供するためにLangGraphの上に構築されている」と書いています。つまり依存の向きはLangChain → LangGraphです。 逆向きの依存はありません。LangGraphの公式ドキュメントは「LangGraphを使うためにLangChainを使う必要はない」と明記しています。LangGraphが必要とするのはメッセージ型などを持つ`langchain-core`であり、モデル抽象・ツール・エージェントとプロバイダ連携をまとめる高レベル層のLangChain本体ではありません。この非対称性が、両者の関係を読み違えないための分岐点になります。 v1.0ではパッケージの整理も行われました。旧来のチェーン実装・Retriever・indexing API・hubモジュールは`langchain-classic`へ移され、`langchain`名前空間はエージェント構築に必要な要素へ絞り込まれています。v1.0で何が入れ替わったかは[LangChain v1.0の概要と新機能：v0.xからの刷新点・新要素を含むアップデート全体像](https://www.issoh.co.jp/tech/details/9663/)で個別に扱っています。 ## 処理構造の違い：一方向のチェーンと循環するグラフ ### LangChain：入力から出力へ一方向に流れるチェーン LangChainの中心的な抽象はチェーンです。プロンプトテンプレート、モデル呼び出し、出力パーサーといった部品を並べ、前の出力を次の入力へ渡していきます。構造としては有向非巡回グラフ（DAG）で、同じ工程へ戻ることはありません。ドキュメントを検索して埋め込み、プロンプトに詰めて回答を生成する、といった一往復のRAGはこの形に収まります。処理系が単純なぶん、状態管理も分岐設計も不要です。 ### LangGraph：State・Node・Edgeによる分岐とループ LangGraphは処理をグラフとして定義します。構成要素は4つです。 | 要素 | 役割 | | ---------- | ------------------------------- | | State | 共有状態（各Nodeが差分で更新） | | Node | 処理単位（モデル呼び出し・ツール実行・任意のPython関数） | | Edge | 次Nodeへの経路（条件付きEdgeで分岐・ループ） | | StateGraph | グラフ本体（`compile()`で実行可能に） | ここで効いてくるのが条件付きEdgeです。「モデルがツール呼び出しを返したらツールNodeへ、最終回答を返したら終了へ」という判定を書けるため、ツールを呼んで結果を見て考え直す、という循環がグラフとして表現できます。LangChainのチェーンでは、この「戻る」動きを素直に書けません。両者の差が最も見えるのがこの一点です。 加えて、checkpointerを差せばStateは永続化されます。エージェントの実行がサーバー再起動を跨いで生き残る、人の承認待ちで数時間止めてから再開する、といった運用の土台がこれです。ツール呼び出しの仕組みは[LangGraphのTool Callingとは？その仕組みと基本概念](https://www.issoh.co.jp/tech/details/5428/)で詳しく扱っています。 ## コードで見る違い：create\_agentとStateGraphの書き分け LangChain 1.0以降、標準的なエージェントは`create_agent`で作ります。ツール呼び出しのループはこの中に組み込まれており、グラフを自分で組む必要はありません。 ``` from langchain.agents import create_agent from langchain.tools import tool @tool def search_docs(query: str) -> str: """社内文書を検索して該当箇所を返す""" return retriever.invoke(query) # モデルIDは利用するプロバイダの現行ラインナップに合わせて指定する agent = create_agent( model="openai:gpt-4.1", tools=[search_docs], system_prompt="あなたは社内文書を検索して回答するアシスタントです。", ) result = agent.invoke({"messages": [{"role": "user", "content": "就業規則の有給付与日は?"}]}) ``` この`create_agent`が内部で組み立てているのがLangGraphのグラフです。ループ構造そのものを自分で決めたい場合は、同じことをStateGraphで書き下ろします。 ``` from langchain.chat_models import init_chat_model from langgraph.graph import StateGraph, START, END, MessagesState from langgraph.prebuilt import ToolNode from langgraph.checkpoint.memory import InMemorySaver model = init_chat_model("openai:gpt-4.1").bind_tools([search_docs]) tool_node = ToolNode([search_docs]) checkpointer = InMemorySaver() def call_model(state: MessagesState): return {"messages": [model.invoke(state["messages"])]} def should_continue(state: MessagesState): last = state["messages"][-1] return "tools" if getattr(last, "tool_calls", None) else END builder = StateGraph(MessagesState) builder.add_node("model", call_model) builder.add_node("tools", tool_node) builder.add_edge(START, "model") builder.add_conditional_edges("model", should_continue) builder.add_edge("tools", "model") graph = builder.compile(checkpointer=checkpointer) ``` `add_conditional_edges`で分岐を書き、`tools`から`model`へEdgeを戻すことでループが閉じます。`create_agent`で足りるならグラフを書く理由はありません。逆に、ツール実行の前に独自の検証Nodeを挟む、失敗時に別ルートへ逃がす、といった制御が必要になった時点でStateGraphへ降ります。この「降りられる」ことが、v1.0の階層構造が持つ実務上の価値です。 ## 使い分けの判断基準：LangChain先行とLangGraph移行の境界 ### LangChainだけで足りる要件 処理が直線で、1回のリクエストが数秒で終わり、途中で人が介入しないなら、LangChainだけで完結します。具体的には、単発のRAG（検索して1回答える）、要約、分類、定型のプロンプト連結です。ツールを数個持つ標準的なエージェントも`create_agent`の範囲に収まります。ここでStateGraphを手書きすると、得るものがないままNodeとEdgeの管理コストだけが増えます。検索と回答生成だけが主題なら、索引と検索に守備範囲を絞った[LlamaIndexとは？RAG構築の仕組み・LangChainとの違いと採用判断](https://www.issoh.co.jp/tech/details/15836/)のような別系統のフレームワークも選択肢になります。 ### LangGraphに降りるべき要件 次のいずれかに当てはまるなら、グラフを自分で組む価値があります。 - ツール実行と再考のループを、独自の停止条件や検証工程つきで回したい - 複数エージェントを役割分担させ、Stateを共有しながら協調させたい（[Agentic RAGのアーキテクチャと構成要素を詳しく解説](https://www.issoh.co.jp/tech/details/8079/)で扱う多段検索もこの形） - 人の承認を挟んで実行を中断・再開する（human-in-the-loop） - 数分から数時間かかる処理を、プロセス再起動を跨いで再開したい - 失敗したNodeだけをリトライし、他の経路へ逃がしたい ### 採用すべきでない場面 「将来マルチエージェントにするかもしれないから最初からLangGraphで書く」という設計は勧めません。v1.0の階層は`create_agent`からStateGraphへ後から降りられるように作られており、先回りしてグラフを書いても移行コストは下がりません。むしろ、State設計とEdgeの分岐が初期から複雑化し、プロンプトやツールの改善サイクルが遅くなります。ループが実際に必要になった時点で降りるのが、2026年時点で合理的な順序です。実際にグラフを組む段になったら、StateGraphの最小実装からチェックポインタでの永続化、interruptによる承認待ちまでを追った[LangGraphでAIエージェントを実装する手順](https://www.issoh.co.jp/tech/details/17447/)を手順書として使えます。 もう一つ、LangGraph単体をLangChainの代替として選ぶ判断も、多くの案件では過剰です。LangGraph単体で手に入るのは`langchain-core`の最小抽象（メッセージ型・`BaseChatModel`・`@tool`）までで、`init_chat_model`によるモデル差し替えや`create_agent`のループ実装、各プロバイダのインテグレーション導線はアプリ側が担うことになります。プロバイダを1社に固定し、抽象化レイヤーを自前で持つと決めたチームだけが選ぶ構成です。 ## 旧記事のコードで詰まる点：v1.0移行で変わったAPI 比較記事の多くは概念の説明で終わりますが、実際に手を動かすと引っかかるのは移行済みAPIです。2024年〜2025年前半の解説をそのまま写すと動きません。 ### create\_react\_agent から create\_agent への置換 旧来のエージェント生成は`langgraph.prebuilt.create_react_agent`でした。LangChain 1.0でこの役割は`langchain.agents.create_agent`へ移り、`create_react_agent`は非推奨（v2.0で削除予定）になっています。LangGraphのパッケージからエージェントを丸ごと作る記述を見かけたら、v1.0以前のコードです。ただし非推奨なのは`create_react_agent`だけで、`langgraph.prebuilt`モジュール自体は現役です。後述のコード例で使う`ToolNode`や`tools_condition`はここから読み込みます。 ### カスタマイズの入口：Middlewareの6フック v1.0の`create_agent`は、エージェントループの各地点にフックを差せます。`before_agent`、`before_model`、`wrap_model_call`、`wrap_tool_call`、`after_model`、`after_agent`の6箇所です。組み込みのMiddlewareとして`HumanInTheLoopMiddleware`（人手承認）、`SummarizationMiddleware`（履歴の要約圧縮）、`PIIMiddleware`（個人情報の秘匿）が提供されます。以前ならStateGraphを自作して割り込ませていた処理の一部が、グラフを書かずに実現できるようになったということです。「ループを挟みたいから即LangGraph」と判断する前に、Middlewareで足りないかを確認してください。 ### LangGraph 1.2で入った運用機能 2026年5月11日のLangGraph 1.2は、本番運用寄りの機能が中心です。`add_node()`にNode単位のタイムアウトを直接指定できるようになりました（対応は非同期Nodeのみで、同期Nodeでは発火しません）。`error_handler=`を渡せば、リトライを使い切った後の回復関数を登録できます。回復関数は型付きの`NodeError`を受け取り、`Command`を返してStateを更新しながら別Nodeへ迂回する挙動です。DeltaChannelは各ステップで蓄積値を丸ごと再シリアライズせず、差分だけを保存します。長い会話履歴を持つエージェントでチェックポイントが肥大する問題への対処です。ほかにgraceful shutdown（実行中のsuperstep完了後に再開可能なcheckpointを保存する）とstreaming v3も入りました。バージョンの動きは速いため、採用前に公式リリースノートで最新版を確認してください（2026年7月10日時点でLangGraphは1.2.9、LangChainは1.3.13、いずれもPython 3.10以上が必要）。 ## よくある質問 ### LangGraphを使うならLangChainは不要ですか？ 技術的には不要です。公式ドキュメントが「LangGraphを使うためにLangChainを使う必要はない」と明記しており、LangGraphの依存は`langchain-core`まで。ただし実務では、モデル抽象・ツール定義・`create_agent`を提供するLangChainと併用する構成が標準になっています。片方を捨てる二択ではなく、どの層まで自分で書くかの判断だと考えてください。 ### LangChainのチェーン（LCEL）はもう古いのですか？ 直線的な処理では今も現役です。v1.0で整理されたのはレガシーなチェーン実装や`AgentExecutor`系で、これらは`langchain-classic`へ移りました。エージェントを新規に作るなら`create_agent`が標準の入口です。既存のLCEL資産をv1.0へ移す場合は、まず`langchain-classic`のどのモジュールに該当するかを確認してから移行してください。関連する内容として、[PydanticAI](https://www.issoh.co.jp/tech/details/6743/)もご覧ください。 ### どちらから学ぶべきですか？ LangChainの`create_agent`からです。エージェントループ・ツール呼び出し・モデル抽象という土台を先に理解しないと、StateGraphのNodeに何を書くべきかが決まりません。LangGraphはループを自分で設計する必要が出たときに降りる層で、最初の学習対象には抽象度が低すぎます。v1.0で入った要素を先に把握したい場合は[LangChain v1.0の概要と新機能](https://www.issoh.co.jp/tech/details/9663/)から読んでください。 ### LangGraphで作ったエージェントはどうデプロイしますか？ 自前のサーバーに載せる方法と、LangChain Inc.が提供するLangGraph Platform（旧LangGraph Cloud）を使う方法があります。後者は永続化やタスクキューを含む実行基盤と、Studioによるグラフの可視化つき。手順と料金は[LangGraph Platform（旧 LangGraph Cloud）とは？デプロイ手順・Studio・料金を実践解説【2026年版】](https://www.issoh.co.jp/tech/details/6175/)にまとめています。 ### TypeScript／JavaScriptでも同じ構成ですか？ 同じです。LangGraph.jsとLangChain.jsが対応し、StateGraphとNode・Edgeの考え方はPython版と共通です。Node.js側の入門は[LangChain.jsとは？その概要と特徴を詳しく解説](https://www.issoh.co.jp/tech/details/3590/)を参照してください。ただしバージョンの進み方はPython版と一致しないため、APIは各言語のリリースノートで確認が必要です。 ## 関連記事 - [LangChain v1.0の概要と新機能：v0.xからの刷新点・新要素を含むアップデート全体像](https://www.issoh.co.jp/tech/details/9663/) - [LangGraph Platform（旧 LangGraph Cloud）とは？デプロイ手順・Studio・料金を実践解説【2026年版】](https://www.issoh.co.jp/tech/details/6175/) - [LangGraphのTool Callingとは？その仕組みと基本概念](https://www.issoh.co.jp/tech/details/5428/) - [Agentic RAGのアーキテクチャと構成要素を詳しく解説](https://www.issoh.co.jp/tech/details/8079/) - [LangChain.jsとは？その概要と特徴を詳しく解説](https://www.issoh.co.jp/tech/details/3590/) --- 出典: [LangChainとLangGraphの違い｜v1.0で逆転した関係と使い分け]()（株式会社一創）