LangGraph 状態管理実践：Checkpoint、Thread State、障害復旧

2026-06-03 更新：LangGraph 公式 persistence ドキュメントを確認し、checkpoint、thread state、failure recovery の説明を補強しました。StateGraph を動かすだけでなく、各実行を復旧・追跡・再生できる設計が重要です。

LangGraph の GitHub リポジトリはスター数 30,000 を突破し、2026 年で最も活発なエージェントフレームワークの一つになりました。それでも多くの人の使い方は「とりあえず動けばいい」段階のままです。状態の衝突、永続化の失敗、本番デプロイの難しさ——チュートリアルではあまり触れられませんが、実プロジェクトでは繰り返し起きます。

LangChain 公式が 2026 年に公開した State of Agent Engineering レポートによると、エージェント本番事故の 60% 超が状態管理に関係しています。この記事では、チュートリアルが教えてくれないこと——State Schema の設計パターン、Reducer 関数の実践、永続化の選定、フレームワーク比較、Observability 統合——に焦点を当てます。読み終われば、すぐ使えるコードテンプレートと、フレームワーク選定の根拠が手に入ります。

LangGraph 状態管理の核心：StateGraph から Reducer へ

LangChain の Chain を使ったことがあるなら、StateGraph は馴染みが薄いかもしれません。Chain は線形——一歩ずつ、ベルトコンベアのように進みます。でも実際のエージェントロジックはそう素直ではありません。あるノードで「ユーザーの意図は雑談か検索か」を判定し、別ブランチへ分岐させたい。複数ノードを並列実行して、最後に結果を集約したい。StateGraph はそのためにあります。

1.1 StateGraph の構築パターン

StateGraph と普通の Graph の決定的な違いは「状態」です。普通の Graph ではノード間に固定の入出力が渡されますが、StateGraph では全ノードが同じ状態オブジェクトを共有します。各ノードは状態を読み、書き、変更後の状態は次のノードへ自動で渡ります。

from langgraph.graph import StateGraph, MessagesState
from langchain_openai import ChatOpenAI

# 定义状态结构（继承 MessagesState，自动包含 messages 字段）
class AgentState(MessagesState):
    next_action: str  # 下一步动作
    retry_count: int = 0  # 重试次数

# 初始化图
graph = StateGraph(AgentState)

# 添加节点
graph.add_node("classify", classify_intent)
graph.add_node("respond", generate_response)
graph.add_node("fallback", handle_fallback)

# 定义边（条件分支）
graph.add_conditional_edges(
    "classify",
    lambda state: state["next_action"],
    {
        "respond": "respond",
        "fallback": "fallback"
    }
)

# 编译——这一步必须，不编译无法执行
app = graph.compile()

.compile() を忘れる人が多いです。私も LangGraph を始めた頃、ノードとエッジを書き込んだのに実行すると「Graph not compiled」で落ちました。コンパイル時に型チェック、エッジの接続性検証が走り、設定に応じて checkpointer も注入されます。

一点注意：StateGraph の状態は「完全上書き」ではなく「増分更新」です。ノード A で retry_count を変えても、ノード B はそのフィールドだけ読めばよく、他の状態を気にする必要はありません。この設計が並列実行を可能にします——複数ノードが同時に走り、それぞれ別フィールドを更新し、最後に結果をマージします。

1.2 状態 Schema 設計の進化

状態構造の定義には 3 つの方式があり、それぞれ長所・短所があります。

TypedDict が最も基本的で、型安全ですがデフォルト値は使えません：

from typing import TypedDict, Annotated

class SimpleState(TypedDict):
    messages: list
    context: str
    # 不支持默认值，每个字段都必须标注类型

dataclass は Python ネイティブのデフォルト値に対応し、IDE の補完も効きやすいです：

from dataclasses import dataclass

@dataclass
class DataclassState:
    messages: list
    context: str = ""
    retry_count: int = 0  # 可以有默认值

Pydantic BaseModel が 2026 年の推奨方式です。再帰的な検証、型変換に対応し、LangChain のツールともスムーズに連携できます：

from pydantic import BaseModel, Field

class OptimizedState(BaseModel):
    messages: list = Field(default_factory=list)
    context: str = ""
    retry_count: int = Field(default=0, ge=0)  # 支持校验：必须 >= 0

    class Config:
        # Pydantic v2 的配置
        extra = "forbid"  # 禁止额外字段，防止状态污染

以前は TypedDict で十分だと思っていました。あるとき、デバッグ用に一時追加した不正フィールドを消し忘れ、後続ノードが奇妙なデータを受け取り、半日かけて原因を特定しました。それ以来、Pydantic の extra="forbid" で入口で不正フィールドを弾くようにしています。

1.3 Reducer 関数の仕組み

LangGraph 状態管理の核心で、最も誤解されやすい部分です。

複数ノードが並列実行されると、同じ状態フィールドを同時に変更することがあります。デフォルトは「後から実行した方が上書き」ですが、多くの場合それは望ましくありません。Reducer 関数が、並列変更をどうマージするかを定義します。

LangGraph にはよく使う Reducer として add_messages があります。メッセージリストのマージ用——重複を除き、最新版を残します：

from langgraph.graph import add_messages

class ChatState(TypedDict):
    messages: Annotated[list, add_messages]

2 つの並列ノードがそれぞれ messages に追記しても、add_messages は単純上書きではなく賢くマージします。

カスタム Reducer は、現在値と新値の 2 引数を受け取り、マージ結果を返す関数です。

def merge_contexts(existing: str, new: str) -> str:
    """合并上下文字符串，保留最长版本"""
    if not existing:
        return new
    if not new:
        return existing
    return existing if len(existing) >= len(new) else new

class CustomState(TypedDict):
    context: Annotated[str, merge_contexts]

あるプロジェクトでは、3 つの検索ノードがベクトル DB・キーワード索引・ナレッジグラフを並列クエリし、候補リストを返す「多路召回」にカスタム reducer を使いました。最後にマージ・重複除去・関連度ソート。直列呼び出しより約 3 倍速くなりました。

永続化とチェックポイント：本番級エージェントの土台

序文で触れた深夜のクラッシュ——根本原因は永続化の設定ミスでした。MemorySaver はメモリにしか状態を置かないので、プロセス再起動で消えます。エージェントが途中で落ちると、ユーザーの会話が全部失われる。本番では許容できない事故です。

2.1 Checkpointer の種類と選定

LangGraph には 3 種類の Checkpointer があり、用途が大きく異なります。

Checkpointer	適用シナリオ	長所	短所
MemorySaver	ローカル開発、クイックテスト	設定不要、極めて高速	プロセス再起動で消失
SqliteSaver	単一サーバー、プロトタイプ検証	軽量、外部依存なし	書き込み性能に限界、高並列向きでない
PostgresSaver	本番環境	信頼性高、高並列対応	PostgreSQL の運用が必要

開発は MemorySaver、本番は PostgresSaver を直接使うのがおすすめです。SqliteSaver はスキップ——高並列での書き込みボトルネックは地獄です。

# 生产环境配置示例
from langgraph.checkpoint.postgres import PostgresSaver
import psycopg

# 同步版本
conn = psycopg.connect("postgres://user:pass@host:5432/db")
checkpointer = PostgresSaver(conn)

# 异步版本（推荐用于高并发）
from langgraph.checkpoint.postgres.aio import AsyncPostgresSaver
import psycopg_pool

pool = psycopg_pool.AsyncConnectionPool(
    "postgres://user:pass@host:5432/db",
    min_size=5,
    max_size=20
)
async_checkpointer = AsyncPostgresSaver(pool)

# 编译时注入
app = graph.compile(checkpointer=async_checkpointer)

2.2 Thread ID の仕組み

Thread ID は LangGraph におけるマルチユーザー／マルチセッション分離の核心です。各 thread_id は独立した状態履歴に対応し、互いに干渉しません。

# 第一次对话
config = {"configurable": {"thread_id": "user_123_session_1"}}
result = app.invoke(
    {"messages": [{"role": "user", "content": "僕の名前は田中です"}]},
    config
)

# 第二次对话（同一个 thread_id）
# Agent 会记住之前说的"我叫小明"
result2 = app.invoke(
    {"messages": [{"role": "user", "content": "僕の名前は何ですか？"}]},
    config  # 同一个 thread_id
)

# 不同 thread_id = 完全独立的新会话
config_new = {"configurable": {"thread_id": "user_456_session_1"}}
result3 = app.invoke(
    {"messages": [{"role": "user", "content": "僕の名前は何ですか？"}]},
    config_new  # Agent 不知道"小明"
)

仕組みは巧妙ですが、使い方を間違えやすい。以前、thread_id を固定値にしてしまい、全ユーザーが同じ会話履歴を共有——ユーザー A の質問に、ユーザー B が答えを見てしまう事態に。正しくは ユーザー ID + セッション ID の組み合わせを thread_id にします。

自動保存・自動ロードも checkpointer の「暗黙の」機能です。手動で save() や load() を呼ぶ必要はなく、invoke() や stream() のたびに自動で走ります。便利な反面、DB には頻繁な書き込みがかかります。

2.3 シリアライズと型サポート

LangGraph はデフォルトで JsonPlusSerializer により状態をシリアライズします。対応しているのは次のとおりです。

• Python ネイティブ型（list, dict, str, int, float, bool）
• datetime オブジェクト
• LangChain メッセージ型（HumanMessage, AIMessage など）
• enum 列挙値

from datetime import datetime
from langchain_core.messages import HumanMessage

class RichState(TypedDict):
    messages: list
    created_at: datetime  # 支持 datetime
    status: str

# 可以直接存 datetime，不需要转成字符串
state = {
    "messages": [HumanMessage(content="Hello")],
    "created_at": datetime.now(),
    "status": "active"
}

一方、Python の set（集合）は非対応です。状態に set がある場合は list に変換し、読み取り時に戻す必要があります。あるプロジェクトで訪問済みノード ID を set で持っていたら、シリアライズでエラー。原因特定に時間がかかりました。

2.4 本番デプロイの落とし穴

落とし穴 1：SqliteSaver の書き込み性能

SQLite の書き込みロックは DB レベルで、同時に 1 書き込みしかできません。100 以上の並行会話を扱うエージェントでは SqliteSaver がボトルネックになります。症状は応答遅延、エラー率上昇、ログに “database is locked” が並ぶこと。

対策：PostgreSQL に直接移行し、非同期版 AsyncPostgresSaver を使う。

落とし穴 2：非同期 API の選択

LangGraph の同期 API と非同期 API は別物です。FastAPI や aiohttp など非同期フレームワークなら、必ず非同期版を使いましょう：

# 同步 API（阻塞）
result = app.invoke(state, config)

# 异步 API（非阻塞）
result = await app.ainvoke(state, config)

# 流式输出也需要对应的异步方法
async for chunk in app.astream(state, config):
    yield chunk

同期と非同期の混在は問題を起こします。FastAPI ルートで同期 invoke() を呼んだら、イベントループ全体がブロックされ、他リクエストが全部止まりました。

落とし穴 3：エラー復旧機構の欠如

Checkpointer は状態を保存しますが、自動の失敗検知器ではありません。ノード C でクラッシュした場合、状態は C の直前で止まりますが、「中断地点から再開」するロジックは自分で実装する必要があります：

# 从上次中断的地方恢复
state = app.get_state(config)
if state.values.get("current_node") == "C":
    # 重新执行节点 C
    result = app.invoke(state.values, config)

LangGraph は app.get_state() と app.update_state() を提供し、状態の読み取りと手動更新ができます。デバッグに便利——特定チェックポイントへ「巻き戻して」再実行できます。

フレームワーク比較：LangGraph vs CrewAI vs AutoGen

フレームワーク選びはプログラミング言語選びに似ています。「最強」はなく、「最適」があります。3 つともプロジェクトで使った経験があり、それぞれ個性があります。

3.1 3 フレームワークの設計思想

LangGraph：グラフ構造 + 状態駆動

LangGraph の核心は「明示的なグラフ構造」です。ノード、エッジ、状態を定義し、フレームワークが実行します。制御力は極めて強い——データの流れ、各ノードでの判断がはっきり見えます。反面、学習曲線が急で、コード量も多め。

# LangGraph 风格：显式定义每个节点和边
graph = StateGraph(AgentState)
graph.add_node("research", research_node)
graph.add_node("write", write_node)
graph.add_node("review", review_node)
graph.add_edge("research", "write")
graph.add_conditional_edges("write", should_review, {"review": "review", "end": END})

CrewAI：ロール駆動 + 高抽象

CrewAI は「ロールを定義し、協調させる」発想です。Agent（ロール）、Task（タスク）、Crew（チーム）を定義すれば、フレームワークがオーケストレーションします。数行で動かせ、非常に早い。ただし制御力は弱い——下層の编排ロジックが隠れ、障害時のデバッグが難しい。

# CrewAI 风格：定义角色和任务
researcher = Agent(role="Researcher", goal="Find information", ...)
writer = Agent(role="Writer", goal="Write articles", ...)

task1 = Task(description="Research topic X", agent=researcher)
task2 = Task(description="Write article based on research", agent=writer)

crew = Crew(agents=[researcher, writer], tasks=[task1, task2])
crew.kickoff()  # 一行启动

AutoGen：対話駆動 + 協調

AutoGen は Microsoft Research 由来で、核心は「エージェント間の対話」です。複数エージェントを定義し、対話で協調してタスクを完了します。頻繁なコミュニケーション・交渉が必要なコードレビューや方案議論に向きます。ただし Token 消費が大きい——エージェント間メッセージがコンテキストを大量に占めます。

# AutoGen 风格：Agent 通过对话协作
assistant = AssistantAgent("assistant", llm_config=...)
user_proxy = UserProxyAgent("user_proxy", ...)

# Agent 之间自动对话
user_proxy.initiate_chat(
    assistant,
    message="帮我写一个排序算法"
)
# assistant 和 user_proxy 会自动多轮对话，直到任务完成

3.2 技術次元の比較表

実使用経験に基づき、いくつかの次元で比較しました。

次元	LangGraph	CrewAI	AutoGen
学習曲線	急	緩やか	中程度
制御力	極めて強い	中程度	中程度
本番成熟度	最も成熟	安定	改善中
状態管理	ネイティブ対応	カプセル化	カプセル化
デバッグ能力	強（可視化 trace）	中程度	中程度
Token 効率	高	中程度	低（対話オーバーヘッド大）
並列実行	ネイティブ対応	対応	対応
永続化	複数バックエンド	限定的	限定的
ドキュメント品質	充実	普通	普通

学習曲線：CrewAI が最もフレンドリー。ロールを定義すれば動きます。LangGraph は StateGraph、Reducer、Checkpointer などの概念理解が必要で、立ち上がりに時間がかかります。

制御力：LangGraph が勝ち。各ノードの入出力、条件分岐、並列実行を精密に制御できます。CrewAI と AutoGen は编排ロジックが隠れ、問題時の特定が難しい。

Token 効率：AutoGen の対話機構は Token 消費が大きい。エージェント間メッセージがコンテキストウィンドウを占め続けます。LangGraph の状態駆動は必要情報だけを保持し、無限に膨らみにくい。

3.3 選定の判断フレーム

迷っているなら、次の基準で判断できます。

CrewAI を選ぶなら：

• プロトタイプを素早く、デモ効果を出したい
• チームのエージェント開発経験が浅い
• タスクフローが比較的固定で、複雑な条件分岐が不要
• 期間が短く、まず納品を優先

LangGraph を選ぶなら：

• 本番級システムを構築する
• フローと状態を精密に制御したい
• 複雑な条件分岐、並列実行が必要
• 長期メンテナンス・反復開発

AutoGen を選ぶなら：

• マルチエージェントの交渉・議論が中心
• LLM クォータに余裕があり、Token 消費を気にしない
• 研究プロジェクトで、エージェント協調パターンを探索

私の提案：迷ったら LangGraph から学ぶ。概念がより低レイヤーで、CrewAI や AutoGen も理解しやすくなります。ドキュメントとコミュニティも、現時点で 3 つの中で最も充実しています。

Observability と本番デプロイの実践

エージェントを本番に載せると、新たな問題が出ます。ブラックボックスのまま動いている——どのノードで止まったか、なぜ変な出力が出たか、Token 消費が正常かわからない。Observability ツールはその解決のためです。

4.1 LangSmith 統合

LangSmith は LangChain 公式の Observability プラットフォームです。各呼び出しをトレースし、エージェントの実行パスを可視化し、出力品質を評価できます。

import os

# 配置环境变量（启动时设置一次即可）
os.environ["LANGSMITH_API_KEY"] = "your-api-key"
os.environ["LANGSMITH_TRACING"] = "true"
os.environ["LANGSMITH_PROJECT"] = "my-agent-project"

# 之后的每次 invoke 都会自动上报
result = app.invoke({"messages": [...]})

# 在 LangSmith 控制台查看：
# - 完整的调用链路
# - 每个节点的输入输出
# - Token 消耗明细
# - 执行时间分布

LangSmith の trace は、エージェントデバッグで最も使う機能です。あるときユーザーから「たまに無関係な内容が出る」と報告があり、trace を辿ると特定の検索ノードが誤った結果を返していました。原因特定は 10 分未満、修正もフィルタ条件を 1 つ足すだけで済みました。

コスト面では、LangSmith に無料枠（月 5000 trace）があり、小規模プロジェクトなら足ります。チーム版は $39/月〜で、複数人協業向きです。

4.2 Langfuse：オープンソース代替

データプライバシーが敏感、または Observability データを自社で握りたいなら、Langfuse がオープンソースの代替です。

# 安装
# pip install langfuse

from langfuse.langchain import CallbackHandler

# 初始化 handler
langfuse_handler = CallbackHandler(
    public_key="pk-xxx",
    secret_key="sk-xxx",
    host="https://cloud.langfuse.com"  # 或自托管地址
)

# 注入到 invoke
result = app.invoke(
    {"messages": [...]},
    config={"callbacks": [langfuse_handler]}
)

# Langfuse 会记录：
# - prompt 和 completion
# - 模型参数
# - Token 使用量
# - 执行时间

Langfuse は自ホスト可能で、Docker で一発デプロイできます。LangSmith より機能は少ないですが、trace、スコアリング、データセット管理の核心機能は揃っています。コンプライアンス上、第三者へデータを送れないプロジェクトでは、Langfuse 自ホスト版をプライベート Kubernetes クラスタで動かした経験があります。

機能比較：

機能	LangSmith	Langfuse
Trace 追跡	対応	対応
可視化	強	中程度
自ホスト	非対応	対応
価格	$0〜$39+/月	オープンソース無料
データセット管理	対応	対応
スコアリング	対応	対応

4.3 カスタム Metrics

既存の Observability プラットフォームに加え、自前でメトリクスを仕込むこともできます。

状態遷移の追跡：各ノードの入退場時刻を記録し、所要時間分布を算出。

import time
from datetime import datetime

# 自定义节点包装器
def timed_node(node_func):
    def wrapper(state):
        start = time.time()
        print(f"[{datetime.now()}] Entering {node_func.__name__}")
        result = node_func(state)
        elapsed = time.time() - start
        print(f"[{datetime.now()}] Exiting {node_func.__name__}, took {elapsed:.2f}s")
        return result
    return wrapper

# 使用
@timed_node
def my_research_node(state):
    # 节点逻辑
    return state

判断パスの可視化：エージェントが通ったノード列を記録し、よくあるパスを分析。

# 在状态中添加路径字段
class TrackedState(MessagesState):
    visited_nodes: list = []

# 每个节点执行后追加记录
def track_visit(state, node_name):
    state["visited_nodes"].append({
        "node": node_name,
        "timestamp": datetime.now().isoformat()
    })
    return state

これらのカスタム metrics は Prometheus や Grafana など自社監視へ送り、ビジネス指標と合わせて分析できます。あるエージェントが夕方のピークで遅くなっていたのを、カスタム metrics で外部 API タイムアウトと特定。リトライとサーキットブレーカーを足したら、p99 レイテンシが 15 秒から 3 秒に下がりました。

2026 エージェントエンジニアリングの潮流と LangGraph の進化

技術は速く変わりますが、押さえておく価値のある潮流もあります。

5.1 LangChain State of Agent Engineering レポートの核心

LangChain は 2026 年初頭に State of Agent Engineering レポートを公開し、数百の本番エージェントシステムを分析しました。特に印象的だった 3 点：

発見 1：グラフアーキテクチャが主流に

本番エージェントの 70% 超が、単純な線形 Chain ではなく、何らかのグラフ構造（DAG やステートマシン）を採用しています。理由は現実的——実際の業務フローは一直線ではありません。ユーザーが途中で割り込み、確認を求め、話題を切り替える——グラフ構造の方がこうした複雑さに対応しやすい。

発見 2：Human-in-the-loop の標準化

60% のエージェントシステムに人間の介入ポイントが入っています。エージェントが全自動で走り切るのではなく、重要な判断点で一時停止し、人間の確認後に再開する。LangGraph の interrupt API はそのための設計です：

# 在关键节点暂停，等待人工审核
graph.add_node("human_review", interrupt=True)

# 审核通过后继续
app.update_state(config, {"approved": True})
result = app.invoke(None, config)  # 从中断点继续执行

金融や医療など高リスク領域では特に重要——エージェントに振込や処方を全自動で任せられず、人間のチェックが必要です。

発見 3：Observability ツールの成熟

レポートのデータ：Observability を備えたエージェントは、未装備より平均的な障害調査時間が 60% 短い。私の経験とも一致——trace がなければ、闇の中を手探りするようなデバッグになります。

5.2 LangGraph 2026 の新機能

LangGraph には 2026 年、いくつか重要な更新があります。

Pydantic v3 による状態定義が標準に

Pydantic v3 は v2 比で性能が 5〜10 倍向上し、検証も高速化。LangGraph 公式は新規プロジェクトで Pydantic BaseModel による状態定義を推奨しています。

Subgraph によるモジュール化

複雑なエージェントを複数の Subgraph に分割できます。各 Subgraph は独立したステートマシンとして、単体テスト・再利用が可能。

# 子图：独立的检索 Agent
research_subgraph = StateGraph(ResearchState)
research_subgraph.add_node("search", search_node)
research_subgraph.add_node("summarize", summarize_node)
research_subgraph.compile()

# 主图：调用子图
main_graph = StateGraph(MainState)
main_graph.add_node("research", research_subgraph)
main_graph.add_node("write", write_node)

大規模プロジェクトに有用——チームごとに Subgraph を開発し、最後に組み立てられます。

Deep Agents：計画 + サブエージェント + ファイルシステム

LangGraph は「Deep Agents」概念を導入——主エージェントが計画し、サブエージェントに具体タスクを委譲し、ファイルシステムも操作します。「この PDF を分析し、レポートを生成して指定ディレクトリに保存する」といった複雑なワークフローが可能に。

5.3 今後の展望

Agent Governance の進化

本番でのエージェント利用が広がるほど、ガバナンスが重要に——誰が監督するか、判断ミスの責任、コンプライアンス。LangChain は AgentOps を推進しており、DevOps に似たがエージェント全ライフサイクル向けの概念です。

マルチモーダルエージェント対応

現状のエージェントは主にテキスト処理。今後は画像・音声・動画との統合が増えます。LangGraph はマルチモーダルメッセージ型をサポートし始めていますが、完全なクロスモーダルワークフローはまだ探索段階です。

これらの予測が全部当たるかはわかりません。ただ一つ確かなのは、エージェントエンジニアリングはまだ初期段階で、ベストプラクティスは日々進化していること。公式ドキュメントとコミュニティを追い続けるのが、変化についていく唯一の方法です。

まとめ

この記事では LangGraph 状態管理の核心次元をカバーしました。

• StateGraph 構築：グラフ構造 + 状態駆動がエージェント開発の基礎パターン
• Reducer パターン：並列実行時の状態マージの鍵
• 永続化の選定：開発は MemorySaver、本番は PostgresSaver
• フレームワーク比較：LangGraph は制御力最強、CrewAI は最速で始められる、AutoGen は協調向け
• Observability：LangSmith か Langfuse、どちらか必須

アクション提案：

1. 既存のエージェントプロジェクトを確認。MemorySaver のままなら、PostgresSaver への移行を今すぐ計画する。
2. LangChain の State of Agent Engineering レポートを読み、業界トレンドを把握する。
3. エージェントに Observability を追加——LangSmith でも自ホスト Langfuse でも、まず動かす。
4. エージェント開発を始めたばかりなら、本シリーズのエージェント記憶システム設計と AI エージェントアーキテクチャ設計も参照し、技術スタックを揃える。

エージェントエンジニアリングは急速に進化しています。今日のベストプラクティスが来年には古くなるかもしれません。ただ、状態管理・永続化・可観測性という基礎原理を押さえておけば、新しいツールも理解しやすくなります。

状態管理の選択表

目的	推奨	避けたいこと	理由
ローカル実験	MemorySaver	最初から複雑な DB	schema と reducer を低コストで検証
本番チャット/長時間タスク	Postgres checkpointer + thread_id	最終結果だけ保存	resume、replay、人間介入に対応
マルチ Agent 編成	明示的な LangGraph state + checkpoint	prompt だけの記憶	どのノードが状態を壊したか追える
研究型協調フロー	AutoGen/CrewAI + 外部状態記録	完全な無状態議論	協調にも task status と timeout 監視が必要

関連記事：状態管理から Agent 体系へ

• AI コーディングツール全景 2026
• LangGraph と AutoGen の状態追跡
• Llama 70B ハードウェアガイド