※本記事にはアフィリエイト広告（PR）が含まれます。
MillenVPNの接続品質をコマンドプロンプトで検証する最短ルートは、「①ipconfig /all で仮想アダプタとDNSを確認」→「②ping -n 50 で実測遅延・ジッター・パケロスを測定」→「③tracert と route print で経路とトンネル経由を把握」→「④pathping で各ホップのロス率を集計」→「⑤netsh でMTUを確認」の5ステップです。この順番で実行すれば、VPNが「繋がっているのに遅い」のか「特定経路で詰まっている」のか「MTU不一致でフラグメント化している」のかを、推測ではなく数値で切り分けられます。
この記事のポイント（2026年6月時点）
- 公式アプリのPing表示は全体の1要素しか映さない——体感速度を決める5要素のうち「自宅→VPNゲートウェイ」のRTTだけしか見えていない
- 5つの標準コマンドだけで品質を数値化できる——ipconfig・ping・tracert（+route print）・pathping・netshは無料・標準搭載・ログ保存可能
- ジッター＝最大RTT−最小RTTで近似でき、用途別の合否（VoIP 30ms以下／FPS 20ms以下／ストリーミング 50ms以下）が一目で判定できる
- DNSリークは nslookup、意図しないスプリットトンネルは route print で確定できる
- 正常系/異常系の出力例を掲載——自分の結果と見比べるだけで「これは正常か異常か」が判断できる
筆者は2026年6月時点でMillenVPNを2年4ヶ月運用しており、東京・大阪・シンガポール・ロサンゼルスの4拠点を業務で日常的に使い分けています。これまで公式アプリの「接続済み」表示だけを信じて、実際には経路の3ホップ目で200msのジッターが発生していたケースを何度も観測してきました。本記事では市販の計測ツールを一切使わず、Windows標準コマンドだけでMillenVPNの接続実態を解剖する手順を、実測ログ付きで共有します。
なお、サーバー選びや初期設定から見直したい方は、MillenVPNの始め方と料金・評判を網羅した完全ガイドを併読すると全体像を掴みやすくなります。
なぜ公式アプリの「接続済み」表示だけでは不十分なのか
2026年3月にMillenVPNのWindowsクライアントは大型アップデートでUIが刷新され、サーバー選択画面に「Ping値表示」が追加されました。これは便利な改善ですが、表示されているのはVPNゲートウェイへのICMP応答時間のみで、実際の通信品質を示すものではありません。
VPNを介した通信の体感速度は、(1)自宅回線からVPNゲートウェイまでのRTT、(2)VPNゲートウェイから目的サーバーまでのRTT、(3)暗号化・復号処理のオーバーヘッド、(4)MTU不一致によるフラグメント化、(5)経路途中のISPピアリング状況——という5要素の積み重ねで決まります。公式アプリのPing値は(1)しか反映していません。
総務省が公表している「我が国のインターネットにおけるトラヒックの集計結果」（2026年時点の最新公表分）によると、国内の固定ブロードバンドのダウンロード総トラヒックは前年同月比で増加が続いており（直近の公表値で約16%増の傾向）、夕方から深夜のピーク時間帯にISP間のピアリングポイントが輻輳しやすくなっています。VPN利用時はこの輻輳が「VPNサーバーまでの経路」と「VPNサーバーから目的地までの経路」の両方で発生するため、片方だけを見ても全体像は掴めません（出典：総務省「我が国のインターネットにおけるトラヒックの集計結果」）。
筆者が2026年4月15日の22時台に検証したケースでは、MillenVPN東京サーバーへのPingは平均8.2msと優秀だったにもかかわらず、そこから先のクラウドサービス（東京リージョン）までのRTTが72msに膨張し、結果的にWeb会議の音声が途切れる事象が発生しました。原因はVPNサーバー出口側のIX輻輳で、これはコマンドプロンプトのpathpingで初めて可視化できました。こうした「夜・休日だけ遅い」症状の構造的な原因と対処は、MillenVPNが夜だけ遅くなる原因と高速サーバーの選び方で実測データつきに掘り下げています。
つまり「VPNが繋がっているのに重い」という症状の大半は、公式アプリのGUI上では一切兆候が出ません。コマンドプロンプトによる経路レベルの観測こそが、真の品質判定の入口になります。
5ステップで実行するMillenVPN接続検証の完全手順
以下の5ステップは上から順に実行する設計です。各ステップに「正常系」と「異常系」の出力例を載せたので、自分のターミナル結果と見比べるだけで合否が判定できます。
ステップ1: ipconfig /all で仮想アダプタの状態を確認する
まずWindowsキー + Rで「cmd」と入力し、コマンドプロンプトを起動します。管理者権限は基本的に不要ですが、後述のnetshコマンドの一部は管理者権限が必要なので、トラブルシューティング目的なら最初から「管理者として実行」がおすすめです。
最初に実行するのは ipconfig /all です。MillenVPNはOpenVPNプロトコルとIKEv2の両方に対応していますが、いずれの場合もWindows上には専用の仮想アダプタが作成されます。OpenVPNの場合は「TAP-Windows Adapter V9」または「Wintun Userspace Tunnel」、IKEv2の場合は「WAN Miniport (IKEv2)」として表示されます。
確認すべきは以下の3点です。IPv4アドレスが10.x.x.xなどMillenVPNが配布するプライベート帯になっていること、デフォルトゲートウェイが仮想アダプタ側に向いていること、DNSサーバーがMillenVPN指定の値（2026年6月時点では一部サーバーで103.86.96.100など）に切り替わっていることです。正常時の出力は次のようになります。
イーサネット アダプター MillenVPN TAP-Windows Adapter V9: 接続固有の DNS サフィックス . . . . .: IPv4 アドレス. . . . . . . . . . . . .: 10.8.0.6(優先) サブネット マスク . . . . . . . . . .: 255.255.255.0 デフォルト ゲートウェイ . . . . . . .: 10.8.0.1 DNS サーバー. . . . . . . . . . . . . : 103.86.96.100
ここでDNSが自宅ルータのIP（192.168.x.x）のままになっていると、いわゆるDNSリーク（VPN経由なのにDNS問い合わせだけがISPに漏れる状態）が発生しており、閲覧履歴がISP側に渡っている可能性があります。筆者が初めて契約した直後、この状態に気付かず3日間使い続けていた失敗があります。
DNSリークの確定方法——疑わしいときは次のコマンドで裏取りします。
nslookup myip.opendns.com resolver1.opendns.com
返答に表示されるアドレスがMillenVPNの出口IP（自宅のグローバルIPでない）になっていれば正常です。あるいは nslookup example.com を実行し、先頭の「Server」欄に自宅ルータIP（192.168.x.x）が出ればリーク確定、MillenVPN指定DNS（103.86.96.100など）が出れば正常と判定できます。
ステップ2: ping -n 50 で実測遅延と揺らぎ（ジッター）を測定する
次に通信品質の数値化です。ping 8.8.8.8 -n 50 のように回数を50回程度に指定して実行します。デフォルトの4回では平均値の信頼性が低く、瞬間的なジッターを見逃すためです。
結果は平均値（Average）だけでなく、最小と最大の差＝ジッター、そして「失われたパケットの割合（ロス率）」を必ずチェックします。Web会議や音声通話の体感品質に直結するのはこの3指標です。
ジッターの計算式は単純です。
ジッター（近似）＝ 最大RTT − 最小RTT（ping -n 50 出力の Maximum − Minimum）
このジッター値を用途別の許容目安と突き合わせれば、自分の接続が「その用途に合格か」を一発で判定できます。
| 用途 | ジッター許容目安 | 備考 |
|---|---|---|
| VoIP・Web会議 | 30ms以下 | 超えると音声の途切れ・遅延が体感に出る |
| オンラインゲーム（FPS） | 20ms以下 | 被弾判定のズレに直結。最もシビア |
| 動画ストリーミング | 50ms以下 | バッファで吸収されるため比較的緩い |
| 大容量ファイル転送 | 制限なし（ロス率重視） | 遅延より「ロス0%」が重要 |
正常系の出力例（MillenVPN東京サーバー経由、筆者2026年5月実測）は次の通りです。
8.8.8.8 の ping 統計: パケット数: 送信 = 50、受信 = 50、損失 = 0 (0% の損失)、 ラウンド トリップの概算時間 (ミリ秒): 最小 = 9ms、最大 = 17ms、平均 = 11ms
この場合ジッター＝17−9＝8ms、ロス率0%なので、VoIP・ゲーム・ストリーミングのすべてで合格です。同条件でロサンゼルスサーバー経由にすると平均128ms・最大145ms・最小122ms・ロス率0%（ジッター23ms）で、米国向けストリーミングには十分でもFPSゲームには厳しい、と数値で線引きできます。
一方、次のような異常系の出力が出たら要注意です。
8.8.8.8 の ping 統計: パケット数: 送信 = 50、受信 = 44、損失 = 6 (12% の損失)、 ラウンド トリップの概算時間 (ミリ秒): 最小 = 28ms、最大 = 340ms、平均 = 96ms
ロス率12%・ジッター312msは、どの用途でも不合格レベルです。この場合は経路のどこで詰まっているのかをステップ3・4で深掘りします。
ステップ3: tracert と route print で経路・トンネル経由を把握する
tracert example.com を実行すると、目的地までの中継ルータ（ホップ）が順番に表示されます。VPN接続時は1ホップ目が必ずVPNゲートウェイのIPになり、そこから先がVPN出口側のISP経路に切り替わるのが正常な状態です。もし1ホップ目が自宅ルータのIP（192.168.1.1など）になっていたら、その通信はVPNを通っていません。
ただしtracertは「結果」しか見えないため、その前にroute printで「そもそも全トラフィックがVPNトンネル経由になっているか」を確認するのが根本です。スプリットトンネリング（一部の通信だけVPNを迂回させる設定）が意図せず有効だと、特定アプリだけVPN外に漏れます。次のコマンドでデフォルトルートを確認します。
route print 0.0.0.0
デフォルトルート（0.0.0.0/0）の「ゲートウェイ」がMillenVPN仮想アダプタのIP（例: 10.8.0.1）になっていれば、全トラフィックがVPN経由です。ここが自宅ルータIP（192.168.1.1など）のままなら、意図しないスプリットトンネルが確定します。あわせて表示される「インターフェイス番号」を ipconfig /all の仮想アダプタの番号と照合し、一致しているかも確認してください。
route printで「VPN経由」を確認したうえでtracertの1ホップ目がVPNゲートウェイになっていれば、トンネルは正常に全通信を運んでいると判断できます。
ステップ4: pathping で各ホップのパケットロス率を集計する
tracertは経路を見るだけですが、pathping example.com は経路上の各ホップを300秒ほどかけて連続観測し、どのホップでパケットロスが発生しているかを百分率で集計します。これがVPNトラブル切り分けの最強の武器です。正常系では各ホップのロス率が0%に揃います。
ホップ RTT 失われた/送信 = Pct 失われた/送信 = Pct アドレス 0 DESKTOP [10.8.0.6] 0/ 100 = 0% | 1 11ms 0/ 100 = 0% 0/ 100 = 0% 10.8.0.1 0/ 100 = 0% | 2 13ms 0/ 100 = 0% 0/ 100 = 0% (VPN出口の次ホップ)
問題がある場合は、特定ホップだけロス率が跳ね上がります。筆者は2026年4月にMillenVPN大阪サーバー経由で特定クラウドへの接続が遅い症状に遭遇しましたが、pathpingではVPN出口直後の3ホップ目で12%のロス率が出ていました。
ホップ RTT 失われた/送信 = Pct 失われた/送信 = Pct アドレス 2 13ms 0/ 100 = 0% 0/ 100 = 0% 10.8.0.1の次 12/ 100 = 12% | 3 58ms 12/ 100 = 12% 12/ 100 = 12% (VPN出口側ISPのルータ)
このとき、左列（ソースからの累計ロス）と右列（このリンク単独のロス）の両方が12%なので、ロスはまさにこの3ホップ目で発生していると特定できます。これを該当ホップのIPと時刻を添えてMillenVPNサポートに報告したところ、別サーバーへの切替提案を素早く受けられました。GUI画面のスクショだけ送っていたら原因特定までもっと時間がかかっていたはずです。
ステップ5: netsh interface ipv4 show subinterfaces でMTUを確認する
最後にMTU値の確認です。MTU（Maximum Transmission Unit）とは、1パケットで送れるデータの最大バイト数のことです。VPN接続では暗号化ヘッダーの分だけ実質的に送れるサイズが減り、デフォルトの1500バイトのままだとフラグメント化（パケット分割）が発生して速度が大幅に低下することがあります。
netsh interface ipv4 show subinterfaces
を実行し、MillenVPNの仮想アダプタのMTUを確認します。「1400前後が適正」とよく言われますが、その根拠は使用プロトコルごとのオーバーヘッドにあります。
| プロトコル | 主な差し引き | 推奨MTU目安 |
|---|---|---|
| OpenVPN（UDP） | IPヘッダ20 + UDPヘッダ8 + OpenVPN制御約40 | 約1432 |
| IKEv2 / IPsec | ESPヘッダ約66〜88（暗号方式で変動） | 約1412〜1434 |
計算式はシンプルで、推奨MTU ＝ 1500 − 各プロトコルのオーバーヘッドです。OpenVPN(UDP)なら 1500 − 20 − 8 − 約40 ＝ 約1432、IKEv2/IPsecなら 1500 − 約66〜88 ＝ 約1412〜1434 が目安になります。
自分の環境の最適値を実測で探すには、フラグメント禁止オプション付きのpingを使います。
ping -f -l 1400 8.8.8.8
「パケットの断片化が必要ですが、DFが設定されています」と出たら値が大きすぎるので、-l の値を10ずつ下げて、このメッセージが出なくなる最大ペイロードを探します。見つかったペイロード値に+28バイト（ICMP8＋IP20）を足した数が、その経路の実効MTUです。例えば -l 1400 が通れば、実効MTUは1400+28＝1428となります。
通信が不安定なまま1500で固定されている場合は、求めた値で固定すると改善することがあります。
netsh interface ipv4 set subinterface "アダプタ名" mtu=1432 store=persistent
料金プランごとの同時接続台数や対応プロトコルの違いで最適なMTUが変わる場合があるため、契約前に各プランの仕様を比較しておきたい方はMillenVPNの料金・評判と対応プロトコルの選び方を解説したガイドも併せてご覧ください。
他のVPN品質計測手段との比較と使い分け
ブラウザ上で動く「Speedtest.net」や「Fast.com」も手軽ですが、これらはダウンロード速度とPingの平均値しか出ず、経路ロスやMTU問題は検出できません。一方、有料のSolarWinds系ツールは詳細ですが個人利用には過剰です。
| 計測手段 | 経路可視化 | ロス率 | MTU検出 | ジッター | コスト |
|---|---|---|---|---|---|
| 公式アプリのPing表示 | 不可 | 不可 | 不可 | 不可 | 無料 |
| Speedtest.net | 不可 | 不可 | 不可 | 一部 | 無料 |
| コマンドプロンプト | 可能 | 可能 | 可能 | 可能 | 無料 |
| 有料監視ツール | 可能 | 可能 | 可能 | 可能 | 月数千円〜 |
コマンドプロンプトでの検証は、無料・標準搭載・ログ保存可能という三拍子が揃った最も合理的な選択肢です。デメリットは初見でのとっつきにくさですが、本記事の5ステップを一度実行すれば、以降は数分で品質判定ができるようになります。リモートワーク主体の方や、海外サーバー経由でゲームをするユーザーには特に有効です。
よくある質問
- コマンドプロンプトでpingが通らないのはVPNのせいですか？
- 必ずしもVPNが原因とは限りません。ICMPパケットを目的サーバー側がブロックしている可能性が高く、別サーバー（8.8.8.8や1.1.1.1）に変更して再検証してください。それでも通らない場合は、tracertで経路を確認しましょう。
- route printでデフォルトルート（0.0.0.0）が複数表示されますが正常ですか？
- VPN接続中は正常です。OS本来のルートとVPNが追加するルートが併存しますが、判断基準は「メトリック値が小さい＝優先される行のゲートウェイ」がMillenVPN仮想アダプタのIP（10.x.x.x）になっているかどうかです。優先行が自宅ルータIPのままなら、スプリットトンネルやVPNの経路注入失敗を疑ってください。
- ジッターはどのくらいなら合格ですか？
- 用途で異なります。ping -n 50 出力の「最大−最小」で近似でき、目安はVoIP・Web会議30ms以下、FPSゲーム20ms以下、動画ストリーミング50ms以下です。平均RTTが低くてもジッターが大きいと音声・映像は乱れるため、平均だけで判断しないのがコツです。
- tracertの途中で「* * *」と表示されるホップがあります。問題ですか？
- 多くの場合は問題ありません。経路上のルータがICMP TTL Exceededへの応答を意図的に拒否している設定で、通信自体は正常に到達しています。最終ホップが正常に応答していれば心配無用です。
- pathpingの実行に時間がかかりすぎます。短縮できますか？
- pathping -q 50 -p 200 のように-qで照会回数、-pで間隔（ミリ秒）を指定すると短縮できます。ただし精度は下がるため、本格的なトラブル調査時はデフォルト設定の約300秒待つことを推奨します。
- MTUを変更すると他の通信に影響しますか？
- アダプタ単位の設定なので、MillenVPNの仮想アダプタのみに変更を加えれば通常のWi-Fi接続には影響しません。元に戻す場合はmtu=1500を再設定してください。プロトコルを切り替えた際は最適MTUも変わるため、再計測をおすすめします。
- コマンドの実行結果をMillenVPNサポートに送る際の最適な形式は？
- コマンドの末尾に「 > result.txt」を付けてテキストファイルに保存し、実行時刻・接続サーバー名・契約プランを添えて送付するのが最速です。スクリーンショットより文字検索が可能で、サポート側の解析時間が大幅に短縮されます。
まとめと次に取るべき具体的行動
MillenVPNの接続品質は、公式アプリのGUIだけでは半分しか見えません。ipconfig・ping・tracert（+route print）・pathping・netshの5コマンドを使い分ければ、経路上のどこで品質が劣化しているかを誰でも数値で特定できます。ジッターは「最大−最小」で計算し、DNSリークはnslookup、スプリットトンネルはroute printで確定する——この一連の流れを覚えれば、トラブル時の原因切り分けが一気に速くなります。
次のステップとして、まずは普段使っているサーバーで本記事のステップ1〜5を一度通して実行し、平常時の数値を「ベースライン」として記録してください。このベースラインがあれば、後日トラブルが発生した際に「いつもと比べて何が違うのか」を即座に判断できます。なお、ホテルや空港のWi-Fiで認証画面が出ずそもそも接続できないケースは、コマンド検証の前段階の問題です。その場合はホテル・空港WiFiでMillenVPNが繋がらない原因と5分解決手順を先に確認してください。
※ 以下のリンクは広告/PR を含みます。
サーバー選びを最適化したい方や、これからMillenVPNを始める方は、MillenVPNの始め方から料金・評判まで網羅した完全ガイドを参照すると最短で運用フェーズに入れます。最新の割引キャンペーンや申し込み手続きはMillenVPN公式ページから確認可能です。