Makeが途中で止まったら：未完了実行の復旧とRun Replayの使い分け

まず「成功した前段」と「失敗した箇所」を分ける

履歴にWarningやErrorが出ても、すべての処理がなかったことになったとは限りません。対象の実行を開き、成功したモジュール、失敗したモジュール、まだ通っていないモジュールを控えます。受付番号や注文番号で保存先も開き、追加済みの行・記録を確かめましょう。受信段階で止まっている場合は、Webhookの設定記事から確認できます。

編集部は2026年10月19日、MakeのFreeで「Basic trigger → Data store追加（before）→ Parse JSON → Data store追加（after）」の4モジュールを作りました。受付番号は架空のO16-TEST-001で、メール・Slack・実際の顧客情報は使っていません。専用ストアはキーを自動生成し、実行ごとに別記録を追加する条件です。

JSON stringを「{invalid-json」にして実行すると、DataError「Source is not valid JSON」でWarningになり、未完了実行が1件保存されました。ストアにはbeforeが1件、afterは0件。前段の追加は残っていました。今回の「Commit after each module」はYesです。トランザクションの確定条件や連携先によって結果は変わるため、この件数をすべてのシナリオへ当てはめないでください。

図で理解する成功した処理を先に控える

関連ガイド：MakeのWebhookの使い方：設定・JSONの受信と動かないときの確認手順

参考：Make：Incomplete executionsMake：Scenario settings

Store incomplete executionsを確認し、復旧方法を選ぶ

公式資料では未完了実行の保存は既定で無効です。Scenario settingsでStore incomplete executionsを有効にします。今回の編集画面では下部のMore → Scenario settingsにありました。設定場所は更新されることがあるため、機能名を目印にしてください。保存設定は、過去の失敗を後から保存し直す操作ではありません。

保存先の容量も確認します。Keep data confidential、保存容量が満杯のときの破棄、処理順、各モジュール後の確定なども挙動に関わります。検証では架空データの保存を有効にし、容量満杯時の破棄はNo、スケジュールはInactiveのまま手動実行しました。実際の個人情報を扱うシナリオでは、保持するログの範囲も運用条件に合わせます。

今回試したのは、設定ミスを直して進める手動Resolveです。一時的な接続エラー等のRetry selectedや、自動Retryの待機動作は試していません。未完了一覧ではInactiveにより自動再試行できない案内がありました。再試行のために有効化すると通常のスケジュールも動き得るので、起動条件を確認してから操作します。

参考：Make：Incomplete executionsMake：Manage incomplete executionsMake：Automatic retry of incomplete executionsMake：Scenario settings

手動復旧：未完了実行内で直し、失敗箇所から進める

シナリオのIncomplete executionsから対象の作成日時を開き、失敗したモジュールを確認します。今回の画面では一覧の日時から詳細へ進み、左のシナリオ図をクリックすると未完了実行の編集画面になりました。通常シナリオの編集と、未完了実行の編集を取り違えないことが大切です。

Parse JSONのJSON stringだけを「{"ok":true}」へ変更し、モジュールのSave、未完了実行のSaveを押してからRun onceを実行しました。復旧試行の履歴ではParse JSONと後段のData storeだけが成功し、2 operations・2 creditsでした。ストアはbefore 1件・after 1件となり、前段の再追加はありませんでした。

未完了実行はResolvedになりました。ただし、後で通常シナリオを開くとJSON stringは不正な値のままでした。今回、未完了実行内の修正は通常構成へ反映されていません。次の新規受付で同じ失敗を繰り返さないよう、通常側にも必要な修正を保存し、別に動作を確認します。

図で理解するどこから通るかを選ぶ

編集部の検証画面復旧試行はJSONと後段追加だけ成功

編集部の検証画面手動復旧後：前段1件・後段1件

参考：Make：Manage incomplete executions

Replay：同じ受付番号が前段・後段とも2件になった

通常シナリオ側も正しいJSONに直して保存し、Historyで元のWarning実行を開きました。Replay run → 確認ダイアログのReplayを1回押します。ダイアログには、最新の構成で新しい実行を作ること、creditsの消費、接続先の重複記録の可能性が表示されました。

ReplayはSuccessとなり、履歴のTriggerはReplay、Source runは元のWarning実行を指していました。4モジュールが成功し、4 operations・4 creditsです。ストアでは同じO16-TEST-001のbeforeが2件、afterも2件。すでに復旧した1件に対し、前段と後段がそれぞれもう1件追加されました。これは自動キーで毎回追記する今回の条件での実測です。

Run with existing dataも過去のデータで現在の構成を試す機能です。テストという名前でも、通過する保存・通知モジュールは実際に動く前提で扱います。公式資料ではReplayは全プラン対応ですが、対象にできる期間は履歴の保存範囲に依存し、一括Replayはできません。今回の実操作はFreeのHistoryにあるReplay runを1回使ったものです。

編集部の検証画面Replay後：前段2件・後段2件

参考：Make：Scenario run replay

再実行前に「追加」と「更新」、通知の扱いを決める

今回の重複は、Data storeのKeyを空欄にして毎回新しいキーを発行したため確認できました。受付番号をレコード内に保存するだけでは、同じ受付の再追加を防げません。実運用では、どの項目を照合キーとするか、既存レコードを更新するか、処理済みなら追加を止めるかを決めます。以下は編集部の設計案で、今回の重複防止実装の実測ではありません。

Data storeで固定キーを使う場合も、Overwriteの設定で更新になるかエラーになるかが変わります。連携先が別なら、そのサービスの追加・更新・一意性の仕様を確認します。「存在確認→追加」の間に別実行が入る場合もあるので、確認モジュールを置くだけで同時実行の重複がなくなるとは断定できません。

台帳の重複を防げても、メールやSlackへの通知はもう一度送られるかもしれません。補完したい処理と、済んでいる処理を分け、検証用の保存先・宛先で1件から確認します。今回、通知モジュールは接続していないため送信数は0で、再送や未着の動作は未検証です。

図で理解する同じ受付番号で追加先を照合

関連ガイド：Googleフォームの回答をNotionへ送る：Make・アドオン・標準フォームの選び方

参考：Make：Scenario run replayMake：Data stores

完了表示の後も、件数・元実行・creditsを照合する

下表の件数は各段階のストア内の累計、creditsはその実行・復旧試行だけの消費です。復旧とReplayは代替方法として比較するため、今回は同じ受付を意図的に両方で処理しました。本番で「復旧したから、さらにReplayする」という順序を勧めるものではありません。

先に受付番号と元実行を控え、少数で復旧してから保存先を開きます。履歴が成功でも、期待した値・保存件数・実際の通知まで照合して完了とします。余分なレコードがあった場合は、関連する記録との対応を確認してから修正方針を決め、成功表示だけを理由にまとめて削除しません。

自動Retryはすべてのエラーに同じように働くわけではありません。公式はRateLimitError・ConnectionError・ModuleTimeoutError等の条件を案内しています。今回のDataErrorでは手動で設定を修正しました。未完了実行がない場合や、保存履歴がない場合は、この手順で同じデータを復元できるとは限りません。

検証は架空の受付1件、組み込みモジュール4個、自動キーの専用Data storeに限定しています。外部通知、複数バンドル、並列処理、障害待ちの自動Retry、容量超過、実際の請求額は未検証です。テストシナリオはInactiveで残しています。復旧機能のためだけに有料化せず、利用中の履歴・保存容量と必要な運用条件を先に確認しましょう。

図で理解する完了表示と保存先を照合する

関連ガイド：Make入門：日本語データを一つの通知につなぐMakeとZapierの料金を比較：無料枠・課金単位と月100件の自動化で選ぶ

参考：Make：Manage incomplete executionsMake：Scenario run replayMake：Automatic retry of incomplete executions