Makeのエラー対応｜止める・知らせる・直す設計

Makeのシナリオで大切なのは、エラーを一度も起こさないことではありません。失敗を早く見つけ、影響範囲を止め、同じデータを二度処理せずに復旧できる状態をつくることです。とくに請求書、受注、申請、顧客情報のように後工程へ渡るデータは、通知が届いたかだけでは完了と判断できません。

この記事では、Makeの画面操作そのものではなく、エラーに強い業務設計を扱います。Makeや接続先サービスの機能・制限は変わるため、実装時は必ず各サービスの公式ドキュメントと自分の契約条件を確認してください。

先に結論：失敗した処理を「見つけられる仕事」に変える

自動化が失敗したとき、担当者が最初に知りたいのはエラー文ではありません。「何が止まったか」「誰に影響するか」「再実行して安全か」です。そこで、通常処理、確認待ち、失敗、再処理済みを同じ一覧で追えるようにします。

状態	意味	自動化がしてよいこと	人が確認すること
`受付`	入力を受け取っただけ	受付IDと受信時刻を記録する	入力に不足がないか
`処理中`	シナリオが後工程へ渡している	対象データを読み、処理記録を残す	同時実行がないか
`確認待ち`	条件外・不明値・重要判断がある	担当者へ必要最小限の通知を送る	続行、保留、差し戻し
`完了`	必要な結果を確認できた	完了日時と結果IDを残す	結果の妥当性を定期点検
`失敗`	自動処理を完了できなかった	失敗箇所と対象IDを記録して停止する	原因確認、修正、再実行可否

この状態をGoogleスプレッドシート、データベース、チケットなど一つの管理場所に残せば、Slackやメールは「確認へ誘導する手段」になります。通知そのものを正本にしないことが、引き継ぎと復旧を楽にします。

最初に決める5項目

決める項目	具体例	決めない場合のリスク
処理の単位	注文番号、フォーム受付ID、請求書ファイルID	再実行時に対象を特定できない
正本データ	受注はShopify、処理状態は管理台帳、添付はDrive	複数の表で値が食い違う
停止条件	金額不一致、必須項目不足、権限エラー、重複候補	誤った結果が後工程へ流れる
通知の責任者	一次確認者、不在時の代替、営業時間外の扱い	通知だけが残り、誰も対応しない
再実行の条件	修正済み、重複なし、対象範囲を確認済み	二重送信・二重登録が起きる

「失敗したらSlackへ送る」という設計だけでは不十分です。通知には、対象ID、処理段階、失敗時刻、確認先URL、次に選べる操作を含めます。ただし、氏名、住所、認証情報などを必要以上に通知文へ含めないでください。

例：請求書を台帳へ記録するシナリオ

メール添付の請求書をDriveへ保存し、管理台帳へ記録する例を考えます。ここでの目的は、すべての添付を自動処理することではなく、確認が必要な請求書を取りこぼさないことです。

段階	入力	Makeの役割	完了の判定	例外時の扱い
受付	メールと添付ファイル	メールID・ファイルIDを記録	受付IDが発行された	添付なしは確認待ち
判定	送信元、件名、ファイル形式	ルールに合う候補を分ける	判定理由が残る	不明な形式は停止
保存	対象ファイル	決めたDriveフォルダへ保存	保存先IDを台帳へ記録	同名・重複候補は確認待ち
記録	請求月、取引先、金額候補	管理台帳の候補欄を更新	必須項目がそろう	金額・取引先不明は人へ渡す
確認	担当者の判断	通知と確認リンクを送る	人が確定した状態になる	差し戻し理由を残す

このように、保存・記録・承認を分けると、途中で失敗しても戻る場所が明確です。たとえば保存済みだが台帳更新に失敗した場合、ファイルIDと受付IDから台帳更新だけをやり直せます。

重複を防ぐための設計

再実行は「もう一度ボタンを押す」ことではありません。まず、同じ仕事をすでに完了したか確認します。重複判定には、入力ごとに変わらないIDを使います。メールならメッセージID、フォームなら回答ID、注文なら注文番号を候補にします。件名やファイル名だけでは、人の変更や同名ファイルで判定を誤るためです。

判定結果	意味	次の操作
未処理	記録がない	通常処理へ進む
処理中	別の実行が動いている可能性	待機し、担当者へ必要時だけ通知
完了	結果IDと完了日時がある	処理しない。参照リンクだけ返す
失敗	途中までの記録がある	失敗段階と副作用を確認して限定再実行
判定不能	IDがない、または矛盾する	自動処理を止め、人が確認

二重送信や二重登録を防ぐには、外部サービスへの書き込み前にも状態を確認します。すでに送信済みかを記録で確認できない場合は、再実行を自動化せず、人が対象を絞って処理してください。

エラーを4種類に分ける

エラーを一括で扱うと、緊急度の判断が遅れます。まずは次の4種類に分けるだけで、通知と復旧の優先順位が作れます。

種類	例	自動化の動き	担当者の最初の確認
入力不備	必須列が空、想定外の形式	対象を確認待ちへ移す	元データの訂正担当は誰か
接続・権限	認可切れ、接続先の一時障害	後工程を止め、失敗時刻を記録	影響範囲と復旧見込み
ルール不一致	担当者表に該当者がいない	共通窓口へ渡す	ルールを直すか個別判断か
重複・整合性	同じIDが複数、金額が一致しない	書き込みを止める	正本と既存結果のどちらが正しいか

接続エラーでも、相手側で処理が完了している可能性があります。タイムアウトや不正応答の直後に機械的に再送すると、重複を作ることがあります。結果が不明な場合は「失敗」ではなく「要確認」として止め、外部サービス側の履歴と管理台帳を照合してください。

変更管理と引き継ぎの最低ライン

Makeのシナリオは、画面上では分かりやすく見えても、接続先・フィルター・通知先・例外処理が増えると属人化します。変更する前に、少なくとも次を残します。

シナリオの目的と対象業務
入力、正本データ、出力先
トリガー、主要な条件、停止条件
接続を管理する責任者（認証値そのものは記録しない）
通常時の確認頻度と、障害時の連絡先
テスト方法、変更日、戻し方

変更は一度に一つの意図へ絞ります。通知先、フィルター、書き込み先を同時に変えると、失敗原因を切り分けにくくなります。変更後はテストデータで、通常ケース、入力不備、重複候補の少なくとも3ケースを確認します。

運用チェックリスト

頻度	確認すること
毎日	失敗・確認待ちが残っていないか。担当者が不在になっていないか。
毎週	同じエラーが繰り返されていないか。通知が多すぎて見落とされていないか。
変更時	正本、停止条件、再実行手順、通知先を見直したか。
月次	接続権限、不要な個人情報、不要になったシナリオを点検したか。

復旧を急ぎすぎないための実行手順

エラー通知を受け取った直後は、シナリオを再実行する前に「外部へ何かを書き込んだか」を確認します。ここを省くと、同じメールを二度送る、同じ注文を二度登録する、同じファイルを複製するといった事故につながります。復旧担当が変わっても使えるよう、次の順番を運用手順として共有します。

管理台帳で受付ID、現在の状態、最後に完了した段階を確認する。
接続先の履歴で、書き込み・通知・ファイル作成が実行済みかを確認する。
入力不備、設定変更、接続障害、重複候補のどれかへ分類する。
修正する場所を一つに絞り、修正内容と担当者を記録する。
必要な段階だけを、テストまたは限定対象で再実行する。
結果ID、完了日時、残った確認事項を台帳へ戻す。

状況	すぐに再実行してよいか	先に確認すること	推奨する扱い
入力の必須項目が空	いいえ	元データを誰が直すか	訂正後に対象IDだけ処理
接続先が一時的に応答しない	原則いいえ	相手側で成功していないか	結果不明として照合
通知モジュールで失敗	条件付き	通知済み履歴、宛先、内容	通知段階のみ再実行
台帳への記録で失敗	条件付き	外部処理の結果ID	結果IDを使って台帳だけ補正
同じIDがすでに完了	いいえ	完了結果が正しいか	再実行せず記録を参照
ルール自体が誤っていた	いいえ	影響を受けた対象一覧	停止して変更レビューへ回す

通知を「対応できる情報」にする

通知が多すぎると、重要な障害ほど埋もれます。成功通知を毎回送るより、確認待ちと失敗を区別し、同じ原因の通知を必要に応じて集約します。通知文は、受け取った人が別の画面を探さなくても次の判断を始められる情報に限定します。

通知に入れる情報	理由
対象IDと業務名	何の処理かを特定するため
失敗した段階	どこから確認すべきか分かるため
発生時刻と実行記録へのリンク	同時実行や履歴を照合するため
影響範囲の仮説	緊急度を判断するため
次の選択肢	修正、保留、限定再実行、担当変更

エラーの詳細には接続先から返された値が含まれる場合があります。通知先が広いチャンネルなら、個人情報、顧客データ、アクセストークン、ファイル本文を載せません。詳細が必要な場合も、権限を管理した確認場所へのリンクを使います。

まとめ

Makeのエラー対応では、止める・知らせる・直すを別の仕事として設計します。処理単位のID、正本、状態、停止条件、再実行の条件を先に決めれば、エラーは「何が起きたか分からない障害」から「確認して戻せる作業」へ変わります。最初は一つの業務と少数の例外から始め、実行履歴を見ながらルールを育ててください。

参考資料

Makeを試す前に、公式サイトで利用条件と料金を確認できます。

Make公式サイトで利用条件を確認する