はじめに
tailscale up と一度打つ。それだけで、自宅のノート PC とクラウドのサーバが、同じ LAN にいるかのようにつながる。ポート開放も、固定 IP も、長い設定ファイルもいらない。初めて見たとき、正直「何かの魔法か」と思った。
だが魔法ではない。Tailscale（タイルスケール、WireGuard〔後述の軽量 VPN プロトコル〕を土台にしたメッシュ型 VPN サービス）の裏側は、いくつかの妥当な設計判断の積み重ねでできている。分解すれば、誰でも仕組みで説明できる。
この記事を貫くテーマは、次の二つだ。
- 軽量・高速の正体は WireGuard という最小核：機能を足したのではなく、削ったから軽い。
- メッシュが組めるのは「制御と通信の分離」＋NAT 越え：中央は鍵だけを配り、通信は端末同士が直接張る。
VPN（Virtual Private Network、公衆網の上に仮想的な専用線を引く技術）は、長らく「重くて面倒なもの」だった。その常識を Tailscale がどう覆したのか。ブラックボックスを順番に開けていく。
1. そもそも VPN はなぜ重かったのか
Tailscale の軽さを語る前に、比較対象を思い出しておきたい。従来の VPN は、なぜあれほど重く感じられたのか。
理由は大きく二つある。構成が中央集約だったことと、暗号の交渉が複雑だったことだ。
OpenVPN（通信を暗号化する標準規格 TLS〔Transport Layer Security〕をベースにした定番の VPN ソフト）や IPsec（IP 層でパケットを暗号化する規格群）では、多くの場合すべての通信が中央のサーバを経由する。いわゆるハブ&スポーク型だ。拠点 A から拠点 B へ届けたいだけでも、パケットは一度ハブまで上り、そこから下りていく。
これは、駅が一つしかない鉄道網に似ている。隣町へ行くだけでも、わざわざ中央駅まで出ないといけない。ハブの帯域と CPU がボトルネックになり、ハブが落ちれば全員が止まる。
もう一つの重さは、接続を確立するまでの「交渉」にある。IPsec では、どの暗号アルゴリズムを使うか、鍵をどう交換するかを、接続のたびに両者がすり合わせる。選べる組み合わせが多いぶん、設定項目は膨れ上がり、相互接続でハマりどころも増える。設定ファイルが数百行に達することも珍しくない。
柔軟さと引き換えに、複雑さと遅さを抱え込んでいた。ここに「逆の発想」で切り込んだのが WireGuard だ。
2. WireGuard ―「最小核」という思想
WireGuard（ワイヤーガード、Linux カーネルにも統合された軽量 VPN プロトコル。公式サイト）が軽い理由は、ひとことで言える。機能を足したからではなく、削ったからだ。
象徴的なのがコード量だ。OpenVPN や IPsec の実装が数十万行規模なのに対し、WireGuard のコア実装は約 4,000 行しかない。少ないコードは、読める・監査できる・バグが潜みにくい。セキュリティ製品にとって「小ささ」はそのまま信頼性になる。十徳ナイフではなく、よく研いだ一本の包丁を選んだ、と言ってもいい。
暗号スイートを固定した
WireGuard は暗号アルゴリズムを交渉しない。最初から一式に固定している。
- 鍵共有：Curve25519（楕円曲線を使った鍵交換）
- 暗号化：ChaCha20-Poly1305（認証付き暗号、AEAD）
- ハッシュ：BLAKE2s
- 全体の枠組み：Noise プロトコルフレームワーク（鍵交換手順の設計図）
暗号化と改ざん検知を同時に行う AEAD（Authenticated Encryption with Associated Data）を一つに決め打ちした。これで「どれを使うか」という交渉が丸ごと消えた。交渉がなければ、弱い方式へ引きずり下ろすダウングレード攻撃も成立しない。選択肢を捨てたことが、速さと安全の両方を生んでいる。暗号設計の細部は WireGuard 公式のプロトコル解説に明文化されている。
公開鍵がそのまま身元になる
WireGuard には、ユーザー名もパスワードもない。各ノードは鍵ペアを一つ持ち、公開鍵がそのまま身元（アイデンティティ） になる。相手の公開鍵を知っていることが、相手を認める唯一の条件だ。
通信は UDP（User Datagram Protocol、軽量で高速なデータ転送方式）だけで動く。接続の確立は 1-RTT、つまり「一往復」で終わる。RTT（Round Trip Time、パケットが往復する時間）が一回で済むので、つながり始めが速い。
宛先を鍵で決める ― Cryptokey Routing
WireGuard 独特の発想が、Cryptokey Routing（暗号鍵ルーティング） だ。「この公開鍵の相手には、この IP アドレス範囲を割り当てる」という対応表を持つ。
すると、ある宛先 IP へのパケットは「どの公開鍵で暗号化すべきか」が一意に決まる。逆に、復号できたパケットは「正しい相手から来た」と確定する。ルーティングと認証が一枚の表に統合されている。ここが薄さの効いている部分だ。
ただし、WireGuard は一つだけ宿題を残す。「相手の公開鍵と、相手の現在地（IP:ポート）を、どうやって知るか」 である。2 台ならば手で書けばいい。だが 10 台、100 台になると、全組み合わせを手で設定するのは現実的でない。この宿題を解いたのが Tailscale だ。
3. Tailscale の本質 ― 制御と通信を分けた
Tailscale がやったことは、ひとことで言うと 「制御（コントロールプレーン）と通信（データプレーン）の分離」 だ。WireGuard が残した鍵配布の宿題を、専用の中央サーバに切り出して解いた（全体像は Tailscale 公式の How Tailscale works が詳しい）。
コーディネーションサーバは「連絡網」だけを配る
Tailscale には、コーディネーションサーバ（coordination server、調整役の中央サーバ）がいる。各ノードは起動すると、自分の公開鍵と今いる場所（候補となる IP:ポート） をここへ登録する。サーバは、誰と誰が通信してよいか（ACL、アクセス制御リスト）に従って、その情報を必要なノードへ配る。
ここで決定的に重要な点がある。秘密鍵は一度も端末から出ない。 サーバが扱うのは公開鍵と接続先情報、そしてポリシーだけだ。だから、たとえコーディネーションサーバが覗かれても、通信そのものは復号できない。
同窓会の幹事を思い浮かべるとわかりやすい。幹事は参加者の連絡先リストを配るが、会話の中身には入らない。話すのは本人同士だ。Tailscale の中央サーバは、この幹事に徹している。
図の点線が制御、太線が通信だ。鍵とポリシーは中央を通るが、実トラフィックは一切中央を通らない。 ここが従来のハブ&スポークとの最大の違いになる。中央はボトルネックにならず、落ちても既存の接続は生き続ける。
tailnet という一枚のネットワーク
こうして束ねられた仮想ネットワークを tailnet（テイルネット）と呼ぶ。tailnet 内の各ノードには、100.x.y.z という安定した固定 IP が一つ割り当てられる。これは CGNAT（Carrier-Grade NAT、通信事業者級の大規模 NAT）用に予約された 100.64.0.0/10 の範囲（インターネットには出ない私的アドレス帯）を使っている。
さらに MagicDNS（マジック DNS、ホスト名を自動で名前解決する機能）を使えば、IP を覚えずとも ssh my-server のように名前でつなげる。物理的な場所がどこであれ、利用者からは「一枚のフラットな LAN」に見える。
ここまでで「制御と通信を分けた」という柱は見えた。だが、最後の難関が残っている。お互いが NAT（Network Address Translation、ルータが内側の私的アドレスを一つの公開アドレスに変換する仕組み）の内側にいるとき、どうやって直接つながるのか、だ。
4. なぜメッシュが組めるのか ― NAT 越えの仕組み
メッシュ（mesh、各ノードが互いに直接つながる網目状の構成）を組むうえで、最大の壁になるものがある。先ほど触れた NAT だ。
家庭やオフィスの機器は、たいてい NAT の内側にいる。内側から外へは出られるが、外から内へは原則入れない。両端がともに NAT の内側だと、普通は直接の接続を張れない。ここを Tailscale はどう貫くのか。
ステップ1：自分の「外から見える住所」を知る
ノードはまず、自分がインターネットから見たときどの IP:ポートに見えているかを調べる。STUN（Session Traversal Utilities for NAT、自分のグローバル側アドレスを知るための仕組み）に相当する方法だ。得られた候補は、先ほどのコーディネーションサーバ経由で相手に伝えられる。
ステップ2：両側から同時に穴を開ける ― ホールパンチング
次が UDP ホールパンチング（UDP hole punching）だ。両端が同時に相手へ向けて外向きの UDP パケットを送る。
NAT は「内側から出した通信の戻り」を通す性質がある。両側がほぼ同時に送ると、それぞれのルータに一時的な「戻り口（穴）」が開く。相手のパケットがその穴に滑り込み、直接の通り道ができる。両側から同時にトンネルを掘り、真ん中で貫通させるイメージだ。
ステップ3：つながるまでの保険 ― DERP リレー
とはいえ、穴開けは常に成功するわけではない。NAT の種類が厳しいと、どうしても直接つながらない組み合わせがある。そこで DERP（Designated Encrypted Relay for Packets、Tailscale が運用する暗号化中継サーバ）が効く。
DERP は HTTPS の上で動く中継所だ。役割は二つある。
- ブートストラップ：穴を開けている最中も、まず DERP 経由で通信を始める。つながりが途切れない。
- フォールバック：直接接続にどうしても失敗したペアは、そのまま DERP 中継で通信を続ける。
重要なのは、DERP を通る場合でも中身は WireGuard で暗号化されたままという点だ。中継所は暗号文を右から左へ流すだけで、読めない。
結果として全員が直接つながる
この「発見 → 穴開け → 必要なら中継」を、すべてのノードのペアが裏で同時にやっている。だから、つながり始めは DERP 経由でも、しばらくすると多くのペアが direct（直接）へ昇格する。
tailscale status を打つと、各相手が direct か relay（DERP 経由）かが見える。最初 relay だった行が、数秒後に direct へ変わる瞬間を観察できる。あの一行の裏で、ここまでの処理が走っている。
各ペアが自前のトンネルを持つので、全体としてフルメッシュになる。中央を経由しないから速く、ペアごとに独立しているから一部が切れても他は平気だ。これが「メッシュ VPN が組める」ことの正体である。
NAT 越えの細部は、Tailscale の How NAT traversal works と DERP servers の解説 に踏み込んだ記述がある。
5. なぜ人気なのか ― 体験と設計が噛み合っている
ここまで来ると、人気の理由は「ただ楽だから」では説明が浅いとわかる。軽さと分離という設計が、そのまま使い心地に直結しているからだ。
第一に、ほぼゼロコンフィグである。鍵交換も NAT 越えも経路設定も、すべて裏で自動化された。利用者は tailscale up を打つだけでよい。これは、3 章の「制御の集約」と 4 章の「NAT 越えの自動化」がそのまま体験になっている。
第二に、既存の ID でログインできる。SSO（Single Sign-On、手持ちのアカウントで一括ログインする仕組み）に対応する。Google や GitHub の ID でそのまま入れるので、誰をネットワークに入れるかを既存の ID 基盤で管理できる。
第三に、アクセス制御をコードで書ける。どのノードがどのノードに到達してよいかを ACL として記述できる。ゼロトラスト（誰も無条件には信用せず、接続ごとに認可する考え方）を実践しやすく、「VPN に入れたら何でも見える」を避けられる。
そして第四に、軽いから常時接続でも気にならない。WireGuard の薄さが、バッテリーや帯域への負担を小さく抑える。設計の薄さが、そのまま指先の軽さになっている。
自前で運用したい人には Headscale（ヘッドスケール、コーディネーションサーバの OSS 実装）という選択肢もある。中央サーバまで自分の手元に置ける。設計が分離されているからこそ、中央だけ差し替える、という芸当が成り立つ。
おわりに
仕組みをたどってみると、Tailscale は魔法ではなく、妥当な設計の積み重ねだった。最後に二本柱を振り返る。
- 軽量・高速の正体は WireGuard という最小核：暗号スイートを固定し、約 4,000 行に削ぎ落とした薄さが、速さと安全を同時に生む。
- メッシュが組めるのは「制御と通信の分離」＋NAT 越え：中央は鍵とポリシーだけを配り、実通信は端末同士が直接張る。NAT 越えがそれを現実にする。
仕組みを知ると、ツールは安心して使えるようになる。ブラックボックスのままだと、トラブル時に手も足も出ない。だが「今これは DERP 経由だな」「直接に昇格したな」と読めれば、対処の解像度が一段上がる。
次の一歩は簡単だ。手元で tailscale up を打ち、tailscale status で相手が direct か relay かを覗いてみてほしい。もう一歩踏み込むなら、Headscale で中央サーバごと自分の手元に立ててみる。この記事で開けた箱の中身が、画面の上で動いているのが見えるはずだ。
追記：TCP/IP モデルでどこにいて、なぜ外に出た瞬間に安全になるのか
公開後に質問が多かった二点を補っておく。「Tailscale（WireGuard）は TCP/IP モデルのどの層にいるのか」、そして「なぜ物理ネットワークに出た瞬間に安全といえるのか」だ。
L3（ネットワーク層）のトンネルである
結論から言うと、WireGuard は L3、OSI でいうネットワーク層（TCP/IP モデルのインターネット層）で動くトンネルだ。仕組みはこうだ。WireGuard は OS に仮想ネットワークインターフェース（Linux なら wg0、macOS なら utun といったトンネル用デバイス）を一枚生やす。このインターフェースには、3 章で触れた 100.x.y.z の IP が割り当たる。アプリは普段どおり「宛先 IP」へパケットを送るだけでよい。OS のルーティングがそのパケットを仮想インターフェースへ流し込み、WireGuard が受け取る。
ここが肝だ。WireGuard が扱うのは IP パケットそのもの、つまり L3 の荷物である。だからアプリ側に改修はいらない。ブラウザも SSH も DB クライアントも、「相手の IP に送る」という当たり前の動作のまま、気づかぬうちにトンネルを通る。L3 で動くからこそ、既存のアプリにそのまま被せられる。これが「設定がほぼ要らない」体験の土台でもある。
ひとつ補足すると、トンネルの中身は L3 の IP パケットだが、それを運ぶ外側は UDP（L4）だ。暗号化した荷物を UDP データグラムに詰め、相手の物理アドレスへ飛ばす。「中身は L3、配送便は L4」と二段に分けて眺めると、頭の中が整理される。
なぜ「外に出た瞬間」に安全なのか
本題はこちらだ。なぜ物理ネットワークに出た時点で安全といえるのか。鍵は「暗号化の境界がどこにあるか」にある。
平文の IP パケットが存在するのは、アプリから仮想インターフェースまでの、ホスト内部のメモリ上だけだ。WireGuard はパケットを受け取るとすぐ、相手ごとのセッション鍵（2 章のハンドシェイクで導出したもの）を使って ChaCha20-Poly1305 で暗号化する。元の IP パケットは丸ごと暗号文になり、UDP の中身として封をされる。そのうえで初めて、本物の NIC（物理ネットワークカード）へ渡され、ケーブルや電波に乗る。
だから、家庭の LAN もルータも ISP も、経由するインターネットの各ルータも、さらには 4 章の DERP リレーですら、見えるのは「二つの端点の間を飛ぶ、中身の読めない UDP パケット」だけだ。中に入っている本当の送信元・宛先 IP も、ペイロードも読めない。AEAD の認証タグが付くので、途中で 1 ビットでも書き換えれば受信側が弾く。盗み見も改ざんも成立しない。
封筒にたとえるなら、手紙は自分の机の上で封をしてからポストに入れる。配達員も中継局も、封筒の外側しか見られない。Tailscale には「社内だから平文でいい」という例外モードがない。tailnet の中であっても、物理ネットワークを 1 ホップでも進む荷物は、例外なく暗号文だ。secure by default（既定で安全）とは、この「出る前に必ず封をする」設計を指す。
しかも鍵は定期的に更新される（前方秘匿性）。今この瞬間の通信を丸ごと記録され、後日どこかで鍵が漏れても、過去のセッションはもう復号できない。
まとめると、Tailscale が L3 のトンネルだからアプリを選ばず被せられ、暗号化の境界をホストの内側に置くから、ネットワークへ出る荷物は最初から暗号文になる。「軽さ（最小核）」と「安全（出る前に封をする）」は、同じ WireGuard の設計から同時に生まれている。一つ目の柱を、別の角度から言い換えた姿だ。