MakeのWebhook機能の使い方｜外部サービスからのデータ受信をトリガーにした自動化レシピ

MakeのWebhookを使うと、自動化の起点が一気に広がる。ポーリング型のトリガーとは違い、外部サービスからHTTPリクエストが届いた瞬間にシナリオが動く。フォーム送信、決済完了、GitHubへのPush——そういったイベントをリアルタイムで拾って、複数のツールへ一括で処理を投げられる。

Makeの基礎を一通り触ったことがある人なら、「既存のアプリ統合だけでは届かないサービスと繋ぎたい」と感じた経験があるはずだ。公式サイトによると、MakeはStripe・GitHub・Typeform・Shopifyなど2,000以上のアプリと統合しているが、それでもカバーされていないサービスは当然ある。社内システムや、ニッチなSaaSツール、自前のWebアプリなどがその典型だ。Webhookはその隙間を埋めるために使う。

カスタムWebhookの設定は、正直そこまで難しくない

MakeのカスタムWebhookは、HTTP POSTリクエストを受け取り、JSON・FormDataなど複数フォーマットを自動でパースしてシナリオのトリガーにできる（公式ドキュメントより）。「JSONって読めない」という人も、最初のテストリクエストを一度送信するだけでOK。ペイロードのフィールド構造をMakeが自動解析して、後続モジュールで使えるマッピングを自動生成してくれる。

たとえばTypeformで「name」「email」「message」の3フィールドを持つフォームを作った場合、Webhookにテストリクエストを1回投げるだけで、それぞれのフィールドがMake上に自動で展開される。あとはNotionのデータベースに追加するなり、Slackに通知を飛ばすなり、後続モジュールを繋げていくだけだ。ネストが深いJSONでも同様に処理できる点は、実務で使い込むほど助かる。

もう一つ、見落とされがちだが実用的な機能が「カスタムWebhookレスポンス」だ。受信したリクエストに対して、任意のHTTPステータスコード（200・400・500など）とボディを即座に返せる。フォームサービス側がWebhookの応答を確認するケース——たとえばJotFormやHubSpotがWebhook先の死活を確認する仕様になっている場合——や、開発中に簡易的なAPIモックとして動かしたい場面で地味に重宝する。

セキュリティ面では、特定のIPアドレスからのリクエストのみを受け付けるIPフィルタリングを設定できる。Stripeなど送信元IPが公開されているサービスと繋ぐなら、最初に設定しておくべきだ。不特定多数からの誤送信やスパムを弾けるし、万一URLが漏れた場合のリスクも減らせる。

コスト面でZapierと差が出るポイント

MakeはOperationsベースの課金モデルを採用している。Zapierがタスク（ステップごと）に課金するのに対し、MakeはシナリオのOperations単位で消費する仕組みだ。この違いが、多ステップのシナリオほど大きなコスト差を生む。

具体的な数字で確認しておこう（2025年時点の公式情報）。

• Freeプラン：Operations 1,000回/月、カスタムWebhook利用可、シナリオ数2件
• Coreプラン：月額約$10.59（年払い）、Operations 10,000回/月
• Proプラン：月額約$18.82（年払い）、Operations 40,000回/月

Webhookを起点に5〜6ステップのフローを組む場合、1回の起動で消費するOperations数はZapierのタスク数と比べて少なくなるケースが多い。月に数百〜数千件のWebhookを受信するような用途なら、この差は無視できない。

ただし、Freeプランの1,000回/月は思いのほか早く消える。開発中にテスト送信を繰り返しているだけで、あっという間に半分を使い切ることもある。本番運用に移行するなら、CoreかProプランへのアップグレードを最初から見込んでおいたほうがいい。

こんな人には向かない（重要）

Webhook機能は強力だが、万能ではない。

まず、高頻度で大量のWebhookを受信する構成を組む場合。ECサイトのリアルタイム在庫更新や、ユーザー行動ログを逐一受け取るような用途では、Operations消費が爆発的に増える。Coreプランの10,000回でも数日で上限に達することがあり、上位プランへの移行コストを含めてROIを試算しておく必要がある。

次に、日本語の情報が少ない点。Make公式ドキュメントは英語が中心で、日本語コミュニティはZapierと比較するとまだ薄い。エラーコードを調べるときや、特定のサービスとの接続でハマったときに、日本語で解決策がすぐ見つかるとは限らない。英語のフォーラムを読む抵抗感がある人には、この点がストレスになる。

それから、単純な1対1の連携で十分な場合。たとえば「Googleフォームに回答が来たらGoogleスプレッドシートに記録するだけ」なら、MakeのWebhookを使うまでもなく、既存のGoogle統合で事足りる。Webhookが本領を発揮するのは、条件分岐・複数経路への振り分け・カスタムサービスとの連携など、既存統合だけでは手が届かない場面だ。

MakeのWebhookを特に活かせるのは、「既存の統合では繋がらないサービスとリアルタイムで連携したい」「受信データを条件分岐・フィルタリングして複数の処理経路に投げたい」と考えている人だ。

迷っているなら、まずFreeプランでカスタムWebhookを一つ動かしてみるのが一番早い。実際に自分のシナリオにWebhookを繋いで動作確認できれば、有料プランが必要かどうかも自然と判断がつく。手を動かすのが最短の学習だ。

MakeのWebhookを使って自動化の幅を今すぐ広げる