web会議が社内ネットワークでつながらない原因と、中継で越える作り
2026年9月12日
web会議が社内ネットワークでつながらないとき、「回線が遅い」と「そもそも映像が来ない」は別の問題です。遅いのは帯域の話で、来ないのは通り道が塞がれている話です。上位の記事は前者の対策で埋まっていますが、商談で本当に困るのは後者のほうで、しかも塞いでいるのは相手の会社の設定なので、営業側では触れません。
この記事では、まず「ページは開くのに映像だけ来ない」がなぜ起きるかを短く説明します。次に、相手の会社の設定を変えられない営業側が実務で詰まる点を整理します。後半は、自分たちのツールで直接つながらないときだけ外の中継点を通す作りにした理由と、そのときに何をどの順で試しているかを、実際に動いているコードの値つきで書きます。
「遅い」と「来ない」は原因が違います
上位の記事が挙げる原因は、回線の混雑、古いWi-Fi規格やLANケーブル、OS更新やファイル転送との取り合い、電子レンジなどの電波干渉です（出典）。どれも「映像は来るが、途切れる・遅れる」の原因で、対処は帯域を空けるか経路を変えることです。その場で打てる手の順番は回線が不安定なときの記事に書きました。
「来ない」は別です。会社のネットワークには、外との通信を選別するファイアウォールがあり、web会議が使う通信の種類（UDP）や通り道（ポート）が許可されていないと、ページは開けるのに映像と音声だけが届きません。Google Meet のヘルプも、ネットワーク転送のタイムアウトやファイアウォールのエラーが出たときは必要な UDP か TCP のポートが塞がれている可能性があるとして、管理者に連絡するよう案内しています（出典）。
つまり上位の答えは「管理者にポートを開けてもらう」です。正しいのですが、商談ではそれができません。
実務で詰まるのは、塞いでいるのが「相手の会社」だという点です
1. 相手のIT部門に、初回商談の前に頼めない
自社の網なら管理者に頼めます。詰まるのは、お客様が社内の端末から参加するときです。相手の会社のファイアウォールを営業側が変えることはできず、「御社のネットワーク管理者にポート開放を依頼してください」と初回の商談前に言うわけにもいきません。
2. ページが開くので、回線のせいだと思って再読み込みを繰り返す
招待URLは開ける。名前も入れられる。入室まで進む。それなのに相手の映像が出ない。この状態は、ページの読み込み（HTTPS）は通っているのに映像の通り道（UDP）だけ止められているときの典型です。回線が遅いのだと思って再読み込みしても、何度やっても同じ結果になります。
3. 確かめられる時間が、商談の最初の数分しかない
対面の商談と違って、つながらなければ何も始まりません。原因の切り分けに使えるのは開始時刻からの数分で、相手の会社の設定を聞き出す余裕はありません。営業側でその場にできるのは、自分側の経路を変えること（スマホ回線・VPNを外す）くらいで、相手側が塞がれているときには効きません。
この3つは、営業側の工夫では解けません。つながる責任をツールの側が持つしかない、というのが自分たちの結論でした。
うちはこう作った：直接つながらないときだけ、外の中継点を通します
自分たちのツールは、映像と音声を相手のブラウザと直接やり取りする作り（WebRTC）です。通話中の映像と音声は、通話をつないでいる自分たちのサーバーを経由しません。ただし直接つなぐには、お互いのブラウザが外から見たときの自分の住所（IPアドレスとポート）を知り、それが相手から届く形になっている必要があります。
最初の段階では、この住所を調べる仕組み（STUN）だけを使っていました。ブラウザが外部のサーバーに「自分は外からどう見えているか」を聞き、その住所を相手に渡して直結する方式です。同じ社内の2台では問題なくつながりましたが、この方式には限界があります。会社のファイアウォールが UDP を通さなければ、住所が分かっても相手からの通信が届きません。
そこで、直接つながらないときだけ経路を借りる中継点（TURN）を足しました。中継点は外にある通り道で、自分の映像を一度そこに送り、相手はそこから受け取ります。直結が塞がれていても、ブラウザから中継点への通信が1本通れば会話が成立します。中継点は Cloudflare のものを使っています。
通り道は3つ用意し、どれを使うかはブラウザに任せます
中継点への通り道は、ファイアウォールの厳しさに合わせて3つ持たせています。現在の設定で相手のブラウザに渡している通り道は、次のとおりです。
- UDP の 3478番。いちばん軽く、遅延が小さい。UDP が通る網ではこれで抜けます
- TCP の 3478番。UDP を丸ごと止める網のために、TCP で同じ中継点へつなぎます
- TLS で包んだ TCP の 5349番。中身を見て弾く網のために、HTTPS と同じ暗号化で包んで通します
Cloudflare の中継点はこの3種類の通信を受け付けており、TCP には80番、TLS には443番という代わりの番号も用意されています（出典）。自分たちの設定に入れているのは上の3本で、ブラウザはこれらと直結の候補を同時に試し、つながったもののうち最も直接に近い経路を選びます。直結できるならそちらを使い、中継はあくまで最後の逃げ道です。この選び方は WebRTC の標準の仕組み（ICE）で、自分たちが順番を決めているわけではありません。
中継点は中身を読めません。WebRTC の映像と音声は暗号化が必須で、中継点は宛先を見て通すだけで暗号化の層には触れられない、と WebRTC のセキュリティ解説にあります（出典）。経路が変わっても、映像を復元できるのは相手のブラウザだけです。
中継の鍵は、ロビーを表示している間に先に取っておきます
中継点を使うには、その場限りの利用者名と鍵が要ります。自分たちはこれを、招待URLを開いた直後、ロビー画面（名前入力とカメラ確認の画面）を表示している裏で取りに行きます。鍵の有効期限は24時間（86,400秒）で、1回の商談で切れることはありません。
入室ボタンを押して接続を始めるときは、この取得が終わるのを待ってから相手との接続を組み立てます。先に接続を始めて後から鍵が届くと、最初の接続に中継の候補が入らず、塞がれた網では最初の試行が必ず失敗するからです。ロビーにいる数秒で済む作業なので、待ち時間として体感することはありません。
鍵の取得に失敗したときは、止まらずに進みます。その場合は住所を調べる仕組み（STUN、Google の公開サーバー2つ）だけで直結を試みます。中継が無くてもつながる網は多いので、鍵が取れないことを理由に入室を止めない、という判断です。
それでもつながらない網は、どのツールでもつながりません
3つの通り道をすべて塞ぐ網もあります。外向きの通信を特定の宛先にしか許さない設定なら、中継点への1本も届きません。この場合は、Meet のヘルプが書いているとおり、その会社の管理者に許可してもらう以外に方法がありません。自分たちのツールも例外ではないので、ここは正直に書いておきます。
営業側にできるのは、つながらなかったときに「回線が遅い」と切り分けを間違えないことです。ページが開いて名前まで入るのに映像が来ないなら、帯域の問題ではありません。再読み込みではなく、相手にスマホの回線からの参加を頼むほうが早く、その日の商談は進みます。
Meetnect はブラウザだけで動くオンライン商談ツールです。映像と音声は相手のブラウザと直接やり取りし、社内ネットワークで直結が塞がれているときだけ、この記事に書いた3つの通り道のどれかで中継点を通ります。中継の鍵はロビーを表示している間に取っておくので、お客様が社内の端末から参加するときも、営業側が相手の会社の設定を気にせず入室できます。