Makeのエラー対応｜履歴・未完了実行・安全な再実行の手順

履歴から失敗した入力と操作を特定する

対象の実行履歴で、開始時刻、失敗モジュール、エラーの種類、受付IDを確認します。前のモジュールの出力と失敗したモジュールの入力を見比べ、必須項目が届いているかを調べます。顧客本文や認証情報をそのまま他人へ貼り付けず、調査に必要なIDとエラー内容だけを共有します。

入力不備・認証・制限・一時障害を分ける

必須項目の欠落は入力や割り当ての修正、認証切れは接続と権限の見直し、API制限は頻度や待機の調整が必要です。一時障害は回復後の再試行が候補になりますが、同じ不正入力を繰り返しても直りません。複数件のうち一件だけ不備があるなら、正常な受付まで失わない分け方を検討します。

未完了実行を保存できるようにする

必要なシナリオでは設定のStore incomplete executionsを確認します。有効化により、失敗時の状態を保存して後から調べられますが、保存容量や設定による制約があります。機密データを残さない設定では、調査できる情報が減る点も考えます。保留が増えていないかを確認する担当者を決めてください。

Retry・Skip・Resumeを用途で選ぶ

Retryは再試行、Skipは対象データを後続から外す、Resumeは代替の出力で後続へ進む選択です。重要な受付をSkipして見かけ上成功にしないこと、存在しない保存先IDをResumeで作って先へ進めないことが大切です。画面や旧資料で名称が異なる場合は現行ヘルプと照合します。成功表示だけで業務が完了したとは判断しません。

再開前に保存先と通知先を照合する

受付IDで台帳を探し、保存済みならそのレコードIDを使います。通知が届いているかも別に確認してください。タイムアウトでは送信先だけ成功している場合があります。未完了実行の再開か、状態の修正か、必要な一操作の再実行かを選びます。外部サービスの更新は、シナリオのロールバックで必ず取り消せるわけではありません。

練習環境で部分失敗を確認する

自分たちの練習用データと通知先で、必須項目なし、接続権限の不備、保存後に通知できない場面を確認します。意図的に止める操作は本番では行いません。復旧後に受付IDごとの台帳と通知を照合し、欠落と重複の両方を見ます。この記事はその確認項目を示したもので、実施済みの障害試験結果ではありません。

よくある疑問：通知が来ないのに成功と表示される

フィルターの条件で対象外になった場合や、エラーをSkipした場合などは、必要な通知がなくても全体が成功扱いになることがあります。まず入力の受付IDが後続まで進んだかを確認します。エラー通知の有無だけでなく、受け付けた件数と台帳・通知の件数を照合すると、この種の漏れを見つけやすくなります。

ただし台帳の件数と通知件数は、まとめ通知や対象外の条件によって一致しない設計もあります。期待する対応を先に決めてから点検し、差が出たことだけを障害と判断しないようにしてください。

停止と復旧の担当者を決める

手順書には、停止する条件、連絡先、未処理一覧、再開前に照合する項目を残します。自動再試行を続けても回復しない場合に、人が確認する期限も決めてください。通知先そのものが停止したときにエラー連絡まで消えないよう、重要な業務では別の確認経路を持たせます。復旧後は原因と再発防止を記録します。

• Makeの重複登録を防ぐ｜受付ID・Data store・再実行の設計
• MakeでGoogleフォームの回答をSlackに通知する方法
• Makeでフォーム受付メールを自動返信する｜宛先・本文・送信状態の設定
• MakeでGmailをスプレッドシートに記録する｜対象メールと重複の設定