# WebRTCファイル転送の仕組み Source: https://help.strongfolder.com/ja/guides/how-webrtc-file-transfer-works/ Updated: 2026-11-05 > WebRTCファイル転送は3つの段階で動きます。シグナリングサーバーが2つのブラウザを引き合わせ、STUNとICEが家庭のルーター（NAT）を越えるネットワーク経路を探し、直接の経路がなければTURNリレーに切り替えます。そしてブラウザ同士がDTLSで暗号化されたデータチャネルを開き、ファイルを直接またはリレー経由で、保存することなく少しずつ送ります。 WebRTCファイル転送を使うと、2つのブラウザが、クラウドストレージにアップロードすることなく互いにファイルを 送れます。簡単そうに聞こえますが、インターネットは家庭のパソコン同士が直接やり取りするようにはつくられて いませんでした。このガイドでは、StrongFolderを例に、実際に何が起きているのか — シグナリング、NAT、STUN、 ICE、TURN、DTLS、データチャネル — をわかりやすく解説します。 **Key facts** - **WebRTC**は、2台のデバイス間で直接の暗号化接続を行うためのブラウザ標準です。ファイル転送ツールはその**データチャネル**を使います。 - **シグナリング**がブラウザ同士を引き合わせ、**STUN**と**ICE**がルーター（**NAT**）を越える経路を探し、直接の経路がなければ**TURNリレー**が通信を中継します。 - **暗号化：** すべてのデータチャネルは**DTLS**を使います。WebRTCに暗号化なしのモードはありません。 - StrongFolderは、WebRTCの上でPeerJSを使い、StrongFolderのシグナリングサーバー、公開STUNサーバー（Googleのものを含む）、独自のTURNリレーを利用しています。ファイルがStrongFolderのサーバーにアップロード・保存されることはありません。 - ファイルは送信者のディスクから受信者のディスクへ少しずつ送られ、その間、送信者はオンラインのままです。 ## WebRTCとは何ですか？ [WebRTC](https://help.strongfolder.com/en/glossary/#webrtc)（Web Real-Time Communication）は、W3CとIETFが標準化した、ブラウザ間の リアルタイム接続のためのブラウザAPIとネットワークプロトコルの集まりです。Chrome、Edge、Firefox、Safari、 Operaのすべてが対応しています。ビデオ通話や音声通話のためにつくられましたが、あらゆるバイナリデータを運ぶ **データチャネル**も備えています。ファイルとは、まさにそのバイナリデータです。 重要なのは、WebRTC接続がいったん確立すると、データはサーバーのストレージではなく**2つの端末の間**を流れる ことです。これが[ブラウザでのP2Pファイル転送](https://help.strongfolder.com/en/guides/p2p-file-transfer/)を可能にしています。 ## なぜ2つのブラウザは単純に直接つながれないのですか？ 自分専用のパブリックアドレスを持っているデバイスがほとんどないからです。あなたのノートパソコンは、家庭の ルーター、オフィスのファイアウォール、携帯キャリアのネットワークの内側にあります。ルーターは [NAT](https://help.strongfolder.com/en/glossary/#nat)（Network Address Translation）を行い、多数のプライベートなデバイスで1つのパブリック IPアドレスを共有し、内側から送ったものへの応答だけを通します。 そのため、2つのブラウザは、ファイルのデータを流す前に3つの問題に直面します。 1. **互いに到達する方法**がわからない — どちらも相手の存在を知らない。 2. **自分のパブリックアドレス**がわからない — 知っているのは192.168.1.20のようなプライベートアドレスだけ。 3. ルーターが**要求していない外部からの通信をブロック**するかもしれない。 WebRTCは、それぞれの問題を別々の仕組みで解決します。 ## WebRTCファイル転送はステップごとにどう動きますか？ 「共有」をクリックしてから最後の1バイトまでの全体の流れは次のとおりです。 ``` Sender browser Servers Recipient browser ────────────── ─────── ───────────────── 1. Choose files ──── metadata ──▶ Signaling server ◀──────── 2. Open link ──────── 3. Offer (SDP) ─────────────────▶ Signaling ──────────────────▶ Answer (SDP) 4. Ask STUN "how do I look?" ─▶ STUN servers ◀─ Ask STUN "how do I look?" 5. ICE candidates ◀─────────────▶ Signaling ◀──────────────────▶ ICE candidates 6. ICE checks: try LAN → direct internet → TURN relay 7. DTLS handshake ◀════════════ encrypted ═════════════════▶ DTLS handshake 8. Data channel: file chunks ═══(direct or via TURN relay)══▶ written to disk ``` **ステップ1〜2 — シグナリング。** 送信者がファイルを選び、サービスはリンクに必要なメタデータを記録します。 受信者がリンクを開くと、両方のブラウザが[シグナリング](https://help.strongfolder.com/en/glossary/#signaling)サーバーに接続します。WebRTCは シグナリングの方式を定めていません。StrongFolderはPeerJSと独自のシグナリングサーバーを使っています。 **ステップ3 — オファーとアンサー。** 一方のブラウザが、SDP（Session Description Protocol）で**オファー**を 作成します。「データチャネルを使いたい。これが私の暗号化のフィンガープリントと機能です」という内容です。 もう一方は**アンサー**で応えます。どちらもシグナリングサーバーを通って送られます。 **ステップ4 — STUN。** 各ブラウザは[STUN](https://help.strongfolder.com/en/glossary/#stun)サーバーに「私はどのアドレスとポートから来て いるように見えますか？」と尋ねます。その答えが、ルーターによって割り当てられたパブリックアドレスです。 STUNサーバーが扱うのはごく小さなリクエストだけで、ファイルのデータは扱いません。StrongFolderは、Googleの ものを含む公開STUNサーバーと独自のSTUNサーバーを使っています。 **ステップ5 — ICE候補。** 各ブラウザは、自分に到達できる可能性のある方法、つまり**候補**を集めます。 ローカルネットワークのアドレス（host）、STUNで得たパブリックアドレス（server-reflexive）、TURNリレー上の アドレス（relayed）です。これらの候補をシグナリング経由で交換します。 **ステップ6 — 接続チェック。** [ICE](https://help.strongfolder.com/en/glossary/#ice)（Interactive Connectivity Establishment）が候補の 組み合わせを試し、使えるもののうち最適なものを選びます。両方のデバイスが同じWi-Fiにあれば、ローカルの経路が 選ばれます。ルーターが許せば、インターネット上の直接経路（「ホールパンチング」）が選ばれます。直接の経路が どれも使えなければ、リレー経由の経路が使われます。 **ステップ7 — DTLS。** データが流れる前に、ブラウザ同士は[DTLS](https://help.strongfolder.com/en/glossary/#dtls)ハンドシェイク （UDP向けに調整されたTLS）を行い、証明書のフィンガープリントがオファーとアンサーに含まれるものと一致するかを 確認します。これ以降、すべてが暗号化されます。 **ステップ8 — データチャネル。** DTLSの上ではSCTPが動き、データチャネルに確実で順序どおりの配信を 提供します。StrongFolderでは、受信者のブラウザがファイルを要求し、送信者のブラウザがディスクからファイルを 少しずつ読み込んで送り、受信者は届いた断片を順にディスクに書き込みます。そのため、非常に大きなファイルでも メモリに収める必要はありません。 ## STUN、TURN、ICEなどの用語はどういう意味ですか？ | 用語 | 役割 | ファイルのデータが見えるか | 標準 | |---|---|---|---| | シグナリング | ブラウザ間でオファー、アンサー、候補を受け渡す | 見えない | 標準化されていない（アプリごと） | | NAT | 1つのパブリックIPを多数のデバイスで共有するルーターの機能 | — | — | | STUN | ブラウザに自分のパブリックアドレスとポートを伝える | 見えない | IETF RFC 8489 | | ICE | 候補を集めて使える経路を選ぶ | 見えない | IETF RFC 8445 | | TURN | 直接の経路が使えないときに通信を中継する | 暗号化されたパケットのみ | IETF RFC 8656 | | DTLS | 接続を暗号化する（UDP向けのTLS） | 暗号化する | IETF RFC 9147（1.3）、RFC 6347（1.2） | | SCTPデータチャネル | 断片を確実に順序どおり届ける | 運ぶ（暗号化された状態で） | IETF RFC 8831 | これらはすべて[用語集](https://help.strongfolder.com/en/glossary/)で簡単に説明しています。 ## TURNリレーはいつ使われ、何が見えるのですか？ リレーはあくまで代替手段であり、標準ではありません。ICEがリレーを使うのは、直接の候補の組み合わせが どれもつながらない場合だけです。典型的には、**シンメトリックNAT**のネットワーク（一部の携帯キャリア）、 外向きのUDPをブロックする**企業のファイアウォール**、特定のVPNなどです。 直接接続できない場合（厳しい企業ファイアウォールや一部のモバイル回線など）、暗号化された ストリームはStrongFolderのリレー（TURN）サーバーを経由します。リレーはデータを中継する だけで、保存はしません。 リレーはDTLSで暗号化されたパケットを受け取り、そのまま転送します。リレーにわかるのは、通信が流れていること、 その量とタイミングであり、中身ではありません。リレー経由の転送は、すべてのバイトがリレーを余分に往復する ため、直接の転送より遅くなることがあります。転送が異常に遅い場合は、別のネットワークを試してください。 オフィスのネットワークでは直接つながらなくても、スマートフォンのテザリングや自宅のWi-Fiなら直接つながる ことがよくあります。 [今すぐファイルを送る](https://strongfolder.com) ## WebRTCの暗号化はどのくらい安全ですか？ WebRTCでは暗号化が必須で、暗号化されていないデータチャネルを開く方法はありません。DTLSは2つのブラウザが 取り決めた最新の暗号方式を使い、接続ごとに新しい鍵が作られます。 ただし、すべてのWebRTCサービスに当てはまる注意点が1つあり、正直にお伝えします。2つのブラウザは、 シグナリングサーバーを通じて交換された証明書の**フィンガープリント**で互いを確認します。つまり、サービスの シグナリングがそれを改ざんしないことを信頼していることになります。だからこそStrongFolderは、自社の保護を **転送中の暗号化**と説明しており、あなたが鍵を持つエンドツーエンド暗号化とも、「ゼロ知識」とも呼んで いません。「安全」の意味をより広く知りたい方は、[安全なファイル共有](https://help.strongfolder.com/en/guides/secure-file-sharing/)と [セキュリティとプライバシー](https://help.strongfolder.com/en/security/)をお読みください。 ## なぜ送信者のブラウザを開いたままにする必要があるのですか？ 送信者のブラウザこそがファイルの送り元だからです。代わりに頼れるサーバー上のコピーはありません。データ チャネルが送信者のディスクから断片を読み込めるのは、タブが開いていてデバイスが起動している間だけです。 受信者のダウンロードが終わるまで、送信者のブラウザタブを開いたままオンラインにしておく必要があります。ファイルはサーバーではなく送信者のデバイスから届くためです。 これにどう備えるかは [送信者がオンラインでいる理由](https://help.strongfolder.com/en/guides/why-sender-stays-online/)で解説しています。 ## WebRTCファイル転送の速度はどのくらいですか？ 決まった速度はありません。上限は経路上で最も遅い区間、多くの場合は送信者の**上り**速度で決まります。目安として、 1 GBは50 Mbpsで約2.7分、100 Mbpsで約80秒、高速なローカルネットワークなら1分を大きく下回ります。実際の転送は、 プロトコルのオーバーヘッド、ディスクの速度、そしてリレーを使う場合は余分な経由によって、これらの数値より やや遅くなります。1つのリンクを複数の受信者が開けます。各受信者は送信者から直接ダウンロードします。 同時に複数のダウンロードがあると、送信者の上り帯域を分け合います。 ## まとめ WebRTCファイル転送は、短い交渉と、その後に続く長い暗号化されたストリームでできています。シグナリングが ブラウザ同士を引き合わせ、STUNとICEがNATを越える経路を探し、最後の手段としてTURNが中継し、DTLSで暗号化 されたデータチャネルがファイルをディスクからディスクへ運びます。送信者として実際に何を意味するのかを知るには、 まず[ブラウザでのP2Pファイル転送](https://help.strongfolder.com/en/guides/p2p-file-transfer/)と [StrongFolderの仕組み](https://help.strongfolder.com/en/how-it-works/)をお読みください。 ## FAQ ### WebRTCのデータチャネルとは何ですか？ データチャネルは、音声や映像ではなく任意のバイト列を2つのブラウザ間で運ぶWebRTCの機能です。UDPの上のDTLSの上でSCTPが動くため、暗号化されており、確実で順序どおりの配信に設定できます。これはファイル転送に必要な性質です。 ### STUNとTURNの違いは？ STUNサーバーは、ブラウザに自分のパブリックアドレスがどう見えるかを伝えるだけで、2つのブラウザはそれをもとに直接接続を試みます。ファイルのデータはSTUNを通りません。TURNサーバーはリレーで、直接の経路が使えないときに暗号化されたストリームがここを通ります。StrongFolderは独自のTURNリレーを運用しており、データを中継するだけで保存しません。 ### シグナリングサーバーは私のファイルを見ますか？ いいえ。シグナリングサーバーがブラウザ間で受け渡すのは、接続のためのメッセージ（セッション記述とネットワークの候補）だけです。ファイルのデータは、直接またはTURNリレー経由でデータチャネルを流れます。 ### WebRTCファイル転送は暗号化されていますか？ WebRTCはすべてのデータチャネルをDTLSで暗号化するため、どの接続でもファイルのストリームは転送中に暗号化されます。 WebRTCでは暗号化されていないデータチャネルは使えません。鍵は2つのブラウザが取り決め、そのフィンガープリントはシグナリングを通じて送られます。そのため、これはあなたが鍵を管理するエンドツーエンド暗号化ではなく、転送中の暗号化です。 ### WebRTC転送が失敗したり遅かったりするのはなぜ？ 多くの場合、ネットワーク経路が原因です。厳しいファイアウォールやVPNが直接のUDP通信をブロックするため、接続がTCP経由のTURNリレーに切り替わるか、まったく接続できなくなります。別のネットワーク（スマートフォンのテザリングなど）を試すか、VPNをオフにするか、IT部門にWebRTCの許可を依頼してください。 ### TURNリレーは私のファイルを読めますか？ リレーは、2つのブラウザ間でDTLS暗号化されたパケットを中継します。リレーに見えるのは暗号化された通信、サイズ、タイミングであり、ファイルの中身ではありません。また、StrongFolderのリレーは中継したデータを保存しません。