リアルタイム通信は『手段の選択』が9割
リアルタイム通信には WebSocket・SSE・WebRTC・ポーリングなど複数の方式があり、用途で使い分けます。「とりあえず WebSocket」は失敗の元で、要件に合った選択が重要です。本記事では、リアルタイム通信の選び方と実装パターンを編集部の視点で整理します。Webの基礎を学ぶロードマップ もご参考に。
主要な通信方式
(1) WebSocket：双方向・低レイテンシ。(2) SSE（Server-Sent Events）：サーバー→クライアント単方向。(3) WebRTC：ピアツーピアの音声・映像・データ。(4) ロングポーリング：HTTP で疑似リアルタイム。(5) HTTP Streaming：チャンク転送でストリーム。REST API設計 もご参考に。
用途別の選び方
(1) チャット：WebSocket が標準。(2) 通知：SSE で十分なことが多い。(3) 協調編集：WebSocket + CRDT。(4) ライブ配信（観客向け）：HLS/DASH の方が経済的。(5) 音声・映像通話：WebRTC。「双方向が必要か」「クライアント数の規模」で選びます。SaaS MVPの作り方 もご参考に。
WebSocket の基本
(1) HTTP からアップグレード：Upgrade ヘッダ。(2) 持続的接続：1接続で双方向通信。(3) メッセージング：テキスト・バイナリ。(4) ハートビート：接続維持確認。(5) 再接続戦略：切断時の自動復帰。Next.js学習ロードマップ もご参考に。
SSE の使い所
(1) サーバー→クライアントのみで足りる場合。(2) HTTP/2 上で効率的。(3) 自動再接続が標準。(4) ロードバランサとの相性が良い。(5) 通知・ストリーミング応答に最適。LLM のストリーミング応答は SSE が定番です。RAG実装の作り方 もご参考に。
スケーリングの戦略
(1) 接続数の上限：単一サーバーの限界。(2) Pub/Sub アーキテクチャ：Redis・Kafka 経由。(3) 水平スケール：複数サーバーで分散。(4) マネージドサービス：Pusher・Ably・Soketi。(5) エッジコンピューティング：Cloudflare Durable Objects 等。Cloudflare活用ガイド もご参考に。
協調編集の実装
(1) CRDT（Conflict-free Replicated Data Type）：競合解決の数学的構造。(2) Yjs・Automerge：CRDT ライブラリ。(3) OT（Operational Transformation）：別の解法。(4) カーソル共有：他者の位置を可視化。(5) 権限管理：読み書きの分離。Figma・Notion 等で使われている技術が CRDT です。
セキュリティ考慮
(1) 認証：接続時に検証。(2) 認可：チャンネルごとの権限。(3) レート制限：DoS 防止。(4) 入力検証：XSS・インジェクション。(5) 暗号化：wss:// で TLS。セキュリティエンジニアへの転身ガイド もご参考に。
失敗しがちなパターン
(1) WebSocket を過剰に使う：SSE で済む場合も。(2) 再接続戦略なし：切断で UX が崩れる。(3) スケールを後回し：単一サーバー前提。(4) セッション固定的な認証：認可漏れ。(5) 監視・ログ不足：障害調査が困難。対策は、(1)用途で選ぶ、(2)再接続実装、(3)Pub/Sub 設計、(4)接続時認可、(5)監視整備、です。IT・Web業界の職種完全マップ もご活用ください。