Makeのシナリオでエラー処理を足す:止める・無視する・やり直すの選び方

まず押さえる:何もしないとどうなるか

エラーハンドラを付けていない場合の既定動作は、Rollback相当です。Makeのエラー処理の概要によると、シナリオの実行を止め、トランザクションに対応したモジュールの変更を元に戻します。

見落としやすいのが自動停止です。同じ概要ページによれば、「連続エラー回数」の既定値は3回で、エラーで終わる実行がその回数続くとシナリオが無効になります(Webhookなどの即時トリガーや、一部のエラーは即座に無効化されます)。

つまり、手を入れずに放置すると「たまたま1件エラー → 全体が止まる → 3回続くとスケジュールごと止まる」という流れになります。エラー処理を足す目的は、この止まり方を業務に合わせて選び直すことです。

4つのハンドラの動きを一言で

Makeのエラーハンドラ一覧では、次の役割が説明されています。

• Skip:エラーを無視して、後続のバンドルの処理を続ける
• Retry:未完了の実行として保存し、自動または手動で再試行できるようにする
• Resume:失敗したモジュールの代わりの値を設定して、処理を続ける
• Rollback(ほか、変更を確定して止めるCommit):実行を止める

それぞれ、公式の説明から実務で効いてくる点を補足します。

Skip:流すが、失敗は見えなくなる

Skipのヘルプでは、問題のあるバンドルを捨てて次へ進むと説明されています。実行は「成功」として記録され、エラーでシナリオが無効になることもありません。公式も、誤ったデータが業務に影響せず、まれな欠落が許容できる場面向けとしています。

裏を返すと、失敗しても履歴上は成功に見えます。後から「何件落ちたか」を数えたい業務には、Skipだけでは向きません。

Retry:保存して、やり直す

Retryのヘルプでは、失敗したバンドルをシナリオの流れから外し、エラーメッセージ・マッピング・残りの流れを未完了の実行として保存すると説明されています。ほかのバンドルは処理が続きます。

• 自動完了を「はい」にすると、設定した回数と間隔で再試行します(ヘルプの例は15分おきに3回)
• 「いいえ」にすると、人が解決するまで未完了の実行に残ります
• 使うには、シナリオ設定で未完了の実行の保存を有効にする必要があります
• 効果が見込めるのは一時的なエラーです。入力値の不備のように、待っても直らないエラーには向きません

保存できる量には上限があり、プランごとに異なります(概要ページ)。具体的な件数は今回確認していないので、運用前にご自身の契約で確かめてください。

また、接続エラーやレート制限は、Retryを付けなくても未完了の実行の保存を有効にすれば自動で再試行されます(Retryのヘルプ)。

Resume:代わりの値で進める

失敗したモジュールの出力を、あらかじめ決めた値で置き換えて続けます。たとえば任意項目の取得に失敗したとき「未取得」という文字を入れて進める使い方です。代わりの値で進めても下流が壊れないことが前提になります。

Rollback:元に戻して止める

Rollbackのヘルプによると、元に戻せるのは「ACID」ラベルの付いたトランザクション対応モジュールだけです。GmailやDropboxのように対応していないモジュールの操作は、取り消されません。失敗したバンドルは先へ進まず、残りのバンドルも処理されません。

自動コミットの設定にも左右されます。有効なら、元に戻るのはエラーになったモジュールの変更だけです。無効なら、対応モジュール全体の変更を戻せます。

もう一点、同ページによると、スケジュール実行のシナリオではRollbackは連続エラー回数に数えられず、カウンターもリセットされます。そのため、Rollbackで止まり続けても自動では無効にならない可能性があります。エラー通知を別途用意しておくと安心です。

業務の種類別:エラー時の動作の判断表

以下は編集上の提案で、業務は説明用の例です。実際の判断は、失った場合の影響と、やり直しで二重処理が起きるかで決めてください。

• 注文データを会計・在庫に反映、エラーの典型：相手先の一時障害、推奨：Retry(自動)+通知、理由：欠落が許されず、待てば直る
• 同じ業務で、金額や必須項目の不備、エラーの典型：入力エラー、推奨：Retry(手動)または止める、理由：待っても直らない。人が直して再開
• 顧客へのメール送信、エラーの典型：送信APIの失敗、推奨：Retry(手動)、理由：自動だと重複送信の恐れ。送信済みか人が確認
• フォーム登録をCRMへ追加、エラーの典型：重複登録による拒否、推奨：Skip(その種類のエラーだけ)、理由：重複は落としてよい
• Slackへの社内通知、エラーの典型：通知先の一時不調、推奨：Skip、理由：本業務に影響しない。ログは別に残す
• 任意項目の補完(例:会社名の取得)、エラーの典型：取得失敗、推奨：Resume、理由：「未取得」で進めても害がない
• 複数テーブルを順に更新(ACID対応モジュール)、エラーの典型：途中で失敗、推奨：Rollback、理由：中途半端な更新を避ける
• 一括処理(100件のうち数件が異常)、エラーの典型：一部データの不備、推奨：Retry(手動)、理由：他の件は進み、異常分だけ残る

要点は次の3つです。

1. 金額・顧客・在庫に関わる処理はSkipにしない。 失敗が成功として記録されるためです。
2. 外部への送信系は自動リトライを慎重に。 失敗の時点で相手側が受理済みかもしれず、やり直すと二重になる恐れがあります。受理の確認方法はサービスごとに異なります。
3. 「待てば直る」エラーと「直らない」エラーを分ける。 前者は自動リトライ、後者は手動で人に渡します。

設定前の確認メモ

ハンドラを付ける前に、シナリオごとに次を埋めておくと迷いません。

1. 失敗したバンドルを後で再処理する必要があるか。 ある → Retry。ない → Skipを検討。
2. 再処理で二重処理が起きないか。 起きうる → 自動リトライを避ける、または送信前に重複確認を入れる。
3. 代わりの値で下流が壊れないか。 壊れない → Resume。分からない → 使わない。
4. ロールバックしたいモジュールはACID対応か。 非対応なら、Rollbackを付けても取り消せません。
5. 失敗に誰がどう気づくか。 Skipは成功扱いになり、Rollbackは自動停止に数えられないことがあります。通知先を決めてから付けます。
6. 未完了の実行の保存は有効か。 Retryの前提です。保存の上限もご自身のプランで確認します。
7. エラーの種類ごとに分ける必要があるか。 「重複だけSkip、それ以外はRetry」のように、エラーの種類で分岐させたいかを先に決めます。

運用で最初に見るところ

付けた後は、次の順で確認します。

• 実行履歴で、エラー、警告、成功のどれで記録されているかを確認する
• 未完了の実行に、想定外の件数が溜まっていないかを確認する
• 再試行が尽きた分は、人が手動で処理する担当と頻度を決める

テスト用データで、わざと失敗させてから本番に出すと、記録のされ方を実際に確かめられます。たとえば必須項目を空にして流し、期待したハンドラが動くかを見ます。

エラー処理は多く付けるほど良いわけではありません。最初は「止めてよい処理」と「流してよい処理」を二分し、その後で再試行や代替値を足すと、設定が複雑になりにくくなります。