Spring Bootで使う SSE（Server-Sent Events）の仕組みを初心者向けに解説
新人
「Spring Bootでリアルタイム通知を作りたいんですが、WebSocket以外にも方法があると聞きました」
先輩
「その場合によく使われるのがSSEです。Server-Sent Eventsという仕組みですね」
新人
「SSEって、HTTP通信とは違うんですか？」
先輩
「HTTP通信をベースにしつつ、サーバーから継続的にデータを送れる点が特徴です」
新人
「なるほど、仕組みから知りたいです」
先輩
「では、Spring Boot SSEの基本から整理していきましょう」
1. SSE（Server-Sent Events）とは何か
SSEとは、Server-Sent Eventsの略で、サーバーからクライアントへ 一方向にデータを送り続けることができる通信の仕組みです。 Spring Boot SSE を使うことで、画面を更新しなくても サーバー側の情報を自動的に受け取れるようになります。
通常のHTTP通信では、クライアントがリクエストを送らない限り、 サーバーからデータを送ることはできません。 SSEでは最初のリクエスト後、接続を維持したまま サーバーがイベントを送信し続けます。
そのため、通知や進捗表示など、 サーバー主導で情報を届けたい場面に向いています。 これが Server-Sent Events 仕組み の大きな特徴です。
2. SSEが解決しようとしている問題（HTTP通信の限界）
HTTP通信は、リクエストとレスポンスが一対一で完結する仕組みです。 このため、サーバー側で状態が変わっても、 クライアントが再度リクエストしない限り変化を知ることができません。
例えば、処理の進捗状況や新しい通知を表示したい場合、 定期的にサーバーへ問い合わせる必要があります。 これを繰り返すと、通信回数が増え、処理効率も下がります。
SSEはこの問題を解決するために生まれました。 一度接続すれば、サーバーから必要なタイミングで 情報を送り続けられるため、無駄な通信を減らせます。 Spring Boot SSE は、この仕組みを簡単に利用できるようにしています。
@Controller
public class SseController {
@GetMapping("/sse")
public SseEmitter stream() {
return new SseEmitter();
}
}
この例では、SseEmitterを返すことで、 HTTP接続を維持したままイベント送信が可能になります。 実際のイベント送信処理は、別の処理から行われます。
3. SSEとWebSocketの大まかな違い
SSEとWebSocketは、どちらもリアルタイム通信に使われますが、 仕組みと用途には違いがあります。 SSEはサーバーからクライアントへの一方向通信に特化しています。
一方、WebSocketは双方向通信が可能で、 クライアントからも自由にデータを送信できます。 その分、設計や管理は複雑になりやすいです。
Spring BootでSSEを使う場合、 「サーバーから通知したいだけ」 「クライアントから頻繁に送信する必要はない」 といったケースに非常に向いています。
HTTPをベースにしているため、SSEは理解しやすく、 初心者でも仕組みを把握しやすい点が特徴です。 SSEとは何かを理解することで、 WebSocketとの使い分けも自然と見えてきます。
SseEmitter emitter = new SseEmitter();
emitter.send("サーバーからのイベント通知");
このように、SSEではシンプルなコードで サーバー主導のイベント送信を実現できます。 Spring Boot SSE は、HTTP通信の延長として扱える点が 大きなメリットです。
4. SSEの通信の仕組み（サーバーから一方向に送られる理由）
SSE 通信 流れを理解するためには、 なぜサーバーからクライアントへの一方向通信になっているのかを 先に押さえておく必要があります。 SSEは、サーバーからの通知を効率よく届けることに 特化した仕組みとして設計されています。
通常のHTTP通信では、 クライアントがリクエストを送信しなければ、 サーバーは何も返せません。 SSEでは、最初のリクエストで接続を確立したあと、 その接続を切らずに維持します。
この状態になると、 サーバーは「必要なときに」「必要な情報を」 クライアントへ送信できます。 クライアント側は、通知を受け取るだけでよく、 追加のリクエストを送る必要がありません。
比喩で考えると、 SSEは放送のような仕組みです。 テレビをつけていれば、 放送局から番組が一方的に流れてきます。 視聴者が毎回問い合わせをする必要はありません。
この「一方通行の配信」という性質があるからこそ、 SSEはシンプルで理解しやすく、 Spring Bootでのリアルタイム通知に向いています。
5. Spring BootにおけるSSEの基本的な構成
Spring BootでSSEを扱う場合、 基本となるのは SseEmitter という仕組みです。 SseEmitter は、HTTP接続を保持したまま、 サーバーからイベントを送信するための窓口のような役割を持ちます。
構成としては非常にシンプルで、 @Controller を使ってエンドポイントを用意し、 そのメソッドで SseEmitter を返すだけです。 これにより、SSE通信が開始されます。
@Controller
public class SseController {
@GetMapping("/events")
public SseEmitter events() {
return new SseEmitter();
}
}
この時点で、クライアントとサーバーの接続は維持されます。 あとは、別の処理からこの SseEmitter を使って イベントを送信するだけです。
Spring Boot SSEでは、 通常のコントローラと同じ書き方で 非同期的な通知処理を扱える点が特徴です。 特別な通信制御を意識しなくても、 サーバーからの配信処理を実現できます。
SseEmitter emitter = new SseEmitter();
emitter.send("処理が完了しました");
このように、SSEの構成は非常に直感的です。 「接続を作る部分」と「通知を送る部分」が分かれている、 という点を意識すると理解しやすくなります。
6. Spring MVCの通常通信とSSE通信の流れの違い
Spring MVCの通常通信と、 SSE通信の流れを比較すると、 両者の違いがはっきりと見えてきます。 通常通信では、 リクエストとレスポンスが一回で完結します。
ブラウザがURLにアクセスし、 @Controller が処理を行い、 レスポンスを返した時点で通信は終了します。 次に何かをしたい場合は、 再度リクエストを送る必要があります。
一方、SSE通信では、 最初のリクエストで接続を確立したあと、 その接続が継続されます。 サーバーは、この接続を使って 何度でもイベントを送信できます。
Spring MVCは、 「要求に対して結果を返す」 という考え方が中心ですが、 SSEは、 「状態が変わったら通知する」 という考え方が中心になります。
この違いを理解していないと、 「なぜレスポンスが返ってこないのか」 「処理が終わらないように見える」 といった混乱が起こりやすくなります。 SSEは、通信が終わらないことが正常な状態だと 認識することが大切です。
7. SSEが非同期処理と言われる理由
Spring Boot 非同期処理という言葉と一緒に、 SSEが紹介されることがよくあります。 その理由は、SSEが 「処理の完了を待たずに通信を維持する」 という性質を持っているからです。
通常の同期処理では、 リクエストを受け取ったあと、 処理が完了するまでレスポンスを返しません。 その間、クライアントは待ち続けます。
SSEでは、 最初のレスポンスで接続だけを確立し、 実際のデータ送信は サーバーの都合の良いタイミングで行われます。 クライアントは待ち状態になりますが、 ブロックされるわけではありません。
この仕組みにより、 長時間かかる処理や、 いつ発生するか分からないイベントでも、 自然な形で通知できます。 これが Server-Sent Events Spring が 非同期処理と呼ばれる理由です。
初心者の段階では、 「SSEは、結果が出たらあとから知らせてくれる仕組み」 と理解しておけば十分です。 通常通信との役割の違いを意識することで、 SSEの使いどころが見えてくるようになります。
8. SSEを使うときに初心者がつまずきやすいポイント
Spring Boot SSE 注意点として、初心者が最初につまずきやすいのは、 「通信が終わらない状態が正常である」という前提を 理解できていないケースです。 SSEは、レスポンスを返して処理を終える仕組みではありません。
通常のHTTP通信に慣れていると、 コントローラの処理が終われば すぐに通信も終了するものだと考えがちです。 しかし、SSEでは接続を維持し続けること自体が目的になります。
そのため、 「画面がずっと読み込み中に見える」 「レスポンスが返ってこない」 と感じてしまうことがあります。 これはエラーではなく、 SSEの仕組みを正しく理解できていないことによる混乱です。
もう一つ多いのが、 SseEmitter を通常の戻り値と同じ感覚で 使ってしまうケースです。 SseEmitterは、 その場で完結する値ではなく、 あとからイベントを送るための通路です。
「SseEmitterを返したあとに、どこで送信するのか」 という流れをイメージできていないと、 SSEの動きが分からなくなります。 仕組みとしては、 接続の確立と通知の送信が 別のタイミングで行われる点が重要です。
9. SSEが向いている処理・向いていない処理
Server-Sent Events 使いどころを考えるうえで、 SSEが得意な処理と、 苦手な処理を分けて理解することが大切です。 SSEは、サーバーからの通知を 継続的に届けたい場面に向いています。
例えば、 処理の進捗状況の表示、 管理画面での状態変化の通知、 新しい情報が追加されたことを知らせる通知などは、 SSEと非常に相性が良いです。 クライアントは受け取るだけでよく、 操作は不要だからです。
一方で、 クライアントから頻繁にデータを送信したい場合や、 双方向でやり取りしたい場合には、 SSEは向いていません。 SSEはあくまで一方向通信であり、 入力を受け取る仕組みではないからです。
このような場合に無理にSSEを使おうとすると、 設計が不自然になり、 実装も分かりにくくなります。 「通知だけで足りるのか」 「やり取りが必要なのか」 を基準に考えると判断しやすくなります。
SSEは万能ではありませんが、 役割を限定すれば、 非常に分かりやすく、 保守しやすい仕組みになります。
10. WebSocketやSTOMPと比較したときのSSEの立ち位置
リアルタイム通信 Spring の技術には、 SSE、WebSocket、STOMPなどがあります。 これらはすべて目的が少しずつ異なります。 SSEの立ち位置を理解することで、 技術選択がしやすくなります。
WebSocketは双方向通信が可能で、 チャットやオンラインゲームなど、 双方が頻繁にデータを送る場面に向いています。 その分、接続管理や設計は複雑になりがちです。
STOMPは、 WebSocketの上でメッセージの流れを整理する仕組みです。 publish と subscribe の考え方を使い、 多人数への配信を管理しやすくします。
それに対してSSEは、 HTTP通信をベースにした一方向配信です。 設定や理解のハードルが低く、 初心者でも仕組みを把握しやすい点が特徴です。
「双方向が必要ならWebSocket」 「配信管理が必要ならSTOMP」 「通知だけで十分ならSSE」 というように整理すると、 SSEという選択肢が存在する理由が 自然と見えてきます。
