RPAで失敗する原因は「リトライ設計」にある。現場で効いたシンプルな対策 #業務自動化 #WEB自動化

RPAで「リトライ」を入れるのは当たり前ですが、
どこにでも入れていいわけではありません。

むしろ、設計を間違えると
二重処理という別の事故を生みます。

私は現在、リトライを入れる場所を明確に制限しています。

■ 結論：リトライは“ログイン”に限定する

私の設計では、基本的にリトライはこの2箇所です。

• Webのログイン処理（最大3回）

• SMTPのメール送信（最大3回）

逆に、それ以外の業務処理では
基本的にリトライを入れません。

■ なぜログインはリトライしてよいのか

理由はシンプルで、状態を持たないからです。

ログイン処理は、

• 何回やっても結果は同じ

• 副作用がない

• データ更新が発生しない

つまり、ステートレスな処理です。

そのため、

1回目：失敗（通信・描画遅延）
2回目：成功

というケースを安全に吸収できます。

実際、運用上も「2回目で復活する」ケースが非常に多いです。

■ 業務処理にリトライを入れてはいけない理由

一方で、ログイン後の処理は全く別です。

• データ登録

• 更新処理

• アップロード

これらはすべて、**状態を変える処理（ステートフル）**です。

ここで安易にリトライを入れると、

• 2回登録される

• 2回更新される

• 同じデータが重複する

といった問題が発生します。

さらに厄介なのは、

という点です。

この判断は、最終的には
人間が画面やデータを見て判断するしかありません。

そのため私は、

業務処理は“失敗したら止める”設計にしています。

■ リトライの境界は「副作用があるかどうか」

整理すると、判断基準はこれです。

• リトライOK：副作用なし（ログインなど）

• リトライNG：副作用あり（登録・更新）

この「境界設計」が、RPAの安定性に直結します。

■ SMTPは例外的にリトライする

メール送信は少し特殊です。

• タイムアウトが発生する

• 一時的に送信失敗する

にもかかわらず、

• 処理全体はエラーにならないことがある

• 送信失敗に気づきにくい

という特徴があります。

さらに問題なのは、

• どのメールが失敗したか特定が面倒

• 手動リカバリのコストが高い

という点です。

そのため、

SMTPは例外的にリトライを入れる価値が高い処理です。

■ ログ設計もセットで考える

SMTPについては、リトライだけでなく

• 送信失敗ログを残す

• 対象データを特定できるようにする

といった運用設計も重要になります。

リトライで吸収できなかった場合の
「次の一手」を用意しておくことが前提です。

■ 3回という回数の意味

経験上、

• 1回目失敗 → 2回目成功：非常に多い

• 3回目まで行く：まれ

です。

3回すべて失敗するケースは、

• パスワード期限切れ

• システム仕様変更

• 根本的なエラー

など、リトライでは解決しない問題がほとんどです。

■ 発展：PW期限の検知

そのため最近は、

• 「パスワード期限のポップアップ」を取得

• 残り日数をメール通知

という仕組みも入れています。

これにより、

• 突然ログインできない

• RPAが連続失敗する

といった事故を未然に防げています。

■ まとめ

RPAのリトライ設計で重要なのは、回数ではありません。

どこまでリトライしていいかを決めることです。

• ログインはリトライする（安全）

• 業務処理はリトライしない（危険）

• SMTPは例外的にリトライする（コストが高いため）

この線引きをするだけで、
RPAの安定性と運用性は大きく変わります。

RPAの設計は、ツールよりも考え方で安定性が決まります。
もし「なぜか不安定」「エラーが多い」と感じている場合は、一度設計を見直すだけで改善するケースも多いです。

スキを押してもらえると励みになります。コメント・質問もぜひお待ちしています。役立ったと感じたらシェアしていただけると嬉しいです。