WebSubとは？ハブ経由で更新を配る仕組みと購読側の実装を実装者目線で解説【2026年版】

WebSubとは、HTTPで取得できるリソースの更新を、ハブと呼ばれる仲介サーバ経由で購読者へ届けるための購読型プロトコルです。購読者が相手のフィードを数分おきに取りに行く代わりに、更新が起きた側からの通知を待ち受ける方式です。旧称はPubSubHubbubで、現在はW3C勧告として仕様が公開されています。この記事では、発見から購読と配信までの手順、購読側のエンドポイントに要る実装、Incoming Webhookのような通知連携との役割の違い、そして自前でハブを持つべきかの判断までを扱います。

まとめ｜WebSubで買えるのはポーリング停止と配信のハブ委譲

このプロトコルが売っているのは2つです。1つは購読者側の定期取得をやめられること。もう1つは、誰に何を配るかという購読者管理と再送をハブへ寄せられることです。発行者は更新をハブへ知らせるだけでよく、購読者が1万人に増えても発行者の負荷はほぼ変わりません。

対価も2つです。経路に第三者のハブが入るため、届いたかどうかの最終的な保証は自分の手を離れます。もう1つは購読者側の負担で、インターネットから到達できるコールバックURLを公開し、意図確認の応答と署名検証を実装し、期限が来る前に購読を更新し続ける必要があります。判断としては、公開フィードを不特定多数へ配る場面に置き、社内システム同士の1対1連携には持ち込みません。

WebSubとは｜発行者とハブと購読者で更新通知を配るW3C勧告

用語が独特なので、何であって何でないかを先に押さえます。

WebSubの定義｜HTTPで更新を知らせる購読型の通信プロトコル

WebSubは、HTTPで取得できるURL（仕様ではトピックと呼びます）を対象に、その内容が変わったことを購読者へプッシュで知らせる約束事です。対象はRSSやAtomのフィードに限らず、HTTPで配信できるものなら形式を問いません。中身の書式を定めるのではなく、購読の申し込み方・意図の確かめ方・配信時のヘッダという、やり取りの手順だけを決めているのが性格です。

比較対象になるのは、購読者が一定間隔でURLを取りに行くポーリングです。RESTの原則に沿ったAPIで更新を追う場合、更新が疎なリソースほど空振りの取得が積み上がります。WebSubはこの空振りをなくす代わりに、待ち受け側の実装を増やす取引だと考えると位置付けが掴めます。

PubSubHubbubとの関係｜名称が変わり2026年に勧告が改訂

元の名前はPubSubHubbubで、Googleの技術者が中心となって作られた仕様です。W3Cへ持ち込まれる過程でWebSubへ改称され、初版の勧告は2018年1月23日に公開されました。2026年8月時点の現行版は、2026年6月2日付の勧告です。改訂で追加されたのは、発見処理をHTTPヘッダとHTML本文のどちらから読むかに関する安全面の注意や、全体像を示す図といった補強で、パラメータ名やヘッダ名といった実装に直結する部分は変わっていません。

そのため、PubSubHubbubの名前で書かれた古い解説記事の手順も、ヘッダ名やパラメータ名についてはおおむねそのまま通用します。ただし署名アルゴリズムの推奨や購読期間の考え方は改訂で整理されているため、実装前に現行の勧告を確認する価値はあります。

役割の分担｜発行者とハブと購読者がそれぞれ何を受け持つのかを見る

登場するのは3者です。発行者は更新されるURLを持ち、そのURLに紐づくハブの場所を公表する役目です。ハブは購読の受付と配信を担い、誰がどのURLを購読しているかの台帳を持ちます。購読者は受け取りたいURLをハブへ申し込み、通知を受けるコールバックを用意します。

ここで押さえたいのは、購読者の一覧を持つのが発行者ではなくハブだという点です。発行者は自分の記事が誰に配られたかを知りません。この分業のおかげで発行側は軽くなりますが、配信状況の可視化はハブの提供機能に依存することになります。

WebSubの仕組み｜発見から購読確認と配信完了までの4つの段階

やり取りは4段階です。順に、どのHTTPが飛ぶのかを見ていきます。

第1段階の発見｜rel=hubとrel=selfのLinkヘッダから場所を知る

購読者はまず、購読したいURLを取得してハブの場所を調べるのが最初の手順です。発行者はレスポンスにハブを示すLinkヘッダと、自分自身の正規URLを示すLinkヘッダを付けます。購読者はHTTPヘッダを先に読み、そこに無い場合だけHTML本文やフィード内のlink要素を見る、という優先順位が決められています。

HTTP/1.1 200 OK
Content-Type: application/atom+xml
Link: <https://hub.example.com/>; rel="hub"
Link: <https://blog.example.com/feed>; rel="self"

本文側のlink要素だけを信じる実装は、投稿内容に細工されたタグを紛れ込ませられると別のハブを掴まされます。ヘッダ優先という規定はこの手の混入を避けるためのもので、購読側を書くときに省略してよい部分ではありません。

第2段階の購読｜hub.callbackとhub.topicをフォーム形式で送る

ハブのURLが分かったら、購読者がハブへPOSTします。必須は3つで、通知を受け取るURLを示すhub.callback、subscribeかunsubscribeの文字列を入れるhub.mode、対象のURLを入れるhub.topicです。任意で、希望する購読期間の秒数を示すhub.lease_secondsと、署名に使う共有秘密のhub.secretを添えます。

POST /subscribe HTTP/1.1
Host: hub.example.com
Content-Type: application/x-www-form-urlencoded

hub.callback=https%3A%2F%2Fapp.example.jp%2Fwebsub%2Fcallback
&hub.mode=subscribe
&hub.topic=https%3A%2F%2Fblog.example.com%2Ffeed
&hub.lease_seconds=864000
&hub.secret=r4nd0m-generated-per-subscription

hub.secretは購読ごとに乱数で作り、200バイト未満に収めることが仕様で求められます。値が長すぎる実装はハブ側で弾かれる余地があるため、32バイト前後のランダム文字列に揃えておくと事故がありません。なお、この時点ではまだ購読は成立していません。

第3段階の意図確認｜hub.challengeをそのまま返して購読を成立させる

ハブは申し込みを受けると、指定されたコールバックURLへGETを投げます。付いてくるのはhub.mode・hub.topic・hub.challenge・hub.lease_secondsで、購読者は2xxのステータスと、本文にhub.challengeの値そのものを返さなければなりません。この往復が、第三者が勝手に他人のURLを購読先として登録する事故を防いでいます。

GET /websub/callback?hub.mode=subscribe
  &hub.topic=https%3A%2F%2Fblog.example.com%2Ffeed
  &hub.challenge=Ab3xY9qT
  &hub.lease_seconds=864000

（購読者の応答）
HTTP/1.1 200 OK
Content-Type: text/plain

Ab3xY9qT

本文にJSONで包んだり、末尾に改行以外の文字を足したりすると一致とみなされず、購読は成立しません。申し込んだ覚えのないトピックが来た場合は404などを返して拒否します。ハブ側が申し込みを断る場合は、hub.mode=deniedとhub.reasonを付けたGETが届きます。

第4段階の配信｜X-Hub-Signature付きのPOSTで更新内容が届く

購読が成立すると、対象URLが更新されるたびにハブからコールバックへPOSTが届きます。本文はハブが取得したトピックの内容そのもので、購読時にhub.secretを渡していれば、X-Hub-Signatureヘッダが付きます。値はmethod=signatureという形式で、認識されるアルゴリズムはsha1・sha256・sha384・sha512の4つです。

POST /websub/callback HTTP/1.1
Content-Type: application/atom+xml
Link: <https://hub.example.com/>; rel="hub"
Link: <https://blog.example.com/feed>; rel="self"
X-Hub-Signature: sha256=1f2a...（本文のHMAC）

現実にはsha1で署名するハブが多く残っているのが実情です。仕様自身も、古い購読者との相互運用のために弱いと分かっているsha1が使われ続けている、と明記しています。購読側を書くときは、届いた署名のアルゴリズム名を見て検証方式を切り替える作りにしておき、自分が発行側でハブを選べる立場ならsha256以上に対応したハブを選びます。

購読エンドポイントの実装｜意図確認の応答と署名検証とリース更新

購読側に要る実装は3つに整理できます。ここを外すと、動いているように見えて通知が届かない状態になります。

1つのURLでGETとPOSTを受ける｜メソッドで処理を分岐させる

コールバックURLは、意図確認のGETと配信のPOSTを同じパスで受ける構成です。GETならクエリのhub.challengeを本文にそのまま返し、POSTなら本文を業務処理へ回す、という分岐を最初に書きます。ここでフレームワークの自動的な本文パースを効かせてしまうと、次の署名検証で使う生のバイト列が失われるため、POST側は生ボディを保持できる設定にしておきます。

署名検証の実装｜生ボディのHMACを時間一定比較で突き合わせる

hub.secretを渡した購読では、届いたPOSTの本文からHMACを計算し、X-Hub-Signatureの値と比較する処理が必要です。比較には桁ごとに早期終了しない関数を使い、署名ヘッダが無いリクエストは処理せずに落とします。秘密を渡しておきながら未署名の配信を受け入れると、検証の意味がなくなります。

const crypto = require("crypto");

function verify(req, rawBody, secret) {
  const header = req.headers["x-hub-signature"];
  if (!header) return false;
  const [algo, sig] = header.split("=");
  const mac = crypto.createHmac(algo, secret)
    .update(rawBody).digest("hex");
  const a = Buffer.from(sig, "utf8");
  const b = Buffer.from(mac, "utf8");
  return a.length === b.length && crypto.timingSafeEqual(a, b);
}

リース更新の運用設計｜有効期限切れで通知が黙って止まる事態を防ぐ

WebSubの購読は有効期限付きです。仕様はハブに期限の適用を義務付け、無期限の購読を発行できない内容です。期限が切れると通知は何のエラーも出さずに止まるため、購読者側で期限を保存し、切れる前に同じ内容で再申し込みする処理を組みます。仕様のセキュリティ節は短い期間を勧めており、10日程度が良い既定として挙げられています。

あわせて、最後に通知を受けた時刻を購読ごとに記録し、想定間隔を大きく超えたら警告を出す監視を置きます。届かないことは正常系と区別が付かないため、沈黙を検知する仕組みを用意しないと障害に気付けません。

重複配信への備え方｜同じ更新が2度届く前提で安全な受信側を作る

ハブは応答が得られない場合に再送します。そのため同じ更新が複数回届く前提で、受信処理には冪等性を担保する設計を入れます。フィードのエントリIDや更新日時をキーに、処理済みなら握りつぶす形が扱いやすい方法です。

受信側が重い処理を同期で走らせると、ハブ側のタイムアウトで再送が増えて悪循環になります。受け取ったら即座に2xxを返してキューへ積み、後段の処理はリトライパターンの考え方で組み立てるのが定石です。

WebhookとWebSubの違い｜通知先を誰が決めるかで役割が分かれる

この2つは同じ「更新を投げてもらう仕組み」に見えますが、決定権の所在が違います。

通知先の決定権の所在｜受け取り側が自分で申し込めるかを分ける判断基準

一般的なWebhookは、通知を送る側の管理画面に受け取り先URLを登録して成立します。つまり送り先を決めるのは発行側で、受け取りたい人が勝手に増えることはありません。WebSubでは購読者がハブへ申し込むだけで購読が成立するため、発行者の手を借りずに受信者が増えていきます。不特定多数へ公開フィードを配る場面で効くのはこの性質です。

使い分けの目安｜1対1の連携ならWebhookのほうが手数が少ない

受け取る相手が自社の1システムだけなら、ハブを挟む必要はありません。Webhookで通知を送る構成のほうが、購読管理も期限更新も要らず運用が軽く済む構成です。逆に、社外の複数の相手が自分の判断で購読を始めたり止めたりする世界を作りたい場合に、WebSubの決定権の置き方が生きます。イベント駆動の連携全体を仕様として書き残したい場合は、AsyncAPIによる仕様記述と組み合わせる形になります。

WebSocketやMQTTとの使い分け｜接続の持ち方と通信の向きで選ぶ

更新を早く知る手段は他にもあります。判断軸は、接続を持ち続けるか、通信が双方向かの2つです。

接続の持ち方｜常時接続を持たずにHTTPだけで完結するかどうか

WebSubは通知のたびに新しいHTTPリクエストが飛ぶ方式で、購読者側はWebサーバさえあれば受けられます。WebSocketによる双方向通信は接続を張り続けるため、切断検知や再接続の実装が要る代わりに、遅延はミリ秒単位まで詰められます。画面へ即座に反映したい対話的な機能はWebSocket、分単位の遅れが許される更新配信はWebSubという住み分けです。

配信保証の粒度｜到達確認や順序が要るならメッセージ基盤を選ぶ

WebSubの仕様は到達保証や順序保証を定めていません。MQTTのQoSによる配信品質や、AMQPのルーティングと確認応答は、この部分を設計できるように作られています。取引データのように欠落が許されない流れは専用のメッセージ基盤へ寄せ、公開フィードの更新通知のように取り逃しても次の取得で回復できるものをWebSubへ回す、という切り分けが実務的です。

WordPressのWebSub｜更新通知でクロール要求を送る使われ方

日本語で検索したときに最初に出てくるのは、プロトコルの解説ではなくWordPressプラグインの設定手順です。ここは期待値を正確に把握しておく価値があります。

プラグインの実体と役割｜記事公開時に既定の3つのハブへ通知を送る仕組み

公式ディレクトリにある「WebSub (FKA. PubSubHubbub)」は、2026年8月時点でバージョン4.0.1、有効インストール10万以上のプラグインです。入れると自分のサイトのフィードにハブのLink情報が付き、記事を公開したタイミングでハブへ更新が知らされます。既定で通知先に入っているのは、Google App Engine上のデモハブ、SuperFeedr、WebSubHubの3つです。

期待できる効果｜クロールの入口が増えるだけで順位の約束はない

フィードの更新をハブ経由で知らせると、そのハブを購読しているサービスへ更新が伝わります。結果としてクローラが早く来る余地は生まれますが、これはインデックス登録や順位を約束するものではありません。設定して数字が動かないという相談の多くは、この前提の取り違えです。検索経由の成果を動かしたいなら、通知の経路より本文と内部リンクの設計を先に見直す順序になります。

身近な採用例｜YouTubeの新着通知も同じ仕組みで配られている

プラットフォーム側の例では、YouTube Data APIのプッシュ通知がこのプロトコルを使っています。チャンネルIDを含むフィードURLをトピックとして、Googleが運用するハブへ購読を申し込むと、新しい動画が公開されたときにコールバックへAtom形式の通知が届く作りです。チャンネルの新着を監視する処理を、数分おきのフィード取得から置き換えられます。

採用の条件と見送る場面｜ハブ運用の手間に見合う境界線をどこに引くか

ここまでの整理を、受託開発で判断するときの条件へ落とします。

採用する条件｜公開フィードと不特定の購読者がそろっている場合

採るのは次の条件が重なるときです。配りたい対象がHTTPで公開されたURLとして存在すること、購読者が複数いて今後も増える見込みがあること、更新が疎でポーリングの空振りが目立つこと、そして購読者側にHTTPSで到達できるエンドポイントを置けること。この4つがそろえば、発行側の負荷を増やさずに配信範囲を広げられます。

ハブは既存の公開ハブを使えば自前運用は要りません。自前で建てるのは、購読者の一覧や配信ログを自社で握る必要がある場合に限ります。その場合は購読管理・再送・スケールを自分で実装することになるため、要件として明示的に見積もりへ載せます。

導入を見送る場面｜コールバックを外部公開できない連携には向かない理由

見送るのは、受け取り側がインターネットから到達できない閉じたネットワークにある場合、通知の欠落が業務事故に直結する場合、そして相手が1社1システムに固定されている場合です。最初の2つは仕組みとして噛み合わず、3つ目は素直にWebhookで組んだほうが総手数が少なくなります。秒単位で更新が連続するデータも、通知が飽和して意味を失うため対象外です。

どちらに倒すか迷う場合は、購読者が今後増えるかどうかを起点に決めると判断がぶれません。連携先の増え方が読めない段階の設計や、既存システムへの通知基盤の組み込みは、API開発・システム連携としてご相談を承っています。

よくある質問

ハブは自分で用意しないと使えませんか？

公開されているハブを指定すれば自前運用は不要です。WordPressプラグインが既定で使うようなハブを指すLink情報をフィードに載せるだけで、発行側の準備は済みます。自前で建てるのは、購読者の一覧や配信の記録を自社で保持したい場合に限られます。

RSSやAtomのフィードは不要になりますか？

いいえ、フィードは引き続き必要です。WebSubが配るのは「そのURLが更新された」という通知と内容であり、対象となるURLそのものは発行側が公開し続けます。フィードをやめるとトピックが消えるため、購読の対象がなくなります。

通知の本文に更新内容は含まれますか？

仕様では、ハブが取得したトピックの内容がPOSTの本文として配られます。ただし差分だけを送るか全体を送るかはハブの実装によって差があるため、購読側は本文を信頼しきらず、必要に応じてトピックURLを取得し直す作りにしておくと安全です。

署名がsha1のハブでも使って問題ありませんか？

仕様はsha1・sha256・sha384・sha512を認識対象としており、古い購読者との相互運用のためsha1が広く残っていると明記しています。受け取る側はアルゴリズム名を見て検証方式を切り替え、選べる立場ならsha256以上に対応したハブを選ぶ、という運用にします。

購読していたのに通知が来なくなるのはなぜですか？

多くはリース期限の切れです。ハブは無期限の購読を発行できないため、期限前に再申し込みしなければ通知は静かに止まります。購読ごとに期限と最終受信時刻を保存し、更新処理と沈黙の監視を組んでおくと再発を防げます。

関連記事

• Incoming Webhookとは？WebhookとAPIの違い・Slack/Discordでの使い方
• AsyncAPIとは？OpenAPIとの違いと3.0仕様・イベント駆動APIの設計を実装目線で解説
• WebSocketとは？仕組み・ハンドシェイクからNode.js実装・運用の判断まで実装者向けに解説
• MQTTとは？Pub/Subの仕組み・QoS・MQTT 5.0の実装からHTTPとの使い分けまで実装者向けに解説
• AMQPとは？0-9-1と1.0の違い・ルーティングの仕組みと採用判断を実装者向けに解説
• 冪等性とは？読み方・意味からAPI・IaCでの担保方法まで実装者向けに解説
• リトライパターンとは？指数バックオフ・ジッター・リトライ予算の実装判断を解説