アプリ/フロント基盤

Server-Sent Eventsとは|1分ごとに見に行くと遅れは31.5分、1分ごとを15分にしても回数は3分の1

見に行く形と何が違うのか遅れはどれだけ縮むのかどこまでできる仕組みなのか

決めた間隔で見に行く形では、15分ごとなら気づくまで平均7.4分かかります。

1分ごとにすると0.5分ですが、見に行く回数は13.7倍です。押し出す形はこの両方を外します。

この記事の要点

  • 15分ごとで7.4分
  • 1分ごとで0.5分
  • 回数は13.7倍
  • 接続は一方向

1分ごとに見に行っても、遅れは0.5分にしか縮まない

見に行く形では、遅れは間隔の半分です。縮めるには回数を反比例で増やすことになります。

Server-Sent Eventsを使うと、受け取る側は見に行きません。出典はサーバーから送られる出来事の面は、EventSourceという面に含まれると述べており、接続を開いたまま受け取る形になります。

比べる相手は、決めた間隔で見に行く形です。その遅れと回数を数えました。

見に行く間隔を変える

知らせたい出来事が180分の幅でばらついて起きるとします。

text
上流のファイルが届くのを待つ。届く時刻は 180分の幅でばらつく
決めた間隔で見に行く。届いていれば次へ進む

見に行く間隔  気づくまでの遅れ(平均)  99%点  見に行った回数(平均)
1分ごと                            0.5分     1.0分                   81.1回
5分ごと                            2.5分     5.0分                   16.6回
15分ごと                           7.4分    14.8分                    5.9回
30分ごと                          15.2分    29.7分                    3.2回
60分ごと                          31.5分    59.4分                    1.9回

遅れは間隔のおよそ半分です。15分ごとなら7.4分になります。

1分ごとにすれば0.5分ですが、回数は5.9回から81.1回へ13.7倍です。

押し出す形はこの表の外にある

押し出す形では、遅れも回数も間隔に依存しません。出来事が起きた時点で届きます。

この表でいえば、遅れは0分に近く、回数は出来事の数だけになります。どの行にも当てはまりません。

その代わり、接続を開いたまま保つことになります。受け取る側の数だけ接続が残ります。

見に行く形では、遅れと回数のどちらかしか選べない。

気づくまでの遅れ(分)見に行った回数(回)→34.789.260分ごと30分ごと15分ごと5分ごと1分ごと180分の幅で起きる場合を3000回試した平均。押し出す形は、この曲線の左下のさらに外側にあたる。
図1 ── 見に行った回数と、気づくまでの遅れ
出典MDN Web Docs「Using server-sent events」2026-08-18 確認
The server-sent event API is contained in the EventSource interface.
原文MDN Web Docs「Using server-sent events」 この内容の有効期限2027-02-18

送る側は決まった形式で書き出すだけ

特別な取り決めを別に用意しません。返す形式を指定し、決まった書き方で送ります。

Server-Sent Eventsの実装は重くありません。出典はサーバーから送られる出来事を使うウェブアプリケーションの開発は、単純明快であると述べています。

送る側に必要なのは、形式の指定です。出典は出来事を送る側の記述は、text/event-streamという種別を使って応答する必要があると定めています。

要らないもの

  1. 別の取り決め。通常の通信の上で成り立つ
  2. 別の口。同じ経路をそのまま使える
  3. 接続の再開の記述。受け取る側の面が担う
  4. 順番の管理。印を付ければ続きから受け取れる

1番目が効きます。途中にある仕組みが、そのまま通してくれます

その代わり、接続が長く開いたままになります。途中の仕組みが時間で切る設定を持っていると、そこで切れます。

接続の数を見積もる

受け取る側の数だけ接続が残ります。1万人が同時に開けば1万本です。

見に行く形なら、同じ1万人でも接続は一瞬です。代わりに前の節の回数がかかります。

つまり移し替えているのは、回数の負荷から、同時に開いている数の負荷へです。どちらが軽いかは構成で決まります。

出典MDN Web Docs「Using server-sent events」2026-08-18 確認
Developing a web application that uses server-sent events is straightforward.
原文MDN Web Docs「Using server-sent events」 この内容の有効期限2027-02-18

呼ぶ側から送れないので、往復には別の口が要る

一方向と明記されています。双方向が必要なら、別の仕組みと組み合わせることになります。

Server-Sent Eventsには明確な制約があります。出典はこれは一方向の接続であり、呼ぶ側から受ける側へ出来事を送ることはできないと述べています。

つまり受け取る専用です。送る必要があれば、通常の呼び出しを別に使います。

向いている場面

  1. 進み具合を知らせる。送るのは片方向だけ
  2. 一覧の更新を配る。受け取る側は見るだけ
  3. 通知を届ける。返事は別の呼び出しでよい
  4. 細かい往復がある。向かない。別の仕組みを使う

4番目が分かれ目です。往復が細かいなら、双方向の仕組みのほうが素直になります。

押し出す量にも上限がある

押し出す形にしても、送る量そのものは減りません。出来事が多ければ、そのぶん流れます。

受け取る側が処理しきれない場合、間引く判断は送る側が持つことになります。

その間引き方は、呼び出しの制限と同じ考え方になります。数え方による差はレート制限の実装の記事で測りました。

余談 この計測での注意

見に行く形の計測では、出来事の起きる時刻を180分の幅で一様としました。実際には特定の時刻に集中することが多く、その場合は集中する時刻の直後だけ細かく見る形が有利になります。押し出す形については、遅れと回数を式で置いておらず、この表の外にあるという位置づけだけを示しています。接続を保つ側の負荷も計測に含めていません。

出典MDN Web Docs「Using server-sent events」2026-08-18 確認
This is a one-way connection, so you can't send events from a client to a server.
原文MDN Web Docs「Using server-sent events」 この内容の有効期限2027-02-18

よくある質問

見に行く形と何が違いますか
きっかけの向きです。押し出す形では、変化が起きた側から知らせます。
遅れはどれだけ縮みますか
見に行く形では間隔の半分が遅れになります。15分ごとなら平均7.4分でした。
間隔を短くすればよいのでは
回数が増えます。15分ごとを1分ごとにすると、遅れは6.9分縮む代わりに回数が13.7倍になります。
何ができない仕組みですか
一方向です。呼ぶ側から送ることはできないと明記されています。

まとめ

  • サーバー側から押し出す
  • 見に行く必要がなくなる
  • 接続は一方向
  • 送る形式が決まっている

今日から始められること

  1. いま何分ごとに見に行っているか確かめる
  2. その半分が遅れとして許せるか判断する
  3. 見に行く回数を数える
  4. 呼ぶ側から送る必要があるか確かめる

実務で組んだServer-Sent Eventsのワークフローには、値段が付きます

同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。

出品の仕組みを見る