社内の注文照会エージェントを作り、モデルと検索ツールまではつながった。
ところが「重要な処理だけ担当者の承認を挟みたい」「障害後に保存した状態から再開したい」となった瞬間、LangChainのまま進めるか、LangGraphを直接使うかで設計会議が止まります。
LangGraphとLangChainの違いは、2026年10月4日時点では「標準的なエージェントを素早く組み立てる高水準フレームワーク」と「状態を持つ実行フローを細かく制御する低水準ランタイム」の違いです。
検索意図への直答：モデル、ツール、プロンプト、ミドルウェアを標準APIで組み合わせたいならLangChainが第一候補です。独自の状態、分岐、反復、停止・再開、人手承認を実行フローとして設計したいならLangGraphを直接使います。
- LangChain：
create_agentを中心に、一般的なツール利用エージェントを短く組み立てる - LangGraph：
StateGraphなどで、状態と遷移をノード単位に制御する - 併用：LangChainのエージェントはLangGraph上で動くため、両者は競合というより高水準と低水準の関係にある
迷ったらLangChainから始め、標準のエージェントループでは表現しにくい制御が出た部分だけLangGraphへ降りるのが実務的です。単発のモデル呼び出しや固定変換だけなら、どちらも使わず各社SDKと通常のアプリケーションコードで足りる場合もあります。
30秒で選ぶなら、見るべきは「複雑さ」ではなく制御権
「処理が複雑そうだからLangGraph」という選び方では、必要以上に設計を重くしがちです。判断基準は、アプリ側がどこまで実行順序と状態を所有したいかです。
| 要件 | 第一候補 | 判断理由 |
|---|---|---|
| モデルに複数のツールを選ばせたい | LangChain | create_agentで標準的なモデル・ツールループを組みやすい |
| プロンプト、モデル、出力整形を順につなぎたい | LangChainのコンポーネント | Runnableとして小さな処理を合成しやすい |
| 条件分岐や戻り先をコードで固定したい | LangGraph | State、Node、Edgeとして遷移を明示できる |
| 承認待ちで止め、後から再開したい | LangGraph、またはLangChainの承認ミドルウェア | 任意位置の制御ならLangGraph、ツール実行前の標準承認ならLangChainでも対応できる |
| 標準エージェントの一部分だけ独自制御したい | 併用 | LangGraphのノード内でLangChainのモデルやツールを利用できる |
| 単発のモデル呼び出しだけ | どちらも不要な場合がある | 抽象化を増やすより、提供元SDKで十分なことがある |
- LangChainコンポーネント：モデル、プロンプト、ツール、Retriever、出力整形
- LangChain標準エージェント：
create_agentで一般的なツール利用ループを構成 - LangGraph直接利用：独自State、Node、Edge、割り込み、再開を構成
上から下へ置き換える関係ではなく、必要な制御粒度に応じて利用する層を選びます。
AIエージェント全体の選択肢を先に俯瞰したい場合は、AIエージェント構築ツール比較ガイドもあわせて確認してください。
「チェーン対グラフ」だけでは現在の違いを説明できない
LangChainは高水準のエージェントフレームワーク
LangChain公式は、現在のLangChainをエージェントフレームワークと位置づけています。中心となるcreate_agentは、モデル、ツール、システムプロンプト、ミドルウェアをまとめ、モデルが必要なツールを呼びながら完了まで進む標準ループを提供します。モデルプロバイダーの違いを吸収するインターフェースや、ツール定義、構造化出力、ガードレールなどを同じ考え方で扱えるのが強みです。
歴史的にLangChainは「コンポーネントを鎖のようにつなぐ」説明で広まりました。しかし、公式のLangChain v1移行ガイドでは、旧来のLLMChainやConversationChainなどはlangchain-classicへ移されています。2026年の比較で「LangChainは直線的なチェーンしか扱えない」と書くのは不正確です。
LangGraphは状態を持つオーケストレーションランタイム
LangGraphは、長時間動くステートフルなエージェント向けの低水準オーケストレーションフレームワーク兼ランタイムです。共有状態をState、処理をNode、遷移をEdgeとして表し、決定論的な業務ロジックとLLMによる判断を同じグラフに置けます。公式のLangGraph overviewは、耐久実行、ストリーミング、人手介入、永続化を主要な能力として挙げています。
LangGraphの公式例はLangChainのモデルやツールをよく使いますが、LangChainは必須ではありません。各社SDKや独自関数もNodeに置けます。Graph APIのほかにFunctional APIもあります。
現在はLangChainの下でLangGraphが動く
公式の製品レイヤー解説では、LangChainをエージェントフレームワーク、LangGraphをオーケストレーションランタイムとして区別しています。LangChainのエージェントはLangGraph上に構築されるため、二者択一ではありません。
- 一方向の合成：入力 → 前処理 → モデル → 出力整形
- LangChain標準エージェント：モデル → ツール選択 → ツール結果 → モデル、を完了まで反復
- LangGraph直接利用：状態を読み、条件分岐、ループ、承認待ち、再開先をアプリ側が明示
LangGraphとLangChainの違い7選
| 比較軸 | LangChain | LangGraph |
|---|---|---|
| 1. 主な役割 | エージェントの部品と標準ハーネスを提供 | 状態を持つ実行フローを制御 |
| 2. 抽象度 | 高水準。少ない構成要素から始めやすい | 低水準。制御の代わりに設計項目が増える |
| 3. 中心API | create_agent、モデル、ツール、ミドルウェア |
StateGraph、State、Node、Edge、interrupt() |
| 4. フロー制御 | 標準的なエージェントループを任せやすい | 分岐、反復、再試行、並列、終了条件を明示しやすい |
| 5. 状態と再開 | 標準エージェントでは内部のLangGraph能力を利用 | チェックポイントとスレッドを直接設計できる |
| 6. 人手介入 | ミドルウェアでツール実行前の承認を設定できる | 任意ノードで停止し、入力後に再開できる |
| 7. 向く状況 | 標準パターンを速く立ち上げたい | 実行順序と状態をアプリ要件どおりに所有したい |
1. 役割：部品と標準ハーネスか、実行制御か
LangChainはモデルやツールを共通インターフェースで組み、一般的なエージェントを立ち上げます。LangGraphは「次にどこへ進むか」「何を状態に残すか」を制御します。
2. 抽象度：速い着手か、細かな設計か
LangChainは標準のエージェントループを提供します。LangGraphは状態スキーマや遷移の設計が増える一方、処理経路をレビューしやすくなります。独自制御の必要量で選びます。
3. API：create_agentか、State・Node・Edgeか
LangChainではモデル、ツール、プロンプト、ミドルウェアをcreate_agentへ渡します。LangGraphではState、Node、Edgeを定義してコンパイルするため、フローが暗黙のループに隠れにくくなります。
4. フロー：モデルに任せる範囲が違う
一般的なツール選択はLangChainに任せられます。「結果が不足なら検索へ戻る」「規程に該当したら人へ渡す」のように、業務規則で遷移先を固定するならLangGraphが自然です。
5. 状態：会話履歴だけでなく業務状態を持つか
LangGraphのStateには、メッセージだけでなく判定結果、取得済みデータ、承認状態、エラー種別などを保持できます。ただし、状態を定義しただけで永続化されるわけではありません。公式のPersistenceガイドにあるとおり、短期のスレッド状態にはcheckpointer、スレッドをまたぐ長期データにはstoreを使い分けます。
6. 人手介入：標準承認か、任意位置の停止か
「送信ツールを呼ぶ前に承認する」といった標準的な用途はLangChainのHuman-in-the-loopミドルウェアでも構成できます。生成文を見せて編集してもらい、その値で別ルートへ進むなど、停止位置と再開後の遷移を細かく決めるならLangGraphのinterrupt()が向きます。「人手介入があるから必ずLangGraph」とは限りません。
7. 学び方：まず高水準、必要なら低水準へ
初めてならLangChainでモデル・ツール・メッセージの流れを理解します。承認、障害復旧、複数経路が要件として確定しているなら、LangGraphで状態から設計します。既存のLangChain部品はNode内で再利用できます。
| モデル・ツール・プロンプト | LangChainが標準化 |
|---|---|
| 標準的なエージェントループ | LangChainのcreate_agentが担当 |
| 独自の状態遷移・停止・再開 | LangGraphを直接設計 |
| トレース・評価 | 別製品のLangSmithを必要に応じて接続 |
使い分けを決める5つの質問
ツール名から選ばず、次の順で要件を確認すると判断しやすくなります。
- モデルがツールを選ぶ標準ループで足りるか。 足りるならLangChainを優先します。
- 次の処理を業務ルールで固定する必要があるか。 複数の条件分岐や戻り先を持つならLangGraphが候補です。
- プロセスをまたいで状態を復元する必要があるか。 必要ならcheckpointerと
thread_idを含む永続化設計が要ります。 - 人が確認する位置はツール実行前だけか。 標準承認ならLangChain、任意位置の停止や編集ならLangGraphを検討します。
- 独自制御の範囲は一部分か。 一部分なら、全体を作り直さずLangChainとLangGraphを併用できます。
事例区分：想定シナリオ
社内規程を検索して回答するだけならLangChainのコンポーネントで十分です。必要に応じて検索ツールを選ばせるなら
create_agentを使います。回答の根拠が不足したら再検索へ戻り、外部操作の前に担当者承認を挟み、後日同じ案件を再開するならLangGraphを直接設計します。
固定変換だけ → 提供元SDKまたは通常コード
標準的なツール利用 → LangChain
独自の分岐・状態・再開 → LangGraph
標準エージェントと独自制御の両方 → LangChainとLangGraphを併用
同じ業務で比べる3つの実装例
ここでは注文照会を題材に、固定処理、標準エージェント、承認付きグラフの順で構造を比較します。コードは公式の現行APIを基準にした最小構成です。
例1：固定処理ならLangChainのRunnableを合成する
入力を正規化してチケット文面へ変換するだけなら、状態グラフは不要です。
動作環境：Python 3.10以上、langchain-core
from langchain_core.runnables import RunnableLambda
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
def normalize_order(data: dict) -> dict:
return {
"order_id": data["order_id"].strip(),
"requires_review": bool(data["requires_review"]),
}
def build_ticket(data: dict) -> str:
review = "要確認" if data["requires_review"] else "自動処理可"
return f"注文 {data['order_id']} / {review}"
pipeline = RunnableLambda(normalize_order) | RunnableLambda(build_ticket)
result = pipeline.invoke({"order_id": " A-001 ", "requires_review": True})
print(result)ポイント：処理順が固定され、途中停止や分岐を業務状態として保存しないなら、この程度の合成で読みやすさを保てます。
例2：標準的なツール利用ならLangChainのcreate_agent
モデルが質問内容を見て注文検索ツールを使う構成です。モデル名は環境変数に置き、鍵をコードへ埋め込みません。
動作環境：Python 3.10以上、langchainと利用するモデルプロバイダーの公式連携パッケージ
import os
from langchain.agents import create_agent
from langchain.tools import tool
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
@tool
def lookup_order(order_id: str) -> str:
"""承認済みの業務システムから注文状態を取得する。"""
return f"{order_id}: 確認待ち"
agent = create_agent(
model=os.environ["LANGCHAIN_MODEL"],
tools=[lookup_order],
system_prompt="注文照会に必要な場合だけツールを使ってください。",
)
result = agent.invoke({
"messages": [
{"role": "user", "content": "注文A-001の状態を確認して"}
]
})
print(result["messages"][-1].content)ポイント：標準的なツール選択を任せる段階では、独自グラフを先に書く必要はありません。認証、権限、タイムアウト、エラー処理は業務要件に合わせて追加してください。
例3：任意位置で承認待ちにするならLangGraph
入力フラグで処理を分け、確認が必要な案件だけinterrupt()で止めます。再開には同じthread_idを使います。
動作環境：Python 3.10以上、langgraph
from typing import Literal, TypedDict
from langgraph.checkpoint.memory import InMemorySaver
from langgraph.graph import END, START, StateGraph
from langgraph.types import Command, interrupt
# 注意: 本番環境で使用する前に、必ずテスト環境で動作確認してください。
class ReviewState(TypedDict):
request: str
requires_review: bool
status: str
def inspect_request(state: ReviewState) -> dict:
return {"status": "確認済み"}
def choose_path(state: ReviewState) -> Literal["review", "auto"]:
return "review" if state["requires_review"] else "auto"
def review(state: ReviewState) -> dict:
approved = interrupt({"question": "この処理を承認しますか？"})
return {"status": "承認" if approved else "却下"}
def auto(state: ReviewState) -> dict:
return {"status": "自動処理可"}
builder = StateGraph(ReviewState)
builder.add_node("inspect", inspect_request)
builder.add_node("review", review)
builder.add_node("auto", auto)
builder.add_edge(START, "inspect")
builder.add_conditional_edges(
"inspect", choose_path, {"review": "review", "auto": "auto"}
)
builder.add_edge("review", END)
builder.add_edge("auto", END)
graph = builder.compile(checkpointer=InMemorySaver())
config = {"configurable": {"thread_id": "review-example"}}
graph.invoke(
{"request": "注文A-001", "requires_review": True, "status": "受付"},
config,
)
result = graph.invoke(Command(resume=True), config)
print(result["status"])ポイント：InMemorySaverは学習用です。公式ドキュメントは、プロセス再起動をまたぐ本番用途では永続チェックポインターを使うよう案内しています。また、割り込みを含むノードは再開時に先頭から再実行されるため、割り込み前の外部送信やレコード追加は避けるか、冪等に設計してください。
LangGraphのStateGraphをさらに掘り下げる場合は、LangGraph完全ガイド｜StateGraph実装とv1.2新機能を参照してください。LangChain側の実装は、LangChainでAIエージェントを構築する完全ガイド【2026年最新版】で詳しく扱っています。
併用するときはLangGraphを骨格、LangChainを部品にする
併用時は、LangGraphのNodeにLangChainのモデル、ツール、Retriever、あるいはcreate_agentで作ったエージェントを置きます。LangGraphは「次にどのNodeを動かすか」を担当し、各Node内のLLM呼び出しはLangChainに任せる構成です。
たとえば、規程検索エージェント、回答評価処理、人間の承認、外部システム更新を別Nodeにします。検索エージェントの内部はLangChainで短く保ち、評価が不十分なら検索へ戻すEdgeと、承認後だけ更新へ進むEdgeをLangGraphに持たせます。この分担なら、モデル統合と業務制御を同じ層へ押し込まずに済みます。
LangGraph：受付Node → 検索Node → 評価Node → 承認Node → 更新Node
LangChain：検索Node内のRetriever・モデル、またはcreate_agentを担当
チェックポイント：状態を保存 → 割り込み → 人間が承認 → 同じスレッドを再開
LangGraph以外の選択肢も含めて比較したい場合は、Agents SDKか、LangGraphか｜2026年のフレームワーク選定指針も判断材料になります。
2026年10月4日時点で押さえる現行仕様
LangChainの現行公開版は1.4.3
PyPIではLangChain 1.4.3が2026年9月28日に公開された現行版として表示されています。Python要件は3.10以上4未満です。固定された古い記事のimport文をそのまま移さず、langchain.agents.create_agentと現行の連携パッケージを公式ドキュメントで確認してください。
LangGraphの現行公開版は1.2.12
PyPIではLangGraph 1.2.12が2026年9月21日に公開された現行版です。公式リリースでは、interrupt()へ再開時入力のresponse_schemaを指定する機能などが記録されています。直近2週間の更新まで確認すると、人手介入は現在もLangGraphの主要な改善領域だと分かります。
create_react_agentではなくcreate_agentを基準にする
LangGraph v1ではlanggraph.prebuilt.create_react_agentが非推奨となり、LangChainのcreate_agentが推奨されています。古いサンプルを読むときは、どの世代のAPIかを先に確認しましょう。なお、LangGraphを直接使うStateGraphまで非推奨になったわけではありません。
LangSmithは別の観測・評価プラットフォーム
LangSmithはトレース、デバッグ、評価、プロンプト管理、デプロイを扱う別製品です。LangChainやLangGraphのコードに接続できますが、LangGraphをインストールするだけでクラウドのGUIやマネージド実行環境が自動的に付くわけではありません。ライブラリ選定と運用基盤選定は分けて考えてください。
選び方を誤りやすい4パターン
失敗1：エージェントなら最初からすべてLangGraphで書く
❌ よくある判断：ツールを使う時点でStateGraphを自作する。
⭕ 見直し方：標準的なモデル・ツールループならLangChainのcreate_agentから始める。独自遷移が要件になった部分だけLangGraphへ移す。
状態項目とEdgeを増やすほど、テスト対象も増えます。制御権が不要な部分まで低水準で書かないことがポイントです。
失敗2：LangChainとLangGraphを排他的な選択肢と考える
❌ よくある判断：LangGraphへ移るならLangChainのツールやRetrieverを捨てる。
⭕ 見直し方：LangGraphのNode内で既存のLangChainコンポーネントを再利用する。
役割が異なるため、置き換えより責任分担で考える方が自然です。
失敗3：InMemorySaverで障害復旧までできると思う
❌ よくある判断：メモリ上のcheckpointerを本番の永続化として扱う。
⭕ 見直し方：開発用と本番用の保存先を分け、再起動後に必要な状態が戻るかをテストする。
InMemorySaverとMemorySaverはプロセス再起動でチェックポイントを失います。永続化は明示的な設計項目です。
失敗4：interruptの前に非冪等な外部操作を置く
❌ よくある判断：レコード作成や外部送信の後で承認待ちにし、再開時の再実行を考慮しない。
⭕ 見直し方：承認を外部操作より前へ置くか、外部操作を別Nodeへ分け、同じ入力が来ても重複しない設計にする。
Interrupts公式ガイドは、再開時にNodeの先頭から再実行される点と、副作用を冪等にする必要性を説明しています。
よくある質問
Q1. LangGraphとLangChainの一番大きな違いは何ですか？
LangChainはモデル、ツール、ミドルウェアを使って標準的なエージェントを組み立てる高水準フレームワークです。LangGraphは状態、分岐、停止、再開を低水準で制御するランタイムです。
Q2. LangGraphを使うにはLangChainが必須ですか？
必須ではありません。LangGraphは単体で利用でき、各社SDKや独自関数をNodeに置けます。ただし、公式例ではモデルやツールの統合にLangChainコンポーネントを使うことが多く、併用は自然です。
Q3. LangChainとLangGraphは併用できますか？
できます。LangGraphで全体の遷移を制御し、各Node内でLangChainのモデル、Retriever、ツール、標準エージェントを使う構成が可能です。
Q4. LangChainのcreate_agentとLangGraph直接利用の違いは何ですか？
create_agentは一般的なモデル・ツールループを高水準APIとして提供します。LangGraphを直接使う場合は、State、Node、Edge、チェックポイント、割り込み位置をアプリ側が定義します。
Q5. LangChainとLangGraphとLangSmithの違いは何ですか？
LangChainはエージェントフレームワーク、LangGraphはオーケストレーションランタイム、LangSmithはトレースや評価などを扱うプラットフォームです。LangSmithはLangChainやLangGraph以外のアプリにも接続できます。
Q6. RAGだけならどちらを選ぶべきですか？
文書を検索して回答する固定的なRAGなら、LangChainのRetrieverやRunnableで足りることが多いでしょう。検索結果の評価、不足時の再検索、複数Retrieverへの分岐、承認後の再開まで制御するならLangGraphが候補です。
Q7. 人間の承認があるならLangGraphが必要ですか？
ツール実行前の標準的な承認はLangChainのHuman-in-the-loopミドルウェアでも設定できます。任意のNodeで止め、状態を編集し、承認結果で遷移先を変えたい場合はLangGraphを直接使う方が設計しやすくなります。
Q8. マルチエージェントなら必ずLangGraphですか？
必ずではありません。既成のハーネスで要件を満たせる場合もあります。複数エージェント間の受け渡し、共有状態、並列実行、失敗時の戻り先を独自に決めたいときにLangGraphの価値が高まります。
Q9. 既存のLangChainコードはLangGraphで再利用できますか？
モデル、ツール、Retriever、RunnableなどはNode内で再利用できます。ただし、旧来のLLMChainなどはlangchain-classicへ移っているため、現行v1へ寄せるか互換パッケージを使うかを先に判断してください。
Q10. 初心者はどちらから学ぶべきですか？
まずLangChainでモデル、ツール、メッセージ、エージェントループを理解するのが近道です。その後、状態遷移、チェックポイント、割り込みが必要になった時点でLangGraphを学ぶと、抽象化の違いを捉えやすくなります。
運営元 Uravation よりAIエージェントを構想から本番運用まで進める順番と、体制・KPIの決め方をまとめた資料を無料で公開しています。 AIエージェント導入ロードマップを受け取る（無料）
参考・出典
- Runtimes, frameworks, and harnesses — LangChain公式（参照日：2026年10月4日）
- LangChain overview — LangChain公式（参照日：2026年10月4日）
- LangGraph overview — LangChain公式（参照日：2026年10月4日）
- LangChain v1 migration guide — LangChain公式（参照日：2026年10月4日）
- Persistence — LangChain公式（参照日：2026年10月4日）
- Interrupts — LangChain公式（参照日：2026年10月4日）
- langchain on PyPI — Python Package Index（参照日：2026年10月4日）
- langgraph on PyPI — Python Package Index（参照日：2026年10月4日）
- Release langgraph 1.2.12 — LangChain公式GitHub（公開日：2026年9月21日、参照日：2026年10月4日）
結論と次の一歩
LangGraphとLangChainの違いは、機能の多さではなく抽象度と制御権です。標準的なエージェントを速く組むならLangChain、独自の状態遷移や停止・再開を設計するならLangGraph、両方の要件があるなら併用します。
- 処理フローを一文で書く：「モデルがツールを選べば終わる」のか、「条件で戻る・止まる・再開する」のかを切り分けます。
- 最小構成を選ぶ：標準ループなら
create_agent、固定処理ならRunnableまたは通常コードで始めます。 - 状態を設計する：独自制御が必要なら、Stateに残す値、Nodeの責任、Edgeの終了条件、承認前後の副作用を明文化してからStateGraphへ進みます。
あわせて読みたい：
- LangGraph完全ガイド｜StateGraph実装とv1.2新機能
- LangChainでAIエージェントを構築する完全ガイド【2026年最新版】
- Agents SDKか、LangGraphか｜2026年のフレームワーク選定指針
この記事を読んで導入イメージが固まってきた方へ
UravationではAIエージェント導入の研修・コンサルを行っています。
この記事はAIgent Lab編集部がお届けしました。
