NAT越えで使われるUDPホールパンチングとは？仕組みをやさしく解説

この記事の最終更新日: 2026年7月15日

インターネット通信を学んでいると、「NAT越え」や「UDPホールパンチング」という言葉を見かけることがあります。

特に、次のような技術に関わると出てきやすい用語です。

• WebRTC
• オンラインゲーム
• P2P通信
• 音声通話アプリ
• ビデオ通話アプリ
• VPN
• チャットアプリ
• ファイル共有アプリ

UDPホールパンチングは、簡単に言うと NAT配下にいる端末同士が、直接通信するための工夫 です。

ただし、名前だけ聞くと少し難しく感じます。

「UDPで穴を開ける？」
「NATに穴を開けるって危なくない？」
「ポート開放とは違うの？」

このように感じる人も多いと思います。

この記事では、UDPホールパンチングの仕組みを、できるだけやさしく整理します。

まずNATとは何か

UDPホールパンチングを理解するには、まずNATを理解する必要があります。

NATとは、ざっくり言うと 家庭や会社の中のプライベートIPアドレスを、インターネット用のグローバルIPアドレスに変換する仕組み です。

たとえば、自宅のPCやスマホには次のようなIPアドレスが割り当てられます。

192.168.0.10
192.168.0.11
192.168.0.12

これらはプライベートIPアドレスです。

そのままではインターネット上から直接アクセスできません。

そこで、ルーターが通信を中継します。

自宅PC
  ↓
家庭用ルーター（NAT）
  ↓
インターネット

このとき、ルーターは内部の端末から外部への通信を、グローバルIPアドレスに変換して送信します。

NATがあると外から直接接続しにくい

NATは便利ですが、P2P通信では問題になります。

たとえば、AさんとBさんがどちらも家庭用ルーターの内側にいるとします。

AさんのPC
  ↓
Aさんのルーター
  ↓
インターネット
  ↑
Bさんのルーター
  ↑
BさんのPC

この状態で、AさんのPCからBさんのPCへ直接通信したいとします。

しかし、BさんのPCはプライベートIPアドレスを使っています。

インターネット側から見ると、BさんのPCに直接アクセスする方法がありません。

Bさんのルーターが「この通信は内側のどの端末に届ければいいのか」を知らないからです。

そのため、普通は外部からNAT配下の端末へ直接通信することは難しいです。

ポート開放をすれば通信できるが、手間が大きい

NAT配下の端末に外部からアクセスしたい場合、昔からよく使われる方法が ポート開放 です。

ポート開放とは、ルーターに対して次のように設定することです。

外から来た 50000番ポートへの通信は、
内側の 192.168.0.10 に転送する

これにより、外部から家庭内のPCにアクセスできます。

ただし、ポート開放には問題もあります。

• ユーザーがルーター設定を変更する必要がある
• 設定方法がルーターごとに違う
• セキュリティリスクがある
• モバイル回線や企業ネットワークでは設定できないことがある
• 一般ユーザー向けアプリでは現実的ではない

そこで登場するのが、UDPホールパンチングです。

UDPホールパンチングとは

UDPホールパンチングとは、NAT配下の端末同士が 互いに外向き通信を行うことで、NATに一時的な通信経路を作り、直接通信を成立させる技術 です。

ポイントは、外部から無理やり入ってくるのではなく、内側の端末から先に外へ通信を出す ことです。

NATは、内部の端末が外へ通信すると、その戻り通信を受け取るために一時的な対応表を作ります。

この対応表を利用して、相手からの通信を受け取れるようにするのがUDPホールパンチングです。

NATの対応表をイメージする

たとえば、自宅PCが外部サーバーにUDP通信を送ったとします。

192.168.0.10:50000
  ↓
ルーター
  ↓
203.0.113.10:62000
  ↓
外部サーバー

このとき、ルーターは内部で次のような対応表を作ります。

内部: 192.168.0.10:50000
外部: 203.0.113.10:62000

これは、「外部から 203.0.113.10:62000 に戻ってきた通信は、内部の 192.168.0.10:50000 に届ければよい」という意味です。

この対応表がある間は、外部からのUDPパケットが内側の端末に届く可能性があります。

UDPホールパンチングは、この性質を利用します。

UDPホールパンチングの登場人物

UDPホールパンチングでは、基本的に次の3者が登場します。

Aさんの端末
Bさんの端末
中継用サーバー

ここでいう中継用サーバーは、音声データや映像データをずっと中継するためのサーバーとは限りません。

主な役割は、AさんとBさんがお互いの外部IPアドレスとポート番号を知るための 待ち合わせ場所 です。

このようなサーバーは、ランデブーサーバーと呼ばれることもあります。

WebRTCの文脈では、STUNサーバーが似た役割を持ちます。

UDPホールパンチングの流れ

UDPホールパンチングの流れを簡単に整理すると、次のようになります。

1. AさんがサーバーにUDP通信を送る
2. BさんもサーバーにUDP通信を送る
3. サーバーがAさんとBさんの外部IP・ポートを把握する
4. サーバーが互いの接続情報を教える
5. AさんとBさんが互いにUDPパケットを送る
6. NATの対応表ができる
7. 直接通信できる可能性がある

図にすると、次のようなイメージです。

Aさんの端末 ---- UDP ----> サーバー
Bさんの端末 ---- UDP ----> サーバー

サーバー:
Aさんの外部アドレスをBさんへ教える
Bさんの外部アドレスをAさんへ教える

Aさんの端末 <---- UDP ----> Bさんの端末

重要なのは、AさんもBさんも 先に外向きのUDP通信を出す ことです。

これにより、それぞれのNATに一時的な通信経路が作られます。

なぜ「ホールパンチング」と呼ばれるのか

ホールパンチングは直訳すると「穴あけ」です。

ただし、実際にルーターに恒久的な穴を開けるわけではありません。

イメージとしては、NATに対して一時的な通り道を作るようなものです。

通常:
外部 → NAT → 内部端末
この通信は通りにくい

UDPホールパンチング:
内部端末 → NAT → 外部
この通信を先に発生させることで、
戻り通信用の一時的な通り道を作る

つまり、「外から入る穴を勝手に開ける」というより、内側から通信を出した結果として、NATに一時的な通路ができる と考えると分かりやすいです。

TCPではなくUDPが使われる理由

UDPホールパンチングという名前の通り、この仕組みではUDPがよく使われます。

UDPはTCPと違い、接続確立の手順が軽いプロトコルです。

TCPでは、通信開始時に3ウェイハンドシェイクがあります。

SYN
SYN-ACK
ACK

一方、UDPにはこのような接続確立手順がありません。

UDPは、パケットを送るだけです。

そのため、NATの対応表を作りやすく、P2P通信の経路確立に使いやすいという特徴があります。

特に、リアルタイム性が重要な通信ではUDPがよく使われます。

• 音声通話
• ビデオ通話
• オンラインゲーム
• ライブ配信
• WebRTC

多少のパケットロスよりも、遅延の少なさが重要な場面ではUDPが向いています。

UDPホールパンチングの具体例

たとえば、AさんとBさんがビデオ通話を始めるとします。

AさんもBさんも、それぞれ家庭用ルーターの内側にいます。

Aさん: 192.168.1.10
Bさん: 192.168.2.20

このままでは、AさんはBさんのプライベートIPアドレスに直接アクセスできません。

そこで、まず両者が待ち合わせサーバーにアクセスします。

Aさん → サーバー
Bさん → サーバー

サーバーから見ると、AさんとBさんは次のように見えます。

Aさん: 203.0.113.10:50001
Bさん: 198.51.100.20:60001

サーバーは、この情報を互いに教えます。

AさんにBさんの外部アドレスを教える
BさんにAさんの外部アドレスを教える

その後、AさんとBさんが互いにUDPパケットを送ります。

Aさん → Bさんの外部アドレスへUDP送信
Bさん → Aさんの外部アドレスへUDP送信

このとき、双方のNATに一時的な対応表が作られ、うまくいけば直接通信が成立します。

UDPホールパンチングが成功する条件

UDPホールパンチングは便利ですが、必ず成功するわけではありません。

成功しやすい条件は次の通りです。

• UDP通信が許可されている
• NATのマッピングが比較的安定している
• 片方または両方のNATが厳しすぎない
• ファイアウォールでUDPがブロックされていない
• 一定時間内に双方がパケットを送り合える
• 外部IPアドレスとポート情報を正しく交換できる

つまり、UDPホールパンチングは「NAT越えを必ず成功させる魔法」ではありません。

ネットワーク環境によっては失敗します。

失敗しやすいケース

UDPホールパンチングが失敗しやすい代表例は、次のような環境です。

1. Symmetric NAT

NATの種類によっては、UDPホールパンチングが難しくなります。

特に問題になりやすいのが Symmetric NAT です。

Symmetric NATでは、通信先ごとに異なる外部ポートが割り当てられることがあります。

たとえば、同じ内部端末からの通信でも、接続先によって外部ポートが変わります。

A → サーバー: 203.0.113.10:50001
A → Bさん:   203.0.113.10:50088

この場合、サーバーが見たポート番号と、実際にBさんへ通信するときのポート番号が異なる可能性があります。

すると、相手に教えた接続情報が使えず、UDPホールパンチングに失敗しやすくなります。

2. UDPがブロックされている

企業ネットワークや学校、病院、公共Wi-Fiなどでは、UDP通信が制限されていることがあります。

この場合、そもそもUDPパケットが通らないため、UDPホールパンチングは成功しません。

WebRTC通話で「会社のネットワークだけ音声がつながらない」という場合、UDP制限が原因のことがあります。

3. CGNAT配下にいる

モバイル回線や一部のインターネット回線では、ユーザーがさらに大きなNATの内側にいることがあります。

これはCGNATと呼ばれることがあります。

スマホ
  ↓
家庭用ルーターまたは端末側NAT
  ↓
通信事業者のNAT
  ↓
インターネット

NATが多段になると、P2P通信の成立が難しくなる場合があります。

4. NATの対応表がすぐ消える

NATの対応表は永続的ではありません。

一定時間通信がないと消えます。

UDPは接続状態を持たないため、NAT側が「もうこの通信は不要」と判断すると、対応表を削除します。

そのため、UDPホールパンチングでは定期的に小さなパケットを送って、経路を維持することがあります。

これは keep-alive と呼ばれます。

STUN・TURN・ICEとの関係

UDPホールパンチングを調べていると、STUN、TURN、ICEという言葉も出てきます。

それぞれの関係を簡単に整理します。

WebRTCでは、ICEが通信経路を探す中で、STUNやTURNを使います。

直接P2P通信できる場合は、UDPホールパンチングのような仕組みによって経路が成立します。

直接通信できない場合は、TURNサーバーを経由します。

理想:
端末A <---- 直接通信 ----> 端末B

直接通信できない場合:
端末A <---- TURNサーバー ----> 端末B

TURNを使うと通信は安定しやすくなりますが、サーバー側の帯域やコストが増えます。

そのため、まずは直接通信を試し、無理ならTURNにフォールバックする構成が一般的です。

UDPホールパンチングとWebRTC

WebRTCでは、ブラウザ同士で音声や映像をやり取りできます。

しかし、実際には多くのユーザーがNAT配下にいます。

そのため、WebRTCではNAT越えが重要です。

WebRTCでは、ICEという仕組みを使って通信経路を探します。

1. ローカル候補を集める
2. STUNで外部から見えるアドレスを取得する
3. TURNがあれば中継候補も集める
4. 相手と候補情報を交換する
5. 通信できる候補ペアを試す
6. 最適な経路で通信する

この中で、直接通信を成立させるための考え方としてUDPホールパンチングが関係します。

WebRTCで音声が聞こえない場合、ICE接続が失敗していることがあります。

その裏側では、NAT越えがうまくいっていない可能性があります。

UDPホールパンチングとポート開放の違い

UDPホールパンチングとポート開放は、どちらもNAT越えに関係します。

しかし、考え方はかなり違います。

一般ユーザー向けのアプリで「ルーターの設定を変更してください」と案内するのは現実的ではありません。

そのため、WebRTCやオンラインゲームなどでは、UDPホールパンチングやSTUN/TURN/ICEのような仕組みが使われます。

UDPホールパンチングのメリット

UDPホールパンチングのメリットは次の通りです。

• ユーザーがルーター設定を変更しなくてよい
• P2P通信を実現しやすい
• サーバーの帯域負荷を減らせる
• TURN中継よりも遅延を抑えやすい
• 音声通話やゲームのようなリアルタイム通信に向いている

特に、直接通信できる場合は、中継サーバーを経由するよりも低遅延になる可能性があります。

また、サーバーがすべての音声・映像データを中継しなくて済むため、インフラコストの削減にもつながります。

UDPホールパンチングのデメリット

一方で、デメリットもあります。

• 必ず成功するわけではない
• NATやファイアウォールの種類に依存する
• 企業ネットワークでは失敗しやすい
• UDPがブロックされていると使えない
• 実装やデバッグが難しい
• 接続維持のためにkeep-aliveが必要になることがある
• セキュリティ設計を誤ると不正通信の原因になる

そのため、実務ではUDPホールパンチングだけに頼るのではなく、TURNサーバーによるフォールバックも用意するのが一般的です。

UDPホールパンチングは安全なのか

「NATに穴を開ける」と聞くと、セキュリティ的に危険そうに感じるかもしれません。

ただし、UDPホールパンチングは通常、アプリが通信相手を制御したうえで、一時的な通信経路を作る仕組みです。

ポート開放のように、特定ポートを常時インターネットへ公開するものとは違います。

とはいえ、安全性を保つには設計が重要です。

たとえば、次のような対策が必要です。

• 通信相手を認証する
• 暗号化された通信を使う
• 不正な相手に接続情報を渡さない
• セッション管理を適切に行う
• 不要になった通信経路を維持し続けない
• アプリ側でアクセス制御を行う

WebRTCでは、メディア通信は暗号化される前提で設計されています。

ただし、シグナリングサーバーや認証処理の設計が甘いと、別の問題が発生する可能性があります。

実務ではUDPホールパンチングだけを意識すればよいのか

実務でWebRTCやP2P通信を扱う場合、UDPホールパンチングの概念を理解しておくことは重要です。

ただし、アプリ開発者がUDPホールパンチングを低レベルで直接実装するケースは多くありません。

多くの場合、次のような仕組みを使います。

• WebRTC
• ICE
• STUN
• TURN
• ライブラリやSDK
• SFUやメディアサーバー

そのため、実務では次のように理解するとよいです。

UDPホールパンチング:
NAT越えの基本的な考え方

STUN:
外部から見えるアドレスを知る仕組み

TURN:
直接つながらない場合の中継手段

ICE:
どの経路で通信するかを自動的に探す仕組み

WebRTC:
これらを使ってブラウザ間の音声・映像通信を実現する技術

つまり、UDPホールパンチングはWebRTCやICEの裏側にある重要な考え方の一つです。

よくある誤解

UDPホールパンチングを使えば必ずP2P接続できる？

必ずできるわけではありません。

NATの種類やネットワーク制限によっては失敗します。

そのため、TURNサーバーなどの代替経路が必要になります。

UDPホールパンチングはポート開放と同じ？

違います。

ポート開放はルーターに明示的な転送設定を入れる方法です。

UDPホールパンチングは、内側から外向きに通信することでNATの一時的な対応表を利用する方法です。

STUNサーバーがあれば必ず通信できる？

これも違います。

STUNは、自分が外部からどう見えているかを知るための仕組みです。

STUNだけでは通信できない環境もあります。

その場合はTURNが必要になります。

TURNは不要？

直接通信できる環境だけを想定するなら不要な場合もあります。

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

特に企業ネットワーク、モバイル回線、厳しいNAT環境ではTURNが重要です。

まとめ

UDPホールパンチングとは、NAT配下にいる端末同士が直接通信するために使われるNAT越えの技術です。

ポイントは、外部から無理やり接続するのではなく、双方の端末が内側から外へUDP通信を出すことで、NATに一時的な通信経路を作る という点です。

UDPホールパンチングの要点

・NAT配下の端末同士で直接通信するための工夫
・UDPを使って一時的な通信経路を作る
・待ち合わせ用のサーバーが必要になる
・ポート開放とは違い、ユーザーのルーター設定変更は基本的に不要
・WebRTCやオンラインゲームなどで重要になる
・NATやファイアウォールの種類によっては失敗する
・失敗時にはTURNサーバーによる中継が必要になる

UDPホールパンチングは、WebRTCやP2P通信を理解するうえで非常に重要な考え方です。

特に、SIP.jsやWebRTCで「接続はできているのに音声が聞こえない」「特定のネットワークだけ通話できない」といった問題を調査するとき、NAT越えの仕組みを知っていると原因を切り分けやすくなります。

UDPホールパンチングは万能ではありませんが、NAT越えを理解するための基礎として押さえておきたい技術です。

daigoro

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