AIワークフローのエラー処理——リトライ設計

🚧実際に起きたこと: レート制限で完全に止まった

エラーは「起きるかもしれない」ものではなく、実際に起きるものとして設計する必要があります。

先日、複数の情報源を横断して裏取りする重い調査タスクを走らせていたところ、利用しているモデルのレート制限に達し、タスクが完全に失敗するということがありました。原因が分かった時点で、別のモデルに切り替えて同じタスクをやり直したところ、無事に完走しました。同じ失敗を繰り返さないための一番シンプルな対処は、「同じ手段に固執せず、別の経路を試す」ことだと実感しました。

🔁リトライは「同じことをもう一度」ではない

失敗した処理をそのまま再実行するだけでは、同じ理由でまた失敗することがあります。

レート制限のようなエラーの場合、単純に同じモデル・同じ条件で再試行しても、同じ制限に再び引っかかるだけのことがあります。実際に起きた先述のケースから学んだのは、「原因が変わらない限り、同じ手段への再試行は意味を持たない」という単純な事実です。原因がモデル側のリソース枯渇なのであれば、待つより先に、モデルや経路そのものを切り替える方が早く復旧できる、という考え方を持つようになりました。

🩹一部の失敗が全体を巻き込まない設計

並行実行の仕組みの中には、一部の失敗を全体の失敗にしない設計が既に組み込まれていることがあります。

私たちが使っている並行実行の仕組み（複数のAIエージェントを同時に走らせる機構）は、複数のタスクをまとめて実行するparallel()のような関数として組まれています。この種の関数は、内部のタスクが一つ失敗しても処理全体を止めず、失敗した箇所の結果をnull（値が無いことを表す印）として返し、残りのタスクは実行を続ける、という設計になっています。実際にこの結果を使う側では、nullになった箇所を後から取り除いて（フィルタして）、成功した分だけで次の判断に進めます。全てが揃わないと何も進められない設計だと、一箇所の失敗がタスク全体を止めてしまいますが、「失敗はnullとして扱い、成功した部分だけで進める」という設計があると、その心配が減ります。

🧭まとめ: 失敗を前提に設計する

整理します。①エラーは起きるものとして設計する②失敗の種類に応じてリトライの仕方を変える③一部の失敗が全体を巻き込まない縮退運転を組み込む④同じ手段に固執せず別の経路を用意しておく。

長時間AIに作業を任せるほど、エラーへの向き合い方そのものが、成果を左右する設計上の要点になると感じています。

📚参考・出典

本文の対応は私たちが自社のAI実行ループで実際にやっていることです。リトライや縮退運転の一般的な設計原則としては、以下の一次資料を参照しています。

• Amazon Builders' Library: Timeouts, retries, and backoff with jitter（素朴な再試行が障害を増幅させる理由と、待ち時間の設計）
• AWS: Retry behavior（SDK のリトライ仕様）（再試行回数の上限とエラー種別による分岐の実装例）
• Google SRE Book: Addressing Cascading Failures（一部の失敗を全体に波及させない縮退運転の考え方）