Rustdesk：話題のAIプロジェクトを開発者向けに詳しく解説（2026）

RustDeskが実際に解決すること

RustDeskは、「SSHでは接続できる」と「今すぐ完全なGUIが必要」の間にある、扱いづらいながらも確実に存在する隙間を埋めます。

これは、次のような環境を扱う際に重要です。

• NATの背後にあるGPUワークステーション
• 特定のツールを使うためにデスクトップ環境で起動するオンプレミスサーバー
• 小規模なチームが使うアノテーション用マシン
• 会場のWi-Fiネットワークに接続されたデモ用ノートPC
• VDIでは過剰になる、厳しく制限されたサブネット内の実験用マシン

エンジニアリング上の大きな価値は、リモート画面そのものではありません。RustDeskの通信を、自分たちで管理するインフラ経由にできることです。モデル関連の作業を行うチームにとっては、外部のリモートアクセス中継サービスへの依存が減り、コンプライアンス上の悩みが少なくなり、監査やアクセス制御についても明確に説明できるようになります。

実際には、VPN、SSH、ブラウザベースの管理だけでは対応できないときに機能する代替経路が必要な場面で、このプロジェクトは特に役立ちます。

アーキテクチャの仕組み

RustDeskの設計はシンプルで、それも運用上の魅力の一つです。

大きく分けると、次の三つの要素があります。

• クライアントアプリ ローカルマシンとリモートマシンで動作します
• ランデブー／IDサーバー ピア同士が互いを見つけられるようにします
• リレーサーバー 直接接続に失敗したときに通信を中継します

一般的なセルフホスト構成で使用するのは、 hbbs と hbbr のサービスです。 hbbs は識別と接続の調整を担当し、 hbbr はNAT越えやファイアウォールのルールによって直接のピアツーピア接続が阻まれた場合に、中継通信を担当します。

基本的な考え方は次のとおりです。

1. リモートマシンが自身を登録します。
2. クライアントがIDでそのマシンを検索します。
3. RustDeskが直接接続を試みます。
4. 直接接続のためのNAT越えに失敗すると、通信はリレーサーバー経由に切り替わります。
5. セッションはエンドツーエンドで暗号化されたままです。

最後の点は重要です。適切な構成では、リレーサーバーがデスクトップの内容を確認できてはいけません。リレーサーバーはパケットを転送するものであり、信頼を委ねる操作コンソールになるわけではありません。これは、「すべての画面情報をどこかのSaaSサーバーに送り、ポリシーページの記述が実態と一致していることを願う」という方式より優れています。

見落とされがちな点

よくある落とし穴は、セルフホスティングを「サーバーをインストールすれば完了」と考えることです。次の対応も必要です。

• 適切なポートを開放する
• クライアントの接続先を自分たちのサーバーに設定する
• 想定する鍵またはサーバーの識別情報を固定する
• クライアントが知らないうちに公開のフォールバック経路を使っていないことを確認する

最後の確認をしないと、自分たちのインフラを使っているつもりでも、クライアントは依然としてデフォルトの経路を使って接続先を解決しているかもしれません。

現実的なセルフホスト構成

よくある構成は、小規模なVPSまたはエッジVMでランデブーとリレーのサービスを実行し、DNSにはたとえば rd.example.com を使用して、そのサーバーを参照するように設定するものです。

最小限のコンテナベースのデプロイは、多くの場合、次のようになります。

docker run -d --name hbbr --restart unless-stopped \
  -p 21117:21117 \
  -v $PWD/data:/root \
  rustdesk/rustdesk-server hbbr

docker run -d --name hbbs --restart unless-stopped \
  -p 21115:21115 \
  -p 21116:21116 \
  -p 21116:21116/udp \
  -v $PWD/data:/root \
  rustdesk/rustdesk-server hbbs -r rd.example.com:21117

ファイアウォールのポリシーも、通常は同じくらい平凡です。

{
  "name": "rustdesk-self-hosted",
  "ingress": [
    { "proto": "tcp", "port": 21115 },
    { "proto": "tcp", "port": 21116 },
    { "proto": "udp", "port": 21116 },
    { "proto": "tcp", "port": 21117 }
  ],
  "egress": [
    { "proto": "all", "port": "all" }
  ]
}

具体的なポートやイメージタグはリリースによって異なる場合があるため、自分たちのデプロイ手順書に固定値を記録してください。変わらないのは運用上の構成です。接続を調整するサービス、リレーサービス、DNS、そして自分たちが実際に理解しているファイアウォールのルール一式です。

デプロイのトレードオフ

趣味用のマシンなら、公開インフラでも問題ないかもしれません。本番のAIインフラでは、通常、セルフホスティングを基本の選択肢にするのが適切です。

実際のワークフロー

私が一般的だと考えるワークフローは、次のようなものです。

ある研究者が、オフィスのワークステーションでノートブックサーバー、ローカルのアノテーションツール、ライセンス契約のあるデータセットポータルへのブラウザベースのログインフローを実行しています。オフィスのサブネットが分割されているため、そのワークステーションにはVPN経由でアクセスできません。SSHは使えますが、実際に作業を妨げているのはブラウザのプロンプトとローカルのデスクトップアプリです。

RustDeskを使う場合は、次のように進めます。

1. ワークステーションと管理用ノートPCにクライアントをインストールします。
2. 両方の接続先をセルフホストのIDサーバーとリレーサーバーに設定します。
3. ワークステーションが想定したIDで表示されることを確認します。
4. ノートPCから接続します。
5. GUIを使ってブラウザのログインを完了し、ローカルアプリを確認して、問題のあるセッションを修復します。
6. 必要に応じてファイルや設定を転送します。
7. ログアウトし、VNCのような常時の外部からの接続口を残さないようにします。

直接接続の経路が使えないと、実際には何が起こるのでしょうか。リレー経由でセッションが遅くなりますが、管理作業なら通常は許容範囲です。高フレームレートの動画を見たり、グラフィックス処理の多い対話的な作業をしたりしようとすると、リレー経路はあくまで代替手段であり、レイテンシを魔法のように減らすものではないと実感するでしょう。

これが率直な限界です。RustDeskは運用作業のためのアクセスに優れています。クラウドGPUストリーミングプラットフォームを装っているわけではありません。

現代のAIスタックにおける位置づけ

インフラの観点から見たRustDeskの最も興味深い点は、AI運用における非常に実用的な役割を担っていることです。

次の用途に役立ちます。

• GPUマシンの復旧 人の操作が必要なデスクトップセッションでマシンが起動した場合
• アノテーション用端末 技術者ではないレビュアーが使用する端末
• デモ用機材 顧客との通話前に、画面上で手早く修正する必要があるもの
• エアギャップ環境または部分的に隔離された環境 SSHは許可されていても、ブラウザー認証やGUIツールが依然として重要な環境
• オンコール対応 学習ノードが技術的には稼働していても、運用上は行き詰まっている場合

現代のAIスタックは、モデル配信とベクトルデータベースだけで構成されているわけではありません。次のものも含まれます。

• ワークステーション
• スケジューラー
• ストレージ
• ブラウザー
• ドライバー
• アノテーションツール
• シークレット管理のフロー
• 復旧手段

RustDeskは、この最後のカテゴリーに属します。システムが技術的には正常でも、運用上の作業が進められないときに備えて確保しておく手段です。

この点で、ほかのツールともうまく組み合わせられます。

• SSH シェルを中心とした管理に
• VPN ネットワークへのアクセスに
• RustDesk GUIでの復旧とサポートに
• MDMまたはエンドポイントポリシー 端末群の管理に

AIインフラを管理するなら、単一のツールですべての障害パターンに対応できると期待するより、この組み合わせのほうが現実的です。

メリットとデメリット

チームに支持される理由

• セルフホスティングが机上の話ではなく、実用的である
• クライアントとサーバーの分離が、実際のインフラ構成に自然に対応する
• ネットワーク条件が整っていれば、ピア間の直接接続でリレーの負荷を減らせる
• フォールバック用のリレー経路により、複雑なネットワーク構成でもサポートを続けられる
• すべてのリモートアクセスをブラックボックスのSaaSに委ねるよりも、優れた信頼モデルである

負担になる点

• サーバー、DNS、ファイアウォール、可用性を自分たちで管理する必要がある
• セッションの品質は、依然としてネットワーク品質に左右される
• リレーモードは機能するが、レイテンシーに敏感な作業には最適ではない
• あくまでリモートデスクトップツールなので、シェルアクセス、構成管理、適切な監視の代わりにはならない
• 厳格な企業ポリシーでは、クリップボード、ファイル転送、デバイスの認可に関する追加の制御が必要になる場合がある

私が最もよく目にする間違いは、RustDeskを万能の解決策として扱うことです。そうではありません。運用の隙間を埋める、よく設計されたツールです。

率直に見る制約

特に重要な制約が二つあります。

まず、リモートデスクトップは本質的に状態を持ち、画面操作を伴うものです。ターミナルやAPIで実行できるワークフローなら、そちらを使ってください。RustDeskは例外時の手段であるべきで、標準の管理インターフェースにすべきではありません。

次に、セルフホスティングは制御性を高めますが、信頼性まで自動的に高めるわけではありません。ランデブーサーバーが停止していたり、ファイアウォールのポリシーが誤っていたり、DNSの情報が古かったりすると、構成全体の挙動がたちまち分かりにくくなります。そのため私は、たとえ「単なる」小さな補助サービスであっても、サーバーを常に本番インフラとして扱います。

つまり、セルフホスト型のリモートデスクトップスタックの信頼性は、それを支える地味なインフラの信頼性に左右されます。

実践上のポイント

• 必要なときにRustDeskを使いましょう： セルフホスティングで制御できるGUIアクセス。特にAIワークステーションやラボのマシンに適しています。
• 優先的に選ぶのは セルフホスト型のランデブーサービスとリレーサービス 。そのマシンがチームやコンプライアンス体制にとって重要である場合に。
• 次の値を保持してください： SSH、VPN、RustDesk を併用しましょう。それぞれ異なる障害パターンに対応します。
• リレーモードは次の用途として扱いましょう： フォールバック。性能の基準にしてはいけません。
• 検証しましょう： DNS、ポート、サーバーの識別情報のピン留め 。緊急時にこのツールが必要になる前に。
• AIチームにとって、RustDeskは次のように捉えるとよいでしょう： 運用上の保険 。スタックのうち、シェルでは対応できない部分に備えるものです。