一時的なエラーへのリトライ設計（何回・何秒待つか・どこからやり直すか）

一時的なエラーと恒久的なエラーを分ける

ロボットが止まる原因には、時間をおいてやり直せば成功するものと、何度やり直しても失敗するものがあります。前者は、サーバーの応答が遅れたことによるタイムアウト、ネットワークの瞬断、画面の描画が終わる前に次の操作をしてしまった、といったものです。後者は、入力データの不備、ログインできないアカウント、画面の項目が変わってしまった、などです。

リトライが効くのは前者だけです。後者に対してリトライを繰り返しても、実行時間が延びるだけで、場合によっては相手のシステムに余計な負荷をかけたり、アカウントをロックさせたりします。リトライを設計する最初の一歩は、「どのエラーなら再試行してよいか」を決めておくことです。

• リトライしてよい例：タイムアウト、接続エラー、画面の読み込み待ちで要素が見つからない
• リトライしてはいけない例：認証エラー、入力値のチェックエラー、権限がないという画面、項目自体が存在しない

回数と待ち時間の決め方

回数は、多くの業務で2〜3回あれば十分です。それ以上やり直しても成功しない場合は、一時的な問題ではない可能性が高いと考えて、エラーとして記録し、人に知らせる方が早く解決します。

待ち時間は、すぐにやり直すより、少し間を空ける方が成功しやすくなります。たとえば1回目は10秒、2回目は30秒、3回目は60秒のように、回を重ねるごとに長くする方法がよく使われます。相手のシステムが混み合っている時間帯に、短い間隔で何度もアクセスすると、かえって状況を悪くすることがあるためです。

1件あたりのリトライの合計時間が、全体のスケジュールに収まるかも確認しておきます。100件を処理するロボットで、各件が最大で数分リトライすると、夜間バッチの終了時刻を大きく過ぎてしまうことがあります。

どこからやり直すか

失敗した操作だけをやり直せばよい場合と、もう少し前に戻る必要がある場合があります。たとえば検索結果の一覧が表示されなかったときは、検索ボタンを押す操作からやり直せば済みます。一方、セッションが切れてログイン画面に戻されてしまった場合は、ログインからやり直さなければ先に進めません。

設計のときは、処理を「ログイン」「検索」「1件の登録」のような単位に分け、それぞれの単位の頭に戻れるようにしておくと整理しやすくなります。BizRobo! では、Try ステップを使ってエラー時に別の分岐へ進める考え方が基本になります。Try ステップの使い方そのものは別の記事で解説しています。

リトライしてはいけない処理（二重登録の危険）

最も注意が必要なのは、登録・送信・申請のように、相手のシステムにデータを書き込む操作です。登録ボタンを押した後にタイムアウトしても、相手のシステムでは登録が完了していることがあります。この状態でそのまま登録をやり直すと、同じデータが2件登録されてしまいます。

書き込みの操作で失敗したときは、やり直す前に「登録されていないこと」を確かめる手順を入れます。受付番号や申込番号で検索し、すでに登録されていればやり直さずに「登録済み」として記録します。確認の手段がない場合は、リトライせずにエラーとして人に判断を任せる方が安全です。

• 書き込みの前：入力値のチェックで弾けるものは先に弾く
• 書き込みの後に失敗：まず登録の有無を検索して確認する
• 確認できない：リトライせず、件名と状況を記録して人に回す

リトライの記録を残す

リトライで最終的に成功した場合も、「何回目で成功したか」を記録しておくことをおすすめします。成功しているので見過ごされがちですが、リトライの回数が日に日に増えている場合は、相手のシステムの性能低下や、画面の変更の前兆であることがあります。

ログの残し方や通知の考え方は、通知とログの記事で詳しく扱っています。リトライ回数を月に一度でも集計して見る習慣があると、ロボットが止まる前に手を打てるようになります。

ほかの記事