Notion Webhookとは？通知を外部へ送る2つの方法と、相手に「届く」ようにする設計
「NotionのWebhookで通知を飛ばせるらしい」と聞いて設定を調べ始めると、記事によって言っていることが違って混乱します。ある記事は「データベースの⋯メニューから設定」と言い、別の記事は「開発者ページで購読を作る」と言う——これは、Notionに名前の似た2つのWebhookが存在するからです。この記事は、その2つ（ノーコードの自動化アクションと、開発者向けのAPI購読）を最初にはっきり切り分け、それぞれの手順・料金・向くケースを比較表で一望できるように整理します。
そして見落とされがちな一点——Webhookはあくまで「別のシステムに知らせる」仕組みで、それ自体は人（特にNotionを持たない社外の相手）に通知を届けるものではない——を切り分け、そこを埋める設計まで扱います。
要点（TL;DR）
- NotionのWebhookは2種類。①ノーコードの「Webhookを送信」アクション（データベースオートメーションから、更新をトリガーに外部URLへ送る）と、②API Webhook（購読）（開発者が公開エンドポイントを用意して変更イベントを受け取る）。
- どちらも共通して**「受け口（エンドポイント）」が別途必要**です。Webhookは飛ばした先で誰かが受けて処理してはじめて意味を持ちます。Notionだけで完結しません。
- ノーコードのWebhookアクションは有料プランが前提（無料プランで作れる自動化はSlack通知のみ）。API Webhookは「無料」でも、受けるサーバーの開発・運用の工数がかかります。
- Webhookが不得手なのは**「人に、特にNotionを持たない社外の相手にそのまま届ける」**こと。ここだけを、受け口の自作なしに埋めるのが通知特化のKapselのようなサービスの領域です。誇張なく、その位置づけも本文で示します。
結論：Webhookは「機械に知らせる」仕組み。人に届けるには受け口が要る
先に結論です。NotionのWebhookは**「Notionで何かが起きたことを、外部のシステムに知らせる」ための出入口であって、それだけで人にメールやメッセージが届くわけではありません。飛ばした先に受け口（Webhookを受け取って処理するサーバーや自動化ツール）**があってはじめて、Slack通知や外部サービスへの反映といった「結果」につながります。
用途で分けると、選ぶべきものはこうなります。
- コードを書かずに、更新をトリガーに外部サービス（Make/Zapier/自作の受け口など）へ飛ばしたい → データベースオートメーションの「Webhookを送信」アクション（有料プラン）
- 自作の連携アプリが、Notionの変更（ページ・コメント等）にリアルタイムで反応するようにしたい → API Webhook（購読）（開発者向け）
- 相手（特にNotionを持たない社外の人）に、そのまま通知を"届けたい" → Webhook単体では成立しない。受け口の自作か、通知特化のサービスが必要
以下、まず2つのWebhookを比較表で一望し、次にそれぞれの手順と勘所を具体的に、最後に「人に届ける」ための設計を扱います。
Notionの2つのWebhookを一望する（比較表）
同じ「Webhook」でも、対象読者も設定場所もまったく別物です。自分がどちらを探しているのかを、この表で先に確定させてください。
| ① Webhookを送信（オートメーション） | ② API Webhook（購読） | |
|---|---|---|
| 向いている人 | ノーコードで自動化したい運用担当 | 連携アプリを作る開発者 |
| 向き | Notion→外部（送信） | 外部←Notion（受信・購読） |
| 設定場所 | データベースの「オートメーション」タブ | 開発者ページ（インテグレーションの接続設定）の「Webhooks」タブ |
| きっかけ | プロパティ変更・ページ追加などのトリガー | ページ・データベース・コメント等の変更イベント |
| 必要なもの | 送信先のWebhook URL（受け口） | 公開されたHTTPSのエンドポイント（localhost不可）＋検証 |
| 料金の勘所 | 有料プランが前提（無料はSlack通知のみ） | API自体は無料。受け口の開発・ホスティング工数がかかる |
| 典型用途 | 承認時にMake経由でSlack DM／HubSpotへ連携／SNS投稿を起動 | Notionの変更を検知して自社アプリを更新・同期 |
ポイントは最下段の共通点です。どちらも「飛ばした先で受け取る仕組み」が別に要る——ここが、Webhookを「通知」と混同すると詰まる場所です。
方法①：ノーコードで「Webhookを送信」（データベースオートメーション）
コードを書かずに使えるのがこちらです。Notionのデータベースオートメーションに用意された**「Webhookを送信」アクション**を使うと、行の更新などをきっかけに、指定したURLへ自動でデータ（HTTPリクエスト）を飛ばせます。「承認済みになったらMake経由でSlackにDM」「ステータス変更をHubSpotへ連携」といった連携を、GUIだけで組めるのが利点です。
設定手順
- 対象のデータベースを開き、右上の**「⋯（三点）」→「オートメーション」**を選ぶ（ビューによっては稲妻アイコン）。
- **「新しいオートメーション」**を作成し、トリガー（例：「ステータス」が「承認済み」になったら）を設定する。
- アクションで**「Webhookを送信」を選び、送信先のWebhook URL**を入力する（送るプロパティも指定可能）。
- 受け口側（Make/Zapier/自作サーバーなど）でそのリクエストを受け取り、Slack通知やメール送信などの「結果」を作る。
手順自体は数分です。ただし4番——受け口の準備——が本題で、ここを用意しないとWebhookは「送っているのに何も起きない」状態になります。
料金と権限の勘所
データベースオートメーションは有料プラン（Plus以上）が前提です。無料プランで作れる自動化はSlack通知のみで、Webhookアクションの新規作成はできません（テンプレートに含まれる既存の自動化は動いても、編集はできない場合があります）。「無料でWebhookを送りたい」と考えていた場合は、ここで前提が変わるので先に確認してください。
つまずき先回り：Webhookアクションは**「送る」まで**が守備範囲です。受け取った側で何をするか（誰に・どう通知するか）は、受け口を用意するあなたの責任範囲になります。「Webhookをオンにしたのに相手に何も届かない」の大半は、受け口を作っていないか、受け口が人への通知まで面倒を見ていないケースです。
方法②：API Webhook（購読）——開発者向け
自作の連携アプリを持っていて、「Notionで変更が起きたら自分のアプリをリアルタイムに反応させたい」なら、こちらのAPI Webhook（購読）です。ページ・データベース・データソース・コメントなどの変更をイベントとして受け取れます。
設定手順と押さえどころ
- 開発者ページで対象の接続（インテグレーション）を選び、「Webhooks」タブ→購読を作成（+ Create a subscription）。
- 公開されたHTTPS（SSL）のエンドポイントURLを登録する。localhostは届かないため、公開サーバーが必要。
- 検証ハンドシェイクを通す：最初のPOSTには署名がなく、本文に
verification_tokenが入っている。これを受け取ってNotionの管理画面に貼り、購読を有効化する。 - 受け取りたいイベント種別を選ぶ。コメント系（
comment.createdなど）は接続側で対応する権限（capability）を有効にしていないと届かない。
設計上の大事な性質が2つあります。ひとつは、イベントは「変わった」という信号で、変更後の中身そのものは含まれないこと。中身が必要なら、イベントを受けてから改めてNotion APIで取得します。もうひとつは、当然ながら受け口となるサーバーの開発・ホスティング・監視が必要なこと。「APIは無料」でも、動かし続けるコストはゼロではありません。
Webhookが苦手なこと：「人に、社外の相手に届ける」
ここまでで見えてきたのは、NotionのWebhookは「システム間の連絡」に強く、「人への通知」はその先の受け口に丸投げになるという構造です。とくに次のようなケースは、Webhookだけでは素直に解けません。
- Notionを持たない社外の相手（クライアント・取引先・生徒など）に、ログイン不要で届けたい
- 相手がメールのボタンを押したらNotionのステータスが変わる、という双方向にしたい
- **「完了・入金済みには送らない」**といった事故防止を、毎回きちんと効かせたい
Webhookで組もうとすると、「送信（Webhookを送る）→受け口を自作→宛先を判定→メール文面を作る→送る→返信を受けてNotionを更新」までを、自分で作って保守し続けることになります。動く仕組みは作れますが、そこが本業でない限り重いのが正直なところです。
図にすると、両者の守備範囲の違いはこうなります。
Notionで更新 → Webhookを送信 → 🖥️ 受け口（自作サーバー / Make / Zapier）→ …ここから先の「人への通知」は自分で組む
※ 受け口を用意しないと、送っても何も起きない
通知特化サービス（Kapsel）
Notionの期日・担当・ステータスを監視 → 📧 相手（社外・Notion不要）へメール → ✅ 相手のワンクリックでNotionのステータスへ書き戻る
※ 完了・入金済みには送らない。受け口の自作は不要
この「人に、特に社外の相手に届ける」一点を、受け口の自作なしに埋めるのがKapselです。NotionのデータベースをWebhookでどこかへ飛ばす代わりに、Notionの期日・担当・ステータスを監視して、Notionを持たない社外の相手にもログイン不要でメールリマインドを送り、受信者のワンクリックでステータスをNotionに書き戻せます。そして完了・入金済みには送りません。無料プラン（¥0）でも自己・社外あわせて月20通まで試せるので、Webhookの受け口を作る前に、まず「人に届く」形を確かめられます（本格運用はStandard ¥1,980／月500通〜）。
Webhookが不要になるわけではありません。システム間をつなぐならWebhook、人に届けるなら通知特化のサービス——と役割で分けると、無理な自作を抱え込まずに済みます。
どちらを選ぶ？用途別の早見表
| やりたいこと | 選ぶもの |
|---|---|
| コードを書かず、更新を外部サービスへ飛ばしたい | ① Webhookを送信（有料プラン） |
| 自作アプリでNotionの変更にリアルタイム反応したい | ② API Webhook（購読・開発者向け） |
| Slackに社内通知したいだけ | まずNotion×Slack連携（無料の自動化で可） |
| Notionを持たない社外の相手にメールで届けたい | 通知特化サービス（Kapsel） |
| 相手のクリックでNotionのステータスを更新したい（双方向） | 受け口の自作、またはKapsel |
よくある質問（FAQ）
NotionのWebhookは無料で使えますか？
ノーコードの「Webhookを送信」アクション（データベースオートメーション）は有料プラン（Plus以上）が前提です。無料プランで作れる自動化はSlack通知のみで、Webhookアクションの新規作成はできません。一方、開発者向けのAPI Webhook（購読）はAPI自体は無料で使えますが、イベントを受け取る公開サーバーの開発・ホスティングの工数が別途かかります。「無料でできる／運用に乗せて続けられる」は分けて考えると失敗しません。
「Webhookを送信」と「API Webhook」は何が違うのですか？
向きと対象読者が逆です。「Webhookを送信」はNotion→外部への送信で、ノーコードの運用担当がデータベースのオートメーションから設定します。**「API Webhook（購読）」は外部←Notionの受信（購読）**で、開発者が接続設定の「Webhooks」タブで公開エンドポイントを登録して使います。「更新を外に飛ばしたい」なら前者、「Notionの変更を自作アプリで受けたい」なら後者です。
Webhookを設定したのに相手に何も届きません。なぜですか？
Webhookは「受け口（エンドポイント）」に向けてデータを送るだけの仕組みだからです。送った先で受け取って処理するサーバーや自動化ツール（Make/Zapierなど）を用意していないと、送信しても何も起きません。また受け口を用意しても、そこが「人への通知」まで面倒を見ていなければ、相手にメールやメッセージは届きません。人に届けること自体が目的なら、通知特化のサービスを使うほうが近道です。
WebhookでNotionを持たない社外の相手に通知できますか？
Webhook単体ではできません。Webhookはシステム間の連絡手段なので、社外の人へ「届ける」には、受け口で宛先を判定してメール送信する仕組みを自作する必要があります。Kapselは、Notionの期日・担当・ステータスを監視し、Notionを持たない社外の相手にもログイン不要でメールリマインドを送り、受信者のワンクリックでステータスをNotionに書き戻せます。完了・入金済みには送りません。
メールのボタンを押したらNotionのステータスを更新する「双方向」はWebhookで作れますか？
作れますが、実装量が大きくなります。ボタンの遷移先となるフォームやWebhookの受け口を用意し、そこからNotion APIでステータスを更新する、という一連を自作・保守する必要があります。この双方向（受信者のクリック→Notion更新）を標準機能として持つのが、通知特化の専用サービスです。
