Makeのエラー再実行で二重登録を防ぐ｜Incomplete Executionsの確認手順

Makeのエラーを再実行する前に、「前段の書き込みが成功していないか」を調べてください。フォーム回答は受信できたのにWordPress投稿だけ失敗した場合と、投稿作成後に通知だけ失敗した場合では、再開位置が違います。注文・予約・顧客の登録を最初からやり直すと二重作成の原因になります。小規模なブログや個人事業でMakeを使い始めた人向けに、失敗の調べ方、重複を防ぐ設計、再開後の確認を説明します。手順は設計例であり、筆者がすべての接続先で再現検証した体験ではありません。

Incomplete Executionsでできること

Makeの公式ヘルプによると、シナリオ設定で「Store incomplete executions」を有効にすると、失敗した実行を後で確認・再試行できます。この保存機能は初期状態で無効です。対応可能なエラーには自動再試行やRetryエラーハンドラーもありますが、全てのエラーや全ての接続先に同じ処理が使えるわけではありません。保存上限に達した場合の挙動、データ損失設定、シナリオの再実行順序も運用前に確認してください。Make公式のIncomplete executionsを2026年9月26日に確認しました。

再実行前の調査は7段階

1. 新規入力と再試行の状態を確認。調査中に同じ入力が重ならないよう、必要ならスケジュールを止める。Pendingの自動再試行予定と、停止中の入力の扱いも確認する。Retry selectedにはシナリオがactiveである必要があるため、停止したまま実行できるとは考えない。
2. 履歴から対象実行を特定。実行日時、失敗したモジュール、エラー文、入力と出力を記録する。機密情報を共有するときはマスクする。
3. 入力の一意IDを決める。フォーム回答ID、注文ID、動画IDなど、同じ事象に対して変わらない値を使う。メールアドレスだけでは複数注文を区別できない。
4. 保存先を直接見る。投稿一覧やスプレッドシート、CRMで同じIDを検索し、すでにレコードがあるか確認する。Makeの緑色の実行結果だけで確定しない。
5. 失敗原因を修正。認証期限、権限、項目名変更、APIの一時制限、入力の欠損を区別。エラー内容が不明なまま何度もRetryしない。
6. テストを1件だけ実行。テスト用IDを使い、作成件数、更新内容、通知先、消費クレジットを照合する。
7. 本番データを慎重に再開。処理前後のレコード数を比較し、二重登録や抜けを確認してから定期実行を戻す。

WordPressへ下書きを作るシナリオなら、入力元の記事IDをWordPressのカスタムフィールド等で一意に保持し、作成前に検索できる設計を検討します。ただしWordPressの標準検索がカスタムフィールドに対応するとは限らず、検索と作成の間に別の実行が割り込む可能性もあります。競合する同時実行がある場合、予約枠やユニークキーを含めて慎重に設計してください。

二重作成を防ぐ設計

最も単純な対策は「同じ入力IDなら新規作成を繰り返さない」ことです。受信時にIDを確認し、保存先にあれば更新かスキップ、なければ新規作成する分岐を用意します。しかし、検索で見つからなかった直後に別の並列実行が同じIDを作る場合は、検索だけでは不十分です。接続先に一意制約や重複禁止機能があれば併用し、処理を順番にする設定も検討します。決済やメール送信など取り消しにくい処理は、接続先の冪等キーや重複防止仕様を優先して確認します。

たとえば「フォーム回答#A123 → データベース登録 → WordPress下書き → 担当者にメール」という例で、下書きまでは成功しメールだけが失敗したとします。全体を手動で最初から走らせると#A123の登録と下書きが2件になる恐れがあります。実行履歴とWordPressの投稿IDを照合し、未実行の通知だけを実施する、または同じIDを見つけたら新規作成しない設計へ修正します。実際の再開地点はエラーハンドラーと各モジュールの仕様で変わるので、成功済み部分を必ず確認してください。

「投稿済み・通知未確認」を分けて記録する

次は架空の回答ID「A123」を使った確認例です。Makeの表示だけでなく、保存先で確認できた事実を記録します。

タイムアウトは「相手に届いていない」と同じではありません。通知や書き込みの結果を確認できない場合は、成功とも失敗とも決めつけず保留します。この記録なら、担当者が交代しても同じ投稿を増やさずに調査を続けられます。

Retry・手動解決・Replayを使い分ける

通常のシナリオだけを直してRetryを押しても、保存された失敗実行へその修正が反映されるとは限りません。設定ミスを直すときは、公式の手動解決手順に沿って対象の失敗実行を開きます。

入力値を直して1件だけ再開する手順

1. 対象シナリオのIncomplete executionsタブで、日時とIDを照合して対象のDetailsを開く。
2. 失敗したモジュールの入力と設定を確認し、必要な値やマッピングを修正する。
3. モジュールのSaveで修正を保存し、その失敗実行の画面でRun onceを実行する。
4. Resolvedになったか確認し、保存先でも対象IDの件数と内容を照合する。別のモジュールで止まった場合は新たなIncomplete executionも調べる。

一時的なエラーを同じ設定で試し直す場合は、シナリオがactiveであることを確認して、一覧で対象1件だけを選びRetry selectedを使います。表の先頭のチェックボックスは全件選択なので、最初からまとめて実行しないでください。Pendingは成功ではなく再試行待ちです。

Run Replayの公式説明では、成功済みのモジュールも実行対象になります。投稿作成やメール送信があるなら、既存IDとの照合と重複防止を確認してから選びます。失敗地点から続ける操作と混同しないでください。

失敗する典型例と対処

• 401/403の認証・権限エラー：接続を再認証し、対象アカウントに必要な権限があるか調べる。入力を繰り返しても改善しない。
• 429など制限：APIのレート制限と再試行間隔を確認。急いで連続実行しない。
• 必須データ欠損：フィールド名変更や空欄に対応し、欠損時は保留にする。
• 下流だけ失敗：上流の登録が済んだか実際の保存先で調査。
• 複数実行が同時進行：同一IDへの書き込みを競合させず、接続先の制約も使う。

作業時間と費用の見積り

調査時間は、保存先の確認や認証・API仕様の調査が必要かで変わります。復旧用に「入力ID、失敗位置、修正内容、再実行回数、消費クレジット」を残し、次の障害でも使える記録にします。Makeはクレジットを実行で消費するため、同じ失敗を繰り返すと利用量が増える可能性があります。料金と残りクレジットは公式料金ページと自分の管理画面で確認してください。設計を試すときは本番と分けたシナリオと少数のテストデータを使い、通知先もテスト用にします。保存済みの失敗実行をRetryする場合は、上記のactive条件を確認してください。

再試行を含む消費量が分かったら、MakeとZapierの料金・無料枠の比較で、同じ処理を月に何件動かせるかを見積もれます。乗り換えても二重登録の対策は必要です。まず現在のシナリオを直し、運用費用が負担になる場合に比較してください。

FAQ

Retryを設定すれば必ず二重登録を防げますか？

いいえ。再試行機能と保存先の一意性は別です。注文番号等で照合し、必要なら接続先側でも重複登録を防ぎます。

Incomplete Executionsは自動で保存されますか？

Make公式ヘルプでは保存設定は初期状態で無効と案内しています。シナリオ設定を確認してください。

エラーが直ったらすべて再実行してよい？

いいえ。保存先の作成済みレコードと通知済み件数を照合し、少数のテストから進めます。

無料プランでもできますか？

利用できる機能や上限は時期と契約で変わるため、管理画面と公式料金を確認してください。本記事は特定プランでの動作を保証しません。

再開前の最終チェック

• エラーになった実行と入力IDを特定した
• 保存先に同じIDのレコードがないか見た
• 二重送信し得るモジュールを把握した
• テスト1件で作成数と通知先を照合した
• 再開後に失敗リストが残っていないか確認した

初めてシナリオを作る場合はMakeの基本設定から始めると接続の前提を確認できます。関連する公式情報：Incomplete executions、Retry error handler、料金。Retry・手動解決・Run Replayの違いは2026年10月3日に公式ヘルプで確認。その他の公式情報の確認日：2026年9月26日。

運用で必要になった場合はMakeの登録ページを開く。条件や費用を確認してから選んでください。

※本記事にはアフィリエイト広告を含みます。