Trigger Condition

トリガー条件とは、スケジュールされたタスクが本当にいつ起動すべきかを決めるロジックのことで、単に「何時何分」というだけの単純なものではない。最も基本的なトリガー条件は固定時刻であり、時刻になればタスクが実行される。しかしより完全なトリガー条件は追加の判断を組み込む。例えば「時刻になったが、前段階のデータが既に生成されているかも確認する」、あるいは「時刻になったが、今日が祝日なら実行をスキップする」といった具合だ。これは retry policy（再試行ポリシー）が扱う時点とは異なる。再試行ポリシーはタスクが既に開始され失敗した後どうするかを扱い、トリガー条件はタスクがそもそも開始すべきかどうかを扱う、より上流の判断だ。設計が不完全なトリガー条件は、データがまだ準備できていない状態でタスクを起動させてしまい、出てきた結果は表面上は成功しているように見えても、実際には不完全あるいは古くなったデータを処理しているにすぎない。

この問題が生じるのは、時刻そのものと「実行すべき条件が本当に成立しているか」がしばしば同一視されるからだ。毎朝9時に前日のシステム警告をまとめるよう設定したとすると、この時刻設定は「前日のデータが9時までに必ず整理完了している」という前提に基づいている。しかし前段階が時々遅延する場合（例えば上流システムのメンテナンスが長引き、データが10時になってようやく書き込み完了するなど）、9時にトリガーされたタスクはデータが揃っていない状態で実行され、一見正常だが実際には数件欠けたレポートを出してしまう。この種の誤りは特に発見しづらい。スケジュールは確かに実行され、確かに出力もあり、エラーメッセージも何も出ないからだ。データの件数を丁寧に照合して初めて何かが欠けていることに気づく。トリガー条件が存在する理由は、これまで同じことだと扱われがちだった「時刻になったこと」と「本当に始めてよいこと」という二つの判断を分けて扱うことにある。

実務では二層で設計する。第一層は基本的な時刻設定だ。タスクがどれくらいの頻度で、どの時刻に実行されるべきかを決める、最も設定しやすい部分である。第二層は追加の事前チェックだ。タスクを実際に実行する前に、処理すべきデータが本当に存在するか、形式が正しいか、件数が想定の範囲に収まっているかを確認する。チェックに通らなければ、タスクは正式な処理を進めず、待機するか人による確認へ直接通知し、不完全なデータに基づく結果を無理に出力することはしない。よくある事前チェックには、前段のスケジュールタスクが完了マークを付けているかの確認、処理対象のファイルが存在し空でないかの確認、データのタイムスタンプが想定範囲内に収まっているかの確認などがある。この層は単純に時刻を設定するより設計コストが高いが、まさにこの層が「タスクは実行されたがデータが間違っていた」という最も気づきにくい失敗パターンを防ぐ。

あなたにとって、トリガー条件の本当の価値は、「タスクが実行されたか」と「タスクが出した結果が正しいか」という、同じことだと扱われがちな二つの問いを分けて検証できる点にある。固定時刻だけを設定し事前チェックのないスケジュールタスクでは、確認できるのは「実行すべき時刻に実行されたか」だけであり、「実行された瞬間にデータが本当に準備できていたか」は確認できない。この二つは近く見えるが、実際にはまったく異なる階層の保証だ。注意すべきは、事前チェック自体も妥当な厳しさに調整する必要がある点だ。チェック条件を厳しくしすぎると（データ件数が特定の固定数と完全に一致することを要求するなど）、データ量が正常に変動しただけで「まだ準備できていない」と誤判定され、タスクが不必要に止まってしまう。緩すぎると本当に問題のあるデータを見逃してしまう。妥当なやり方は通常、絶対値ではなく範囲を設定し、不確実な場合は自分で実行すべきか推測するのではなく人による確認に通知することだ。