マルチキャストは「同じデータを、受け取りたい複数の機器へ一度の送信で届ける」仕組みで、今もっとも活躍しているのは同じLAN（セグメント）の中です。IPv6 の近隣探索、mDNS による機器の発見、VRRP による冗長化、社内の映像配信などが代表例で、反対にインターネット越しの配信やクラウド上のサーバー間通信では、使えない・使わないほうがよい場面が多くあります。この記事では、使いどころと避けるべき場面を整理し、手元の環境でマルチキャストが動いているかを確認する方法まで説明します。
マルチキャストの基本：アドレスと届く範囲
マルチキャストでは、送信者は特定の機器ではなく「グループのアドレス」宛てに送り、そのグループに参加した機器だけが受け取ります。IPv4 では 224.0.0.0/4、IPv6 では ff00::/8 がマルチキャスト用の範囲です。
使いどころを考えるうえで大事なのは「どこまで届くか」です。
- 224.0.0.0/24（IPv4）・ff02::/16（IPv6）：同じリンク内だけで使う範囲で、ルーターは転送しません。mDNS や VRRP、OSPF などはここを使います。
- 239.0.0.0/8（IPv4）：組織内で自由に使える管理用の範囲です。社内アプリで独自にマルチキャストを使うなら、まずここから選びます。
- ff05::/16 や ff0e::/16（IPv6）：アドレスの中にサイト内・グローバルといった範囲（スコープ）が含まれている形式です。
同じLANを越えて届けるには、経路上のルーターが PIM などのマルチキャスト経路制御に対応し、設定されている必要があります。ここが、マルチキャストの使える場所を限定する最大の理由です。
使いどころ1：意識せずに使っているLAN内の仕組み
多くの人は、気付かないうちにマルチキャストを使っています。
- IPv6 の近隣探索（NDP）：IPv4 の ARP にあたる処理を、全ノード宛て（ff02::1）や要請ノード宛てのマルチキャストで行っています。IPv6 では、マルチキャストを止めると通信そのものが成り立ちません。
- mDNS（224.0.0.251 / ff02::fb、UDP 5353）：
.localの名前解決や、プリンター・AirPlay・Chromecast などの機器の発見に使われます。 - SSDP（239.255.255.250、UDP 1900）：UPnP 対応機器の発見に使われます。
- ルーティングプロトコル：OSPF は 224.0.0.5 と 224.0.0.6 を使って隣接ルーターとやり取りします。
これらは「同じLANにいる相手を、相手のアドレスを知らない状態で見つける」用途で、マルチキャストがもっとも向いている使い方です。
使いどころ2：サーバーの冗長化とクラスター
サーバー運用で身近なのが、keepalived などで使われる VRRP です。2台のサーバーやロードバランサーで仮想IPを共有し、現用機が 224.0.0.18 宛てに定期的に広告を送り、届かなくなると待機機が仮想IPを引き継ぎます。
クラスター製品の中にも、メンバーの発見や死活監視にマルチキャストを使えるものがあります。ただし、最近のソフトはユニキャストを既定にしているものもあり、たとえば Corosync 3 系は knet というユニキャストの通信方式が標準です。使う製品の現行の文書で、既定の方式を確かめてから設計してください。
使いどころ3：多数の受信者への同時配信
社内の映像配信、IPTV、デジタルサイネージ、金融の相場配信など、「同じストリームを大勢が同時に受け取る」用途では、マルチキャストの効果が大きく出ます。送信側の帯域は受信者の数に関係なく1本分で済みます。
この用途では、ネットワーク側の準備が欠かせません。
- IGMP（IPv6 では MLD）：受信する機器が「このグループに参加したい」とルーターやスイッチに伝える仕組みです。
- IGMP スヌーピング：スイッチが参加状況を見て、参加しているポートにだけ転送する機能です。無効だと、マルチキャストがブロードキャストのように全ポートへ流れます。
- IGMP クエリア：スヌーピングを有効にしたセグメントに、参加状況を定期的に問い合わせる役（ルーターやスイッチ）がいないと、一定時間後に配信が止まることがあります。「最初は見えるのに数分で止まる」という症状の典型的な原因です。
使わないほうがよい場面
インターネット越しの配信：一般的なインターネット接続では、マルチキャストは事業者をまたいで届きません。Web サイトや動画の配信は、ユニキャストと CDN を組み合わせるのが現実的です。
クラウド上のサーバー間通信：主要なクラウドの仮想ネットワークは、標準ではマルチキャストを通さない設計が一般的です。AWS では Transit Gateway のマルチキャスト機能のように限定的な対応がありますが、対応範囲や条件はサービスごとに異なり、変わることもあります（2026年10月現在）。クラウドで VRRP を使う場合は、keepalived の unicast_peer のようにユニキャストに切り替える設定を使うか、クラウドが提供する仮想IPの付け替え機能を使います。
WordPress のサーバー群：複数台の WordPress でキャッシュの削除やセッションを共有したい場合も、マルチキャストではなく、Redis や Memcached などの共有ストア、あるいは各サーバーへのユニキャストの通知で組むのが一般的です。到達範囲やファイアウォールの制約を受けにくく、障害時の調査もしやすくなります。
手元で動いているかを確認する
Linux では、インターフェースが参加しているグループを次のように確認できます。
# 参加しているマルチキャストグループ（IPv4 / IPv6）
ip maddr show dev eth0
# マルチキャストのパケットを観察する
sudo tcpdump -ni eth0 'ip multicast or ip6 multicast'
# mDNS だけを見る
sudo tcpdump -ni eth0 udp port 5353社内アプリで独自に使う前に、受信できるかを小さなスクリプトで試すと、ネットワーク側の問題とアプリ側の問題を分けられます。以下は Python の標準ライブラリだけで動く受信側の例です。
import socket
import struct
GROUP = "239.1.2.3" # 組織内で使う管理用の範囲から選ぶ
PORT = 5007
sock = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
sock.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
sock.bind(("", PORT))
# グループに参加する（この時点で IGMP の参加通知が送られる）
mreq = struct.pack("4s4s", socket.inet_aton(GROUP), socket.inet_aton("0.0.0.0"))
sock.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, mreq)
while True:
data, addr = sock.recvfrom(1500)
print(addr, data)送信側は同じグループとポートに sendto するだけですが、IP_MULTICAST_TTL の値で届く範囲が変わります。既定は 1（同じセグメント内だけ）なので、ルーターを越えたい場合は値を上げ、経路上のルーターの設定も確認します。
受信できないときは、ファイアウォールで該当ポートの UDP が許可されているか、複数のインターフェースがある環境で意図したインターフェースでグループに参加しているか、スイッチの IGMP スヌーピングとクエリアの状態はどうか、の順に確認すると原因にたどり着きやすくなります。ネットワーク機器の設定を変える場合は、事前に設定を保存し、業務時間外や検証環境で試してください。
まとめ
- マルチキャストがもっとも向いているのは、同じLANの中で「相手を知らずに見つける」「大勢に同時に届ける」用途です。
- NDP・mDNS・VRRP・OSPF など、意識せずに使っている仕組みも多く、むやみに遮断すると通信が壊れます。
- インターネット越しや一般的なクラウドの仮想ネットワークでは使えないことが多いため、ユニキャストや CDN、共有ストアで設計します。
- 配信用途では IGMP スヌーピングとクエリアの設定が、安定して届くかどうかを左右します。