「Makeで作ったシナリオが夜中にエラーで止まってしまい、朝になって大量の処理が溜まっていた…」
こんな経験はありませんか?
私も以前、ECサイトの在庫管理シナリオがAPIのタイムアウトで停止し、200件以上の注文処理が滞ってしまったことがあります。
しかし、MakeのResume機能とBreak機能を使いこなすことで、今では99.9%の稼働率を実現しています。
この記事では、私が実際に運用している15個以上のシナリオで培った、エラーハンドリングの実践的なノウハウをすべて公開します。
読み終える頃には、あなたも「エラーが怖くない」堅牢なシナリオを構築できるようになるでしょう。
なぜMakeのエラーハンドリングが重要なのか?
Makeで自動化を進めていくと、必ず直面するのがエラー処理の問題です。APIの一時的な不具合、ネットワークの不安定さ、外部サービスのメンテナンスなど、エラーの原因は多岐にわたります。
私が管理している顧客のシナリオでは、1ヶ月あたり平均して以下のようなエラーが発生しています:
- APIタイムアウト:月15〜20回
- レート制限エラー:月5〜10回
- 認証エラー:月2〜3回
- データ形式エラー:月10〜15回
これらのエラーを適切に処理しないと、ビジネスに深刻な影響を与えることがあります。例えば、ECサイトの注文処理が止まれば顧客からのクレームにつながりますし、請求書の自動送信が失敗すれば入金遅延の原因になります。
特に夜間や週末など、人が対応できない時間帯にエラーが発生すると、復旧までに長時間かかることもあります。私のクライアントの一社では、金曜夜のエラーに月曜朝まで気づかず、3日分のデータ処理が滞ったケースもありました。
しかし、MakeのResume機能とBreak機能を適切に使えば、これらの問題の大部分は自動的に解決できます。実際、私が構築したシナリオでは、エラーの95%以上が自動復旧し、人の介入が必要なケースは月1〜2件程度まで減少しました。
Resume機能とBreak機能の基本理解
Makeのエラーハンドリングには、主に2つの強力な機能があります。それがResume機能とBreak機能です。まずはそれぞれの基本的な動作を理解しましょう。
Resume機能とは
Resume機能は、エラーが発生したモジュールから処理を再開する機能です。一時的なエラーの場合、時間を置いて再実行することで正常に処理できることが多いため、この機能は非常に有効です。
Resume機能の特徴:
- エラーが発生した特定のモジュールから処理を再開
- 前のモジュールまでの処理結果は保持される
- 手動または自動で再実行が可能
- 再試行回数や間隔を設定できる
Break機能とは
Break機能は、エラーが発生した時点でシナリオの実行を意図的に中断する機能です。重要な処理でエラーが発生した場合に、後続の処理を実行させないために使用します。
Break機能の特徴:
- エラー発生時に即座にシナリオを停止
- エラー内容を保存して後で確認可能
- 特定の条件でのみBreakを発動させることも可能
- 手動でのResume実行に備えた状態を保持
実践的なエラーハンドリング戦略
ここからは、私が実際に使用している具体的なエラーハンドリング戦略を紹介します。これらは、様々なシナリオで検証済みの手法です。
1. APIタイムアウト対策のResume設定
外部APIを使用する際、最も頻繁に発生するのがタイムアウトエラーです。私は以下のような設定を標準としています:
推奨設定:
- 初回タイムアウト:30秒
- 再試行回数:3回
- 再試行間隔:1回目5分、2回目10分、3回目30分
この設定により、一時的なサーバー負荷やネットワーク障害の多くが自動的に解決されます。実際のシナリオでは、HTTPモジュールの詳細設定で以下のように設定します:
1. モジュールの「詳細設定」を開く
2. 「エラーハンドリング」セクションで「Resume」を選択
3. 「再試行回数」を3に設定
4. 「再試行間隔」で段階的な待機時間を設定
2. データ検証エラーのBreak戦略
データの整合性が重要な処理では、不正なデータで後続処理を実行させないことが重要です。例えば、請求書作成シナリオでは以下のようなBreak設定を行います:
- 必須項目(顧客名、金額、日付)が欠けている場合は即Break
- 金額が0円またはマイナスの場合は即Break
- 日付フォーマットが不正な場合は即Break
これらの条件は、RouterモジュールとBreakモジュールを組み合わせて実装します。条件に合致した場合のみBreakルートに流すことで、データの整合性を保ちます。
3. レート制限エラーの賢い回避方法
多くのAPIには利用制限があり、制限を超えるとエラーが発生します。私が使用している対策は以下の通りです:
予防的アプローチ:
- Sleepモジュールで意図的に処理を遅延(1リクエストあたり2秒など)
- バッチ処理の場合は、100件ごとに5分の休憩を挟む
- APIの利用状況をDatastoreで記録し、制限に近づいたら自動的に速度を落とす
エラー発生時の対応:
- 429エラー(Too Many Requests)専用のResumeルートを作成
- レスポンスヘッダーの「Retry-After」を読み取り、指定時間後に再実行
- Retry-Afterがない場合は、段階的に待機時間を延長(5分→15分→60分)
4. 複雑なシナリオでの階層的エラーハンドリング
大規模なシナリオでは、エラーハンドリングも階層的に設計する必要があります。私が採用している3層構造を紹介します:
第1層:個別モジュールレベル
各モジュールで軽微なエラーを処理。タイムアウトや一時的な接続エラーはここで対応。
第2層:機能ブロックレベル
関連する複数のモジュールをグループ化し、ブロック単位でエラー処理。例えば「顧客データ取得」ブロック全体でエラーが発生した場合の代替処理を定義。
第3層:シナリオ全体レベル
致命的なエラーや想定外のエラーをキャッチ。管理者への通知やログ記録を行う。
実装例:ECサイト在庫同期シナリオ
実際に私が構築した、ECサイトの在庫同期シナリオを例に、具体的な実装方法を解説します。このシナリオは、複数の倉庫システムとECサイトの在庫を15分ごとに同期するものです。
シナリオの構成
1. Webhookトリガー:15分ごとに起動
2. 倉庫API呼び出し:3つの倉庫システムから在庫データ取得
3. データ統合処理:重複チェックと在庫数の集計
4. ECサイトAPI更新:在庫数を更新
5. ログ記録:処理結果をGoogleスプレッドシートに記録
エラーハンドリングの実装詳細
倉庫API呼び出し部分:
- 各倉庫APIにResume設定(再試行3回、間隔5/10/30分)
- 1つの倉庫でエラーが続く場合は、その倉庫をスキップして他の倉庫のデータで処理継続
- すべての倉庫でエラーの場合のみBreak発動
データ統合処理部分:
- データ形式エラーはBreakで即停止
- 在庫数がマイナスや異常に大きい値(10万個以上)の場合は警告メール送信後、その商品のみスキップ
ECサイトAPI更新部分:
- レート制限対策として、100商品ごとに30秒のSleep
- 更新失敗した商品はArrayに格納し、処理完了後に再試行
- 3回失敗した商品のみ手動対応リストに追加
この設計により、月間約45,000件の在庫更新を99.8%の成功率で処理しています。
Makeの高度な機能を活用したエラー管理
Makeには、エラーハンドリングをさらに強化する高度な機能があります。これらを組み合わせることで、より堅牢なシナリオを構築できます。
Error Handlerの活用
Error Handlerは、特定のモジュールで発生したエラーを捕捉し、カスタム処理を実行できる機能です。私がよく使用するパターンは:
- エラー内容をSlackに通知
- エラーログをデータベースに保存
- エラーの種類によって異なる対応を自動実行
Commit/Rollback機能との組み合わせ
トランザクション処理が必要な場合、Commit/Rollback機能とエラーハンドリングを組み合わせます。例えば、在庫移動と売上計上を同時に行う場合:
1. トランザクション開始
2. 在庫移動処理(エラー時はRollback)
3. 売上計上処理(エラー時はRollback)
4. 両方成功したらCommit
この方法により、データの整合性を保ちながらエラー処理を行えます。
他のツールとの比較
Makeのエラーハンドリング機能を、他の自動化ツールと比較してみましょう。
Zapierとの比較
Zapierの利点:
- シンプルなUIでエラー処理設定が直感的
- 自動リトライがデフォルトで有効
Makeの利点:
- Resume/Breakによる細かな制御が可能
- Error Handlerで複雑な条件分岐が可能
- エラー時の処理フローを視覚的に設計できる
n8nとの比較
n8nの利点:
- エラー処理用の専用ノードが豊富
- カスタムエラーハンドリングの自由度が高い
Makeの利点:
- GUIでの設定が簡単で学習コストが低い
- エラー履歴の管理機能が充実
- Resume機能の使いやすさ
総合的に見ると、Makeは「使いやすさ」と「機能の充実度」のバランスが優れており、特にビジネスユーザーにとって最適な選択肢といえます。
まとめ:安定稼働への第一歩
この記事では、MakeのResume機能とBreak機能を使った実践的なエラーハンドリング方法を解説しました。重要なポイントをまとめると:
- Resume機能で一時的なエラーは自動復旧
- Break機能でデータの整合性を保護
- エラーの種類に応じた適切な戦略の選択
- 階層的なエラーハンドリング設計の重要性
これらの技術を習得することで、あなたのMakeシナリオは格段に安定性が向上するはずです。まずは、既存のシナリオ1つにResume設定を追加することから始めてみてください。
さらに詳しいMakeの機能や基本的な使い方については、Make完全ガイド記事で解説していますので、ぜひ参考にしてください。
エラーハンドリングをマスターすれば、真の意味での「自動化」が実現します。ぜひMakeの無料アカウントで、今すぐ実践してみてください。きっと、あなたのワークフローが劇的に改善されるはずです。