LangGraphとは？仕組みと使い方、LangChainとの違いと本番の注意

公開：2026年10月06日更新：2026年10月06日編集：inovie株式会社監修：桒谷一成

LangGraphとは、AIエージェントの処理を「状態」と「グラフ」で組み立て、長く動かすためのPythonとJavaScriptのライブラリです。途中経過を保存する、人の承認を待つあいだ処理を止める、承認後に同じ場所から再開する、といった動きをコードで細かく決められます。この記事では、LangGraphの考え方（状態・ノード・エッジ・条件分岐・ループ）、チェックポイントによる保存と人の承認を挟む仕組み、2026年10月7日に最新版で動作を確かめた最小のコード例を説明します。あわせて、LangChainとの違い、DifyやほかのAgent SDKとの使い分け、本番で使うときの注意もまとめます。AIエージェントそのものの仕組みは、AIエージェントとは？仕組みとできること、作り方と導入の進め方で解説しています。

LangGraphとは：状態を持つAIエージェントの実行基盤

LangGraphは、LangChain社が開発しているオープンソースのライブラリです。GitHubの langchain-ai/langgraph でMITライセンスのもとで公開されています。2026年10月7日時点の最新版は、Python版が10月6日公開の1.2.14、JavaScript版（@langchain/langgraph）が1.4.19です。Python版はPython 3.10以降で動きます。LangChainの機能と使い方は、LangChainとは？主な機能とPythonでの使い方で解説しています。

公式ドキュメントは、LangGraphを「長時間動き、状態を持つエージェントを作り、管理し、デプロイするための低レベルのオーケストレーション（処理の進行を制御する）フレームワーク兼ランタイム」と説明しています。ここでいう低レベルとは、指示文（プロンプト）やエージェントの構成を決めた形で用意するのではなく、処理の順番や分岐を開発者が自分で書くという意味です。

LangGraphが特に役立つのは、次のような場面です。

決まった処理とAIの判断を混ぜたい：入力の確認や計算はコードで確実に行い、文章の作成や次の作業の判断だけをモデルに任せる、という組み合わせを1つのグラフで書けます。
途中で止めて再開したい：処理の状態を保存しておけるので、障害で止まった処理を最後に保存した地点から再開したり、人の承認を何時間も待ったりできます。
処理の流れを後から追いたい：チェックポインターを使うと段階ごとの状態が残るため、どの段階で誤ったかを調べやすくなります。

LangGraphの考え方：状態・ノード・エッジ・条件分岐・ループ

LangGraphでは、処理を「グラフ」として書きます。グラフの部品は次の5つです。

状態（State）

状態は、グラフ全体で受け渡すデータの入れ物です。TypedDict やPydanticのモデルで、どんな項目を持つかを決めます。各ノードは状態を受け取り、変えたい項目だけを返します。返された値をどう反映するかは項目ごとに決められ、何も指定しなければ上書きされます。会話の履歴のように追記したい項目には、追記用の関数（reducer）を指定します。会話の履歴を持つ状態は MessagesState として用意されています。

ノード（Node）とエッジ（Edge）

ノードは、状態を受け取って処理をするPythonの関数です。モデルを呼ぶ処理も、データベースを読む処理も、ただの計算もノードになります。エッジはノードどうしをつなぐ線で、ある処理が終わったら次にどのノードへ進むかを表します。グラフの入口は START、出口は END という決まった名前で表します。

条件分岐とループ

条件付きのエッジ（add_conditional_edges）を使うと、状態を見て次のノードを選べます。モデルがツールを呼ぶと判断したらツールのノードへ、そうでなければ終了へ進む、という分岐がその代表です。分岐の先を前のノードに戻せばループになり、「回答を作る、確認する、直す」のくり返しも書けます。

ループが止まらない事態に備えて、1回の実行で進める段階の数には上限（recursion limit）があります。公式ドキュメントによると、バージョン1.0.6以降の既定値は1000で、超えると GraphRecursionError で止まります。業務では、上限に頼らず「3回直しても承認されなければ人に戻す」のような終了の条件を状態に持たせておくほうが扱いやすくなります。

なお、LangGraphにはグラフとして書く「Graph API」のほかに、ふつうの関数として書く「Functional API」もあります。どちらも同じ実行の仕組みで動きます。この記事では、処理の流れが見えやすいGraph APIで説明します。

チェックポイントで状態を保存し、interruptで人の承認を挟む

LangGraphの大きな特徴が、状態の保存（永続化）と、人の判断を待つための一時停止です。

チェックポイントとスレッド

グラフをコンパイルするときにチェックポインター（checkpointer）を渡すと、LangGraphは処理が1段階進むごとに状態を保存します。保存した状態をチェックポイントと呼びます。保存した状態は、実行時に渡す thread_id ごとに分けて管理されます。同じ thread_id で呼び出せば続きから、新しい値で呼び出せば空の状態から始まります。会話の続き、人の承認待ち、障害からの再開、過去の時点からのやり直しは、どれもこのチェックポイントを使う機能です。

保存のタイミングは、実行時の durability で選べます。"sync" は次の段階に進む前に必ず保存し、"async" は次の段階と並行して保存します。"exit" は終了や一時停止のときだけ保存するため速く動きますが、実行中にプロセスが異常終了すると、途中の状態は残りません。

一方、スレッドをまたいで残したい情報（利用者の好みや、共有の知識など）は、ストア（store）という別の仕組みに保存します。チェックポイントは1つのスレッドの短期の記憶、ストアはスレッドをまたぐ長期の記憶、という分担です。

interruptで止めて、Commandで再開する

人の承認を挟むには、ノードの中で interrupt() を呼びます。呼んだ時点で処理が止まり、そのときの状態がチェックポイントに保存されます。呼び出し側には承認に必要な情報（回答案など）が返り、人が判断するまでグラフは待ち続けます。判断が決まったら、同じ thread_id で Command(resume=...) を渡して呼び出すと、渡した値が interrupt() の戻り値になり、処理が先へ進みます。

使うときは、公式ドキュメントにある次の決まりを守ります。

再開すると、ノードは先頭からやり直される：止めた行から続くのではなく、interrupt() を呼んだノードの最初から実行し直します。そのため、interrupt() より前にメール送信やデータ更新などの処理を書くと、再開のたびに同じ処理が実行されます。外部に影響する処理は、承認の後のノードに分けるか、何度実行しても結果が変わらない形にします。
interrupt() を、例外をすべて捕まえる try/except で囲まない：一時停止は特別な例外で実現しているため、捕まえてしまうと止まらなくなります。
1つのノードで複数回呼ぶときは、毎回同じ順番で呼ぶ：再開時の値は呼んだ順番で対応づけられるためです。

バージョン1.2.12以降は、interrupt() に response_schema を渡して、人が返す値の形（承認したか、コメントなど）をPydanticのモデルで検証できるようになりました。人の承認をどの操作の前に置くべきかという設計の考え方は、AIエージェントの設計パターンとは？6つの型と業務に合わせた選び方で整理しています。

LangGraphの使い方：承認を挟む最小のコード例

ここでは、問い合わせへの回答案を作り、担当者の承認を待ってから送る、という流れを書いてみます。モデルの呼び出しは省き、回答案を作る部分は文字列を組み立てるだけにしています。2026年10月7日に、langgraph 1.2.14とPython 3.14で動作を確かめました。

まず、パッケージを入れます。

pip install -U langgraph

次のコードを approval_graph.py として保存し、実行します。

from typing import Literal
from typing_extensions import TypedDict

from langgraph.checkpoint.memory import InMemorySaver
from langgraph.graph import StateGraph, START, END
from langgraph.types import Command, interrupt


class State(TypedDict):
    inquiry: str     # 問い合わせの内容
    draft: str       # 回答案
    feedback: str    # 担当者の指摘
    approved: bool   # 承認されたか
    revisions: int   # 回答案を作った回数


def write_draft(state: State):
    # 実際はここでモデルを呼び、回答案を作る
    count = state.get("revisions", 0) + 1
    draft = f"{state['inquiry']}への回答案（第{count}版）"
    if state.get("feedback"):
        draft += f"：{state['feedback']}を反映"
    return {"draft": draft, "revisions": count}


def review(state: State):
    # ここで止まり、担当者の判断を待つ
    decision = interrupt({"draft": state["draft"]})
    return {"approved": decision["approved"], "feedback": decision.get("note", "")}


def route(state: State) -> Literal["send", "write_draft", END]:
    if state["approved"]:
        return "send"
    if state["revisions"] >= 3:
        return END  # 3回直しても承認されなければ担当者に戻す
    return "write_draft"


def send(state: State):
    print("送信:", state["draft"])  # 実際は送信の処理を呼ぶ
    return {}


builder = StateGraph(State)
builder.add_node("write_draft", write_draft)
builder.add_node("review", review)
builder.add_node("send", send)
builder.add_edge(START, "write_draft")
builder.add_edge("write_draft", "review")
builder.add_conditional_edges("review", route, ["send", "write_draft", END])
builder.add_edge("send", END)
graph = builder.compile(checkpointer=InMemorySaver())

config = {"configurable": {"thread_id": "inquiry-001"}}

result = graph.invoke({"inquiry": "納期の変更"}, config)  # 承認の前で止まる
print(result["__interrupt__"][0].value)

result = graph.invoke(  # 差し戻すと、作り直して再び止まる
    Command(resume={"approved": False, "note": "新しい納期の日付"}), config
)
print(result["__interrupt__"][0].value)

result = graph.invoke(Command(resume={"approved": True}), config)  # 承認すると送信まで進む

実行すると、次のように表示されます。

{'draft': '納期の変更への回答案（第1版）'}
{'draft': '納期の変更への回答案（第2版）：新しい納期の日付を反映'}
送信: 納期の変更への回答案（第2版）：新しい納期の日付を反映

コードの要点は3つです。State で受け渡すデータを決め、add_node と add_edge で処理の順番をつなぎ、add_conditional_edges で承認・差し戻し・打ち切りの3つに分けています。差し戻すと write_draft に戻るので、この部分がループになります。interrupt() で止まったときは、invoke() の戻り値の __interrupt__ に、interrupt() に渡した値（ここでは回答案）が入ります。公式ドキュメントでは、途中経過を順に受け取れる stream_events(..., version="v3") での呼び出しを推奨していますが、invoke() も引き続き使えると明記されています。

InMemorySaver はメモリに保存するため、プログラムを終了すると状態は消えます。別のパッケージ langgraph-checkpoint-sqlite を入れ、SqliteSaver.from_conn_string("checkpoints.db") で作ったチェックポインターに替えると、状態がファイルに残ります。今回の確認でも、承認の前で止めたプログラムを一度終了し、別のプログラムから同じ thread_id で承認を渡すと、続きから送信まで進みました。

実際にモデルを使うときは、write_draft の中でモデルを呼びます。公式のクイックスタートは、LangChainの init_chat_model でモデルを指定し、ツールを呼ぶ計算エージェントを作る例を載せています。モデル名やAPIの指定方法は変わることがあるため、使う時点のクイックスタートとモデル提供元のページで確かめてください。

LangGraphとLangChainの違いと関係

LangGraphとLangChainは同じ会社が開発しているため混同されやすいのですが、役割が違います。公式ドキュメントは、LangChainを「エージェントのフレームワーク」、LangGraphを「エージェントのランタイム」と分けて説明しています。

LangChain：モデルやツールの共通の書き方と、多くの外部サービスとの連携部品を提供します。create_agent を使うと、モデルがツールを呼びながら作業するエージェントを短いコードで作れます。
LangGraph：処理の順番、状態の保存、一時停止と再開、途中経過の配信といった、エージェントを動かすための機能を提供します。

2つは上下の関係にあります。LangChain 1.0以降の create_agent はLangGraphの上に作られており、LangChainでエージェントを作ると内部ではLangGraphのグラフが動きます。一方で、LangGraphはLangChainがなくても使えます。以前LangGraphにあった create_react_agent は非推奨になり、LangChainの create_agent へ移行するよう案内されています。

人の承認も、LangChainでは create_agent に承認用のミドルウェアを付けて、ツールの実行前に承認（approve）、修正（edit）、却下（reject）などを選ぶ形で組み込めます。止めて再開する仕組み自体は、LangGraphの interrupt とチェックポイントです。そのため、ツールを呼ぶ一般的なエージェントならLangChainから始め、処理の順番や分岐を細かく決めたくなった部分だけLangGraphで書く、という進め方ができます。なお同社は、計画づくりやサブエージェント、ファイル操作の機能を持つ「Deep Agents」も、LangGraphの上に作っています。

LangChainのエージェントから、MCPサーバーのツールを使うこともできます。LangChain 1.4.0以降では、langchain[mcp] を入れると MCPAdapter でMCPサーバーのツールを読み込めます（2026年10月7日時点ではベータ版です）。MCPの仕組みと権限の考え方は、MCPとは？MCPサーバーの仕組みと社内システム連携の権限設計で解説しています。

ほかのAIエージェントの作り方との使い分け

AIエージェントを作る方法には、LangGraphのほかに、画面で組み立てる開発基盤や各社のAgent SDKがあります。主な選択肢を、どこまで自分で決めるかで比べると次のようになります。

Dify は、画面上で部品をつないでチャットボットやワークフロー、エージェントを作る開発基盤です。プログラムを書かずに試作でき、Webアプリとしてすぐ共有できます。詳しくはDifyとは？できること、使い方とクラウド版・セルフホスト版の違いで紹介しています。画面で表せる範囲の処理ならDifyのほうが早く形になり、承認の条件や例外処理を細かく分けたい場合はLangGraphが向きます。

各社のAgent SDK は、モデルの提供元などが公開しているエージェント開発用のライブラリです。2026年10月7日時点で、次のようなものがあります。

OpenAI Agents SDK：エージェント、エージェント間の引き継ぎ（handoffs）、入出力の検証（guardrails）、会話の保存（sessions）、実行の記録（tracing）を備え、人の承認を挟む仕組みもあります。
Claude Agent SDK：Claude Codeと同じツール（ファイルの読み書き、コマンド実行、Web検索）やエージェントの処理の流れを、PythonとTypeScriptから使えるライブラリです。どのツールを自動で実行し、どれに承認を求めるかを権限として設定できます。
Agent Development Kit（ADK）：Googleが公開するオープンソースのフレームワークで、Python、TypeScript、Go、Java、Kotlinに対応しています。デプロイ先として、Google CloudのCloud RunやGKEなどが案内されています。

これらのSDKは、エージェントがモデルとツールで作業を進める部分を手早く作るのに向いています。LangGraphが向くのは、処理の順番や分岐、承認の場所、途中で止めたときの保存と再開を、開発者が明示的に設計したい場合です。LangChainの公式ドキュメントも、細かな制御が必要なとき、長く動き状態を持つエージェントが必要なとき、決まった処理とAIの判断を組み合わせた複雑な処理を作るときにLangGraphを使うよう案内しています。

本番でLangGraphを使うときの注意

試作で動いたグラフを業務で使い続けるには、少なくとも次の4点を決めておきます。

評価とログ

エージェントは、同じ入力でも毎回同じ結果になるとは限りません。どの段階で誤ったかを追えるよう、実行の記録を残します。LangChain社の観測サービスLangSmithを使う場合は、環境変数 LANGSMITH_TRACING=true とAPIキーを設定すると、各ノードの入力と出力が記録されます。記録には個人情報などが含まれうるため、送る前に特定の文字列を伏せる設定（anonymizer）も用意されています。社外のサービスに実行の記録を送ってよいかは、扱うデータの区分に合わせて決めます。

テストについては、公式ドキュメントが、テストのたびに InMemorySaver を新しく作ってグラフをコンパイルする方法や、ノードを1つずつ呼び出して確かめる方法を紹介しています。モデルの回答の質は、業務の実際の入力をもとにした評価用のデータで、モデルや指示文を変えるたびに確かめます。

状態の保存先

InMemorySaver は、再起動すると保存した状態が消えるため、開発やテスト用です。公式ドキュメントは、開発ではファイルに保存する SqliteSaver、本番ではPostgreSQLに保存する PostgresSaver（パッケージは langgraph-checkpoint-postgres）を案内しています。ほかにもRedis、MongoDB、AWSのサービスなどに保存する連携パッケージがあります。

PostgreSQLを使う場合は、thread_id を255文字未満にすること、長く使うとチェックポイントが増え続けるため古いものを定期的に消すことも、公式ドキュメントで注意されています。状態には問い合わせの内容などがそのまま入るため、保存期間と削除の方法も最初に決めます。

デプロイの選択肢

手元で試すときは、langgraph-cli[inmem] を入れて langgraph dev を実行すると、APIサーバーが起動し、LangSmith Studioの画面でグラフの動きを確かめられます。LangSmithのAPIキーとPython 3.11以降が必要で、状態をメモリに置くため開発とテスト専用です。

本番の動かし方は、大きく2つに分かれます。1つは、LangChain社のLangSmith Deploymentを使う方法です。実行環境（Agent Server）と、状態の保存、実行待ちの処理の管理をまとめて用意できます。2026年10月7日時点の公式ドキュメントでは、次の4つの形態が案内されています。

Cloud：LangChain社がすべてを管理する形態です。GitHubのリポジトリからデプロイでき、Plusプラン以上が必要です。
Hybrid：デプロイを管理する仕組み（コントロールプレーン）はLangChain社が持ち、Agent Serverと保存先のデータベースは自社の環境に置く形態です。
Self-hosted with control plane：管理の仕組みも含めて自社のKubernetes環境で動かす形態で、Enterpriseプランが必要です。
Standalone server：コントロールプレーンを使わず、Agent ServerをDockerやKubernetesで動かす形態で、PostgreSQLとRedis、LangSmithのライセンスを自社で用意します。

もう1つは、LangGraphをライブラリとして自社のアプリケーションに組み込み、PostgreSQLなどのチェックポインターを自分で用意する方法です。こちらは追加の契約なしに始められますが、同時実行の制御や、止まったまま残った処理の扱いなどを自分で作る必要があります。

人の承認と権限

interrupt() で承認を挟めても、承認を経ずに外部へ影響する処理が呼べてしまう作りでは意味がありません。送信や更新を行うノードを承認の後にだけ置き、ツールに渡す権限も業務に必要な範囲に絞ります。承認の画面を誰が見て、どのくらいの時間で判断するか、承認されないまま残った処理をどう扱うかも決めておきます。

想定例：見積もりの回答をLangGraphで半自動にする場合

以下は説明のための架空の例です。製造業の営業部門で、見積もりの依頼メールに対する回答案をAIで作り、担当者の承認後に送る仕組みを作るとします。

開発担当者は、依頼の読み取り、価格表の検索、回答案の作成、担当者の承認、送信の5つのノードでグラフを組みます。価格表の検索は決まったコードで行い、モデルには回答案の文章だけを書かせます。承認のノードで interrupt() を呼び、差し戻しは2回までとして、それを超えたら担当者が自分で回答する流れに戻します。状態は社内のPostgreSQLに保存し、問い合わせの内容を含むチェックポイントは90日で削除する決まりにします。最初の1か月は送信のノードを止めておき、承認画面で修正された回答案の割合を見て、送信まで任せる範囲を決めます。

LangGraphでのエージェント開発を相談する場合

LangGraphは、処理の順番、状態の保存、人の承認を細かく設計できる反面、その設計を自分たちで決める必要があります。最初から複雑なグラフを作るより、対象の業務を1つに絞り、承認の場所と終了の条件を決めた小さなグラフから始めるほうが、評価と改善を進めやすくなります。

inovieでは、業務の整理からエージェントの設計、LangGraphなどを使った試作、既存システムへの組み込みと運用の設計までを支援しています。支援の範囲はAIエージェント導入・改善支援をご覧ください。LangGraphを使うべきか、DifyやAgent SDKで足りるかを検討している段階でも、お問い合わせからご相談いただけます。

出典確認日：2026-10-07

← ブログ一覧に戻る記事の先頭へ ↑