· RustDesk Team · ガイド · 8 分で読めます
リモートデスクトップソフトウェアをセルフホストすべき理由
TeamViewerやAnyDeskから乗り換えるチームが、なぜリモートデスクトップのセルフホストを選ぶのか。データ管理の主導権、予測可能なコスト、そして間に入るクラウドがないという理由です。

多くのリモートデスクトップツールは、クラウドサブスクリプションという一つの形でしか販売されていません。すべてのセッションはベンダーのサーバーが仲介し、多くの場合は中継も行います。リモートアクセスの運用方法にはもう一つの選択肢があります。これは新しい考え方ではなく、単に定期的なクラウドサブスクリプションが付随しないために、あまり宣伝されてこなかっただけです。それがリモートデスクトップソフトウェアをセルフホストするという決断です。接続を仲介し、直接接続が確立できない場合にトラフィックを中継するサーバーを、自分たちが管理するインフラ上で運用するということです。本記事では、このモデルの利点を論じ、具体例としてRustDeskを取り上げます。
「リモートデスクトップをセルフホストする」とは実際どういうことか
クラウド専用という手軽さの代償は、デバイス一覧、接続メタデータ、そして時にはセッショントラフィックまでもが第三者を経由することです。稼働率もベンダー次第、料金もベンダー次第、セキュリティ体制もベンダー次第です。
セルフホスティングはこの構図を逆転させます。RustDesk Server Proでは、ID/ランデブーサーバー、リレー、コンソール、そして保存されるデプロイメントデータはすべて自社インフラ上で稼働します。直接接続はエンドポイント間をそのまま流れ、中継が必要な接続は自分で設定したリレーを使用します。RustDeskはオープンソース(AGPL)であり、無料のコミュニティサーバーは期限なく利用し続けられます。
クラウド専用型とセルフホスト型の比較、一目でわかる違い
| 一般的なクラウド専用ツール | セルフホスト型(RustDesk Server Pro) | |
|---|---|---|
| セッションの仲介場所 | ベンダーのクラウド | 自社のオンプレミス機またはVPS |
| データの所在地 | ベンダーが管理 | サーバー側サービスは自社管理下のインフラで稼働。ただしエンドポイント間の経路にも注意が必要 |
| 同時接続数の上限 | 多くの場合チャンネル/シート単位 | 標準プランは無制限、Customized V2は従量制 |
| 料金モデル | シート単位/チャンネル単位のクラウドサブスクリプション | ログインユーザー数+管理対象デバイス数(料金詳細) |
| ソースコード | 非公開 | オープンソース(AGPL)、監査可能 |
| 障害への依存 | ベンダーの稼働率次第 | 自社の運用次第 |
| サーバーの運用主体 | ベンダー | 自社 |
セルフホスティングだからといって、スケールや機能を犠牲にする必要はありません。RustDeskはより大規模な環境をサポートするチーム向けに、大規模フリート計画のガイダンスを公開しています。MSPや社内IT部門向けには、セルフホスト型のWebコンソール、カスタムブランドのクライアントジェネレーター、そしてユーザー単位のアクセス制御を実現するデバイスグループと共有アドレス帳が用意されています。LDAP/SSO(OIDC)はBasicプラン以上で利用できます。
サーバー運用に実際に必要なこと
この主導権には、ある程度の運用作業が伴います。とはいえ、ほとんどのチームが想像するよりも少なく、その大半は一度きりの作業です。具体的な内容は次のとおりです。
- ホストを用意する。 RustDeskのハードウェア要件は低いため、オンプレミスの環境でも安価なVPSでも、控えめなスペックのLinux VMでID/ランデブーおよびリレーサービスを稼働できます。デバイス台数と、ピアツーピアではなくリレー経由になるトラフィック量に応じてサイズを決めてください。
- 使用するポートだけを開放する。 ネイティブのRustDeskクライアントは、NATテスト、接続サービス、登録、ハートビート、リレーのためにTCP 21115-21117とUDP 21116を必要とします。21114-21119の範囲をすべて公開してはいけません。TCP 21118-21119はWebSocketバックエンド、TCP 21114はPro版のHTTP API/コンソールバックエンドです。HTTPS/WSSリバースプロキシがPro APIとWebSocketサービスの手前に立つ場合は、そのトラフィック用にTCP 443のみを公開し、21114と21118-21119は内部にとどめてください。ネイティブクライアントも接続する環境では、公開された443がネイティブクライアント用のコアポートの代わりにはなりません。詳細は公式のポートリファレンスを参照してください。
- TLSを設定する。 リバースプロキシでHTTPSとWSSを終端させ、認証情報、API呼び出し、ブラウザクライアントのトラフィックが、平文HTTPのコンソール/APIや生のWebSocketバックエンドを露出させることなく、公開されたTCP 443を使うようにします。
- バックアップを取る。 サーバーにはデバイス一覧、ユーザーアカウント、アドレス帳、アクセスルールが保存されています。バックアップをスケジュールし、実際に復元できることをテストしてください。
- パッチ適用のペースを保つ。 サーバーの新しいビルドは随時リリースされ、その下で動くOSの管理も自社の責任です。誰がどのくらいの頻度で更新を適用するかを決めておきましょう。
- 監視する。 調整サービスは自社のものになったので、稼働率、ディスク、リレースループットを監視し、アラートと復旧も自社で管理します。
これらはどれも特別なことではなく、大半は一度きりのセットアップです。途中で疑問が出てきた場合は、RustDeskサポートがサポートします。
セルフホスティングを検討する方法
- まずコミュニティサーバーから始める。 コアはAGPLライセンスです。無料のオープンソースサーバーは今日の午後にでもデプロイでき、監査した上で、無償のままいくらでも長く運用できます。
- Pro版の機能セットが必要な場合は? 最新のプラン料金はrustdesk.com/pricingに掲載されており、現在利用可能な評価オプションについては[email protected]にお問い合わせください。
- インストールする前にまず見てみたい方は? RustDeskのYouTubeチャンネルに、詳しいデモ動画があります。
値上げ、非公開のコード、自分でコントロールできないクラウドが原因で乗り換えを検討し始めたのであれば、セルフホスティングは単なる値引きではなく、構造そのものを解決する手段です。すでにインフラを運用しているチームにとって、これは飛躍ではなく次の一歩です。サーバーを持ち、データを持ち、コストを持つ。それが答えです。
Frequently asked questions
リモートデスクトップソフトウェアをセルフホストするとはどういう意味ですか?
セッションをベンダーのクラウド経由でルーティングする代わりに、接続を仲介し、直接接続が確立できない場合にトラフィックを中継するサーバーを、自分たちが管理するインフラ上で運用することを意味します。RustDesk Server Proでは、ID/ランデブーサーバー、リレー、コンソール、保存されるデプロイメントデータがすべて自社インフラ上で稼働します。
セルフホスト型のRustDeskサーバーを運用するには、実際に何が必要ですか?
ハードウェア要件は低く、作業のほとんどは一度きりです。小規模なLinuxホストを用意し、使用するポートだけを開放し(ネイティブクライアントにはTCP 21115-21117とUDP 21116が必要です)、リバースプロキシでTLSを設定し、バックアップをスケジュールします。それ以降は日常的なパッチ適用と監視だけで済み、つまずいた際にはRustDeskサポートが力になります。
セルフホスティングはデータの所在地やGDPR準拠に役立ちますか?
はい、この点では実質的な主導権が得られます。ランデブー、リレー、コンソール、デバイスデータをどこで稼働させるかを自分で選べるからです。ただしこれは絶対的な保証ではなく、あくまで基盤です。直接接続はエンドポイント間をそのまま流れるため、トラフィックを国内に留めることやGDPRの義務を満たすことは、デプロイメントをどのようにルーティングし運用するかにも左右されます。
セルフホスティングはすべてのチームに適していますか?
セルフホスティングは、データとインフラの主導権を持ちたいチームに適しています。サーバーの運用は必要になりますが、その規模は小さく、セットアップの大半は一度きりです。サーバーを一切運用したくないのであれば、マネージドSaaSが代替となるモデルです。しかしRustDesk Server Proは、データが自社インフラにとどまり、間にベンダーのクラウドが入らないようにするために、設計上セルフホスト型になっています。すでにインフラを運用しているチームにとっては、その主導権こそが本質的な価値です。



