のシナリオが止まることに気づかないでいた期間が、たぶん2週間くらいある。
クライアント案件でデータ転送を自動化していたシナリオが、APIのレート制限でずっとエラーを吐いていた。通知設定を入れていなかったので、僕は何も知らなかった。気づいたのは「先週のデータが反映されていない」とクライアントから言われたときだ。
この記事でわかること：
- Makeのシナリオが止まる原因の整理（リトライできるものとできないもの）
- Resume機能・Break機能の実装手順と使い分けの判断基準
- Error Handlerでの通知設定
- 実際に運用してみた感想（良い点と悪い点）
Makeのシナリオが途中で止まる原因を先に整理する
自動復旧の話をする前に、エラーの種類を整理しておきたい。どんなエラーにも自動復旧が有効なわけじゃないので。
一時的なエラー（リトライで解決できるもの）
- APIの一時ダウン・タイムアウト
- レート制限（一定時間後に回復する）
- ネットワークの一時的な不安定
これらはしばらく待ってから再試行すると解決することが多い。ResumeはこのタイプのエラーPRIMARY対象だ。
根本的なエラー（リトライしても無駄なもの）
- データの形式が間違っている（null値が来た・必須フィールドがない）
- 認証エラー（トークンが切れている）
- 接続先のURL・APIエンドポイントが変わった
こういうエラーは何回リトライしても同じ結果になる。むしろ後続処理を続けさせると、不正なデータがシステムに入り込むリスクがある。BreakはこのタイプのエラーPRIMARY対象だ。
この区別を最初に理解しておくと、Resume/Breakの使い分けがずっとシンプルになる。
Resume機能で「一時的エラー」を自動復旧させた話
Resume機能の基本的な仕組み
Resumeは、エラーが発生したモジュールの処理を、指定した間隔・回数だけ自動で再試行する機能だ。
設定方法はシンプルで、エラーが出やすいモジュールを右クリックして「Add error handler」を選ぶ。そこでエラーハンドラーの種類として「Resume」を選べる。リトライ回数と間隔（秒数）を設定するだけで使える。
実際に設定した手順
- エラーが頻発するモジュール（APIリクエストが多いもの）を特定する
- 該当モジュールを右クリック →「Add error handler」→「Resume」を選択
- 「Number of attempts」：3（最大で一時的なエラーが3回続くことを想定）
- 「Interval between attempts」：60秒（APIの一時ダウンやレート制限からの回復を待つ）
この設定を入れてから、APIタイムアウト系のエラーは週3〜4件から週1件以下に減った。
ただし、Resumeに頼りすぎると問題が出る。リトライ間隔を60秒に設定すると、3回失敗した場合は「最初の失敗から3分後にシナリオ完了」になる。実行頻度が高いシナリオだと、複数のシナリオが重なって実行が詰まるケースが出た。リトライ間隔は短すぎても長すぎても問題になる。30〜60秒が僕の感覚だとちょうどいい。
Break機能で「処理継続しちゃいけないエラー」を止める
Breakは「エラーが起きたらシナリオ全体の実行を止める」機能だ。
最初はResumeとの違いがよくわからなかった。「リトライしても無駄なエラーにはBreakを使う」というのはドキュメントに書いてあったが、「どんなエラーがリトライしても無駄なのか」の判断が難しかった。
で、実際に試した結論としては、こう判断するようにした：
- APIの認証関連エラー（401/403系）→ Break。再試行しても認証は通らない
- データの必須フィールド欠損（404系・null関連）→ Break。データが直るまでどうにもならない
- タイムアウト・503系（一時ダウン）→ Resume
Breakを設定したモジュールにエラーが来ると、そのシナリオの実行は停止する。ただし、シナリオ内の他のバンドル（データのまとまり）に影響しないように設計できる。これがBreakの重要な挙動で、「1件のデータでエラーが出たからといって、残り全件の処理が止まる」ことを防げる。
Error Handlerルートで通知を飛ばすようにした
ResumeとBreakを設定しても、エラーが起きたことを知る手段がないと気づけない。そこでError Handlerルートに通知を追加した。Resume/Breakの基本的な仕組みはこまろぐの解説が詳しい。
設定の流れはこうだ。エラーハンドラーを追加したモジュールの後に、別のルートとして「エラー時に実行するルート」が追加できる。このルートにSlack通知モジュールを繋いで、以下の情報を送るようにした：
- エラーが発生したモジュール名
- エラーメッセージ
- 実行日時
これでSlackに「このモジュールでこのエラーが出た」という通知が飛ぶようになった。
Error Handlerルートの設定に1日以上かかったのは、「全モジュールに設定すべきか、重要なモジュールだけに絞るか」の判断が難しかったからだ。全モジュールに設定すると、通知が大量に来て逆にノイズになる。最終的に「外部APIを呼び出すモジュール」「データを書き込むモジュール」に絞って設定した。
実際に運用してみた正直な感想
自動復旧を組んで2ヶ月が経った。正直に言う。
「思ったより設定量が多い」が最初の感想だ。20〜30モジュールのシナリオに全部設定すると、それだけで数時間かかる。慣れれば短縮できるが、最初は設計と実装の両方を考えながらやるので時間がかかった。
効果は出ている。設定前は週3〜4件出ていたAPIエラーが、設定後は週0〜1件になった。通知も来るようになったので、エラーに気づくまでの時間が2週間から30分以内に縮まった。
ただ、完全にゼロにはなっていない。月に1〜2回はResumeで回復しきれないエラーが出て、手動で対処している。「自動復旧を入れたから放置してOK」ではなく、「頻度が減って、気づきやすくなった」という話だ。
あと、Resume/Breakを設定したシナリオは、設定していないシナリオと比べて若干重くなる（実行時間が増える）。軽微な差だが、頻繁に実行するシナリオでは気になることもある。
まとめ
Makeのエラー自動復旧は、組む価値はある。ただ「組めば完全に手放せる」というものでもない。
優先度としては、まずError Handlerの通知設定から入るのがいいと思う。Makeのエラー対処の全体像はNADJAの解説記事も参考になる。エラーに気づける状態を作るのが先で、ResumeとBreakの設定はその後でいい。
通知が来るようになれば、どのエラーが多いか・どのモジュールが頻繁に問題を起こすかがわかる。そのデータを見てから、Resume/Breakの設定優先度を判断するのが現実的なアプローチだった。
合わせて読みたい
– Make（旧Integromat）の使い方：日本語で解説する初回シナリオ作成ガイド
– Makeのシナリオが半年後に読めなくなった：保守できるシナリオ設計にやり直した話
コメント