GLOSSARY / 用語を知る
Webhookとは？
「何か起きたら、向こうから知らせてもらう」仕組み
注文・予約・問い合わせ・GitHubの更新など、あるサービスで何かが起きた瞬間に、別のシステムへ自動で知らせたいことがあります。Webhookは、イベントが起きたら、登録しておいたURLへ向こうから通知を送るための仕組みです。
更新日：2026-09-22イベント発生 → Webhook通知 → 登録URLへデータ送信 → 次の処理を開始という流れです。こちらから何度も確認しに行かなくても、変化が起きたタイミングで通知を受け取れます。
Webhookは「呼び鈴」のようなもの
何か変化があったかを何度も見に行く代わりに、「変化があったらこのURLへ知らせてください」と先に登録しておきます。イベントが起きると、サービス側から自動で通知が届きます。
注文完了、予約作成、決済完了、GitHub Pushなど、サービス側のイベントです。
サービスが登録済みURLへ、イベント内容をHTTPリクエストとして送ります。
受け取った側で、通知・記録・処理開始などを自動実行できます。
GitHub公式でも、Webhookは「システム内のイベントを購読し、イベント発生時に自動でデータを受け取る仕組み」と説明されています。
たとえば、こんな使い方
- 注文が入ったらSlackへ通知する
- 決済が完了したら顧客台帳へ記録する
- 予約が作成されたら担当者へ知らせる
- GitHubへPushされたら自動デプロイを始める
- 問い合わせが来たら受付処理を開始する
- 外部サービスでステータスが変わったら社内システムへ反映する
「何かが起きた直後に、別の作業を始めたい」ときに向いています。
APIとの違いは？
「今どうなってる？」と聞く
「変わったよ」と知らせる
GitHub公式では、WebhookはAPIを定期的に呼んで変化を確認する方法と対比して説明されています。Webhookなら、イベントが起きたときだけ通知を受け取れます。
Webhookで「注文が入った」と受け取り、そのあとAPIで注文詳細を取得する、といった使い方ができます。
Webhookを使うには何が必要？
- 通知元サービス：Webhookを送れるサービス
- 受け取りURL：通知を受信できるWeb上のURL
- 受け取り側の処理：届いたデータを確認し、必要な処理を行うプログラム
- イベント設定：何が起きたときに通知するか
通知元によって、送られてくるデータ形式や設定方法は異なります。
安全に使うために確認すること
Webhook URLが分かれば誰でも同じようなリクエストを送れる構成だと、偽の通知を受け取る可能性があります。そのため、サービスが提供する署名・Secretなどを使って「本当にそのサービスから届いた通知か」を確認する設計が重要です。
- Webhook用のSecretや署名検証を使う
- 受け取ったデータを無条件に信用しない
- 同じイベントが複数回届いても問題ない処理にする
- 失敗時の再送やエラー記録を考える
- 顧客情報などを受け取る場合は保存先・権限も確認する
公開GitHubやWebページへ秘密情報を直接書かないようにします。サービス側のSecret管理や環境変数などを使います。
言葉屋で考えられる利用例
- 問い合わせ受付 → 自動記録 → 担当者通知
- 決済完了 → 案件ステータス更新
- GitHub更新 → デプロイや確認作業を開始
- 外部フォーム送信 → 顧客台帳へ連携
- 予約・申込イベント → Google Workspace側の処理を開始
「ずっと見張る」のではなく、「変化が起きたときだけ動く」構成にできるのがWebhookの良さです。
よくある質問
WebhookはAPIと同じですか？
役割が違います。APIはこちらからサービスへ依頼・取得するときに使い、Webhookはイベント発生時にサービス側から通知を受け取る用途で使われます。
Webhookはリアルタイムですか？
多くの場合はイベント発生後すぐ送られますが、ネットワークやサービス側の処理による遅延はありえます。
Webhookが届かなかったらどうなりますか？
サービスによっては再送機能がありますが、仕様はそれぞれです。受信履歴や失敗時の再処理方法も含めて設計します。
GASでWebhookを受け取れますか？
Webアプリとして公開してPOSTリクエストを受け取る構成などは可能ですが、認証・署名検証・公開範囲・実行制限を考慮する必要があります。
公式資料
関連ガイド
「Webhookで、この受付を自動化できる？」
使っているサービスがWebhookに対応しているか確認し、APIやGASと組み合わせる方法まで整理できます。
無料相談へ →