メッシュVPNで開発者体験を改善する ― Tailscale導入までのPoCと製品選定

VPN セキュリティ インフラ オフショア

こんにちは。テクニカルアーキテクチャ・インフラ担当の原田です。

今回は、社内の開発メンバー向けにメッシュVPNの導入を支援し、安全なアプリ開発、テスト効率の改善、工数削減につなげた取り組みをご紹介します。

背景

現在、社内では基幹システムの刷新プロジェクトが進行しています。
このプロジェクトでは「開発チームの体制」と「システムアーキテクチャ」に起因する、ローカル開発環境特有の大きな課題を抱えていました。

  • 多国籍・マルチ拠点でのリモート開発
    • 日本国内だけでなく、海外のオフショア開発チームを含めたグローバルなリモート環境で開発が進められている
  • マイクロサービスアーキテクチャの採用
    • システムが多数のAPI（マイクロサービス）に細分化されており、それぞれが密接に依存し合っている

このような環境下で開発・テストを効率化するためには、各メンバーのローカルPC間でセキュアに相互通信（ピアツーピア通信）できるネットワーク環境が不可欠でした。
具体的には、以下のようなユースケースが発生していたためです。

  1. 「マージ前の開発途中API」同士のリアルタイム結合テスト
    「Aさんが手元のローカルPCで開発中の最新の認証API」と、「Bさんが開発中の決済API」のように、双方マージ前の段階で繋ぎ込んで動作確認をしたい場面が発生します。
    相手のコードを取り込んでDocker Composeで毎回手元に再現（ビルド）するのは効率が悪く、ホットリロードの恩恵を受けながらリアルタイムにデバッグを行うには、お互いのローカルAPI同士を直接P2Pで叩き合える環境が必要でした。
  2. ローカルマシンのスペック制限
    依存するすべてのサービスを個人のローカルPC（Docker Compose）上で同時に立ち上げるのは、マシンスペックの観点から困難でした。
    他メンバーが手元で起動している最新の依存APIを直接呼び出すことで、ローカルマシンの負荷を節約する効果も見込めます。

「AWS環境（ステージング等）に都度デプロイして確認する」といった手法もありますが、こちらもマージやビルド、環境準備による工数・デプロイ待ち時間が発生してしまいます。

ソリューション

この課題に対し、P2P（ピアツーピア）通信を活用して解決できないかと考え、実現する手段としてメッシュ型VPNの導入を検討しました。

ℹ
P2P（ピアツーピア）とは？
端末同士が1対1で接続・通信する方式のことです

VPNという特性上インフラ領域ということもあり、今回の技術検証を私の方で主導して進めることとなりました。
本記事では検証や導入にあたって、個人的な所感や検証結果を中心にまとめさせていただきます。

期待される効果

メッシュ型VPNを導入すると、開発メンバー同士がローカルPC間で相互通信できるようになります。
その結果、開発中APIをテスト可能な状態にするまでの工程が短縮され、開発〜テスト〜改修〜再テストの反復効率が大幅に改善されることが期待されます。

特にマイクロサービスアーキテクチャでは、開発対象のAPI数が多くなるため、効果は大きいと考えられます。
定性的な効果として、セキュリティ向上や開発者のモチベーション向上も期待できます。

導入課題

メッシュ型VPNを導入するにあたり、主な懸念点は次のとおりです。

  1. 目的は実現できるか（端末間のP2P通信が目的）
  2. セキュリティは担保できるか（ガバナンスを効かせて安全に運用できるか）
  3. パフォーマンスに問題はないか（通信速度、応答性能が十分か）
  4. コストは妥当か（費用対効果を得られるか）

製品の検討

メッシュ型VPNの実現にあたり、比較対象とした製品は次の3つです。

  • Tailscale
  • NetBird
  • AWS Client VPN

TailscaleとNetBirdはSaaSとして提供されるサービスで、AWS Client VPNはAWS提供のマネージドVPNサービスです。
前者2つはWireGuardプロトコルをベースとしたメッシュ型VPNソリューションですが、後者はどちらかといえばAWSへの接続用途に特化したClient VPNといえます。

ℹ
WireGuardとは？
シンプルかつ高速なVPNプロトコルの1つで、P2P通信の実現に利用されます。
暗号化通信を比較的容易に構築できることが特徴で、TailscaleやNetBirdなどのメッシュ型VPNで採用されています。

厳密には各製品の立ち位置は異なりますが、比較検討のため候補に含めました。
実際のPoCは、TailscaleとNetBirdの2製品に絞って進めています。

PoCを実施した結果

候補3製品の比較結果は以下のとおりです。
今回の目的である「メッシュVPNを利用したP2P通信」は、AWS Client VPNを除き、基本要件（P2P通信、ACL/ポート制御）を高い水準で満たしていることが分かりました。

※価格・プラン仕様は2026年7月のPoC実施時点のものです。

評価点 NetBird Team Tailscale Standard AWS Client VPN
目的の実現性 ◯メッシュVPNを構築し、デバイス間同士のアクセス（ピアツーピア）が可能 ◯メッシュVPNを構築し、デバイス間同士のアクセス（ピアツーピア）が可能 △AWS VPC やオンプレミス環境へのリモートアクセス用途には適しているが、P2P用途には不向き
セキュリティ[ユーザー制御] ◯SSO統合(okta)が可能 ◯SSO統合(okta)が可能 ◯Active Directory、SAML、証明書認証に対応しており、既存IdPと連携したユーザー認証は可能
セキュリティ[デバイス制御] ◯okta側で認証済デバイスからの利用に制限が可能 ◯okta側で認証済デバイスからの利用に制限が可能 △証明書認証により端末制御は可能だが、デバイス単位の可視化・承認・失効管理はTailscale / NetBirdの方が扱いやすい。
セキュリティ[アクセス制御] ◯アクセスコントロールポリシーにより、グループ、ポートベースで制御が可能 ◎アクセスコントロールにより、グループ、ポートベースで制御ができ、HuJSON管理可能で再現性に優れる △ルート、認可ルール、Security Group により、VPCやCIDR単位のアクセス制御が可能。一方で、ユーザー・端末・タグ単位の細かな制御はメッシュVPN製品の方が適している。
ログ ◯監査ログの保持期間の定めあり ◯設定変更の監査ログは標準で90日間保存 △接続ログや接続状況の確認が可能で、監査用途には利用できる。ただし、端末間通信やピア単位の可視化という観点では、メッシュVPN製品とは粒度が異なる。
性能 ◯通信速度、応答速度は実用上の問題なし ◯通信速度、応答速度は実用上の問題なし △AWSリソースへのアクセスでは安定性が期待できるが、通信はClient VPN Endpoint経由となるため、P2Pによる直接通信の効率性は期待できない。
運用のしやすさ、使いやすさ ◯GUIで直感的に管理が可能。Peerの情報がダッシュボードから確認可能 ◎GUIで直感的に管理が可能。設定値をHuJSONポリシーで管理可能。製品シェアが高く、ナレッジが豊富でサポート支援が手厚い ×マネージドサービスのためVPNサーバー運用は不要。ただし、VPC、ルート、認可ルール、証明書などの設計が必要で、Tailscale / NetBirdより導入・運用は重い。
コスト ◎$6 / ユーザー /月 ◯$8 / ユーザー / 月 ×Endpoint稼働時間、接続時間、データ転送料、IPv4料金などの従量課金。コストが読みづらいため、前提条件を置いた試算が必要

AWS Client VPNでもクライアント間通信は実現できますが、Client VPN Endpointを経由する構成となり、端末間の直接通信を前提としたメッシュVPNとはアーキテクチャが異なります。
今回の「開発者端末同士を柔軟に接続する」というユースケースでは、Tailscale / NetBirdの方がより適しているなと感じました。

今回はTailscaleとNetBirdの2製品をターゲットに導入を検討することに決定しました。

開発メンバーに使用感を聞いてみた

実際の利用者である開発メンバーに、TailscaleとNetBirdの両方を試してもらい、定性評価をしてもらいました。

結果、どちらも期待どおりに動作し、パフォーマンス上の問題もないというフィードバックをもらいました。
一方で、セットアップの容易さ（導入のしやすさ）や、開発端末上のWebアプリケーションを容易にHTTPS化できる点から、Tailscaleのほうが使いやすいという声が寄せられました。

導入支援をしている私から見ても、両者とも機能面・パフォーマンス面で大きな差はありませんが、次の点はTailscaleの運用上の強みだと感じたポイントです。

  • アカウント管理においてSSO連携（当社ではOkta）が可能で、よりセキュアかつ迅速なユーザー改廃が可能
  • アクセスポリシー（通信制御）をHuJSON形式で管理・保存でき、環境の再現性に優れる

コストはどうなの？

契約プランにもよりますが、単純な価格比較ではNetBirdのほうがコストパフォーマンスは高いです。
しかし、以下の点を総合すると、多少単価が高くてもTailscaleのほうが使い勝手が良いという結論になりました。

  • ドキュメントや技術情報の充実度
  • サポート体制（国内代理店サポート含む）
  • 管理・運用機能の使いやすさ

そのため、当社ではTailscaleを採用することにしました。

主な機能面についての紹介

Access controls (Grants)

ネットワーク接続を許可するユーザーやデバイスを制御する基本機能です。 HuJSON形式で、デバイスやユーザーグループなどの条件を細かく定義して通信制御できます。 視認性が高く、設定しやすい点もメリットです（もちろんGUIで直感的に設定することも可能です）。

  • 設定例 開発・運用チーム内限定で80/443通信のみ許可する（SSH通信は不許可）
{
    "grants": [
        {
            "src": ["group:Developer Team"],
            "dst": ["group:Developer Team"],
            "ip":  ["tcp:80", "tcp:443"],
        },
        {
            "src": ["group:Ops Team"],
            "dst": ["group:Ops Team"],
            "ip":  ["tcp:80", "tcp:443"],
        },
    ],
    "ssh": [],
    "nodeAttrs": [],
}

操作感としては、AWSのIAMポリシーに近いイメージで扱えます。 HuJSON形式のため、Git管理やIaC化がしやすい点も魅力です。

MagicDNS

通常、ピア同士の接続ではIPアドレスを指定しますが、MagicDNSという機能を使うとTailscaleが自動で各ピアにドメインを割り当てます。 ドメイン名にはマシン名やTailnet名が反映されるため、分かりにくいIPアドレスを覚える必要がありません。 これも開発メンバーから要望の多かった機能の1つです。

100.x.x.x
↓
monitoring
monitoring.yak-bebop.ts.net

DNS / Split DNS

VPN接続した端末のDNSリゾルバー設定を、Tailscale側で一元管理することができます。 例えば、「社内ドメインへのアクセス時だけ社内DNSに振り分ける」といったルーティング制御ができるようになります。

設定例

  1. Global nameserver に公開DNSを設定 例: 1.1.1.1, 8.8.8.8
  2. Split DNS を追加 corp.local -> 192.0.2.53 dev.internal -> 192.0.2.53
  3. 必要に応じて Override local DNS を有効化 端末ローカル設定より、Tailnet側のDNSポリシーを優先させる

利用時の動作

  1. github.com を引く: 公開DNS（1.1.1.1 など）で解決される
  2. api.corp.local を引く: 自動的に 192.0.2.53（社内DNS）へ問い合わせる

この機能を利用することで

  • 社内向け名前解決ルールを、管理者側で一元管理できる
  • 環境差分（人によってDNS設定が違う問題）を減らせる
  • 社内ドメインの名前解決ルールを統制しやすくなる

などの効果が得られます。

利用時の注意点

  • Looopでは、ゼロトラストソリューションとしてZscalerを導入しています。 ZscalerでもDNS制御機能が有効となっており、Tailscale側の設定によっては競合する可能性があるため、既存DNSと共存する場合は検証が必要になります。
  • 既存のVPN・セキュリティ製品がDNS設定を制御している環境では、MagicDNSやSplit DNSの設定が競合する可能性があります。
    特に複数のVPNクライアントを併用する場合は、OSごとの名前解決の挙動を含めて事前検証が必要です。

HTTPS（SSL証明書）

ユーザー自身のデバイスにHTTPS証明書をプロビジョニングできる機能です。
通常、HTTPS通信にはSSL証明書の発行が必要で、ドメイン認証やメール認証などの手続きが発生します。

Tailnet側でHTTPSを有効化すると、MagicDNSで割り当てられた *.ts.net のドメインに対してLet's Encryptの証明書を取得できます。
証明書発行の手間を大きく削減できるため、開発者への負担を下げながらも、より安全で実環境に近い動作を得ることが期待できます。

tailscale cert machine-name.tailnet-name.ts.net

導入効果

本記事執筆時点では、Tailscaleを社内リリースしたばかりのため、開発メンバーからのフィードバックやトラブル報告はまだ多くありません。 一般的には動作確認のたびにAWS環境へのデプロイが必要でしたが、導入によって開発者のローカル環境へ直接接続して確認できるようになることで、工数やコストの削減が期待できます。

今後の展望

今回導入した「メッシュVPNを利用したP2P通信」のソリューションについて、当初想定していた用途に加え、副次的な効果も期待できることが分かりました。 その一つが現在閉域網で利用している既存のVPN機器を、Tailscaleへ置き換えられる可能性があるという点です。

昨今のセキュリティニュースでは、VPN製品の脆弱性を悪用した不正アクセスがたびたび報告されています。 これは、VPNソフトウェアやハードウェアの脆弱性が未対応のまま放置されることで、外部からの攻撃対象となり、不正アクセスや情報窃取につながるものです。

特に、古いバージョンのVPN製品を継続利用している場合や、VPNへ接続する端末がマルウェアに感染している場合には、侵入や内部ネットワークへの横展開のリスクが高まります。 こうしたリスクを抑えるため、従来型のVPN製品では定期的なアップデート、脆弱性対応、機器の監視、アクセス制御など、継続的なセキュリティ対策が必要とされてきました。

一方、TailscaleのようなメッシュVPN製品は、以下のような設計を採用しています。

  • 自社でインターネット公開VPNゲートウェイを運用する必要がない
  • 認証されたユーザーと端末間で、必要な通信のみを許可する
  • 通信を端末間でエンドツーエンド暗号化する

最小権限のアクセス制御と組み合わせることで、端末侵害時のアクセス範囲を限定し、ラテラルムーブメントのリスク低減が期待できます。 （もちろん導入するだけで安全になるわけではなく、適切な経路設定や端末管理ができることが前提になります）

このような背景から、現在自社設備に設置しているVPN機器についても、Tailscaleへの置き換えが可能かを検討し、セキュリティリスクと運用管理コストの双方を抑えた構成への移行を進めていきたいと考えています。

まとめ

今回の取り組みを通じて実感したのは、インフラの改善は「開発者体験」を変えるということでした。 メッシュVPNの導入によって待ち時間や手戻りが減り、開発チームの環境準備・デプロイ工数を大きく削減可能な見込みです。

最終的にTailscaleを選んだ理由は、機能やコストだけではありません。

  • 現場の開発者が迷わず利用できること
  • 管理者が安全かつ継続的に運用できること

この2点も、製品選定における重要な判断材料となりました。 今後はデプロイ回数や動作確認に要する時間などを計測し、導入効果の定量的な確認を進めつつ、インフラアーキテクトとして、安全性と開発者体験の両立を意識しながら、引き続き開発チームを支援していきたいと考えています！