Makeが遅い原因と対処法 レスポンスを3倍速くする設定7つと切り分け手順

フォームに入力してから、Slackに通知が飛ぶまで15分。その間に「動いてないのでは」と何度も画面を開き直す。Makeを使い始めた人がほぼ全員ぶつかる場面です。

答えを先に言うと、その15分はバグではありません。プランで決められた最小の実行間隔です。設定を変えれば、この待ち時間はほぼ消えます。

Make（旧Integromat）とは、複数のWebサービスをドラッグ操作でつなぎ、決まった作業を自動で走らせるクラウド型の自動化ツールです。プログラムを書かずに組めるかわりに、動き方のクセを知らないと「なぜか遅い」に悩まされます。

このクセを7つの設定に分解して潰していきます。

Makeが遅い原因は、ほぼ3つに絞れます

Makeの遅さは、待ち時間の発生場所で3種類に分かれます。原因を特定しないまま設定をいじると、効かない場所を延々と直すことになります。

1つめは起動の遅さ。トリガーが動き出すまでの待ち時間で、これはプランの最小実行間隔に縛られます。

2つめは処理の遅さ。シナリオが走り始めてから終わるまでの時間で、モジュールの数と外部APIの応答速度で決まります。

3つめは画面の遅さ。エディタの操作や保存がもたつく状態で、シナリオの実行速度とは別問題です。

つまり、最初にやるのは切り分けです。どこで待たされているかを見ずに設定を触ると、効果がゼロの作業に時間を使うことになります。

「遅い」を切り分ける: 待ち時間はどこで生まれている？

実行履歴を開けば、待ち時間の正体は1分で判別できます。Makeの画面左メニューにあるHistory（実行履歴）に、1回ごとの開始時刻と所要時間が記録されています。

見るべき数字は2つだけ。トリガーとなる出来事が起きた時刻と、シナリオの開始時刻です。

この差が大きければ起動の問題。差はほぼゼロなのに完了まで長いなら、処理の問題です。

• 差が5〜15分 → プランの実行間隔が原因。Webhook化かプラン見直し
• 差がほぼ0で所要30秒超 → モジュール構成か外部APIが原因
• 実行自体が記録されていない → シナリオが無効、またはオペレーション枯渇
• エラーで途中終了 → リトライ設定が待ち時間を伸ばしている

所要時間の内訳は、実行履歴の各モジュールをクリックすると出ます。1つだけ突出して長いモジュールがあれば、そこが犯人。だいたいはHTTPリクエストか、大量データを扱うGoogle Sheets系です。

ここまで見れば、次にどのセクションを読むべきかが決まります。

プランの最小実行間隔が、体感速度の天井を決めます

Makeのスケジュール実行には、プランごとに「これより短くはできない」下限があります。無料プランの15分は、どんなに設定を詰めても縮みません。

公開されているプラン構成では、無料プランが15分、有料の下位プランで5分、上位プランで1分まで短縮できる形になっています（2026年4月時点）。プラン名や価格は改定が入るため、契約前に公式の料金ページで現行の内容を確認してください。

数字が示すのは単純な話です。無料プランで「1分以内に反応させたい」は、スケジュール実行では物理的に不可能。

ただし、この表には抜け道があります。実行間隔の制限がかかるのはスケジュール実行だけで、Webhookによる即時起動には適用されません。無料プランのままでも、トリガーの種類を変えれば待ち時間はほぼ消えます。

この抜け道が、7つの設定のうち最も効く1手です。

スケジュール設定の見直しで、反応はどれだけ変わる？

Webhookに変えられないケースもあります。定期的に一覧を見にいくタイプの処理は、スケジュール実行のままで組むしかありません。その場合でも、設定次第で無駄な待ちは削れます。

まず見直すのは実行のタイミング指定です。Makeのスケジュール設定には、間隔指定のほかに曜日・時刻指定があります。

夜間や休日にも15分おきに回っているシナリオは、オペレーションを食うだけで誰も見ていません。営業時間だけに絞ると、同じ月間オペレーション量でより短い間隔に振り分けられます。

• 24時間×15分間隔 = 1日96回
• 平日9〜19時のみ×5分間隔 = 1日120回

回数はほぼ同じなのに、業務時間中の反応は3倍速くなります。ここが「3倍」の正体のひとつ。魔法ではなく、資源の配り直しです。

もうひとつ、複数シナリオが同じ時刻に集中していないかも確認してください。毎時0分にすべてを寄せると、Make側の実行キューで順番待ちが起きます。5分ずつずらすだけで、体感の遅さが減る例は多いです。

とはいえ、待ち時間をゼロにしたいなら答えはひとつです。

Webhook化が、いちばん効く一手です

Webhookとは、相手のサービス側から「いま出来事が起きました」と即座に知らせてもらう仕組みです。Makeが定期的に見にいくのではなく、向こうから叩いてもらう形に変わります。

待ち時間の観点では、この差が決定的。定期確認は最大で間隔ぶんだけ待たされますが、Webhookは平均待ち時間が実質ゼロです。

つまりWebhookは、速度とコストの両方で有利です。空振りの実行が消えるぶん、月間オペレーションの節約にもなります。

対応しているサービスなら、モジュール名に「Watch 〜（instant）」と書かれています。これを選ぶだけで設定完了。相手側にWebhook設定画面がある場合は、Makeが発行したURLを貼り付ければ動きます。

問題は、Webhookに対応していないサービスです。その場合はHTTPモジュールで相手のAPIを直接叩き、変化があったときだけ後続を動かす形にします。少し手間ですが、モジュール数を抑えれば処理時間も短く保てます。

社内の申請フローや監査系の自動化を組むなら、どこまでを即時通知にするかの線引きが効いてきます。判断の材料としては、内部監査で使えるAIツールの整理記事が参考になります。通知の頻度と証跡の粒度をどう分けるかの考え方が、そのまま設計に使えるはずです。

モジュールを減らし、Iteratorの中で重い処理を回さない

シナリオが走り始めてからの時間は、モジュールの数にほぼ比例します。1モジュールあたり数百ミリ秒から数秒。20個つなげば、それだけで数十秒です。

減らし方は3つあります。

1つめ、Set variableの整理。 値を整形するためだけのモジュールが並んでいませんか。Makeの関数は1つの項目内で入れ子にできるので、3つのSet variableは多くの場合1つにまとまります。

2つめ、Router分岐の見直し。 条件が2つなら、Routerを使わずフィルターだけで済むことがあります。分岐は経路ごとに実行されるので、無駄な枝は丸ごと時間になります。

3つめ、Iteratorの中身を軽くする。 ここが最大の落とし穴です。

Iteratorは配列を1件ずつ回すモジュールですが、その中に置いたモジュールは件数ぶん実行されます。100件の配列にHTTPリクエストを1つ入れれば、100回の通信が直列で走る計算。1回0.5秒でも50秒です。

• Iterator内のHTTPリクエストは、可能なら一括APIに置き換える
• 件数が多い配列は、Iteratorの前にフィルターで絞る
• 集計だけならAggregatorで先にまとめてから1回で送る
• ループ内のログ出力用モジュールは本番では外す

Aggregatorは逆方向の道具で、バラバラの結果を1つの配列に戻します。「1件ずつ100回スプレッドシートに書く」を「100件を1回で書く」に変えられれば、処理時間もオペレーション消費も一桁変わります。

配列を扱う場面では、まず「まとめて送れないか」を疑う。この癖がつくとシナリオは劇的に軽くなります。

データ量が多いシナリオを軽くする

モジュール数を削っても遅いなら、1回あたりに運んでいるデータ量を疑います。Makeにはプランごとに月間の転送データ容量の上限もあり、無料プランは100MB規模、上位プランで数十GB規模という構成です（2026年4月時点）。

重くなりやすいのは、次の4パターンです。

つまり、運ぶ量を減らすのが本筋です。表示に使わないフィールドを最初のモジュールで捨てるだけでも、後続の処理が軽くなります。

画像生成をシナリオに組み込んでいる場合は要注意。生成そのものに数十秒かかるため、待ち時間の大半がMakeではなく生成側にあります。ツールごとの速度差が体感を左右するので、イラスト系AIツールの比較で応答の速いサービスを把握しておくと選択が楽になります。ローカル生成まで視野に入れるなら、ComfyUIとStable Diffusionの違いを先に読むと、なぜクラウド生成に待ちが出るのかが腹落ちします。

Search RowsのLimit設定は、初期値のままにしている人が多い箇所。ここを10や20に絞るだけで、実行時間が半分になるケースは珍しくありません。

ここまでの整理: 起動の遅さはWebhook化で潰す。処理の遅さはモジュール削減とIterator内の見直しで潰す。データ量は「必要な分だけ運ぶ」で潰す。ここまでで、多くのシナリオは体感3倍まで届きます。残りは画面の重さとツール選定の話です。

エディタが重い・保存が遅いときはどうする？

シナリオは速く動くのに、編集画面だけがもたつく。この症状は実行速度とは別の原因で起きています。

いちばん多いのは、シナリオ1本が巨大化しているケースです。モジュールが50個を超えたあたりから、キャンバスの描画とオートセーブが目に見えて重くなります。

• モジュール30個を目安にシナリオを分割する
• 分割したシナリオはWebhookか「Run scenario」でつなぐ
• 使っていないモジュールは無効化ではなく削除する
• 実行履歴が数千件たまったシナリオは複製して作り直す

ブラウザ側の要因も無視できません。広告ブロッカーやパスワード管理の拡張機能が、Makeのキャンバスと干渉して描画を止める報告があります。シークレットウィンドウで開いて軽くなるなら、拡張機能が原因です。

もうひとつ、複数タブでMakeを開いたままにするのも重さの元。編集中のシナリオは1タブに絞るのが無難です。

画面が重いだけなら業務は回りますが、編集効率は確実に落ちます。ここは早めに分割して逃げるのが正解。

オペレーション消費と速度はトレードオフになる？

速くしようとして実行間隔を短くすると、オペレーションを食う。この関係は事実ですが、正しく組めば両立します。

鍵はやはりWebhookです。スケジュール実行は「変化がなくても」1回消費しますが、Webhookは出来事が起きたときしか動きません。

1日に5件しか申請が来ないフォームを、1分間隔で監視すると1日1,440回。Webhookなら5回です。速度は上がって、消費は288分の1になります。

つまり、間隔を詰めて速くするのは最後の手段です。トリガー方式を変えるほうが、速度もコストも同時に改善します。

節約の副産物として、無料プランのままで運用を続けられる規模も広がります。プラン変更を検討する前に、監視型のシナリオが何本残っているか数えてみてください。

Makeより他ツールが速い場面もあります

設定を詰めても要件に届かないなら、ツール側の限界です。素直に別の選択肢を見たほうが早い場面があります。

判断の分かれ目は3つ。秒単位の即時性が必要か、処理件数が月10万を超えるか、社内システムと直結する必要があるか。

つまり、Makeは「分岐が多くて、外部サービスがバラバラ」な業務に強いツール。処理件数が跳ね上がる段階では、自前で回せるn8nのほうが速度もコストも制御しやすくなります。

AI処理を含むフローなら、生成部分をDifyのような専用基盤に逃がし、Makeは前後のつなぎ役に徹させる分業が現実的です。Makeの中で全部やろうとすると、待ち時間が1本の線に積み上がります。

ほかの選択肢を眺めるなら、業務自動化ツールのカテゴリ一覧とノーコード系のツール一覧が起点になります。

3倍速までの30分チェックリスト

上から順に手を動かせば、たいていのシナリオは30分で見違えます。効果の大きい順に並べています。

7つ全部をやる必要はありません。1と2だけで、体感の大半は解決します。

作業の前に、必ずシナリオを複製してバックアップを取ってください。Makeには詳細な変更履歴が残らないため、戻す手段を先に用意しておくのが安全です。

調べながら進めるなら、検索と要約を1画面で回せるツールがあると手が止まりません。Feloの使い方ガイドは、公式ドキュメントを横断して読むときの時短に効きます。

AI PICKS編集部の判定

Makeの「遅い」は、9割が設定の問題です。ツールの性能不足で遅いケースは、月間10万オペレーションを超える規模になってようやく出てきます。

なかでもWebhook化は圧倒的。無料プランのまま15分待たされていた処理が、そのまま数秒に変わります。ここを試さずにプランを上げるのは、正直もったいない判断です。

一方で、Makeの無料プランを本番運用に使うのは微妙。同時稼働2本という制限が早い段階で効いてきますし、オペレーション枯渇で実行が静かに止まると、原因調査に時間を取られます。業務で使うなら有料プランへの移行が現実的です。

逆に、秒単位の応答保証が要件に入っているなら、Makeは向きません。クラウド共有型である以上、実行キューの混雑は避けられないためです。そこは自前で回せるn8n一択。

用途を見極めて使えば、Makeは重宝します。遅さの正体を知っているかどうか、それだけの差です。

よくある質問（FAQ）

Q. 無料プランのまま実行間隔を1分にできますか？

スケジュール実行では不可能です。無料プランの下限は15分に固定されています。ただしWebhookによる即時起動には実行間隔の制限がかからないため、対応サービスなら無料のままほぼリアルタイムで動かせます。

Q. シナリオが途中で止まるのは遅さと関係ありますか？

別問題ですが、体感には影響します。エラーで停止したシナリオは、次回の実行まで動きません。エラー処理にBreakやIgnoreを設定しておくと、1件の失敗で全体が止まる事故を防げます。リトライ設定を多段にしていると、そのぶん実行時間も伸びます。

Q. モジュールを並列で動かして速くできますか？

Routerを使えば分岐先を並行に見せられますが、Makeの実行は基本的に直列です。速度目的で分岐を増やすと逆効果になります。速くしたいなら、モジュールを減らすか、重い処理を別シナリオに切り出してWebhookで投げっぱなしにする形が有効です。

Q. 実行履歴が見づらいときはどうすればいいですか？

履歴の保存件数が増えるほど画面は重くなります。シナリオ設定でデータ保存期間を短くするか、検証が終わった大量ログを抱えたシナリオは複製して新しいほうを使う運用に切り替えてください。開発中はログを詳細に、本番では絞るのが定石です。

Q. Google Sheets連携が特に遅いのはなぜですか？

行数が多いシートに対して全件検索をかけていることが大半です。Search RowsのLimitとフィルター条件を設定し、必要な範囲だけを読むようにしてください。書き込みも1件ずつではなくAggregatorでまとめると、処理時間とオペレーション消費が同時に下がります。

Q. AIの生成処理を組み込むと必ず遅くなりますか？

生成そのものに時間がかかるため、待ち時間は増えます。対策は、生成を別シナリオに分けて非同期にすること。依頼だけ投げて、完了通知をWebhookで受け取る形にすれば、本体のシナリオは即座に終わります。AIサービス側の応答速度も差が大きいので、Meta AIの機能ガイドのような個別解説で処理の重さを事前に把握しておくと選定を外しません。

Q. どのタイミングで有料プランに上げるべきですか？

同時に動かしたいシナリオが3本を超えたときが最初の分岐点です。オペレーション消費が月1,000に近づいてきたら、そこも判断材料になります。速度だけが理由なら、先にWebhook化を試してから決めるほうが賢明です。

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

• Make — 分岐の多い業務フローを組むなら中心になる1本
• n8n — 実行制限を自分で決めたいときの移行先
• Zapier AI — 2ステップの単純連携を最短で組みたい場合
• Power Automate — Microsoft 365中心の社内業務との相性
• 業務自動化ツール一覧 — 用途別に候補を並べて比べる
• ノーコードツール一覧 — 開発なしで組める選択肢を探す
• 業務自動化ツールのランキング — 導入実績の多い順から見る
• 生産性向上ツールのランキング — 自動化の前後を支える道具

次に読むなら、内部監査で使えるAIツールの整理記事がおすすめです。自動化した処理の記録をどう残すかは、シナリオを本番に載せる前に決めておくべき論点だからです。

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

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

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