同じWi-Fiでファイルを直接送る方法｜LocalSendの実力と使えない場面

ローカル転送とは何か

ファイルを誰かに渡すとき、多くの人はまずクラウドを経由します。ギガファイル便にアップロードする、Googleドライブに置いて共有リンクを出す、メールに添付する。いずれも「一度インターネット上のサーバーにファイルを預け、相手がそこから取り出す」という流れです。

ローカル転送はこの経路を使いません。送り手の端末と受け手の端末が、同じネットワークの中で直接つながってファイルを渡します。サーバーを経由しないので、アップロードとダウンロードの二度手間が発生せず、外部にファイルのコピーが残りません。

AppleのAirDrop、Androidのクイック共有（旧Nearby Share）が代表例ですが、これらは基本的に同じOS同士でしか使えません。OSをまたいで同じことをしたい、という需要に応えているのがLocalSendのようなアプリです。

LocalSendとは

LocalSendは、同一ネットワーク内の端末同士でファイルやテキストを直接やり取りできる無料アプリです。オープンソースで開発されており、「クロスプラットフォームなAirDropの代替」を掲げています。

• 対応OS：Windows・macOS・Linux・Android・iOS
• 料金：無料（オープンソース）
• アカウント：不要
• インターネット接続：不要（同じLANにいれば足りる）
• 容量上限：サービス側の制限なし（実質的には回線速度と保存先の空き容量次第）
• 保存期間：概念そのものがない（サーバーに置かないため）

使い方は、両方の端末でアプリを開くだけです。同じネットワークにいる端末が一覧に出てくるので、送りたい相手を選んでファイルを投げます。事前のペアリングやアカウント紐付けはありません。

暗号化とPIN

転送はHTTPSで暗号化されます。証明書は各端末が自分で生成する自己署名証明書で、外部の認証局は関与しません。ローカルネットワーク内の通信を保護するための仕組みで、公開サーバーの証明書とは目的が違います。

加えて、受信時にPINコードの入力を求める設定があります。オフィスや教室のように同じネットワークに多数の端末がいる環境では、意図しない相手に送ってしまう／送られてしまう事故を防げます。

アプリを持っていない相手に渡す「リンクで共有」

受け取る側にアプリが入っていない場合の逃げ道として、「リンクで共有（Share via link）」という機能があります。送り手側でダウンロード用のURLを発行し、相手はブラウザでそれを開くだけでファイルを受け取れます。

ただしここで発行されるURLは http://192.168.x.x:53317/... のような、ローカルIPアドレスとポート番号の組み合わせです。この形式には後述する固有の問題があります。

なぜローカル転送は速いのか

クラウド経由の転送は、ファイルサイズの2倍のデータが回線を通ります。送り手がアップロードし、受け手がダウンロードするからです。しかも多くの家庭用回線は上り（アップロード）が下りより遅く設計されているため、大きいファイルではアップロードが待ち時間の大半を占めます。

ローカル転送では、データはLANの中だけを一度通ります。有線や5GHz帯のWi-Fiであれば、インターネット回線より桁違いに速いことも珍しくありません。1GBの動画を渡すときの体感差はかなり大きくなります。

さらに副次的な利点として、保存期間を気にする必要がありません。クラウド転送サービスは「3日で消える」「7日で消える」といった期限があり、相手が取り忘れると再送になります。ローカル転送は転送が終われば完了です。

「同じネットワークにいる」という前提

ここまでは強みの話です。実際に使ってみると、うまくいかない場面のほとんどが同じ原因に行き着きます。両方の端末が同じネットワークにいて、かつ端末同士が直接通信できること——この前提が満たされていないケースです。

1. ゲストWi-Fiのクライアント分離

カフェ・ホテル・コワーキングスペース・イベント会場のWi-Fiは、「クライアント分離（AP isolation、プライバシーセパレータ）」が有効になっていることが多いです。同じアクセスポイントにつながっていても、端末同士の通信はブロックされ、インターネットへの通信だけが許可されます。

この設定はセキュリティ上まったく正しい判断です。不特定多数が同じネットワークに入る場所で端末同士が見えてしまうのは危険だからです。つまり、外出先の共用Wi-Fiでローカル転送を使うのは、原理的に期待できません。

2. 会社や学校のネットワーク

端末の自動検出は、ネットワーク内へのマルチキャスト／ブロードキャスト通信に依存しています。管理されたネットワークではこの種の通信が遮断されていたり、VLANで部署ごとにセグメントが分けられていたりするため、相手の端末が一覧に出てきません。

IPアドレスを手動で指定すれば通る場合もありますが、そもそも業務端末に自由にアプリを入れられない環境も多く、その場合は選択肢に入りません。

3. 回線が別々のとき

相手が自宅のWi-Fi、自分はモバイル回線。あるいは片方が会社のネットワーク、もう片方が外出先。この状態では同一ネットワークが成立しないため、ローカル転送は使えません。ネットワークをまたぐ用途は、そもそもこの方式の設計範囲外です。

4. 双方が同時にその場にいる必要がある

クラウド転送は非同期です。送り手がアップロードしておけば、相手は都合のよいタイミングで取りに行けます。ローカル転送は同期的で、両方の端末が起動していてアプリが開いている状態が同時に必要です。「今から送るからアプリ開いて」というやり取りが前提になります。

方式ごとの比較

残るのは「リンクをどう伝えるか」の問題

比較表の最後の行が、この記事でいちばん伝えたい点です。

ローカル転送でもクラウド転送でも、多くの場面で最後に残る手間は「相手にURLを伝える」ところにあります。LocalSendの「リンクで共有」で発行される http://192.168.1.24:53317/... のようなURLは、まさにその典型です。同じ部屋にいる相手に対してこれを口で伝えるのは、現実的ではありません。IPアドレスの数字、コロン、5桁のポート番号、その後ろのパス。読み上げれば必ず聞き返しが発生します。

結果として、そのURLを渡すためにチャットやメールを開くことになります。ファイル転送はクラウドを経由しないのに、URLを渡すためにクラウドのサービスを使う——という構図です。相手の連絡先を知らなければ、それすらできません。

パシる（PASHIRU）はこの一点だけを解決するツールです。URLを貼り付けると6桁の数字が発行され、相手は pashiru.com でその6桁を入力するだけで同じURLを開けます。「さんきゅう、いちに、ぜろご」と口で言えば伝わる長さです。連絡先の交換もアプリのインストールも要りません。

つまり、両者は競合しません。ファイル本体はLocalSendが直接運び、そのリンクをパシる（PASHIRU）が口頭で運ぶという組み合わせが成立します。

状況別の使い分け

まとめ

LocalSendのようなローカル転送アプリは、条件が合えば間違いなく最速の手段です。クラウドを経由しない、容量制限がない、保存期間を気にしなくてよい、データが外部に残らない。無料でOSをまたいで使えることも含めて、常備しておく価値のあるアプリだと言えます。

一方で「同じネットワークにいて、端末同士が直接通信できる」という前提は、外出先や管理されたネットワークでは意外なほど簡単に崩れます。ローカル転送とクラウド転送は優劣ではなく、前提の違いで選ぶものです。

そしてどちらの方式でも、最後に残る「URLを相手に届ける」という一手間は別の問題として残ります。ファイル転送サービスの選び方についてはギガファイル便だけで大丈夫？国内ファイル送信サービスを徹底比較で詳しく整理しているので、あわせて参考にしてください。