エラー処理とエッジケース

🔄 前のレッスンでデータ処理とマルチステップワークフローを学んだ。今回は自動化の避けられない現実——エラー——に対処する方法を学ぶ。

完璧だった自動化が壊れた日

ある企業が完璧な請求書自動化を構築した。3ヶ月間問題なく動いた。ある日、顧客データベースのフィールド名がAPI更新で変更された。自動化は黙って壊れ、2週間分の請求書が未送信のまま溜まった。誰も気づかなかった——顧客からの問い合わせまで。

エラー処理の3つの原則

原則1：失敗は「いつ起きるか」であり「起きるか」ではない

すべての自動化はいつか壊れる。エラー処理は「もし壊れたら」ではなく「壊れた時にどう対応するか」を設計すること。

原則2：大声で失敗する

原則3：回復可能なら自動回復、不可能なら人間に渡す

エラー処理パターン

リトライ（再試行）

一時的な障害（ネットワーク、API制限）に対応：

ステップ失敗
  → 1分待って再試行
  → 失敗 → 5分待って再試行
  → 失敗 → 15分待って再試行
  → 失敗 → 担当者にSlack通知（詳細付き）

フォールバック（代替手段）

主要な方法が失敗した場合の代替：

サーキットブレーカー

連続失敗が閾値を超えたら、自動化を一時停止：

5回連続失敗 → 自動化を一時停止
  → 管理者に通知：「原因調査が必要」
  → 手動で再開するまで待機

エッジケースのチェックリスト

この自動化のエッジケースを洗い出してください：
[自動化の説明]

以下を確認：
1. 空欄・null値：必須フィールドが空の場合
2. 形式不一致：日付、通貨、名前の異常形式
3. 境界値：0、負数、最大値
4. 重複実行：トリガーが2回連続で発火した場合
5. タイミング：深夜、年末年始、月末
6. 権限：APIキー期限切れ、認証失敗
7. データ量：通常の10倍のデータが来た場合

エラー通知の設計

良いエラー通知に含めるべき情報：

実践演習

1. レッスン3〜5で設計した自動化を振り返り、5つ以上のエッジケースを洗い出す
2. 各エッジケースに対するエラー処理を設計する
3. エラー通知のテンプレートを作成する

💡 ポイント： エラー処理は「保険」と同じ。面倒でつまらない作業だが、1回の大事故を防ぐだけで、投資した時間の何十倍も回収できる。自動化の信頼性は、ハッピーパスではなくエラー処理の質で決まる。