LangGraph vs AutoGen の状態追跡比較：Checkpoint の仕組み、タイムアウト復旧と選定判断

30 ステップの学術文献整理エージェントが、2 時間 40 分かけて実行されていた。

25ステップ目で、データベースAPIがタイムアウトしてクラッシュ。

前の24ステップが全部無駄になった。API呼び出しのコスト、待ち時間、生成済みの論文要約——全部ゼロに。

これは珍しいケースじゃない。AutoGenで複雑なワークフローを組んだ経験があるならわかるはず。状態が制御できなくて、エージェントが暴走して、問題の調査に開発時間の3倍を費やした。その後LangGraphに切り替えたら、シンプルなプロトタイプでさえ100行以上の状態定義コードを書く羽目になった。どちらのフレームワークでも痛い目を見ている。

LangGraphとAutoGenの状態管理は、設計思想が根本的に違う。一方は明示的なステートマシンでフローを制御し、もう一方は対話型プロトコルでエージェントに自由な協調を許す。フレームワーク選択を間違えると、エージェントプロジェクトの80%はLLMの能力不足ではなく——状態追跡という道を最初から間違えたせいで失敗する。

この記事では、チェックポイント機構、タイムアウト復旧、分散サポートなど12の観点から2つのフレームワークを比較する。実際の失敗事例、選定フローチャート、実行可能なコード付き。読み終われば、あなたのプロジェクトにどちらが適しているか、すぐに判断できるはずだ。

状態管理の死活ライン：なぜチェックポイントがエージェントの生命線なのか

クライアント向けに学術文献整理エージェントを開発した。学術データベース API を連続 10 回呼び出し、200 本の文献要約を整理し、レビュー報告書を生成する。

実行時間は3時間と見積もっていた。25ステップ目（全30ステップ）でデータベースAPIがタイムアウトしてクラッシュ。

従来のエージェントはステートレス——前の24ステップが全部無駄になった。生成済みの論文要約、API呼び出しコスト、2時間40分の待ち時間、すべてゼロに。再実行では最初からやり直しで、APIコストをもう一度支払う必要がある。

クライアントの質問：25ステップ目から再開できない？

答え：できない。従来のエージェントの状態はメモリにしか存在せず、プロセスが中断されたら消えてしまう。

従来のエージェントがステートレスな5つの災難

この穴にはまった。当時はAutoGenで複雑なアフターサービスチケット処理フローを構築していて、状態が制御できず、エージェントが暴走。問題の調査に開発時間の3倍を費やした。後にLangGraphで状態グラフを定義したが、シンプルなプロトタイプで100行以上のコードを書く羽目になった。

まとめると、従来のエージェントがステートレスだと5つの致命的な問題がある。

1. サービス再起動後にすべての対話履歴が消失

新バージョンのデプロイ、サーバーメンテナンス、予期せぬクラッシュ——どのプロセス終了も状態をクリアする。ユーザーが進行中だった対話が、一瞬で途切れる。

2. マルチラウンドタスクの中断後に復旧不可

長時間タスク（論文整理、データ処理パイプライン）が失敗したら、最初からやり直すしかない。30ステップのタスクが25ステップ目でクラッシュしたら、前の24ステップは無駄になる。

3. マルチユーザー同時接続不可、状態が相互干渉

同一エージェントインスタンスで複数ユーザーをさばくと、状態が混ざる。ユーザーAの対話履歴がユーザーBの操作で上書きされ、データ汚染が発生。

4. 履歴の監査とリプレイ不可

本番環境で問題が起きた時、当時エージェントがどう判断したか振り返りたい？記録がない。バグを再現したい？履歴状態がない。

5. 長時間タスク失敗時の全面やり直し

数時間かかるタスク（データ処理、一括生成）の失敗コストは甚大。API費用、時間コスト、ユーザー体験、全部損失。

LangGraph vs AutoGen：チェックポイント成熟度比較

LangGraphとAutoGenのチェックポイント能力には、明確な差がある。

項目	LangGraph	AutoGen
チェックポイントネイティブサポート	各ノードで自動的にスナップショット保存	ロードマップで進化中
本番成熟度	⭐⭐⭐⭐⭐（2026年のデファクトスタンダード）	⭐⭐⭐（まだ進化中）
API安定性	LangChainエコシステムで安定	v0.2からv0.5で大移行、プロジェクトが作り直しに

LangGraphは設計当初からチェックポイント機構を組み込んでいる。各ノードの実行完了後、自動的にStateのスナップショットを保存。クラッシュ後は中断地点から復旧し、完了済みノードは再実行されない。

AutoGenの状態管理はまだ進化中。2024年4月にMicrosoftがPersistence roadmapを公開し、2025年3月になってSave/Load機能（AgentChat.NET）が登場。AutoGen v0.2で開発したプロジェクトはv0.5にアップグレードするとAPIが全滅、コードを書き直す羽目になる。

Checkpoint は「あると便利」程度の機能ではない——エージェントの生命線だ。本番環境で状態の永続化がないなら、丸腰で走っているのと同じ。

LangGraphチェックポイント機構の詳細解説

チェックポイントの本質：「メッセージを保存」じゃなく「グラフの完全な状態を保存」

チェックポイントについて認識のズレがある人が多い——「対話履歴を保存する」だけだと思っている。

実は違う。

チェックポイントが保存するのは、Graphがある実行ステップでの完全な状態スナップショット。以下を含む：

• すべてのChannel（Stateの各フィールド）の現在値
• 現在どのノードまで実行されたか
• 親チェックポイントID（バージョンチェーンを形成）
• タイムスタンプとメタデータ

Gitのコミット履歴に似ている：各ノード実行で「コミット」が生成され、任意の履歴ノードにチェックアウトして再実行可能。これは対話履歴のバックアップじゃなく、ワークフロー全体の状態スナップショットだ。

Checkpoint v4データ構造の詳細

LangGraphは現在Checkpoint v4を使用し、7つのコアフィールドを含む。LangChain公式ドキュメントの定義によると：

class Checkpoint:
    v: int                  # バージョン番号（現在は4）
    ts: str                  # タイムスタンプ（ISO形式）
    id: str                  # UUID、スナップショットの一意識別子
    channel_values: dict     # Stateの各フィールドの現在値
    channel_versions: dict   # 各フィールドのバージョン番号、衝突検出に使用
    versions_seen: dict      # 各ノードが参照したバージョンを記録、重複処理を回避
    pending_sends: list      # 送信待ちのメッセージキュー

channel_versionsを重点的に解説——これは無駄なフィールドじゃない。

LangGraphはバージョン番号で「あるノードを再実行すべきか」を判断する。これが中断再開の根拠：復旧時、各Channelのバージョン番号をチェックして、実行済みノードをスキップする。

thread_id：マルチセッション分離の「パラレルワールド座標」

同一Graphインスタンスで無数の対話スレッドをさばける。

各スレッドは独立したチェックポイントシーケンスを持ち、互いに干渉しない。thread_idで区別する。

ゲームのセーブスロットに例えると：各thread_idは独立したセーブファイル。ユーザーAの対話状態はユーザーBに影響しない。

config = {"configurable": {"thread_id": "user-001"}}
result = graph.invoke(input, config)

thread_idを変えれば、別のパラレルワールドになる。

Super-Step実行フロー

LangGraphの実行フローはSuper-Stepと呼ばれる。LangChain公式ドキュメントの記述によると：

[前のチェックポイントを読み込み] 
  ↓
[現在のノードを実行、Stateを更新]
  ↓
[新規チェックポイントを書き込み（スナップショット）]
  ↓
[次のステップを決定：継続/待機/終了]

各ノードの実行完了後、自動的にチェックポイントを保存。クラッシュ後の復旧は中断地点から継続。

3種類のチェックポイント保存バックエンド比較

保存タイプ	適用シナリオ	特徴
MemorySaver	開発デバッグ	メモリ保存、再起動で消失
SqliteSaver	単体本番	SQLite永続化、軽量
PostgresSaver	分散本番	PostgreSQL、pause/resume、分散対応

開発段階ではMemorySaverを使い、デバッグに便利。本番環境ではPostgresSaverで、分散デプロイにネイティブ対応。

RedisSaverは高並行シナリオに適し、読み書きが高速。

中断再開の実践

冒頭のケースに戻る：30ステップの論文整理エージェント、25ステップ目でタイムアウト失敗。

LangGraphのCheckpointerで、中断地点から復旧：

# 7ステップ目で失敗後に復旧
config = {"configurable": {"thread_id": "research-001"}}
recovered_state = compiled_graph.invoke({"step": 7}, config)
# 前6ステップを自動スキップ、7ステップ目から継続

同じthread_idで、直近のチェックポイントをロードし、実行を継続。

前の24ステップは再実行されない。API費用、生成済みコンテンツ、すべて保持。

AutoGen状態追跡の現状：ロードマップ進化のコスト

状態管理ロードマップの変遷

AutoGenの状態管理は、まだ進化の途上にある。

GitHub Issue #2358の記録によると、2024年4月にMicrosoftがPersistence and state management roadmapを公開。AutoGen v0.2からv0.5へのAPI大移動で、プロジェクトが作り直しに。

この穴にはまった。AutoGen v0.2で開発したプロジェクトは、v0.5にアップグレードするとAPIが全滅。ConversableAgent、GroupChatといったコアクラスのインターフェースが変わった。コードを書き直す必要があった。

2025年3月、Save/Load for AgentChat.NET PR (#5841)が公開。AgentChatエージェントとチームがスナップショットにロールバック可能に（Issue #4100）。SingleThreadedAgentRuntime state serializationがドキュメント化（Issue #4108）。

状態管理能力は備わったが、成熟度はLangGraphに劣る。

終了条件制御：4種類のヒューズ機構

AutoGenには痛点がある：2つのエージェントが「シングルクォートかダブルクォートか」で50ラウンド議論し、$5のAPI費用を消費する。

あるいは夜間自動タスクが対話終了せずに8時間稼働し、翌朝に請求額が爆発していることに気づく。

AutoGen v0.4はイベント駆動アーキテクチャを採用し、メッセージループが継続的にリッスン。終了条件がなければリソースブラックホールを形成。

AutoGen公式ドキュメントによると、4種類の終了条件を提供：

終了タイプ	制御項目	適用シナリオ
MaxMessageTermination	ラウンド数制御	総メッセージ数を10以下に制限
TextMentionTermination	コンテンツ制御	「TERMINATE」キーワードを検出
TimeoutTermination	時間制御	長時間ハングアップによる接続占有を防止
TokenUsageTermination	コスト制御	予算超過を防止

組み合わせて使用：

from autogen_agentchat.conditions import (
    MaxMessageTermination, 
    TimeoutTermination,
    TokenUsageTermination
)

# 終了条件を組み合わせ
termination = (
    MaxMessageTermination(max_messages=20) 
    | TimeoutTermination(timeout_seconds=3600)
    | TokenUsageTermination(max_tokens=10000)
)

いずれかの条件に達すると、対話が終了。ヒューズ機構が無限ループを防止。

対話型プロトコル vs ステートマシン：暗黙 vs 明示の哲学的違い

AutoGenとLangGraphの設計哲学は、根本的に異なる。

AutoGenは対話型プロトコル（Conversational Programming）を使用：

• ConversableAgent：対話可能なエージェント基底クラス
• GroupChat：複数エージェントをグループチャットに投入
• GroupChatManager：次に誰が発言するか決定（ラウンドロビン、自動選択、カスタム戦略）

エージェントはチャットできるエンティティで、自然言語の対話で協調。状態は対話フローに暗黙的に埋め込まれ、LangGraphのような明示的管理はない。

LangGraphはステートマシン（State Machine）を使用：

• State TypedDict：状態構造を明示的に定義
• Node：各ノードの処理ロジック
• Edge：ノード間の接続と条件分岐

各ステップの実行、状態の変化、次の行き先、すべて明示的に定義。

AutoGenは柔軟な対話フローに適する——次に誰が発言するか不明確で、エージェントに自由な協調を許可。

LangGraphは精密な制御に適する——条件分岐が明確で、フローパスが予測可能。

チェックポイントシリアライズ能力（AgentChat.NET）

AutoGenのチェックポイント能力は、シリアライズで実現。

GitHub PR #5841によると、AgentChat.NETはエージェント状態の保存/ロードをサポート：

# 状態をファイルに保存
team.save_state("checkpoint.json")

# ファイルから復旧
team.load_state("checkpoint.json")

これはファイルシリアライズで、データベースの永続化ではない。単体シナリオに適し、分散デプロイには追加の適応が必要。

観測可能性の面では、AutoGenはOpenTelemetryの3本柱を使用：Logs、Metrics、Traces。イベントストリーム監視 + Replayリプレイデバッグで、問題の特定が容易。

コア比較と技術選定：12項目の定量比較

フレームワーク選択は結婚相手選びに似ている——ベストなものじゃなく、あなたに最適なものを。

LangGraphとAutoGenは、エージェントフレームワークの2大技術ルートを代表する：ステートマシン優先のワークフローオーケストレーション、対話優先のマルチロール協調。

12項目定量比較表

項目	LangGraph	AutoGen	スコア差
状態管理モデル	明示的State TypedDict	暗黙的対話フロー	LangGraph +2
チェックポイント機構	ネイティブサポート、各ノードで自動保存	ロードマップ進化中、シリアライズ依存	LangGraph +3
復旧能力	Super-Stepレベル復旧	対話ロールバック（発展中）	LangGraph +2
終了制御	条件エッジ（Conditional Edge）	TerminationConditionクラス	引き分け
永続化メディア	Memory/SQLite/Postgres/Redis	ファイルシリアライズ	LangGraph +2
タイムトラベル	任意履歴ロールバック対応	Replayリプレイ	LangGraph +1
Human-in-the-Loop	interrupt() + Command(resume=)	UserProxyAgent人工プロキシ	LangGraph +1
分散サポート	PostgresSaverネイティブ対応	イベント駆動アーキテクチャ分散適応	LangGraph +1
開発柔軟性	詳細制御、State+Edge定義必要	対話駆動、高速プロトタイプ	AutoGen +1
学習曲線	高、グラフステートマシンの理解必要	中、対話パターンの理解必要	AutoGen +1
API安定性	LangChainエコシステムで安定	v0.2からv0.5で大移行	LangGraph +2
本番成熟度	⭐⭐⭐⭐⭐	⭐⭐⭐	LangGraph +2

総評：LangGraphは状態管理能力でリード（+14点），AutoGenは対話柔軟性でアドバンテージ（+2点）。

これはLangGraphがより優れているという意味じゃない——LangGraphは精密な状態制御が必要なシナリオにより適している。AutoGenは柔軟な対話フロー協調が必要なシナリオにより適している。

適用シナリオ決定フローチャート

どう選ぶ？ニーズを見る。

要件分析
  ↓
明確な条件分岐フローがある？
  ├─ はい → LangGraph
  └─ いいえ → マルチエージェントの自由協調が必要？
      ├─ はい → AutoGen
      └─ いいえ → 長時間タスクのフォールトトレランスが必要？
          ├─ はい → LangGraph
          └─ いいえ → 高速プロトタイプ？
              ├─ はい → AutoGen
              └─ いいえ → デフォルトLangGraph（本番級）

LangGraphが優位なシナリオ

LangGraphはこういうシナリオに適している：

1. 複雑な条件分岐ワークフロー

アフターサービスチケット処理フロー：問題タイプを判断 → 異なる処理パスに振り分け → 結果を集計。条件分岐が明確なら、LangGraphのConditional Edgeで精密に制御。

2. 精密な状態制御が必要な長時間タスク

論文整理エージェント：データベースAPIを連続10回呼び出し、200本の論文を整理、レビューを生成。実行時間3時間、途中クラッシュ時はチェックポイントから復旧必要。LangGraphのSuper-Stepレベル復旧で、完了済みノードは再実行されない。

3. 本番級Human-in-the-Loopレビューフロー

契約レビュー、機密メールレビュー——初稿生成後に一時停止、人工確認を待機。LangGraphのinterrupt() + Command(resume=)で、エレガントな一時停止と再開。

4. タイムトラベルデバッグが必要なシナリオ

バグ再現、A/Bテスト——任意の履歴バージョンにロールバックし、分岐探索。LangGraphのチェックポイントシーケンスは任意のノードにチェックアウト可能。

5. 分散デプロイの高並行エージェントシステム

カスタマーサービスシステム：マルチインスタンスデプロイ、状態共有。PostgresSaverは分散にネイティブ対応、ステートレス競合なし。

AutoGenが優位なシナリオ

AutoGenはこういうシナリオに適している：

1. マルチエージェント自由対話協調

マーダーミステリー推理、ディベートシナリオ——次に誰が発言するか不明確で、エージェントに自由な協調を許可。GroupChatの自動選択戦略で、柔軟な対話フロー。

2. 高速プロトタイプ開発

コンセプト検証デモ——素早く構築、State+Edge定義不要。対話駆動、学習コストが低い。

3. ロールプレイ型協調

コピーライター+デザイナー+運営の議論——異なるロールのエージェントが協調し、リアルなチーム対話をシミュレート。

4. コード生成+実行ループ

Code Executor + UserProxyAgent——コード生成、実行、フィードバック、修正。AutoGenはネイティブでコード実行ループチェーンをサポート。

5. 柔軟な対話フローが必要なシナリオ

次のステップが不明確——GroupChatManagerが誰が発言するか決定、事前のフロー設定不要。

実践コード例：同一要件の2フレームワーク実装

同一の要件で、2つのフレームワークの実装の違いを比較。

要件定義：長時間論文整理エージェント

タスク説明：

• 学術データベースAPIを連続10回呼び出し
• 200本の論文要約を整理
• レビュー報告書を生成

実行時間：約3時間

フォールトトレランス要件：

• 7ステップ目でデータベースAPIがタイムアウト失敗
• チェックポイントから復旧、前の6ステップは再実行しない

Human-in-the-Loop：

• 初稿生成後に一時停止
• 人工確認後に最終稿を生成

LangGraph実装

from langgraph.checkpoint.sqlite import SqliteSaver
from langgraph.graph import StateGraph, END
from typing import TypedDict, Annotated
from operator import add

# State構造を定義
class ResearchState(TypedDict):
    papers: Annotated[list, add]  # 累積、上書きしない
    summaries: Annotated[list, add]
    draft: str
    final_report: str
    step: int
    human_approved: bool

# ノード関数を定義
def fetch_papers(state: ResearchState):
    """学術データベースAPIを呼び出し"""
    step = state["step"]
    papers = call_database_api(step)  # 想定のAPI呼び出し
    return {"papers": papers, "step": step + 1}

def summarize_papers(state: ResearchState):
    """論文要約を生成"""
    papers = state["papers"]
    summaries = generate_summaries(papers)  # 想定の要約生成
    return {"summaries": summaries}

def generate_draft(state: ResearchState):
    """初稿を生成"""
    summaries = state["summaries"]
    draft = generate_report(summaries)  # 想定の報告書生成
    return {"draft": draft}

def human_review(state: ResearchState):
    """人工レビューノード（interrupt後にresume待機）"""
    return {"human_approved": True}

def generate_final(state: ResearchState):
    """最終稿を生成"""
    draft = state["draft"]
    final_report = refine_report(draft)
    return {"final_report": final_report}

# Graphを構築
graph = StateGraph(ResearchState)

# ノードを追加
graph.add_node("fetch", fetch_papers)
graph.add_node("summarize", summarize_papers)
graph.add_node("draft", generate_draft)
graph.add_node("review", human_review)
graph.add_node("final", generate_final)

# エッジを定義
graph.add_edge("fetch", "summarize")
graph.add_edge("summarize", "draft")
graph.add_edge("draft", "review")
graph.add_edge("review", "final")
graph.add_edge("final", END)

# エントリーポイントを設定
graph.set_entry_point("fetch")

# Checkpointerを追加（コア）
checkpointer = SqliteSaver.from_conn_string("research_checkpoints.db")
compiled_graph = graph.compile(
    checkpointer=checkpointer,
    interrupt_before=["review"]  # reviewノード前で一時停止
)

# タスクを実行
config = {"configurable": {"thread_id": "research-session-001"}}
result = compiled_graph.invoke({"step": 0}, config)

# 7ステップ目で失敗後に復旧
# 同一thread_idを使用、前の6ステップを自動スキップ
recovered_state = compiled_graph.invoke({"step": 7}, config)

# Human-in-the-Loop復旧
# 初稿生成後に一時停止、人工確認後に継続
compiled_graph.invoke(
    Command(resume={"human_approved": True}),
    config
)

主な特徴：

• SqliteSaverが各ノード実行後のStateを自動保存
• thread_idで異なるセッションを分離
• 復旧時、実行済みノードを自動スキップ（channel_versionsで判断）
• interrupt_beforeでHuman-in-the-Loopの一時停止を実現

AutoGen実装

from autogen_agentchat.agents import AssistantAgent
from autogen_agentchat.teams import RoundRobinGroupChat
from autogen_agentchat.conditions import (
    MaxMessageTermination,
    TimeoutTermination,
    TokenUsageTermination
)
from autogen_core.models import ChatCompletionClient

# エージェントを定義
research_agent = AssistantAgent(
    name="researcher",
    model_client=ChatCompletionClient(model="gpt-4"),
    system_message="あなたは論文整理アシスタントです。\
        データベースを連続呼び出し、要約を整理、報告書を生成します。\
        完了したら「TERMINATE」と言ってください。"
)

human_agent = AssistantAgent(
    name="human_reviewer",
    model_client=ChatCompletionClient(model="gpt-4"),
    system_message="あなたはレビュアーです。初稿をレビューしたら「APPROVED」または「REJECT」と言ってください。"
)

# 終了条件を設定（無限ループ防止）
termination = (
    MaxMessageTermination(max_messages=50)
    | TimeoutTermination(timeout_seconds=10800)  # 3時間
    | TokenUsageTermination(max_tokens=50000)
    | TextMentionTermination(text="TERMINATE")
)

# チームを構築
team = RoundRobinGroupChat(
    participants=[research_agent, human_agent],
    termination_condition=termination
)

# タスクを実行
async def run_research():
    result = await team.run(
        task="200本の論文要約を整理し、レビュー報告書を生成してください"
    )
    return result

# チェックポイント保存（AgentChat.NET）
team.save_state("research_checkpoint.json")

# チェックポイントから復旧
team.load_state("research_checkpoint.json")

# 実行を継続
async def resume_research():
    result = await team.run()
    return result

主な特徴：

• TerminationConditionが無限ループを防止（ヒューズ機構）
• Save/Loadで状態をファイルに保存（シリアライズ方式）
• イベント駆動アーキテクチャは分散に適応
• 対話型プロトコル：エージェントは自然言語で協調

両者の比較まとめ

特徴	LangGraph	AutoGen
状態定義	明示的TypedDict	暗黙的対話フロー
チェックポイント	各ノードで自動保存（データベース）	ファイルシリアライズ
復旧機構	Super-Stepレベルで実行済みノードをスキップ	対話ロールバック
Human-in-the-Loop	interrupt一時停止 + resume再開	UserProxyAgent介入
終了制御	条件エッジルーティング	TerminationConditionヒューズ
コード量	約60行（State+Edge定義必要）	約30行（対話駆動）

LangGraph：詳細制御、精密な状態管理に適する。

AutoGen：高速プロトタイプ、柔軟な対話協調に適する。

本番級デプロイのアドバイス：開発から本番までの完全パス

LangGraph本番デプロイのポイント

永続化ソリューション：

PostgresSaver + RedisSaverの組み合わせ。

PostgreSQLで永続化ストレージ、分散デプロイにネイティブ対応。Redisはキャッシュレイヤー、高並行シナリオで読み書きが高速。

from langgraph.checkpoint.postgres import PostgresSaver
from langgraph.checkpoint.redis import RedisSaver

# 本番級設定
postgres_saver = PostgresSaver.from_conn_string(
    "postgresql://user:pass@host:5432/db"
)
redis_saver = RedisSaver.from_conn_string(
    "redis://host:6379/0"
)

# 組み合わせ使用：Redisキャッシュ + Postgres永続化
compiled_graph = graph.compile(
    checkpointer=postgres_saver
)

観測可能性：

LangSmithトレーシング + OpenTelemetry統合。

LangSmithでコールチェーン追跡——どのノードが遅いか、どのトークン消費が多いか。OpenTelemetryで既存の監視体系に接続。

パフォーマンス最適化：

ストリーミング出力——ユーザーは最初のトークンを即座に確認、遅延知覚<1秒。

並列ツール呼び出し——LangGraphネイティブサポート、複数ツールを同時実行。

プロンプト事前コンパイル——LLM推論時間を約30%削減。

コスト最適化：

戦略	コスト削減率	適用シナリオ
プロンプト圧縮	30-50%	汎用シナリオ
マルチプロバイダールーティング	40-60%	本番環境フェイルオーバー
キャッシュ機構	50-80%	重複クエリシナリオ

マルチプロバイダールーティングは本番級の標準装備。API Gatewayでフェイルオーバーを実現：GPT-4がダウンしたらClaudeに自動切り替え、コストも40%削減可能。

AutoGen本番デプロイのポイント

観測可能性：

OpenTelemetryの3本柱——Logs、Metrics、Traces。

• EventLogger + 構造化ログ：問題特定、監査追跡
• OpenTelemetry Meter：パフォーマンス監視、容量計画
• OpenTelemetry Tracer：コールチェーン分析、遅延最適化

from autogen_core.telemetry import (
    enable_telemetry,
    EventLogger
)

# 観測可能性を有効化
enable_telemetry(
    logger=EventLogger(),
    meter=OpenTelemetryMeter(),
    tracer=OpenTelemetryTracer()
)

イベントストリーム監視：

Replayリプレイデバッグ技術——すべてのエージェント行動がイベントストリームを生成、リプレイで問題を再現可能。

分散適応：

イベント駆動アーキテクチャは分散にネイティブ対応。エージェント間のメッセージはイベントで伝達、ステートレス競合なし。

コスト制御：

TokenUsageTerminationヒューズ——予算上限に達すると自動終了。

from autogen_agentchat.conditions import TokenUsageTermination

# コストヒューズを設定
termination = TokenUsageTermination(max_tokens=10000)

構造化ログでトークン消費を分析——どの対話が多く消費しているか、どのエージェントのコストが高いか。

本番デプロイ比較表

項目	LangGraph	AutoGen
永続化	PostgresSaver分散対応	ファイルシリアライズ（適応必要）
観測可能性	LangSmithトレーシング	OpenTelemetryの3本柱
コスト制御	マルチプロバイダールーティング	TokenUsageTerminationヒューズ
パフォーマンス最適化	ストリーミング出力+並列ツール	イベントストリーム監視
分散	PostgresSaverネイティブ対応	イベント駆動適応

核心教訓：本番環境にはAI Gatewayが必須

LangGraphを選ぶかAutoGenを選ぶかに関わらず、本番環境にはAI Gatewayが必須。

なぜ？

1. マルチプロバイダーフェイルオーバー

APIがダウンしたら自動切り替え。GPT-4がクラッシュ？Claudeに切り替え。単一障害点を排除。

2. コスト監視

どのエージェントが多く消費しているか、どの対話のコストが高いか——リアルタイム監視。予算超過で自動ヒューズ。

3. レート制限

APIがスロットリングされるのを防止。リクエストキューイング、自動リトライ。

4. ログ追跡

すべての呼び出しを一元記録。問題特定、監査追跡。

AI Gatewayはオプション機能じゃない——本番級エージェントの必須項目だ。

結論

LangGraphとAutoGenは、エージェントフレームワークの2大技術ルートを代表する。

LangGraph：ステートマシン優先のワークフローオーケストレーション。State+Node+Edgeを明示的に定義、各ステップが制御可能。チェックポイントはネイティブサポート、クラッシュ復旧で再実行なし。複雑な条件分岐、長時間タスク、分散デプロイに適する。

AutoGen：対話優先のマルチロール協調。エージェントは自然言語で協調、柔軟な対話フロー。終了条件ヒューズが無限ループを防止。高速プロトタイプ、マルチエージェント自由協調、ロールプレイ型シナリオに適する。

選定は「どちらが良いか」じゃなく「どちらがあなたのシナリオに適しているか」だ。

明確な条件分岐フローがある？LangGraph。マルチエージェント自由協調が必要？AutoGen。長時間タスクでフォールトトレランスが必要？LangGraph。高速プロトタイプ検証？AutoGen。

どちらのフレームワークでも痛い目を見た。AutoGenは状態が制御できず、API移行でコード書き直し。LangGraphは状態グラフ定義で100行以上書いた。

核心教訓：本番環境にはAI Gatewayが必須。マルチプロバイダーフェイルオーバー、コスト監視、レート制限——この3つの機能はエージェント安定稼働の最低ラインだ。

次のステップ：あなたのプロジェクトが複雑なワークフローならLangGraphを選ぼう。高速でマルチエージェントプロトタイプを組みたいならAutoGenを選ぼう。その後、「LangGraph状態管理実践」（シリーズNo.39）を読んで、チェックポイント機構の実践を深めよう。

どちらのフレームワークも使える。重要なのはシナリオの違いを理解し、穴を避けることだ。