設定ミスは手動解決へ。Retryは元の設定で試し直します。
一時的な接続エラーならRetry、設定修正が必要なら未完了実行のDetailsから手動解決を検討します。Run replayは過去データで現在のフロー全体を動かす別の機能。送信や登録が済んでいるか不明なときは、再開より先に相手側の結果を確かめます。
エラー発生時の設定を使う
未完了実行の詳細で修正。元の入力で再開
成功済みの登録・送信も通り直す
公式仕様を整理した模式図です。実画面ではありません。再開位置が途中でも、失敗した外部書き込みの結果確認は必要です。
最初は「どの1件が、どこまで進んだか」を確かめる。
たとえば、記事の候補を整理してから担当者へ通知する自動化。通知で止まったとき、候補の登録までやり直す必要があるとは限りません。逆に「通知が失敗」と見えても、送信先には届き、応答だけ受け取れなかった可能性を切り分ける必要があります。
対象のScenarioを開き、Historyの失敗した実行と、Incomplete executionsの該当レコードを照合します。後者は保存された未完了処理の一覧です。日時だけで曖昧なら、実行ID・失敗モジュール・入力の業務IDを合わせて確認します。画面の開き方はMake公式の管理手順に沿っています。
再開前にメモする3点
- 止まった場所：どのモジュールで、何というエラーか。
- 使った入力：どの記事・注文・依頼の処理か。
- 外部の結果：登録や送信が、未処理・処理済み・不明のどれか。
顧客名やAPIキーを調査メモへ写す必要はありません。自分の管理画面で照合できる識別子を使い、共有するメモは匿名化します。何件も選択して再開するのは、この1件の流れを把握してからです。
「再実行」の3種類は、同じボタンの言い換えではない。
| 方法 | 向く状況 | 押す前の判断 |
|---|---|---|
| Retry | 接続先の一時停止など。設定変更は不要 | 自動再試行待ちではないか。外部への処理結果を確認したか |
| 手動解決 (Manual resolve) | 入力のマッピングやモジュール設定に原因がある | 未完了実行の詳細で修正できるか。元の入力を使ってよいか |
| Run replay | 過去のトリガーデータを、更新したフローへ流したい | 成功済みの工程も再実行してよいか。重複を防げるか |
Retryは失敗当時の構成を使います。通常のDiagramを修正しただけで、保存済みの未完了実行にもその変更が反映される、と考えないことがポイントです。設定が原因なら、対象の未完了実行を開いて直します。公式：Retryと手動解決
Run replayは、過去のトリガー出力を現在のシナリオへ入れ直す機能です。成功済みのモジュールも通り、通常の実行と同様にcreditsを使います。「未完了の続きだけを処理したい」場面で、HistoryのReplay runを代わりに押さないようにします。公式：Run replay
編集上の判断として、再処理の理由を一文にできるか確認するのがおすすめです。「接続先が復旧したので同じ処理をもう一度」「空欄の対応を直してこの1件を続行」「追加した保存先へ過去データを入れ直す」。理由が違えば、確認する範囲も変わります。
Pendingは待機中。Unresolvedは原因を見直す合図。
- Unresolved
- まだ解決していない。エラーを読み、再試行か設定修正かを選ぶ。
- Pending
- 再試行待ち。Scheduled inを見て、いつ再開予定か確認する。
- In progress
- 再試行中。同じ処理を別経路から重ねて始めない。
- Resolved
- 未完了処理の解決に成功。外部側の件数・内容も確認する。
これらは未完了実行のStatusです。History全体の表示とは分けて読みます。Attemptsは試行回数、Scheduled inは再試行までのおおよその待ち時間。エラーが再発したのか、まだ順番待ちなのかを判断する材料になります。
Make公式では、ConnectionError・RateLimitError・ModuleTimeoutErrorなどの未完了実行に自動再試行を案内しています。実行中の元シナリオが終わるのを待つ場合や、同じシナリオ内で再試行が順番待ちになる場合もあります。Pendingが続くときは、元の実行と待ち時間を先に見ます。公式：自動再試行の条件
手動のRetry selectedはScenarioがActiveであることが前提です。ただし、押せないからといって本番のSchedulingを無条件にONへ戻すのは避けます。通常の定期処理や受信処理も再開してよいかを、管理担当者と確認してください。
設定が原因なら、未完了実行を開いて直す。
ここでは、入力値の対応や固定値など、失敗したモジュールの設定を直せば続けられるケースを扱います。たとえば必須項目へ空の値を渡していた場合です。値の意味が分からないまま、適当な文字を埋めてエラーだけ消すことはしません。
対象のDetailsを開く
Incomplete executionsで該当の1件を選び、Detailsへ。警告があるモジュールと、元の入力・エラーを確認します。
失敗モジュールの設定を直してSave
この未完了実行の詳細から対象モジュールを開き、原因のある設定を修正して保存します。通常のDiagram画面だけを直す操作と混同しないようにします。
Run onceで続きを実行
公式手順では、失敗地点から元の入力を使って再開します。元の入力そのものが不足・誤りなら、ここで直せるかを判断し、足りない情報を推測で補わないでください。
Statusと新しい失敗を確認
同じモジュールでまた失敗したら未解決。別のモジュールで失敗した場合は、新しい未完了実行を追います。前の1件が消えた・変わったことだけで、全工程の完了とは判定しません。
操作の根拠はMake公式のResolve an incomplete executionです。今回の修正を次回以降の通常運用にも使いたい場合は、通常のScenario側の設定も別途確認します。1件の救済と、繰り返し発生する原因の修正を、チェック表の別欄に残しましょう。
まずはJSONを読むだけの練習用Scenarioで流れをつかむ。
これは編集部が組み立てた練習案です。Makeでの実行結果やスクリーンショットではありません。メール・Sheets・外部API・AI生成をつながず、2つのParse JSONで「失敗地点の設定を直す」操作を確認します。Make上で実行するため、通常の利用枠は消費し得ます。
- 1 / Parse JSON正しいダミー入力
{"case_id":"LAB-MAKE-001"} - 2 / Parse JSON閉じ括弧がない固定値
{"ready":true - 2に付けるエラーハンドラーRetry自動完了はNo
模式図。後段を直接修正する練習に絞るため、前段の出力は後段にマッピングしません。
新しい練習用Scenarioを作る
本番とは別名にし、SchedulingをOFFのままにします。JSONアプリのParse JSONを2つ並べます。追加の接続認証は不要です。
2つのJSON stringへ固定値を入れる
Data structureは2つとも未指定のまま、JSON stringだけを入力します。前段は図の正しいJSON、後段は閉じ括弧を欠いたJSONです。正常なJSONを手動実行すると構造が判定される、公式の方法を使います。後続への項目マッピングは設定しません。
保存先とRetryを準備する
後段を右クリックし、Add error handler → Retryへ進みます。Automatically complete executionをNo、Scenario settingsのStore incomplete executionsをYesにして保存します。設定ミスを自動で繰り返させないための練習条件です。
手動実行して、未完了の1件を探す
Run onceで全体を手動実行し、後段の失敗とIncomplete executionsの記録を確認します。記録がなければ、この後の修正へ進まず、保存設定とエラーハンドラーを見直します。
未完了実行の詳細で後段を直す
該当のDetailsから後段のJSON stringを、下の正常な値へ置き換えてSave。そこでRun onceを実行し、Statusと後段の出力を確認します。
{"ready":true}練習の期待結果は、後段の出力でreadyが真偽値のtrueになり、未完了処理が解決すること。文字列の"true"とは分けます。このページのローカル確認はJSONの構文・値までで、Make上のStatus変化は未検証です。
参照：JSONモジュール／Retry error handlerの設定。この例は外部サービスへの二重登録が防げるかを検証するものではありません。次の段階で、専用のテスト保存先を使った結果照合が必要です。
Incomplete executionsが空なら、先に「保存されたか」を確認する。
未完了実行の保存は初期状態では無効です。Scenario settingsのStore incomplete executionsを確認します。ONにするのは、以後の失敗を保存するための設定です。過去分を復元した証拠にはならないため、対象の日時・IDで実際に残る記録を探します。保存量には利用枠に応じた上限もあります。公式：保存設定と上限
一覧にないときは、①別のScenarioを見ていないか、②Historyに対象の失敗があるか、③保存設定とエラーハンドラーがその実行に適用されたか、④容量関連のエラーがないか、の順で確認します。原因を一つに決めつけず、見えた表示を記録してください。
保存された未完了処理がない場合、同じ「続きから復旧」ができるとは限りません。Historyに残るデータからRun replayを検討するときも、前段の重複確認に戻ります。実行履歴の保存期間はプランで異なり、単一モジュールだけの実行など、Replayできない履歴もあります。公式：Replayの制約
「Resolvedになった」と「意図どおり1件できた」を分ける。
ここからは運用上の確認案です。登録先に同じ業務IDのレコードが1件ある、担当者への通知が1通だけある、といった読者の仕事としての完了条件を確認します。Makeの実行状態と、相手側の結果を同じメモで追うと判断がぶれにくくなります。
結果不明なら、再送より照合を先に
相手側の登録一覧、送信履歴、APIの照会結果などで対象IDを探します。受理されたか確認できず、重複時の影響が大きい処理は保留。Makeの再試行回数だけから「相手には届いていない」とは判断しません。
練習用なら、「正しいJSONで出力を読めた」が最初の完了条件です。本番ではそれに加え、外部の件数・内容・次回運用の設定を確認します。後から誰が見ても未確認範囲が分かるように、次のひな型を使えます。
対象のScenario名 / 確認日時:
元の実行ID / 未完了実行ID:
失敗したモジュール / エラー名:
Status / Scheduled in / Attempts:
外部への登録・送信は済んでいるか: 未処理 / 処理済み / 不明
照合に使う業務ID（顧客情報・秘密値は書かない）:
選んだ方法 / 再開位置 / 使用する設定:
直した設定 / 元の入力で直せる理由:
再開後のStatus / 新しい失敗の有無:
外部側の確認方法 / 期待件数 / 実際の件数:
通常運用へ同じ修正を反映・確認したか:
今回まだ確認できていないこと:よくある質問
Diagramで直したのにRetryで同じエラーになるのはなぜ？
Retryはエラー当時の設定を使います。設定を直す必要があるなら、保存済みの未完了実行のDetailsから対象モジュールを修正して手動解決します。
Retryなら、二重送信は起きませんか？
再開位置が失敗モジュールになることと、外部側で処理が1回だけ成立することは別です。失敗した送信自体が相手に届いていた可能性があるなら、相手側の履歴を確認してから判断します。
Run replayは、元の実行をそのまま再現しますか？
過去のトリガーデータを使いますが、動くのは現在のフローです。更新された変数は過去の値が保持されない場合もあります。過去の環境すべてを復元する機能ではありません。公式仕様を確認
古い記事のBreakと、今のRetryは同じ前提で読めますか？
古い画面名だけを頼りに設定せず、現行の公式ページにあるRetry error handlerの項目と、手元の表示を照合してください。特に自動完了のYes／Noと未完了保存の設定を確認します。
未完了実行を削除すれば、外部への登録も取り消せますか？
未完了記録の削除を、外部側の取り消し操作の代わりにはしません。残りを実行しない判断と、済んだ登録の修正は別の作業です。なおMake公式は、削除した未完了実行は戻せないと案内しています。
まず1件を特定。原因と再開位置が分かってから動かす。
Retryで直らないときは、回数を増やす前に「同じ設定でも直る一時的な問題か」を考えます。設定修正は対象の未完了実行から手動解決へ。Run replayを選ぶなら、成功済みの工程ももう一度通ることを前提にします。
最初の一手は、History・Incomplete executions・外部の処理結果を1件だけ照合すること。その記録が、再開方法と復旧後の確認の両方に役立ちます。
公式資料と確認範囲
2026年9月16日にMake公式資料を確認しました。図・復旧メモ・練習構成は編集部による説明用の例です。Make実機での復旧、外部サービスへの書き込み、人間によるレビューは未実施。UI名は英語版の公式表記に合わせています。