Webhookとは？読み方・仕組み・APIとの違いを実際のHTTPリクエストで解説

Webhookの読み方は「ウェブフック」です。あるサービスのイベントをきっかけに、あらかじめ登録しておいた相手のURLへHTTPリクエストで通知する仕組みを指します。配信には遅延や再送が生じる場合があります。GitHubへのpush、決済の完了、LINEへのメッセージ着信といった出来事を、受け取る側が問い合わせに行かなくても知ることができます。専用のプロトコルはなく、実体はHTTP POSTが1往復するだけです。この記事では、読み方と定義、GitHubが実際に送ってくるヘッダ、ポーリングやWebSocketとの違い、そして「Webhookが廃止される」という話の正体までを、公式ドキュメントと仕様書に沿って整理します。

まとめ

Webhookは「ウェブフック」と読み、Webフックと書かれることもあります。送信側がイベント発生時に受信側のURLへHTTP POSTを送る、一方向の通知です。受信側は2xxを返すだけで、GitHubの場合は10秒以内に応答しないと配信失敗として記録されます。

APIとの違いは通信を始める側にあります。ポーリングは受信側が定期的に問い合わせる方式で、1分間隔なら1日1,440回です。Webhookは送信側から届き、配信回数はイベント数に加えて再送や通知先の数で決まります。その代わり、受信側はインターネットから届く公開URLを用意し、届いたリクエストが本物かを署名で確かめる責任を負います。ブラウザへリアルタイムに配信したいならWebhookではなくWebSocketやSSEの領域です。

Webhook全般に一律適用される共通仕様はなく、署名ヘッダも再送の有無もサービスごとに違います。GitHubは失敗した配信を自動では再送しないので、取りこぼしの回収は受信側の仕事です。この差を揃えようとしているのがStandard WebhooksとCloudEventsです。2026年に話題になった「Webhook廃止」はMicrosoft TeamsのOffice 365コネクタの停止で、Webhookという仕組みは現役です。以下で、それぞれの根拠を見ていきます。

Webhookの読み方と定義

読み方は「ウェブフック」：Webフック・Web Hookなどの表記ゆれ

「Webフック」「Web Hook」もWebhookと同じ仕組みを指す表記です。GitHubの日本語ドキュメントのように公式の日本語版でも英語表記のwebhookがそのまま使われるため、技術文書ではWebhookと書くのが無難です。複数形のwebhooksは、Standard Webhooksのように仕様や製品の名前に入っているときに見かけます。

語源のフックと「ユーザー定義のHTTPコールバック」という原義

語源はプログラミング用語の「フック（hook）」です。既存のプログラムの決められた場所に、利用者側の処理を差し込むための口を指します。Webhookという呼び方は、Jeff Lindsayが2007年5月3日のブログ記事「Web hooks to revolutionize the web」で提唱したものです。記事は「Web hooks are essentially user defined callbacks made with HTTP POST」、つまりHTTP POSTで行うユーザー定義のコールバックだと説明し、コマンドラインでSTDOUTの行き先を付け替えるのに近い、とたとえています。処理を差し込む口がURLになった、と考えると原義に近くなります。

定義に「HTTP」と入っている点が肝心です。Webhookは特定の企業の製品ではなく、HTTPリクエストの使い方に付いた名前です。だからGitHubにもStripeにもLINEにも「Webhook」という機能があり、それぞれ仕様が少しずつ違います。

Webhook URL・イベント・ペイロードという3つの構成要素

Webhookを構成する要素は3つです。

• Webhook URL：通知を受け取る側が用意し、送信側の管理画面に登録するエンドポイント（「ウェブフックユーアールエル」と読みます）。インターネットから到達できる必要があります
• イベント：送信のきっかけになる出来事。GitHubならpushやpull_request、決済サービスなら支払い成功や返金など、送信側が定義した一覧から選びます
• ペイロード：リクエストボディに載る本体データ。Standard Webhooksの仕様は互換性のためにJSON形式を推奨しています

Webhookの仕組み：イベント発生から2xx応答まで

GitHubのWebhookリクエスト：ヘッダと簡略化したボディの例

抽象的な図よりも、実際に届くリクエストを見るほうが早いです。GitHubのリポジトリでpushが起きると、登録済みのWebhook URLには次のような形のリクエストが届きます（ヘッダ名と値の形式はGitHubのWebhook events and payloadsの例に合わせています。署名とIDの値は公式例のもので、このボディから計算したものではありません）。

POST /webhooks/github HTTP/1.1
Host: example.com
Content-Type: application/json
User-Agent: GitHub-Hookshot/044aadd
X-GitHub-Event: push
X-GitHub-Delivery: 72d3162e-cc78-11e3-81ab-4c9367dc0958
X-GitHub-Hook-ID: 292430182
X-Hub-Signature-256: sha256=d57c68ca6f92289e6987922ff26938930f6e66a2d161ef06abdf1859230aa23c

{
  "ref": "refs/heads/main",
  "repository": { "full_name": "example/app" },
  "pusher": { "name": "octocat" }
}

X-GitHub-Eventがイベント種別、X-GitHub-Deliveryがイベントを識別するGUID、X-GitHub-Hook-IDがWebhook自体のID、User-Agentは必ずGitHub-Hookshot/で始まります。X-Hub-Signature-256はシークレットを設定したときだけ付く署名で、リクエストボディをシークレットを鍵にHMAC-SHA256で計算したhex値です。SHA-1版のX-Hub-Signatureも互換のために残っていますが、GitHubはSHA-256版を使うよう案内しています。

受信側の仕事は、このリクエストを受け取って2xxを返すことです。GitHubのベストプラクティスは「10秒以内に2xxを返す」ことを求めており、それを超えると接続を切って配信失敗として記録します。重い処理はキューに積んで後で実行し、先に応答だけ返すのが定石です。

送信元IPの範囲と、受信URLを公開するときの前提

Webhookを受けるには、送信側のサーバーから届くURLが要ります。社内のファイアウォールで送信元を絞りたい場合、GitHubは送信元のIPレンジをAPIで公開しています。https://api.github.com/metaのhooksを2026年10月21日に取得したところ、IPv4が7レンジ（192.30.252.0/22、140.82.112.0/20など）、IPv6が2レンジの計9件でした。

このレンジは変わるため、ファイアウォールに固定で書き写すと、ある日から急に届かなくなります。IPで絞るなら定期的に/metaを取り直す仕組みとセットにし、なりすましの防止は次の章の署名検証で行う、と役割を分けてください。開発中に開発用のPCで受けたいだけなら、ngrokでローカルサーバーを外部公開する手順やCloudflare Tunnelのようなトンネルを使います。

Webhook仕様の共通化：Standard WebhooksとCloudEventsの役割

Webhook全般を一律に規定する仕様はありませんが、共通化を目指すStandard Webhooksなどの仕様書は公開されています。HTTPを使う点は共通していますが、ボディはJSONとは限らず、署名の有無やヘッダもサービスごとに異なります。複数サービスから受信するときは、それぞれの署名方式を確認し、方式ごとに検証処理を用意します。共通仕様への対応や公式ライブラリの利用で、実装を共用できる場合もあります。

これを揃えようとしている仕様が2つあります。ひとつがStandard Webhooksで、ヘッダをwebhook-id・webhook-timestamp・webhook-signatureの3つに固定します。仕様書の例は次のとおりです。

webhook-id: msg_2KWPBgLlAfxdpx2AI54pPJ85f4W
webhook-timestamp: 1674087231
webhook-signature: v1,K5oZfzN95Z9UVu1EsfQmfVNQhnkZ2pj9o9NDN/H/pI4=

署名の対象はmsg_id.timestamp.payloadをピリオドで連結した文字列で、対称鍵（HMAC-SHA256）ならv1,、非対称鍵（ed25519）ならv1a,を頭に付けます。IDと時刻まで署名に含めるのは、同じリクエストを後から投げ直すリプレイ攻撃を防ぐためです。仕様は時刻が許容範囲内かを確かめるよう求めていますが、何分までを許すかは決めていません。

もうひとつのCloudEventsは、イベントデータそのものの書式を定める仕様です。CNCFで2024年1月25日にgraduatedプロジェクトになり、最新版は2022年2月のv1.0.2のままです（GitHubのリリース一覧で2026年10月21日に確認）。Standard Webhooksが「配送と署名の作法」、CloudEventsが「イベントの中身の書式」を受け持つ、と分けて捉えると混乱しません。

ただし、GitHubもStripeも独自形式のままです。受ける側は当面、相手ごとの実装が必要だと割り切ってください。自社がWebhookを送る側になるときは、ゼロから独自形式を作るよりStandard Webhooksに寄せたほうが、受け取る側の実装が楽になります。

WebhookとAPI・WebSocketの違い

ポーリング型APIとの違い：通信の起点と1日の通信回数

WebhookはAPIの一部として提供されることもあります。ここでは、HTTPベースのデータ取得APIを定期的に呼び出すポーリング方式と比較します。違うのは誰が通信を始めるかです。ポーリングではデータを必要とする側が定期的にAPIへ問い合わせ、Webhookではイベントの発生元が登録先へ通知します。

通信回数は掛け算で出ます。1分間隔なら60×24で1日1,440回、5分間隔でも288回です。10サービスへそれぞれ1分間隔で1回ずつ問い合わせるなら、合計は1日14,400回です。更新が少ない業務では、その多くが「変化なし」の応答になります。対象イベントが1日10件で、各イベントを1つの通知先へ個別に送り、再送がなければ、Webhookの配信は1日10回です。APIのレート制限によく当たるなら、空振りのポーリングが枠を使っていないかを先に疑ってください。

Webhook・WebSocket・SSEの比較：通知先と接続方式

「リアルタイムに届く」という点でWebSocketやSSE（Server-Sent Events）と並べられますが、使う場面が違います。

決定的なのは、誰が接続を張るかです。WebSocketとSSEはブラウザ側から接続を張って開けておくので、受け手に公開URLは要りません。Webhookは送信側が受け手のURLへ毎回つなぎに来るので、受け手はサーバーである必要があります。チャット画面や株価表示のようにブラウザへ流し続けたいならWebSocketかSSE、決済完了のようなサーバー間の通知ならWebhook、と分けてください。WebSocketとSSEの選び分けはSSEとWebSocketの違いと使い分け、WebSocketの仕組みはWebSocketとは？仕組み・ハンドシェイクからNode.js実装までで扱っています。

Webhookを選ぶ条件と、ポーリングを残すべき条件

イベントが散発的で、発生をきっかけに処理を始めたいならWebhookが候補です。決済完了通知やCI/CDのトリガーで使われますが、数秒以内の到達が必須なら、送信元の配信保証と障害時の補完手段を確認してください。

逆に、次のどれかに当てはまるならWebhookだけに頼るべきではありません。受信側を外部に公開できない環境では、Webhookは物理的に届きません。過去にさかのぼった一括取得が必要な場合も、Webhookは登録後に起きたイベントしか流れてこないため、初期同期はAPIで行うことになります。データの整合性を自分で保証したい場合も同じで、次章のとおりWebhookには欠損の可能性があり、最後の突き合わせはAPIに頼ります。

実務では、初期同期と定期的な突き合わせをAPI、日常のリアルタイム反映をWebhook、と併用する構成が安定します。複数システムをまたぐ連携の設計から任せたい場合は、一創のAPI開発・システム連携の支援でも相談を受けています。API方式そのものの選定はREST APIとGraphQLの違いと使い分け、イベントを軸にした全体設計はイベント駆動アーキテクチャとは？を参照してください。

Webhookでできることと主な対応サービス

用途は大きく、チャットへの通知、システム間のデータ同期、処理の連鎖（CI/CDやワークフローの起動）に分かれます。ここで混同しやすいのが通信の向きです。同じ「Webhook」でも、相手から届くものと、相手へ送り込むものがあります。

たとえばkintoneのWebhookは、レコードの追加・編集・削除、コメントの書き込み、プロセス管理のステータス更新の5種類の操作で通知を送り、使うにはcybozu.com管理画面でWebhookの設定を許可しておく必要があります。kintoneでWebhook・REST API・iPaaSのどれを使うかはkintoneのデータ連携を実装視点で選ぶで比べています。

「届く」型は受信エンドポイントを自分で用意し、署名を検証する必要があります。「送り込む」型（Incoming Webhook）は相手が発行したURLへPOSTするだけで、受信エンドポイントは要りません。LINE公式アカウントのWebhookと、SlackのIncoming Webhookは名前が同じでも向きが逆です。「送り込む」型の設定手順はIncoming Webhookとは？仕組みとSlack・Discordでの使い方、ノーコードツール側でWebhookを受けてフローを動かす例はLangflowのWebhook連携にあります。

Webhookの安全性と信頼性：なりすまし・URL漏えい・配信欠損

URLを知っていれば誰でも送れる：署名とシークレットの役割

Webhook URLはインターネットに公開されているので、URLさえ知っていれば誰でもリクエストを送れます。署名を確かめない受信エンドポイントは、「決済が完了しました」という偽のJSONを送り込まれると、そのまま商品を出荷してしまう状態です。これを防ぐのが、前述のX-Hub-Signature-256やwebhook-signatureのような署名ヘッダです。送信側と受信側で共有したシークレットでボディのHMACを計算し、届いた署名と一致するかを確かめます。

「送り込む」型では立場が逆になります。SlackやDiscordのIncoming Webhookは多くの場合URLそのものが認証情報で、URLが漏れると第三者が誰でもそのチャンネルに投稿できます。URLを認証情報として秘密管理し、公開リポジトリなどへ漏らさないでください。漏えいした場合は、そのWebhookを無効化してURLを再発行します。

署名検証の実装には、JSONをパースする前の生のボディで計算する、タイミング攻撃に強い比較関数を使う、といった落とし穴があります。コードはWebhookの実装方法と作り方で扱っています。

再送するサービスとしないサービス：重複と欠損の前提

Webhookの配信保証はサービスごとに違います。ここを「送信側が必ず再送してくれる」と思い込むのが最も危険です。

GitHubは失敗した配信を自動では再送しません。受信サーバーが落ちていた間のイベントは、管理画面かREST APIから手動で再配信しない限り届かないままです。対してStripeは、本番環境では指数バックオフで最長3日間、配信を試し続けます。LINE Messaging APIはその中間で、管理画面で「Webhookの再送」を有効にしたチャネルだけが再送され、回数と間隔は開示されていません。再送があるサービスでは、同じイベントが2回以上届くことも、発生順と違う順序で届くこともあります。主要サービスの再送と応答期限の比較はWebhookの実装方法と作り方に表でまとめています。

つまり受信側は、欠損と重複の両方に備える必要があります。重複には、イベントIDを保存して処理済みかを判定する冪等性の設計で対処します。GitHubは再配信でもX-GitHub-Deliveryの値を変えず、LINEも再送時にwebhookEventIdを変えません。Standard Webhooksはwebhook-idを冪等キーとして使うよう明記しています。欠損には、前章の「APIによる定期的な突き合わせ」で対処します。同じイベントの再配信を、その都度別のイベントとして処理すると、二重課金や在庫の二重引き当てにつながります。

「Webhookが廃止される」と検索される理由：TeamsのOffice 365コネクタ停止

「Webhook 廃止」と調べると技術そのものが終わるように読めますが、止まったのはMicrosoft TeamsのOffice 365コネクタ（Microsoft 365コネクタ）という一機能です。Microsoftの開発者ブログは期限の延長を何度も繰り返したあと、2026年4月14日の更新で「2026年5月18日から5月22日にかけて段階的に無効化する」と告知しました。代わりに案内されたのは、TeamsのWorkflowsアプリ（Power Automate）が発行するWebhookです。

置き換え先もWebhookだという点が要点です。終わったのはMicrosoftが独自に載せていたコネクタで、HTTP POSTでイベントを届ける仕組みは変わっていません。ここから引き出せる教訓は、URLの発行元がベンダー独自の機能だと、その機能の寿命がそのまま連携の寿命になるということです。連携先ごとにURLの発行元と、廃止予告を受け取る場所（MicrosoftならメッセージセンターやDevBlog、GitHubならChangelog）を一覧にしておくと、次の廃止に間に合います。Teamsでの移行手順と、Slack・Discordを含む廃止状況はIncoming Webhookの記事にまとめています。

よくある質問

WebhookのURLは何と読み、どこで手に入りますか？

「ウェブフックユーアールエル」と読みます。手に入れ方は向きで変わります。GitHubやLINEのように相手から届く型では、自分のサーバーにURLを用意して相手の管理画面に登録します。SlackやDiscordのように相手へ送り込む型では、相手の管理画面でURLを発行して受け取ります。後者の発行手順はIncoming Webhookのサービス別の使い方で扱っています。

Webhookは無料で使えますか？料金はかかりますか？

Webhookの利用料金や利用条件は、サービスと契約プランによって違います。Webhookだけに別料金を設けていないサービスが多い一方で、TradingViewのアラートのWebhook通知（無料のBasicでは使えません）のように有料プランでしか使えない例もあります。費用が発生しやすいのは受け取る側で、リクエストを受けるサーバーの稼働費や、iPaaS・ワークフローツールの実行回数課金がこれに当たります。登録数や呼び出し回数の上限はサービスごとにあるので、連携先のドキュメントで確認してください。

Webhookの作り方は？何から始めればよいですか？

受信側から作るのが自然です。インターネットから届くURLを1本用意し、POSTを受けたら中身を保存してすぐに2xxを返すところまでを最初に作ります。処理を同期で書き切ろうとすると、GitHubの10秒のような送信側のタイムアウトに引っかかります。署名検証・重複排除・再送を含む手順とコードはWebhookの実装方法と作り方にまとめています。

Webhookの受信URLを外部に公開できない場合はどうすればよいですか？

社内からの片方向通信しか許されない環境では、Webhookをそのまま受けられません。選択肢は2つで、クラウド上の中継で署名を検証して通知を保存し、社内側から取得する構成か、Webhookをやめて社内からAPIをポーリングする構成です。CloudflareのQuick Tunnelsなど開発・検証用の一時トンネルは、本番の受け口には使わないでください。通常のCloudflare Tunnelは本番利用も想定されているため、固定ホスト名や可用性、認証を設計して選びます。

Webhookが届かないとき、まず何を確認すればよいですか？

送信側の配信履歴を最初に見ます。GitHubやStripeは管理画面に配信ごとのレスポンスコードを残しているので、リクエストが飛んでいないのか、飛んだが4xx・5xxで弾かれたのかを切り分けられます。届いているのに失敗しているなら、署名検証でのボディの扱い、応答の遅さによるタイムアウト、ファイアウォールによる送信元IPの遮断を疑います。飛んでいないなら、登録したURLの綴りと、通知対象のイベントにチェックが入っているかを確認してください。自分のサーバーを疑う前に、Webhook.siteのような受信内容をそのまま表示するテスト用URLを一時的に登録すると、送信側が何を送っているかを切り分けられます。ただし第三者のサービスにペイロードが渡るので、本番の個人情報や決済データを流す連携では使わないでください。

関連記事

• Webhookの作り方と実装方法｜受信側の署名検証・冪等性と送信側の再送をNode.js・Pythonで解説
• Incoming Webhookとは？Slack・Discord・Teams・Google Chatの使い方と違い【2026年版】
• SSEとWebSocketの違いと使い分け｜WebRTC・WebTransportまで性能比較【2026年10月】
• イベント駆動アーキテクチャとは？仕組み・実装パターンと採用判断を実装者目線で解説
• REST APIとGraphQLの違いと使い分け｜選定基準と運用コスト