ハクソク

世界を動かす技術を、日本語で。

Localsend: AirDropのオープンソースクロスプラットフォーム代替品

2026年4月28日原文(github.com)

概要

LocalSend は、インターネット接続不要で ローカルネットワーク上のデバイス間で安全にファイルやメッセージを共有できる オープンソースアプリケーション。 REST API と HTTPS暗号化 を活用し、外部サーバーを介さず通信を実現。 クロスプラットフォーム 対応で、Windows、macOS、Linux、Android、iOSなど多様な環境で利用可能。 ファイアウォール設定やAPアイソレーション など、導入時の注意点も明確に解説。 貢献・翻訳・バグ報告 など、コミュニティ参加方法も充実。

LocalSendとは

  • LocalSend は、ローカルネットワーク内でデバイス間の安全なファイル・メッセージ転送を実現する無料・オープンソースアプリ
  • REST API と HTTPS（TLS/SSL）暗号化 を用いた通信プロトコル採用
  • 外部サーバーやインターネット接続不要、 高速かつ信頼性の高いローカル通信 を実現
  • クロスプラットフォーム 対応（Windows、macOS、Linux、Android、iOS、Fire OSなど）
  • サードパーティサーバー不要による プライバシー保護

ダウンロードと対応プラットフォーム

  • 各種ストアまたはパッケージマネージャー 経由でのダウンロード推奨（自動アップデート非対応のため）
    • Windows（App Store, Winget, Scoop, Chocolatey, EXE Installer, ZIPなど）
    • macOS（App Store, Homebrew, DMG Installerなど）
    • Linux（Flathub, Snap, APK, DEB, TAR, AppImage, AURなど）
    • Android（Play Store, F-Droid, APKなど）
    • iOS（App Store）
    • Fire OS（Amazon）
  • 非公式MSIXプレビュー も提供（安定性保証なし、カスタム変更点は公式サイト参照）
  • 対応OSバージョン
    • Android: 5.0以降
    • iOS: 12.0以降
    • macOS: 11 Big Sur以降（OpenCore Legacy Patcher推奨、詳細は#1005参照）
    • Windows: 10以降（Windows 7はv1.15.4までサポート、今後バックポートの可能性あり）
    • Linux: GNOME/KDEはxdg-desktop-portal関連パッケージ必須

セットアップと設定

  • 基本的にインストール後すぐに利用可能
  • ファイル送受信で問題が発生する場合、 ファイアウォール設定 で以下ポートの許可が必要
    • 受信: TCP, UDP 53317番ポート許可
    • 送信: TCP, UDP 全ポート許可
  • ルーターのAPアイソレーション 無効化推奨（特にゲストネットワーク利用時）
  • ポータブルモード （v1.13.0以降対応）
    • 実行ファイルと同じディレクトリに空のsettings.jsonを作成
    • 設定情報がデフォルト位置ではなくこのファイルに保存される
  • トレイに隠して起動 （v1.15.0以降）
    • --hiddenフラグを付けて起動（例: localsend_app.exe --hidden）

仕組み

  • 各デバイスでオンザフライでTLS/SSL証明書を生成
  • REST APIを通じてHTTPS通信 を行い、データを安全にやり取り
  • 詳細は LocalSend Protocolドキュメント 参照

開発・ビルド方法

  • Flutter （指定バージョン、.fvmrc参照）と Rust のインストール
  • LocalSendリポジトリのクローン
  • cd appでアプリディレクトリへ移動
  • flutter pub getで依存関係取得
  • flutter runでアプリ起動
  • fvmによるFlutterバージョン管理 推奨（fvm flutterコマンド使用）

貢献方法

  • 翻訳 ：Weblateプラットフォーム利用、もしくはリポジトリのapp/assets/i18nディレクトリで手動編集
    • missing_translations<locale>.jsonまたはstrings_<locale>.i18n.jsonを編集
    • @付きフィールドは翻訳不要（説明用）
  • バグ報告 ：プルリクエストで詳細な説明と修正方法を記載
  • 改善提案 ：Issue作成で必要性をディスカッション
  • 詳細はcontributing guide参照

トラブルシューティング

  • デバイスが見えない
    • ルーターのAP-Isolation無効化
    • Windowsの場合、ネットワークを「プライベート」に設定
    • macOS/iOSでは「ローカルネットワーク」権限を有効化
  • 転送速度が遅い
    • 5GHz帯のWi-Fi利用推奨
    • 両デバイスで暗号化を無効化
    • Androidは既知の問題あり（flutter-cavalry/saf_stream#4参照）

ビルドコマンド（メンテナ向け）

  • Android: flutter build apk / flutter build appbundle
  • iOS: flutter build ipa
  • macOS: flutter build macos
  • Windows: flutter build windows / flutter pub run msix:create
  • Linux: flutter build linux / appimage-builder --recipe AppImageBuilder.yml
  • Snap: localsend/snap/README.md参照

コミュニティとサポート

  • Discord や GitHub で情報共有・開発参加
  • Screenshots や Sponsors ページで最新情報や支援者紹介
  • トラブル時は公式ドキュメントやIssue参照

Hackerたちの意見

なんか、AirDropの代替品について「spamsolutions.txt」みたいなのが必要な気がする。これ、両方のデバイスが接続されてるWi-Fiネットワークが必要って条件をクリアしてないし。

最近使い始めたけど、すごくうまくいってるし、AirDropよりもずっと信頼性が高いよ。でも、UXはもうちょっと改善の余地があるかな。AppleがAirDropを直してくれたらいいのに。使おうとするたびに全然自信が持てないし、デバイスが見えなかったり、複数のMacユーザーがいると混乱しちゃって、同じMacデバイスが二回表示されたりして、どのユーザーか教えてくれないんだよね。

└

その問題のトラブルシューティングはもう試した？過去に似たような可視性の問題があったけど、今はいつもちゃんと動いてるよ。

└

うん、俺の場合はデバイスは見えるんだけど、送信を始めようとすると、半分の確率で相手のデバイスに表示されないんだ。これを確実に直す方法は見つけてないけど、両方のデバイスでAirDropをオンオフするのが一番効果的みたいだけど、70%くらいの確率でしか効かない。

└

みんな、これを何に使ってるのか気になるな。生成して転送してる（おそらく大きな）ファイルって何なんだろう？俺の場合、スマホで生成するファイルは写真と動画だけで、これらはImmichでバックアップされて、リンクを送ることで誰かと共有できる。普通の人はiCloudやGoogleフォトを使って同じことをするんじゃないかな。他のファイル、例えばドキュメントの同期にはownCloud OCISを使ってるし、ほとんどの人はDropBoxやiCloud、あるいはメールやWhatsAppでファイルを送ると思う。ISOみたいなローカルネットワーク転送は、SMBでコピーすればいいし、特別なアプリも必要ないから、ほぼ普遍的だよ。バックアップする時はハードドライブを直接繋げばいいし。だから、これを使う理由がよくわからないんだよね。

それに、ブラウザでも使えるよ。https://web.localsend.org/ WindowsからAndroid、iOSまで対応してる。

└

すごい！でも、v1.18.0はまだF-droidには出てないね。

俺の問題は、これらの代替手段がすべて同じローカルネットワークにデバイスがいることを要求すること。AirDropのいいところは、自動的にそのローカルネットワークを作ってくれるところ（俺の理解では）。だから、友達とハイキング中にAirDropで何か送ったりできるんだ。Androidに切り替えた後に見つけた対策は、友達のデバイスに接続をテザリングすること。これでLocalsendが使えるLANができるけど、あんまり快適な体験ではないね。

└

今のAndroidではQuickShareって呼ばれてるみたいで、ちゃんと動くよ。でも、断片化と認知度が問題の一部だと思う。

└

Appleが裏で使ってるプロトコルはAWDL（Apple Wireless Direct Link）で、これは独自のピアツーピアレイヤーなんだ。既存のWiFi接続を切らずに、その横で動いてる。時間をスライスしてチャンネルホッピングする仕組みを使ってるから、無線がインフラWiFiと直接のピアリンクを同時に扱えるんだよね。これが再現するのが難しい部分。LocalSendや他の代替手段は、既存の共有ネットワークが必要だから、単なるTCP/IPで、OSレベルのサポートなしに直接の無線リンクを交渉する方法がないんだ。AndroidのQuickShareもWiFi Directでピアツーピアをやってるけど、古いデバイスでは既存のWiFi接続が切れちゃう。無線は一度に一つのBSSにしか接続できないからね。lxgrが言ってるEUの相互運用性の義務は、理論的にはAppleにこれを公開させることになるけど、AWDLの相互運用性は、かなり深い無線スケジューリングのロジックをライセンスしたりリバースエンジニアリングしたりしないといけないから、 complianceは別の（おそらく遅い）道を通ると思う。

└

ハイキング中なら、友達のスマホのWiFiホットスポットに繋げば同じネットワークに入れるよ。

└

本当にクロスプラットフォームのp2pで、私が見つけた中で一番近いのはFlyingCarpetだね。でも、あんまり信頼性が高くないし、使いやすくもない。 [1] https://github.com/spieglt/FlyingCarpet

Hacker Newsで議論の続きを見る