一言でいえば：通常のVPNはデバイスのトラフィック100%を暗号化されたトンネル経由でルーティングします。スプリットトンネリングは意図的にこのルールを破ります。どのアプリまたはどの宛先がトンネルをバイパスして通常の接続から直接送出するかを自分で選びます。概念はシンプルですが、実際の実装はOSによって大きく異なり、プライバシー上のトレードオフも見落としがちです。トンネル外にルーティングされたストリーミングアプリには実際のIPアドレスが見えます。トンネル外にルーティングされた銀行アプリはホームネットワーク越しに銀行と通信します。それ自体は問題ありませんが、同じアプリがバイパスを通じてDNSクエリを送信し、意図せず別のドメインを露出させてしまう可能性があります。
VPNトンネリングが実際に行うこと（基本）
何が「分割」されるかを理解するには、まずフルトンネルが何をするかを明確にする必要があります。デバイス上で動作するVPNクライアントは仮想ネットワークインターフェイスを作成します。Linuxでは通常 tun0 や wg0、macOSでは utun と呼ばれ、iOSやAndroidではOSがアプリごとの拡張APIを通じて管理します。その後、OSのルーティングテーブルが変更され、デフォルトルート（「他に一致するルートがないパケットはこのゲートウェイへ送る」というルール）が物理的なWi-Fiやモバイル通信インターフェイスの代わりにこの仮想インターフェイスを向くようになります。
それ以降、デバイスが生成するすべてのパケットはVPNクライアントによって暗号化され、VPNサーバーを宛先とする新しいIPヘッダーでラップされ、単一の均質なストリームとして物理インターフェイスから送出されます。VPNサーバーはパケットを復号してパブリックインターネット上の実際の宛先に転送し、応答を受け取って再び暗号化して送り返します。ISPには単一のIPアドレスへの暗号化されたストリームしか見えません。宛先サイトにはあなたのIPではなくVPNサーバーのIPが見えます。
これがデフォルトの動作です。スプリットトンネリングは、「この宛先へのトラフィック」または「このアプリが生成したトラフィックについては、デフォルトのトンネルルートを無視して物理インターフェイスを直接使用する」というより具体的なルートをルーティングテーブルに追加することで、このモデルに介入します。
スプリットトンネリングが変えること
概念的には、スプリットトンネリングはネットワークフローに分岐を生じさせます。一部のパケットは暗号化されたトンネルを通り、残りは直接インターフェイスから送出されます。判断はVPNクライアントが設定したルールに従って行われます。スプリットルールには主に3つのカテゴリがあります：
- アプリベース — 「Netflixのトラフィックはすべてトンネル外へ送り、それ以外はトンネル経由にする。」発信元プロセスのUIDまたはPIDでパケットにタグを付け、タグごとにルーティングを決定することで実装されます。
- 宛先ベース — 「
10.0.0.0/8へのトラフィックはトンネル外へ送り、自宅のNASにアクセスできるようにする。それ以外はトンネル経由にする。」ルーティングテーブルのエントリのみで実装される最もシンプルな形式です。 - URLまたはドメインベース — 「
*.bank.comへのトラフィックはトンネル外へ送る。」OSのルーティング層はネイティブにドメインを認識しないため、これは不安定です。VPNクライアントがDNSをインターセプトしてレスポンスを書き換えるか、DNSの解決結果を追跡する動的なIPアローリストを維持する必要があります。ベンダーによる実装にはばらつきがあります。
アーキテクチャの概略図を簡略化して示します：
フルトンネル（スプリットなし）:
[アプリA] -> [アプリB] -> [アプリC]
\ | /
[仮想VPNインターフェイス]
|
[暗号化されたトンネル]
|
[VPNサーバー] -> インターネット
スプリットトンネル（アプリベース、アプリCを除外）:
[アプリA] -> [アプリB] [アプリC]
\ / \
[仮想VPNインターフェイス] [物理Wi-Fi]
| |
[暗号化されたトンネル] [通常のインターネット]
| |
[VPNサーバー] 直接宛先へ
「スプリット」はOS内部の分岐点です。仮想インターフェイスと物理インターフェイスのどちらを使うかは暗号化の前に決定されるため、トンネルをバイパスしたパケットは最初から暗号化されていません。復号ステップはなく、パケットはそのままデバイスから送出されます。
逆スプリットトンネリング — アローリストとブロックリスト
スプリットトンネリングの設定には、対称に見えてもデフォルト時の失敗動作が大きく異なる2つのフレーバーがあります：
- ブロックリストモード（一般的なデフォルト） — 「このリストのアプリ/宛先以外はすべてトンネル経由にする。」デフォルトは保護されており、特定の例外のみがリークします。アプリをリストに追加し忘れても、そのアプリは保護されたままです。
- アローリストモード（逆スプリットトンネリングとも呼ばれる） — 「このリストのアプリ/宛先のみトンネル経由にし、それ以外は直接接続にする。」デフォルトは保護されておらず、特定のアプリのみがトンネルを通ります。アプリをリストに追加し忘れると、そのアプリはリークします。
アローリストモードは「ブラウザだけVPNを使いたい、他は通常の接続でよい」という場合に適しています。ブロックリストモードは「ほとんどのものを保護したいが、一部の特定アプリは実際のネットワークが必要」という場合に適しています。一般ユーザーはブロックリストモードが適切です。OperationsチームやDevOpsチームは、システム全体を妨げずに特定のサービスをトンネル経由で公開しようとしているため、アローリストモードを好むことがあります。
アローリストモードの失敗は深刻です。新しいアプリを追加してアローリストへの追加を忘れると、そのアプリのトラフィックがリークします。ブロックリストモードの失敗はより軽微です。追加し忘れたアプリは保護されたままで、ストリーミングや銀行アプリがVPN IPを検出して動作しないという互換性の問題が生じるだけです。
スプリットトンネリングを使うべき場面 — 具体的な5つのシナリオ
スプリットトンネリングには正当な用途があります。以下の状況では適切なツールといえます：
1. VPNエンドポイントを検出してブロックするストリーミングサービス
Netflix、Disney+、Hulu、そしてほとんどの地域放送局は既知のVPNデータセンターIPの大規模なアローリストを保有しており、検出するとストリーミングを拒否します。VPNをオフにする（すべての保護を失う）か、ストリーミングアプリをスプリットトンネルに設定して実際のIPを見せつつ、それ以外はすべて保護されたままにするかを選べます。
2. 位置情報ベースの不正検出を持つ銀行・金融アプリ
銀行はVPNデータセンターへの突然のIP変更を不正シグナルとして扱うことが多く、追加認証を要求したり、取引を保留したり、一時的にアカウントをロックしたりします。銀行アプリをトンネルから分離することで、銀行との実際のIP関係を一貫して保てます。これはセキュリティの向上ではなく使いやすさの改善です。銀行の通信はすでにTLS暗号化されているため、VPNはそのセッションに大きなセキュリティを付加していません。
3. ローカルネットワークリソース（NAS、プリンター、スマートホーム）
VPNがすべてのトラフィックをキャプチャすると、192.168.1.50 のプリンターにはVPNトンネル越しではアクセスできないため、デバイスから届かなくなります。宛先ベースのスプリットトンネリング（192.168.0.0/16 と 10.0.0.0/8 を除外）により、パブリックインターネット向けのVPNを無効にせずにローカルアクセスを復元できます。多くのVPNクライアントはデフォルトでこれを自動的に行いますが、そうでないものもあります。
4. レイテンシーに敏感なアプリケーション
競技性の高いオンラインゲーム、ライブビデオ会議、音声通話は、遠い地域のVPNサーバー経由でルーティングされることで余分なレイテンシーが生じると品質が低下します。特定のアプリをスプリットアウトすることでレイテンシーを回復しつつ、他のすべては暗号化されたままにできます。ただし、それらのアプリはISPから識別可能になり、ネットワーク監視者に見えるようになります。
5. 個人VPNと並行して使う業務用VPN
会社が社内リソースへのアクセスにコーポレートVPNを要求しており、個人のトラフィックは別の（プライバシー重視の）VPN経由にしたい場合、コーポレートVPN上でスプリットトンネリングを設定し、会社のIPレンジのみをそちら経由にすることで、残りのトラフィックを個人VPNで使えます。パワーユーザー向けの設定ですが、業務と個人のトラフィックを明確に分離できます。
スプリットトンネリングを使うべきでない場面 — プライバシーの落とし穴
スプリットトンネリングはネットワークの動作を複雑にし、複雑なネットワーク動作は予想外の方法でリークします。最もよくある失敗パターン：
バイパス経路からのDNSリーク
アプリのTCPトラフィックがトンネル外にルーティングされていても、そのDNSクエリはVPNのDNSリゾルバを使うよう設定されている場合があります。あるいは逆に、VPNクライアントがシステムDNSを適切に管理していない場合にISPのDNSリゾルバにフォールバックする可能性もあります。結果として、ISPから見えないはずのアプリが部分的に見えてしまいます。ISPには後続のTCP接続が別の経路を通ったとしても、banking.example.com へのDNSクエリが見えてしまいます。DNS暗号化の詳細については、DNS-over-HTTPSガイドで詳しく解説しています。
アプリとドメインの混同
アプリベースのスプリットトンネリングはプロセスのIDでルーティングしますが、現代のアプリは多くのドメインに接続します。「ストリーミングアプリ」は広告、テレメトリー、レコメンデーションAPI、アナリティクスのエンドポイントを数十の異なるドメインから読み込んでいる可能性があり、その中にはトンネル経由にしたいアプリと共有されているものもあります。アプリ全体を除外するとそれらの接続もすべて除外されます。ドメインベースのスプリットトンネリングには逆の問題があります。1つのアプリが、ストリーミング動画（保護不要）と開示したくないコンテンツの両方に同じCDNドメインを使用している可能性があります。
IPv6リーク
多くのスプリットトンネル実装は、IPv4が唯一のルーティング上の関心事だった頃に設計されました。ネットワークにIPv6接続があり、スプリットトンネルルールがIPv6ルートを明示的に含んでいない場合、トンネル経由にすべきパケットがトンネル外のIPv6経由で送出される可能性があります。これは2026年において最も一般的なVPNリークの1つであり、ほぼ常に不完全なスプリットトンネルルールの設定に起因します。スプリットトンネリングを有効にした後は、IPv6リークテストで確認してください。
キルスイッチとの相互作用
キルスイッチはVPNが切断された場合にすべてのトラフィックをブロックして、何も保護されていない状態でリークしないよう設計されています。スプリットトンネリングが有効の場合、キルスイッチのロジックはより複雑になります。キルスイッチはスプリットトンネルされたアプリの通信は引き続き許可しつつ、それ以外はVPN自体がダウンしている間もブロックする必要があります。多くのVPNクライアントには、VPNが切断されたときにキルスイッチがトンネル経由のアプリをブロックしないか、逆に引き続き動作すべきスプリットトンネルのアプリを誤ってブロックするバグがあります。組み合わせの動作を明示的にテストしてください。
スプリットトンネリングモードの比較
| モード | 暗号化されるもの | リークするもの | 最適な用途 |
|---|---|---|---|
| フルトンネル（スプリットなし） | すべてのトラフィック、すべてのアプリ、すべての宛先 | アプリ側からは何もリークしない。ただしVPNを使用していることはISPに見える | 敵対的なネットワーク、旅行中、ISPを脅威モデルに含めているすべてのユーザー |
| アプリベース ブロックリスト | 明示的に除外されたアプリ以外のすべて | 除外されたアプリには実際のIPが見える。DNSが実装によってリークする場合としない場合がある | VPNを検出するストリーミング、銀行、地域制限のあるアプリ |
| アプリベース アローリスト（逆） | リスト上のアプリのみ | その他すべて — OSのバックグラウンドサービス、アップデート、テレメトリーを含む | 「ブラウザだけトンネルする」などの特定用途、開発者向けセットアップ |
| 宛先ベース（LAN除外） | パブリックインターネット向けのすべて | ローカルネットワークトラフィック（プリンター、NAS、スマートホーム） | ほぼ常に望ましい。多くのクライアントがデフォルトで有効にしている |
| ドメインベース（URLルール） | DNSインターセプションロジックによる | 不定。共有CDNと動的DNSによりこの方法は不安定 | 特定のアローリスト済みサイト。一般ユーザーにとって複雑さに見合うことはほぼない |
各オペレーティングシステムでのスプリットトンネリングの仕組み
iOS — 限定的で間接的
iOSはサードパーティVPNアプリに真のスプリットトンネリングAPIを公開していません。NetworkExtensionフレームワークでは、VPNをシステム全体（すべてのトラフィック）またはアプリごと（MDMプロファイルで明示的に登録されたアプリのみ）として設定できます。真のアプリごとスプリットルーティングにはAppleの NEAppProxyProvider とMDM配布の設定プロファイルが必要で、管理デバイスのシナリオを意味します。「スプリットトンネリング」を謳っているiOS向けのコンシューマーVPNアプリは、通常、宛先ベースの除外（特定のIPレンジをトンネルから除外するなど）を実装するか、Wi-Fi SSIDやドメインマッチに基づいてVPNを条件付きで有効化するオンデマンドルールAPIを使用しています。コンシューマーiOSユーザー向けのアプリベーススプリットトンネリングは実質的に利用できません。
Android — ファーストクラスのサポート
AndroidのVpnService APIはアプリごとのルーティングをネイティブでサポートしています。VPNクライアントは addAllowedApplication() または addDisallowedApplication() を呼び出すことで、どのアプリがトンネルを通るかを指定できます。OSがアプリごとのルーティングを透過的に処理するため、VPNクライアントはパケットレベルのタグ付けを行う必要がありません。Androidはまた「常時接続VPN」システム設定に「VPNなしの接続をブロック」オプションもサポートしており、キルスイッチの動作とアプリごとの設定を組み合わせます。トンネル経由のアプリはトンネルを通り、非トンネルのアプリは直接接続し、VPNが切断されるとトンネル経由のアプリはブロックされます。
macOS — 実装はさまざま
macOSはいくつかのメカニズムでスプリットトンネリングをサポートしています。NetworkExtensionフレームワーク（iOSと同様ですが柔軟性が高い）、pf ルールで設定されたパケットフィルター、または上位権限で動作するVPNクライアントによるルーティングテーブルの操作です。macOS上でのアプリベーススプリットトンネリングは実現可能ですが、VPNクライアントがカーネルにソケットとプロセスのマッピングを問い合わせる必要があります。宛先ベースのスプリットは簡単で信頼性が高いです。
Windows — スプリットトンネリングで最も一般的なプラットフォーム
Windows VPNクライアントは10年以上にわたってスプリットトンネリングを使用してきました。Windows Filtering Platform（WFP）は、VPNクライアントがフックするカーネルレベルのパケット検査とルーティング決定APIを提供します。Windowsでのアプリごとスプリットトンネリングは十分にサポートされており、広く展開されています。ほとんどの企業向けVPNデプロイメントでは、パフォーマンスと企業VPNコンセントレーターの負荷軽減の両方のために、Windowsのスプリットトンネリングを使用して会社のトラフィックは会社のトンネル経由に、一般のインターネットトラフィックは直接送出するよう設定しています。
スプリットトンネリング設定時のよくある間違い
実際のスプリットトンネリングの誤設定パターンを観察すると、いくつかの繰り返すパターンが見えてきます。設定する際はこのリストと照らし合わせてください：
- 有効にした後にDNSリークのテストをしない。設定変更のたびにリークテスト（dnsleaktest.com など）を実行してください。トンネル経由にすべきアプリについてISPのDNSリゾルバがリストされていたら、バイパスでDNSがリークしています。
- ブラウザが特別な存在であることを忘れる。ストリーミングウェブアプリを実行しているブラウザは、ストリーミング動画も他のタブも同じプロセス経由でルーティングします。ブラウザを除外するとブラウジング全体が除外されます。ストリーミングには別のブラウザプロファイルや別のアプリを使用してください。
- IPv6を処理しない。VPNクライアントが明示的にIPv6を処理しない場合は、IPv6を完全に無効にしてください。忘れられたIPv6スプリットトンネルルールからのリーク率は高いです。
- セキュリティに重要な判断にドメインベースのルールを使う。ドメインベースのスプリットトンネリングは使いやすさの調整には問題ありません。「この機密性の高いアプリは常にVPN経由でなければならない」を強制するには信頼性が不十分です。そのためには、アプリを明示的にトンネルに設定したアプリベースのルール（理想的にはアローリストモード）を使用してください。
- ルールを定期的に見直さない。アプリは追加・削除されます。同じパブリッシャーの新しいアプリは古いものの設定を何も引き継ぎません。定期的にスプリットトンネルのルールセットを監査してください。
スプリットトンネリングについての率直な評価
スプリットトンネリングは特定の問題に対して本当に役立ちます。VPNを検出するストリーミングアプリ、VPNログインにフラグを立てる銀行アプリ、ローカルネットワークアクセス。また、企業環境における正当なデプロイの長い歴史もあります。一般ユーザーへの率直な説明としては、これは第一にユーザビリティのツールであり、プライバシーのツールは第二です。スプリットトンネルのルールはすべて何らかの方法で保護モデルを弱め、セキュリティのトレードオフが価値があるのは、そのトラフィックに保護がそもそも役立たない場合だけです（例：すでにTLS暗号化されていて単一の既知の宛先に向かう銀行セッション）。
脅威モデルが「敵対的なパブリックWi-Fiネットワーク上でローカルネットワーク事業者がトラフィックを観察できないようにVPNを使いたい」というものなら、フルトンネルが正解です。VPNクライアントが提供しているからといってスプリットトンネリングを有効にしないでください。すべての除外は穴です。脅威モデルが「ほとんどのトラフィックを保護したいが、特定のアプリは実際のネットワークが必要」というものなら、スプリットトンネリングは適切なツールです。ただし慎重に設定し、その後DNSとIPv6のリークをテストし、定期的にルールを見直してください。WireGuardクイックスタートドキュメントの技術リファレンスには、基盤となるルーティング判断がプロトコル層でどのように機能するかが示されています。
Casper's Cloakは、私たちが保護の対象としている脅威モデル（敵対的なネットワーク、ISP監視、アドテクトラッキング）がシンプルな「すべてをトンネルする」モデルで恩恵を受けるため、デフォルトでフルトンネルアーキテクチャを採用しています。さらにDNS層でのトラッカーフィルタリングと既知の悪意ある宛先へのAI脅威検出を組み合わせているため、フルトンネルは単なるルーティングだけでなく積極的なフィルタリングも行います。ストリーミングや銀行のエッジケースについては、忘れてしまうような永続的なスプリットトンネルの除外を維持するより、一時的に切断する方が通常は正しい選択です。