「WebSocket わかりやすく」と検索したのに、どの記事を読んでもピンとこない。
専門用語ばかりで、結局「何がすごくて、いつ使えばいいのか」が分からない。そんなモヤモヤした気持ちを、あなたも感じていませんか？
実は、この記事を書いている私も、最初はWebSocketがさっぱり分かりませんでした。
しかし、あるとき「WebSocketを電話のように考える」と聞いてから、一気に頭の中が整理されました。そこからは、チャットや通知機能の仕組みがスッと理解できるようになったのです。
この体験から、「初心者の方に説明できるレベルまでかみ砕けば、誰でもWebSocketを使いこなせる」と確信しました。
だから、この記事では、むずかしい専門知識はいっさい使わず、「電話」など身近なイメージ使ってWebSocketの考え方と使いどころを説明していきます。
WebSocketとは？
WebSocket は、Webブラウザとサーバーの間で「リアルタイムにデータをやり取りできる通信の仕組み」です。
例えると、「一度つないだら、ずっとつながったまま双方向にやり取りできる電話」のようなものです。
WebSocketを理解する為に、一般的なWebサイトで使われている「HTTP」という仕組みと比較していきます。
HTTP通信の場合
HTTP（HyperText Transfer Protocol）は、Webブラウザとサーバーが情報をやり取りするためのルール（通信プロトコル）です。
例えると、「手紙のやり取り」のように伝えたいことを１通ずつやり取りするようなイメージです。
普段、私たちが何気なく使っているWebサイトは、ほとんどが「HTTP」という仕組みで動いています。
HTTP通信の流れとしては以下です。
- ブラウザが「ページをください」とサーバーにお願いする
- サーバーが「はい、これがページです」と送り返す
- そこでいったん通信は終わる
上記のような「お願い → 返事 → 終了」という単発のやり取りが基本形です。
HTTPは、ログイン、商品情報の取得、ファイルのアップロードなど様々な機能を実現する為に使用されています。
一方で、Lineのようなチャット機能や複数人で対戦するようなオンラインゲーム、株価の自動更新画面のように、「常に状況が動き続けるもの」を扱うサービスでは、毎回Http通信のような「お願い → 返事 → 終了」というやり取りをブラウザとサーバーで行っていては機能を実現できません。
ここで登場するのがWebSocketです。
WebSocketは、一度つないだら、そのつながりを維持したまま、サーバーとブラウザがいつでも好きなタイミングでメッセージを送り合える仕組みになっています。
WebSocket通信の場合
WebSocket通信の流れとしては以下です。
接続準備
- ブラウザが「WebSocketでつなぎたいです！」とサーバーにリクエストを送ります
- サーバーが「OK、つながりました！」と応答
このやり取りを業界用語でハンドシェイク（Handshake）と呼びます。
通信開始
- 双方向にメッセージをやり取りできる
- ブラウザからサーバーへ、サーバーからブラウザへ、好きなタイミングで送信可能
- WebSocketでは、データを小さな単位（フレーム）に分けて送受信します
ポイントとしては、HTTPの場合ブラウザ→サーバーへメッセージを送ることしか出来なかったのですが、WebSocketの場合は双方向からメッセージを開始することが出来ます。
回線の健康チェック
- 長時間の通信で回線が切れないかチェックする
- 電話に例えると、長話中に「まだ聞こえますか？」と確認する行為になります。
このやり取りを業界用語でPing / Pongと呼びます。
- Ping：ブラウザやサーバーが「生きてますか？」と送る信号
- Pong：受け取った側が「はい、生きてます」と返す信号
通信終了
- WebSocket接続を閉じます
- 業界用語でClose Frame呼んでいます
ここまでのまとめ
| 段階 | 電話の例え | 技術的説明 | 業界用語 |
| 接続準備 | 電話をかける | ブラウザ→サーバーに接続リクエスト | ハンドシェイク、接続確立 |
| 通信開始 | 会話開始 | 双方向に自由にメッセージ送受信 | メッセージフレーム、データフロー |
| 健康チェック | まだ聞こえる？ | 接続が生きているか確認 | Ping / Pong |
| 通信終了 | 電話を切る | 不要な接続を閉じる | Close Frame、接続切断 |
WebSocketを使うとできること5選
チャット・DM・コメント欄
最も分かりやすいのが、チャットやDM機能です。
仕組み
- ユーザーがメッセージを送る
- ユーザーのブラウザがサーバーへメッセージを送る
- サーバーが受け取ったメッセージを他のユーザーへ送る
- 相手の画面にほぼ同時に表示される
これらはすべて、ユーザー同士のアクションをリアルタイムに共有しているからこそ成り立ちます。WebSocketを使えば、サーバー側は「新しいメッセージが届いたタイミング」で即座に各ユーザーに通知を送れるため、ポーリングのような無駄な問い合わせが減り、スムーズなチャット体験を作れます。
株価・暗号資産・スポーツスコアの自動更新
株価アプリや暗号資産の価格表示、スポーツ中継サイトのスコア表示なども、WebSocketの典型的な利用シーンです。株価やスコアは秒単位で変わることも珍しくなく、ユーザーは「ページをリロードせずに最新情報を見続けることができます。
仕組み
- サーバー側の株価などのデータが更新される
- サーバー側が各ユーザーへ株価などのデータを送信する
- ユーザーは「ページをリロードせずに最新情報を見続けることができる
WebSocketなら、サーバーが「本当に価格が変わったときだけ」メッセージを送ればよいので、とても効率的です。
オンラインゲームやマルチプレイの同期
オンラインゲームや、ブラウザ上で動くシンプルなマルチプレイゲームでも、WebSocketがよく使われます。
仕組み
- プレイヤーAがキャラクターを動かす
- プレイヤーAの位置をクライアントからサーバーへ送る
- サーバーがプレイヤーAの位置を他プレイヤーに送る
- 各プレイヤーの画面上で、ほぼ同時にAの動きが反映される
このような「複数人の動きをリアルタイムで共有する」場面では、WebSocketの「双方向・常時接続」が力を発揮します。
管理画面のメトリクス・ログのリアルタイム表示
企業のシステムでは、サーバーの状態や売上データ、アクセス数などをリアルタイムにモニタリングするダッシュボードがよく使われます。
仕組み
- サーバー側の数値が更新される
- サーバー側から各ユーザーへ数値を送信する
- 各ユーザーが都度画面をリロードせずに最新の数値を確認できる
通知バナー・トーストのリアルタイム配信
Webアプリを使っていると、画面の端に「新しいメッセージが届きました」「メンテナンスが予定されています」といった通知バナーがリアルタイムで出てくることがあります。
これも、裏ではWebSocketなどを使って、サーバーからユーザーへ即時に情報を送っているケースが多いです。
ユースケースまとめ
ここまでのユースケースをまとめると、WebSocketは主に
- 人と人のコミュニケーション（チャット・DM）
- 数値や状態が頻繁に変わる情報の共有（株価、スコア、メトリクス）
- 複数人の動きをリアルタイムに同期する仕組み（オンラインゲーム、共同編集など）
で力を発揮します。
「リアルタイムで変わるものを、なるべく無駄なくサクサク届ける技術」と理解しておくのがポイントです。
これを頭に入れたうえで、次は「じゃあHTTPやREST APIとはどう使い分けるのか？」という、実務で重要になる視点を見ていきましょう。
Httpとどう使い分ける？「WebSocketを選ぶべきシーン」の判断軸
結論から言うと、下記３つの観点で判断する必要があります。
- 情報がどれくらい頻繁に変わるか？
- ユーザーの行動がトリガーか、システム側の変化がトリガーか？
- リアルタイムであることがビジネス上どれくらい重要か？
順番に解説していきます。
情報がどれくらい頻繁に変わるか？
判断の大きなポイントは、「情報がどれくらい頻繁に変化するか」です。
- 数十秒〜数分に一度変わる程度 → Http通信で十分
- 数秒以内の変化をリアルタイムに届けたい → WebSocketを検討
たとえば、
- 「会社の基本情報を編集するフォーム」 → 頻繁に変わらないのでHttp通信でOK
- 「チャットの新着メッセージ」 → 1秒単位で変わりうるのでWebSocket向き
といったイメージです。
ユーザーの行動がトリガーか、システム側の変化がトリガーか？
もうひとつのポイントは、「誰がきっかけを作るか」です。
- ユーザーがボタンを押したときだけ処理すればいい → Http通信向き
- サーバー側で変化が起きた瞬間に知らせたい → WebSocket向き
たとえば、
- 「ユーザーがプロフィールを保存する」→ ユーザー操作がきっかけなのでHttp通信で十分
- 「他の人がタスクのステータスを変えたら、自分の画面にも自動反映したい」→ サーバー側の変化がきっかけなのでWebSocketが有効
リアルタイムであることがビジネス上どれくらい重要か？
WebSocketは便利ですが、
- 接続の切断・再接続の処理
- 負荷分散（たくさんのユーザーをさばく仕組み）
- セキュリティや認証の設計
など、Http通信に比べて考えるべきことが少し増えます。そのため、「リアルタイムであることがビジネス上どれくらい重要か？」を冷静に考える必要があります。「1分おきの更新でも十分な画面」にまでWebSocketを使うと、開発コストのわりにユーザー価値が小さいということになりかねません。
使い分けのまとめ
ここまでを踏まえると、ルールは次の通りです。
- 基本はHttp通信で作る
- 「秒単位のリアルタイム性」が本当に必要な部分だけ、WebSocketを検討する
全部を置き換える魔法の技術”ではなく、リアルタイムが本当に必要な一部にだけピンポイントで使う技術と意識しておくと、エンジニアとの会話も現実的になります。
最後に
この記事が過去の私のようなWeb開発の学習を始めたばかりの方のお役に立てると幸いです(*´꒳`*)
コメント