先に言ってしまうと、Makeのエラーの大半は「接続切れ」「マッピングのズレ」「相手側の都合」の3種類に収まります。エラー画面の赤い表示は威圧感がありますが、原因のパターンは案外少ない。
私はこのブログの記事生成をMake.comで組んで運用していましたが、その間に踏んだエラーもほぼこの範囲でした。この記事では、よくある失敗5つの原因と直し方、そしてエラーで止まらないシナリオの作り方まで整理します。
そもそも:エラーが起きるとシナリオはどうなるのか
まず前提の仕組みから。Makeのシナリオは、エラーが起きるとその実行を中断します。そして重要なのが、エラーが連続すると、シナリオ自体が自動でオフになること。
ひとことで言えば、シナリオはブレーカーです。異常が続くと、被害が広がる前に自分で落ちる。安全装置としては正しい挙動ですが、これを知らないと「いつの間にか自動化が全部止まっていた」が起きます。夜中に止まって、朝まで誰も気づかない——自動化あるあるの筆頭です。
もうひとつ知っておきたいのが、エラーで途中まで走った処理も、走った分のクレジットは消費されること。エラーの放置は、動かないうえにお金も漏れる状態です。だから対処法を知っておく価値があります。
エラーが起きたら最初にやること:実行ログを見る
対処の入り口は1つだけ。シナリオ画面の「History(履歴)」から、失敗した実行を開くことです。
ログを開くと、シナリオの流れ図の中でどのモジュールで止まったかが表示されます。モジュールをクリックすれば、入ってきたデータと出て行ったデータ、エラーメッセージの本文が見られる。原因究明に必要な情報は、ほぼすべてここにあります。
エラーメッセージは英語ですが、読むべきポイントは「エラーの種類名」と「数字3桁のコード(401、429など)」の2つだけ。次の章で、頻出パターンを日本語に翻訳していきます。
よくある失敗5つと直し方
失敗1:接続切れ(401 Unauthorized)
いちばん多いのがこれ。GmailやGoogle Sheetsなど外部サービスとの「接続(Connection)」の認証が期限切れになり、401エラーで弾かれるパターンです。昨日まで動いていたのに突然止まった、という場合はまずこれを疑ってください。
直し方:エラーが出たモジュールを開き、Connection欄から再認証(Reauthorize)する。それでも直らなければ、接続をいったん削除して作り直します。パスワード変更やセキュリティ設定の変更をした直後に起きやすい、というのも覚えておくと原因究明が早いです。
ちなみに私の場合、WordPressとの接続で401が出続けたことがありました。原因はMake側ではなく、レンタルサーバー(エックスサーバー)のセキュリティ設定でREST APIへのアクセスが制限されていたこと。Makeの設定をいくら見直しても直らないときは、相手側のサービスの設定を疑う。これはエラー対処全般に効く考え方です。
失敗2:マッピングのズレ(データが空っぽ)
モジュール間でデータを受け渡す設定(マッピング)で、参照先のデータが存在せず、空の値が渡って後続が失敗するパターン。「Validation failed」系のエラーや、動くけれど中身が空、という形で現れます。
直し方:ログで、失敗したモジュールに「何が入ってきたか」を確認します。期待した項目が空なら、原因は上流にある。たとえばGoogle Sheetsの列名を変えた、フォームの項目を消した——上流側の小さな変更が、下流のマッピングを静かに壊します。シナリオの外で何かを変更したら、シナリオも見直す。この習慣だけでこの失敗は激減します。
失敗3:回数制限(429 Too Many Requests)
相手のサービスに短時間でアクセスしすぎて、「ちょっと落ち着いて」と止められるパターン。大量の行を一気に処理するときや、AI系のAPIを連続で呼ぶときに出がちです。
直し方:一度に処理する件数を絞る(トリガーモジュールの取得上限を下げる)、モジュール間にSleepモジュールを挟んで間隔を空ける、実行頻度そのものを下げる。力技で再実行しても、また同じ壁に当たります。流量を減らすのが正解です。
失敗4:トークン切れで出力が途中で終わる(AI連携)
エラー表示が出ないぶん厄介な失敗。AIモジュールで生成した文章が途中でぷつっと切れているパターンです。原因は、AIモジュールの最大トークン数(出力の上限)の設定が小さいこと。
直し方:AIモジュールの詳細設定(Advanced settings)でMax Tokensを上げる。私が記事生成を回していたときは、8000に設定してようやく日本語の長文記事が最後まで出るようになりました。初期値のままだと、長い出力はまず切れます。AI連携で「なんか短い」「最後の文が変」と感じたら、エラーログよりも先にこの設定を見てください。
失敗5:テスト実行で本番データを動かしてしまう
エラーというより事故ですが、被害が大きいので入れておきます。シナリオ作成中の「Run once」で、本番のスプレッドシートに書き込んだり、本物のメールを送ってしまったりするパターン。自動化の失敗談として、たぶん最も背筋が冷えるやつです。
直し方(予防):作成中はテスト用のシート・テスト用の宛先に差し替えておく。処理件数の上限を1にする。送信系のモジュールは最後に足す。地味な習慣ですが、これで事故はほぼ防げます。
エラーで止まらないシナリオにする:エラーハンドラー
個別の対処と別に、そもそも「エラーが起きても全体は止まらない」設計にする道具があります。それがエラーハンドラー。モジュールを右クリックして「Add error handler」を選ぶと、そのモジュールが失敗したときの逃げ道を作れます。
主な選択肢は5つ。
- Ignore:そのエラーを無視して次へ進む(欠けてもいい処理向き)
- Resume:代わりの値を渡して続行する(空欄をデフォルト値で埋める等)
- Break:未完了として保存し、あとで再実行できるようにする
- Commit:そこまでの処理を確定して終了する
- Rollback:処理を巻き戻して終了する(既定の挙動に近い)
全モジュールに付ける必要はありません。外部サービスに依存するモジュール(接続切れ・回数制限が起きうる場所)にだけ付けるのが現実的です。そしてうれしいことに、エラーハンドラー系モジュールはクレジットを消費しません。保険はタダで付けられるわけです。
復旧したあとにやること
原因を直したら、2つ確認を。まず、シナリオが自動オフになっていたらスケジュールをオンに戻すこと。直しただけでは再開しません。次に、止まっていた間のデータの取りこぼしがないか。Webhookで受けたデータはキューに溜まっていて再開後に処理されますが、ポーリング型のトリガーだと、止まっていた期間の扱いがモジュールの設定次第で変わります。取りこぼしが疑われる場合は、対象期間を指定して手動実行するのが確実です。
よくある質問
エラーが起きたらメールなどで知らせてもらえますか?
シナリオがエラーで自動オフになると、Makeから登録メールアドレスに通知が届きます。さらに、エラーハンドラーの先にメールやSlackの送信モジュールをつなげば、「エラー発生を自分に通知する」仕組みも自作できます。放置事故を防ぐならこの自作通知がおすすめです。
エラーになった実行は、あとからやり直せますか?
Breakハンドラーで「未完了の実行(Incomplete executions)」として保存しておけば、原因を直したあとに一覧から再実行できます。何も設定していない場合は、その実行分は失敗として終わるので、必要なら手動で流し直します。
何回エラーが続くとシナリオはオフになりますか?
連続で数回(目安として3回程度)失敗すると自動で無効化される仕様です。正確な条件は変わる可能性があるので、「連続エラー=止まるもの」と覚えておくのが安全です。
エラー対処にプログラミング知識は必要ですか?
この記事のレベルなら不要です。ログを開いて、どのモジュールで・何のコードで止まったかを見る。それだけで大半は対処に入れます。401なら再認証、429なら流量を減らす、と対応表で動けば十分です。
まとめ:エラーは「どこで・何番で」の2点だけ見る
エラー対処と聞くと難しそうですが、実際に見るべきはどのモジュールで止まったかとエラーコードは何番かの2点だけ。401なら接続、429なら流量、コードなしで空データならマッピング。この対応表が頭にあれば、赤い画面はもう怖くありません。
私がブログの記事生成をMakeで回していたときも、結局この2点確認とエラーハンドラーの保険で安定運用に落ち着きました。エラーはゼロにするものではなく、止まらない設計で受け流すもの。次にシナリオが赤くなったら、まずログの「どこで・何番で」から見てみてください。
※本リンクはアフィリエイトリンクです。 Make.com(※アフィリエイトリンクです)
コメント