リアルタイム通信が当たり前の時代へ

チャットアプリ、株価のライブ更新、SNSの通知、共同編集ツール。現代のWebアプリケーションではリアルタイム通信が当たり前になっています。従来のHTTPリクエスト・レスポンスモデルでは、クライアントが能動的にサーバーに問い合わせない限りデータを取得できませんが、リアルタイム通信技術を使えば、サーバー側からクライアントにデータをプッシュできます。

リアルタイム通信の代表的な技術としてWebSocketとServer-Sent Events（SSE）がありますが、それぞれの特性を理解し、適切に選択している開発者は意外と少ない印象です。本記事では、両技術の仕組みと特徴を比較し、ユースケースに応じた選択指針を提示します。

WebSocketの仕組みと特徴

通信の仕組み

WebSocketは、HTTPのアップグレードリクエストを介して確立される双方向の全二重通信プロトコルです。初回のハンドシェイク後は、単一のTCP接続上でクライアントとサーバーが自由にメッセージを送受信できます。HTTPとは異なるプロトコル（ws:// または wss://）で動作し、ヘッダーのオーバーヘッドが小さいため、高頻度の通信に適しています。

WebSocketの利点

• 双方向通信：クライアントからもサーバーからも任意のタイミングでデータを送信可能
• 低レイテンシ：接続確立後はHTTPヘッダーのオーバーヘッドがなく、高速な通信が実現できる
• バイナリデータ対応：テキストだけでなくバイナリデータも効率的に送受信可能
• プロトコルの柔軟性：サブプロトコルを定義することで、アプリケーション固有の通信仕様を策定できる

WebSocketの課題

• 接続管理の複雑さ：切断検知、再接続処理、コネクションプーリングなどを自前で実装する必要がある
• ステートフル：サーバー側で接続状態を保持するため、スケールアウト時にセッションの分散が課題になる
• プロキシやファイアウォールとの相性：企業ネットワークやCDNによってはWebSocket通信がブロックされることがある
• HTTP/2の恩恵を受けにくい：WebSocketは独自プロトコルのため、HTTP/2の多重化機能を直接活用できません

Server-Sent Events（SSE）の仕組みと特徴

通信の仕組み

SSEは、HTTPプロトコル上で実現されるサーバーからクライアントへの単方向通信技術です。通常のHTTPレスポンスとしてContent-Type: text/event-streamを返し、接続を維持したままサーバーがイベントデータを逐次送信します。標準のHTTPプロトコル上で動作するため、既存のインフラとの互換性が高いのが特徴です。

SSEの利点

• シンプルさ：HTTPベースのため、特別なプロトコルやライブラリが不要でブラウザのEventSource APIで簡単に利用可能
• 自動再接続：ブラウザが切断を検知すると自動的に再接続を試みる機能が標準搭載
• イベントID管理：各イベントにIDを付与でき、再接続時に最後に受信したIDをサーバーに送信することでデータの欠損を防げる
• HTTP/2との親和性：標準HTTPのため、HTTP/2の多重化機能を自然に活用できる
• インフラ互換性：プロキシ、CDN、ロードバランサーなど既存インフラとの互換性が高い

SSEの制約

• 単方向通信：サーバーからクライアントへの一方通行でして、クライアントからの送信には別途HTTPリクエストが必要
• テキストのみ：バイナリデータを直接送信できない（Base64エンコードは可能だが非効率）
• 接続数制限：HTTP/1.1ではブラウザのドメインあたり同時接続数制限に引っかかる場合がある

ユースケース別の選択指針

WebSocketを選ぶべきケース

双方向のリアルタイム通信が必要な場合は、WebSocketが最適です。具体的なユースケースとしては以下が挙げられます。

• チャットアプリケーション：ユーザー間のメッセージ送受信が頻繁に発生する
• オンラインゲーム：プレイヤーの操作とゲーム状態の同期に低レイテンシが求められる
• 共同編集ツール：複数ユーザーの編集操作をリアルタイムで同期する必要がある
• IoTデバイス制御：デバイスとの双方向通信が求められる

SSEを選ぶべきケース

サーバーからのプッシュが主体で、クライアントからの送信頻度が低い場合はSSEが適しています。

• ニュースフィードやタイムライン：新着情報のプッシュ配信
• ダッシュボードの自動更新：メトリクスやステータスのリアルタイム更新
• 通知システム：ユーザーへの通知配信
• 長時間処理の進捗表示：ファイルアップロードや分析処理の進捗報告
• LLMのストリーミング応答：生成AIの応答をトークン単位で逐次表示する

パフォーマンスとスケーラビリティの比較

パフォーマンス面では、高頻度の双方向通信ではWebSocketが圧倒的に有利です。一方、サーバーからの単方向プッシュのみの場合、SSEとWebSocketのパフォーマンス差はほとんどありません。

スケーラビリティについては、SSEの方がシンプルに扱えます。標準HTTPで動作するため、既存のロードバランサーやリバースプロキシがそのまま使え、ステートレスなHTTP/2接続の恩恵を受けられます。WebSocketのスケールアウトには、Redis PubSubなどを使ったメッセージブローカーの導入が必要になることが多いです。

まとめ：要件に基づいた合理的な選択を

WebSocketとSSEは対立する技術ではなく、それぞれ得意な領域を持つ補完的な技術です。双方向通信が必要ならWebSocket、サーバーからのプッシュが主体ならSSEという基本原則を押さえた上で、インフラ要件やチームの技術スタックを考慮して選択しましょう。迷ったときは、よりシンプルなSSEから始めて、要件の変化に応じてWebSocketに移行するアプローチも現実的な選択肢です。技術選定は常にトレードオフでして、要件に最も適した技術を合理的に選ぶことが重要です。