Makeが動かない時の原因7つと対処法チェックリスト（2026年版）

昨日まで問題なく回っていた自動化が、今朝になって静かに止まっている。通知も来ない。Makeの画面を開いても、赤い文字がどこにも見当たらない。この状況、原因の8割は「エラーが起きた」ではなく「そもそも起動していない」です。

Makeは他のツールと違い、失敗の仕方が静かです。だから最初にやるべきは、エラー内容の解読ではなく、どの段階で止まっているかの切り分け。

Makeが動かないとは、どの状態を指すのか

Makeが動かないとは、シナリオが起動しない・途中で停止する・結果が空になる、のいずれかが起きている状態です。この3つは原因も対処も別物なので、混ぜて考えると迷子になります。

まぎらわしいのが3番目。シナリオの実行履歴には緑のチェックが並び、エラーは1件もない。なのにスプレッドシートには行が増えていない。これは「正常に動いた結果、何も処理しなかった」状態です。フィルタ条件で全件が落とされたときの典型的な見え方。

切り分けの入口として、症状と疑う場所を対応させておきます。

つまり、どこを見に行くかは症状で決まります。エラーメッセージの検索から入るのは、この表で当たりを付けた後で十分です。

最初の3分でやる初動チェック

復旧を急ぐときの手順です。ここまでで直るケースが実務では半分を超えます。

順番に意味があります。上から順に、確認コストが低くて発生頻度が高いものを並べています。

1. シナリオ一覧のトグルがONか（保存はしたが有効化していない事故が最多）
2. Schedulingの実行間隔と、開始日時が未来になっていないか
3. 直近の実行履歴を開き、最後に成功した時刻を確認
4. 組織のUsage画面で、当月の操作数が上限に達していないか

ここまでで異常が見つからなければ、原因はシナリオの中身か連携先にあります。

覚えておきたいのは、Makeが「エラーを出さずに止まる」パターンの多さ。トグルOFF、スケジュール未来日、操作数切れ。この3つは全部、赤いエラーを1件も残しません。静かな停止こそ疑ってください。

自動化の全体設計から見直したいなら、Makeの基本ガイドを先に読むと、この後の話が早く入ります。

そもそも実行されていない場合の原因

シナリオが起動していないときの犯人は、有効化・スケジュール・トリガー種別の3つです。エラーが出ないぶん、気づくのが遅れます。

Makeのシナリオは、編集画面で「Save」しただけでは動きません。一覧画面のトグル、または編集画面左下のスイッチをONにして初めて定期実行の対象になります。テスト用の「Run once」で成功したから安心、というのが最もよくある落とし穴。

スケジュール設定も見落としがち。実行間隔だけでなく、Advanced schedulingで曜日や時間帯を絞っていると、指定外の時間には一切動きません。深夜に検証していて「動かない」と焦ったら、平日9時から18時のみの設定だった、という話は珍しくないです。

タイムゾーンも要注意です。組織のプロフィール設定にあるタイムゾーンが実行時刻の基準になります。ここがUTCのままだと、日本時間の朝9時に動かしたつもりが夕方18時に動きます。9時間ずれる。

もうひとつ、インスタントトリガー（Webhook）を使うシナリオは、そもそもスケジュールで動きません。外部からのリクエストが来た瞬間だけ起動します。相手側の設定が終わっていなければ、Makeはただ待っているだけ。この場合、実行履歴が空なのは正常な状態です。

接続（Connection）切れはなぜ最多の原因なのか

接続とは、MakeとGoogleやSlackなどの外部サービスをつなぐ認証情報のことです。この認証には期限があり、切れた瞬間に該当モジュールが全滅します。

OAuth（他のサービスにログイン権限を預ける仕組み）で作った接続は、パスワード変更、二段階認証の再設定、管理者によるアプリ権限の取り消し、アカウントの権限変更などで無効になります。ユーザー側は何も操作していないのに切れる。ここが厄介なところ。

症状ははっきりしています。特定サービスのモジュールだけが一斉にエラーになり、他のシナリオでも同じサービスが落ちている。エラー文には認証・トークン・権限を示す単語が並びます。

対処はConnections画面から該当接続を選び、Verifyで疎通を確認し、必要なら再認証します。ここで気をつけたいのが、新しい接続を作り直すパターン。接続を新規作成すると、既存シナリオのモジュールは古い接続を参照したまま残ります。同じ名前の接続が2つ並び、片方だけ生きている状態になる。復旧したつもりで半分だけ動く、という中途半端な事故が起きます。

既存の接続を再認証で更新する。これが原則です。

業務システム側の権限管理と絡む話でもあるので、社内でのアクセス権限の棚卸しが必要になったら、内部監査向けAIツールの整理が参考になります。

操作数（オペレーション）の上限に当たっていないか？

操作数とは、シナリオ内のモジュールが1回動くごとに消費されるカウントのことです。月間の上限に達すると、その組織のシナリオが軒並み停止します。

これが「昨日まで動いていたのに今日は全部動かない」の代表的な正体。月初にリセットされて突然復活するので、原因不明のまま放置されがちです。

消費が跳ね上がる原因は決まっています。

つまり、操作数は「何回動いたか」ではなく「何個のデータが流れたか」で増えます。設計を変えずにプランだけ上げると、翌月も同じ壁に当たります。

無料プランは同時に有効化できるシナリオ数にも上限があります。新しいシナリオをONにしたら古いものがOFFになった、という挙動に見えたときは、この枠を疑ってください。2026年4月時点の有料プランは操作数の量で段階が分かれる構成なので、金額と枠は公式の料金ページで確認するのが確実です。

エラーメッセージ別の対処早見表

Makeのエラーは表示が英語のうえ、連携先のAPIからの生メッセージがそのまま出ます。頻出パターンだけ意味を押さえておけば、検索の手間が減ります。

以下は実務で遭遇しやすいものを整理したものです。

つまり4xxは自分の設定側、5xxは相手側。この線引きだけで、直せるものと待つべきものが分かれます。

エラー文の意味をその場で調べるなら、AI検索を使うと連携先の公式ドキュメントに早く辿り着けます。使い分けはFeloの活用ガイドにまとめています。

なぜ実行は成功しているのにデータが空になる？

実行履歴が緑なのに結果が反映されない場合、フィルタでバンドル（Makeを流れるデータの1件分）が0件になっているか、マッピングが外れているかのどちらかです。

フィルタは条件に合わないデータを捨てる仕組みです。捨てた結果0件になっても、Makeはエラーを出しません。仕事をした結果として正常終了します。実行履歴のモジュール間の線をクリックすると、何件通過したかが見えます。ここが0なら犯人はフィルタ。

条件式の型ミスも定番です。「Text: equal to」と「Numeric: equal to」を取り違えると、見た目が同じ値でも一致しません。日付の比較も同様で、文字列のまま比べると期待した結果になりません。

マッピングが外れる事故は、前段のモジュールを差し替えたときに起きます。参照元が変わると、後続の項目が空欄になったり、赤いラベルのまま残ったりする。保存はできてしまうので、実行するまで気づけません。

再現性のある確認方法を挙げておきます。

• 実行履歴で各モジュールの入力（Input）と出力（Output）を1つずつ開く
• モジュール間の接続線に表示される件数を追う
• 空になった直前のモジュールを特定してから条件を疑う
• テストは「Run once」でリアルタイムに流れを見る

画像生成APIを組み込んだシナリオでは、レスポンスの構造が生成側の仕様変更で変わることがあります。画像系の自動化を組んでいるなら、AIイラストツールの選び方や、ローカル環境で動かす選択肢を扱ったComfyUIとStable Diffusionの比較も見ておくと、どこまでMakeに任せるかの線引きがしやすくなります。

Webhookが受け取れないときの確認手順

Webhookとは、外部サービスからMakeへデータを送りつけてもらう受け口のことです。反応しないときは、URL・登録先・データ構造の3点を順に確認します。

WebhookのURLは、Makeが発行した固有のアドレスです。シナリオを作り直したり、Webhookモジュールを削除して置き直したりすると、URLが変わります。送信側の設定に古いURLが残っていれば、当然届きません。

構造の学習も落とし穴。Makeは初回に届いたデータを見て、項目の構造を記憶します。この学習が終わる前に本番のデータを流すと、項目が認識されず後続にマッピングできません。「Re-determine data structure」を押してから、送信側でテスト送信をやり直すのが正しい手順です。

送信側にIPアドレスの制限や署名検証がある場合も届きません。相手側のログに「送信済み」の記録があるのにMakeの履歴が空なら、経路の途中で弾かれています。

SNS連携でよく詰まるのが、プラットフォーム側の権限とAPI仕様の変更です。Meta系のサービスは権限まわりの更新が多いので、Meta AIの機能整理で現状を掴んでおくと、連携が切れた理由の見当が付きやすくなります。

シナリオが勝手に止まった・無効化されたときは？

Makeは連続してエラーが発生したシナリオを自動的に停止します。放置すると操作数を無駄に消費し続けるための保護機能です。

停止するとメールで通知が届きます。ただし通知先は組織の設定に依存するので、担当者の受信箱に届いていないケースがよくあります。「気づいたら1週間止まっていた」の背景はたいていこれ。

復旧の手順は、原因を直してからトグルをONに戻すだけです。ただし、止まっている間に発生したデータの取りこぼしをどうするかは別問題として残ります。

ここで効いてくるのが「Incomplete executions（未完了の実行）」です。シナリオ設定で有効にしておくと、失敗した実行がキューに退避されます。原因を直した後、キューから再実行できる。有効化していないと、失敗したデータはその場で消えます。

ここまでの整理: 静かな停止はトグル・スケジュール・操作数。赤いエラーは接続・権限・データ型。緑なのに空はフィルタ・マッピング。この3分類で当たりを付けてから、個別のエラー文に進むのが最短ルートです。

Make側の障害か、自分の設定か？

切り分けの基準はシンプルです。複数の無関係なシナリオが同時に落ちているならMake側、特定のシナリオだけならこちら側を疑います。

Makeはゾーン単位で稼働しています。自分のアカウントが属するゾーンで障害が起きていれば、公式のステータスページに掲載されます。確認先はhttps://status.make.comです。ここが緑なら、原因は自分の環境か連携先にあります。

連携先の障害も見落とせません。Google WorkspaceやSlackなど、相手側のAPIが不調なら5xx系のエラーが並びます。相手のステータスページも合わせて確認する習慣を付けておくと、無駄な調査を省けます。

判断に迷ったら、単純なシナリオを1本作ってテストします。HTTPモジュールで公開APIを叩くだけの構成で成功すれば、Makeの実行基盤は生きています。あとは対象シナリオの中身の問題。

同じ事故を繰り返さないための設計

エラーハンドリングを組み込んでおくと、止まる前提で運用できます。Makeにはモジュール単位でエラー時の振る舞いを指定する仕組みがあります。

使い分けの目安はこの通りです。

つまり、失敗したデータを捨ててよいかどうかで選ぶディレクティブが決まります。決済や在庫のような取り返しがつかない処理はRollback、通知系はIgnoreが現実的です。

運用で効く仕込みも挙げておきます。

• エラールートを分岐させ、Slackやメールに通知を飛ばす
• 重要なシナリオはブループリントをエクスポートして保管する
• 変更前にシナリオを複製し、旧版をOFFで残す
• Incomplete executionsを有効にして取りこぼしを退避する

ブループリントのエクスポートは地味に効きます。編集を戻したいとき、バージョン履歴だけに頼ると詰むことがあるので、大きな改修の前には手元にJSONを落としておく。5秒の作業で半日を救います。

Makeで無理をせず乗り換えるべきサインは？

Makeが悪いのではなく、そのシナリオがMake向きではないケースがあります。判断の目安を持っておくと、トラブル対応の沼にはまらずに済みます。

以下に当てはまるなら、別の選択肢を検討する価値があります。

• 操作数の消費が読めず、月末に必ず上限へ張り付く
• 分岐とIteratorが入れ子になり、自分でも構造を追えない
• 社内規定でデータを外部クラウドに出せない
• 数万件規模のバッチ処理を毎日回している

主要な選択肢を並べておきます。数字ではなく性格の違いで選ぶのが実務的です。

つまり、複雑さを飲み込めるのがMake、運用を自分で握れるのがn8n、数を稼ぐのがZapier。詳しい比較はn8nとMakeの違いとZapier・Make・n8nの使い分けにまとめています。

AI PICKS編集部の判定

Makeのトラブルは、ツールの品質問題というより設計の負債が表に出た結果であることがほとんどです。動かなくなった瞬間に慌ててモジュールを触ると、たいてい状況が悪化します。実行履歴を開いてどこで止まったかを特定するまで、設定は変えない。この一手を守るだけで復旧速度が変わります。

そのうえで正直に言うと、Makeの「静かに止まる」挙動は不親切です。トグルOFFも操作数切れも赤いエラーを出さないので、初心者ほど原因に辿り着けません。ここは他のツールに比べて明確に微妙な点。

ただし、分岐とループを視覚的に組める自由度は依然として圧倒的で、複雑な業務フローを1本にまとめたいなら一択に近い存在です。乗り換えを考える前に、Incomplete executionsの有効化とエラー通知の追加、この2つを入れてください。多くのチームで「動かない」の体感は、この時点で解消します。

上限に張り付いて設計から見直すことになった段階が、他のツールを検討する適切なタイミングです。

よくある質問（FAQ）

Q. シナリオを保存したのに実行されません。何を見ればいいですか

一覧画面のトグルがONになっているか確認してください。保存と有効化は別の操作です。ONになっているならSchedulingを開き、実行間隔と時間帯の制限、開始日時が未来になっていないかを見ます。ここまでで直らなければ、組織設定のタイムゾーンを確認してください。

Q. エラーは出ていないのに、連携先にデータが届きません

フィルタで全件が落ちている可能性が高いです。実行履歴でモジュール間の接続線をクリックし、通過した件数を確認してください。0件ならフィルタの条件式、特に文字列と数値の型指定を見直します。件数が流れているのに届かない場合は、書き込み先のIDやシート名の指定を疑ってください。

Q. 特定のサービスのモジュールだけ全部エラーになります

接続の認証切れです。Connections画面から該当の接続を選び、Verifyで疎通確認をしてから再認証してください。新しく接続を作り直すと既存シナリオが古い接続を参照したままになるので、既存のものを更新するのが安全です。

Q. 月末になると必ずシナリオが止まります

操作数の上限に達しています。Usage画面で消費の内訳を確認し、消費が大きいシナリオを特定してください。実行間隔を1分から15分に緩める、Search系モジュールにLimitを設定する、Iteratorの前でフィルタして件数を絞る、この3つで多くの場合は収まります。

Q. Webhookにデータを送っても反応しません

発行されたURLが送信側に正しく登録されているか確認してください。シナリオを作り直すとURLが変わります。URLが合っている場合は、Webhookモジュールで「Re-determine data structure」を実行してから、送信側でテスト送信をやり直します。相手側にIP制限があるケースもあります。

Q. 止まっている間に失われたデータは復旧できますか

Incomplete executionsを有効にしていれば、失敗した実行がキューに退避されているので再実行できます。無効のままだった場合、Makeの側にデータは残りません。連携元のサービスから該当期間のデータを取り直し、手動で流し直す必要があります。今後のために、重要なシナリオでは先に有効化しておいてください。

Q. Make自体が落ちているかどうかはどこで分かりますか

公式のステータスページでゾーン別の稼働状況が公開されています。無関係な複数のシナリオが同時に落ちているならMake側、特定のシナリオだけなら自分の設定か連携先の問題です。連携先のステータスページも合わせて確認すると切り分けが早くなります。

Q. 復旧後、同じ事故を防ぐには何を入れればいいですか

エラー時の分岐を作ってSlackやメールに通知を飛ばす設定と、Incomplete executionsの有効化。この2つが最優先です。加えて、重要なシナリオはブループリントをエクスポートして手元に保管しておくと、設定を戻したいときに困りません。

あわせて見たいツール・カテゴリ

• Make — シナリオ設計の自由度が高い自動化ツール。分岐とループを視覚的に組みたい場合の主力
• n8n — 自前サーバーで運用できる選択肢。データを外部に出せない環境向け
• Zapier — 連携先の数が強み。単純な一対一の自動化を数多く回すならこちら
• Yoom — 国内サービスとの連携と日本語情報の厚さが利点
• Power Automate — Microsoft 365中心の環境ならまず検討したい
• Activepieces — 軽量な構成で自動化を始めたいとき
• 業務自動化ツールのカテゴリ — 目的別に候補を眺めるならここから
• ノーコード系ツールのカテゴリ — 開発リソースをかけずに組みたい場合
• 業務自動化ツールのランキング — 導入実績の多い順に見たいとき
• ノーコードツールのランキング — 選定の出発点として

次に読むならこれ: 復旧が済んだら、Makeの基本ガイドで設計の原則を押さえ直してください。今回の事故がシナリオ構造そのものに起因していた場合、対処療法を繰り返すより組み直したほうが早く終わります。

各ツールの公式サイト（一次情報）

料金・機能・対応範囲は各社公式が一次情報です。本記事は公開時点の検証に基づきますが、最新かつ正確な条件は必ず各公式ページで確認してください。

• Make — 公式サイト（AI PICKSの詳細）
• n8n — 公式サイト（AI PICKSの詳細）
• Zapier AI — 公式サイト（AI PICKSの詳細）
• Yoom — 公式サイト（AI PICKSの詳細）