Make.comは、SaaSやAPIの処理を「モジュール」として画面上に並べ、線でつないで自動化の流れ（シナリオ）を作るiPaaSです。2022年にIntegromatから名称を変えた製品で、条件分岐や繰り返しを図のまま描ける点が特徴です。この記事では、シナリオ・モジュール・バンドルという3つの基本単位を押さえたうえで、2025年8月に始まったクレジット課金の数え方と、月の消費量の見積もり方を解説します。後半は、Custom webhookとルーターで受付から通知までを組む手順と、Make APIでシナリオを外部から起動するcurlの例を示します。仕様と数値の根拠は、2026年11月6日時点の公式ヘルプとAPI仕様です。
まとめ：Make.comは図で組むiPaaSで、費用はバンドル数の掛け算で決まる
Make.comの費用を左右するのは、シナリオの実行回数よりも、各モジュールが処理するバンドル（データ1件）の数です。トリガーで10件拾えば、後続のモジュールはそれぞれ10回動き、その回数がクレジットとして引かれます。設計の段階で集約モジュールを入れるかどうかで、同じ業務でも消費量が数倍変わります。
構築は、Custom webhookで受けてルーターで振り分ける形が基本です。外部システムから任意のタイミングで動かしたい場合は、シナリオをOn demandにしてMake APIの/scenarios/{scenarioId}/runを呼びます。分岐を含むSaaS連携が月数万件までならMake.comで組み、大量バッチや厳密な整合性が要る処理は見送る、というのが本記事の結論です。
Make.comの定義とシナリオ・モジュール・バンドルの3つの基本単位
Make.comの画面で扱う要素は多く見えますが、動作の理解に必要なのは3つの単位だけです。
旧Integromatから続くMake.comの位置づけとiPaaSの中での役割
Make.comは、クラウド上で複数のサービスをつなぐiPaaS（Integration Platform as a Service）に分類されます。iPaaS全体の仕組みとRPAとの違いはiPaaSとは？仕組み・RPAとの違い・料金の数え方と導入判断で整理しています。
同じiPaaSのZapierが「トリガー1つ＋アクションの直列」を基本とするのに対し、Make.comはルーターでの分岐や配列の分解を標準の部品として持ちます。そのため、非エンジニアが1本道の通知を作るより、業務の担当者と開発者が一緒に、分岐の多い連携を組む用途に向いています。
トリガー・検索・アクション・ユニバーサルの4種類のモジュールの役割
公式ヘルプのモジュールの種類では、モジュールをトリガー・検索・アクション・ユニバーサルの4種に分けています。トリガーはシナリオの先頭に1つだけ置け、サービス側の変化を取り込む役割です。
| 種類 | 役割 | 例 |
|---|---|---|
| トリガー（ポーリング） | スケジュールごとに新着を確認 | Watch New Rows |
| トリガー（インスタント） | サービスからの通知で即時起動 | Custom webhook |
| 検索 | 条件に合うデータを取得 | レコード検索 |
| アクション | 作成・更新・削除を実行 | Send an Email |
| ユニバーサル | 任意のAPIを直接呼ぶ | HTTPリクエスト |
ポーリング型は名前が「Watch」で始まるものが多く、インスタント型には稲妻のアイコンが付きます。連携先が専用モジュールを持たない場合でも、ユニバーサルモジュールでREST APIを直接呼べば接続できます。
モジュール間を流れるバンドルとマッピングでデータの値を渡す仕組み
オペレーションの解説によると、バンドルは関連するデータ項目をまとめた入れ物です。新規連絡先を表に追加する処理なら、1人分の氏名やメールアドレスが1バンドルになります。前のモジュールの出力バンドルが、次のモジュールの入力バンドルになり、この受け渡しがシナリオの最後まで続きます。
値の受け渡しは「マッピング」で行い、前段の出力項目を後段の入力欄に差し込みます。注意したいのは、JSONを解析するモジュールやCustom webhookでデータ構造を定義していないと、後段のマッピング欄に項目が表示されない点です。イテレーターのヘルプが示す対処は、一度シナリオを実行してモジュールに出力の形を覚えさせることです。
オペレーションとクレジットの数え方と月間消費量を見積もる計算式
Make.comの料金は、シナリオ数ではなく消費したクレジットで決まります。見積もりを外さないための数え方を順に確認します。
2025年8月にオペレーションからクレジットへ変わった課金単位の中身
Makeは2025年8月に、課金単位を「オペレーション」から「クレジット」へ切り替えました。切り替えの告知では、既存のオペレーションは1対1でクレジットに換算され、プランの価格も据え置きと説明されています。
現在のオペレーションは「モジュール1回の実行」を指す言葉で、クレジットは支払いの単位です。クレジットのヘルプによると、AIを使わないアプリでは1オペレーションが1クレジットです。一方、Make’s AI Providerを使うAIエージェントなどは、トークン量に応じて消費が変わります。OpenAIやAnthropicのモジュールを自社のAPIキーで接続した場合、Makeには1オペレーション1クレジットを払い、トークン代はAI提供元へ別に払う形です。
トリガー1回と後続モジュールのバンドル数で決まる消費の掛け算
消費量を見積もる式は単純です。トリガーは返すバンドルが何件でも1回の確認で1オペレーションと数え、後続の各モジュールは受け取ったバンドルの数だけ実行されます。
1回の実行の消費 = 1（トリガー）+ 後続モジュール数 × バンドル数
例：フォーム回答10件 × 後続3モジュール = 1 + 3 × 10 = 31
月の消費 = 1回の実行の消費 × 月の実行回数（新着0件の確認も1ずつ数える）この31という数字は、ヘルプにあるGoogle Formsの例と同じ計算です。見落としやすいのは最後の行で、15分ごとのポーリングなら新着が無くても1日96回、30日で2,880回の確認が発生します。新着が少ない業務ほど、空振りの確認がクレジットの大半を占めます。
アグリゲーターで束ねて消費を11から3へ減らすヘルプの削減例
バンドル数の掛け算を断ち切るのが、複数のバンドルを1つにまとめるアグリゲーターです。ヘルプの例では、新規連絡先10件ごとにメールを10通送っていたシナリオに、Text aggregatorを入れて1通の一覧メールにまとめ、1回の実行の消費を11から3へ減らしています。
アグリゲーターには、集約を始める位置を決めるSource Moduleと、値ごとにまとめ直すGroup byの設定があります。集約した後のモジュールからは、集約前のバンドルの項目を直接参照できません。後段で使う項目は、集約の設定で出力に含めておく必要があります。
無料の月1,000クレジットと追加購入の25%増しで考える月額の上振れ
料金ページに記載された無料プランは、月1,000クレジットです。有料プランで含み枠を超えた場合は、追加クレジットを買います。追加クレジットのヘルプでは、手動購入・自動購入とも、プラン内の単価より25%高くなると説明されています。
ヘルプの計算例では、10,000クレジットで9ドルのプランだと1クレジットは0.0009ドルで、1,000クレジットの追加は1.125ドルです。自動購入は10,000クレジット単位で行われ、プランのクレジット数までが上限です。2025年11月6日のプラン改定で、Coreは月30万クレジットまで、Proは月800万クレジットまでに整理されました。追加購入が毎月続くなら、上位の枠に変えたほうが単価は下がります。プラン別の月額をZapierと並べた試算はZapierとMakeの違いで扱っています。
Custom webhookでフォームの受付からSlack通知までを組む構築手順
ここからは、外部フォームの送信をCustom webhookで受け、問い合わせ種別ごとに通知先を分けるシナリオを例に手順を示します。
Webhooksアプリでカスタムwebhookを作りcurlで受信を確かめる手順
- 新しいシナリオを作り、先頭のモジュールにWebhooksアプリのCustom webhookを選ぶ
- Addでwebhookを作成し、名前を付けて発行されたURLをコピーする
- モジュールが受信待ちの状態のまま、curlでテスト用のJSONを送る
- 受け取った項目から、データ構造が自動で決まったことを確認する
curl -X POST '<Custom webhookで発行されたURL>' \
-H 'Content-Type: application/json' \
-d '{"category": "見積依頼", "company": "株式会社サンプル", "body": "kintone連携の費用を知りたい"}'応答にAcceptedが返れば受信は成功です。Webhooksのヘルプによると、Webhook responseモジュールを置かない場合の既定の応答は、受付時が200、キューが満杯のときが400、レート制限に当たったときが429です。受付の上限は10秒あたり300リクエストで、シナリオにつながっていないwebhookは5日（120時間）で無効になり、410を返すようになります。テストで作ったwebhookを放置して本番のURLと取り違える事故を防ぐため、名前に用途を入れておきます。
ルーターとフォールバックルートで問い合わせ種別を振り分ける設定
webhookの後ろにFlow controlsのルーターを置き、ルートごとにフィルターでcategoryの値を判定します。見積依頼は営業チャンネル、不具合報告は保守チャンネルへ、という分け方です。
押さえておきたいのは、ルーターの各ルートは並列ではなく順番に処理されることです。先のルートの処理が終わるまで、次のルートは動きません。どの条件にも当たらないデータは、フォールバックに指定したルートが最後に受け取ります。フォールバックを置かないと、想定外の種別が届いたときに何も通知されず、取りこぼしに気づけません。
添付ファイルの配列をイテレーターで分けて処理しアグリゲーターで戻す組み方
フォームに添付ファイルが複数付く場合、受け取ったデータは配列になります。イテレーターは配列の要素を1件ずつのバンドルに分けるモジュールで、ファイルを1つずつストレージへ保存する処理に使います。
分けた後に「保存したファイルの一覧をSlackへ1回だけ投稿する」なら、保存の後ろにアグリゲーターを置き、Source Moduleにイテレーターを指定します。イテレーターとアグリゲーターの間がグレーの範囲で囲まれ、どこからどこまでが繰り返しの処理範囲なのかを図で確認できる構成です。この組み合わせを入れないと、投稿がファイルの数だけ発生し、クレジットもその分だけ増えます。
Make APIでシナリオを外部から起動する設定とresponsiveの40秒制限
基幹システムのバッチや自社アプリのボタンからシナリオを動かしたい場合は、Make APIを使います。
APIトークンのscenarios:runスコープとゾーン別ベースURLの確認
Make APIの認証では、APIトークンをAuthorization: Token <トークン>の形でヘッダーに入れます。トークンには使える操作の範囲（スコープ）があり、シナリオの起動にはscenarios:runが要ります。
ベースURLを決める基準は、組織が置かれたゾーンです。ScenariosのAPI仕様にはeu1.make.com・eu2.make.com・us1.make.com・us2.make.comなどが並んでいます。管理画面のURLに表示されるゾーンとの一致が必要で、一致しなければ正しいトークンでも呼び出しは失敗です。トークンは起動専用に分け、シナリオの編集や削除の権限を持たせないでおくと、漏えい時の被害を起動だけに抑えられます。
On demandにしたシナリオをcurlで起動するリクエストと応答
スケジュール設定でOn demandを選ぶと、シナリオはAPIか「Run once」ボタンからしか動かなくなります。そのうえでシナリオを有効化し、次のように呼びます。
curl -X POST 'https://eu1.make.com/api/v2/scenarios/<scenarioId>/run' \
-H "Authorization: Token $MAKE_API_TOKEN" \
-H 'Content-Type: application/json' \
-d '{
"data": {"order_id": "A-1024"},
"responsive": true
}'dataには、シナリオの入力（Scenario inputs）として定義した項目を入れます。responsiveをtrueにすると完了まで待ち、応答にexecutionIdとstatus（1が成功、2が警告、3がエラー）が返ります。falseまたは省略時はすぐに戻り、返される情報はexecutionIdだけです。組織のクレジットや転送量が上限に達して停止している場合、呼び出しは429とコードIM310で拒否されます。
40秒を超える処理をcallbackUrlで受け取る非同期の設計
API仕様には、responsiveがtrueでも40秒を超えるとタイムアウトのエラーが返り、シナリオ自体は実行を続ける、と書かれています。呼び出し側がエラーを見て再送すると、同じ処理が二重に走ります。
重い処理はresponsiveをfalseにし、callbackUrlに自社のエンドポイントを指定します。完了時にMakeがexecutionIdと、結果を取得できるstatusUrlをPOSTしてくるので、そこで後続の処理に進めます。受け側で通知の再送による重複を防ぐ方法は、executionIdを使った重複の判定と排除です。なお、このエンドポイントには組織単位のAPIレート制限が適用されません。呼び出し元で送信間隔を管理してください。
本番運用で止めないためのエラーハンドラーとシナリオ設定の要点
作ったシナリオが本番で止まる原因の多くは、連携先のエラーとシナリオ設定の既定値です。
Retry・Resume・Skip・Commit・Rollbackの5種類の使い分け
Makeのエラーハンドラーは5種類あり、エラーを起こしうるモジュールに個別に付けます。
| ハンドラー | エラー時の動き | 向く場面 |
|---|---|---|
| Retry | 未完了実行に保存して再試行 | 連携先の一時障害 |
| Resume | 代わりの値で処理を続行 | 任意項目の取得失敗 |
| Skip | そのバンドルを飛ばして次へ | 1件の不正データ |
| Commit | 停止し処理済みの分を確定 | 途中までの結果を残す |
| Rollback | 停止し変更を取り消す | 全件そろって意味がある処理 |
実務の最初の一手は、シナリオ設定で未完了実行の保存を有効にすることです。接続エラー（ConnectionError）とレート制限（RateLimitError）は、これだけでMakeが自動で再試行します。Retryハンドラーも未完了実行の保存が前提で、付ける対象は、それ以外の一時的なエラーを決めた間隔で再試行させたいモジュールです。Skipは手軽ですが、飛ばした件数を通知する仕組みとセットにしないと、データが黙って欠けます。
未完了実行の保存と順序処理とインスタントトリガーの即時停止を確認する設定
シナリオ設定で確認したい項目は4つです。「Store incomplete executions」を有効にすると、失敗した実行が保存され、原因を直してから止まった位置の続きを処理できます。「Process data in order」は前の実行の完了を待ってから次を始める設定で、webhookは既定で並列処理されるため、受付順に台帳へ書き込む業務では必須です。
「Errors before deactivation」は連続エラー何回でシナリオを止めるかの設定ですが、インスタントトリガーで始まるシナリオではこの値が無視され、最初のエラーで停止します。webhook起点のシナリオこそエラーハンドラーを付けておく理由がここにあります。個人情報を扱う場合は「Keep data confidential」で実行ログにデータを残さない設定もできますが、障害時の調べ方が限られる点は理解したうえで選んでください。
ブループリントJSONでシナリオを書き出し版管理とレビューに回す
シナリオはブループリントとしてJSONファイルに書き出せます。モジュール・設定・マッピングの値が含まれ、接続（認証情報）は含まれません。取り込めるファイルは2MB未満です。
受託開発でMakeを納品する場合、ブループリントをGitで管理しておくと、変更の差分をレビューでき、担当者が替わっても構成を追えます。接続は取り込み先で作り直す必要があるため、どのアカウントで接続するかを手順書に残しておくと引き継ぎが滞りません。
受託開発の現場でMake.comを採用する条件と見送るべき業務の境界
Make.comは万能ではありません。採用の可否は、件数と処理の性質で判断します。
月数万件までの分岐を含むSaaS連携をMake.comに任せる条件
Make.comを採用するのは、SaaS同士の連携で、ルーターやイテレーターが要る分岐があり、月の消費が数万クレジットに収まる業務です。問い合わせの振り分け、受注データの転記と通知、kintoneとスプレッドシートの同期などが当てはまります。kintoneを中心にした連携方式の比較はkintoneのデータ連携を実装視点で選ぶで解説しています。
分岐の無い1本道の通知を現場の担当者だけで作るならZapierのほうが早く、セルフホストで社内ネットワークに閉じたいならn8nが候補です。iPaaSの選定からシナリオの設計・保守まで任せたい場合は、iPaaS導入支援（Zapier／Make／Workato／Yoom）で、Makeを含めた構成をご提案しています。
大量バッチや厳密なトランザクションでMake.comを見送る場面
見送るのは次の2つです。1つは、毎日数千件以上の明細を1件ずつ処理するバッチです。バンドル数の掛け算でクレジットが膨らみ、追加購入の25%増しが毎月発生します。もう1つは、在庫の引当てや会計仕訳のように、途中で失敗したら全体を確実に戻す必要がある処理です。Rollbackハンドラーはありますが、取り消せるのはMySQLやData Storeのようにトランザクションに対応した（ACIDの表示がある）モジュールだけです。Gmailで送ったメールのように、外部サービス側で完了した操作は戻せません。
この2つに当たる業務は、APIを直接呼ぶプログラムを開発するほうが、運用費と障害時の復旧の両面で有利です。RPA・iPaaS・開発のどれで自動化するかの切り分けは、業務自動化の進め方で整理しています。
よくある質問：Make.comの無料枠・Zapierとの比較・コードの扱い
Make.comについて検索されることの多い質問に答えます。
Make.comは無料でどこまで使えますか？
無料プランは月1,000クレジットで、AIを使わないモジュールなら1,000回の実行に相当します。15分ごとのポーリングを1本動かすだけで月2,880回の確認が発生するため、常時動かす用途では足りません。無料プランは、webhook起点で件数の少ないシナリオの検証や、課金前の動作確認に使うのが現実的です。追加クレジットの購入は有料プランが対象です。
Make.comとZapierはどちらを選べばよいですか？
分岐や繰り返しを含むフローを、月数千件以上の規模で動かすならMake.comが有利です。分岐の無い通知を現場の担当者が作り、連携先のアプリがZapierにしか無い場合はZapierを選びます。課金単位の違いと月額の逆転条件はZapierとMakeの違いで、Zapier自体の仕組みはZapierとはで詳しく扱っています。
Make.comとn8nの違いは何ですか？
最大の違いは提供形態です。Make.comはクラウドで提供されるサービスで、自社サーバーに置くことはできません。n8nはクラウド版に加えて自社環境で動かすセルフホストを選べるため、データを社外に出せない業務で候補になります。ただし、n8nのライセンスには利用目的の制限があり、受託で使う場合は条件の確認が要ります。詳細はn8nとはを参照してください。
クレジットを使い切るとシナリオはどうなりますか？
組織のクレジットや転送量が上限に達すると、組織のシナリオのスケジュール実行が止まります。APIからの起動も拒否の対象で、その際に返るのは429とコードIM310です。止めたくない場合は、追加クレジットの自動購入を有効にしておくと、10,000クレジット単位で補充されます。自動購入はプラン内の単価より25%高いため、毎月続くようなら上位の枠への変更を検討してください。
Make.comのシナリオにプログラムのコードは書けますか？
基本はノーコードで組めますが、式の中で関数を使った文字列や日付の加工は可能です。より複雑な処理が要る場合、有料プランではJavaScriptやPythonを実行できるMake Codeアプリが使えます。それでも足りない処理の切り出し先は自社で作ったAPIで、HTTPモジュールから呼ぶ形です。処理の中心がコードになるなら、Makeで組む利点は小さくなります。
関連記事
- iPaaSとは？仕組み・RPAとの違い・料金の数え方と導入判断をわかりやすく解説：Make.comを含むiPaaS全体の仕組みと導入判断を確認できます
- ZapierとMakeの違い｜課金単位と対応アプリ数で決める選び分けの基準：Zapierとの月額試算と選び分けの条件を扱っています
- iPaaSの比較9製品｜料金と課金単位・接続数で選ぶ判断軸と規模別の結論：Make.com以外の製品も含めて規模別に比べられます
- Zapierとは？読み方・できること・料金とタスク課金の仕組み【2026年版】：タスク課金の数え方をMakeのクレジットと見比べられます
- n8nとは？読み方・料金・商用利用の範囲と3.0で変わる始め方【2026年10月】：セルフホストできる自動化ツールを検討する場合に読めます
