LangGraph vs AutoGen 状態管理比較：checkpoint、タイムアウト復旧、選定の決定ガイド

ある研究文献整理エージェントが 30 ステップのタスクを実行し、25 ステップ目で LLM を呼び出した時にクラッシュしました。前の 24 ステップがすべて無駄になり、API 費用と時間コストがゼロに。これは例外ではありません。エージェントプロジェクトの 80% が失敗する理由は、LLM の能力不足ではなく——初期の状態管理設計が間違っているからです。本記事では Checkpoint メカニズム、タイムアウト復旧、分散サポートなど 12 の評価軸で LangGraph と AutoGen の 2 大フレームワークを比較し、実践的なトラブルシューティング事例、選定フローチャート、実行可能なコードを添えて、どちらのフレームワークがプロジェクトに適しているかを素早く判断できます。

Checkpoint メカニズムの詳細比較

LangGraph は設計当初から checkpoint をアーキテクチャに組み込みました。各ノード実行後、グラフの状態が自動的にスナップショットとして保存され、StateSnapshot と呼ばれます。このスナップショットは 4 つの情報を保存：channel_values（現在のグラフ状態）、channel_versions（各チャネルのバージョン番号）、versions_seen（ノードが前回見た状態バージョン）、pending_writes（まだチャネルに書き込まれていない更新）。復旧時、LangGraph はソースコードの次の行から継続せず、ノードを再実行します——これが永続実行の核となるセマンティクス：node re-execution です。

Checkpoint の保存タイミングは 3 つあります。input 段階でグラフ起動前に 1 枚保存、loop 段階で各ノード実行後に 1 枚保存、外部注入（例えば人間による介入）でも手動でトリガー可能。永続モードは 3 種類：'exit' は終了時のみ保存で中間復旧なし、'async' は非同期保存で checkpoint を見失う可能性あり、'sync' は各ステップを同期的に永続化しパフォーマンスオーバーヘッドが最大ですが最も安全です。

AutoGen の状態管理はまだ進化中です。v0.4 は save_state() と load_state() API を提供しますが、その状態構造は会話履歴のシリアライゼーションで、グラフ状態の完全なスナップショットではありません。典型的な AutoGen state は次のような構造：

{
  "type": "AssistantAgentState",
  "version": "1.0.0",
  "llm_messages": [
    {"content": "ユーザーの質問...", "role": "user"},
    {"content": "エージェントの回答...", "role": "assistant"}
  ]
}

TeamState はさらに agent_states と group_chat_manager 状態を追加します。これと LangGraph の違いは明確：AutoGen は会話軌跡を保存、LangGraph はグラフ状態の完全なスナップショットを保存。会話軌跡は多段協議シナリオに適していますが、エージェントに複雑な状態遷移（例えばマルチノード分岐、条件ジャンプ、ループチェック）がある場合、会話軌跡は正確に表現できません。

あるアフターサービスタケット処理フローで問題に直面しました。フローは 8 つのノード：チケット受付 → 分類 → ナレッジベース検索 → API 呼び出しで注文チェック → 回答ドラフト生成 → 人間によるレビュー → 回答送信 → ログ記録。AutoGen で実装時、5 ステップ目のドラフト生成後にクラッシュし、再起動しても会話履歴から前の数回の会話しか見られず、「ナレッジベース検索済み、API 呼び出し済み」という状態組み合わせに復旧できませんでした。LangGraph に切り替えると、checkpoint が直接 knowledge_base_result と api_check_result の 2 つのチャネル値を保存し、復旧時に「ドラフト生成」ノードを再実行しても、ナレッジベースと API 呼び出しの結果が残っており、無駄な再実行が不要でした。

LangGraph の checkpoint データ構造は複雑ですが、公式ドキュメントで完全な説明が提供されています。Persistence - Docs by LangChain の定義によると、channel_versions と versions_seen は状態競合を判断するために使用——外部注入とノード実行が同時に同じチャネルを更新すると、バージョン番号がシステムに誰が先か後かを伝えます。この設計はマルチスレッド実行と人間とマシンの介入シナリオで重要で、AutoGen には現在、同様のバージョン管理メカニズムがありません。

タイムアウトと復旧メカニズムの実践

LangGraph v1.2 は 3 つのフォールトトレランスメカニズムを導入：RetryPolicy、TimeoutPolicy、error_handler。これらは独立した設定ではなく、協調するシステムです。

🔥 需要のない製品に3ヶ月も無駄にするな！少額の予算で Adsterra を使い、SaaS の訴求を今すぐ検証 ➡️

今すぐ検証 →広告

RetryPolicy はノード失敗後のリトライ動作を制御します。デフォルトでは ConnectionError と HTTP 5xx エラーのみリトライし、4xx はリトライしません（リクエスト自体に問題があるため）。max_attempts（最大試行回数）、backoff_factor（指数バックオフ係数）、jitter（揺らぎ、全クライアントが同時にリトライするのを防止）、retry_on（カスタムリトライ条件）を設定可能。典型的な設定：

from langgraph.pregel import RetryPolicy

retry_policy = RetryPolicy(
    max_attempts=4,
    backoff_factor=2.0,
    jitter=True,
    retry_on=(ConnectionError, TimeoutError)
)

指数バックオフの意味：最初の失敗で 2 秒待機、2 回目で 4 秒、3 回目で 8 秒、4 回目で 16 秒。揺らぎを加えると、実際の待機時間が基準値の上下に変動し、複数インスタンスが同時に API に殺到するのを防ぎます。

TimeoutPolicy は 2 つのタイムアウトパラメータ：run_timeout はハードクロック制限でノード開始実行から計測、idle_timeout は無進行タイムアウトでノードが長時間出力なし（例えばストリーミング呼び出しがスタック）の場合もトリガー。設定例：

from langgraph.pregel import TimeoutPolicy

timeout_policy = TimeoutPolicy(
    run_timeout=30,  # 30 秒ハードタイムアウト
    idle_timeout=5,  # 5 秒無進行タイムアウト
    refresh_on="auto"  # 自動リフレッシュ
)

error_handler はリトライを消費した後に実行されます。NodeError コンテキスト（ノード名、エラータイプ、checkpoint ID を含む）を受け取り、降級ロジックに使用可能：例えば LLM 呼び出し失敗後、ルールエンジンで回答を生成したり、このタスクを人間の処理が必要とマーク。完全なノード設定例：

from langgraph.pregel import RetryPolicy, TimeoutPolicy

def handle_model_failure(error: NodeError):
    # 降級：ルールエンジンで回答を生成
    return generate_fallback_response(error.context)

graph.add_node(
    "call_llm",
    call_llm,
    retry_policy=RetryPolicy(max_attempts=4, backoff_factor=2.0),
    timeout=TimeoutPolicy(run_timeout=30, idle_timeout=5),
    error_handler=handle_model_failure
)

AutoGen のタイムアウト制御は終了条件に依存します。v0.4 は MaxMessage（メッセージ数上限）、Timeout（総時間上限）、TokenUsage（トークン数上限）の 3 種類の終了条件を提供。これらはノードレベルではなく、会話レベル——会話全体が 20 メッセージを超えるか、10 分を超えると停止します。無限ループ防止に適していますが、単一ノードのタイムアウト動作を制御できません。

Node re-execution は LangGraph 永続実行の核となるセマンティクスで、最も落とし穴になりやすい部分です。復旧時、システムはクラッシュしたノードを再実行し、ソースコードの次の行から継続しません。つまり、ノードに副作用（メール送信、DB 書き込み、外部 API 呼び出し）がある場合、冪等性を保証する必要があります。Vadim のブログ Durable Execution in LangGraph によると、研究では 75% の checkpoint は冪等設計で回避でき、復旧成功率は 8% から 100% に向上しました。

冪等性の実装方法は？最も一般的なのは重複排除チェックです。メール送信前にメールシステムで送信済みかチェック、DB 書き込み前に一意キーで存在確認。もう一つは決定的ロジック：ノードが計算と状態更新のみ（外部呼び出しなし）を行う場合、再実行しても結果は変わらず、天然で冪等。月次メールマーケティングフローでは thread_id を重複排除マークに使用：thread_id = "campaign-{campaign_id}-{contact_id}"。checkpoint 復旧時、メール送信ノードはまずこの thread_id が送信済みかチェックし、重複送信を回避します。

AutoGen には現在、node re-execution の概念がなく、その実行モデルはグラフ駆動ではなく会話駆動です。会話がクラッシュした後、保存された会話履歴から継続するしかありませんが、中間の API 呼び出し結果の整合性は保証されません。AutoGen で副作用のあるフローを実装する場合、冪等ロジックを自分で実装するか、クラッシュ後の重複実行リスクを受け入れる必要があります。

Fault Tolerance in LangGraph: Retries, Timeouts and Error Handlers 公式ブログによると、LangGraph のフォールトトレランスメカニズムの設計目標は、LLM API が不安定（ネットワーク変動、レート制限、タイムアウト）な時も、エージェントが継続動作し、直接停止しないことです。AutoGen の設計目標は無限会話ループの防止で、両者の重点が異なります。

分散と本番デプロイ

LangGraph の永続化バックエンドは 3 層：SqliteSaver（ローカル開発）、PostgresSaver（本番環境）、RedisSaver（高同時実行シナリオ）。公式はカスタム Saver もサポートし、MongoDB、DynamoDB または KV ストレージをサポートする任意のバックエンドに接続可能。設定例：

from langgraph.checkpoint.sqlite import SqliteSaver
from langgraph.checkpoint.postgres import PostgresSaver

# ローカル開発
checkpointer = SqliteSaver("checkpoints.db")

# 本番環境
checkpointer = PostgresSaver(
    connection_string="postgresql://user:pass@host/db",
    table_name="langgraph_checkpoints"
)

graph = StateGraph(State)
graph.set_checkpointer(checkpointer)

3 種類の永続モードの選択はシナリオによります。'exit' はグラフ終了時のみ保存で、短時間フロー、低リスクシナリオ（例えば一回限りのデータ処理）に適しています。'async' は非同期保存で、中程度のリスク、パフォーマンス重視のシナリオ（例えばリアルタイム応答のエージェント）に適しています。'sync' は各ステップを同期的に永続化し、高リスク、復旧必須のシナリオ（例えば財務、決済フロー）に適しています。Persistence - Docs by LangChain によると、'sync' のパフォーマンスオーバーヘッドは最大ですが、安全性が最高です。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

AutoGen は現在、ファイルシリアライゼーション + JSON ストレージのみサポート。分散サポートはまだロードマップ上で、Managing State — AutoGen 公式ドキュメントにはマルチインスタンスデプロイの状態同期ソリューションが言及されていません。分散環境で AutoGen を実行する場合、状態共有ロジックを自分で実装する必要があります：例えば save_state() の結果をデータベースに保存、load_state() でデータベースから読み込み。これは LangGraph の組み込みソリューションより開発コストが増えます。

本番デプロイの典型的なケースは Cloudflare Workers 月次メールマーケティングです。Vadim ブログ Durable Execution in LangGraph によると、フローは 6 回のタッチ：check_reply（返信チェック）→ compose_touch（タッチコンテンツ作成）→ [interrupt]（人間によるレビュー）→ send_touch（送信）→ schedule_next（次回タッチ予定）→ [interrupt]（次回時間確認）。thread_id は "campaign-{campaign_id}-{contact_id}" で設計され、各連絡先に 1 つのスレッド、冪等性を保証。

Interrupt は LangGraph の人間とマシンの介入メカニズムです。ノードが interrupt に達すると一時停止し、外部注入（例えば人間による確認）を待ちます。注入後、グラフは interrupt 点から継続実行。これは AutoGen の Group Chat 協議より制御可能：AutoGen のマルチエージェント協議は非同期会話で、明確な一時停止点がありません。LangGraph の interrupt はグラフノードレベルの一時停止で、復旧セマンティクスが明確です。

冪等性は副作用ノードの必須要件です。Crab checkpoint/restore study の研究によると、75% の checkpoint は冪等設計で回避でき、復旧成功率は 8% から 100% に向上。冪等性実装方法は主に 2 つ：重複排除チェック（メール送信前にメールシステムで送信済みかチェック）と決定的ロジック（純計算ノード、再実行しても結果不変）。デプロイ時には AI Gateway（マルチ Provider フェイルオーバー、コスト監視、レート制限）を追加——これがエージェント安定稼働の底线です。単一 Provider の API は不安定なため、バックアップルートが必須。

AutoGen の分散デプロイは現在、自分で構築する必要があります。Kubernetes や Cloudflare Workers でマルチインスタンスを実行する場合、各インスタンスの状態保存を共有ストレージ（Redis やデータベース）に集約する必要があります。これは LangGraph の PostgresSaver ソリューションと本質的に同じですが、AutoGen には公式サポートがなく、ドキュメントにもベストプラクティスがなく、トラブルシューティングコストが高いです。

API 移行とバージョン変更

AutoGen v0.2 から v0.4 への移行コストは低くありません。Migration Guide for v0.2 to v0.4 — AutoGen によると、v0.4 はゼロから書き直され、アーキテクチャが同期から非同期イベント駆動に変更されました。API は 2 層：Core API は低レイヤーのイベント駆動アクターフレームワーク、AgentChat API は高レイヤーのタスク駆動フレームワーク。大部分の開発者は AgentChat API を使用しますが、Core API の変更が間接的にコードに影響します。

Model Client 設定方法が変わりました。v0.2 は OpenAIWrapper(config_list=config_list) を使用し、config_list はリストで各要素が独立した設定辞書。v0.4 は OpenAIChatCompletionClient(model="gpt-4o", api_key="sk-xxx") を使用し、パラメータを直接渡します。コード比較：

# v0.2
from autogen import OpenAIWrapper

config_list = [
    {"model": "gpt-4", "api_key": "sk-xxx"},
    {"model": "gpt-3.5-turbo", "api_key": "sk-yyy"}
]
client = OpenAIWrapper(config_list=config_list)

# v0.4
from autogen import OpenAIChatCompletionClient

client = OpenAIChatCompletionClient(
    model="gpt-4o",
    api_key="sk-xxx"
)

AssistantAgent の初期化も変わりました。v0.2 の AssistantAgent は llm_config パラメータを受け取ります。v0.4 は直接 model_client を渡します。Group Chat API の変更はさらに大きく：v0.2 の GroupChat と GroupChatManager が v0.4 の RoundRobinGroupChat または SelectorGroupChat に統合されました。AutoGen でマルチエージェント協議を行う場合、この部分のコードはほぼ書き直しが必要です。

pyautogen PyPI パッケージは 0.2.34 バージョン以降、Microsoft によるメンテナンスが終了しました。移行ガイドによると、新しいパッケージ名は autogen（py プレフィックスなし）ですが、古い pyautogen もまだ使用されており、混同しやすいです。移行前にどちらのパッケージを使用しているか確認してください。

LangGraph の API 安定性は比較的良好です。v0.2 から v1.2 まで、コア API（StateGraph、add_node、add_edge）に破壊的変更はありません。追加機能（RetryPolicy、TimeoutPolicy、interrupt）は拡張で、既存コードに影響しません。これは LangChain エコシステム全体の安定性に関連——LangChain チームは API 設計で後方互換性を重視し、移行コストを削減しています。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

AutoGen v0.2 から v0.4 への移行時、15 エージェントの Group Chat プロジェクトで 2 週間の改修が必要でした。核心的な問題は Group Chat の協議ロジックが同期から非同期に変更され、既存のイベントリスナーとコールバックがすべて書き直しが必要でした。プロジェクトが Group Chat の複雑な協議メカニズムに依存している場合、移行前にコスト評価を：全体の書き直しより高くなる可能性があります。

LangGraph の移行コストは主に永続化バックエンドに集中します。SqliteSaver から PostgresSaver への変更は設定を 1 行変更するだけで、checkpoint データ構造は不変。カスタム Saver を使用する場合、互換性を自分で処理する必要がありますが、公式 Saver の移行は透過的です。

12 軸の定量化比較と選定の決定

TrueFoundry AutoGen vs LangGraph blog の比較分析によると、2 つのフレームワークの核となる違いを 12 の評価軸で定量化できます。以下の表は各軸にスコア（満点 10 点）を付け、スコアは公式ドキュメントの成熟度、本番事例数、API 安定性、コミュニティ活発度を総合評価。

LangGraph 合計 86 点、AutoGen 合計 66 点。差は主に checkpoint、分散サポート、復旧セマンティクスの 3 軸に現れます。しかし AutoGen は会話の柔軟性とマルチエージェント協議で優位性があります：Group Chat の非同期協議メカニズムは複雑なマルチエージェントシナリオに適し、LangGraph の interrupt は線形フローの人間による介入に適しています。

選定の決定は 2 つの分岐に簡略化できます。エージェントフローが明確な分岐構造（例えばアフターサービスタケット処理、月次メールマーケティング）、長時間タスク（10 ノード以上）、本番環境での永続実行が必要な場合、LangGraph を選択。エージェントがマルチエージェント協議シナリオ（例えば研究者ディスカッション、コードレビュー）、迅速なプロトタイピング（会話駆動の方が直感的）の場合、AutoGen を選択。

本番デプロイには底线設定があります：AI Gateway。Dive into Claude Code の分析によると、安定稼働するエージェントの 98.4% は運用インフラ（監視、リトライ、レート制限、フェイルオーバー）で、AI 決定ロジックはわずか 1.6% です。単一 Provider の API は不安定なため、バックアップルートが必須。コスト監視は API 費用爆発の最後の防衛線。レート制限は Provider からのブロックを回避する鍵。LangGraph でも AutoGen でも、AI Gateway の設定が必須です。

結論

LangGraph の checkpoint、node re-execution、分散永続化ソリューションは、明確なフロー構造、長時間タスク、本番級永続実行のシナリオに適しています。AutoGen の会話駆動と Group Chat 協議は、マルチエージェント相互作用、迅速なプロトタイピングに適しています。選定の鍵はエージェントがフロー駆動か会話駆動かの判断——フロー駆動なら LangGraph、会話駆動なら AutoGen。どちらを選んでも、本番デプロイには AI Gateway（マルチ Provider フェイルオーバー、コスト監視、レート制限）の設定が必須で、これがエージェント安定稼働の底线です。状態管理でトラブルシューティングの経験があれば、コメント欄で共有してください。checkpoint 本番デプロイの完全なコード例が必要ですか？シリーズの後続記事に注目してください。