P2P（ピアツーピア）ファイル転送とは？

最終更新: 2026-08-07

「P2P」という言葉はあいまいに使われがちですが、ファイル転送における本当の意味はこうです。ファイルは会社のサーバーに一度アップロードされてからダウンロードされるのではなく、一台のデバイスからもう一台へ直接送られます。途中にコピーが留まりうる寄り道はありません。

単純に聞こえますが、実際の経路は同じではありません。このページではまず TURN が予備になり得る一般的な WebRTC/ICE を説明し、そのうえで Relayium の実装を区別します。同じ LAN のブラウザは WebRTC 直結、ネットワーク間ブラウザは設計上 TURN、CLI は直接接続専用です。

P2P と一般的な方式の違い：中間の寄り道を省く

ほとんどの「ファイルを送る」ツールはアップロード方式で動きます。手元のデバイスから会社のサーバーへファイルが送られ、そこに保存され、相手はそれをダウンロードします。これは2ホップであり、しばらくの間、そのファイルの完全なコピーが他者のストレージ上に存在します——後で削除されるとしてもです。

P2P 転送はこの寄り道を省きます。手元のデバイスと相手のデバイスの間に接続が開けば、ファイルのバイトはその1ホップだけを直接流れ、他のどこも経由しません。保存すべきサーバー側のコピーも、守るべき対象も、いずれ削除すべきものもありません。そもそもアップロードされていないからです。

アップロード方式：手元のデバイス → サーバー → 相手のデバイス——2ホップで、途中に保存されたコピーがある。
P2P 方式：手元のデバイス → 相手のデバイス——1ホップで、何も保存されない。
Relayium のリアルタイムブラウザモードには2つの経路があります。同じ LAN では WebRTC が直接接続し、ネットワークをまたぐ場合は設計上 TURN でエンドツーエンド暗号文を運び、サーバー側の内容コピーや履歴は残しません。

2台のデバイスが実際にどう見つけ合うか：STUN

ここが直感的ではない部分です。手元のデバイスは、外部インターネットから自分がどう見えているかをほぼ確実に知りません——家庭用ルーターや通信キャリアのネットワークアドレス変換（NAT）の内側にあり、共有のグローバル IP の裏に隠され、ポートも動的に割り当てられます。相手のデバイスも同じ状況です。どちらも、実際に到達できるアドレスをまず知らなければ、相手に直接「電話」をかけることはできません。

そこで使われるのが STUN（NAT 越え用セッション走査ユーティリティ）です。各デバイスは軽量な STUN サーバーに短く一つの質問をします。「私はどのアドレス・ポートから来ているように見えますか？」その答えが、自分の外部向けアドレスを教えてくれます——ファイルでも、コンテンツでもなく、そこへの経路を示すのに十分なネットワーク情報だけです。両デバイスはこの情報を（接続確立の詳細だけを運び、ファイルのバイトは一切運ばないシグナリングの手順を通じて）交換し、互いのアドレスへ直接経路を開こうとします。多くの現実のケース——特に同じ Wi-Fi 上の2台や、挙動が予測可能な NAT——では、これだけで成功し、完全な直接接続が開きます。

STUN が扱うのはネットワークアドレスの取得と交換のみです——ファイルの中身やファイル名、暗号鍵は一切扱いません。
Relayium は同じ LAN のブラウザセッションで WebRTC を直接使用します。ネットワークをまたぐブラウザ経路は意図的にリレーされます。
Relayium CLI の send/receive と text は P2P 直接接続専用です。ファイルやメッセージのバイトを TURN やその他の Relayium サーバーで中継することはありません。2 つの端末が直接接続を確立できなければ、リレーへフォールバックせずにセッションは失敗します。
同じネットワーク上の2台（コード不要）は、多くの場合そもそも間に NAT がないため、最も直接的につながる傾向があります。

直接経路が見つからないとき：TURN リレー

STUN だけでは足りないこともあります。一部の NAT——特に厳しい企業ネットワークや一部の通信キャリア——は挙動が予測できず、外部から得られる情報だけでは到達可能なアドレスを発見できないことがあります。両方のデバイスがそうした NAT の内側にある場合、本当の意味での直接接続は不可能で、何かが間でトラフィックを中継する必要があります。

一般的な WebRTC/ICE では、TURN は直接経路が失敗した際の予備リレーになり得ます。Relayium のブラウザアプリはより明示的で、同じ LAN は WebRTC で直接、ネットワークをまたぐ全セッションは最初から TURN を使います。ファイルはリレー到達前にエンドツーエンド暗号化されるため、リレーは暗号文だけを運び、読み取りも復号もできません。

同一ネットワークでは Relayium はデバイス同士を直接つなぎます。ネットワークをまたぐ場合は、直接経路が見つからないことが多いため、既定で TURN リレーを使います。
リレーは暗号文だけを転送します。復号鍵を持つことは決してなく、ファイルの中身もファイル名も、中に含まれる他の情報も読めません。
Relayium CLI の send/receive と text は P2P 直接接続専用です。ファイルやメッセージのバイトを TURN やその他の Relayium サーバーで中継することはありません。2 つの端末が直接接続を確立できなければ、リレーへフォールバックせずにセッションは失敗します。

なぜこれが重要か：プライバシーと速度

プライバシー面の理屈はシンプルです。ファイルのバイトが1ホップだけ、2台のデバイス間を直接横切るとき、コピーが留まったり記録されたり他人にアクセスされたりし得るサーバー側の保存段階そのものが存在しません——そもそもそこに置かれたことがないからです。これは「いずれ削除すると約束します」とは構造的にまったく異なる保証です。

速度面の理屈も同じ論理です。アップロードしてからダウンロードする転送は、ネットワークを2回——上りと下り——横切らねばならず、送信側が完全に完了するまで受信側が開始できないこともよくあります。直接接続はネットワークを1回だけ横切り、間にスループットを制限したり独自の遅延を加えたりするサーバーがないまま、両デバイス間で遅い方の接続が許す速さでデータが連続的にストリーミングされます。

Relayium はこれをどう組み合わせているか

自分で確かめるために必要なもの

同時に画面を見られる2台の端末——ノートパソコンとスマートフォンの組み合わせが最適です。
小さなファイル1つ。ここで見るのは接続がどの経路を通ったかであって、速度ではありません。
2台が同じ Wi-Fi にある時間と、別々のネットワークにある時間。スマートフォンの Wi-Fi を切ってモバイル回線にするだけで足ります。

同じネットワーク上の2台で relayium.com を開くと、たいていは自動的に見つけ合います——アカウントもコードも不要、インストールするものも何もありません。これがローカルネットワークのケースで、多くの場合 STUN すら不要です。異なるネットワーク上の相手にインターネット越しに送る場合はペアリングコードを使います。送信者がサインインしてコードを生成する（または QR コードのオプション付きでリンクを共有する）と、相手が参加した時点で、転送は暗号化 TURN リレー経由で行われます——予測しづらい NAT を越える最も確実な経路で、リレーが扱うのは暗号文だけです。受信者はアカウント不要のままです。

リアルタイム経路が開けば、最大1,000ファイルが選択された経路を継続的に流れ、各ファイルを SHA-256 で検証します。Relayium はサーバー側のリアルタイム内容コピーや転送履歴を保持しません。相手がオフラインなら、ゼロ知識の保存リンクという別モードを使います。

2台を同じ Wi-Fi につないだ状態で、それぞれ Relayium を開いてファイルを送ります。
```
https://relayium.com/
```
アプリが接続に付けるラベルを読みます。同じネットワークなら「LAN直結」と表示されます。
次に2台を別々のネットワークに置き、今度はペアリングコードを使ってもう一度送ります。
```
https://relayium.com/cross-network
```
もう一度ラベルを読みます。「P2P直結」はインターネット越しに直接の経路が見つかったこと、「中継」は見つからず、暗号化されたリレーがバイトを運んだことを意味します。
どちらが出たか、そのときどのネットワークの組み合わせだったかを控えておきます。それが、この記事の冒頭の問いに対する、当社の説明ではなく自分の目で確かめた答えです。

ラベルが教えてくれること

同じネットワークなら「LAN直結」になります。ネットワークをまたぐと「P2P直結」か「中継」のどちらかになり、どちらになるかは設定した何かではなく、その2つのネットワーク次第です。

「中継」は失敗ではありません。フォールバックが存在して機能しているということであり、リレーは終始暗号文しか運びません——この記事の TURN の節が説明している状況を、内側から見たものです。

ラベルが思っていたものと違うとき

初めて見る人が意外に思うのは、たいてい次の3つです。どれも直すべき不具合ではありませんが、どれも名前を言えるようにしておく価値があります。

見えるもの、確認すること、その意味

ネットワークをまたぐと必ず「中継」で、「P2P直結」にならない。

https://relayium.com/cross-network   # the path label reads the same on both ends

両端がモバイル回線か、キャリアグレード NAT の内側にないかを確認してください。直接の経路が見つからない最も一般的な理由です。直すべきものはありません。これは設計どおりのフォールバックで、リレーは暗号文しか運ばず、同じ2台でも同一ネットワーク上なら引き続き直結で、無料のままです。

同じ Wi-Fi なのに「LAN直結」にならない。

https://relayium.com/   # both devices on one Wi-Fi, and the path label never says LAN direct

そのネットワークがクライアント同士を分離していないか確認してください。ゲスト用 Wi-Fi や、多くのホテル・オフィスのネットワークは端末間の通信をそもそも遮断します。そこでは2台は互いをまったく見つけられないため、ローカルでの到達性に依存しないネットワーク越しのペアリングコード方式を使ってください。

経路ラベルがまったく表示されない。

https://relayium.com/   # there is no path label until the two ends have connected

このラベルは接続に名前を付けるものなので、接続が成立して初めて現れます。両端が互いを見つける前は名付ける対象がなく、「そもそも始まらない転送」は「予想外の経路を通った転送」とは別の問題です。

よくある質問

P2P とエンドツーエンド暗号化は同じことですか？

関連はしていますが同じではありません。P2P は端点間の通信を表し、全ホップが直接とは限りません。TURN がトラフィックを運ぶこともあります。暗号化は中間者が読めるかを表します。Relayium は同じ LAN で WebRTC 直結、ネットワークをまたぐ場合はエンドツーエンド暗号化 TURN を使い、リレーは読み取りも復号もできません。

P2P 転送はそもそもサーバーに触れることがあるのですか？

小さなシグナリングサーバーが2台のデバイスが互いのアドレスを見つけるのを助けますが、それが見るのは接続確立の情報だけで、ファイルのバイトは一切見ません。ブラウザでネットワークをまたぐ場合は、設計上つねに TURN リレーが暗号化されたファイルデータを転送しますが、それでも扱うのは復号できない暗号文だけです。

そもそもなぜ直接接続が失敗することがあるのですか？

一部のネットワーク——厳しい企業ファイアウォールや一部の通信キャリアの NAT に多い——は、外部から得られる情報だけでは到達可能なアドレスを発見できないような構造になっています。それを毎回20秒前後かけて確かめるより、Relayium のブラウザ版はネットワークをまたぐ転送を最初からすべてリレー経由にしています——つまりそれらを運ぶのは、失敗した直接接続の試行ではなくリレーです。

リレーを経由すると P2P 転送は遅くなりますか？

リレーはデータが通過する余分な1ホップであり、専用サーバーではなく共有サーバーであるため、多少の遅延は増える可能性があります。それでも一般には、アップロードしてからダウンロードする流れより速いです。ファイルが完全にサーバーに届くのを待たずにダウンロード側が開始できるからです。

P2P 転送には双方ともアカウントが必要ですか？

同じネットワーク上の2台であればアカウントはまったく不要です。ペアリングコードで異なるネットワーク間に送る場合は送信者のサインインが必要ですが、どちらの経路でも受信者はアカウント不要です。

実際に試してみませんか？2台のデバイスで Relayium を開き、暗号化されたリアルタイムセッションを始めてください。

Relayium を今すぐ試す