WebRTCでNAT越えが必要になる理由｜ブラウザ同士の通信の裏側

この記事の最終更新日: 2026年6月2日

WebRTCを使うと、ブラウザ同士で音声通話、ビデオ通話、画面共有、データ通信などを行えます。

たとえば、次のような機能です。

• ブラウザだけでビデオ通話する
• 音声通話をリアルタイムで行う
• 画面共有をする
• P2Pでファイルやデータを送る
• オンラインゲームのようなリアルタイム通信を行う

WebRTCの特徴は、可能であればブラウザ同士が直接通信することです。

しかし、実際にはこの「直接通信」が簡単ではありません。

なぜなら、多くのユーザーはNATの内側にいるからです。

この記事では、WebRTCでなぜNAT越えが必要になるのか、ブラウザ同士の通信の裏側で何が起きているのかを初心者向けにわかりやすく解説します。

WebRTCとは？

WebRTCとは、Webブラウザやアプリ間でリアルタイム通信を行うための技術です。

WebRTCを使うと、専用アプリをインストールしなくても、ブラウザ上で音声や映像をやり取りできます。

代表的な用途は次のとおりです。

• ビデオ通話
• 音声通話
• 画面共有
• ライブ配信の一部機能
• P2Pデータ通信
• ブラウザゲーム
• オンライン面談
• リモートサポート

通常のWebアプリでは、ブラウザはサーバーと通信します。

ブラウザ
↓
Webサーバー

一方、WebRTCでは、可能であればブラウザ同士が直接通信します。

ブラウザA
↓ ↑
ブラウザB

この「ブラウザ同士で直接つながる」という点が、WebRTCの大きな特徴です。

普通のWeb通信とWebRTCの違い

まず、通常のWeb通信を見てみましょう。

たとえば、ブラウザでWebサイトを見る場合です。

ブラウザ → Webサーバー
Webサーバー → ブラウザ

この場合、通信は基本的にブラウザからサーバーへ向かって始まります。

ブラウザがHTTPリクエストを送り、サーバーがレスポンスを返します。

GET /index.html
↓
HTMLを返す

このような通信では、NATがあっても問題になりにくいです。

なぜなら、通信を始めるのはユーザー側のブラウザだからです。

WebRTCではブラウザ同士が通信したい

WebRTCでは、ブラウザAとブラウザBが直接通信しようとします。

ブラウザA ←→ ブラウザB

たとえば、ビデオ通話の場合、次のようなデータをリアルタイムに送受信します。

• 音声データ
• 映像データ
• 画面共有データ
• データチャネルの通信

これらをすべてサーバー経由にすると、サーバーの負荷や通信遅延が大きくなります。

そこでWebRTCでは、可能であれば端末同士が直接通信します。

ユーザーAのブラウザ ←→ ユーザーBのブラウザ

しかし、ここで問題になるのがNATです。

NATとは？

NATとは、IPアドレスを変換する仕組みです。

家庭や会社のネットワークでは、多くの場合、端末にはプライベートIPアドレスが割り当てられます。

PC：192.168.1.10
スマホ：192.168.1.11
タブレット：192.168.1.12

これらのIPアドレスは、家庭内や社内ネットワークでは使えます。

しかし、インターネット上ではそのまま使えません。

そこで、ルーターがNATによって、プライベートIPアドレスをグローバルIPアドレスに変換します。

192.168.1.10
↓ NAT
203.0.113.10

これにより、家庭内の端末はインターネットに接続できます。

NATがあると何が困るのか？

NAT環境では、内側から外側への通信は比較的簡単です。

自宅PC → Webサーバー

自宅PCが通信を開始すると、ルーターはその通信を覚えます。

そのため、Webサーバーから返ってきたレスポンスを自宅PCに戻せます。

問題は、外側から内側へ通信したい場合です。

外部の端末 → 自宅PC

この場合、ルーターは困ります。

なぜなら、外部から来た通信を内部のどの端末へ届ければよいかわからないからです。

192.168.1.10：PC
192.168.1.11：スマホ
192.168.1.12：ゲーム機

外から見えるのは、基本的にルーターのグローバルIPアドレスだけです。

そのため、外部から突然通信が来ても、ルーターはそれを内部端末へ渡せないことがあります。

WebRTCでNAT越えが必要になる理由

WebRTCでは、ブラウザ同士が直接通信しようとします。

しかし、多くのブラウザはNATの内側にいます。

たとえば、ユーザーAもユーザーBも自宅のWi-Fiを使っているとします。

ブラウザA
↓
家庭Aのルーター（NAT）
↓
インターネット
↓
家庭Bのルーター（NAT）
↓
ブラウザB

この状態で、ブラウザAとブラウザBが直接通信するには、NATを越えて相手に通信を届ける必要があります。

しかし、NATがあると、外部から内部端末へ直接通信しにくくなります。

そのためWebRTCでは、NAT越えが必要になります。

NAT越えとは？

NAT越えとは、

NATの内側にある端末同士が、インターネット越しに通信できるようにするための技術や工夫

です。

WebRTCでは、主に次のような技術が使われます。

• STUN
• TURN
• ICE

ざっくり言うと、役割は次のとおりです。

STUN：
外から見た自分のIPアドレスとポート番号を調べる

TURN：
直接通信できないときに通信を中継する

ICE：
使える通信経路を探して、最適なものを選ぶ

WebRTCでは、これらを組み合わせて、ブラウザ同士が通信できる経路を探します。

WebRTC通信の全体像

WebRTCでは、いきなりブラウザ同士が通信できるわけではありません。

大まかには、次のような流れになります。

1. ブラウザAが通信候補を集める
2. ブラウザBも通信候補を集める
3. シグナリングサーバーを通じて候補を交換する
4. 使える経路を試す
5. 最適な経路で通信する

ここで重要なのが、シグナリングサーバーとICEです。

シグナリングサーバーとは？

WebRTCでは、通信を始める前に、ブラウザ同士が接続情報を交換する必要があります。

たとえば、次のような情報です。

• 自分が使える通信候補
• 音声や映像の設定
• コーデック情報
• セッション情報
• ICE candidate

この情報交換を行うための仕組みが、シグナリングです。

シグナリングには、WebSocketやHTTPなどが使われることがあります。

ブラウザA
↓
シグナリングサーバー
↓
ブラウザB

注意点として、シグナリングサーバーはWebRTCの通信そのものを中継するとは限りません。

主な役割は、接続前の情報交換です。

ICEとは？

ICEとは、WebRTCで通信経路を探す仕組みです。

ICEは、簡単に言うと、

使えそうな通信経路を集めて、実際に試し、最適な経路を選ぶ仕組み

です。

WebRTCでは、複数の通信候補を集めます。

代表的な候補は次の3つです。

ICEはこれらの候補を使って、どの経路なら通信できるかを試します。

host candidateとは？

host candidateは、端末自身が持っているローカルIPアドレスです。

たとえば、自宅PCでは次のようなアドレスになります。

192.168.1.10:50000

同じLAN内にいる相手なら、このアドレスで通信できる場合があります。

たとえば、同じ社内ネットワーク内の端末同士であれば、host candidateで通信できる可能性があります。

しかし、インターネット越しの相手には、プライベートIPアドレスはそのまま使えません。

192.168.1.10

このアドレスは、自宅ネットワークの中でしか意味がないためです。

server reflexive candidateとは？

server reflexive candidateは、STUNサーバーを使って取得した外部アドレスです。

たとえば、ブラウザAがSTUNサーバーに問い合わせるとします。

ブラウザA → STUNサーバー

STUNサーバーは、通信元を見て次のように返します。

あなたは外から見ると 203.0.113.10:62001 に見えています

この 203.0.113.10:62001 のようなアドレスが、server reflexive candidateです。

これは、NATを通ったあとに外から見えるIPアドレスとポート番号です。

WebRTCでは、この情報を相手に伝えて、直接通信できるかを試します。

relay candidateとは？

relay candidateは、TURNサーバー経由で通信するための候補です。

直接通信できない場合、TURNサーバーを中継して通信します。

ブラウザA
↓
TURNサーバー
↓
ブラウザB

この経路は、直接通信よりも遅延やコストが増えやすいです。

しかし、NATやファイアウォールが厳しい環境でも通信できる可能性が高くなります。

そのため、relay candidateは接続成功率を上げるための重要な候補です。

STUNは何をしているのか？

WebRTCにおけるSTUNの役割は、外から見た自分のIPアドレスとポート番号を調べることです。

ブラウザ自身は、自分のローカルIPアドレスは知っています。

192.168.1.10:50000

しかし、外部からどう見えているかはわかりません。

そこでSTUNサーバーに問い合わせます。

ブラウザ → STUNサーバー

STUNサーバーは、外から見たアドレスを返します。

203.0.113.10:62001

この情報を使って、ブラウザ同士が直接通信を試します。

TURNは何をしているのか？

TURNは、直接通信できないときに通信を中継します。

たとえば、ブラウザAとブラウザBが直接通信できなかったとします。

ブラウザA ←×→ ブラウザB

この場合、TURNサーバーを経由します。

ブラウザA → TURNサーバー → ブラウザB

TURNサーバーは、実際の音声や映像データを中継します。

そのため、STUNよりもサーバー負荷や通信コストが高くなります。

なぜ最初からTURNだけ使わないのか？

TURNを使えば接続成功率は上がります。

では、なぜ最初からすべてTURN経由にしないのでしょうか。

理由は、主に次の3つです。

1. サーバーコストが高い

TURNサーバーは実データを中継します。

ビデオ通話では、音声や映像データが大量に流れます。

すべての通信をTURN経由にすると、サーバーの帯域コストが大きくなります。

2. 遅延が増える

直接通信なら、ブラウザAとブラウザBが直接データをやり取りできます。

ブラウザA ←→ ブラウザB

TURNを使うと、必ずサーバーを経由します。

ブラウザA → TURNサーバー → ブラウザB

経路が増えるため、遅延が大きくなることがあります。

3. サーバーが障害点になる

すべての通信をTURNに依存すると、TURNサーバーが落ちたときに通信できなくなります。

そのため、可能なら直接通信し、必要な場合だけTURNを使う方が効率的です。

WebRTCではどの経路が選ばれるのか？

WebRTCでは、ICEによって複数の候補を試し、使える経路を選びます。

一般的には、次のような優先順位になります。

1. 同じネットワーク内で直接通信
2. NAT越しに直接通信
3. TURNサーバー経由で通信

直接通信できるなら、その方が低遅延で低コストです。

直接通信できない場合に、TURNサーバー経由へフォールバックします。

つまりWebRTCは、

できるだけ直接通信し、無理なら中継する

という設計になっています。

ブラウザ同士の通信は本当にサーバーを使わないのか？

WebRTCでは、ブラウザ同士が直接通信できる場合があります。

ただし、完全にサーバー不要というわけではありません。

通常、WebRTCでは少なくとも次のサーバーが関係します。

つまり、WebRTCは

通信データは直接やり取りできる場合がある

というだけで、

最初から最後までサーバーが不要

という意味ではありません。

WebRTCの通信の流れを具体例で見る

ユーザーAとユーザーBがブラウザでビデオ通話を始めるとします。

1. ユーザーAが通話を開始する

ユーザーAのブラウザは、音声・映像の準備をします。

カメラ
マイク
通信設定

2. ICE candidateを集める

ブラウザは、自分が使えそうな通信候補を集めます。

host candidate
server reflexive candidate
relay candidate

ここでSTUNやTURNが使われます。

3. シグナリングサーバーで情報を交換する

ユーザーAとユーザーBは、シグナリングサーバーを通じて接続情報を交換します。

ユーザーA → シグナリングサーバー → ユーザーB
ユーザーB → シグナリングサーバー → ユーザーA

4. 接続できる経路を試す

ブラウザ同士は、交換した候補を使って通信できるか試します。

直接通信できるか？
NAT越しに届くか？
TURN経由なら届くか？

5. 最適な経路で通信する

直接通信できれば、その経路が使われます。

ユーザーA ←→ ユーザーB

直接通信できなければ、TURNサーバー経由になります。

ユーザーA → TURNサーバー → ユーザーB

NAT越えが失敗するとどうなる？

NAT越えがうまくいかないと、WebRTCでは次のような問題が起きます。

• 通話が開始できない
• 相手の映像が表示されない
• 音声だけ聞こえない
• 片方向だけ通信できない
• 接続に時間がかかる
• 特定のネットワークだけ使えない
• 会社Wi-Fiでは失敗するがモバイル回線では成功する

このような問題は、アプリ側のバグだけでなく、NATやファイアウォール、TURN設定の問題で起きることがあります。

企業ネットワークでWebRTCがつながりにくい理由

企業ネットワークでは、セキュリティのために通信制限が厳しく設定されていることがあります。

たとえば、次のような制限です。

• UDP通信がブロックされている
• 特定ポートしか通さない
• プロキシ経由でしか外部通信できない
• ファイアウォールが厳しい
• 外部サーバーへの接続先が制限されている

WebRTCはリアルタイム性を重視するため、UDPを使うことが多いです。

しかし、UDPが使えない環境では、直接通信が失敗しやすくなります。

このような場合、TURN over TCPやTURN over TLSが必要になることがあります。

TURN over TCP / TLSとは？

通常、WebRTCではUDP通信が使われることが多いです。

UDPは低遅延で、音声・映像通信に向いています。

しかし、ネットワーク環境によってはUDPが通らないことがあります。

その場合、TURNサーバーをTCPやTLSで使うことがあります。

TURN over UDP
TURN over TCP
TURN over TLS

特にTURN over TLSを443番ポートで使う構成は、厳しいネットワークでも通りやすくなる場合があります。

ただし、TCPやTLSを使うと、UDPより遅延が増えることがあります。

そのため、基本はUDPで試し、必要に応じてTCP/TLSへフォールバックする設計になります。

WebRTCでよくある誤解

WebRTCは完全なP2Pだからサーバー不要

これは誤解です。

WebRTCでは、通信データがP2Pになる場合があります。

しかし、接続準備にはシグナリングサーバー、STUNサーバー、場合によってはTURNサーバーが必要です。

STUNを設定すれば必ず接続できる

これも誤解です。

STUNは外部アドレスを調べるだけです。

NATやファイアウォールの状況によっては、STUNだけでは通信できません。

TURNは不要

小規模な検証ではTURNなしでも動くことがあります。

しかし、本番サービスではTURNがないと、一部のユーザーが接続できない可能性があります。

特に企業ネットワーク、公共Wi-Fi、モバイル回線などでは、TURNが重要になります。

TURNを使えば常に高品質になる

TURNは接続成功率を上げますが、直接通信より遅延やコストが増える場合があります。

そのため、TURNは万能の高速化手段ではなく、直接通信できない場合のフォールバックです。

開発者が押さえるべきポイント

WebRTCを実装する開発者は、次の点を押さえておくとよいです。

• WebRTCはブラウザ同士の直接通信を試す
• しかし多くのユーザーはNATの内側にいる
• NAT越えのためにSTUN・TURN・ICEが使われる
• STUNは外部アドレス確認用
• TURNは直接通信できない場合の中継用
• ICEは通信経路を集めて選ぶ仕組み
• シグナリングサーバーは接続情報の交換に必要
• 本番ではTURNサーバーを用意した方が接続成功率が上がる
• TURNは認証、監視、帯域制限、冗長化が重要
• 企業ネットワーク向けにはTURN over TCP/TLSも検討する

特に本番運用では、

自分の環境では動いた

だけでは不十分です。

ユーザーのネットワーク環境はさまざまなので、STUN/TURN/ICEを含めた設計が重要になります。

WebRTCでNAT越えが必要になる理由を一言で言うと

WebRTCでNAT越えが必要になる理由は、次のようにまとめられます。

ブラウザ同士が直接通信したいのに、多くのブラウザはNATの内側にいて、外部から直接アクセスしにくいから

通常のWeb通信では、ブラウザからサーバーへ通信するため問題になりにくいです。

しかしWebRTCでは、ブラウザ同士が通信しようとするため、NATの壁を越える必要があります。

まとめ

WebRTCは、ブラウザ同士で音声、映像、データをリアルタイムにやり取りできる強力な技術です。

しかし、実際のユーザー環境では、多くの端末がNATの内側にいます。

そのため、ブラウザ同士で直接通信するには、NAT越えが必要になります。

WebRTCでは、主に次の技術が使われます。

STUN：
外から見たIPアドレスとポート番号を調べる

TURN：
直接通信できないときに通信を中継する

ICE：
使える通信経路を集めて、最適な経路を選ぶ

シグナリング：
接続に必要な情報を相手と交換する

WebRTCの裏側では、単にブラウザ同士がすぐにつながっているわけではありません。

実際には、候補を集め、情報を交換し、直接通信を試し、失敗した場合はTURNサーバーで中継するという複雑な処理が行われています。

初心者のうちは、まず次のように覚えておくとよいでしょう。

WebRTCはブラウザ同士で直接通信したい。しかしNATがあると直接つながらないことがある。そのためSTUN・TURN・ICEを使って通信経路を探す。

この理解があると、WebRTCの接続エラー、STUN/TURNサーバーの設定、NAT越えのトラブルシュートがかなり理解しやすくなります。

daigoro

大阪のエンジニアが書いているブログ。