RustDesk はセルフホストを選べる Rust 製リモートデスクトップ
セルフホスト可能なオープンソースのリモートデスクトップアプリケーション。
ひと目でわかる
- これは何？
- rustdesk/rustdesk の README とメタデータから、接続方式、GUI の選択、ビルド経路、コード構成、配布と未検証の安全性を整理します。
- 誰に向いている？
- RustDesk は、リモートデスクトップの rendezvous と relay を自分で管理する選択肢を求める利用者に候補になります。ビルドは Rust、C++、vcpkg、GUI 依存関係の準備が必要で、README では Sciter が非推奨です。
- 商用利用できる？
- 厳しい条件付きでできます。AGPL-3.0 はネットワーク型コピーレフトのライセンスで、改変版をホスティングサービスなどとしてネットワーク越しに利用させる場合、その利用者にソースコードを同じライセンスで提供する必要があります。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Rust です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
セルフホストできる Rust 製の遠隔操作アプリ
RustDesk は Rust で書かれたオープンソースのリモートデスクトップアプリケーションです。リポジトリの説明では TeamViewer の代替とセルフホスティングを位置付けています。接続の rendezvous と relay については、プロジェクトのサーバーを使う、自分で立てる、カスタムサーバーを書くという三つの道が README に示されています。README は設定不要で使えることやデータを自分で管理できることを述べますが、独立した監査、性能ベンチマーク、詳細な脅威モデルは素材にありません。安全性の断定ではなく、設計方針として読むべき記述です。
Flutter を主軸に Sciter は非推奨
デスクトップ GUI には Flutter と Sciter の選択肢があり、README は Sciter を非推奨としています。掲載されているビルド手順は Sciter 向けで、Windows、Linux、macOS 用の Sciter 動的ライブラリを手動で取得します。依存関係として Rust ツールチェーン、C++ ビルド環境、vcpkg の libvpx、libyuv、opus、aom が挙げられています。Linux については Ubuntu 18 または Debian 10、openSUSE Tumbleweed、Fedora 28 または CentOS 8、Arch または Manjaro のパッケージコマンドが例示されています。これらの版名は README にある例で、現在の OS 全般への保証ではありません。
cargo と Docker で異なる準備をする
素のビルドでは Rust と C++ の環境、vcpkg、VCPKG_ROOT、四つのコーデックライブラリを準備し、cargo run を実行します。Linux の手順はサブモジュールを含めて取得し、libsciter-gtk.so を target/debug に置き、環境変数を設定して起動する流れです。Fedora では libvpx の修正手順も示されています。Docker の道ではソースとサブモジュールを用意し、rustdesk-builder イメージをビルドして cargo の git と registry キャッシュを volume で渡します。初回は遅く、--release を追加できます。Docker のワークフローでは cargo install と cargo run をホストで使う形はサポートされません。
通信、キャプチャ、入力、UI のコード分割
libs/hbb_common はビデオコーデック、設定、TCP と UDP のラッパー、protobuf、ファイル転送の補助を担います。libs/scrap は画面キャプチャ、libs/enigo はキーボードとマウス、libs/clipboard は各 OS のコピーと貼り付けです。src/server には音声、クリップボード、入力、映像、ネットワーク接続が置かれ、src/client.rs がピア接続を始めます。src/rendezvous_mediator.rs は rustdesk-server と通信し、TCP hole punching による直接接続または relay 接続を待ちます。Flutter UI、Web の JavaScript、プラットフォーム固有コードも別の場所に分かれています。
バイナリ配布と不正利用に関する注意書き
バイナリは GitHub Releases から取得でき、nightly タグもあります。README には Android と Linux デスクトップに関係する F-Droid と Flathub の表示、複数言語の翻訳案内、Discord、Twitter、Reddit、YouTube へのリンクがあります。冒頭の注意書きは、未承認アクセスやプライバシー侵害を容認せず、不正利用の責任を負わないというプロジェクト側の方針です。これは技術的な安全保証ではありません。利用者側の認証、接続先の公開範囲、ログ、更新管理は別途設計する必要があります。
AGPL-3.0 とメタデータからの判断限界
素材のメタデータは主要言語 Rust、AGPL-3.0、非アーカイブ、122,040 stars、18,696 forks、144 open issues と記録しています。README はユーザーがデータを管理できることを掲げますが、提示資料には性能値、利用者数、第三者統合、独立監査の結果はありません。今回のライセンス確認では共通パスに LICENSE が見つからず、README の主張だけで全条項を確定できません。配布形態や改変版の公開範囲を決める前に、対象リビジョンの実際のライセンス、セキュリティアドバイザリ、公式ビルドの来歴を確認すべきです。
RustDesk を自分で運用する場合、接続経路とビルド方式を一つの構成図にまとめる必要があります。rendezvous で接続先を見つけ、TCP hole punching による直接接続を試し、必要なら relay へ進むという説明はありますが、ネットワーク環境ごとの到達性や遅延を保証するものではありません。画面キャプチャ、入力制御、音声、ファイル転送は複数のライブラリとサービスに分かれているため、権限を一つのアプリとして扱わず、接続相手、管理者、relay サーバーに何が見えるかを確認します。Docker はホストの環境差を減らせますが、ソース、cargo キャッシュ、コンテナの実行権限、生成バイナリの署名は別に管理しなければなりません。README のセキュリティ表現は独立監査ではなく、AGPL-3.0 の条項も提示素材だけでは実ファイルを確定できません。公式 release、アドバイザリ、対象 OS、接続ログをそろえてから本番の公開範囲を決めるべきです。
遠隔操作の運用では、接続できることだけでなく、誰が接続を承認し、画面、キーボード、クリップボード、ファイル転送をどこまで許可するかを定義します。README の rendezvous と relay の説明は接続経路の見取り図ですが、組織の認証、端末登録、監査、鍵更新の仕組みまでを提供する説明ではありません。Sciter のビルドは非推奨とされているため、新規評価では Flutter 側の文書と対応環境を確認し、古い Sciter 用手順をそのまま標準にしない方がよいでしょう。Docker のキャッシュ volume やビルダーイメージは再現性に役立ちますが、生成バイナリが正しいソースから作られたことを別に記録します。AGPL-3.0 と公式 release の扱い、管理サーバーを自分で立てる範囲、クライアントの更新経路を明確にしてから公開ネットワークへ出すべきです。
編集部の結論
RustDesk は、リモートデスクトップの rendezvous と relay を自分で管理する選択肢を求める利用者に候補になります。ビルドは Rust、C++、vcpkg、GUI 依存関係の準備が必要で、README では Sciter が非推奨です。接続の安全性、性能、脅威モデル、AGPL-3.0 の実際の適用は、対象版を固定して公式文書、セキュリティ情報、検証環境で確かめてください。
コミュニティノート