スケジュールされたスキルが失敗した後の再試行策とは、失敗をあらかじめ分類し、それぞれに対応する反応を定めておく一連のルールを指す。核心は二つの仕組みの組み合わせにある。retry policy（再試行するか、何回するか、間隔をどれだけ空けるか）と fallback instruction（再試行が尽きた後、あるいはそもそも再試行すべきでないと判定された場合にどう締めくくるか）である。これは一般に理解されている「失敗したら通知する」とは異なる。単なる通知は「人がいつ知るべきか」しか扱っておらず、「知る前にシステムが自分で解決を試みるべきかどうか」を扱っていない。これこそ多くのスケジュールタスク設計で飛ばされている段階である。
このニーズが生じるのは、スケジュールタスクが人が手動で行う作業と根本的に異なる点があるからだ。人は一時的なエラーに遭遇すると、ほぼ直感的にもう一度試す。この判断はほとんど考えることなく行われる。しかしスケジュールタスクには傍らに人がおらず、どんな失敗が起きてもあらかじめ書かれたロジックにしか従えない。もしそのロジックが単に「失敗したら通知する」であれば、システムは15分以内に自然に治るはずの一時的な問題も、即座に人が対応すべき事象として一律に扱ってしまう。長期的には大量の誤警報を生み出し、オンコール担当者は次第に通知に麻痺していく。そして本当に対応すべき構造的な問題が発生したとき、「前回も誤報だった」という理由でむしろ反応が遅れてしまう。retry policy と fallback instruction が存在する理由は、人が一時的なエラーに遭遇したときのほぼ直感的な判断を、システムが自動的に実行できる固定ルールとして書き起こすことにある。
実務では三つのことを行う。第一に、よくあるエラーメッセージを一時的なものと構造的なものに分類する。タイムアウト、接続切断、5xx系サーバーエラーは一時的なものに、認証失敗、4xx系リクエストエラー、データ検証エラーは構造的なものに分類し、この分類リストをスケジュールタスクのエラー処理指示に直接書き込む。第二に、一時的な失敗に対する再試行ルールを設定する。指数バックオフの待機間隔（1分、5分、15分）と最大再試行回数（通常3回）を定め、3回とも失敗して初めて人へエスカレーションする。第三に、構造的な失敗や再試行が尽きた場合の fallback instruction を明記する。バックアップのデータソースに切り替えるのか、不完全とマークした部分的な結果を出すのか、単純に止まって人を待つのかは、そのタスクが「不完全な結果をとりあえず出す」ことを許容できるか、完全に正しくなければ使えないかによって決まる。この三つを合わせることで、スケジュールタスクが初めて失敗する前に、失敗処理のロジック全体を設定しておくことができ、失敗のたびにその場で判断する必要がなくなる。
あなたにとって、この設計はオンコール担当者を真夜中に起こすべきかどうかをその場の判断から事前に定めたルールへと変える。これが直接影響するのはチームの通知に対する信頼度だ。通知が頻繁すぎ、かつ誤報が多ければ、人は通知を無視し始める。これは通知が全くないことよりも危険だ。システムは動いているように見えても、実際には警告信号が静かに意味を失っているからだ。設定コストは一回限りで、通常1〜2時間で分類リストと再試行ルールを定められる。その後の保守は、新しいエラー種別に出会うたびに分類リストへ追加し、ルールを現実に即した状態に保つことである。本当に注意すべきなのは、fallback instruction を「静かな失敗」として設計しないことだ。つまり再試行が尽きた後にシステムが自ら止まり、誰もそれに気づかない状態である。これは無闇な再試行よりも危険だ。問題がそのまま存在し続けているのに誰も気づかず、ある日、タスクが実は何日も本当に成功していなかったことに誰かがたまたま気づくまで放置されるからだ。
午前3時、スケジュールされた月次照合タスクが、取引先APIの一時的なタイムアウトで失敗した。システムには二つの選択肢がある。黙って一度だけ再試行する——通常は二回目で成功する——か、即座に通知を出してオンコール担当者を起こすかだ。多くのチームはスケジュールタスクを設計する際、「失敗したら通知する」までしか考えておらず、「通知する前にまず自分で救おうとするかどうか」を詰めていない。この詰め切れていない隙間が、あなたのチームの電話が実際に真夜中に鳴るかどうかを決めている。
一つ目は一時的な失敗だ。取引先のサーバーがタイムアウトした、ネットワークが一瞬途切れた、相手のAPIがちょうどメンテナンス中だった——この種の失敗の特徴は、少し待って同じことをもう一度やれば大抵うまくいく点にあり、本質的には自分でページを再読み込みするのと変わらない。二つ目は構造的な失敗だ。認証情報が期限切れになった、相手のAPI形式が変わった、入力データ自体が最初から間違っていた——この種の失敗の特徴は、何度再試行しても結果が変わらない点にある。問題は今回運が悪かったことではなく、どこかが本当に壊れていることにあるからだ。
この二つを同じものとして扱うことが、多くのスケジュールタスク設計が失敗する出発点になる。一時的な失敗に対して沈黙を保ち黙って再試行するのは合理的だが、構造的な失敗にも同じ「とりあえず再試行」のロジックを適用してしまうと、システムは永遠に開かない扉を無駄に叩き続けることになる。そして本当に叫び起こすべきその一件の通知が届いた頃には、それより前の空振りに終わった「再試行中」の通知のせいで、起こされるべき人は既に無視することを学んでしまっている。
これこそが retry policy（再試行ポリシー）が解決する問題である。失敗時に何回再試行するか、間隔をどれだけ空けるか、待機時間をどう増やしていくかを明記する。よくある方式は指数バックオフで、一回目は1分待ち、二回目は5分、三回目は15分待ち、三回とも失敗して初めて人へエスカレーションする。この設計の狙いは、一時的な問題が自然に回復するのに十分な時間を与えつつ（取引先のメンテナンスは通常15分を超えない）、際限なく待ち続けることも、一回目の失敗で即座に人を起こすこともしない点にある。実際、多くの一時的な問題は二回目の再試行が始まる前に既に自然解決している。
しかし retry policy が答えられるのは「何回再試行するか」だけだ。「そもそもこの失敗を再試行すべきか」には答えられない。だからこそ、もう一つの仕組みと組み合わせる必要がある。
fallback instruction（フォールバック指示）が扱うのは、再試行ポリシーが尽きた後、あるいは最初から構造的な失敗だと判定された場合にどうするかだ。バックアップのデータソースに切り替えるのか、不完全であるとマークした部分的な結果を出すのか、あるいは単純に止まって人を待つのか。この仕組みがなければ、再試行が尽きたあとシステムは黙って停止することが多く、タスクが実際には諦めていたことに誰も気づかない。両方揃って初めて完全な失敗処理になる。retry policy はもう一度試すかどうかを決め、fallback instruction は試しても駄目だったときにどう締めくくるかを決める。
二種類の失敗を見分ける鍵は、エラーメッセージ自体が分類可能かどうかにある。タイムアウト、接続切断、相手からの5xx系サーバーエラーは概ね一時的なものに分類できる。認証失敗、相手からの4xx系リクエストエラー、データ検証エラーは概ね構造的なものに分類できる。この分類ロジックをスケジュールタスクのエラー処理指示に書き込んでおけば、Claude はエラーの種類に応じて再試行するかすぐにエスカレーションするかを自動で判断でき、あらゆる失敗に同じ反応を適用せずに済む。
retry policy がないことの代償は二種類ある。一つは、15分待てば自然に治る一時的な問題のために午前3時に人を起こしてしまい、長期的には「通知が来てもとりあえず放置しておけばそのうち治る」という態度を人に植え付けてしまうこと。もう一つは、再試行の仕組みが一切なく、一時的な不調がすべてタスク失敗としてそのまま報告され、本来対応不要だった大量のノイズが発生することだ。本当に投資すべきなのは retry policy と fallback instruction を設計する一回限りの作業であり、通常は1〜2時間程度で済む。その見返りとして、以降のあらゆる失敗が同じロジックで自動的に判断されるようになり、その場のオンコール担当者がその都度その場しのぎで判断し、基準が緩くなったり厳しくなったりすることがなくなる。本当に人の労力を割くべきは、再試行しても直らない本物の構造的問題であって、「これはまた単なるネットワークの揺らぎか」を毎回確認することに労力を浪費すべきではない。