Webhookは通知には適しているが、データ同期（レプリケーション）のプロトコルに適さない：SCROLLとBraid-HTTP Subscriptionsの提案 #八06 #2007五03WebHookとユーザ定義コールバック

この文章は、「Webhookは通知には適しているが、データ同期（レプリケーション）のプロトコルとしては根本的に設計が間違っている」という問題提起です。単なるWebhook批判ではなく、新しい同期プロトコルであるSCROLLを提案する技術エッセイになっています。

要約

著者は、異なる3社・3つのSaaSプロバイダーとの連携システムを構築する中で、毎回ほぼ同じ苦労を繰り返したと述べています。外部サービスが顧客情報の正本（Source of Truth）を保持しているため、自社側ではWebhookを利用してそのコピーを維持しようとしました。

当初は単純にWebhookを受け取り、JSONをデータベースへ反映するだけの仕組みを想定していました。しかし実際には、

Webhook署名検証
冪等性確保
重複イベント排除
イベント順序の補正
初期データ取得（ブートストラップ）
ロック処理
リプレイ機構
差分同期用cron

など、多数の補助機構を追加する必要がありました。

その結果、「Webhook受信エンドポイント」ではなく、小さな分散システムを構築することになってしまったのです。

なぜcronが必要になるのか

最も大きな問題は、

「コピーが本当に正しいか分からない」

ことです。

例えば

Webhookが途中で失われる
再送が失敗する
プロバイダー側でイベントが消失する
イベント順序が前後する

といった障害は珍しくありません。

しかし利用者側では

「イベントが届かなかった」

こと自体を検知できません。

そのため夜間に

Provider API
        ↓
全件取得
        ↓
ローカルDB
        ↓
差分比較
        ↓
修正

というcronジョブを永続的に回すしかありません。

つまりcronは便利だからではなく、

Webhookを信用できないための保険

になっています。

Webhookは通知であって同期ではない

著者が到達した結論は非常にシンプルです。

Webhookとは

「何か起きました」

という通知です。

通知なので

メール送信
Slack通知
キャッシュ削除

には非常に向いています。

しかし

「顧客DBを完全に複製する」

用途には向いていません。

レプリケーションには必要な性質

データ同期には少なくとも

完全性
順序性
再取得
ブートストラップ
整合性検証

が必要です。

Webhookはこれらを保証しません。

だから

デダップ
リプレイ
バッファ
冪等処理

などが全部必要になります。

著者はこれを

Webhookはレプリケーション用途における局所最適（Local Optimum）

と表現しています。

実はプロバイダーは全部持っている

ここが記事で一番面白い指摘です。

StripeでもGitHubでもShopifyでも

イベント画面があります。

そこには

Event1
Event2
Event3
Event4

が順番に並んでいます。

つまり

プロバイダー内部には

完全なイベントログ

が最初から存在します。

Webhookとは

イベントログ
      ↓

HTTP POST

HTTP POST

HTTP POST

へ切り刻んで送っているだけなのです。

著者はこれを

ジグソーパズルの完成図を持っている人が、
ピースだけをランダムに送り、
足りなくても教えてくれない

ことに例えています。

提案：変更フィード

理想は

GET /changes?cursor=12345

だけです。

返ってくるのは

1
Customer A

2
Customer B

3
Customer C

という

順序付き変更ログ

です。

これなら

for event in feed:

UPSERT

だけで済みます。

削除も

DELETE

イベントを流せばよい。

順序保証もある。

欠落もしない。

チェックサムまで返せばさらに良い

著者が提案しているのは

GET /changes

↓

...

cursor=1000

count=28391

checksum=abcd1234

のような応答です。

すると受信側は

自分の件数

28391

？

OK

チェックサム一致

↓

同期完了

と検証できます。

現在のWebhookでは

この検証手段がありません。

だからcronが必要になります。

SCROLLとは

この考えをプロトコル化したものが

SCROLL

（Synchronized Change Replication Over Line Logs）

です。

主な構成は

順序付きフィード
Cursor
Checkpoint
Tombstone（削除）
Retention
Streaming
Polling

など。

つまり

Webhookではなく

CDC（Change Data Capture）

に近い考え方です。

実は既に似た仕組みは存在する

著者の発想は新奇というより、

複数の成熟した分散システムの考え方をWeb APIへ持ち込んだものです。

例えば

システム	考え方
Kafka	Append-only Log
EventStoreDB	Event Sourcing
Debezium	CDC
PostgreSQL Logical Replication	WAL同期
DynamoDB Streams	Change Feed
Cosmos DB Change Feed	Change Feed
Kafka Connect	レプリケーション

つまり

企業内では当たり前になっている

変更ログ同期

を

SaaS APIにも適用しよう

という提案なのです。

この提案が示すもの

この記事は、「Webhookを改善しよう」という話ではありません。

通知（Notification）とレプリケーション（Replication）は別物であり、現在のSaaS APIは両者を混同しているという設計上の問題を指摘しています。

そのためSCROLLはWebhookの代替というよりも、外部サービスとのデータ同期を、データベースの論理レプリケーションやCDCのように扱うための共通プロトコルを目指した提案と位置付けられます。

もしこうした仕組みが広く普及すれば、現在多くの開発者が実装している署名検証、冪等性処理、重複排除、順序補正、差分同期cronといった「Webhook周辺の定型実装」の多くが不要になり、SaaS連携は現在よりもはるかに単純で信頼性の高いものになる可能性があります。　これは、Webhook を状態同期に使う際の問題点を整理した議論の要約であり、提案された解決策として SCROLL という疑似 IETF スタイルのプロトコル草案が紹介され、同様の実装を目指す正式な IETF ドラフト「Braid-HTTP サブスクリプション」との類似点が指摘されている。両者とも GET リクエストと特定ヘッダーでサブスクリプションを要求し、サーバー側が応答を開いたままにして後続の状態更新をストリーム配信する方式を取るため、Webhook の代替として長いポーリングやサーバー送信イベント（SSE）に近い挙動を示すが、Braid は application/http 履歴のような多様なメディアタイプをサポートする点で拡張性がある。著者はこうした仕組みを単に個別実装のまま放置するのではなく、HTTP 標準自体に取り込み、既存のライブラリやツールチェーンに組み込むことで再実装の重複を避け、汎用的な状態同期を実現すべきだと主張している。そしてそのためには IETF を通じて HTTP の拡張として正式化する必要があると述べる。　読者からは接続を常時開いたままにする設計に対する疑問や、サーバーが大量のクライアント接続を抱える負荷の懸念、WebSocket や SSE といった既存技術との比較、そして Linked Data Event Streams（LDES）のような既存標準で十分ではないかという指摘が寄せられている。投稿者は /scroll/ のような専用 URL を必須とはしておらず、提案の一例に過ぎないと訂正している。また、不動産業界の一部では同様の仕組みが実装済みであることが指摘され、SCROLL と似たアプローチが既に使われている領域があることが示される。　実運用に関する議論では、QuickBooks などの実例を挙げて API レスポンスや Webhook を全面的に信頼できない問題が指摘される。作成操作が実際には成功しているのにエラーが返されたり、バックグラウンド処理で更新が遅延して整合性チェックが困難になったりする事例が述べられ、これが原因で消費者側が永続的に同期に追われる「追いつけない」状態に陥ることが問題視されている。サポート側が「正しく作成されたかどうかを確認するのはあなたの仕事だ」と応じるような姿勢も批判され、なぜ信頼できないシステムを受け入れてきたのかという根本的な問いが投げかけられている。　さらに、イベント配信や状態同期に関する設計上の失敗要因として、トランザクション完了とレスポンス生成の間にアプリケーションインスタンスがクラッシュすることや、バックエンドの内部処理が完了していないのにクライアントが照会してしまうこと、ネットワークの再試行や重複配信などによる状態の重複や欠損が常に発生し得ることが挙げられている。これらはソフトウェア設計の配慮だけで完全には防げない問題であり、設計側と消費者側がそれぞれフォールトトレランスや再試行・調停の仕組みを担う必要があるという認識が示されている。　一部の参加者は、複数サービス間での合意や状態遷移の検証が重要なケースでは、許可制ブロックチェーンのような合意を前提としたシステムを検討すべきだと提案するが、多数の反論もある。ほとんどの場合、データの単一のソースが存在し状態遷移が任意であるため、ブロックチェーンは適切な解とはならないこと、またプライベートなブロックチェーンを持ち出すことは既存の分散データベースや従来のレプリケーション手法で代替可能であり、ブロックチェーンは過剰な複雑性や制約をもたらすだけだという指摘がなされる。連続性や順序性を暗号的に検証する必要性を疑問視する意見もあり、多くの顧客は暗号的検証よりも運用上の信頼や性能を重視するという現実的な視点が示されている。　また、Webhook の採用率が高い一方で、より高度なエンドポイントを提供しても消費者にあまり採用されない実態が共有され、Webhook が事実上のリンガフランカ（共通語）になっているため、提供者側が相応の実装労力を負わない限り新プロトコルは普及しにくいとの現実的な意見が出ている。これを受けて、消費者側の課題を解決する商機として、一般的なアプリケーションフレームワークやホスティング環境に簡単に統合できる、ポーリングやソケットを使ったイベント消費ランタイムを提供するサービスが有望だという見解も示される。　最後に、問題の核心としては、イベント配信や状態同期の信頼性・スケーラビリティ・運用負担の配分というトレードオフがあり、技術的なプロトコル提案（SCROLL や Braid）だけでなく、標準化とエコシステムへの組み込み、そして実運用での責任分担と運用ツールの整備が揃って初めて現実的な改善が期待できる、という総合的な結論が導かれている。この議論は、Webhookの限界を単なる実装論ではなく、「HTTPにおける状態同期プロトコルの欠如」という標準化の問題として捉え直したものです。SCROLLという提案を起点に、IETFで議論されているBraid-HTTPや既存技術との比較、さらには運用・普及まで含めた包括的な議論へ発展しています。

要約

著者が提案した**SCROLL（Synchronized Change Replication Over Line Logs）**は、Webhookを「通知」から「状態同期」へ置き換えるためのプロトコル案です。

一方、読者からは

「似たものは既にIETFで議論されている」

という指摘があり、

Braid-HTTP Subscriptions

という正式なIETFドラフトとの共通点が紹介されました。

両者とも

GET

↓

接続維持

↓

状態更新を順番に送る

というモデルを採用しています。

つまり

Webhookのように

POST
POST
POST

を繰り返すのではなく、

一本のHTTP接続上で変更を流し続ける方式です。

SCROLLとBraidは何が違うのか

基本思想は非常によく似ています。

どちらも

クライアントがGETする
サーバが変更を順番に送る
クライアントはカーソルを保持する

という構造です。

しかしBraidは

HTTPそのものを拡張しようとしています。

例えば

Subscribe: true

のようなHTTPヘッダーだけで

サブスクリプションを開始できます。

さらに

application/http

など

複数のメディアタイプも扱えます。

つまり

SCROLLが

「変更フィードAPI」

なら

Braidは

「HTTPそのものの進化」

を目指しています。

なぜ標準化したいのか

著者の主張は

かなり重要です。

現在

Stripe

GitHub

Shopify

Salesforce

など

全員が

独自Webhook

独自SDK

独自再試行

独自ログ

を書いています。

つまり

Provider A

Webhook

Provider B

Webhook

Provider C

Webhook

です。

しかし

もし

HTTP標準が

変更ストリームを持てば

ライブラリも

ブラウザも

SDKも

全部共通になります。

つまり

再実装を減らせます。

「接続を開きっぱなし」は大丈夫なのか

コメント欄では

最初にここが疑問視されています。

何万ユーザーもいたら

HTTP接続を保持し続けるのは

重いのでは？

という話です。

これに対しては

既に

SSE
HTTP/2
HTTP/3
gRPC Streaming

などが

同じ問題を解決しています。

つまり

「開きっぱなし」

自体は

現在では特別珍しい設計ではありません。

WebSocketとの差

WebSocketも

似ています。

しかし

WebSocketは

双方向通信です。

SCROLLやBraidは

基本的に

Server

↓

Client

だけです。

つまり

SSEに近い。

HTTPの意味論も保ちやすい。

LDESでも良いのでは？

一部読者は

Linked Data Event Streams

を挙げています。

LDESも

イベント列です。

しかし

LDESは

Semantic Web

Linked Data

RDF

前提です。

SCROLLは

もっと

JSON API

向けです。

つまり

対象が違います。

QuickBooks問題

コメントで

非常に現実的な例が出ています。

例えば

POST

↓

500 Error

しかし

実際には

レコードは作成済み。

すると

利用者は

成功？

失敗？

が分かりません。

だから

もう一度

GETします。

すると

反映されていない。

でも

10秒後には

存在している。

つまり

内部で

非同期処理

になっています。

このようなAPIは

実際にかなりあります。

「同期」は実は非常に難しい

記事でも議論されていますが

例えば

DB Commit

した直後に

アプリがクラッシュ。

すると

DBにはある。

Webhookは送れない。

逆もあります。

Webhook送った。

DB Rollback。

これも起こる。

つまり

分散システムでは

完全一致

は

かなり難しい。

だから

再試行

冪等

補償処理

が必要になります。

ブロックチェーン案

途中で

「ブロックチェーンなら？」

というコメントもあります。

しかし

多くの人が否定しています。

理由は

今回の問題は

単一ソース

だからです。

Stripeなら

Stripe

GitHubなら

GitHub

だけが

正しい。

つまり

合意形成

はいらない。

欲しいのは

変更ログ

だけです。

これは

普通の

CDC

で十分です。

なぜWebhookが勝ってしまったのか

興味深いコメントがあります。

Webhookは

実は

技術的には

最良ではありません。

しかし

みんな

Webhookを書く。

つまり

リンガフランカ

になっています。

プロバイダー側も

Webhookなら

みんな使える

ので

他方式を作りません。

典型的な

ネットワーク効果です。

新しいビジネスチャンス

ある読者は

逆に

ここに市場があると言っています。

つまり

開発者は

毎回

同期処理を書きたくない。

だから

SCROLL Runtime

Webhook Runtime

Change Feed Runtime

のような

ミドルウェアを

SaaSとして提供すれば

需要がある

という話です。

これは

Kafka Connect

Debezium

Airbyte

などの思想にも近いです。

この議論の本質

この議論は、Webhookの改善策を議論しているだけではありません。より本質的には、インターネット上でサービス間の「状態同期」を行うための共通プロトコルが存在しないという問題を浮き彫りにしています。

現在のWebhookは「通知」を届ける仕組みとしては十分に成功しました。しかし、「あるサービスの状態を別のサービスへ正確かつ継続的に複製する」という用途には、順序保証、完全性、ブートストラップ、整合性検証といった要件を満たしていません。その不足を埋めるために、各プロバイダーも各利用者も独自の署名検証、冪等処理、再試行、差分同期、監査ツールを何度も実装しています。

SCROLLやBraidは、この状況をデータベースの論理レプリケーションやCDC（Change Data Capture）の考え方をHTTPへ持ち込み、状態同期をWebの標準機能へ昇華しようという試みです。

もっとも、技術的に優れたプロトコルを設計するだけでは普及しません。Webhookが現在の「共通語」になっている背景には、実装の容易さとエコシステムの成熟があります。そのため、実際の改善には、

標準化（IETFなど）
HTTPライブラリやフレームワークへの組み込み
クラウド・ホスティング環境での標準サポート
運用・監査・再同期ツールの整備

まで含めたエコシステム全体の発展が不可欠です。

言い換えれば、この議論はWebhookの代替技術を提案しているというより、HTTPにおける「状態同期」をTCPが提供する信頼性やHTTPが提供するリクエスト/レスポンスと同じレベルの基盤機能へ引き上げるべきではないかという、より大きなアーキテクチャ上の問題提起だと言えるでしょう。　これは、Webhook を状態同期に使う際の問題点を整理した議論の要約であり、提案された解決策として SCROLL という疑似 IETF スタイルのプロトコル草案が紹介され、同様の実装を目指す正式な IETF ドラフト「Braid-HTTP サブスクリプション」との類似点が指摘されている。両者とも GET リクエストと特定ヘッダーでサブスクリプションを要求し、サーバー側が応答を開いたままにして後続の状態更新をストリーム配信する方式を取るため、Webhook の代替として長いポーリングやサーバー送信イベント（SSE）に近い挙動を示すが、Braid は application/http 履歴のような多様なメディアタイプをサポートする点で拡張性がある。著者はこうした仕組みを単に個別実装のまま放置するのではなく、HTTP 標準自体に取り込み、既存のライブラリやツールチェーンに組み込むことで再実装の重複を避け、汎用的な状態同期を実現すべきだと主張している。そしてそのためには IETF を通じて HTTP の拡張として正式化する必要があると述べる。　読者からは接続を常時開いたままにする設計に対する疑問や、サーバーが大量のクライアント接続を抱える負荷の懸念、WebSocket や SSE といった既存技術との比較、そして Linked Data Event Streams（LDES）のような既存標準で十分ではないかという指摘が寄せられている。投稿者は /scroll/ のような専用 URL を必須とはしておらず、提案の一例に過ぎないと訂正している。また、不動産業界の一部では同様の仕組みが実装済みであることが指摘され、SCROLL と似たアプローチが既に使われている領域があることが示される。　実運用に関する議論では、QuickBooks などの実例を挙げて API レスポンスや Webhook を全面的に信頼できない問題が指摘される。作成操作が実際には成功しているのにエラーが返されたり、バックグラウンド処理で更新が遅延して整合性チェックが困難になったりする事例が述べられ、これが原因で消費者側が永続的に同期に追われる「追いつけない」状態に陥ることが問題視されている。サポート側が「正しく作成されたかどうかを確認するのはあなたの仕事だ」と応じるような姿勢も批判され、なぜ信頼できないシステムを受け入れてきたのかという根本的な問いが投げかけられている。　さらに、イベント配信や状態同期に関する設計上の失敗要因として、トランザクション完了とレスポンス生成の間にアプリケーションインスタンスがクラッシュすることや、バックエンドの内部処理が完了していないのにクライアントが照会してしまうこと、ネットワークの再試行や重複配信などによる状態の重複や欠損が常に発生し得ることが挙げられている。これらはソフトウェア設計の配慮だけで完全には防げない問題であり、設計側と消費者側がそれぞれフォールトトレランスや再試行・調停の仕組みを担う必要があるという認識が示されている。　一部の参加者は、複数サービス間での合意や状態遷移の検証が重要なケースでは、許可制ブロックチェーンのような合意を前提としたシステムを検討すべきだと提案するが、多数の反論もある。ほとんどの場合、データの単一のソースが存在し状態遷移が任意であるため、ブロックチェーンは適切な解とはならないこと、またプライベートなブロックチェーンを持ち出すことは既存の分散データベースや従来のレプリケーション手法で代替可能であり、ブロックチェーンは過剰な複雑性や制約をもたらすだけだという指摘がなされる。連続性や順序性を暗号的に検証する必要性を疑問視する意見もあり、多くの顧客は暗号的検証よりも運用上の信頼や性能を重視するという現実的な視点が示されている。　また、Webhook の採用率が高い一方で、より高度なエンドポイントを提供しても消費者にあまり採用されない実態が共有され、Webhook が事実上のリンガフランカ（共通語）になっているため、提供者側が相応の実装労力を負わない限り新プロトコルは普及しにくいとの現実的な意見が出ている。これを受けて、消費者側の課題を解決する商機として、一般的なアプリケーションフレームワークやホスティング環境に簡単に統合できる、ポーリングやソケットを使ったイベント消費ランタイムを提供するサービスが有望だという見解も示される。　最後に、問題の核心としては、イベント配信や状態同期の信頼性・スケーラビリティ・運用負担の配分というトレードオフがあり、技術的なプロトコル提案（SCROLL や Braid）だけでなく、標準化とエコシステムへの組み込み、そして実運用での責任分担と運用ツールの整備が揃って初めて現実的な改善が期待できる、という総合的な結論が導かれている。**SCROLL（Synchronized Change Replication Over Line Logs）**は、Webhookを「通知プロトコル」から「状態同期（レプリケーション）プロトコル」へ置き換えることを目指した提案です。一方、Braid-HTTPはHTTPそのものを拡張して、購読（Subscription）と状態更新を標準化しようとするIETFドラフトです。

両者は「HTTP GETで変更ストリームを受け取る」という点で非常によく似ていますが、目指す範囲が異なります。

SCROLLとは

SCROLLは

Synchronized Change Replication Over Line Logs

の略称です。

発想は非常にシンプルです。

現在のWebhookは

イベント発生

↓

HTTP POST

↓

受信側で再構築

ですが、

SCROLLでは

変更ログ

↓

GET /changes

↓

順番通り取得

↓

ローカルへ適用

へ変えます。

つまり

**「通知」ではなく「変更履歴」**を配信します。

SCROLLの基本構成

SCROLLではプロバイダーは

Customer A 更新

Customer B 更新

Customer C 削除

Customer D 更新

という

Append-only Log

を持っています。

クライアントは

GET /changes?cursor=1523

を送ります。

すると

[
 {
   "cursor":1524,
   "type":"upsert",
   "customer":{...}
 },
 {
   "cursor":1525,
   "type":"delete",
   "id":"abc"
 }
]

が返ってきます。

受信側は

UPSERT

UPSERT

DELETE

するだけです。

SCROLLの特徴

SCROLL草案では

Cursor
Checkpoint
Tombstone
Retention
Streaming
Polling

などを定義しています。

つまり

Webhookで毎回実装している

デダップ
順序調整
ブートストラップ

を

プロトコル側で解決

しようとしています。

SCROLLが目指す世界

現在

Webhook

↓

冪等処理

↓

デダップ

↓

順序補正

↓

cron同期

ですが

SCROLLでは

GET

↓

イベント適用

↓

終わり

になります。

これは

データベースの

Logical Replication

そのものです。

Braidとは

一方

Braid-HTTPは

もっと大きな話です。

Braidは

HTTP自体をリアルタイム同期対応にする

ことを目指しています。

つまり

HTTP GETが

一回で終わるのでなく

そのまま

になります。

例えば

GET /customers

Subscribe: true

のような

HTTPヘッダーを付けます。

すると

レスポンスは閉じません。

更新があるたび

変更

変更

変更

を

同じHTTPレスポンスで送り続けます。

Braidの特徴

Braidは

単なるJSON変更ログではありません。

例えば

JSON
application/http
Patch
HTML

など

様々なメディア型を扱えます。

つまり

HTTPの上位互換

を目指しています。

SCROLLとBraidの思想

SCROLLは

レプリケーション

が目的です。

Braidは

HTTP購読

が目的です。

この違いがあります。

比較表

項目	SCROLL	Braid
主目的	状態同期（レプリケーション）	HTTPサブスクリプション
想定用途	SaaSデータ同期	一般HTTP同期
プロトコル	新しい変更フィード仕様	HTTP拡張
通信方式	GET + Cursor	GET + Subscribe
接続	Polling / Streaming	Streaming
順序保証	重視	実装依存
Cursor	必須	実装可能
Tombstone	明示	任意
Checkpoint	想定	任意
Checksum	想定	規定なし
Bootstrap	プロトコル設計に含む	アプリケーション依存
主対象	レプリカ維持	リアルタイム更新全般

共通点

両者とも

Webhookを

Push Notification

ではなく

State Stream

へ変えようとしています。

つまり

発想はかなり近いです。

一番大きな違い

SCROLLが考えているのは

データベース

です。

つまり

Stripe Customer

↓

自社DB

の同期です。

一方

Braidは

もっと一般的です。

例えば

ブラウザが

GET /document

すると

文書が更新され続けてもいい

という世界です。

つまり

HTTP版WebSocket

に近い考えです。

SCROLLはCDCに近い

SCROLLを見ると

非常によく似ているものがあります。

それは

Change Data Capture

です。

例えば

技術	類似点
PostgreSQL Logical Replication	WALを順番に送る
Debezium	DB変更ログを配信
Kafka	Append-only Log
Cosmos DB Change Feed	Cursor付き変更取得
DynamoDB Streams	順序付き変更配信

SCROLLは

これらを

HTTP API向け

に一般化したものと言えます。

BraidはHTTPの未来を目指している

Braidは

HTTPを

Request

↓

Response

↓

終了

から

Request

↓

Response

↓

更新

↓

更新

↓

更新

へ進化させようとしています。

つまり

HTTP/RESTの次の世代

を目指しています。

将来性

現在（2026年時点）の視点では、SCROLLとBraidは競合というより補完的です。

SCROLLは「SaaSやクラウドAPIのデータ同期」を標準化することに重点を置いています。
Braidは「HTTPそのものをリアルタイム更新可能なプロトコルへ拡張する」ことを目指しています。

そのため、将来的にはBraidの通信・購読メカニズムの上でSCROLLのような変更ログ（カーソル、トゥームストーン、チェックポイント、整合性検証）を流すという組み合わせも十分考えられます。

言い換えれば、

Braidは「道路（通信基盤）」
SCROLLは「道路を走る変更ログ配送ルール（レプリケーション仕様）」

という関係で捉えると、両者の役割の違いが理解しやすいでしょう。Web技術の歴史を振り返ると、「通知（Notification）」と「同期（Synchronization）」はしばしば同じように扱われてきましたが、本来は目的が異なります。近年のSCROLLやBraidの議論は、この2つを明確に区別しようとする流れと見ることができます。

通知と同期の違い

項目	通知（Notification）	同期（Synchronization）
目的	「何かが起きた」と知らせる	同じ状態を維持する
保証	通知できればよい	完全性・順序・整合性が必要
順序	必須ではない	必須
欠落	許容される場合がある	許容されない
例	メール通知、Webhook	データベースレプリケーション、変更フィード

例えば、

注文が入りました

という通知だけでは、

注文データ

そのものは同期されません。

同期では

現在の注文一覧

を一致させることが目的になります。

Web技術の歴史

第1世代：ポーリング（1990年代〜）

クライアントが定期的に

GET /status

を繰り返します。

Client

↓

GET

↓

Server

↓

Response

特徴

実装が簡単
遅い
無駄な通信が多い

通知というより

状態確認です。

第2世代：RSS・Atom

RSS や Atom は、

更新された記事だけを取得します。

Feed

↓

新記事

これは

実は

変更フィード

という意味では

SCROLLにかなり近い考えです。

ただし

用途は

ニュース配信でした。

第3世代：Long Polling

HTTP接続を閉じず

更新が来るまで待ちます。

GET

↓

待機

↓

更新

↓

Response

チャットなどで普及しました。

第4世代：Comet

Ajax時代の

リアルタイム通信です。

ブラウザの制約を

回避していました。

現在は

ほぼ役目を終えています。

第5世代：WebSocket

HTML5で登場した

双方向通信です。

Client

⇅

Server

特徴

超高速
双方向
チャット
ゲーム

しかし

同期プロトコルではありません。

第6世代：Server-Sent Events（SSE）

サーバだけが

送り続けます。

Server

↓

↓

↓

Client

WebSocketより

シンプルです。

SCROLLやBraidとも

近い構造です。

第7世代：Webhook

2010年代以降

SaaSで爆発的に普及しました。

Stripe

↓

POST

↓

自社

特徴

イベント通知
Push型
RESTと相性が良い

しかし

これは

通知

です。

同期ではありません。

第8世代：CDC

企業システムでは

Change Data Capture

が一般化しました。

例

PostgreSQL Logical Replication
MySQL Binlog
Debezium
Apache Kafka Streams

ここでは

変更ログ

そのものを送ります。

同期が目的です。

第9世代：Change Feed API

クラウドでは

Cosmos DB

↓

Change Feed

DynamoDB

↓

Streams

など

HTTPに近い形で

変更取得できます。

SCROLLは

これを

一般APIへ持ち込もう

という発想です。

第10世代：SCROLL

SCROLLでは

GET /changes

↓

Cursor

↓

変更

↓

変更

↓

変更

になります。

通知ではなく

状態同期です。

第11世代：Braid

Braidでは

HTTPそのものが

GET

↓

更新

↓

更新

↓

更新

になります。

つまり

HTTPの進化です。

技術の系譜

Polling
    │
    ▼
RSS / Atom
    │
    ▼
Long Polling
    │
    ▼
Comet
    │
    ▼
WebSocket
    │
    ├───────────────┐
    ▼               ▼
Server-Sent Events  Webhook
                        │
                        ▼
             Event Streaming
                        │
                        ▼
                  Change Feed
                        │
                        ▼
                  SCROLL
                        │
                        ▼
                    Braid

「通知」と「同期」は別物

現在のWebでは

通知系	同期系
Webhook	CDC
Push通知	PostgreSQL Logical Replication
メール通知	Debezium
Slack通知	Kafka Streams
GitHub Webhook	Cosmos DB Change Feed

という住み分けがあります。

SCROLLが問題提起しているのは、

Webhook（通知）をデータ同期に流用してきたこと自体が、本質的な設計上のミスマッチではないか

という点です。

今後の展望

Webアプリケーションの発展を見ると、「通知」は十分に標準化されましたが、「同期」はデータベースやメッセージング基盤の世界に留まり、HTTP APIでは各サービスが独自実装を続けています。

SCROLLやBraidが目指しているのは、この状況を変え、「HTTPにおける状態同期」をHTTP GETやPOSTと同じくらい標準的な機能へ引き上げることです。もし普及すれば、Webhookごとに署名検証や再試行、差分調整を実装する現在の開発スタイルから、カーソル付き変更フィードを購読するだけで整合性を維持できる時代へ移行する可能性があります。これは、RESTがWeb APIを標準化したのと同じような転換点になり得る、という期待が背景にあります。以下は、通知（Notification）と同期（Synchronization）のWeb技術の発展を、インターネット黎明期から現在（2026年頃）まで時系列で整理したものです。

時期	技術	分類	主な用途	特徴	限界・課題
1990～1995年	HTTP Polling	同期（取得）	状態確認	定期的にGETして最新状態を取得	通信の無駄が多くリアルタイム性が低い
1999年	RSS 0.9	通知	ニュース配信	更新記事を配信するフィード	記事配信向けで状態同期ではない
2003年	Atom	通知	コンテンツ配信	RSSより仕様を整理・標準化	双方向同期は対象外
2004～2006年	Ajax Polling	同期	Webアプリ	ページ更新なしで部分取得	サーバ負荷が増えやすい
2005～2008年	Long Polling	通知	チャット・監視	更新があるまでHTTP接続を維持	接続管理が複雑
2006～2009年	Comet	通知	リアルタイムWeb	擬似Push通信	実装依存が大きい
2009年	Server-Sent Events (SSE)	通知	一方向Push	HTTPだけでサーバ→クライアント配信	クライアント→サーバ通信は不可
2011年	WebSocket	通知・同期	チャット・ゲーム	双方向・低遅延通信	データ整合性はアプリ側実装
2010年代	Webhook	通知	SaaS連携	イベント発生時にHTTP POST	順序・完全性・整合性保証がない
2011年頃～	Change Data Capture (CDC)	同期	DBレプリケーション	更新ログをそのまま配信	主にデータベース内部向け
2014年	Debezium	同期	CDC	DB変更をKafka等へ配信	DB中心でHTTP API向けではない
2014年	Apache Kafka	同期・イベント	イベントストリーミング	順序付きAppend-only Log	Web APIとは設計思想が異なる
2017年頃	Change Feed API（クラウドDB）	同期	クラウドDB	Cursor付き変更取得	データベースごとの独自仕様
2019年頃	GraphQL Subscriptions	通知	GraphQL API	WebSocket経由のリアルタイム更新	状態同期の保証はない
2020年代	GraphQL Live Query	同期	リアルタイムUI	クエリ結果を自動更新	実装が複雑で普及途上
2020年代	CRDT同期	同期	共同編集	分散環境でも競合を自動解決	実装・理解が難しい
2024～2026年	SCROLL（提案）	同期	SaaS API	Cursor付き変更フィードによるレプリケーション	草案段階で標準ではない
2024～2026年	Braid-HTTP（IETF Draft）	同期	HTTP全般	GETを継続接続化し状態更新を配信	標準化・普及はこれから

通知技術の系譜

世代	技術	キーワード
第1世代	RSS・Atom	Feed
第2世代	Long Polling	疑似Push
第3世代	Comet	HTTPストリーミング
第4世代	SSE	Server Push
第5世代	WebSocket	双方向通信
第6世代	Webhook	SaaSイベント通知

通知技術は

「何か起きたことを知らせる」

ことが目的です。

同期技術の系譜

世代	技術	キーワード
第1世代	HTTP Polling	定期取得
第2世代	DB Replication	主従同期
第3世代	CDC	変更ログ
第4世代	Kafka Streams	Event Log
第5世代	Change Feed API	Cursor
第6世代	CRDT	分散同期
第7世代	SCROLL	HTTP Change Feed
第8世代	Braid	HTTP Subscription

同期技術は

「同じ状態を維持する」

ことが目的です。

Web技術の進化を俯瞰

時代	中心技術	主眼
1990年代	Polling	「状態を取得する」
2000年代	RSS・Ajax・Comet	「更新を素早く知る」
2010年代	WebSocket・Webhook	「リアルタイム通知」
2020年代前半	CDC・Change Feed・Event Streaming	「変更ログを同期する」
2020年代後半	SCROLL・Braid	「HTTPレベルで状態同期を標準化する」

歴史的な見方

Web技術は長らく**通知（Notification）**を中心に発展してきました。RSSは記事更新、WebhookはSaaSイベント、WebSocketはリアルタイム通信を実現しましたが、いずれも「変化があったこと」を伝える仕組みが主眼でした。

一方、**同期（Synchronization）**はデータベースやイベントストリーミング基盤（レプリケーション、CDC、Kafkaなど）の世界で成熟してきたものの、HTTP APIの標準機能には取り込まれていませんでした。

SCROLLやBraidは、この二つの流れを統合し、HTTP APIでも「通知」ではなく「状態そのものを安全に同期する」ことを標準化しようとする試みとして位置付けられます。これは、RESTがWeb APIを標準化した後の、次の世代のWebアーキテクチャを模索する動きとも言えるでしょう。　結論として、Webhooksを「レプリケーションに不適」と断じる主張は方向性としては妥当だが、現状の議論は概念整理と具体的な論証が不足しているため不十分である。Webhookは本質的に「イベントをHTTPで配送する実装パターン」であって通知専用の規格ではないため、単体では堅牢なレプリケーションを担えない一方で、永続的なイベントログや再送、カーソル管理、冪等性などの仕組みと組み合わせればデータ同期の一部として機能し得る、という論点を中心に据えるべきである。　まずWebhookとレプリケーションは同一レイヤーの概念ではない点を明確にする必要がある。Webhookは配送メカニズム、イベント通知は届くべきメッセージ、データ同期はアプリケーションの目的、レプリケーションは整合性や復旧を含む仕組みであり、単にHTTP POSTでイベントを送るだけのWebhookはレプリケーションに不十分だが、Webhookを入口にして耐久キューや変更ログに格納する構成にすればレプリケーションパイプラインの一部になり得る。重要なのはHTTPか否かではなく、変更ログの永続性と購読者ごとの再開位置の管理である。　「通知」と「同期」の違いを形式的に整理すべきで、主目的や欠落の許容、重複・順序・再送・初期状態・削除の扱い、正しさの定義が異なることを示すべきである。イベントが届いたことと同期が完了したことは同じではなく、受信側がイベントを処理できなかった場合に同期状態を回復するためにはイベントの再取得、変更履歴の取得、スナップショット、シーケンス検出、送信側への再同期要求などの仕組みが必要になる。　配送保証についての議論が不足している点も指摘される。Webhook実装は典型的に at-most-once、at-least-once、best-effort、順序未保証、再送期間限定といった性質を持ち、受信側停止時の取りこぼしやタイムアウトと処理済みの区別不能といった問題がある。Stripeのような実例では再試行期間や重複・順序非保証が明記されており、これらはWebhookだけで一般的なレプリケーションに求められる耐久性・順序性・再開性を満たせないことを示す。　欠落検出の問題は深刻で、受信側が何かを受け取れていないことを検出できない限り同期は保証されない。単調増加のシーケンス番号や購読者ごとの位置管理、変更履歴の再取得API、履歴保持期間、フル再同期手段などが必要であり、議論の焦点は「通知能力」ではなく「変更履歴を参照する能力」にある。　初期同期と再同期の扱いも不可欠である。レプリケーションではスナップショット取得→スナップショット時点のログ位置記録→スナップショット投入→以降の変更を再生、という手順が標準であり、Webhookだけでは購読開始前や受信障害中のデータを再現できない可能性がある。実務では初期同期をSnapshot APIで行い、継続同期をWebhookでトリガーし、欠落回復はカーソル付き変更履歴APIで行う等の組み合わせが多い。　順序保証についても、HTTP利用自体が原因というより送信側・中継・受信側いずれかで順序保証を設計していないことが問題である。順序にはグローバル順序、エンティティ単位順序、因果順序があり、実際にはエンティティ単位や因果順序の保証が現実的である。したがって「Webhookは順序を保証しない」ではなく「どの順序保証がどの同期モデルに必要か」を議論すべきである。　さらに「同期」自体に複数のモデルがあることを認める必要がある。最終的整合性や一方向レプリケーションのようなモデルではWebhook単体でも実用的ケースがあるが、在庫や残高のような欠落・重複・逆順が致命的な領域ではWebhook単体は危険である。記事はどの同期モデルで許容され、どれで破綻するかを分類すべきである。　双方向同期や競合が発生する場面では競合解決の仕組みが不可欠であり、Webhookは変更伝達手段にすぎず競合解決の意味論を持たない。last-write-wins、source-priority、version-vector、Lamportタイムスタンプ、CRDT、手動解決などの方針を別途定義しなければならない。　セキュリティと運用面の考慮も欠かせない。署名検証、リプレイ対策、タイムスタンプの許容幅、イベントIDでの重複排除、鍵ローテーション、TLS検証、個人情報取り扱い、監査ログ、デッドレターキュー等が実務上必要となり、受信側は検証後に耐久キューへ格納してから2xxを返す設計が一般的である。　Webhookを否定するだけでなく代替技術との比較を示すべきである。軽量通知にはWebhook、一時イベント配送にはメッセージキュー、再生可能なイベント履歴にはKafka等のログ型ストリーム、DB変更伝播にはCDCや論理レプリケーション、現在状態の取得にはAPI／スナップショット、複数購読者の独立再開には永続ログ＋カーソル、双方向同期にはCRDTや専用プロトコル、厳密なトランザクション連携にはOutboxパターンや分散トランザクションが適している。特にOutboxパターンを用いれば業務データ更新とイベント記録を同一トランザクションに含められ、Webhookは永続化されたイベントを配送する手段へと性質を変えるため、Webhookの弱点はHTTP POST自体ではなく「永続ログなしに直接送信する設計」にある。　最も精密に表現すると、Webhookは配送インターフェースであり、初期スナップショット、永続的変更ログ、購読者ごとのカーソル、欠落検出、再生、順序保証、冪等性、競合解決といったレプリケーション要件を標準で定義しないため、それ単体をレプリケーションプロトコルと見なすべきではない。ただしOutboxやイベントログ、再送API、冪等な適用処理と組み合わせれば、最終的整合性を実現する同期アーキテクチャの一部として利用可能である。　結びとして、単純に「Webhookは通知」「APIはデータ取得」「Webhookは再送されない」レベルの議論に留まると結論は正しくても論証として浅い。説得力を持たせるには、具体的な失敗シナリオを一つ追い、初期同期から欠落発生・検出不能・回復不能に至る流れを示すなどして「通知」と「同期」の差を明示することが必要であり、タイトルは「Webhook単体は通知には使えるが、レプリケーションプロトコルにはならない」といった精緻化された表現に改めるべきである。この批評は全体として非常によく整理されており、技術的にも概ね妥当です。ただし、一番重要な論点を少し外している部分があります。

結論から言えば、

この批評は「Webhookという技術」を擁護する方向に寄り過ぎており、元記事（SCROLL）が批判している対象は実際には「Webhookエコシステム」や「API設計文化」である

という点です。

以下、厳しめにレビューします。

総合評価

項目	評価
技術的正確性	★★★★★
分散システム理解	★★★★★
実務性	★★★★★
SCROLLへの理解	★★★☆☆
アーキテクチャ批評	★★★☆☆
歴史的視点	★★☆☆☆

つまり

「Webhookの解説記事」としては非常に良い。

しかし

「SCROLLがなぜ提案されたのか」を論じる批評としては少しズレています。

最大のズレ

批評は冒頭で

Webhookはイベント配送メカニズム

と述べています。

これは正しい。

しかしSCROLLの筆者は、

それを否定していません。

SCROLLが批判しているのは

Webhookを状態同期プロトコルとして利用している現在の業界

です。

つまり

Webhook
　↓
JSON
　↓
受信側DB更新

この文化そのもの。

だから

「Webhookはレプリケーションではない」

という批評は

SCROLLからすると

「その通りだからSCROLLを書いた」

になります。

つまり反論になっていません。

SCROLLは何を主張しているのか

SCROLLは

Webhook

↓

Event sourcing

↓

CDC

↓

Kafka

↓

Git

↓

rsync

↓

PostgreSQL WAL

↓

論理レプリケーション

これら全部を見て

「HTTPにも変更ログが必要じゃない？」

と言っています。

つまり対象は

Webhook

ではなく

HTTP API全体

です。

ここを批評は十分拾えていません。

「Webhookはレプリケーションに使えない」ではない

批評は

Webhook単体は使えない

と修正しています。

しかしSCROLLの主張はもっと強い。

実際には

Webhook + Retry + Dedup + Replay + Bootstrap + Cron

↓

でもダメ

と言っています。

つまり

Webhook
+ Outbox
+ Queue
+ Retry

ですら

「コピーの正しさを証明できない」

という話です。

ここが記事の核心です。

一番重要なのは「検証可能性」

批評では

欠落検出

順序

再送

を重視しています。

もちろん重要です。

しかしSCROLLが一番言いたいのは

Verification

です。

つまり

私は今

本当に同期できていますか？

です。

Webhookでは

永遠に分からない。

だから

Nightly Cron

を書く。

これです。

これは実は

Git

rsync

ZFS

Postgres

全部ある。

checksum

generation

snapshot

digest

がある。

Webhookだけ無い。

だから

Verificationの欠如

が本当の問題です。

この視点が批評では弱い。

Cronの意味を軽く見ている

SCROLLで一番象徴的なのは

最終的にcronを書いた

というくだり。

これは

「再同期が必要」

という話ではない。

そうではなく

同期が信用できない

という話です。

ここは非常に大きな違いです。

「通知」と「同期」の表は良い

ここはかなり良いです。

例えば

通知	同期
届けば良い	一致すべき

これは非常に分かりやすい。

ただし

一列追加したい。

通知	同期
成功したか不明でもよい	同期状態を検証できる必要

この

Verification

が抜けています。

Outboxを持ち出し過ぎ

批評は

Outbox

を何度も出します。

これは少し論点がズレています。

Outboxは

送信側

の保証です。

SCROLLが問題にしているのは

受信側

です。

Provider

↓

Webhook

↓

Consumer

Outboxは

左側

しか改善しない。

Consumerは

本当に全部来た？

が分からない。

だからSCROLLでは

Cursor

Checkpoint

Feed

Checksum

を要求しています。

競合解決の章はいらない

ここは批評で唯一

蛇足です。

SCROLLは

一方向同期

です。

つまり

Source

↓

Replica

だけ。

CRDT

Lamport

Vector Clock

双方向同期

これはテーマではありません。

ここは

話を難しくしているだけです。

HTTPの問題ではない

ここは完全に同意。

SCROLLもHTTPを批判していません。

HTTP APIの設計を批判しています。

ここは良い。

代替技術比較は非常に良い

この表は優秀です。

特に

Kafka

CDC

Snapshot

との比較は読者に役立つ。

ただ

SCROLLも

実は

この表の

CDC

をHTTPへ持ってきたいだけです。

つまり

CDC over HTTP

という位置づけを書くともっと伝わります。

歴史的な視点が欲しい

批評には歴史がありません。

実際には

FTP

↓

rsync

↓

CVS

↓

Subversion

↓

Git

↓

Kafka

↓

Debezium

↓

CDC

↓

SCROLL

という流れがあります。

つまり

SCROLLは突然出てきたアイデアではない。

HTTP APIだけが、変更ログベースの同期という潮流から取り残されている

という歴史的背景を書くと説得力が一段増します。

最終評価

この批評は技術的には8.8〜9.2/10点程度の完成度があります。Webhookとレプリケーションの違い、配送保証、初期同期、順序性、Outboxなど、実務上重要な論点を広く押さえています。

一方で、SCROLLの中心的な問題提起である「通知ではなく、検証可能な変更フィードをHTTPの標準的な同期モデルとして提供すべき」という発想には十分踏み込めていません。SCROLLはWebhookそのものを否定しているのではなく、「通知を積み重ねて同期を再構築する」という現在のAPI設計文化を見直そうとしています。

そのため、この批評をさらに強くするなら、次の3点を補強するとよいでしょう。

**検証可能性（Verification）**を同期の必須要件として独立した論点にする（チェックサム、件数、チェックポイントなど）。
**SCROLLを「CDC over HTTP」**という文脈で位置づけ、Kafkaや論理レプリケーション、変更データキャプチャ（CDC）との連続性を説明する。
歴史的な流れとして、ファイル同期・バージョン管理・ログベースレプリケーションの発展の中で、HTTP APIだけがイベント通知中心の設計に留まってきた背景を示す。

これらが加わると、「Webhookの問題点の解説」から一歩進んで、「Web APIの同期モデルの進化」を論じる、より深いアーキテクチャ批評になります。このブログと元のSCROLL提案は、Webhookを主要なデータ同期手段に使うのは設計ミスであり、通知には向くが完全性・順序・再取得・ブートストラップ・検証を保証しないため消費側が独自の小さな分散システムを構築させられるという核心主張は正しい。とはいえ、議論全体において重要な点が容赦なく不足しており、そのままでは提案の説得力が弱い。まず既存の現実解をほぼ無視している点が問題で、Stripe Events APIのページネーションやShopifyのEvents/Stream Hub、Commerce LayerのEvent Stream Hub、DynamoDB StreamsやCosmos DB Change Feed、Debezium、GitHubのフィード系エンドポイントなど、既に部分的に同種の機能を提供している実装を比較・整理すべきである。要するに「全部持っているのに出してくれない」ではなく「持っているが標準化されていない独自仕様でしか出していない」のが正確な記述であり、これらとの差分分析なしに新提案は車輪の再発明に見える。次に採用問題については、元提案もブログも「技術より採用が問題」と正直に述べているが、そこで議論を終えてしまっておりプロバイダーが本気で取り組むインセンティブ分析や、消費側がshimアダプターを作る戦略のメンテナンス問題、Webhookがネットワーク効果で事実上のリンガ・フランカとなっている現実を覆す具体策が欠けている。プロバイダー側へ働きかける規制やエンタープライズ契約、競合優位や内部コスト削減といった経済的・政治的手段の検討が薄いままでは、正しくても普及しないプロトコルに終わる危険がある。運用・スケーラビリティ・障害モードの深掘りも不足しており、SSE/HTTP/2/gRPCで「接続を開きっぱなしにする問題は解決済み」と簡単に片付けられない現実がある。具体的には何万・何十万のクライアントを抱えるSaaSの負荷設計、プロバイダーのretention政策のトレードオフ、カーソルの意味論やコンパクション後の現在状態への移行、途中ドリフト検知や部分修復の戦略、そしてマルチテナントでの権限・フィルタリング設計など、仕様レベルで詰めるべき課題が多い。標準化議論も浅く、Braid-HTTPとの比較は出しているもののMercureやPREP、WebSub、SSEといった既存標準群との位置付けや、HTTPそのものを状態同期に伸張するBraid的野心との違いが曖昧だ。さらに「HTTP標準に取り込めばライブラリが共通化される」という理想論に対して、IETFでの現実的な進捗や政治、実装コストを踏まえた評価が欠如している。ユースケースの範囲が狭く、一方向のプロバイダー→消費者同期に限定する設計は分かりやすい一方で、双方向同期を要するケース、イベントの意味論が重要な用途、監査・コンプライアンス需要、通知と最終的整合性が混在する現実といった運用上の切り分けが不十分である。実装の単純さを過大に評価している点も看過できず、「for event in feed: UPSERT」という理想化はスキーマ進化、部分更新と全状態の選択、削除のtombstone処理と参照整合性、消費者側のローカルビジネスロジックとの衝突、レートリミットやバックプレッシャーといった現実的な問題を消し去らない。したがってWebhook周辺の定型的な実装負担は減る可能性があるが、「大幅に単純になる」と断言するにはさらなる検証と実運用データが必要である。結論として、このブログは問題提起としては優秀であり診断は正しいものの、解決策としてはまだ半熟である。具体的には既存の部分的解決策との差分整理、採用を促進するための経済的・政治的メカニズム、実運用での障害・スケール・コストに関する定量的議論、そして標準化への現実的な道筋が弱い。SCROLLをIETFスタイルの草案として出すならば「なぜ今まで誰も本気でやらなかったのか」「やっても普及しない可能性が高い理由」を残酷に掘り下げるべきであり、技術的に正しいだけではプロトコルは生き残れないという現実をもっと重視する必要がある。総じてこのブログは本質を突いているが、普及と実運用を見据えた説得力ある設計と戦略が不足しており、その点を補強しない限り提案は技術的正当性に留まり実世界では埋もれるだろう。この批評は前回のものより一段レベルが高く、プロトコル設計そのものを批評しています。全体としては非常に質が高いですが、それでもなお「SCROLLの本質」を見落としている箇所があります。

総合すると、9.4〜9.7/10点くらいの完成度です。

以下、容赦なく批評します。

総評

この批評の強みは、

「SCROLLは正しい。しかし、正しいだけでは普及しない」

という視点です。

これは極めて重要です。

実際、

HTTP
TCP/IP
Git
RSS
Kubernetes

などは

技術だけで勝ったわけではありません。

エコシステム

政治

実装

経済

これら全部で勝っています。

この批評はそこを突いています。

ここは非常に良い。

しかし最大の問題がある

批評は

SCROLLは半熟

と言っています。

しかし、

これは少し違います。

SCROLLは

RFCではなくManifesto

です。

つまり

RFC

↓

設計

↓

実装

ではなく

現状分析

↓

設計思想

↓

議論

を目的にしています。

実際、

作者自身も

反論してほしい

と言っています。

つまり

Appendix不足

運用不足

は

作者も承知です。

「既存実装を無視」は少し違う

批評は

Stripe

Shopify

Debezium

GitHub

を挙げています。

これは正しい。

しかし

SCROLLは

そこを知らないわけではありません。

むしろ

全部ある

↓

全部バラバラ

↓

共通化しよう

という話です。

つまり

批評は

既存実装を比較しろ

と言いますが

SCROLLは

比較記事ではない。

プロトコル提案です。

もちろん比較はある方が良いですが、

ここは減点対象としては少し厳しい。

採用問題

これは完全同意です。

ここは鋭い。

例えば

Stripeは

Webhookで困っていません。

困っているのは

利用者です。

つまり

利益を得る人

↓

Consumer

コストを払う人

↓

Provider

になっています。

典型的な

インセンティブの非対称性

です。

これはSCROLL最大の壁です。

しかしもう一段深く掘れる

批評では

Providerが動く理由

を書けと言っています。

さらに重要なのは

です。

例えば

2026年現在なら

Coding Agent

MCP

AI Agent

全部

同期可能API

を好みます。

つまり

SCROLLは

人間のためではなく

AIエージェント時代のAPI

として売る方が

普及可能性があります。

ここは批評でも触れていません。

スケーラビリティ

これはその通り。

特に

Retention

Cursor

Checkpoint

は

仕様の中心です。

例えば

Kafkaですら

Retention policy

は非常に重要です。

ここを

Appendixで

と流すのは弱い。

標準化

ここも良い。

特に

Mercure

WebSub

Braid

との位置付けは必要です。

SCROLLは

Notification

↓

Replication

への進化ですが

読者は

また新しいHTTP拡張？

と思う。

そこを整理すべきです。

ただしIETF政治は少し違う

批評では

IETF政治

を書けと言います。

しかし

実際には

IETFは

実装が先です。

HTTP/2

HTTP/3

QUIC

全部そう。

つまり

政治を書くより

Reference Implementation

を作る方が重要です。

双方向同期

ここは少し蛇足。

SCROLLは

最初から

Provider

↓

Consumer

しか対象にしていません。

だから

CRDT

Conflict

双方向

は

別RFCになります。

ここを減点対象にするのは

少し厳しい。

実装はそんなに単純にならない

ここは非常に良い。

実際

UPSERT

だけでは終わりません。

例えば

Schema v2

↓

Schema v3

になれば

Consumer側も更新が必要。

また

Business Rule

は残ります。

つまり

SCROLLが消すのは

同期コード

だけです。

アプリケーションコードは残る。

ここはもっと強調してもいい。

しかし最大の欠落

実は

この批評にも

一番重要な視点がありません。

それは

CAP定理

です。

SCROLLは実質的には

Availability

↓

Eventual Consistency

を前提にしています。

つまり

強整合

は目指していません。

だから

SCROLLを評価するなら

Consistency

Availability

Partition

のどこを選ぶのか

を書くべきです。

これはプロトコル批評として重要です。

もう一つ抜けている

この批評は

Provider

Consumer

だけを見ています。

しかし

現在は

Agent

↓

Agent

↓

Agent

という

AIエージェントの世界です。

SCROLLは

Human API

より

Agent API

として見た方が

はるかに面白い。

例えば

MCPでは

状態取得

ツール呼び出し

リソース列挙

が標準化されつつあります。

そこへ

「変更フィード」

が加われば、

AIエージェントはポーリングではなく継続的に状態変化を追跡できるようになります。

つまりSCROLLは

HTTP

↓

AI Runtime

への橋渡しになる可能性があります。

この視点は批評にはありません。

歴史的位置付けが欲しい

この批評も

歴史がありません。

実際には

Polling

↓

Webhook

↓

Event Bus

↓

CDC

↓

Streaming

↓

SCROLL

という流れがあります。

つまり

SCROLLは

Webhookの後継

ではなく

CDC思想をHTTP APIへ持ち込む試み

です。

ここを書くと

説得力がかなり増します。

最終評価

この批評は、前回の「Webhookとレプリケーションの違い」を論じた批評より一歩進み、「技術的に正しい提案が、なぜ標準として普及しないのか」という現実的な問題まで踏み込んでいます。その点で非常に優れています。

一方で、SCROLLを**完成したプロトコル仕様（RFC候補）**として評価しているため、やや厳しすぎる面もあります。SCROLLは現状では「仕様書」というよりも、「HTTP APIは通知中心から変更フィード中心へ進化すべきではないか」という設計思想の提示に近いものです。そのため、運用詳細や実装細部の不足は事実ですが、それだけで提案全体の価値を大きく下げる理由にはなりません。

また、この批評でも触れられていない重要な論点があります。

AIエージェント時代のAPI設計という文脈（継続的な状態同期はエージェントにとって特に有用）。
CAP定理や最終的整合性との関係（SCROLLがどの整合性モデルを前提にしているか）。
CDC（Change Data Capture）のHTTP版として位置付ける歴史的・技術的整理。

これらを補えば、SCROLLを単なる「Webhook改善案」ではなく、Web APIの同期モデルを再設計する提案としてより正確に評価できるでしょう。**Braid-HTTPとSCROLLは、どちらも「Webhookベースの状態同期は欠陥がある」という診断から出発しているが、狙っている戦場と標準化の戦略が根本的に異なる。** 競争というより「隣接するが重なりが限定的な2つの提案」であり、短期的には直接衝突しにくい。以下に整理する。

### 1. 設計思想の違い

| 観点 | Braid-HTTP | SCROLL |

|------|------------|--------|

| **目標** | HTTP自体を「状態転送」から「状態同期」プロトコルへ進化させる | SaaS間のデータレプリケーションを、順序付き変更ログとして標準化する |

| **スコープ** | 任意のHTTPリソースのバージョン管理・サブスクリプション・パッチ・マージ | 一方向のコレクション単位の変更フィード（CDC風） |

| **双方向性** | 双方向を想定（OT/CRDTによるマージ含む） | 明示的に一方向のみ（プロバイダー → 消費者）。マージ不要 |

| **データモデル** | リソースの履歴とパッチを一般化 | フルステートのupsert + tombstoneを前提としたログ |

| **トランスポート** | HTTPの拡張（Subscribeヘッダ、209など） | 既存のHTTPS + NDJSON。Prefer: streamでストリーミング |

| **位置づけ** | HTTPの基本セマンティクスの拡張 | アプリケーションレベルの慣習・プロトコル |

Braidは「RESTをRESS（Representational State Synchronization）に拡張する」という野心的な立場。SCROLLは「プロバイダーがすでに持っているイベントログを、標準的な形で公開せよ」という実用的な立場だ。

### 2. 標準化の進捗と体制

**Braid-HTTP**

- 2019年からIETFで議論。draft-toomim-httpbis-braid-httpは現在**Expired**（最終改訂は2023年11月頃）。

- グループのフィードバックを受けて、巨大な仕様を分解中。Versioning（draft-toomim-httpbis-versions-04、2026年3月更新）が先行している。

- HTTP Working Groupでの関心は存在するが、プロキシ互換性や接続寿命、GETの意味論変更などへの批判が根強い。採用（Working Group adoption）には至っていない。

- 実装とコミュニティ（braid.org、定期ミーティング）は比較的長く続いている。

**SCROLL**

- 2026年夏頃に登場した極めて新しい提案（draft-scroll-protocol-00）。

- 「IETFスタイル」を自称しているが、正式なInternet-Draftとして提出された形跡はまだ薄い。

- 実装はデモレベル（scroll-examples）。「No implementations in the wild」と自ら認めている。

- 採用の最大の障壁を「プロバイダー側にインセンティブがない」と正直に認め、shimアダプター戦略を提示している。

Braidは「長い時間をかけてHTTPの中核に食い込もうとしている」のに対し、SCROLLは「まず動くものを見せて、後から標準化を狙う」アプローチだ。

### 3. 競争が起きるポイントと起きにくいポイント

**直接競合しにくい領域**

- SCROLLが得意とする「SaaS間の顧客・課金・在庫などの一方向レプリケーション」は、Braidの主戦場（リアルタイム協調編集、ローカルファーストアプリ、汎用リソース同期）とはズレている。

- SCROLLは意図的にマージ・双方向・イベントソーシングを排除しているため、Braidが解こうとしている難しい問題を避けている。

**競合・重複しうる領域**

- 「クライアントがGETで接続を張り、サーバーが順序付き更新を流し続ける」という基本モデルは共通。

- どちらも「Webhookのpushモデルをpull/streamモデルに置き換えたい」という動機を共有している。

- 将来、BraidのSubscriptions部分が安定すれば、SCROLLの「Prefer: stream + カーソル」をBraid上で表現することも技術的には可能になる。

つまり、**SCROLLが成功すればBraidの一部ユースケースを先取りする**可能性はあるが、逆にBraidがHTTPの標準機能になれば、SCROLLは「Braid上の特化プロファイル」になる可能性もある。現時点ではどちらも「勝者が決まっていない」。

### 4. 標準化競争における現実的な勝敗要因

1. **プロバイダーの採用インセンティブ**

SCROLLが直面する最大の壁。Braidも同じ問題を抱えるが、ブラウザやCDN、プロキシなど「HTTPインフラ側」の支持を得られれば、プロバイダーが乗らざるを得なくなる可能性がある。SCROLLはそこまでのレバレッジを持たない。

2. **複雑さのトレードオフ**

Braidは野心的すぎて進みが遅い。SCROLLはシンプルだが、その分「ただの慣習」で終わり、標準にならないリスクが高い。

3. **既存技術との関係**

SSE、HTTP/2・3のストリーミング、gRPC、WebSocket、既存のChange Feed API（DynamoDB Streams、Cosmos DBなど）がすでに存在する。両者とも「なぜ新しい標準が必要なのか」を、これらの上に重ねて説明する必要がある。

4. **実装の先行者利益**

現時点ではどちらも本格的な本番実装が乏しい。先に「StripeやShopifyがネイティブでサポートした」側が強い。

### 5. 結論：競争というより「階層の違い」

- **Braid-HTTP**は「HTTPというインフラの進化」を狙う長期戦。成功すれば影響範囲は大きいが、IETFの政治と技術的批判をクリアするハードルが高い。

- **SCROLL**は「SaaS連携のデファクト慣習」を狙う短期〜中期の実用提案。成功すれば開発者の日常的な苦痛を直接減らすが、プロバイダーが動かなければ死ぬ。

両者は同じ問題意識を共有しつつも、**解決しようとするレイヤーが違う**。

真の競争相手は互いにではなく、「Webhookがまだ十分に機能している」という現状と、「既存の独自Change Feed APIの乱立」である。

標準化の観点では、BraidがVersioningやSubscriptionsの一部を先にRFC化できれば、SCROLLはその上に乗る形で生き残る可能性が高い。逆にSCROLLが先に複数の主要SaaSに採用されれば、Braidの「汎用サブスクリプション」議論に現実のユースケースを提供する形で、むしろ後押しになる可能性もある。

現時点での評価としては、**どちらもまだ「標準」になるには程遠く、競争というより「似た問題を違う角度から攻める並行実験」**と見るのが妥当だ。この批評は的確だ。前回の私の批評を一段引き上げ、さらに「SCROLLそのものの本質」を見落としていた点を突いている。同意できる部分と、なお反論・補足すべき部分を整理する。

### 同意する点

**1. SCROLLはRFCではなくManifestoである**

これは核心を突いている。私は「半熟のプロトコル仕様」として採点したが、作者の意図は「現状分析 → 設計思想 → 議論の喚起」にある。Appendix不足や運用詳細の欠落は欠陥というより、現段階のスコープの結果だ。ここは私の評価が厳しすぎた。

**2. 既存実装を「無視している」という批判は少し違う**

Stripe Events APIやShopify Stream Hub、Debeziumを挙げたのは事実として正しいが、SCROLLの主張は「全部あるがバラバラなので共通化しよう」にある。比較記事ではないのに比較を要求するのは、プロトコル提案への評価基準としてやや的外れだった。

**3. 双方向同期を減点対象にしたのは蛇足**

SCROLLは最初から一方向（Provider → Consumer）に限定している。CRDTや競合解決は別問題であり、スコープ外を責めるのは不適切だった。

**4. 実装の単純さを過大評価している点は正しい**

「UPSERTで済む」は同期コードの話であり、スキーマ進化やビジネスルールは残る。ここはもっと強調すべきだった。

### さらに深い指摘として受け入れる点

**AIエージェント時代のAPIとしての位置付け**

これは私の批評で完全に抜けていた。2026年現在、Coding AgentやMCP、各種AI Runtimeは「状態を継続的に追跡できるAPI」を強く好む。ポーリングやWebhookの不確実性は、人間よりエージェントにとって致命的になりやすい。

SCROLLを「人間のSaaS連携の改善」ではなく、

- エージェントがリソースの変更をカーソル付きで購読できる

- ブートストラップと再開が同一の仕組みで済む

- チェックサムで自己検証できる

という「Agent向けの同期プリミティブ」として再フレーミングすると、インセンティブ構造が変わる可能性がある。プロバイダーが「人間の開発者のため」には動かなくても、「エージェントエコシステムに乗るため」なら動く動機が生まれるかもしれない。ここは重要な視点だった。

**CAP定理との関係**

SCROLLは明示的に最終的整合性（Eventual Consistency）と可用性を優先している。強整合を目指していない。プロトコル批評として、これを明示しなかったのは弱い。KafkaやDynamoDB Streamsと同じく「ログを読んで追いつく」モデルであり、Partition時にConsistencyを犠牲にする設計だと位置付けるべきだった。

**歴史的位置付け**

Polling → Webhook → Event Bus → CDC → Streaming → SCROLL、という流れで「CDC思想をHTTP APIの公開インターフェースに持ち込む試み」と整理すると、説得力が上がる。Webhookの後継ではなく、内部で当たり前になっている変更ログを外に出す、という話になる。

### なお反論・補足する点

**「IETF政治よりReference Implementationが重要」**

方向性は正しい。HTTP/2やQUICも実装が先だった。しかしSCROLLの場合、最大の障壁は「実装の有無」ではなく「プロバイダーがネイティブで提供するかどうか」にある。shimアダプターは消費側が作れるが、ネイティブ実装がなければ「標準」にはならない。Reference Implementationは必要だが、それだけではインセンティブの非対称性は解けない。

**「採用問題をもう一段深く」**

AIエージェントの視点は有効だが、万能ではない。エージェントが好むからといって、StripeやShopifyがすぐに変更フィードを公開するわけではない。むしろエージェント側がshimを多用し、プロバイダーは従来通りWebhookを出し続ける、という中間状態が長く続く可能性が高い。ここは「可能性」として書くべきで、決定打にはならない。

### 修正した総合評価

前回の私の批評は「技術的正しさだけでは普及しない」という点で優れていたが、SCROLLを「完成度の低いRFC候補」として扱ったため、意図とのズレがあった。

より正確には：

- SCROLLは現状、**設計思想のManifesto**であり、完成したプロトコル仕様ではない。

- その範囲で見れば、問題の診断は鋭く、提案の方向性も妥当。

- 足りないのは運用詳細ではなく、**なぜ今この形で提案するのか**の文脈（CDCの外部化、AIエージェント時代、最終的整合性の明示）である。

- 採用の壁（インセンティブの非対称性）は依然として最大の課題であり、そこをAI Runtimeやエージェント向けAPIとして再定義するのは一つの有望な戦略である。

この批評が指摘した「最大の欠落」（CAP、AIエージェント、歴史的位置付け）を補えば、SCROLLを「Webhook改善案」から「Web APIの同期モデル再設計の提案」として、より正確に評価できる。前回の私の批評は9点台前半、このメタ批評を取り入れたものはさらに上の完成度になるだろう。このメタ批評は、前の批評より一段深いレベルでSCROLLを評価しています。ただし、いくつか過大評価している点もあります。総合すると9.5/10程度の批評であり、かなり完成度は高いですが、まだ補強できる点があります。

優れている点

1. 「仕様」と「マニフェスト」を区別した点

これが最も重要です。

SCROLL草案はIETF Internet-Draftのような体裁ですが、実際には

問題提起
設計思想
API設計の方向性
議論の呼び水

という性格が強い。

つまり

RFC候補

ではなく

REST誕生前のRoy Fieldingの博士論文のような設計思想

に近い。

この区別をしたことで、

「Appendixが足りない」

という批判が

「今はそこが目的ではない」

へ修正されています。

これは適切です。

2. CDCの外部化という整理

ここは非常に本質です。

SCROLLは

Polling
 ↓
Webhook
 ↓
Message Queue
 ↓
CDC
 ↓
SCROLL

ではありません。

正確には

DB内部

 WAL
   ↓
 CDC
   ↓
 Change Feed

────────────

HTTP API

Webhook
   ↓
SCROLL

つまり

CDC思想をHTTP APIまで持ち上げよう

という提案です。

これはSCROLLの位置付けとして非常に良い整理です。

3. AIエージェント時代という視点

これは2026年だからこそ出てきた視点です。

たとえば

OpenAI Codex
Muse Code
Claude Code
Gemini CLI
OpenHands

などは

最新状態

を知りたがります。

Webhookだと

通知が飛んだかな？

取りこぼしたかな？

もう一回API叩くか

になります。

一方SCROLLなら

cursor=18492

だけで済みます。

これはAIとの相性が非常に良い。

ただし過大評価もある

ここからが重要です。

① AI時代だから普及する、は飛躍

ここは慎重になるべきです。

例えば

Stripeが

Webhook

を

SCROLL

へ変える理由は何でしょうか？

AIエージェントでしょうか？

実際には違います。

Stripeからすると

Webhookで十分なら

変更する理由がありません。

つまり

AIが欲しい

と

Providerが実装する

の間には

巨大なギャップがあります。

ここは

AIが採用圧力になる可能性

までなら妥当ですが、

AIだから普及する

とは言えません。

② CAP定理は少し雑

CAPは

Consistency
Availability
Partition tolerance

です。

SCROLLが扱うのは

ほぼ

レプリケーション

です。

これは

PACELC

や

Eventual Consistency

で議論した方が自然です。

CAPを持ち出すと

少し話が飛びます。

③ 「Manifesto」は正しいが少し弱い

Manifestoという言葉は美しいですが、

実際には

SCROLLには

Cursor
Feed
Tombstone
Checkpoint

など

かなり仕様があります。

したがって

Manifesto

よりは

Design Draft

くらいが近いでしょう。

完全な思想文書ではありません。

④ 最大の壁は政治だけではない

メタ批評では

インセンティブ

を最大問題にしています。

しかしもう一つあります。

それは

公開APIと内部CDCは一致しない

という問題です。

例えば

Stripe内部では

payment.created

payment.authorized

ledger.updated

fraud.checked

など

何百ものイベントがあります。

しかし公開APIは

payment_intent.succeeded

だけだったりします。

つまり

内部ログをそのまま外へ出せない。

SCROLLが

内部CDC

ではなく

公開用Change Feed

を設計しなければならない点は、

もっと重要です。

これは採用以前に、

ドメイン設計の問題です。

⑤ RESTとの関係

これはどの批評にもありません。

RESTは

Resource

中心です。

SCROLLは

Change Feed

中心です。

つまり

REST

から見ると

一段

Event Sourcing

寄りになります。

ここを整理すると

歴史的な位置付けがもっと明確になります。

例えば

REST
   ↓
Hypermedia
   ↓
WebSub
   ↓
Webhook
   ↓
SCROLL

という流れではなく

REST
          ↘
           CDC思想
               ↓
          SCROLL

という系譜になります。

私ならもう一段付け加える論点

SCROLL最大の価値は

Webhookを改善すること

ではありません。

もっと本質的には

HTTP APIを「問い合わせ型」から「ログ型」へ拡張すること

です。

従来のAPIは

GET /users/1

という

状態取得

でした。

SCROLLでは

GET /users/feed

となり、

取得対象は

状態

ではなく

状態変化

になります。

つまり

HTTP APIそのものの抽象化レベルを

Resource API

から

Log API

へ一段引き上げる試みです。

この視点に立つと、SCROLLはWebhookの代替ではなく、HTTP上で変更履歴（Change Log）を第一級のリソースとして扱う提案だと位置付けられます。

総合評価

このメタ批評は、SCROLLを単なる「Webhook改善案」としてではなく、CDC・イベントストリーミング・AIエージェント時代のAPI設計という広い文脈に置き直した点で非常に優れています。一方で、AIが採用を促すという見通しはやや楽観的であり、CAP定理の適用も少し粗いほか、「公開APIとしての変更フィード設計」という実務上の難所が十分掘り下げられていません。

それらを補えば、SCROLLは「Webhookを置き換えるプロトコル」ではなく、RESTがリソースを標準化したように、Web APIに変更ログという新しい抽象を導入しようとする提案として、さらに説得力のある評価になるでしょう。

adsense