LangGraph のフォールトトレランス: リトライ、タイムアウト、エラーハンドラ

実際のプロダクション環境では、AIエージェントはプロトタイプでは決して発生しないエラーに直面します：ネットワーク障害、ツール呼び出しエラー、LLMのレート制限。長時間実行中のタスクが途中で回復不可能なエラーに遭遇した場合、どうすべきでしょうか？実行を破棄して最初からやり直す？それは持続可能な方法ではありません。正常系を書くのは通常簡単ですが、プロダクションで生き残るためのエラーハンドリングのボイラープレートコード（リトライ、タイムアウト、フォールバック）は、ビジネスロジックそのものよりも長くなることがよくあります。

LangGraphはこれを第一級の関心事として扱います。これは、エージェントを一連の離散ステップ（ノード）としてモデル化し、グラフとして整理する低レベルオーケストレーションフレームワークです。LangGraphが実行を制御するため、ステップのいずれかが失敗した場合の処理も適切な場所です。この記事では、LangGraphがボイラープレートを処理する3つのプリミティブを紹介します：RetryPolicy（指数バックオフとジッター付き自動リトライ）、TimeoutPolicy（ウォールクロックまたは進捗ベースのタイムアウト）、および error_handler（リトライを使い果たした後に実行され、失敗コンテキストを持つノード）。それらがどのように構成され、ワークフローエンジン内部に存在することが重要であるか、特にクリーンアップ/補償ロジックを考慮し始めるときに説明します。

LangGraphでは、StateGraphにノードとエッジを追加してエージェントを定義します。3つのプリミティブはすべて add_node を介してノードに直接アタッチされるため、フォールトトレランス設定は保護するロジックの隣にあります。RetryPolicyは指数バックオフ、オプションのジッター、および構成可能な例外述語をサポートします（デフォルトでは ConnectionError と 5xx 応答のみをリトライ）。TimeoutPolicyは run_timeout（ハードウォールクロックキャップ）と idle_timeout（進捗がない場合のアイドルタイムアウト）を提供し、ハートビートでリフレッシュできます。タイムアウトが発生すると、ノード試行はキャンセルされ、NodeTimeoutError が発生します。

エラーハンドラはリトライを使い果たした後にのみ実行されます。これにより、支払いプロバイダーがダウンし続けた後、注文を失敗としてマークし、顧客に通知し、部分的な副作用をロールバックし、またはイベントを公開するなどのユースケースが可能になります。LangGraphでは、エラーハンドラは NodeError オブジェクト（失敗したノード名と例外を含む）を受け取り、状態遷移はアトミックです：元のノードが失敗すると、その ERROR 書き込みがチェックポイントにコミットされ、ハンドラタスクは同じスーパーステップ内でスケジュールされます。これにより、ホストプロセスがハンドラの途中でクラッシュした場合、次回の再開時に元の失敗ノードではなくハンドラが再スケジュールされることが保証されます。

3つのプリミティブの真の力は、フライト予約などの副作用を伴うワークフローで発揮されます。各ステップ（座席予約、支払い処理、チケット発行）は外部システムと通信し、いずれも失敗する可能性があります。単純な全体リトライアプローチは、座席が予約されたが支払いが失敗した場合など、状態の不整合を引き起こします。SAGAパターンは、分散システムでこのような障害を処理する標準的な方法です。LangGraphでは、各ステップに同じリトライポリシーとエラーハンドラを設定できます。エラーハンドラはフローを補償ノードにルーティングし、補償ノードは完了したステップのリストを調べて逆順に取り消します。

LangGraphの retry_policy、timeout、error_handler により、さまざまなエラーに対して回復力のあるエージェントを簡単に構築できます。自分たちのユースケースに適したポリシーを定義するだけで、LangGraphのエージェントランタイムが残りを処理します。