WebSocketとは？リアルタイム通信の仕組みとポーリングとの違い

「チャットや通知を画面に即時に出したいけれど、どう作ればいいのか分からない」「数秒ごとにサーバーへ問い合わせる作り方で本当にいいのか」。Webシステムの開発でよくいただくご相談です。

この記事では、リアルタイム通信の代表的な方法であるWebSocketについて、仕組み、ほかの方法との違い、実際に測った通信量と遅延、実装のコード、本番で運用するときの注意点までをまとめて解説します。

WebSocketとは？

WebSocketとは、ブラウザとサーバーの接続を開いたままにして、どちらからでも好きなときにデータを送れる通信方式です。仕様はRFC 6455で定められていて、主要なブラウザすべてで使えます。

普段のWebページで使うHTTPは、「ブラウザが頼んで、サーバーが返す」の1往復で終わります。サーバーの側から「新しいメッセージが来ました」と話しかける手段がありません。WebSocketは、最初の1回だけHTTPで「WebSocketに切り替えたい」と頼み、そのあとは同じ接続を使い続けます。

サーバーが切り替えを受け入れると「101 Switching Protocols（通信方式を切り替えます）」という応答が返ります。当社で動かしたテスト用サーバーでも、この応答が返ってから接続がWebSocketに切り替わることを確認しています。切り替えたあとは、HTTPのような長い付帯情報（ヘッダー）を毎回付けずに、小さな単位でデータをやり取りします。

電話にたとえると、HTTPは「用件ごとに電話をかけ直す」やり方、WebSocketは「つないだまま、話したいときに話す」やり方です。

ポーリング・SSEとWebSocketは何が違うのか？

違いは、誰が・いつデータを送れるかです。リアルタイム通信の主な方法を比べると次のようになります。

方法	仕組み	送れる向き	遅れ	向いている用途
ポーリング	ブラウザが数秒ごとに「新着ある？」と問い合わせる	ブラウザ→サーバー（返事のみ）	問い合わせ間隔の分だけ遅れる	更新が少ない画面、手軽に作りたいとき
ロングポーリング	新着が出るまでサーバーが返事を保留する	ブラウザ→サーバー（返事のみ）	小さい	WebSocketが使えない古い環境
SSE（Server-Sent Events）	HTTPの接続を開いたまま、サーバーが順次送る	サーバー→ブラウザの一方通行	小さい	通知、進捗表示、AIの回答の逐次表示
WebSocket	接続を開いたまま、双方向に送る	双方向	小さい	チャット、共同編集、ゲーム、ダッシュボード

サーバーからのお知らせだけならSSE、ブラウザからもひんぱんに送るならWebSocket、と覚えておくと選びやすくなります。

WebSocketにするとどのくらい早く届くのか？

当社の実測では、20秒ごとのポーリングだと注文が画面に届くまで平均約10秒かかったのに対し、WebSocketでは約1ミリ秒で届きました。通信量もWebSocketのほうが約3分の1で済みました。

手元のパソコンにテスト用のサーバーを立て、平均10秒に1件のペースで「新しい注文が入りました」というイベントを20回発生させました。それを、20秒ごとのポーリングとWebSocketでそれぞれ受け取り、届くまでの遅れと通信量を測った結果です（2回測定）。

項目	20秒ごとのポーリング	WebSocket
発生から画面に届くまでの平均の遅れ	8.6〜11.1秒	0.9〜1.2ミリ秒
サーバーへのリクエスト回数	10〜11回	1回（最初の接続のみ）
合計の通信量	5,045〜5,407バイト	1,804バイト（接続時のやり取りを含む）

ポーリングでは、注文が入っても次の問い合わせの時刻まで画面に出ません。20秒ごとなら最大20秒、平均で約10秒の遅れになります。電話の注文を受けた店員さんが、画面に出るまで10秒待たされるイメージです。

遅れを減らそうと間隔を1秒に縮めると、問い合わせの回数は20倍に増え、そのほとんどが「新着なし」の空振りになります。利用者の数だけ問い合わせも増えるので、サーバーの負担が大きくなります。「すぐ届く」と「サーバーに優しい」を両立できるのがWebSocketの強みです。

一方で、更新が1日に数回しかない画面なら、数十秒ごとのポーリングで十分です。WebSocketは常に接続を保つ分だけサーバーの仕組みが複雑になるので、効果が大きい画面に絞って使うのがおすすめです。

WebSocketが向いている場面・向いていない場面は？

更新がひんぱんで、遅れが目立つと困る画面に向いています。

向いている	向いていない
社内チャット、問い合わせのチャット対応	1日に数回しか更新されない一覧画面
新規注文・予約の即時通知	お知らせ記事やブログのような読み物
複数人での同時編集（在庫表、シフト表など）	送信して結果を1回受け取るだけのフォーム
現場の状況を映すダッシュボード	サーバーからの一方通行の進捗表示（SSEで十分）

WebSocketを実装する方法は？

「接続を待ち受けるサーバー」と「接続して受け取る画面」の2つを用意し、切れたときのつなぎ直しまで作るのが基本の流れです。当社でもNode.jsのライブラリ「ws」で、受け取ったメッセージを接続中の全員に配る簡単なチャットを作り、片方の画面から送ったメッセージがもう片方にすぐ届くことを確認しました。

1. 配信の仕組みを決める：自前でサーバーを用意するか、Supabase RealtimeのようなWebSocket対応のサービスを使うかを決める（次の章で比較します）
2. 何を、誰に配るかを決める：「新しい注文を、ログイン中の店舗スタッフ全員に」のように、配る内容と相手を整理する
3. 画面側で接続して受け取る：画面を開いたら接続し、届いた内容を一覧や通知に反映する
4. 切れたときのつなぎ直しを入れる：1秒、2秒、4秒…と間隔を空けて自動で再接続する
5. つなぎ直した間の取りこぼしを補う：再接続したら、切れていた間の新着を通常の通信で取り直す

特に大切なのは手順4と5です。WebSocketの接続は、スマホの回線切り替えやパソコンのスリープ、サーバーの再起動などで普通に切れます。切れたまま放置すると、画面が更新されないことに利用者が気づけません。

本番でWebSocketを運用するときの注意点は？

最大の注意点は、接続を保ち続けるサーバーが必要になることです。HTTPのように「リクエストが来たときだけ動く」サーバーレスの環境や、静的ファイルを配信するだけの環境では、WebSocketのサーバーをそのまま動かせません。

手間を抑えるなら、WebSocketに対応したサービスを使うのが現実的です（2026年10月28日時点の公式ドキュメントより）。

サービス	特徴	無料で使える範囲の目安
Supabase Realtime	データベースの変更やメッセージを、ブラウザへ即時に配信できる	同時接続200・毎秒100メッセージまで（無料プラン）
Cloudflare Durable Objects	1つのオブジェクトで多数の接続を受けられる。メッセージがない間は「休止」して課金が止まる	料金ページで確認が必要
自前のサーバー（Node.jsなど）	自由度が高い	サーバー代と、落ちたときの対応が必要

Supabaseの無料プランの範囲については、データベースを無料で運用する方法｜Supabase無料プランの制限と注意点でも詳しく解説しています。

そのほか、本番では次の点も押さえておきます。

• 必ず「wss://」で接続する：「ws://」は暗号化されません。HTTPSのページから「ws://」へ接続しようとすると、ブラウザに拒否されます
• 接続時に本人確認をする：WebSocketの接続にはログインの仕組みが自動では付きません。接続時にトークンを確認し、見せてよいデータだけを配信します
• 受信が多すぎる場合に備える：MDNの解説によると、ブラウザのWebSocketの仕組みには受信のペースを調整する仕組み（バックプレッシャー）がありません。大量のデータを流す用途では、送る側で間引くなどの対策が必要です
• 画面を離れたら接続を閉じる：開いたままの接続があると、ブラウザの「戻る」を速くする仕組みが働かない場合があります

まとめ

• WebSocketは、接続を開いたままにして双方向にすぐデータを送れる通信方式。サーバーからの一方通行ならSSE、更新が少ないならポーリングでも十分
• 当社の実測では、20秒ごとのポーリングで平均約10秒かかった遅れが、WebSocketでは約1ミリ秒になり、通信量も約3分の1で済んだ
• 本番では接続を保つサーバーが必要になるため、Supabase RealtimeやCloudflare Durable Objectsなどのサービスを使い、再接続・暗号化・本人確認を最初から組み込む

スエキチシステムでは、チャットや即時通知を組み込んだ業務システムの開発も承っています。「この画面をリアルタイムにしたい」というご相談は、システム開発のページからお気軽にどうぞ。