---
title: "ウェブフック:起きたことを他のツールに知らせる | Briks"
url: https://briks.dev/ja/docs/webhooks
description: "サイトの公開時、フォームの送信時、レコードの変更時に、署名付きのメッセージを別のツールへ送ります。ペイロード、署名、再試行、配信について説明します。"
last_updated: 2026-10-08
---

# ウェブフック:起きたことを他のツールに知らせる

Webhookは、公開、フォームの送信、レコードの変更など、プロジェクトで何かが起きた瞬間に、他のツールへ短いメッセージを送ります。このページでは、追加の方法、メッセージの内容、受信側が正規のものか確認する方法、受信側が停止しているときの動作を説明します。

読了時間 7 分 2026年10月8日にスタジオで確認済み

## Webhookとは

プロジェクトが別のサービスに電話をかけて、起きたことを知らせるようなものだとお考えください。相手のツールから渡されたアドレス(URL)をBriksに登録し、通知したいイベントを選ぶと、そのイベントが起きるたびにBriksがそこへメッセージを送ります。多くの自動化ツール、顧客リストのツール、スプレッドシートのアドオンで、このようなアドレスを発行できます。

技術的には、各メッセージは POST リクエストです。これは本文を伴う呼び出しで、ここではプログラムが読み取れるテキスト形式の JSON で書かれます。受け取ったツールが本文を読み、設定した内容を実行します。

| スタジオでの表示どおりのイベント | コード | 送信されるタイミング |
| --- | --- | --- |
| **Published** | `site.published` | サイトの新しいバージョンが公開されました。 |
| **Form received** | `form.received` | 訪問者がサイトのフォームからメッセージを送信しました。 |
| **Record changed** | `record.changed` | プロジェクトのデータベースのレコードが追加、変更、または削除されました。 |

`record.changed` は、スタジオで行った変更に反応します。Databaseタブでレコードを追加、編集、削除したとき、コレクションを空にしたとき、データベースを復元したときです。訪問者が送る予約リクエストのように、公開サイトが自動で保存するレコードでは作動しません。

`form.received`は、本番環境からの送信だけでなく、プレビューからの送信でも送られます。どちらからかは各メッセージに記されているので、連携先のツールでプレビューの送信を除外できます。

どこで

1. Projects
2. Your project
3. Settings
4. Webhooks

## 各プランの上限

| プラン | プロジェクトごとのWebhook数 | 1プロジェクトあたりの1日の呼び出し回数 |
| --- | --- | --- |
| Free | 1 | 2,000 |
| Starter | 5 | 5,000 |
| Pro | 10 | 10,000 |
| Studio | 25 | 50,000 |
| Agency | 50 | 100,000 |

1日あたりの呼び出し回数は定期タスクと共有です。再試行を含め、配信の試行は1回ごとに1と数え、1日は UTC の午前0時に始まります。

その日の呼び出し回数を使い切ると、配信は送信されず **Failed** と表示されます。表示文言は「Today's calls for this project are used up, so this delivery was not sent. Send it again tomorrow.」です。

プロジェクトにプランが許す数のwebhookがあると、**Add webhook** はグレーになり、数の横の **Get more** リンクからアップグレードのウィンドウが開きます。そこには、もう一つ追加できる最小のプランが示されます。

## Webhookを追加する

1. Add webhookを押す

   場所: Settings, Webhooks

   このページには、プランの上限に対する現在の数が、たとえば「1 of 5 on your plan」のように表示されます。Editor、Admin、Ownerがwebhookを追加できます。

2. アドレスを入力

   場所: Add a webhook

   もう一方のツールから受け取ったアドレスを **Address** に貼り付けてください。数字ではなく名前で書かれた、公開のhttpsアドレスである必要があります。

3. メモを追加

   場所: Add a webhook

   **Note** は任意で、120文字までです。あとからWebhookを見分けるのに役立ちます。たとえば `Enquiries sheet` のように入力します。

4. イベントを選ぶ

   場所: Add a webhook

   通知を受け取りたいイベントにチェックを入れます。**Published** と **Form received** は最初からチェックされています。必要に応じて変更してください。

5. シークレットを保存してコピーする

   場所: Your signing secret

   **Add webhook** を押します。ダイアログに、`whsec_` で始まる署名シークレットが表示されます。**Copy** を押して保管してください。表示されるのは一度だけです。そのあと **Done** を押します。

6. テスト送信

   場所: Settings, Webhooks

   Webhookの3点メニューを開き、**Send a test event** を選びます。次のように表示されます: A test event is on its way. See how it went under Deliveries.

リストの各ウェブフックには、アドレス、メモ、イベント、署名に使うシークレット(最初の数文字)、直近の配信の結果が表示されます。スイッチで **On** と **Off** を切り替えられ、三点メニューには **Send a test event** (1時間に最大10回まで、オンのときのみ)、**Change**、**New signing secret**、**Delete** があります。

## 納品のイメージ

どの配信も同じ3つの部分でできています。`type`(イベントのコード)、`timestamp`(起きた時刻、UTC)、`data`(詳細)です。フォーム送信の例を示します。

form.received の配信

> `{"type":"form.received","timestamp":"2026-10-08T09:41:07.000Z","data":{"form":{"id":"…","subject":"結婚式のお問い合わせ","page":"/contact","fields":[{"label":"お名前","value":"Ellie Marsh"},{"label":"挙式日","value":"2027年6月14日"}],"replyTo":"ellie@example.com"},"production":true}}`

| イベント | `data`に入るもの |
| --- | --- |
| `form.received` | `form`:その `id`、`subject`、送信元の `page`、`fields`(それぞれ `label` と `value` で、フォームの順番どおり)、そしてフォームがメールアドレスを求める場合は訪問者のメールである `replyTo`。続いて `production`:公開中のサイトなら `true`、プレビューなら `false` です。 |
| `site.published` | `url`: 公開されたアドレス。`production`: サイトが本番環境にあるかどうか。`abTest`: A/B テストが実行中かどうか。`served`: メッセージを送った時点で、そのアドレスで新しいバージョンが応答しているのを Briks が確認したかどうか。 |
| `record.changed` | `action`:`created`、`updated`、`deleted`、`cleared`、`restored` のいずれかです。`collection`:対象のコレクションです。`record`:レコードのidです。レコードの値は含まれません。 |
| `test` | `message` と、`id` と `name` を持つ `project`。**Send a test event** を押したときだけ送信されます。 |

各配信には、`webhook-id`(メッセージのID)、`webhook-timestamp`(送信された時刻、秒単位)、`webhook-signature`の3つのヘッダーも付きます。これらはオープンなStandard Webhooks形式に従っているため、対応するツールで配信を検証できます。

## 配信が本物であることを確認する

アドレスには誰でもメッセージを送れるため、受け取る側は信用する前に署名を確認する必要があります。署名は、あなたとBriksだけが持つ署名用シークレットで作られます。プロジェクトにWebhookがあると、Webhooksページの **Checking a delivery is genuine** の下に短いコード例が表示されます。確認の流れを言葉にすると、次のとおりです。

1. JSONとして読み取る前に、届いたままの本文をテキストとして取得します。
2. `webhook-id`、`webhook-timestamp`、本文を、ピリオドでつなぎます。
3. シークレットの先頭にある`whsec_`を取り除き、残りをbase64からデコードします。それがキーです。
4. 連結したテキストに、このキーを使って HMAC SHA-256 で署名し、結果を base64 で書き出して、先頭に `v1,` を付けます。
5. この値が `webhook-signature` のスペース区切りの値のどれかと一致し、タイムスタンプが現在から5分以内であれば、その配信は本物です。

再送される配信は同じ`webhook-id`を保つので、受信側は処理済みのidを保存しておけば、重複をスキップできます。

シークレットを安全に保つ

署名シークレットは一度しか表示されず、もう一度表示することはできません。紛失した場合や漏えいした場合は、Webhookの三点メニューから **New signing secret** を選んでください。古いシークレットは新しい配信の署名にすぐ使われなくなるので、受信側のツールには新しいものをすぐに設定してください。

## 配信と再試行

どこで

1. Projects
2. Your project
3. Settings
4. Webhooks
5. Deliveries

**Deliveries** には、過去30日間の配信がすべて新しい順に並びます。**Status** で絞り込み、**Show** を押してください。1件をクリックすると、メッセージ全文、エラー、送信先アドレスからの応答を確認できます。

| ステータス | 意味 |
| --- | --- |
| **Sending** | 最初の実行を待っています。 |
| **再試行中** | 試行が失敗し、次の試行が予定されています。この行には、次の試行の何時間後かが表示されます。 |
| **Delivered** | そのアドレスは、成功を表すウェブのコードである2xxのステータスで応答しました。 |
| **Failed** | すべての試行が失敗したか、配信をまったく送信できませんでした。 |

各試行は、応答を最大15秒待ちます。応答が2xxでなければ、Briksは再試行します。試行は全部で5回で、1回目はすぐに、その後は約30秒後、2分後、8分後、32分後に行い、最初から最後までで約45分です。410(gone)の応答が返ると、再試行はすぐに止まります。リダイレクトには従わないため、最終的なアドレスを指定してください。

配信が **Failed** または **Delivered** になったら、**Send again** で同じIDの同じメッセージを、署名し直して再送します。Webhookはオンになっている必要があります。

## インサイトと設定

**Insights** は過去30日間をまとめています。**Deliveries** (配信数)、**Delivered** (配信成功の割合)、**Failed after every try** (再試行の回数つき)、**Average answer** (平均応答時間)です。その下の **By event** と **By address** で、失敗が集中している箇所がわかります。

**Settings** の **Download the webhooks** の下に **Download JSON** があり、各webhookのアドレス、イベント、メモが含まれます。署名シークレットは含まれません。危険ゾーンには、配信ログを削除して再試行をすべて止める **Clear log** と、プロジェクト名を入力するとすべてのwebhookを削除する **Delete all** があります。どちらもOwnerとAdminが使えます。

## 実例:フォームの入力内容を別のツールへ送る

フォームの送信内容はスタジオからエクスポートできないため、届いた内容を別のツールに残すにはウェブフックを使います。スタジオにも保存され、最新の100件が **Settings**, **Forms** に表示されます。

ヨークのウェディングフォトグラファーが、お問い合わせをお客様リストに送ります

1. 相手のツールからアドレスを取得する

   場所: Her client list tool

   彼女はそこで受信 Webhook を作成し、発行されたアドレスをコピーします。

2. Webhookを追加する

   場所: Settings, Webhooks

   彼女はアドレスを貼り付け、メモに`Client list`と書き、**Published** のチェックを外して、**Form received** だけにチェックを入れたままにします。

3. ツールにシークレットを渡す

   場所: Her client list tool

   彼女のツールは署名を確認するので、ダイアログを閉じる前に、設定へ署名シークレットを貼り付けます。

4. 試してみる

   場所: Settings, Webhooks, Deliveries

   テストイベントを送信すると、**Deliveries** に **Delivered** と表示されます。

5. フィールドを対応させる

   場所: Her client list tool

   彼女は `fields` のラベルであるお名前、挙式日、会場を自分のツールの列に対応づけ、`production` が `false` のメッセージは無視するよう設定します。

次のお問い合わせ

> ある夫婦が、彼女の公開サイトのお問い合わせフォームに入力します。

サイトが本番環境にあるため、問い合わせは彼女の受信箱に届き、少しあとにクライアント一覧にも表示されます。

## 次に読む

- [サイトの機能 **フォーム** Briks のサイトにフォームを追加し、プレビューでテストし、スタジオで送信内容をすべて確認し、本番環境では1件ずつメールで受け取り、webhook で他へ渡せます。](https://briks.dev/ja/docs/forms)
- [データと自動化 **定期タスク** サイトで定期タスクを決まった時刻に実行。朝の要約や週次の整理に。書き方、実行結果の確認、失敗時の対処、プランごとの上限を解説します。](https://briks.dev/ja/docs/crons)
- [データと自動化 **データベース** サイトが保存しているデータの見つけ方、レコードの手動での編集と追加、コレクションのJSONまたはCSVでのダウンロード、そして誰が何をできるか、適用される制限について説明します。](https://briks.dev/ja/docs/database)
- [データと自動化 **ログ** ビルドログとサイトへの直近1日分のリクエストを読み、レベルやステータスで絞り込んで、失敗しているフォームやジョブ、遅いページの原因を探せます。](https://briks.dev/ja/docs/logs)

まだ解決しませんか?

プロジェクト名と、表示されると思っていた内容を添えて [hello@briks.dev](mailto:hello@briks.dev) までご連絡ください。スクリーンショットがあると助かります。