Webhook（ウェブフック）とは、あるサービスで出来事が起きたときに、登録しておいた宛先へ自動で知らせを送る仕組みです。この記事は、Webhookという仕組みを始めて知ったが、よく理解できない方に向けて、Webhookの意味と使いどころを解説します。
読み終えると、次のことがわかります。
- Webhookが「確認作業を減らす仕組み」と言える理由
- API（システム同士がデータをやり取りするための窓口）との違いと、使い分けの目安
- Slackやkintoneなど、業務での活用例
- 設定だけで使える場合と、開発が必要な場合の違い
- 安全に使うために、導入前に確認したいこと
Webhookとは？
Webhook（ウェブフック）とは、あるサービスで出来事（イベント）が起きたときに、あらかじめ登録しておいた宛先へ自動で知らせを送る仕組みです。
要点は次の3つです。
- 「何か起きたら、相手のほうから知らせてくれる」仕組みである
- 知らせの宛先は「Webhook URL」と呼ばれる、インターネット上の住所である
- 知らせを待つだけでよいため、自分から何度も確認しに行く手間が減る
GitHub（プログラムの管理などに使われるサービス）の公式ドキュメントでも、Webhookは「特定の出来事が起きるたびに、外部のサーバーへ通知を届ける方法」として説明されています。
出典：webhook について – GitHubドキュメント
身近なものにたとえると
取り寄せを頼んだ商品がお店に届いたかを知りたいとき、方法は2つあります。
- 自分からお店に何度も電話して「届きましたか？」と聞く
- 「届いたら電話してください」と頼んでおき、連絡を待つ
後者がWebhookの考え方です。前者は、後ほど説明する「ポーリング」という方法に当たります。
Webhookの仕組み
この章では、Webhookに登場する「送る側」「受け取る側」「Webhook URL」の3つを説明します。
送る側と受け取る側
Webhookには、必ず2つの登場人物がいます。
- 送る側：出来事が起きるサービス（例：決済サービス、kintone、GitHub）
- 受け取る側：知らせを受け取って、何かをするサービスやシステム（例：Slack、自社の業務システム）
やり取りは、次の順番で進みます。
- 受け取る側が、知らせの宛先となるURL（Webhook URL）を用意する
- 送る側の設定画面などで、そのURLと「どの出来事で知らせるか」を登録する
- 指定した出来事が起きると、送る側がそのURLへ自動でデータを送る
- 受け取る側が、届いたデータをもとに通知の表示や記録の更新を行う
送られるデータは、多くの場合JSON（ジェイソン：「項目名と値」の組み合わせでデータを表す、決まった書き方）という形式です。たとえば決済サービスのStripeは、出来事の情報をJSON形式で、HTTPS（暗号化された通信の方式）を使って送ると説明しています。
Webhook URLとは
Webhook URLは、知らせの宛先となるURLです。郵便でいえば「届け先の住所」に当たります。
たとえばSlackでは、アプリの設定画面で「Incoming Webhooks」という機能を有効にし、投稿先のチャンネルを選ぶと、専用のURLが発行されます。
このURLは、他人に知られないように扱う必要があります。理由は「Webhookは危険？」の章で説明します。
WebhookとAPIの違い
一言でいうと、APIを使って情報を確認するときは「自分から取りに行く」、Webhookでは「相手から届く」という違いがあります。
API（Application Programming Interface：システム同士がデータをやり取りするための窓口）は、情報がほしい側が「今の情報をください」と問い合わせ、その返事としてデータを受け取る使い方が一般的です。
変化があったかを知るために、APIへの問い合わせを一定の間隔で繰り返す方法を「ポーリング」と呼びます。冒頭のたとえでいう「何度もお店に電話して確認する」方法です。ポーリングではデータがあるかを断続的に確認するのに対し、Webhookではデータが発生した時点で受け取れる違いがあります。
| 比べる点 | API（ポーリングで使う場合） | Webhook |
|---|---|---|
| やり取りを始めるのは | 情報がほしい側 | 出来事が起きた側 |
| 情報が届くタイミング | 問い合わせたとき | 出来事が起きたとき |
| 変化がないとき | 問い合わせても新しい情報はない | 何も送られてこない |
| 受け取る側に必要なもの | 問い合わせを繰り返す仕組み | 知らせを受け取るURL（受け口） |
| たとえると | 何度も電話して確認する | 届いたら電話をもらう |
なお、WebhookとAPIは、どちらか一方を選ぶものではありません。Webhookで「出来事が起きた」ことを知り、詳しい情報はAPIで取りに行く、という組み合わせもよく使われます。Stripeも、知らせが届く順番が前後して手元にない情報がある場合は、APIで取得できると案内しています。
APIそのものについて詳しく知りたい方は、API連携とは？わかりやすく仕組みや活用例を図解で解説をご覧ください。
Webhookを使うとできること
前の章で見た「相手から届く」という特徴から、業務では主に次の3つのことができます。あわせて、注意点も確認しておきましょう。
確認作業を減らせる
人やシステムが、変化がないかを定期的に確認しに行く必要が減ります。GitHubは、Webhookの利点として次の点を挙げています。
出典：webhook について – GitHubドキュメント
- ポーリングと比べて、少ない手間と処理の負担で済む
- 規模が大きくなっても対応しやすい
- API利用回数の上限（レート制限：一定の時間内に呼び出せる回数の決まり）に達しにくい
起きてすぐ、次の作業に回せる
Webhookならほぼリアルタイムで更新を受け取れるとしています。
たとえば銀行による支払いの確認や、定期支払いの成功など、時間をおいて起きる出来事を受け取る用途があります。支払いが確認できたら、その知らせを合図に発送の準備に移る、といった使い方ができます。
手作業の転記や連絡を自動化できる
レコード（データ1件分）の追加・編集・削除などの操作があったときに、その内容を外部のサービスへ送れます。
届いた内容をチャットへの通知や別のシステムへの登録に使えば、人が画面を見て書き写したり、関係者に連絡したりする作業を減らせます。
注意点：Webhookだけでは足りない場面もある
- 受け取る側は、いつ知らせが来ても受け取れる状態にしておく必要があります。Stripeの場合、受け取り先はインターネットから接続できるHTTPSのURLである必要があります。
- 知らせが届かない、同じ知らせが2回届く、といったことへの備えが必要です（「Webhookは危険？」の章で説明します）。
- 過去のデータをまとめて取り出したい場合などは、APIのほうが向いています（次の章で説明します）。
出典：Receive Stripe events in your webhook endpoint
APIよりWebhookが向くケース／APIのほうが向くケース
「出来事が起きるたびに、すぐ知りたい」ならWebhook、「必要なときに、必要な分だけ取りたい」ならAPIが向いています。
APIのほうが適する場面として、情報が1回だけ必要な場合、時々しか必要ない場合、対象が小規模で今後も増える予定がない場合を挙げています。これをもとに、判断の目安を表にまとめました。
| 判断の目安 | Webhookが向く | APIのほうが向く |
|---|---|---|
| 情報が必要になる頻度 | 出来事が起きるたびに知りたい | 1回だけ、または時々でよい |
| 対象の規模 | 対象が多い、今後増える見込みがある | 小規模で、増える予定がない |
| 知りたいタイミング | 起きたらすぐ | 必要になったときでよい |
| 業務での例 | 支払い完了・フォーム回答・データ更新の通知 | 使い始める前にこれまでのデータをまとめて取り込む、月末にデータをまとめて取り出す、画面を開いたときに最新の状態を表示する |
迷ったときは、「両方を組み合わせる」という考え方もあります。前の章で触れたとおり、Webhookで出来事が起きたことを知り、詳しい内容はAPIで取りに行く使い方です。また、最初にAPIでこれまでのデータを取り込み、その後の変化をWebhookで受け取る、という組み合わせ方もあります。
どちらが合うかは、つなぐサービスがどちらの方法に対応しているかによっても変わります。まずは、使っているサービスの公式ヘルプで「Webhook」「API」の項目があるかを確認してみてください。
システム同士をつなぐ方法は、WebhookとAPIだけではありません。CSVファイルを使った連携や、iPaaS（アイパース：複数のサービスをつなぐためのクラウド型の連携ツール）を使う方法などもあります。連携方法全体の比較は、システム間のデータ連携方法を一覧解説｜シチュエーション別の選択例もで紹介しています。
業務での活用例
ここでは、業務担当者の方が目にすることが多いサービスを例に、Webhookの使われ方を紹介します。
Slackにお知らせを投稿する
Slackの「Incoming Webhooks」は、外部からSlackのチャンネルにメッセージを投稿するための受け口です。発行された専用のURLへ決まった形式のデータを送ると、そのチャンネルに投稿されます。
出典：Sending messages using incoming webhooks | Slack Developer Docs
ただし、送るデータはSlackが決めた形式に合わせる必要があります。そのため、つなぐサービスによっては、間に連携サービスや小さなプログラムを挟むことがあります。
kintoneの更新を外部に知らせる
kintoneでは、レコードの追加・編集・削除、コメントの書き込み、プロセス管理（申請や承認などの進み具合の管理）のステータス更新があったときに、Webhookで外部へ知らせを送れます。
出典：kintone Webhook – cybozu developer network
送り先のURLと送る条件は、アプリの設定画面（［設定］タブの［カスタマイズ／サービス連携］にある［Webhook］）から指定します。公式ヘルプでは、プログラムを書かずに設定できると案内されています。ZapierやMicrosoft Power Automateといった、サービス同士の連携を支援するツールを送り先に指定する方法も紹介されています。
同じヘルプでは、次の点も案内されています。
- ライトコースの契約では、Webhookを利用できない
- Excel・CSVファイルの読み込みや、複数レコードの一括削除などで操作した場合は、通知が送られない
- 通知はドメイン単位で1分間に60回までで、それを超えた操作では通知が送られない
大量のレコードを一括で処理する業務では、Webhookだけでは変更を漏れなく受け取れない場合があります。その場合は、APIで定期的にデータを取得するなど、ほかの連携方法との組み合わせも検討してください。
LINE公式アカウントで、届いたメッセージに応答する
LINE公式アカウントでは、友だち追加やメッセージの受信といった出来事が、Webhookで「ボットサーバー」に送られます。ボットサーバーとは、届いた知らせを受け取り、返信などの処理を行うために、開発者が用意するサーバーのことです。
出典：メッセージ（Webhook）を受信する | LINE Developers
支払いの完了を受け取る
決済サービスのStripeは、支払いの確認や、定期支払いの成功といった出来事をWebhookで知らせます。受け取った知らせをもとに、自社の受注管理や会員管理の情報を更新する、といった使い方をします。
出典：Receive Stripe events in your webhook endpoint
Teamsへの通知は、2026年に仕組みが変わっている
Microsoft Teamsでは、これまでWebhookによる通知などに使われてきた「Office 365コネクタ」の廃止が進められてきました。Microsoftの開発者向けブログでは、2026年5月18日から22日にかけて廃止を進め、それ以降は動作しなくなると案内されていました
出典：Retirement of Office 365 connectors within Microsoft Teams
代わりに案内されているのは、Power Automateを使った「ワークフロー」アプリです。テンプレート「Webhook アラートをチャネルに送信する」などを使うと、通知を受け取るためのWebhook URLが発行されます。
出典：受信 Webhook を作成する – Teams | Microsoft Learn
ワークフローに移行しても、これまでと同じ表示や操作ができるとは限りません。Microsoftは、ワークフロー経由の投稿ではメッセージ内のボタンが表示されないことを、既知の制限として挙げています。投稿者の名前やアイコンを変えられない点も、制限として案内されています。既存の通知を移行するときは、実際の表示を確かめてください。
インターネット上には古い設定手順も残っています。Teamsで通知を設定するときは、Microsoftの最新の案内を確認してください。
設定だけで使える場合と、開発が必要な場合
分かれ目は、「受け取る側を、既製のサービスでまかなえるか」です。受け取る側を自社で用意する場合は、開発が必要になります。
| ケース | 例 | 主な作業 |
|---|---|---|
| 設定が中心で済むことが多い | kintoneの更新を、連携サービス経由でSlackに知らせる | 各サービスの設定画面で、送り先のURLや条件を登録する |
| 開発が必要 | LINE公式アカウントに届いたメッセージに、自動で応答する | 知らせを受け取るサーバー（受け口）を作る |
| 開発が必要 | 支払い完了の知らせを受けて、自社の受注システムを更新する | 受け口を作り、届いた内容で自社のデータを書き換える処理を作る |
LINE公式アカウントの場合、知らせはボットサーバーに送られるため、受け取る仕組みを用意する必要があります。Stripeの場合も、受け取り先として、インターネットから接続できるHTTPSのURLを登録する必要があります。
出典：メッセージ（Webhook）を受信する | LINE Developers、Receive Stripe events in your webhook endpoint
設定が中心で済む場合でも、利用条件や費用の確認は必要です。たとえば、kintoneとPower Automateを使ってSlackに投稿する方法では、Power Automateの有償ライセンスが必要になると案内されています。
出典：kintone Webhook & Microsoft Power Automateを使ってSlackに投稿する、2025年7月更新
自社のケースがどちらに当たるかは、次の3点で見当をつけられます。
- 受け取る側は、自社のシステムか、既製のサービスか
- 届いた知らせをもとに、在庫・受注・会員情報などのデータを書き換えるか
- 送る側が送るデータの形式と、受け取る側が受け付ける形式が合っているか
ひとつでも「自社のシステム」「書き換える」「形式が合わない」に当たる場合は、受け取る側の処理を開発する必要が出てくることがあります。ただし、連携サービスやiPaaSで対応できる場合もあり、必ず一から開発するとは限りません。反対に、既製のサービス同士でも、標準の機能では実現できず、追加の開発が必要になることもあります。使うサービスの標準機能や扱えるデータの形式を、各サービスの公式ヘルプで確認したうえで判断してください。
受け取る仕組みの開発が必要になりそうな場合は、弊社のお問い合わせフォームからご相談ください。
Webhookは危険？安全に使うためのポイント
Webhookという仕組みそのものが危険なわけではありません。ただし、外部からの知らせを受け取る「入り口」になるため、対策をとったうえで使う必要があります。ここでは3つのポイントを説明します。
Webhook URLは「合鍵」のように扱う
SlackのIncoming Webhooksのように、URLそのものが「投稿してよい」という許可の役割を持つ仕組みがあります。この場合、URLを知っていれば誰でも投稿できてしまいます。Webhook URLには秘密の情報が含まれるため、インターネット上で共有したり公開したりしないようにしましょう。流出を検知した場合は、Slack側で無効にするとしています。
出典：Sending messages using incoming webhooks | Slack Developer Docs
一方、送る側が知らせに「署名」を付け、受け取る側がそれを確かめることで、URLを知っているだけの第三者からの偽の知らせを見分けられる仕組みもあります。たとえばGitHubは、「Webhookシークレット」という秘密の文字列を使って、GitHubから送られ、途中で書き換えられていないことを確かめるよう案内しています。署名については、次の項目で説明します。
出典：Webhook の使用に関するベスト プラクティス – GitHubドキュメント
社内マニュアルやチャットにそのまま貼らない、知っている人を必要な担当者に限る、といった管理をおすすめします。
本物の送り主からの知らせかを確かめる
確認をしないと、第三者が偽の知らせを送り、注文の処理などを実行させるおそれがあります。対策として、次の2つがあります。
署名の検証：送る側と受け取る側だけが知る「秘密の鍵」をもとに作られた署名を確認し、本物の送り主から届いたこと、途中で書き換えられていないことを確かめる
- 送信元の制限：決まったIPアドレス（インターネット上の機器の住所）からの知らせだけを受け付ける
LINEは、署名の検証を必須としています。LINE側のIPアドレスは公開していないため、IPアドレスでの制限ではなく署名の検証で安全を確保するよう案内しています。
出典：Webhookの署名を検証する | LINE Developers
このように、どの対策が使えるかはサービスによって異なります。
「届かない」「2回届く」に備える
受け取る側が一時的に止まっていると、知らせを受け取れないことがあります。失敗したときに送り直す「再送」の仕組みは、サービスによって違います。
| サービス | 失敗したときの再送 | 注意点 |
|---|---|---|
| Stripe | 本番環境では最大3日間、自動で再送する | 同じ知らせが2回以上届くことがある。届く順番も保証されない |
| LINE | 再送機能は初期状態では無効。設定画面で有効にできる | 有効にしても、確実に再送されるとは限らない。再送すると、重複や順番の入れ替わりが起こりうる。受信の失敗が長く続くと、送信が止まる可能性がある |
| GitHub | 自動では再送しない。手動で再送する | 失敗に気づく仕組みが必要 |
同じ知らせが2回届くことへの備えも大切です。たとえば、同じ注文の知らせが2回届いても、2回出荷しないようにする必要があります。Stripeは、処理済みの知らせのIDを記録しておき、同じIDの知らせは処理しない方法をすすめています。
出典：Receive Stripe events in your webhook endpoint
開発を依頼する前に決めておくこと
Webhookを使った仕組みを開発会社に依頼する場合、次の項目を社内で整理しておくと、相談や見積もりの依頼がしやすくなります。すべてが決まっていなくても、わかる範囲で書き出しておくと話が進めやすくなります。
- どのサービスの、どの出来事で知らせを送るか
- 知らせを受け取ったら何をするか（通知するだけか、データを書き換えるか）
- 送る側のサービスに再送の仕組みがあるか。初期設定で有効になっているか
- 同じ知らせが2回届いたとき、どう扱うか
- 知らせが届かなかったとき、誰がどうやって気づくか
- Webhook URLや、署名の確認に使う秘密の鍵を、誰が管理するか
- 受け取った知らせの記録（ログ）を残すか。残す場合、どのくらいの期間残すか
よくある質問
Webhookの読み方は？
「ウェブフック」と読みます。
WebhookとAPIは、どちらを使えばよいですか？
出来事が起きるたびにすぐ知りたいならWebhook、必要なときに必要な分だけ取りたいならAPIが向いています。両方を組み合わせることもあります。詳しくは「APIよりWebhookが向くケース／APIのほうが向くケース」の章をご覧ください。
プログラミングの知識がなくても使えますか？
サービスの組み合わせによっては、設定画面の操作が中心で使える場合があります。受け取る側を自社で用意する場合は、開発が必要です。「設定だけで使える場合と、開発が必要な場合」の章を参考にしてください。
Webhookは危険ですか？
仕組みそのものが危険なわけではありませんが、外部からの知らせを受け取る入り口になります。URLの管理、送り主の確認、届かない・2回届くことへの備えを前提に使ってください。
まとめ
- Webhookは、出来事が起きたときに、登録した宛先へ自動で知らせを送る仕組み
- APIへの問い合わせを繰り返す「ポーリング」と比べて、確認しに行く手間を減らせる
- 出来事のたびにすぐ知りたいならWebhook、必要なときに取りたいならAPIが向いており、組み合わせることも多い
- 受け取る側を自社で用意する場合は、開発が必要になる
- URLの管理、署名の確認、再送と重複への備えを、導入前に確認しておく
まずは、自社で使っているサービスの公式ヘルプで、Webhookに対応しているか、どの出来事で知らせを送れるかを確認するところから始めてみてください。
Webhookを使った仕組みづくりのご相談
株式会社オプスインでは、Webシステムやアプリの受託開発を行っています。「自社のシステムとほかのサービスをつなぎたい」「知らせを受け取る仕組みを作りたい」といった場合は、お問い合わせフォームからお気軽にご相談ください。
