結論から言うと、Makeのエラーは3系統しかありません。データの問題か、プランの上限か、つないだ相手側の問題か。この3つのどれかです。
そして一番よく出るのはRateLimitErrorとConnectionErrorの2つだと、Make公式が明言しています。この2つは相手側の一時的な事情なので、放っておいても直ることが多いタイプです。
この記事では、公式の分類を日本語で全部並べたうえで、放っておいていいものと、すぐ手を打つべきものを分けます。
ノート


赤い画面が出たとき、何を疑えばいいか順番に判断できるようになります。
- エラーと警告の違い
- エラー3系統の全種類(公式の分類を日本語で)
- 放置していいものと、すぐ直すべきもの
- 連続3回で自動停止する仕組み
- エラーハンドラー5種類の使い分け
まず「エラー」と「警告」は別物
赤と黄色で意味が違います。ここを最初に押さえてください。
| エラー(赤) | 警告(黄) | |
|---|---|---|
| シナリオ | 止まる | 止まらない |
| スケジュール | 繰り返すと自動で止められる | 止められない |
| やること | 原因を調べて直す | 履歴を見て確認しておく |
エラーが出ると、Makeはロールバックを試みます。その実行の途中でやった変更を、できる範囲で元に戻す動きです。中途半端な状態で放置されにくい作りになっています。
ちなみに、シナリオ設定で「incomplete executions(未完了の実行を保存)」をオンにしておくと、エラーが警告に変わります。止まった状態が保存されるので、後から原因を調べて再開できます。
エラーは3系統に分かれる
Make公式ヘルプの分類をそのまま日本語にしたものです。
系統1:データの問題
モジュール同士で受け渡すデータがおかしいときに出ます。ほぼ自分の設定側に原因があります。
| エラー名 | ざっくりした意味 |
|---|---|
| BundleValidationError | 受け取ったデータの形が想定と違う |
| DataError | データそのものがおかしい |
| DuplicateDataError | 同じものを二重に作ろうとした |
| IncompleteDataError | 必要な項目が足りていない |
よくあるのはIncompleteDataErrorです。「必須の欄が空だった」というだけのことが多いので、空欄で来る可能性のある項目を洗い出すと直ります。
系統2:プランの上限
契約している枠を超えたときに出ます。設定を直しても解決しません。
| エラー名 | ざっくりした意味 |
|---|---|
| OperationsLimitExceededError | クレジットを使い切った |
| MaxFileSizeExceededError | ファイルが大きすぎる |
| DataSizeLimitExceededError | 扱うデータの量が上限を超えた |
無料プランは1回の最大ファイルサイズが5MB、データ転送が月512MBです。画像やPDFを扱う自動化では、ここに当たることがあります。
系統3:つないだ相手側の問題
APIの仕様変更、認証切れ、相手のサーバーの不調など。自分の設定が正しくても出ます。
| エラー名 | ざっくりした意味 |
|---|---|
| ConnectionError | 相手のサービスにつながらなかった |
| RateLimitError | 短時間に呼びすぎて、相手に断られた |
| AccountValidationError | 接続しているアカウントに問題がある |
| ModuleTimeoutError | 相手の応答が遅くて時間切れ |
| RuntimeError | 実行中の想定外の問題 |






放置していい2つ
公式が「最も頻繁に出る」と書いているのがRateLimitErrorとConnectionErrorの2つです。
どちらも相手側の一時的な事情なので、時間を置けば直ることがほとんどです。公式も「未完了の実行の保存をオンにしておけば、標準のエラー処理に任せてよい」という趣旨のことを書いています。
この2つが出たときにやることは、シナリオを作り直すことではありません。まず1回、時間を置いて再実行してみてください。
すぐ手を打つべき3つ
この3つは扱いが特別で、1回出ただけでシナリオのスケジュールが即座に止められます。
- AccountValidationError(アカウントの問題)
- OperationsLimitExceededError(クレジット切れ)
- DataSizeLimitExceededError(データ量超過)
「気づいたら自動化が丸ごと止まっていた」の原因は、たいていこれです。とくにクレジット切れは月末に起きやすいので、消費量は普段から見ておいてください。



連続3回のエラーで、自動的に止められる
Makeには「連続エラー回数」という設定があり、初期値は3回です。3回続けてエラーで終わると、そのシナリオのスケジュールが無効化されます。
意地悪な仕様に見えますが、これは守りの機能です。壊れたまま動き続けてクレジットを溶かすのを止めてくれています。
例外もあります。Webhookで即時に動くシナリオは、1回のエラーで即停止します。回数の猶予がありません。
この設定はシナリオ設定の詳細設定から変更できます。ただし、回数を増やす前に原因を直すほうが先です。






実際に踏んだエラー:403 PERMISSION_DENIED
ここからは実体験です。AutomaNoteでスプレッドシート→Gmailの自動化を組んだとき、3つ目のモジュールが赤くなって止まりました。
表示されたのは「PERMISSION_DENIED」と403という数字だけ。設定を何度見直しても合っている。しばらく固まりました。
原因は設定ミスではなく、MakeにつないだGoogleアカウントと、スプレッドシートを持っているGoogleアカウントが別だったことでした。Makeから見れば他人のファイルなので、断られていたわけです。
直し方は、Makeが使っているアカウントに、そのシート1枚だけを編集者として共有するだけ。1分で終わりました。
系統でいうと、これは系統3(相手側・認証まわり)です。権限まわりのエラーは、設定を疑う前にアカウントを見てください。詳しい手順はスプレッドシート→Gmailの記事に書いています。



エラーハンドラー5種類
同じエラーが繰り返し出るなら、対処を自動化できます。Makeにはエラーハンドラーが5種類あります。
| 名前 | やること | シナリオは止まる? | 結果 |
|---|---|---|---|
| Skip | そのデータを捨てて次へ進む | 止まらない | 成功 |
| Retry | 後で再試行するために保存する | 止まらない | 警告 |
| Resume | 代わりの値を入れて続行する | 止まらない | 成功 |
| Commit | そこで止めて、変更は確定する | 止まる | 警告 |
| Rollback | そこで止めて、変更を巻き戻す | 止まる | エラー |
何も設定しなければRollbackが標準です。つまり「止まって、元に戻す」が初期動作です。
そして地味に嬉しい仕様がひとつ。エラーハンドラーが動いても、クレジットは消費されません。公式に明記されています。エラー処理を入れることで消費が増える心配はありません。






エラーが出たときの調べる順番
最後に、実際に赤くなったときの手順をまとめます。
- モジュールの上の警告マークをクリックして、エラー名を見る(ここが全部の出発点)
- 名前が RateLimit / Connection なら、時間を置いて再実行
- 系統2(上限)なら、クレジットとファイルサイズを確認
- 系統1(データ)なら、空欄で来る項目がないか確認
- 権限まわりなら、接続しているアカウントを確認
- 実行履歴を開いて、どのデータで落ちたかを1件ずつ見る
順番さえ決まっていれば、赤い画面はただの手がかりです。エラー名を読むところから始めてください。そこに答えの半分が書いてあります。
※エラーの分類や仕様は変更されます。この記事は2026年9月5日に、Make公式ヘルプ(最終更新2026年9月4日)で確認した内容です。
出典
次に読む
- スプレッドシートの行追加でGmailを自動送信する — 403エラーを踏んだときの実際の手順
- Makeのクレジットはどう減るのか — クレジット切れを防ぐ考え方
- Makeの使い方完全ガイド — 用語や画面で迷ったらこちら
数字だけ確認したいときはMakeの数値まとめとよくある質問22に早見表があります。読む順番に迷ったらはじめての方へ|AutomaNoteの歩き方をどうぞ。







