Webhookの受け口を先に作る：他サービスからの通知を自動化する5手順

フォームの回答や決済の完了を、別のアプリへ自動で渡したい。こうした場面で最初に手を付けるのは、送る側の設定ではなく受け取る側の器です。Webhookは、出来事が起きたときにアプリが決まったURLへデータを送る仕組みで、送信先と項目名が決まっていないと、送る側の画面は埋められません。Zapierの解説では、受け口を作ってテスト送信を受け、中身を見てから次の処理につなぐ順番が示されています。

手順1：受け取る側の器を先に作る

Zapierでは、トリガーに Webhooks by Zapier を選び、イベントで Catch Hook を指定します。GET・POST・PUTのいずれの要求も受け取れる作りです。保存すると固有のURLが発行されるので、これを控えます。この機能は Pro 以上のプランに含まれる、と記事に書かれています。先にURLがある状態にしておくと、次の手順で迷いません。

手順2：送る側の画面にURLを貼る

送信元のアプリを開き、外部へ通知を送る設定を探します。項目の名前はアプリごとに違い、「Webhook URL」「通知先URL」「コールバックURL」などと書かれています。見つからない場合は、設定内の該当項目を検索したほうが早いです。貼り付けたら保存し、送信側が有効になっているかも確認します。

手順3：テスト送信を1回受ける

送信側にテスト機能があればそれを使い、なければ実際に1件作ります。フォームなら自分で回答を1件送る形です。受け側のテストを実行すると、届いたデータが項目名つきで並びます。ここで中身が見えない場合は、URLの貼り間違いか、送信側がまだ有効でないかのどちらかです。切り分けは、送信側の送信履歴に残っているかで判断できます。

手順4：項目名を控えて次の処理に割り当てる

届いたデータのキー名は、アプリごとにばらばらです。同じメールアドレスでも email、mail、mailaddress と分かれます。キー名が変わると受け側が壊れるため、そのまま使います。次のアプリのフィールドには、候補から選んで差し込みます。手で打ち直すと、空白や大文字小文字の違いで一致しません。キー名の一覧は、ツール呼び出しの考え方と同じで、呼ぶ側と受ける側の取り決めが先に要ります。

手順5：届かなかったときの扱いを決める

Webhookは送りっぱなしになりやすい仕組みです。受け側がエラーを返しても、送信側が再送するとは限りません。記事では、受け取った側がHTTPのステータスコードで結果を知らせる形が説明されています。あわせて、URLは推測されにくいランダムな文字列で作られ、必要ならキーや署名で守る、という前提も書かれています。顧客情報が通るなら、URLを共有する相手を絞ってください。

FAQ

Q. WebhookとAPIは何が違いますか？

A. 取りに行くか、届くかの違いです。APIはこちらから呼び出してデータを取ります。Webhookは相手側で出来事が起きたときに、決まったURLへ向こうから届きます。同じアプリでも両方の入口が用意されていることがあり、用途で選びます。

Q. データの形式は選べますか？

A. 送る側の設定で、JSONやフォーム形式を選べる場合があります。受け側はキー名に依存するため、形式を変える前に、いま届いている中身を控えておくと戻せます。

出典

出典：Zapier「Webhookとは何か：Webアプリをつなぐ基本ガイド」（原題 What are webhooks?、Matthew Guay、2026年5月29日）

あわせて使いたいツール

本記事の手順を実際に回すときに、候補になるツールを挙げます。いずれも無料から試せる範囲があり、料金や機能は各サービスの公式情報で確認してください。

• Zapier：画面だけで受け口と次の動作を組める（手順はこの画面が前提）
• n8n：自前の環境で動かす構成と比べるときの候補になる

関連ガイド

同じ時期に公開した実務ガイドと、用語の定義ページです。手順の前提が分からない場合は、用語ページから確認してください。コピーして使える依頼文が欲しいときは、プロンプト集も参照してください。

• 定例作業を決まった時刻に回す：スケジュール実行の組み方5手順
• MCPサーバーを1つにまとめる：接続先の整理と権限の決め方5手順
• ツール呼び出し（Tool Calling）（用語辞典）
• AI用語辞典（五十音順の一覧）
• はじめての LLM 活用（学習ルート）
• ガイド一覧（実務手順をまとめて読む）
• AIツール一覧（道具から探す）
• 比較記事一覧（料金と機能で比べる）
• レビュー一覧（使った記録を読む）

編集部の見解

受け口を先に作るよさは、キー名を先に知れることに尽きます。送る側から作り始めると、届くデータの形が分からないまま対応表を想像で書き、あとで直すことになります。うちでも、フォームとチャットを同じ受け口に集めたとき、キー名が揃っていないせいで作り直しになりました。URLは1つのまま、届くデータの種類だけ増やすと、見返すときに楽です。逆に、顧客情報が通る受け口は増やさないほうが安全で、用途ごとに分けたくなったら、その時点で権限の分け方を考えます。