MakeのWebhookの使い方：設定・JSONの受信と動かないときの確認手順

Webhookとは？外部から届くデータが処理の入口になる

Webhookは、外部サービスがMakeの受信用URLへデータを送る仕組みです。定期的に新しい情報を取りに行くポーリングと比べ、送信元のイベントをきっかけに処理を開始できます。ただし、Make側で定期実行に設定すると、届いたデータはキューに蓄積され、設定したタイミングで処理されます。

最初に送信元の専用アプリを探します。必要なイベントに対応したINSTANTモジュールがあれば、その専用接続を候補にできます。この記事では、受信URLを自分で作るWebhooks > Custom webhookを扱います。送信元が任意のURLへデータを送れることが前提です。

参考：Make公式ヘルプ：Webhooks（実行方式・キュー・応答・ログ）

設定手順1：Custom webhookを作り、受信用URLを登録する

練習用の新しいシナリオで、先頭にWebhooks > Custom webhookを追加します。Webhookの選択欄の横にあるAddを押し、用途が分かる名前を付けてSaveします。作成されたURLをコピーし、送信元サービスのWebhook送信先へ登録してください。URLはMakeが生成したものをそのまま使い、他の記事のサンプルURLで置き換えないようにします。

API Key authenticationを設定した場合は、送信リクエストのx-make-apikeyヘッダーにキーを含めます。送信元がこのヘッダーを設定できるか先に確認しましょう。実際の受信URLとキーは、公開記事や共有画像に載せません。同じWebhookを複数のシナリオで共有することもできないため、練習用と本番用はそれぞれ用意します。

下図は設定の順序を示す概念図です。Makeの画面配置を再現したものではありません。送信元側の設定画面やイベント名はサービスごとに異なるので、URLを登録するだけで送信が始まるか、イベントの有効化も必要かを確認します。

• 1. 練習用シナリオの先頭にCustom webhookを追加する。
• 2. Add → 名前を入力 → 必要な認証を設定 → Saveで作成する。
• 3. 生成されたURLを送信元へ登録し、必要なら認証ヘッダーも設定する。

図で理解する受信URLを送信元へ登録する

参考：Make公式アプリ資料：Webhooks（作成・認証・項目認識・JSON）

設定手順2：JSONを一件送り、マッピングする項目を認識させる

作成時の受信待ち、またはDetect new valuesでの再検出中に、送信元のテスト機能から架空のデータを一件送ります。POSTでJSONを送る例なら、Content-Typeをapplication/jsonにし、本文を {"request_id":"demo-001","topic":"design","message":"テスト受付"} とします。この三つの名前と値は編集部の練習例で、Makeの必須項目ではありません。送信機能がない場合はPostmanなどのHTTPクライアントから同じ形式を送れます。

受信結果でrequest_id、topic、messageが見えることを確認します。後続モジュールでは、固定の文字として「message」と入力するのでなく、Webhookから受信したmessageの項目を選んで対応付けます。このマッピングにより、受付ごとの内容が通知文や保存先へ渡ります。下図は一件のデータが通知文へ入る対応関係です。

後から追加した項目が選べない場合は、Custom webhookのDetect new valuesを押し、その項目を含むサンプルを再送します。なお、サンプルから項目を認識させることと、受信値の検証は別です。入力形式を検証したい場合はAdvanced settingsのData structureを明示的に設定します。JSON pass-throughを有効にするとJSONは文字列として渡るため、個別項目を選ぶ練習では設定を確認してください。

図で理解する受信した項目を後続の通知へ渡す

参考：Make公式アプリ資料：Webhooks（作成・認証・項目認識・JSON）Make公式ヘルプ：Mapping（項目の対応付け・Run once）

設定手順3：Run onceで受信から通知・保存まで確かめる

後続に必要な通知・保存モジュールを加え、テスト用の宛先や台帳を指定します。Run onceを押して受信待ちになってから、送信元で新しいテストイベントを発生させます。Run onceを押すだけでは、外部からのデータは生まれません。前の設定時のサンプルとは識別子を変え、今回はdemo-002として送ると照合しやすくなります。

送信元に200 Acceptedが返っても、通知や保存まで成功したとは限りません。標準応答はキューへの受付を示します。Makeの受信データ、後続モジュールの入力・出力、実際の通知先や保存先を同じrequest_idで照合します。下図の三段階を通して確認してから、シナリオを保存して有効にし、スケジュールが意図どおりか確認します。

有効化後にも新しい一件を送り、手動テスト時と同じ結果になるか確認してください。即時実行でなく定期実行を選んだ場合は、その実行時刻とキューを見ます。Webhook responseモジュールで応答を変更する方法もありますが、この記事の練習例では標準応答を使い、後続処理の完了を別に点検します。

図で理解する送信元・Make・保存先を同じ識別子で照合する

参考：Make公式ヘルプ：Webhooks（実行方式・キュー・応答・ログ）Make公式ヘルプ：Mapping（項目の対応付け・Run once）

動かないとき：送信・受信・後続処理の順に切り分ける

まず、送信元の履歴で正しいURLへイベントが送られたか確認します。次にMakeの左メニューのWebhooksから対象を選び、Logsで受信時刻、リクエスト、応答、Parsed itemsを見ます。Queueに残っている場合は処理待ちの可能性があるため、シナリオの状態とスケジュールを確認します。受信データが見える場合は、実行結果でどの後続モジュールまで進んだかを調べます。

下図は編集部が整理した確認順です。症状に応じた確認先は表も参照してください。変更は一か所ずつ行い、新しい識別子のデータで再テストすると、古い実行結果との混同を減らせます。

図で理解する送信・受信・後続処理の順に確認する

参考：Make公式ヘルプ：Webhooks（実行方式・キュー・応答・ログ）Make公式アプリ資料：Webhooks（作成・認証・項目認識・JSON）

運用前のFAQ：順番・重複・データの扱いを決める

受信順で処理されますか？ 即時Webhookのシナリオは標準では並列に処理されます。同じ台帳を続けて更新するなど順番が必要な場合は、シナリオ設定のProcess data in orderを検討します。前の処理が終わるまで次が待つため、処理時間と待ち件数も確認します。

同じ受付が二件できる場合は？ 送信元の再試行も調べます。編集部の設計案は、request_idなどの一意な識別子を保存先へ残し、既に処理済みか確認してから新規登録する方法です。並列実行では確認と登録が競合し得るため、順序制御や保存先の一意制約も含めて設計します。Webhookを置くだけで重複がなくなるとは考えません。

本番データはいつ使いますか？ 架空データで項目と保存範囲を確認してから、必要な項目だけを送ります。公式資料では、Data is confidential設定にかかわらず受信データはキューに保存されると説明されています。パスワードや不要な個人情報を送らず、受信URL・キーとログの閲覧者を管理しましょう。

まずは通知一件で練習したい場合は関連記事の「Make入門」、運用費用を確認したい場合は「無料プランで始める前に」を参照してください。Webhookの接続を作ることと、後続サービスの権限・利用枠を確保することを一緒に点検します。

参考：Make公式ヘルプ：Webhooks（実行方式・キュー・応答・ログ）