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からの刷新点・新要素を含むアップデート全体像で個別に扱っています。
処理構造の違い：一方向のチェーンと循環するグラフ
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とは？その仕組みと基本概念で詳しく扱っています。
コードで見る違い：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との違いと採用判断のような別系統のフレームワークも選択肢になります。
LangGraphに降りるべき要件
次のいずれかに当てはまるなら、グラフを自分で組む価値があります。
- ツール実行と再考のループを、独自の停止条件や検証工程つきで回したい
- 複数エージェントを役割分担させ、Stateを共有しながら協調させたい（Agentic RAGのアーキテクチャと構成要素を詳しく解説で扱う多段検索もこの形）
- 人の承認を挟んで実行を中断・再開する（human-in-the-loop）
- 数分から数時間かかる処理を、プロセス再起動を跨いで再開したい
- 失敗したNodeだけをリトライし、他の経路へ逃がしたい
採用すべきでない場面
「将来マルチエージェントにするかもしれないから最初からLangGraphで書く」という設計は勧めません。v1.0の階層はcreate_agentからStateGraphへ後から降りられるように作られており、先回りしてグラフを書いても移行コストは下がりません。むしろ、State設計とEdgeの分岐が初期から複雑化し、プロンプトやツールの改善サイクルが遅くなります。ループが実際に必要になった時点で降りるのが、2026年時点で合理的な順序です。実際にグラフを組む段になったら、StateGraphの最小実装からチェックポインタでの永続化、interruptによる承認待ちまでを追ったLangGraphでAIエージェントを実装する手順を手順書として使えます。
もう一つ、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もご覧ください。
どちらから学ぶべきですか？
LangChainのcreate_agentからです。エージェントループ・ツール呼び出し・モデル抽象という土台を先に理解しないと、StateGraphのNodeに何を書くべきかが決まりません。LangGraphはループを自分で設計する必要が出たときに降りる層で、最初の学習対象には抽象度が低すぎます。v1.0で入った要素を先に把握したい場合はLangChain v1.0の概要と新機能から読んでください。
LangGraphで作ったエージェントはどうデプロイしますか？
自前のサーバーに載せる方法と、LangChain Inc.が提供するLangGraph Platform（旧LangGraph Cloud）を使う方法があります。後者は永続化やタスクキューを含む実行基盤と、Studioによるグラフの可視化つき。手順と料金はLangGraph Platform（旧 LangGraph Cloud）とは？デプロイ手順・Studio・料金を実践解説【2026年版】にまとめています。
TypeScript／JavaScriptでも同じ構成ですか？
同じです。LangGraph.jsとLangChain.jsが対応し、StateGraphとNode・Edgeの考え方はPython版と共通です。Node.js側の入門はLangChain.jsとは？その概要と特徴を詳しく解説を参照してください。ただしバージョンの進み方はPython版と一致しないため、APIは各言語のリリースノートで確認が必要です。
