著者 WireGuardとTailscaleとHeadscaleの違いと選び方
TailscaleはWireGuardにコントロールプレーンを加えたものです。設定管理、NAT越え、運用コストを比較し、VPSにWireGuard、Tailscale、Headscaleのどれを選ぶべきか解説します。
WireGuardとTailscaleの比較：簡単な結論
WireGuardとTailscaleの比較は、2つのプロトコルから選ぶ問題ではありません。Tailscale自体がWireGuardだからです。Tailscaleは同じ暗号化と同じトンネルを使用し、さらにコントロールプレーンを追加します。コントロールプレーンは、公開鍵を交換し、アドレスを割り当て、NAT（ネットワークアドレス変換）を越えるための穴あけを行い、アクセス ポリシーを適用する調整サーバーです。選択するのは、その調整機能のどこまでを自分で運用するかです。
正直な答えは3つあります。1台のサーバーに少数のクライアントがすべて接続する場合は、通常のWireGuardを使用します。設定ファイルを管理せず、すべてのマシンから他のすべてのマシンに接続したい場合は、Tailscaleを使用します。そのメッシュ構成が必要で、第三者にノード一覧を保持させたくない場合は、Headscaleを使用します。
コントロールプレーンで実現できること
素の WireGuard にはサービス検出機能がありません。各ピアは、公開鍵、AllowedIPs 行、そしてそのピアに到達できる場合の Endpoint を手動で記述したテキストブロックです。10台のネットワークに1台追加する場合、両側で相手の鍵が必要になるため、10個の設定ファイルを編集する必要があります。そのため、ほとんどすべてのセルフホスト型 WireGuard 構成はハブアンドスポークです。パブリック IP を持つ1台のサーバーと、そのサーバーとのみ通信するクライアントで構成されます。
コントロールプレーンを使うと、設定ファイルの編集が不要になります。各ノードは1回登録すると、100.64.0.0/10 CGNAT (carrier grade NAT) 範囲からアドレスを受け取り、通信を許可されたノードの公開鍵を通知されます。トンネルは2つのピア間の直接の WireGuard 接続のままです。通信がコーディネーションサーバーを経由することもありません。サーバーが保持するのはメタデータです。存在するノード、その公開鍵、通信を許可されるノードの関係を保持します。
具体的には、次の3つを実現できます。
NAT トラバーサル。 2台のノート PC がそれぞれ別の家庭用ルーターの背後にある場合、両者の間にパブリック IP はありません。Tailscale は STUN (session traversal utilities for NAT) を使って、それぞれの外部アドレスとポートを検出します。その後、両側が同時にパケットを送信するため、各ルーターは先に送信フローを確認し、返信を受け入れます。これに失敗すると、通信は DERP リレーにフォールバックします。DERP リレーは Tailscale が運用する暗号化リレーです。リレーは鍵を保持しないため、リレー経由でもデータはエンドツーエンドで暗号化されます。tailscale status を実行すると、各ピア行に direct または relay と表示されます。tailscale netcheck を実行すると、最寄りのリレーと、ネットワークが UDP をまったく許可しているかどうかを確認できます。
有効期限付きの鍵ローテーション。 WireGuard の鍵には有効期限がありません。3年前に発行した鍵も、手動でピアブロックを削除しない限り永久に使用できます。これに対して Tailscale はノードキーに有効期限を設定します。2026年7月現在、新しい tailnet のデフォルトの有効期限は180日です。再認証していないマシンは接続できなくなります。サーバーやサブネットルーターなど、ログインできる利用者がいないデバイスでは、デバイスごとに有効期限を無効にできます。
ルーティングではなくポリシー。 素の WireGuard では、AllowedIPs がルーティングテーブルとアクセス制御リストを兼ねています。そのため、「alice はデータベースに到達できる」というルールを IP 範囲で表現する必要があります。Tailscale は独立したポリシーファイルを使用し、ルール内でユーザー、グループ、タグを指定します。tag:laptop がポート5432の tag:db にのみ到達でき、それ以外には到達できないというルールを設定できます。このルールは、マシンに新しいアドレスが割り当てられても維持されます。
コントロールプレーンにかかるコスト
調整サーバーはネットワークの情報を把握します。すべてのノードの公開鍵、ノード名、割り当てたアドレス、ポリシーを保持します。ホスト型 Tailscale を使用する場合、このサーバーはお客様が管理できない外部企業にあります。WireGuard の秘密鍵はお客様のマシンに保存されるため、相手がパケットを読み取ることはできません。ただし、ネットワークの構成は相手から見える状態になります。また、接続できるかどうかは、相手のサービスが稼働していることと、お客様のアカウントが正常な状態であることに依存します。
見落としやすい2つ目のコストがあります。Tailscale はすべてのマシンでデーモンとして動作するため、すべてのマシンでパッチを適用して保守するソフトウェアが増えます。Ubuntu 24.04 の標準の WireGuard はディストリビューションに含まれるカーネルモジュールで、カーネルとともに更新されます。
3つ目のコストは料金です。2026年7月時点で、Personal プランは最大6ユーザーまで無制限のデバイスを無料で利用できます。Standard はユーザー1人あたり月額 $8、Premium はユーザー1人あたり月額 $18 です。家庭での利用は無料のままです。10人のチームでは無料になりません。
plain WireGuard が適切な場合
トポロジーが実際にハブアンドスポーク型である場合は、plain WireGuard を選択します。パブリック IP を持つ VPS が1台あり、そこに接続するデバイスが3台または4台あり、それらのデバイス同士が通信する必要がない構成です。設定は1画面に収まり、更新が必要なデーモンも、失うアカウントもありません。サーバーとの間に外部サービスが入ることもありません。
また、他のすべての基盤となるレイヤーを理解したい場合にも適しています。VPS で WireGuard VPN をセルフホスティングするでは、鍵の生成、wg0.conf、IP forwarding、NAT、ハンドシェイクの失敗について説明しています。これらの仕組みは、tailnet の下でもすべて動作しています。以前からある選択肢も検討している場合は、WireGuard と OpenVPN の比較で、OpenVPN が優位性を保つ4つのケースを説明しています。
インストールは簡単です。
sudo apt update && sudo apt install -y wireguard
sudo modprobe wireguard && echo okplain WireGuard が扱いにくくなるのは、すべてのデバイスが他のすべてのデバイスに接続する必要が生じた時点です。N ノードのフルメッシュには、N × N - 1 個の peer ブロックが必要です。デバイスが6台になると、30個のブロックを手動で同期する必要があります。また、重複した AllowedIPs エントリが、先に登録されていた peer からネットワークトラフィックをひそかに奪います。この場合も、どこにもエラーは表示されません。
Tailscaleが適している場合
マシンが移動する場合は、Tailscaleを選択します。ホテルのネットワークに接続するノートPC、モバイルデータ通信を使用するスマートフォン、管理していないルーターの背後にあるホームサーバーなどです。これらは、通常のWireGuardでは適切に処理できません。双方に、Endpointに設定できる安定したパブリックエンドポイントがないためです。
クライアントは、公式インストーラーから1つのコマンドでインストールできます。
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale statustailscale upはURLを出力します。そのURLを開いてログインすると、マシンがネットワークに参加します。コピーする暗号鍵も、開放する受信ポートもありません。デーモンが調整サーバーへの外向き接続を確立し、その接続を維持するためです。そのため、ファイアウォールをまったく管理していないネットワークでもTailscaleノードを使用できます。
その後は、主に2つの設定が役立ちます。サブネットルーターはLAN全体をネットワークに広告するため、すべてのデバイスにクライアントをインストールする必要がありません。
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
sudo tailscale set --advertise-routes=192.0.2.0/24管理コンソールで承認するまで、ルートは無効のままです。これは意図された動作です。ノードが独自にネットワークへルートを追加できないようにするためです。Linuxクライアントではsudo tailscale set --accept-routesも必要です。Linuxはデフォルトでは広告されたルートを受け入れないためです。そのため、サーバー側で承認済みに見えるルートでも、これを設定するまでLinuxノートPCでは機能しません。
Exit nodeを使用すると、クライアントのすべてのトラフィックが1台のマシンを経由します。これは、一般に「VPN」と呼ばれるフルトンネル動作です。
sudo tailscale set --advertise-exit-nodeHeadscaleが適している場合
Headscaleは協調サーバーのオープンソース実装で、所有するVPS上で実行できます。公式のTailscaleクライアントは、ホスト型サービスではなくHeadscaleを接続先に指定します。
sudo tailscale up --login-server https://headscale.example.comデータパスは変わりません。引き続きWireGuardを使用し、ネットワークが許可する場合はピア間で直接通信します。変わるのは、ノード一覧、暗号鍵、ポリシーが、所有するディスク上のSQLiteファイルに保存される点です。外部の誰も、ネットワーク構成を確認したり、アカウントを無効化したり、ユーザー単位で課金したりできません。
その代わり、運用作業が必要です。公開HTTPSサービスを運用するため、DNS名、証明書、WebSocketのアップグレードを正しく中継するリバースプロキシが必要です。可用性も自分で維持します。協調サーバーが停止すると、新しいノードは登録できず、既存のノードは変更を取得できません。Headscaleはまだバージョン1.0未満で、マイナーリリースでも互換性を損なう変更が行われています。そのため、アップグレードの前に毎回変更履歴を確認してください。自分のTailscale制御サーバーとしてHeadscaleを実行するでは、インストール、config.yaml、事前認証キー、開放するポートについて説明しています。
見落とされがちな注意点があります。Headscaleには、Tailscaleのグローバルリレーネットワークが付属しません。2つのピアが直接接続できない場合は、自分のサーバーで組み込みリレーを有効にするか、別のリレーを設定で指定します。このリレーは世界中に分散した構成ではなく、1つのリージョンにある単一のサーバーです。地球の反対側にいるピアでは、その違いが通信性能に表れます。
1回で判断する方法
相互に接続する必要があるマシンの数を確認します。すべてのマシンがサーバーとだけ通信する場合は、同じ結果を得るために必要なソフトウェアが少ない plain WireGuard が適しています。
マシンに安定したパブリックアドレスがあるか確認します。大半が管理できない NAT の背後にある場合は、control plane が必要です。難しいのは hole punching であり、その仕組みを自分で再構築する価値はありません。
ネットワーク構成を誰に知られてよいか確認します。外部企業を含めたくない場合、またはユーザー数が多く、ユーザー単位の課金が負担になる場合は、Headscale を実行します。その場合は、control server も自分で運用する必要があります。
判断を変えても、大きなコストはかかりません。3つの構成では data plane に同じプロトコルを使用するため、plain WireGuard から調整されたメッシュへ移行する場合は、再設計ではなくクライアントのインストールで済みます。Tailscale から Headscale へ移行する場合も、各ノードを別の login server に対して再登録するだけです。
3つのいずれでも提供されないもの
いずれもファイアウォールではありません。トンネルは、どのパケットを転送するかを決めます。どのサービスが待ち受けるかは決めません。トンネル経由で到達できるサーバーは、開いたままのポートがあれば、そのポートでインターネットからも引き続き到達できます。そのため、VPS上のUFWファイアウォールルールが機能する状態を維持してください。Tailscaleのポリシーファイルは、他のノードが到達できる対象を制限します。ただし、パブリックインターフェイスには影響しません。
いずれもサービスごとの認証機能ではありません。また、接続後にユーザーが実行した操作の監査証跡を提供するものでもありません。3つともトランスポートとして扱い、ログイン確認はアプリケーション側で実装してください。
FAQ
Tailscaleは追加手順のあるWireGuardにすぎませんか？
TailscaleはデータパスにWireGuardプロトコルを使用するため、暗号化とトンネルは同じです。Tailscaleが追加するのは、調整機能です。鍵交換、アドレス割り当て、STUNとDERPリレーによるNATトラバーサル、鍵の有効期限、IP範囲ではなくユーザーを指定するポリシーファイルが含まれます。これらは通常のWireGuardでは利用者が管理します。マシンがネットワーク間を移動すると、これらの管理が難しくなります。
トラフィックはTailscaleのサーバーを経由しますか？
通常は経由しません。調整サーバーがピアを相互に認識させると、ピア同士が直接接続します。tailscale status を使用すると、これらのピア行に direct と表示されます。直接パスを確立できない場合、トラフィックはDERPリレーにフォールバックし、行には relay と表示されます。この場合も、リレーが運ぶのは暗号化されたパケットだけです。リレーはWireGuardの秘密鍵を保持しないため、内容を読み取れません。tailscale netcheck を実行すると、直接接続に必要なUDPをネットワークがブロックしているか確認できます。
公式のTailscaleアプリでHeadscaleを使用できますか？
はい。Headscaleは同じ制御プロトコルを使用するため、公式クライアントは sudo tailscale up --login-server https://headscale.example.com で参加できます。デスクトップアプリとモバイルアプリでは、カスタムログインサーバーを指定することもできます。ただし、設定場所はプラットフォームごとに異なります。特定のバージョンが必要になる可能性が高いのはモバイルアプリです。ネットワーク全体を移行する前に、1台のスマートフォンでテストしてください。
TailscaleまたはHeadscaleでポートを開く必要はありますか？
Tailscaleクライアントでは、受信ポートを開く必要はありません。クライアントが調整サーバーへ外向きに接続し、その接続を維持するためです。自己ホスト型のHeadscaleサーバーでは、受信ポートが必要です。制御プロトコルには443、HTTP-01証明書チャレンジを使用する場合は80、組み込みリレーを有効にする場合のみ3478/udpを開きます。通常51820のPlain WireGuardのUDPリッスンポートは、サーバーと、プロバイダーが別途提供するネットワークファイアウォールの両方で開く必要があります。
3つのうち、最も高速なのはどれですか？
3つともWireGuardでパケットを転送するため、スループットは同じです。違いは、接続の確立時間とパスの品質に現れます。正しい Endpoint を設定したPlain WireGuardは、毎回直接接続します。TailscaleとHeadscaleは通常、直接接続します。ただし、ネットワークがホールパンチングをブロックするとリレーへフォールバックし、リレー経由のパスでは遅延が増加します。tailscale ping <node> を使用すると、自分のパスが直接接続かリレー経由か確認できます。トンネル経由で iperf3 を実行して測定することもできます。