failure-recovery

障害からの復旧

エージェントは失敗します。ネットワークはタイムアウトし、モデルは幻覚を起こし、ツールはエラーを返し、想定外のケースに直面することもあります。障害からの復旧をどのように設計するかによって、障害が行き止まりになるか、スムーズな迂回路になるかが決まります。

マルチエージェントシステムにおける障害の種類

• エージェントの障害：単一のエージェントがクラッシュする、タイムアウトする、または無効な出力を生成する
• 引き継ぎの失敗：エージェント間での受け渡し中にコンテキストが失われる、または破損する
• 調整の失敗：エージェント同士が衝突する、デッドロックする、または一貫性のない結果を生成する
• リソースの障害：外部ツール、API、またはデータソースを利用できない
• 連鎖的な障害：あるエージェントの障害により、後続のエージェントも失敗する

復旧戦略

• 再試行：同じ操作をもう一度実行します。一時的なエラー（ネットワークのタイムアウト、レート制限）に有効です。無限ループを避けるため、再試行の上限を設定します。
• フォールバック：別の方法に切り替えます。異なるエージェント、より簡単な方法、またはキャッシュされた結果を使います。
• エスカレーション：より高性能なエージェント、または人間に問題を引き継ぎます。現在のエージェントでは解決できない障害が発生した場合に使用します。
• 段階的な縮退：何も返さないのではなく、部分的な結果を提供します。何ができて何ができなかったかをユーザーに伝えます。
• 補償処理：再試行またはエスカレーションの前に、部分的に完了したワークフローの影響を取り消します。

復旧経路の設計

ワークフローで障害が発生する可能性がある各時点について、次の点を検討します。

• 何が失敗する可能性があるか？ 障害モードを列挙します
• 最初に取る復旧戦略は何か？ 通常、一時的なエラーには再試行します
• フォールバックは何か？ 再試行に失敗した場合、代替策は何ですか？
• いつエスカレーションするか？ 再試行の回数、またはどのような種類の障害を基準にしますか？
• ユーザーには何が見えるか？ 障害を明示するか、それとも気づかれないように復旧するか？
• 最悪のケースは何か？ すべての復旧に失敗した場合、どのように段階的に縮退しますか？

障害時のユーザー体験

• 見えない復旧：ユーザーに気づかれないように、システムが再試行またはフォールバックします。軽微ですぐに解決する障害に最適です。
• 透明性のある復旧：問題が発生したことと、どのように対処しているかをシステムがユーザーに伝えます。「通常より時間がかかっています。別の方法を試しています。」
• ユーザー参加型の復旧：システムがユーザーに協力を求めます。「カレンダーにアクセスできませんでした。接続を確認していただけますか？」
• 正直な失敗：タスクを完了できないことと、その理由をシステムがユーザーに伝えます。代替案を提示します。

設計成果物

• エージェントごと、および引き継ぎごとの障害モード一覧
• 復旧戦略の仕様（再試行の上限、フォールバック経路、エスカレーションのトリガー）
• 連鎖的な障害の分析
• 各障害シナリオにおけるユーザー体験の仕様
• 復旧テストの手順