Android で VPN はつながっているのに、「ブラウザだけ出口を変えたい」「決済アプリやローカル動画再生だけはキャリア直結にしたい」「仕事用チャットだけ会社規程どおり別経路にしたい」といったニーズはよくあります。検索語としては アプリ単位 VPN、英語では Per‑App VPN、仕様書では 分割トンネル（split tunneling） と呼ばれる領域にまとまります。本稿はスクショ依存を避けつつ、OS とクライアントの共通項として「リストをどちらの論理で組むか」を固定し、チェック・確認までを再現できる形で書きます。

マルチアプリ連携や長時間バックグラウンド処理では、VPN の瞬断や DNS の読み替えが別の症状として現れることがあります。関連して読むなら Android で Gemini のアプリ連携・自動ワークフローが途中で途切れる？VPN と DNS・接続設定の切り分け（2026） と Gemini Intelligence（Android）が重い・同期しない？VPN と DNS（2026） を参照すると、「分割リスト」とは別レイヤーの切り分けが立体的になります。

アプリ単位の経路設定で一番つまずくのは UI の名前より モデルの取り違え です。「チェックしたアプリだけ VPN に載せる」のか「まず全体 VPN で、そのうち例外だけ外す」のか──この二者はログの読み方も検証手順も変わります。

まず押さえる｜許可リスト型と全体トンネル＋除外型

実務で主流なのは次の二つの発想です。

製品によってトグル名は「分割トンネル」「アプリ別ルーティング」「Allowed apps」「Bypass」「対象アプリ」などばらばらですが、一覧画面でスイッチが「選択したものが VPN に入る」のか「選択したものが VPN から外れる」のかを確認できれば論理は確定します。混乱したら一度すべてオフにしてデフォルト挙動（全体 VPN か否か）から試してください。

設定を触る前に｜VPN 権限とプロファイルの状態

Android は最初の VPN 確立時に「VPN 接続の許可」を OS ダイアログで取ります。省電力まわりでクライアントが再起動すると、この許可状態やプロファイル選択が初期化されている機種もあるため、リスト編集の前に「いまどのプロファイルが有効か」を状態バーの鍵アイコンや設定アプリの VPN 一覧で確認します。

  1. 機内モードやデータセーバーが誤ってオンになっていないか。
  2. 別の VPN／広告ブロッカー／ファイアウォールアプリが同時に VPN スロットを奪っていないか（Android は基本的に単一の Always‑On 対象になりやすい）。
  3. Private DNS（プライベート DNS） をカスタムにしている場合、トンネル内 DNS と二重指定になっていないか。

モデル A の組み立て｜許可リストで「載せる側」を増やす

許可リストを選ぶときは、「VPN に載せたい通信がユーザー空間のアプリとして明示できるか」を最初に検証します。たとえばブラウザはアプリ単位で効きやすい一方、一部の OEM プリインやシステムサービスはリストに出ても実際のソケット経路が別コンテナ側にあることがあります。その場合は期待どおりに見えず、「VPN が壊れた」と誤認しがちです。

リスト作成の実務ヒント

モデル B の組み立て｜全体 VPN で「外す側」を限定する

セキュリティ方針として「基本はすべて暗号化しつつ、レイテンシが致命的なだけバイパス」というときは除外モデルが向きます。銀行・決済・地域限定のライブ配信など、キャリア認証やローカルマルチキャストが絡むカテゴリを除外にまとめるケースもあります。

運用上のコツは 除外理由をメモできる粒度 にリストを留めることです。半年後に「なぜこれが外れていたか」を説明できないと、セキュリティ監査や家族への引き継ぎで詰みやすくなります。法人端末では MDM がリスト編集自体を禁止していることもあるため、その場合は記事どおりに進めずドキュメントを優先してください。

Always‑On VPN と「VPN が落ちたら通信しない」の読み替え

設定アプリ側には「VPN を常時維持」「VPN が無効ならインターネットをブロック」といった項目があります。これらは漏えい耐性を上げる一方で、アプリ単位リストと組み合わせたときの期待値がずれやすいです。

省電力・バックグラウンド制限との競合

リストは完璧でも、VPN デーモンがバックグラウンドで停止すれば結果は「すべて直結」または「すべてオフライン」に振れます。「設定 → アプリ → 対象 VPN → 電池／バックグラウンドデータ」を確認し、過度な「制限あり」設定を避けます。一部 OEM は独自の自動起動管理があり、クラッシュリカバリ後にリストが既定値へ戻ることも報告されています。そのときは再起動後にリストを再確認するだけで済む場合もありますが、頻発するならクライアント更新またはサポートログが必要です。

検証ステップ｜アプリ単位の結果をどう確認するか

「このアプリは VPN を通った」と断言するのは実は難しく、単純な公開 IP 確認アプリでもプロセス単位ではなくシステムデフォルト経路だけを見ていることがあります。実務では次の順が安定です。

  1. 変更前後で同一サイトへ HTTPS アクセスし、応答ヘッダや GEO API が変わるかを見る（過信せず複数ソース）。
  2. 問題のアプリだけ許可／除外を切り替えて比較する（ほかの設定は固定）。
  3. Wi‑Fi とモバイルデータで別々に試す。キャリア NAT と住宅 ISP で見え方が変わります。
  4. それでも腑に落ちないときは DNS の上流がトンネル外を見ている線を疑い、Private DNS を一時オフまたは別プリセットで切り替えて再試行します。

利用場面とコンプライアンス

VPN は通信経路を変更するツールであり、公共 Wi‑Fi 対策や合法的なリモートアクセスなど用途はさまざまです。一方で利用規約や法令・プラットフォームポリシーに抵触する目的での利用は、アカウント停止や法的リスクにつながり得ます。アプリ単位の設定で経路を細かく切り替えるほど、その前提を自分で説明できる状態を維持してください。

OEM・Android バージョンによる UI のブレへどう向き合うか

メーカーごとのカスタム ROM では、「VPN とプライベート DNS」「データセーバー」「デュアル SIM の既定データ SIM」などが追加タブとして挟まり、純粋な AOSP の説明記事と画面順序が一致しないことがあります。リスト編集画面が見つからないときは、(1) VPN アプリ本体、(2) システム設定の VPN、(3) ネットワーク詳細設定──の三段を順に開くと見つかるケースが多いです。

また IPv6 が有効な回線では、IPv4 だけ分割対象に見えていて IPv6 が別経路を這うと、「一部サイトだけ挙動がおかしい」という印象になります。試験時はモバイルデータ／Wi‑Fi を切り替えつつ、同一ホストへの到達経路が安定しているかを複数回確認するとブレが減ります。

よくある勘違いと切り分け

公式クライアントに寄せる理由（再現性）

アプリ単位のルーティングは、OSS 設定ファイルや複数レイヤのプロキシを重ねる構成ほど、「今どのソケットがどのテーブルを見たか」がブラックボックス化しやすくなります。トラブル時にログを読めない環境では、結局リストを総入れ替えする羽目になりがちです。仕事でも個人でも、まずひとつの公式アプリに集約し、許可リストか除外リストかというユーザ空間の論理だけをいじくるほうが長期的には時間を取り戻せます。

ClashVPN は Android を含む主要 OS でネイティブクライアントを提供し、ノード選択や接続状態をアプリから把握しやすい UI にまとめています。新規登録後すぐに無料で利用できる通信量が付与され、すべてのノードを追加費なしで試せます。クレジットカードの登録や自動更新による課金は設計されていません。分割リストで運用したあとは、ページ末尾のダウンロードから公式ビルドを入れ直し、許可／除外の論理が期待どおりかを本章の検証順で一度だけ確認すると安心です。