LangGraphの障害耐性設計——RetryPolicy・TimeoutPolicy・error_handlerが本番エージェントに必要な理由
LangGraphが障害耐性のための3つのプリミティブ（RetryPolicy・TimeoutPolicy・error_handler）を正式にサポートした。エージェントを「デモが動く」から「本番で壊れない」に引き上げるための、地味だが本質的なアップデートだと私は見ている。
出典: Fault Tolerance in LangGraph: Retries, Timeouts, and Error Handlers
要点 (事実のみ)
- LangGraphはStateGraphの各ノードに対し、
RetryPolicy・TimeoutPolicy・error_handlerの3つをadd_nodeで直接アタッチできる設計になった RetryPolicyは指数バックオフ・ジッター付きで、デフォルトではConnectionErrorや5xxレスポンスのみをリトライ対象とし、ValueError・TypeErrorなどプログラミングバグは対象外TimeoutPolicyは「ハードな壁時計上限（run_timeout）」と「進捗ベースのアイドル上限（idle_timeout）」の2種類をサポート。ストリーミング中はidle_timeoutがリセットされるerror_handlerはリトライ枯渇後にのみ発火し、失敗コンテキスト（NodeError）を受け取って補償ロジックを実行できる。エラーハンドラーにさらにエラーハンドラーを設定することはできない- 記事ではフライト予約（座席予約→決済→発券）を例に、SAGAパターンを
set_node_defaultsとerror_handlerで実装するコードを紹介している
徐 聖博の見解
エージェントの信頼性という問題を、私はIndeedでの推薦システム運用やシンシアでの受託開発を通じて繰り返し経験してきた。「ハッピーパスは書けた、でも本番に出したら外部APIの5xxとタイムアウトで詰まった」というのは、どのプロジェクトでも必ず一度は通る道だ。
今回のLangGraphの設計で評価したい点は2つある。
第一に、ボイラープレートの削除先が正しい場所にあること。リトライのwrapperを各ノード内に書くのではなく、ワークフローエンジン側に移したことで、「誰がリトライ責任を持つか」の構造的な曖昧さが消える。retryロジックがノードのビジネスロジックに混入しないため、ノード自体がテストしやすい。
第二に、error_handlerの原子性の設計が実用的だと感じた。「元のノードが失敗したらチェックポイントにERROR書き込みをコミットし、ハンドラータスクを同一ステップで再スケジューリングする」という仕様は、ホストプロセスがクラッシュしても補償ロジックが再開される保証を与える。SAGAパターンを分散システムで素直に実装しようとすると、まさにここ（部分コミットとリカバリーの一貫性）が最も厄介な部分で、それをランタイム側が保証してくれるのは開発コストとして大きい。
一方で冷静に見ると、これらのプリミティブは「正しく設定されれば機能する」ものであり、設定の責任は依然として開発者にある。リトライ対象の例外クラス選定、idle_timeoutの閾値、補償ロジックの冪等性の担保——これらを間違えると、ランタイムが親切であるがゆえに「静かに誤った方向へ補償し続ける」事故が起きる。特にSAGAパターンの補償ノードは、各ステップが冪等であることを前提に成り立つ設計だが、その冪等性の担保はアプリケーション側の責任のままだ。
Xincereで企業向けAIエージェントのPoC・初期導入を支援している立場から言えば、発注側がこの記事に注目すべき含意は「エラーハンドリングの設計工数をフロントに積む必要がある」という点だ。プロトタイプのデモコストと、本番のエラーハンドリングコストは同等かそれ以上になることが多い。ベンダーや開発会社にエージェントを依頼する際は、リトライ・タイムアウト・補償ロジックの設計方針を要件定義の段階で明示的に議論することを強く勧める。
(編集レンズ: 実装・運用視点 / 発注側・中小企業・開発実務への含意)
