MakeのWebhookを無料で試す。匿名データで分岐まで確認した手順

この記事の内容（9項目）

Makeを試すために、いきなりGoogleアカウントや顧客データを接続する必要はありません。

私も最初は、どこまで権限を渡すのか、1回動かすと何credits使うのかが気になりました。そこで、個人情報を含まない4項目だけをWebhookへ送り、Routerで請求書とそれ以外に分ける小さなシナリオを作りました。

2026年9月24日にMakeのFreeアカウントで試した、外部アプリを接続しないWebhookと分岐の手順です。Windowsから匿名データを送る方法も補っています。

先に結論

最初の確認なら、次の構成で十分でした。

匿名データ → Custom webhook → Router → 組み込みTools

手動実行1回の結果は、Success、1秒未満、2 credits、2 operations、データ転送量129.0 Bでした。シナリオは有効化せず、Inactiveのまま単発で動かしています。

この結果は、Make全体の速さや費用を示すものではありません。今回の入力1件と構成で確認した数値です。外部アプリ、複数件処理、エラー時の再実行が加われば、operationsとcreditsは変わります。

まず匿名サンプルを用意する

今回使ったのは、問い合わせを想定した次の4項目です。

{
  "request_id": "sample-001",
  "category": "invoice",
  "priority": "normal",
  "contains_personal_data": false
}

本物の氏名、メールアドレス、会社名、請求金額は入れていません。分岐を試すだけなら、必要なのはcategoryが請求書かどうかを判定できることです。

テスト用データを先に固定すると、シナリオの設定ミスと入力データの問題を分けて見やすくなります。

1. Inactiveのままシナリオを作る

Freeアカウントで新しいシナリオを作り、最初のモジュールにWebhooksのCustom webhookを置きました。

Make公式ヘルプでは、WebhookはHTTPS経由でデータを受け取り、通常はURLへのリクエストをきっかけにシナリオを動かす仕組みと説明されています。Webhook URLは認証情報と同じように扱い、記事、画面共有、リポジトリへ残しません。

新規シナリオはInactiveの状態から始められます。今回も定期実行を有効にせず、Run onceだけを使いました。

2. Webhookへ匿名データを1件送る

Custom webhookを待機状態にし、先ほどの匿名JSONを1件だけ送りました。

受信後、Makeはrequest_id、category、priority、contains_personal_dataの4項目をデータ構造として認識しました。

ここで見るのは、値が業務上正しいかではなく、後段の分岐で使う項目をMakeが認識しているかです。想定した項目が出なければ、Routerを作る前に入力データへ戻ります。

Windowsから送る場合は、PowerShellで次の例を使えます。先にMakeの試験用シナリオでRun onceを押し、Custom webhookが受信待ちになってから実行してください。

URLの入力を求められたら、自分が作成したCustom webhookのURLを貼り付けます。URLをコードや公開する画面へ書き込む必要はありません。

$webhookUrl = Read-Host '自分のCustom webhookのURLを入力'
$sampleJson = @{
    request_id = 'sample-001'
    category = 'invoice'
    priority = 'normal'
    contains_personal_data = $false
} | ConvertTo-Json -Compress

try {
    Invoke-RestMethod -Uri $webhookUrl -Method Post `
        -ContentType 'application/json' -Body $sampleJson `
        -ErrorAction Stop | Out-Null
} catch {
    throw '送信に失敗しました。再送する前にMakeの受信状態と履歴を確認してください。'
}

送るのは上の匿名データ一件だけです。応答は画面へ出さず、Make側で受信した値を確認する形にしています。

この送信例はローカルの試験用受信先で確認しました。2026年9月24日のMake実測で使った送信方法を再現したものではありません。

最初の送信は、Webhookが受け取るデータの構造を検出するためです。受信した値にrequest_id=sample-001とcontains_personal_data=falseがあるか確認してください。入力が揃ったら手順3へ進みます。

手順3でRouterとToolsを設定し、シナリオを保存した後は、改めてRun onceで受信待ちにします。この例を一度だけ送信し、手順4の履歴で入力と経路を確認してください。最初の構造検出とは別の、保存したシナリオの動作確認です。

送信の応答だけでは、後ろの処理まで終わったとは判断できません。履歴で入力が一件か、想定した経路を通ったかを見てから次へ進めます。反応が見えない場合も、同じコマンドを続けて実行せず、まずMake側の受信状態を確かめてください。

3. Routerで請求書とそれ以外に分ける

Webhookの後ろへRouterを置き、category=invoiceなら請求書経路、それ以外はFallback経路という二つを作りました。

各経路の後ろには、外部サービスではなくMakeの組み込みToolsを置きました。請求書経路では、受け取った値を変数へ設定するところまでにしています。

Routerと条件を置く目的は、自動送信することではありません。まず、想定した1件が想定した経路だけを通るか確認するためです。

4. 実行履歴で通った経路とcreditsを見る

category=invoiceのサンプルを1件送ると、請求書経路だけが動き、Fallback経路は実行されませんでした。

実行履歴では、実行日時、手動実行かどうか、Success・Warning・Error、所要時間、operations、credits、データ転送量を確認できます。

今回の履歴は、Success、1秒未満、2 operations、2 credits、129.0 Bでした。Make公式ヘルプでも、シナリオ履歴には状態、実行時間、operations、credits、転送量などが表示されると案内されています。

非AIの一般的なモジュールは、基本的に1 operationが1 creditです。ただし、AI機能や処理方法によってcreditの計算は異なります。今回の2 creditsを、別のシナリオへそのまま当てはめることはできません。

5. 動かす前に停止条件を決める

無料枠で試す場合も、次のどれかに当てはまったら、外部アプリを接続する前に止めます。

Webhookが想定していない項目を受け取った
同じサンプルを送って別の経路を通った
実行履歴でErrorや意図しない再実行が出た
1件当たりのoperationsを説明できない
Webhook URLや入力値を安全に管理できない

今回は単発実行後もInactiveのままにしました。履歴にはReplay操作も表示されましたが、同じ処理を二重に流さないため再実行していません。

外部アプリをつなぐのは、この確認の後

匿名Webhookで分岐を確認できても、Google Sheets、メール、CRMなどを接続すると、権限と失敗時の影響が増えます。

私なら次の段階で、読み取り専用またはテスト用データから始めます。本番メールの送信、顧客情報の更新、ファイル削除を含む処理は、正常時だけでなく、入力不足、重複、接続切れの動きまで確認してから有効にします。

GASのままにする処理とMakeへ分ける処理で迷う場合は、GASとMakeを分ける5つの判断軸も合わせて確認できます。

Makeを無料で試す

この記事のリンクはMake公式アフィリエイトです。紹介リンクにはCoreプラン1か月無料と10,000 creditsの特典設定が有効になっています。適用条件と無料期間終了後の料金は、登録画面で確認してください。

登録後は、外部アカウントをつなぐ前に、匿名データ1件、分岐2本、手動実行1回だけで試してみてください。そこで入力、経路、operations、creditsを説明できれば、次の接続を増やすか判断しやすくなります。

この記事の確認情報

最終確認日：2026年9月26日

確認に使ったもの

Make Freeで匿名WebhookをRouterへ通した手動実行
Success、1秒未満、2 credits、2 operations、129.0 Bの実行履歴

参照した公式情報

リンクは新しいタブで開きます。