RustDeskの使い方を、自分のサーバーで完結させるまで——hbbsとhbbrが何をしているか

リモートデスクトップの道具って、入れた瞬間はうまくいくんですよね。

つないだ。映った。動いた。

困るのはそのあとです。その画面、どこを経由して届いているか説明できますか？

分からないまま、社内の全員に配ることになる。

RustDeskがおもしろいのは、そこを自分で決められるところでした。

この記事は、RustDeskの使い方を「つないで終わり」ではなく、通り道まで自分の手元に置くところまで通しで見ていきます。中身は公式リポジトリのREADME（2026年9月6日確認）に書かれていることが土台です。

RustDeskの使い方は、まず「どのサーバーを使うか」から始まる

公式の説明文が、この道具の性格をよく表しています。

「Rustで書かれたもう一つのリモートデスクトップ。設定不要でそのまま動く。データは完全に自分の管理下に置ける。」

そして続きがこうです。公式のランデブー／リレーサーバーを使うこともできるし、自分で立てることもできるし、自分で書くこともできる。

ここが分かれ道です。

何もしなければ公式のサーバーを経由します。動きます。手間はゼロです。

でも「データは完全に自分の管理下に」という部分が本当に効くのは、サーバーを自分で持ったときなんですよね。逆に言うと、そこを決めないまま使い始めると、他のリモートデスクトップと変わりません。

なので、使い方の1歩目は接続ボタンではなく、どのサーバーを経由させるかを決めることでした。

何が入っているのか——中身を分解して見る

自分で立てる話に入る前に、この道具が何でできているかを見ておきます。READMEのファイル構成に、けっこう素直に書いてあります。

画面を取り込む部分は libs/scrap。キーボードとマウスを操作する部分は libs/enigo。ファイルのコピー＆ペーストは libs/clipboard（Windows・Linux・macOS向け）。映像コーデックや設定、TCP/UDPのラッパー、ファイル転送の関数などは libs/hbb_common にまとまっています。

そして接続まわりが2つに分かれています。src/client.rs が相手への接続を開始する側。src/rendezvous_mediator.rs がサーバーと通信して、直接つながるか、リレー経由になるかを待つ側です。

つまり、機能の塊（画面・入力・ファイル）と、経路の塊（誰を経由するか）が最初から別になっている。

この分かれ方が分かると、後の設定が読めるようになります。詰まったときに「これは画面の問題か、経路の問題か」で切り分けられるので。

画面のほうはGUIがFlutterで作られています（古いSciter版もありますが、READMEでは非推奨と書かれています）。ビルドには libvpx・libyuv・opus・aom を vcpkg で入れる必要がある、という記述もあります。

配布物の入手先も、READMEに複数並んでいます。GitHubのReleasesにあるバイナリ、開発版のNightly、AndroidならF-Droid、LinuxならFlathub。Dockerでビルドする手順も別に用意されていて、ローカルの環境を汚さずにビルドしたいときはこちらが早いです。

READMEに載っているスクリーンショットが4枚あって、これが機能の範囲をいちばん端的に表しています。接続の管理画面、Windows機への接続中の画面、ファイル転送、そしてTCPトンネリング。最後のTCPトンネリングを見落としている人が多いんですが、画面を映すだけの道具ではありません。

自分のサーバーを立てる: 実行ファイルは3つだけ

ここが本題です。

サーバー側のリポジトリをビルドすると、生成される実行ファイルは3つだけでした。

hbbs — RustDesk ID/Rendezvous server。相手を見つけるための待ち合わせ役です。

hbbr — RustDesk relay server。直接つながらないときに、間に入って中継する役です。

rustdesk-utils — CLIのユーティリティ。

構成としては、これだけです。データベースを別に用意して、キャッシュを別に立てて、という話が出てこない。

READMEには「Self-host your own RustDesk server, it is free and open source.（自分のRustDeskサーバーを自前で持てる。無料でオープンソース）」と1行で書かれています（rustdesk-server・2026-09-06確認）。

私はここで拍子抜けしました。待ち合わせと中継、その2つしかないので。

そして、この2つの役割の違いが、そのままポート番号の違いになっています。

• hbbs の待ち受けポートは既定で 21116

• hbbr の待ち受けポートは既定で 21117

設定は3通りの渡し方がある

hbbs と hbbr の設定は、3通りの方法で渡せます。コマンドラインのフラグ、環境変数、.env または設定ファイル。

使える項目は hbbs --help と hbbr --help で一覧できます。

READMEが「よく使うもの」として並べているのは、この6つでした。

Key（-k / KEY）。hbbs と hbbr の両方に効きます。注記が親切で、hbbs は既定で読み込むか生成すると書かれています。つまり最初は何もしなくていい。

Bind address（-b / BIND）。待ち受けるローカルIPです。既定は全インターフェース。この項目は 1.1.17 以降が必要、と明記されています。

Port（-p / PORT）。既定は上に書いた21116と21117です。

Relay servers（-r / RELAY-SERVERS）。hbbs に効きます。中継サーバーが別のアドレスや標準でないポートにいるときに上書きするためのものです。

Force relay（ALWAYS_USE_RELAY）。hbbs に効きます。Y にすると直接接続を無効化します。

Log level（RUST_LOG）。既定は info。詰まったら debug にすると読める。

最後の2つが、実運用でいちばん触ることになると思います。理由は次の節です。

設定をどこに書くか、で運用が変わる

もう1つ、地味ですが効く話を。

さっき「フラグ・環境変数・ファイルの3通り」と書きましたが、どれを選ぶかは好みではなく、運用の形で決まります。

手で1回だけ立ち上げて試すなら、フラグが速いです。hbbs -p 21116 と打てば終わりなので。

ただ、その形だと次に誰かが立ち上げ直したときに、同じ設定になる保証がありません。私はここで一度やられました。再起動したら設定が消えていて、なぜ消えたのかを調べるところから始まった。

継続して動かすなら、.env か設定ファイルに書いて、それをそのまま置いておくのが安全です。環境変数はコンテナで動かすときに素直な形になります。

判断の目安は1つで、「この設定を、半年後の自分が読めるか」でした。フラグはコマンド履歴の中に消えます。ファイルは残ります。

そしてログのレベルだけは、詰まってから変えることになるので、変え方を先に確かめておくといいです。RUST_LOG=debug を付けて1回起動してみる。それだけで、いざというときに慌てません。

直接つながる時と、リレーを通る時

さっきの src/rendezvous_mediator.rs の説明に戻ります。クライアントはサーバーと通信して、TCPホールパンチングによる直接接続か、リレー経由の接続かを待つ、と書かれていました。

これが動きの本体です。

うまくいけば、2台は直接つながります。映像はサーバーを通りません。速いし、サーバーの回線も食いません。

つながらないときだけ、hbbr が間に入ります。

で、ここが設計の判断どころなんですが、直接つながるということは、相手のネットワークとこちらのネットワークが直に触れるということでもあります。

だから ALWAYS_USE_RELAY に Y を入れて、直接接続を無効化するという選択肢が用意されている。全部を中継サーバー経由にすれば、経路が1本に固定されます。速度は落ちますが、通り道が見えます。

速さを取るか、通り道の見通しを取るか。この1つの環境変数が、その選択そのものでした。

環境が単純ならまず既定のまま試して、社外や取引先とつなぐ用途が出てきたらここを見直す、という順番でいいと思います。

何もしない構成と、自前構成の差はどこに出るか

ここまで読んで「結局、自前にする価値はどこ？」と思った人向けに、差が出る場所を整理しておきます。

まず、つながるかどうかには差が出ません。公式のサーバーを使っても、自前でも、映るものは同じです。

差が出るのは3つでした。

1つめは、経路が自分の管理下にあるかどうか。誰と誰がいつつないだかを、自分のログとして持てます。

2つめは、止まったときに自分で直せるかどうか。外のサービスに依存していると、待つしかない時間が生まれます。

3つめが意外と大きくて、社内に説明できるかどうかでした。「この画面はうちのサーバーを通っています」と言えるのと、「どこかを通っています」しか言えないのとでは、導入の通りやすさが違います。

逆に、1人か2人で使うだけなら自前にする理由は薄いです。維持する手間のほうが上回ります。台数が増えて、説明を求められ始めたときが分岐点でした。

RustDeskを使う前に読んでおく2つの注意書き

技術の話とは別に、READMEに書いてある2つを置いておきます。ここを飛ばすと、後で困るのは導入した側です。

1つめ、誤用に関する免責。 READMEの冒頭に警告として置かれています。開発者は非倫理的・違法な利用を容認しないこと、無許可のアクセス・制御・プライバシーの侵害はガイドラインに明確に反すること、作者はアプリケーションの誤用に責任を負わないこと。

リモートデスクトップは相手の画面と入力を握る道具なので、社内で配るなら誰が誰の画面につなげるのかを先に決めておく必要があります。

2つめ、ライセンスはAGPL-3.0です。 自社内で使うぶんには通常そのまま使えますが、改変して外部にサービスとして提供する形を考えているなら、条件を読んでから設計してください。

なお、より高度な機能が要る場合の商用版（Server Pro）が別に案内されています。オープンソース版で足りるかどうかは、必要な機能を洗い出してから判断するのが順番だと思います。

RustDeskの使い方でつまずきやすい3つ

最後に、実際に触って引っかかりやすいところを整理しておきます。

1つめ、鍵を後から変えると全部つながらなくなります。 hbbs が既定で鍵を生成してくれるので最初は意識しませんが、この鍵はクライアント側の設定と対になります。サーバーを作り直したときに、ここで全台が切れます。

2つめ、hbbs だけ立てて安心しない。 待ち合わせはできても、直接つながらない環境では hbbr が必要です。片方だけ立てて「たまにつながらない」と悩む形になりがちです。

3つめ、まずは1台対1台で試す。 いきなり全社に配ると、切り分けができません。手元の2台でつないで、RUST_LOG=debug でログを読んでから広げる。

もっと単純な出発点が欲しい場合は、公式が rustdesk-server-demo という「このリポジトリより簡単な出発点」を案内しています。自分でサーバーを書きたい人向けの入口です。

今日、20分でできること

いきなり自前サーバーまで行かなくていいので、まず手元の2台でつないでみてください。

配布物はGitHubのReleasesにあります。LinuxならFlathub、AndroidならF-Droidからも入ります。

つながったら、そのあとに1つだけ考えてみてほしいことがあります。

いまの接続は、どこを通っていますか。

その問いに自分で答えられるようにすることが、RustDeskの使い方でいちばん価値のある部分だと思っています。道具そのものより、通り道を持てることのほうが効きます。

▶ 関連記事: LoopXの使い方——AIに長い仕事を任せるとき、途中で止めて戻れるようにする

毎月のオープンソースの伸びを追いかけて、実際に触って使えたものだけを整理した資料を用意しています。

👉 オープンソース研究所の6大特典を受け取る

#RustDesk #オープンソース #リモートデスクトップ #セルフホスト #Rust #TeamViewer代替 #インフラ #サーバー運用 #セキュリティ #AGPL #情シス #業務効率化 #仕組み化