仕事の自動化
Makeの通知が途中で止まったら?失敗した処理を保存して再開する方法
この記事の目次
Makeで受付データを読み取れたのに、Slackへの通知だけが失敗した。そんなとき、元データをもう一度入れ直す前に、失敗した処理が保存されていないかを確認します。Makeの「Incomplete executions」は、途中で完了できなかった処理を残し、原因に合わせて再開するための機能です。
Makeは、アプリの処理を画面上につないで自動化するツールです。通知を作るだけでなく、失敗した位置や渡したデータを確認できる点も、続けて使う際の判断材料になります。この記事は公式資料に基づく設定ガイドです。当サイトで外部サービスの障害を起こして検証したレビューではありません。
まず、通知先とMakeの履歴を見比べる
Slackに届いていないように見えても、送信先のチャンネルが違う場合や、送信後の処理で失敗している場合があります。該当する受付番号・時刻を手がかりに、Slack側の投稿とMakeのHistoryを照合します。自動再試行の予定が入っている場合もあるため、手動で同じ通知を送る前に確認します。
例:受付番号 TEST-19 の連絡を探す
① どの日時の実行か
② 赤い警告が付いている部品は何か
③ Slackには TEST-19 の通知がすでにあるか
④ Incomplete executionsに同じ対象が残っているか
受付番号は当サイトの説明用です。実際には自分のデータを識別できる値で照合してください。
失敗した位置から続けるための保存
- 受付データ読み取りは完了
- Slackへの送信エラーが発生
- 未完了の処理原因と入力を確認
再試行または修正
未完了の処理を保存する設定を有効にする
シナリオの設定でStore incomplete executionsをYesにして保存します。初期状態では無効です。有効化後に残された未完了処理は、対象シナリオのIncomplete executionsタブから確認できます。保存できる量には契約の利用枠に応じた上限があります。Make公式:Incomplete executions
この設定を今から有効にしても、過去に保存されなかった失敗データが復元されるわけではありません。すでに失敗した実行の復旧では、まず保存の有無を確認します。本番シナリオを修正する前に、テスト用の宛先と架空データで動きを確かめてください。
Retryを追加すると、失敗時の扱いを画面で決められる
特定の部品で失敗したデータを残したい場合は、その部品を右クリックし、Add error handler → Retryを選びます。たとえばSlackの送信部品へ追加する、という使い方です。Retryには、自動で再試行するかを決めるAutomatically complete executionがあります。
| 設定 | 使いどころ |
|---|---|
| Automatically complete execution:No | 未完了処理を残し、人が内容を確認してから復旧する |
| Yes/Number of attempts:3/Interval:15分 | 一時的な失敗を時間を置いて再試行する設定例。原因と接続先の制限に合わせて調整する |
上の回数・間隔は全処理に推奨する値ではありません。入力ミスを何度繰り返しても直らないため、原因が分からない段階で自動再試行を増やさないでください。Retryを使う場合も、未完了処理の保存設定が必要です。Make公式:Retry error handler
一方、ConnectionError・RateLimitError・ModuleTimeoutErrorには、未完了処理の保存を有効にすることで働く自動再試行があります。毎回Retry部品を追加しなければ再試行できないわけではありません。自動再試行の対象と予定は公式の自動再試行ガイドで確認できます。
一時的な失敗と、設定を直す必要がある失敗を分ける
対象シナリオのIncomplete executionsを開き、該当行のDetailsから警告が付いた部品を確認します。ここでエラーの内容と保存された入力を見ます。
一時的な接続不良が解消した場合は、対象を選んでRetry selectedから再試行できます。この操作にはシナリオが有効であることが必要です。再試行は、失敗時と同じ設定を使って失敗した部品から始まります。定期実行も動く状態になるため、予定外の対象がないか先に確認します。
宛先の指定や必須項目など、設定自体に問題がある場合は、未完了処理のDetailsで該当部品を修正し、Save → Run onceで再開します。これは通常のシナリオ画面から全体をやり直す操作と区別してください。完了後はResolvedになったかを確認し、Slack側でも対象の通知が届いたかを見ます。Make公式:未完了処理の管理と手動解決
Replayは、成功した部品も通る
HistoryなどにあるRun Replayは、過去の起点データを現在のシナリオへ入れ直す機能です。未完了処理の再開とは違い、以前に成功した部品にもデータが流れます。途中にメール送信や行の追加がある場合は、同じ相手への再送や二重登録が起き得ます。
たとえば「受付メール送信 → Slack通知」で後半だけが失敗したなら、全体をReplayすると受付メールも再び送信される可能性があります。どこから再開したいか、すでに何が完了しているかを確かめてから選びます。Replayもクレジットを消費します。Make公式:Scenario run replay
テストで確かめるのは、成功表示だけではない
まずテスト用シナリオ・通知先で正常な1件を実行し、受付番号などの識別値が通知に含まれるか確認します。失敗時の練習も本番の接続を壊して行うのではなく、隔離したテスト環境で行ってください。
- 保存された未完了処理の入力が、対象のテストデータと一致する。
- 手動確認用にした処理に、意図しない自動再試行が設定されていない。
- 修正して再開した後、Resolvedと通知先の実結果が一致する。
- 同じ対象への通知が重複していない。別の部品で新たな失敗が起きていない。
Make側で送信が失敗と記録されても、相手側では処理されているケースまで、再開機能だけで完全に防げるとは限りません。重要な連絡では識別番号を本文に入れ、送信先の記録と照合できる形にしておくと判断しやすくなります。
通知を作るところから試すなら
MakeのFreeプランは月1,000クレジットです(2026年9月19日確認)。練習や再実行分も利用量に含め、最新の料金・利用枠を確認してください。初めてなら、まず受付行を読み取る設定から始め、必要な受付だけSlackへ通知する例へ進めます。
Makeを試すときは「通知が届く」だけでなく、「届かなかった対象を画面で見つけられる」ところまで確認すると、自分で管理できそうか判断できます。
登録後は練習用シナリオを作り、正常な1件を確認してから、未完了処理の保存設定へ進んでください。