Tailscaleの安全性は大丈夫？暗号化の仕組み・脆弱性・既定設定の落とし穴と料金【2026年10月】

Tailscale（テールスケール）は、WireGuardを土台にしたメッシュ型VPNです。端末にアプリを入れてログインするだけで、端末同士が暗号化された通信でつながります。では、安全性は信頼できるのか。結論から言うと、通信の中身はTailscale社にも読めない設計で、暗号化の仕組みに大きな不安はありません。注意すべきは別のところにあり、作成直後のtailnetはACL（アクセス制御）が「全端末から全端末へ許可」で、クライアントは接続の記録をTailscale社のログサーバーへ送ります。この記事では、公式ドキュメントとセキュリティ公報（Security Bulletins）、Tailscale v1.104.1のコマンドヘルプをもとに、安全と言える根拠、既定設定に残るリスク、2025〜2026年に出た脆弱性、料金と安全な始め方を整理します。

まとめ：Tailscaleの安全性の結論と、導入直後に見直す設定

Tailscaleの通信はWireGuardで端末間を暗号化し、秘密鍵は生成した端末から出ません。直接つながらないときに使う中継サーバー（DERP）も通信を復号できません。この点で「通信の中身を盗み見られる」という不安は当たりません。

一方、次の4点を知らずに使うと危険につながります。

• 新規tailnetのACLは全許可。1台が乗っ取られると、ほかの全端末へ到達できる
• クライアントは接続の開始・終了を含むログを log.tailscale.com へ送る。中身は送らないが、メタデータは残る
• Tailnet Lock（Tailscale社の制御サーバーを信頼しなくて済む機能）はPersonalとEnterpriseだけで、Standard・Premiumでは使えない
• 2026年は8月までに公報が11件出ており、Tailscale SSHに関するものが多い。クライアントの更新を止めると穴が残る

個人の非商用利用は無料のPersonalプランで6ユーザーまで使えます。業務で使うなら1ユーザー月8ドルのStandard以上が前提です。以下、根拠と具体的な設定を順に説明します。

Tailscaleとは：WireGuardベースのメッシュ型VPNと運営会社

読み方と運営会社（どこの国の製品か）

読み方は「テールスケール」で、「テイルスケール」と表記されることもあります。開発元のTailscale Inc.は、2019年にAvery Pennarunら3人が設立したカナダの会社です。利用規約の契約主体は、2024年9月2日までに作られたアカウントがトロントに登録住所を置くTailscale Inc.、9月3日以降の新規アカウントが米国デラウェア州法人のTailscale US Inc.（サンフランシスコ）です。2025年4月にはAccel主導のシリーズCで1億6,000万ドルを調達しています。プライバシーポリシー（2026年8月25日発効）は、法執行機関からの開示請求についてカナダの刑法と米国のStored Communications Actに沿って扱うと定めており、カナダでは原則として裁判官の令状が必要です。

接続の仕組み：直接接続・DERP中継・Peer Relay

Tailscaleでつないだ端末の集まりを「tailnet」と呼びます。端末同士はまずNAT越え（NAT traversal）で直接のUDP通信を張ろうとし、ルーターのポート開放は要りません。ファイアウォールが厳しく直接つながらないときは、Tailscale社のDERPサーバーが暗号化されたパケットを中継します。DERPのドキュメントは、秘密鍵が端末から出ないためDERP側で通信を復号することはできない、と説明しています。自分の端末を中継役にするPeer Relayを設定すると、DERPより先にそちらが使われます。

鍵と設定を配る制御サーバー（コントロールプレーン）と、実際の通信（データプレーン）が分かれている。これが安全性を考える前提です。

Tailscaleの通信が安全と言える根拠：暗号化と鍵の置き場所

WireGuardによる端末間の暗号化と秘密鍵の保管

端末間の通信はWireGuardのセッションで暗号化されます。Tailnet Lockのホワイトペーパーによると、セッションは端末ごとに固有のX25519公開鍵（ノード鍵）で認証・暗号化され、端末同士の通信はピアツーピアです。制御サーバーが配るのは相手のIPアドレス、パケットフィルタのルール、公開鍵といった情報で、通信そのものは通りません。WireGuardの暗号方式そのものはWireGuardとは何かで詳しく扱っています。

鍵の保管場所も見ておきます。v1.104.1の tailscaled --help には、端末上の状態ファイルを暗号化する -encrypt-state（LinuxとWindowsはTPMを使用）と、端末のハードウェアに鍵を結び付ける -hardware-attestation（TPM 2.0やSecure Enclave）が載っています。サーバーでは状態ファイルの保護まで確認してください。

Tailscale社が見られる情報・見られない情報

Tailscale社はセキュリティページで「Tailscale cannot read your traffic」と明言し、HIPAAの対象サービスが無い理由を「顧客データを保存せずメタデータだけを扱うため」と説明しています。読めないのは中身で、メタデータは扱うという意味です。

具体的には、ログの公式ドキュメントに「各エージェントはログを中央のログサーバー（log.tailscale.com）へ送り、そこには端末間のTCP・UDP接続ごとの開始・終了イベントが含まれる」と書かれています。「Tailscaleはログを残さない」という説明を見かけますが、接続の記録については当てはまりません。

送信を止めるには、端末ごとに tailscaled を --no-logs-no-support 付きで起動するか、環境変数 TS_NO_LOGS_NO_SUPPORT=true を設定します。名前どおり技術サポートは受けられなくなります。Windowsは環境変数の方法だけ、macOSはオープンソース版の tailscaled でしか使えません。ログの送信が問題になった実例として、2026年7月の公報TS-2026-010では、Tailscale SSHで転送した環境変数（トークンなど）の値が、この設定をしていない端末では log.tailscale.com のセッションログに記録されていました。

制御サーバーを信頼する問題とTailnet Lock

海外の掲示板で「Tailscaleは本当に安全か」と議論される中心はここです。Tailnet Lockのドキュメント自身が、制御サーバーはtailnetに端末を追加・削除でき、利用者はその判断を信頼するしかないと認めています。制御サーバーが乗っ取られれば、攻撃者の鍵を正規の端末として配られ、通信に割り込まれるおそれがあります。

Tailnet Lockを有効にすると、新しい端末の公開鍵に、利用者が指定した署名ノードの署名（Ed25519）が必要になります。署名を検証できない鍵では通信を始められません。署名に使う鍵は制御サーバーに渡らないため、制御サーバーが侵害されても端末を勝手に追加できない仕組みです。使う前に知っておくべき制約は次のとおりです。

• 提供はPersonalとEnterpriseのみ。StandardとPremiumでは使えない
• 最初の状態は制御サーバーから受け取るTOFU（初回は信頼する）方式。全端末で tailscale lock status の署名鍵が一致するか確かめる
• デバイス承認（Device approval）とは同時に使えない。署名ノードは最大20台、Androidは署名ノードにできない
• 無効化に必要なdisablement secretは初期化時にしか表示されない（管理画面が示すコマンドでは10個、CLIの既定は1個）。失ってサポートにも預けていなければ、各端末で tailscale lock local-disable を実行して回避するしかない

機能にも不具合は出ています。2025年11月の公報TS-2025-008では、--statedir も --state も指定せずに tailscaled を動かしていたLinuxなどの端末が、Tailnet Lockの署名検査をしていませんでした（1.90.8で修正）。Tailnet Lockを使うなら、サーバー側の起動オプションまで確認が要ります。

制御サーバー自体を自分で持つ選択肢として、互換サーバーのheadscaleがあります。Tailscale社の可用性保証は受けられなくなるので、構築の手間と比べて決めてください。手順と判断の目安はheadscaleの使い方と採用判断にまとめています。

Tailscaleは危険？既定設定に残るリスクと見直し方

暗号化の仕組みに問題がなくても、既定値のまま使うと防げるはずの侵入経路が残ります。v1.104.1のコマンドヘルプ（macOSでビルドしたオープンソース版）と公式ドキュメントで確認した既定値を並べます。

--accept-routes だけはOSで既定が分かれます。CLIリファレンスによると、Windows・iOS・Android・macOSのApp Store版とStandalone版は他の端末が広告したサブネット経路を受け入れ、それ以外は受け入れません。

既定のACLは全許可：最小権限に書き換える例

旧来の解説には「ACLはデフォルト拒否」と書かれたものがありますが、正確ではありません。ACLの公式ドキュメントによると、ルールの書き方自体は「明示しない通信は拒否」ですが、tailnetを作った直後のポリシーファイルには全許可のルール（"src": ["*"] から "dst": ["*:*"]）が入っています。acls の項目を消しても全許可のままで、全拒否にしたいときは "acls": [] と空の配列を書きます。ただしACLと後継のgrantsは同じファイルに併存でき、許可は足し合わされるので、grants側に許可が残っていないかも確かめてください。

次は、管理者グループだけがサーバー用タグの22番と443番に入れ、一般メンバーは自分の端末同士だけ通信できるようにした例です。新しく書く設定はACLではなくgrantsで書くよう公式が推奨しているので、grantsで書いています。既定の全許可ルールを残したまま追記すると制限にならないため、ルールはこの内容に置き換えます。tests は、ポリシーを保存するたびに「この通信は通る・通らない」を検査し、外れると保存を拒否する機能で、全プランで使えます。

{
  "groups": {
    "group:admins": ["[email protected]"],
  },
  "tagOwners": {
    "tag:server": ["group:admins"],
  },
  "grants": [
    {"src": ["group:admins"], "dst": ["tag:server"], "ip": ["tcp:22", "tcp:443"]},
    {"src": ["autogroup:member"], "dst": ["autogroup:self"], "ip": ["*"]},
  ],
  "tests": [
    {"src": "[email protected]", "accept": ["tag:server:22"]},
    {"src": "[email protected]", "deny": ["tag:server:22"]},
  ],
}

ポリシーファイルはコメントと末尾カンマを許すHuJSON形式です。上の例は、Tailscaleが公開しているパーサー（github.com/tailscale/hujson）で構文を検証しました。メールアドレスは自分のtailnetのユーザーに置き換えてください。Tailscale SSHのルールも同じファイルに書くので、SSHの許可範囲はTailscale SSHの設定手順とチェックモード・録画の解説と合わせて決めます。

ユーザー承認とメールドメインの落とし穴

Tailscaleは、メールアドレスのドメインでユーザーをtailnetに振り分けます。[email protected] と [email protected] は同じtailnetに入れるということです。2025年5月の公報TS-2025-004は、共有のメールドメインを使う場合に、無関係な人同士が同じtailnetに入ってしまう問題を扱いました。Tailscaleはこれを受け、2025年5月22日以降に作られたtailnetではユーザー承認を既定で有効にしています。それより前に作ったtailnetは既定で無効なので、管理画面で有効になっているか確認してください。全プランで使えます。

ログインに使うIDプロバイダ（Google、Microsoft Entra IDなど）側の多要素認証も、Tailscaleのセキュリティのベストプラクティスが最初に挙げる対策の一つです。Tailscaleの認証はIDプロバイダに任せる構造なので、IDプロバイダのアカウントが破られればtailnetにも入られます。OIDC準拠のIDプロバイダによるSSOは、無料のPersonalを含む全プランで使えます。社内のID管理から設計し直す場合は、認証基盤・ID管理システム開発の観点でSSOと多要素認証の範囲を先に決めておくと、ACLのグループ設計が楽になります。

Exit NodeとSubnet Routerで信頼を預ける範囲

Exit Nodeは、インターネット向けの通信を指定した端末から出す機能です。Tailscaleの暗号化はExit Nodeの端末で終わり、そこから先は通常のインターネット通信になります。つまり、Exit Nodeを使っている間は、その端末と管理者を信頼することになります。他人が管理する端末を出口にしないことが基本です。

Subnet Routerは、Tailscaleを入れていない機器（NASやプリンター）をtailnetにつなぐ機能です。公式の既定ポリシーの説明によると、Linuxで --snat-subnet-routes=false を指定したSubnet Routerがあると、全許可のACLでは同じLAN上の機器からtailnetの全端末へ到達できるようになります。2024年5月の公報TS-2024-005も、1.66.0より前のLinuxのExit Node・Subnet Routerで、全許可のACLのときにLANから他の端末へ着信できた問題でした。公報の条件はACLの送信元が "src": "*" であることで、既定の全許可はこれに当たります。送信元をユーザーやグループに絞ること、1.66.0以降へ更新することが対策です。

タグ付き端末と認証キーの期限管理

ノード鍵の期限は既定で180日で、期限が来ると再ログインが必要です。ところが鍵期限のドキュメントによると、タグを付けて認証したサーバーなどの端末は、既定で鍵の期限が無効になります。退職者の端末やもう使っていないサーバーが、つながる状態のまま残りやすいということです。

サーバーを自動で参加させる認証キー（auth key）も同じで、ベストプラクティスは使っていないOAuthクライアント、APIキー、認証キーの削除を求めています。2025年11月のTS-2025-007では、1回限りの認証キーを同時に送ると複数の端末を登録できてしまう競合状態が見つかり、制御サーバー側で修正されました。キーを配る運用では、使い終わったら失効させ、管理画面の端末一覧を定期的に見直してください。

端末の状態で接続を絞るデバイスポスチャ（CrowdStrike連携）

端末がウイルス対策ソフトで守られているかなど、端末の状態を接続の条件にする機能がデバイスポスチャです。CrowdStrike連携のドキュメントでは、CrowdStrike FalconのZero Trust Assessmentが端末ごとに出す0〜100の信頼スコアをTailscaleに取り込み、スコアが一定以上の端末だけを重要なサーバーに通す設定ができます。Tailscale側で端末のシリアル番号などを集めるDevice Identity Collectionを有効にし、Falcon側でHostsとZero Trustの読み取り権限を持つAPIクライアントを作る必要があります。提供はStandard・Premium・Enterpriseプランです。クライアントのバージョンやOS、ディスク暗号化の有無も条件にできるので、私物端末を接続させる場合に効きます。

Tailscaleの脆弱性：2025〜2026年のセキュリティ公報

TailscaleはSecurity Bulletinsで脆弱性を公開しています。2025年は8件、2026年は8月18日までに11件（TS-2026-001〜011）が出ました。主なものを並べます。

中身を見ると、WireGuardの暗号化そのものが破られた事例はありません。目立つのは、Tailscale SSH、Serve、Web管理画面といった「便利な追加機能」の入口です。TS-2026-009では、Linuxで -i というユーザー名で接続すると getent がオプションとして解釈し、ACLが禁じているはずのrootセッションが開けました。TS-2026-011は、クラウド上のサブネットルーター経由でメタデータサービスに届き、インスタンスの認証情報を取られるおそれがあった問題です（報告者はAnthropicのインフラセキュリティチーム）。

ここから言える判断は二つです。一つは、使わない機能を有効にしないこと。tailscale set --webclient のWeb管理画面やTailscale SSHは、必要な端末にだけ入れます。もう一つは更新を止めないことです。2026年10月12日時点の安定版は1.104.1で、tailscale set --auto-update で自動更新を有効にできます。サーバーで自動更新を使えないときは、公報のRSSを購読して修正版の番号と手元のバージョン（tailscale version）を照らし合わせてください。

TailscaleとVPN・WireGuardの違い

従来型VPNとの違い：集中ゲートウェイの有無

従来型のリモートアクセスVPNは、インターネットに公開した社内のVPN装置に全員が接続します。装置の脆弱性が狙われやすく、一度入られると社内全体へ広がりやすい構造です。Tailscaleは端末同士を直接つなぎ、受け付けのポートを公開しません。接続ごとにACLで許可を判断するので、ゼロトラストの考え方に近い構成をとれます。VPNの方式全体の比較はVPNとは？仕組み・種類・メリットとデメリット、外部公開をトンネルで行う方式はCloudflare Tunnelの仕組みと設定が参考になります。

なお、Tailscaleは匿名化のためのVPNではありません。Exit Nodeを使っても、接続先に見えるのは出口にした自分の端末のIPアドレスです。接続先に見せるIPアドレスを変えたいだけなら、Mullvadのアドオン（5台ごとに月5ドル）でMullvadのサーバーを出口にできますが、利用者の識別そのものを防ぐ匿名化とは別物です。

WireGuard単体との違い：鍵の配布と経路管理の担い手

暗号化の部分はWireGuardそのものなので、強度は同じです。違うのは運用で、WireGuard単体では鍵の作成と配布、相手のIPアドレスとポートの設定、NAT越えを自分で用意します。Tailscaleはそれを制御サーバーとDERPが肩代わりし、IDプロバイダでのログインとACLに置き換えます。その代わりに、前述の「制御サーバーを信頼する」という前提が加わります。自前で全部持ちたいならWireGuard単体かheadscale、運用の手間を減らしたいならTailscale、という分け方になります。

Tailscaleの料金プラン：無料で使える範囲と商用利用

公式の料金ページ（2026年10月12日確認）のプランと、安全性に関わる機能の提供範囲です。

パソコンやスマートフォンなどユーザー所有の端末は台数無制限です（Enterpriseは個別契約で上限を決める）。Exit Nodeなどのタグ付きリソースはPersonalで50個から始まり、追加は1個につき月1ドルです。設定変更の監査ログ（直近90日）とデバイス承認、ユーザー承認、ACLの tests は全プランで使えます。接続そのものの記録を管理画面で残すネットワークフローログはPremium以上です。

商用利用については、料金ページがPersonalを「非商用利用にのみ適した無料プラン」と説明しています。業務で使うならStandard以上を選んでください。逆に、Tailnet Lockを業務で使いたい場合は、StandardとPremiumでは使えないのでEnterpriseの契約が必要になる点に注意が要ります。価格は改定されることがあるので、契約前に公式ページで確認してください。

無料プランを続けられる理由

「無料なのはデータを売っているからでは」という疑問には、共同創業者のAvery Pennarunが2022年3月16日の公式ブログ「How Tailscale’s free plan stays free」で答えています。要点は、通信のほとんどが端末同士で直接流れ、DERPの中継は予備にとどまるので中継網の費用を抑えられること、制御サーバーが軽いこと。個人に無料で使ってもらい、職場に持ち込まれたときに、企業向けの管理機能へ料金を払ってもらう事業モデルだということです。記事は「無料ユーザーは商品なのか」という問いに「No」と書いています。

Tailscaleの使い方：安全に始める導入手順

導入は3ステップです。最初から上の見直しを組み込むと、後で権限を絞る手間が減ります。

1. 公式サイトでアカウントを作り、Google・Microsoft・GitHubなどのIDプロバイダでログインする（IDプロバイダ側の多要素認証を有効にしておく）
2. 各端末にクライアントを入れてログインする。Linuxなら sudo tailscale up を実行し、表示されたURLで認証する。ほかの人は管理画面から招待し、各自のアカウントで同じtailnetに参加してもらう（アカウントを共有するとユーザー単位のACLが効かない）
3. 管理画面のAccess controlsでACLを最小権限に書き換え、ユーザー承認とデバイス承認（またはTailnet Lock）を有効にする

参加後は tailscale status で、tailnet内の端末と、直接接続かDERP経由かを確認できます。外出先の通信を自宅から出したいときは、出口にする端末で tailscale set --advertise-exit-node を実行し（LinuxではIP転送を先に有効にする。手順はExit Nodeの公式ドキュメントにOS別にある）、管理画面で承認してから、使う側で tailscale set --exit-node=<端末名> を指定します。受け付けをしない端末では tailscale set --shields-up で着信を止められます。社外からのリモートアクセス全体の設計は、テレワーク導入企業が直面するセキュリティリスクもあわせて確認してください。AIエージェントの通信をTailscale上で管理する新しい製品についてはTailscale Apertureの仕組みとエージェント権限・監査で扱っています。

Tailscaleの安全性に関するよくある質問

Tailscaleの問題点は何ですか？

暗号化ではなく、既定値と追加機能にあります。新しいtailnetのACLは全許可で、タグ付き端末は鍵の期限が切れません。2026年は8月までに公報が11件出ており、Tailscale SSHやServeなどの機能に集中しています。ACLを最小権限にして自動更新を有効にすれば、主なリスクは抑えられます。

Tailscaleはどこの国の会社ですか？

開発元のTailscale Inc.はカナダの会社です。2024年9月3日以降に作った新規アカウントの契約相手は、米国法人のTailscale US Inc.になります。プライバシーポリシーは、法執行機関からの開示請求をカナダと米国の法律に沿って扱うと定めています。

Tailscaleはなぜ無料で使えるのですか？

通信の大半が端末同士の直接接続で、中継網の費用を抑えられる設計だからです。そのうえで、個人が職場に持ち込んだ後に企業向けの管理機能で収益を得る事業モデルをとっています。公式ブログは、無料ユーザーのデータを売る「商品」ではないと説明しています。

Tailscaleは無料で商用利用できますか？

できません。無料のPersonalプランは非商用利用向けで、6ユーザーまでです。業務で使う場合は1ユーザー月8ドルのStandard、ネットワークフローログが要るなら月18ドルのPremiumが対象です。

Tailscaleは通信の中身をTailscale社に見られますか？

見られません。秘密鍵は端末から出ず、中継のDERPサーバーも通信を復号できません。ただし接続の開始・終了などのログはlog.tailscale.comへ送られます。止めたい場合は --no-logs-no-support を使いますが、技術サポートは受けられなくなります。

関連記事

• WireGuardとは？仕組み・設定方法・OpenVPNとの違いを実践解説
• Tailscale SSHの設定手順：鍵配布なしで使うポリシー・チェックモード・録画と採用判断
• headscaleの使い方：Tailscale互換サーバーの構築手順と0.29系の変更点・採用判断
• Cloudflare Tunnelとは？無料で使える範囲・仕組み・安全性とcloudflaredの設定手順
• VPNとは？仕組み・種類・メリットとデメリット、企業導入の判断基準を解説