過去に出先で急ぎの作業対応を迫られたとき、スマホ単体での操作性や画面サイズの限界で詰んでしまった経験が何度かあり、その都度「ノート PC を持ってこなかったのが悪い」で済ませてきました。今回はそこを根本的に作り直そうと思い、これからの旅行に備えて Tailscale + Windows RDP + RustDesk を組み合わせ、iPhone/iPad → メイン PC → サブ PC の 3 段リモート接続環境を 2 時間ほどで構築しました。
この構成があれば、例えばiPad + HDMI ケーブル + 無線キーボード + 無線マウスだけ持ち出せば、ノート PC を持ち歩くより身軽に旅行に出かけられます。iPad のストレージや CPU が貧弱でも気になりません（重い処理はメイン PC / サブ PC 側で動いていて、iPad は表示と入力だけだから）。出張や旅行のときに荷物を最小化したい人には地味に強い構成だと感じています。
加えて、直近で前回投稿した 3 層 AI ツール選択ヒューリスティック で触れた「ClaudeCode の Remote Control を使い忘れた時の救援」も、この自前リモートインフラがあれば成立するので、AI 協業を続けたい個人エンジニアにとって地味に大きな保険にもなります。なお、個人利用のため基本的に全部無料です。
それにしても、20 年前に IPsec / L2TP のトンネルを張っていた頃と比べると、本当に隔世の感があります。副次的にわかったこともまとめておきます。
構築した環境
iPhone
↓ (RustDesk / Tailscale mesh)
メイン PC (Windows 10 Home)
↓ (Tailscale + Windows 標準 RDP)
サブ PC (Windows 11 Pro)
使ったもの:
- Tailscale（無料 100 台まで）— mesh VPN
- Windows 標準 RDP — メイン PC ↔ サブ PC（Pro 必須）
- RustDesk（無料 / オープンソース）— iPhone から Home エディションへ（Home は標準 RDP ホスト不可なので代替）
3 デバイス全部に Tailscale をインストール、同じアカウントでログインするだけで mesh が自動構築されます。MagicDNS を有効にすると マシン名で疎通できるので、IP を覚える必要もありません。
20 年前の IPsec 時代との比較
正直に言って、当時の苦労を思い出すと笑ってしまうほど運用コストが落ちています。
| 観点 | 旧時代（IPsec / L2TP） | 現代（Tailscale / mesh VPN） |
|---|---|---|
| トンネル設計 | 静的、site-to-site 中心 | 動的 mesh、device-to-device |
| 鍵交換 | IKE / ISAKMP、フェーズ 1/2 のデバッグが職人芸 | WireGuard + OAuth ログイン |
| NAT 越え | NAT トラバーサル設定が職人芸 | 自動（DERP relay フォールバック内蔵） |
| DNS | 別途内部 DNS サーバー構築 | MagicDNS 自動 |
| 鍵管理 | 共有鍵 / 証明書配布、年次更新 | アカウント単位、UI で追加・削除 |
| 端末追加コスト | 数十分〜数時間 | 数分（OAuth ログインで mesh 参加） |
| コスト | 商用 VPN 機器 + 年間ライセンス | 無料（個人利用、100 台まで） |
パラダイムシフトの本質を一行で言うと、運用が「静的構成」から「アイデンティティ駆動の動的構成」へ移ったということなのだと思います。鍵やトンネル設定が認証単位だった時代から、アカウントとデバイス ID が認証単位になる時代となり、既存技術が完全にコモディティ化されています。
これは AI コーディング時代の「個人エンジニアが組織レベルのインフラを 1 人で構築できる」流れと同じ構造変化で、1 人で完結する時代の VPN として位置付けられると感じています。
ClaudeCode Remote Control の「代替」ではなく「起動装置 (bootstrap)」
ClaudeCode には Remote Control という機能があります。デスクトップで開いている Claude Code のセッションを、専用 URL を発行することで他のデバイス（スマホやタブレット）からも継続できる、軽量な遠隔操作用の仕組みです。事前に PC 側で機能を有効化して URL を取得しておけば、出先でその URL をブラウザで開くだけで作業を続けられます。
正直、当初は「外出先で ClaudeCode の Remote Control が使えなかった時の代替手段」程度のつもりで RustDesk を入れたのですが、実際に運用してみたら 代替よりも 1 段先に価値がありました。
具体的なシナリオはこうです:
- 出先で iPhone から ClaudeCode を継続したいが、Remote Control の URL を取り忘れて出てきてしまった
- iPhone → RustDesk で自宅メイン PC にログイン（重いが必ず通る）
- PC の GUI から ClaudeCode の該当チャンネルで Remote Control を有効化して URL を取得
- 取得した URL を iPhone のブラウザで開く → 以降は 軽量な Remote Control に切り替え
つまり RustDesk / RDP は 「重いが必ず通る経路」として bootstrap に使い、その後は軽い Remote Control に乗り換える運用が一番 ROI が高いです。代替ではなく 救援 + 切り替え の関係となります。
これは運用エンジニアの言葉に翻訳すると、「コンソールサーバー経由で帯域外管理 (OOB) から SSH を有効化して、以降は通常の SSH で運用する」のと同じ構造だと思います。重くて確実な経路を bootstrap に、軽い経路を本番に、という分業思想です。
余談ですが、この「リモートで PC に入って Remote Control を起動して、以降は軽量経路に切り替える」二段運用について、軽く検索した範囲では明示的に書かれた先行記事を見つけられませんでした。Remote Control の制約自体（PC 側でしか URL 発行できない）は GitHub Issue でも議論されていて広く認識されているのですが、それを RDP / RustDesk と組み合わせて bootstrap として運用するという発想は、自分の検索範囲では言語化されていないようでした。私が見落としているだけの可能性は十分あるので、もし先行記事をご存知でしたら教えてください。あくまで個人運用の整理として残しておきます。
ツール比較: 軽さの観点
各ツールを軽さで並べると、概ねこんな順になります。
| ツール | CPU 負荷 | 帯域 | レイテンシ | 軽さ順位 |
|---|---|---|---|---|
| Windows 標準 RDP + VPN | ◎ 軽い | ◎ 最軽量 (UI vector) | ◎ 低い | 1 位 |
| ClaudeCode Remote Control | ◎ 軽い | ◎ テキストのみ | △ AI 推論時間あり | 2 位 |
| RustDesk | ○ 中 | ○ 中 (画面コーデック) | ○ 中 | 3 位 |
| Chrome Remote Desktop | △ 重い (Chrome 必須) | △ 中 (WebRTC) | ○ 中 | 4 位 |
なお、Windows 標準 RDP が軽い理由は、画面ピクセルではなく UI コマンド（描画指示）を送るプロトコルだからです。Windows の native UI コンポーネントを相手側で再描画するため、文字や UI 要素はベクター情報のように扱えます。動画再生や 3D アプリでは RDP もビデオストリーム化するので優位性が薄れますが、テキスト中心の作業では圧倒的です。
参考までに、Chrome Remote Desktop も導入はしています。導入の楽さは群を抜いて素晴らしく、Chrome に同じ Google アカウントでサインインしていれば通ってしまうので、設定らしい設定をした記憶もないほどです。ただ、上記のとおり動作はかなり重いので、実際にはほとんど使っていません。導入の楽さと操作感の軽さを天秤にかけると、私の場合は軽い方を選びたい、という結論になりました。Chrome Remote Desktop は「他の経路が全部使えなくなった時の最後の保険」として残してある、というのが正直な位置付けです。
「iPhone から直接サブ PC でよくない?」への回答
そもそも「Windows Pro のサブ PC をメイン PC にしていれば、iPhone から直接サブ PC へ Windows 標準 RDP で繋げて軽かったのでは?」というツッコミも当然あります。実際 iPhone には App Store で「Microsoft Remote Desktop」アプリ（現 Windows App）が出ていて、Pro PC への RDP 接続は RustDesk より軽く繋がります。
これに対する正直な答えは、メイン PC をサブ PC の買い替えとして買った時に、RDP 構成を念頭に置いていなかったから、というだけです。当時はリモート接続前提の構成設計をしておらず、結果としてメイン PC が Home エディションになりました。後付けで使い分けの意味が見えてきた、というのが実態です。
もうひとつ、「もっと踏み込んで Home を Pro 化すれば経路最適化になるのでは?」というツッコミも当然あります。これに関しては 2 時間ほどで組み上げた現状構成なので、現在 Pro 化を検討中です。とはいえ、「現状の HW & SW 構成のみでどうにかできないか」という観点では ほぼ100 点だと思っています。なるべくコストをかけずに手元にあるものだけで成り立たせる制約は、それ自体が個人エンジニアにとって守るべき条件のひとつだったので。
その上で、後付けで見えた合理性として、出先で iPhone または iPad しかない場合限定の話ですが、メイン PC とサブ PC を iPhone 上で画面切り替えせず使いたいという欲求があり、3 段構成として残しています。
メイン PC とサブ PC の間は Windows 標準 RDP なので、メイン PC 側の画面の中にサブ PC のウィンドウが乗っている状態になります。手元の iPhone から見ると メイン PC の画面 1 枚を見ているだけで、その中にサブ PC が含まれている形になり、操作感としてはほぼ変わりません。iPhone から直接サブ PC に繋ぐと、メイン PC の確認に都度切り替える必要が生じてしまいます（冒頭で触れた iPad + HDMI 構成も、この「1 画面で複数 PC を扱える」設計だからこそ意味が出てきます）。
なぜこんな多段構成を組むのか — インフラ屋の「冗長経路」癖
そもそもなぜ 3 段リモートのような 多段経路 を当たり前のように組んでしまうのか、という話。
インフラエンジニアは仕事柄、常に冗長経路を考える癖が身についています。
- 本番系が落ちたら待機系へ自動 failover
- メイン回線が切れたらバックアップ回線へ
- BGP マルチホーミング、HSRP / VRRP、LACP...
「ひとつの経路に依存するのは怖い」というのが体に染み込んでいて、個人の作業環境にも同じ発想が滲むのです。ClaudeCode Remote Control が使えない → RustDesk で代替、メイン PC が落ちる → サブ PC で乗り換え。これは「一の経路では本番システムは止められない」という運用の世界の常識を、個人の作業環境に転用しているだけのことだと思っています。
加えて、もう一つ抜けない癖があります。サービス経路（GUI / RDP / RustDesk）と運用経路に加えて、「別機器から入れるか」を探してしまう第三の経路の発想。実際、Tailscale 上で各 PC に SSH を立てておくと、コマンド操作 / scp / sftp / rsync がすべての機器間で実施可能になります。明らかにオーバーエンジニアリングですが、運用畑の方なら **「ああ、それやるよね」**と笑ってくれるはずです。データセンターでは本番系・管理系・帯域外管理 (OOB) と経路が機能ごとに分かれているのが当たり前で、その発想が個人環境にも滲み出ます。
副次価値: onion routing / Proxy 的な「中継経由」の構造
3 段リモート（iPhone → メイン PC → サブ PC）は機能的には RDP の話ですが、経路として見ると:
- 通信が一本道ではなく 複数のホップを経由する
- 出口の IP が 最終ホップの IP になる（手前の経路は隠蔽される）
- ホップごとに 別の認証を経由できる
この構造は onion routing (Tor) や Proxy chain の発想と方向が近いです。Tor ほどの匿名性保証はありませんが、出先の公衆 Wi-Fi から作業するときに 出口 IP を自宅にしたいような用途では、自前 Proxy サーバーを立てるほどでもなく、自然に経路固定ができます。
加えて、メイン PC やサブ PC でしか取り扱えないデータがある場合、出先で iPhone や iPad に それらを格納せずに作業ができるというメリットもあります。データはメイン PC / サブ PC のローカルに留まり、iPhone / iPad は画面と入力を中継しているだけ。盗難 / 紛失時のデータ流出リスクが構造的に低くなり、データの可搬性とセキュリティのバランスを取りたい場面では地味に有効です。
ただし念のため釘を刺しておきます。本構成は 在宅ワークで位置情報や IP アドレスを偽装して「悪さ」をする手段ではありません。接続先の PC（特に業務用や監査対象の PC）には、ログオン / ログオフ時刻、リモート接続元 IP、セッション ID、操作履歴など セッション情報がほぼ確実に保存されます。中継しても 最終ホップのログには「リモート経由で接続された」記録が必ず残ります。経路を遡れば iPhone / Tailscale アカウント / RustDesk ID まで辿れるので、労務監視の回避用途では監査でバレる可能性が極めて高いということは明記しておきます。本構成は「隠れる」ためではなく「繋がる」ためのものです。
注意点
最後に、実際に構築する際の地味な落とし穴をいくつか:
- PC のスリープ深度: 深いスリープに入ると Tailscale + RDP の応答が止まります。電源設定で「Modern Standby」を確認、可能なら「スリープしない」運用が安全
- Microsoft アカウントの本物のパスワード: PIN や Windows Hello だけで普段ログインしていると、RDP に必要な本物のパスワードを忘れがちです。account.microsoft.com で確認 / リセットしておく
- パスワードレスサインインの無効化: Windows 11 のデフォルトは「Microsoft アカウントは Windows Hello のみ」になっていることがあり、この設定が ON だと RDP のパスワード認証が通りません。設定 → アカウント → サインインオプションで OFF にする
- Home エディションは標準 RDP ホスト不可: 受信側にする予定の PC は Pro 以上、または RustDesk 等で代替
どれもハマると 30 分〜数時間溶けるので、先に書いておきます。（AI のおかげで大抵の効率化作業は 2 時間以内に終わるようになったので、全体作業の1項目で 30 分というのは長い時間という感覚になってしまいました）
ここまでのまとめと、その先
20 年前の自分に Tailscale を見せたら、たぶん信じてもらえなかったと思います。証明書配布も、トンネル設定も、NAT トラバーサル職人芸も、内部 DNS 構築も、全部消えて、OAuth ログイン 1 回で mesh が組み上がる世界。
ただこれは「便利になっただけ」の話ではなく、運用の単位が「ネットワーク機器」から「アイデンティティ + デバイス」に変わったというパラダイムシフトの結果なのだと感じています。AI 協業の時代に「個人エンジニアが組織レベルの仕事を 1 人で組み上げる」流れと同じ構造変化が、ネットワーク基盤側にも来ているわけです。