ノーコード自動化は「止まらない設計」が命
Make（旧Integromat）を使えば、メール送信やスプレッドシート更新、AIとの連携など、多くの業務をノーコードで自動化できます。
しかし、実際に運用してみると「いつの間にかシナリオが止まっていた」「一部の処理が失敗していた」といった経験を持つ人も多いはずです。
自動化が便利なのは、“常に動き続けていること”が前提です。
もしシナリオが止まると、通知が届かず、請求が遅れたり、顧客への対応が抜け落ちたりするリスクが発生します。
この問題を防ぐ鍵が、**エラー処理とリトライ設計（再試行の仕組み）です。
Makeには強力な「エラー処理ツール」が備わっており、適切に設計すれば「落ちない自動化」**を実現できます。
「エラー処理をしない自動化」は、いずれ止まる
Makeは非常に高機能ですが、すべてのAPI・外部サービスが常に安定しているわけではありません。
たとえば次のようなケースでエラーが発生します。
| エラーの種類 | 原因 | 発生頻度 |
|---|---|---|
| 一時的な通信エラー | 外部APIやネットワークの遅延 | よくある |
| データ型の不一致 | 数値・日付・文字列の形式が違う | 中程度 |
| 認証エラー | APIトークンの期限切れや更新忘れ | 時々 |
| Rate Limit（制限超過） | 短時間にリクエストを送りすぎ | よくある |
| 空データ・NULLエラー | 必須項目の欠落 | よくある |
これらのエラーを処理しないままにすると、
Makeのシナリオはその時点で停止し、後続の処理も止まってしまいます。
つまり、ノーコード自動化の最大の敵は「想定外の停止」です。
そしてそれを防ぐ唯一の方法が、「止まらない設計」＝エラーとリトライの体系的な仕組みなのです。
Makeのエラー処理を理解するための基本構造
Makeの自動化フロー（シナリオ）は、モジュールと呼ばれるブロックの連続で構成されています。
この中でどこか1つでもエラーが出ると、通常はそこでシナリオ全体が停止します。
ただし、Makeには次のような制御機能が用意されています。
エラーハンドラー（Error Handler）
各モジュールに分岐線を追加し、「エラーが起きたときに別のルートを実行する」仕組みです。
たとえばメール送信が失敗した場合に「Slackで通知を送る」「別の宛先にリトライする」といった代替ルートを設定できます。
リトライ設定（Auto Retry）
一時的なエラーに対して自動的に再試行を行う機能です。
APIが一時的に落ちている場合などに、一定時間後に再試行して成功させることができます。
ストラテジー（Error Handling Strategy）
各エラーハンドラーの中で、エラー発生時にどのような動作をするかを細かく指定できます。
たとえば：
- Resume（スキップして続行）
- Ignore（無視して次へ）
- Rollback（実行前の状態に戻す）
- Stop（シナリオ全体を停止）
これらを適切に使い分けることで、「完全停止を防ぎつつ、通知や再処理を自動化」できます。
自動化の安定性を高める3層設計の考え方
Makeでのエラー処理を設計する際は、以下の3層を意識すると体系的に整理できます。
| 層 | 内容 | 目的 |
|---|---|---|
| 第1層：モジュールレベル | 各処理単位でのリトライ設定・型チェック | 小さな失敗を即座にリカバリー |
| 第2層：シナリオレベル | エラーハンドラー・通知設定 | シナリオ全体の停止を防ぐ |
| 第3層：システムレベル | 外部監視・ログ・再起動フロー | 異常発生時の復旧・報告を自動化 |
この「三層構造」を意識することで、Makeのシナリオは堅牢になります。
一度エラーが起きても「止まらず、知らせて、再試行する」流れを自動で回せるのです。
「止まらないMake」のための基本原則
Makeのエラー処理を設計するうえで押さえておきたい原則は次の3つです。
- 失敗を前提にする設計
外部APIやネットワークは100％安定していません。成功を前提に作ると必ず落ちます。 - 自動で再試行できる流れを作る
リトライを組み込むことで、人が介入しなくても復旧できる仕組みにします。 - 通知・ログ・監視を仕組みに組み込む
完全自動化は理想ですが、「止まったことに気づけない」状態は致命的です。Slack通知などを併用します。
Makeのエラー処理を構成する主要パターン
Makeでエラーを処理する方法には複数のパターンがあります。
代表的な4パターンを表に整理します。
| パターン | 概要 | 主な用途 |
|---|---|---|
| Try → Catch構成 | エラーハンドラーで別ルートへ分岐 | API失敗時の代替処理 |
| リトライ構成 | 一定時間後に自動再試行 | 一時的なAPIエラー対策 |
| フォールバック構成 | 別アクションに切り替え | メール送信失敗→Slack通知など |
| ログ＋通知構成 | エラー情報を残し、人に知らせる | 運用監視用 |
これらを組み合わせると、ほぼすべてのケースに対応可能です。
たとえば「3回までリトライ→それでもダメならSlack通知→ログに保存」といった流れを作れば、止まるリスクは大幅に減ります。
「再試行設計」が重要な理由
なぜリトライ設計が重要なのか。
その理由は、**エラーの8割以上が“再試行すれば成功する一時的エラー”**だからです。
特に以下のようなケースでは、リトライ設定が極めて有効です。
- APIサーバーが混雑してレスポンスが遅延
- Google Sheetsの書き込み制限（Rate Limit）に一時的に到達
- ネットワーク断が数秒発生
- 一時的に認証が無効化されたが、すぐに復旧
このようなケースでリトライを設けておけば、「一時的エラーによる停止」を完全に防げます。
逆にリトライがないと、毎回人間が手動で再実行しなければならず、自動化の意味が半減します。
リトライ設定の最適化ポイント
Makeのリトライ設定には細かいカスタマイズが可能です。
以下の3点を押さえると、安定性が飛躍的に向上します。
- リトライ回数：最大3回程度が目安（API制限に配慮）
- 間隔設定：指数的バックオフ（1分→3分→5分…）が理想
- 失敗時処理：最後の失敗時にSlack通知やエラーログ送信を追加
指数的バックオフを採用することで、サーバーが混雑しているときも負荷を分散しながら再試行できます。
この設計はGoogleやAWSでも採用されている、信頼性の高いリトライ戦略です。
実例①：Slack通知付きのエラーハンドラー設計
最も基本的で効果的なエラー処理が、Slack通知付きエラーハンドラーです。
シナリオが途中で失敗しても、すぐに自分（またはチーム）へ通知が届く仕組みを構築します。
設定ステップ
- 対象モジュールを選択
- たとえば「Google Sheetsに書き込む」モジュール。
- エラーハンドラーを追加
- モジュール右クリック → “Add error handler”。
- ハンドラー内にSlackモジュールを配置
- 通知チャンネルを選び、メッセージ本文に以下を設定：
【Makeエラー通知】 モジュール: {{module.name}} エラー内容: {{error.message}} シナリオ: {{scenario.name}}
- 通知チャンネルを選び、メッセージ本文に以下を設定：
- ストラテジーを「Resume」で設定
- Slack通知後も処理を継続できるようにします。
この設計により、Makeのシナリオは“落ちることはあっても、気づかず止まり続ける”ことがなくなります。
Slack通知には時刻やエラー種別も含めておくと、後からトラブルシュートが容易になります。
実例②：再試行＋フォールバック構成のテンプレート
次に紹介するのは、リトライ＋フォールバックの組み合わせ。
単純な再試行だけでなく、一定回数失敗した後に“代替手段”を自動で発動させる仕組みです。
構成イメージ
Main Route
└▶︎ モジュール①：API送信（Auto Retry: 3回）
└▶︎ 成功 → 次へ
└▶︎ エラー → エラーハンドラー
└▶︎ フォールバックモジュール（例：メール送信）
└▶︎ Slack通知
実装のポイント
- Retry設定はモジュール単位で「Auto Retry 3回・指数間隔」を設定
- エラーハンドラーでは「フォールバック処理→通知→続行」の順に
- 停止条件は「重大な認証エラー（401/403）」など限定的にする
これにより、外部APIが落ちていてもシナリオは止まりません。
フォールバックをメール送信やGoogle Sheets書き込みに変えれば、
“本処理が落ちても記録を残す”安全設計になります。
実例③：サブシナリオを使った自動回復設計
エラーが複雑なシナリオでは、1つのシナリオ内で全てを処理するより、
「メインシナリオ＋サブシナリオ」に分けるのが効率的です。
構成パターン
| 名称 | 役割 | 主な内容 |
|---|---|---|
| メインシナリオ | 通常の業務処理 | データ取得・更新など |
| サブシナリオ | エラー処理専用 | ログ記録・通知・再実行 |
仕組みの流れ
- メインシナリオでエラーが発生
- エラーハンドラーが起動
- 「Run another scenario」モジュールでサブシナリオを呼び出す
- サブシナリオ内でSlack通知・スプレッドシート記録・再実行判定を実行
これにより、複数のシナリオで同じエラー処理を共通化できます。
運用面でも「全シナリオがどこで落ちたか」を一元監視できるようになります。
高度な応用：AI連携で“自己修復型”の自動化を作る
最近では、ChatGPT APIやClaudeを活用して「エラーを自己分析する」仕組みを作ることも可能です。
仕組みの例
- Makeでエラーが発生
- エラーハンドラーがChatGPT APIを呼び出し
- 以下のようなプロンプトを送信：
以下のエラーログを要約し、原因と対処方法を簡潔に出力してください。 {{error.message}} - ChatGPTの出力結果をSlackに投稿
これにより、Slack上に「AIによるエラー解説」が自動投稿されます。
開発者がいなくても、チーム全体が原因を把握しやすくなり、対応スピードが飛躍的に向上します。
運用フェーズで意識したい監視とメンテナンス
エラー処理を設計しても、完全に放置できるわけではありません。
運用フェーズでは、次の3つのポイントを定期的にチェックしましょう。
- 実行履歴（Scenario History）
- 「Failed」「Incomplete」ステータスを定期的に確認。
- 失敗パターンを溜めて“再利用可能なエラーハンドラー”を改善。
- Webhook制限・API更新
- GoogleやSlackなどのAPIは仕様変更が頻繁。認証切れを防ぐために定期更新が必要です。
- 通知ルールの見直し
- 通知が多すぎると“通知疲れ”になります。
重大エラー（認証・Rate Limit超過）だけを通知するなど、優先順位をつけましょう。
- 通知が多すぎると“通知疲れ”になります。
Makeでは「シナリオ実行履歴を別シートに自動転送」することで、エラーログを半自動的に蓄積できます。
運用レベルが上がるほど、記録の自動化が重要になります。
チーム運用で役立つベストプラクティス
業務が拡大し、複数人でMakeを使うようになると、
「誰がどのシナリオを管理しているのか」「いつエラーが起きたのか」が見えづらくなります。
そこで役立つのが、以下の管理ルールです。
| 管理項目 | 推奨設定 |
|---|---|
| シナリオ命名 | [担当者名]_[機能名]_v1 などルール化 |
| 通知ルール | 各担当者専用のSlackチャンネルを用意 |
| ログ格納先 | Google Sheets or Notionで一元管理 |
| 定期レビュー | 月1回の「自動化ヘルスチェック」会議 |
これにより、Makeを“属人的な自動化ツール”から“チームのインフラ”に進化させることができます。
実践ステップ：止まらない自動化をつくる手順
最後に、この記事の内容をもとにした実践ロードマップをまとめます。
- すべてのモジュールにエラーハンドラーを設置
- Auto Retryを3回＋指数的間隔で設定
- Slack通知を最低1カ所に導入
- 失敗時に再試行 or 代替処理を定義
- 共通エラーハンドラー用のサブシナリオを作成
- シナリオ履歴を自動でログ化
- 月1回のチェックで改善を継続
この7ステップを実装すれば、「Makeが落ちる」ことへの不安はほぼ消えます。
そして、止まらない自動化はそのまま“信頼できるAIシステム”につながります。
まとめ：自動化の本質は“仕組みが止まらないこと”
Makeで自動化を設計する際に最も重要なのは、スクリプトの正確性ではなく耐障害性です。
一時的なエラーは避けられませんが、それを想定し、再試行・フォールバック・通知を組み込むことで、
人の手を介さずに動き続ける“強い自動化”を実現できます。
| 目的 | 実装の柱 | 効果 |
|---|---|---|
| 安定稼働 | リトライ・バックオフ | 短期的な停止防止 |
| 可視化 | Slack通知・ログ化 | トラブル早期発見 |
| 継続改善 | サブシナリオ化・共通化 | 運用効率向上 |
ノーコードの時代における“自動化エンジニア”は、ツールを使う人ではなく、
止まらない仕組みを設計する人です。
あなたのMakeが、24時間365日動き続ける“無停止オートメーション”になることを願っています。
