Cursor／CopilotにはどのVPN？AIコーディングツールの高速化を実測比較

Cursor／Copilotに適したVPNは、速度テストのピーク値ではなく、接続を維持できるか、ストリーミング応答が安定しているか、エディター・ターミナル・Gitが制御可能な同じ経路を使えているかで判断します。AIコーディングツールはコンテキストを連続送信し、差分結果を受け取りながら、インデックスやモデルAPI、拡張機能のサービスを呼び出すこともあります。経路が一時的に切れると生成が中断され、画面に会話が残っていても実行中のリクエストを再送しなければならない場合があります。

そのため、大容量ファイルのダウンロードに向く経路が、CursorやGitHub Copilotにも適しているとは限りません。瞬間的な帯域幅が高くても、ある時点のスループットが良いことしか示せません。開発環境では接続維持、遅延の揺れ、パケットロス後の復旧、プロセスごとのプロキシ設定の引き継ぎ方が重要です。本記事では再現できない瞬間速度の数字で結論を出さず、自分の端末・ネットワーク・作業時間帯で繰り返せるテスト方法を紹介します。

AIコーディングツールが実際に必要とするネットワーク特性

ピーク帯域幅より長時間接続が重要

コード補完で送信するデータは通常大きくありませんが、やり取りは頻繁です。チャット、Agentタスク、複数ファイルの編集ではより多くのコンテキストを含み、結果もストリーミングで返されます。接続が途中でリセットされると、画面が「生成中」のまま止まったり、出力の途中までしか受け取れなかったりします。その場合、待ち続けても解決しないことが多いため、まず接続にデータが届いているかを確認し、再試行するか経路を切り替えるか判断します。

安定した長時間接続には、経路上のローカルクライアント、ルーター、通信事業者のネットワーク、中継入口、出口がセッションを頻繁にリセットしないことが必要です。プロトコル層の高速な再接続は役立ちますが、再接続できても元のリクエストをシームレスに再開できるとは限りません。開発者にとっては「一度でも切断を減らす」ことが、「切断後すぐ復旧する」ことより価値を持つ場合が多いでしょう。

平均遅延だけでは揺らぎは分からない

平均遅延が近い2本の経路でも、入力時の体感は大きく異なります。一方は応答間隔が均一で補完が連続して表示され、もう一方は時々停止してからまとめて応答するため、明らかに引っかかって感じられます。パケットロスも一度の測定だけでは判断できません。ネットワークによっては測定パケットの優先度を下げても、実際のHTTPSリクエストは正常な場合があるためです。エディターの挙動、継続的なリクエスト、システムの接続ログを組み合わせて確認しましょう。

出口地域は統一する

開発セッション中に出口地域を頻繁に切り替えると、アカウントサービスで追加認証が求められたり、既存の接続がすべて再構築されたりする可能性があります。比較時は切り替えても構いませんが、通常の作業では地域と経路をできるだけ固定してください。切り替えが必要な場合は、生成中のタスクを停止し、エディターが現在のリクエストを終えてから新しい経路に接続し、関連機能を再度開きます。

直結・中継・IEPL専線の選び方

「直結」「中継」「IEPL専線」は経路の構成方法を示すもので、プロトコル名ではありません。Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICは、異なる種類の経路上で動作できます。プロトコル名だけで基盤となる国際経路や混雑時間帯の性能を推測することはできません。

CursorとCopilotでは、まず中継またはIEPL系の経路を測定し、直結を比較対象にするとよいでしょう。直結が必ず遅いからではなく、AIコーディングでは一時的な揺らぎが生成の停止として現れやすいためです。対象地域への直結ルートが安定しているなら、よりシンプルな選択肢になることもあります。

プロトコルの違いはCursorとCopilotにどう影響するか

プロトコルはクライアントとノード間でデータをカプセル化、暗号化、転送する方法を決めますが、品質の低い基盤経路を改善することはできません。選択時はまずローカルネットワークでUDPが制限されていないかを確認し、次にクライアントの互換性、プロキシモード、経路品質を見ます。

Shadowsocks、VMess、Trojan、VLESS

Shadowsocksは軽量で、対応クライアントも多く、一般的なシステムプロキシやルールベースの分割ルーティングに適しています。VMessとVLESSはさまざまな転送方式と組み合わせて使われることが多く、実際の安定性はサーバー設定、TLS、基盤転送、クライアント実装に左右されます。VLESS自体は従来の意味で完全な暗号化スイートを担わず、通常はTLSなど外側のセキュリティ機構に依存します。TrojanはTLS接続を基盤とするため、クライアントの互換性と証明書設定の正しさが重要です。

TCPを基盤とするこれらの方式は、一般的なオフィスネットワークでも接続を確立しやすい傾向があります。ただし基盤側のパケットロスが増えると、連続した応答が待ち状態になることがあります。AIのストリーミング生成では、接続できるかだけでなく、長時間の停止が起きていないかを確認しましょう。

Hysteria2とTUIC

Hysteria2とTUICはQUICとUDPを基盤とし、揺らぎやパケットロスがある経路で転送体験を改善することを目指しています。TCP over TCPで起きる典型的な問題の直接的な制約を受けにくく、複数の同時リクエストにも適しています。ただし会社、学校、またはローカルルーターがUDPを制限している場合、接続が不安定になったり、まったく確立できなかったりします。

UDPが利用でき、経路品質が合っている場合、この種のプロトコルでストリーミング応答が滑らかになる可能性があります。UDPが速度制限やポリシーによる破棄を受ける場合は、互換性の高い方式に切り替えます。プロトコル名だけを理由に設定を固定せず、現在の接続ネットワークに合わせて選択してください。

• ✅ クライアントがシステムプロキシ、TUN、または明確なアプリ別分割ルーティングに対応している。
• ✅ ノードのプロトコルが現在のネットワークと互換性があり、UDP制限時に切り替えられる選択肢がある。
• ✅ エディターで継続生成している間、周期的な停止や接続リセットが発生しない。
• ✅ ネットワーク切り替え後に接続を再確立でき、古いプロキシアドレスが残らない。
• ❌ プロトコルの新旧だけで速度を判断し、基盤経路やクライアントログを確認しない。
• ❌ 複数のプロキシクライアントを同時に有効にし、システムのルーティングとDNS設定を互いに上書きさせる。

再現可能な手順で実測比較する

実測の目的は「理論上最速」のノードを探すことではなく、日常の開発環境で作業を最も中断しない組み合わせを見つけることです。キャッシュ、プロジェクト規模、モデル応答の違いを避けるため、同じプロジェクト、同じ種類のリクエスト、近い時間帯を使います。

1. ローカル環境を固定する。ほかのプロキシクライアントを終了し、大容量ファイルの同期とシステム更新を一時停止します。Cursor、VS Code、JetBrains系IDEが同じネットワーク環境を使っていることを確認してください。
2. 基準を作る。普段使うプロジェクトを選び、コード補完、チャット、複数ファイルの分析、Gitの取得を実行します。正常な操作と停止する操作を記録しましょう。
3. 一度に切り替える変数は1つにする。経路を比較するときはプロトコルを変えず、プロトコルを比較するときは出口地域を変えません。そうしないと、変化の原因を特定できません。
4. タスク全体を観察する。接続直後の短いリクエストだけを測定しないでください。コンテキストの読み込み、ストリーミング生成、ファイル変更を含む一連の処理をツールに完了させます。
5. 普段の作業時間帯をカバーする。日中に正常でも、混雑時間帯に安定するとは限りません。ネットワークが空いている時間を選ぶのではなく、実際にコードを書く時間にテストしましょう。
6. 失敗の形を確認する。接続タイムアウト、生成中断、拡張機能のログイン失効、DNS解決失敗、Gitリクエスト失敗を区別します。現象によって調査の方向は異なります。

ある経路でウェブページは速く開くのに、Agentの実行が途中で頻繁に止まるなら、優先度を下げます。初回応答はやや遅くても長いタスクを完了できる経路のほうが、実際の開発には適している場合があります。結果はまず「タスク全体を完了できるか」で並べ、次に応答速度を参考にしましょう。

コマンドラインとエディターのプロキシを個別に確認する

Cursorの画面上のリクエスト、拡張機能のプロセス、内蔵ターミナル、外部ターミナルが同じプロキシ設定を参照するとは限りません。GitHub Copilotはエディターの拡張機能環境で動作するため、エディターのプロキシ設定、システムプロキシ、起動プロセスから継承した環境変数のいずれかに従う可能性があります。よくある問題は経路が使えないことではなく、ブラウザーはプロキシ経由なのにターミナルは直結していることです。

環境変数を使う方法

まずプロキシクライアントでローカルHTTPプロキシのアドレスを確認し、現在のターミナルが読み取れる環境変数として保存します。以下のコマンドはLOCAL_HTTP_PROXYが本機の設定から提供されることを前提としており、特定クライアントのポートは固定しません。

export HTTP_PROXY="$LOCAL_HTTP_PROXY"
export HTTPS_PROXY="$LOCAL_HTTP_PROXY"
export http_proxy="$LOCAL_HTTP_PROXY"
export https_proxy="$LOCAL_HTTP_PROXY"

git config --global http.proxy "$LOCAL_HTTP_PROXY"
git config --global https.proxy "$LOCAL_HTTP_PROXY"

テストが終わったら、Gitで固定プロキシを長期間使いたくない場合は、関連設定を削除できます。

unset HTTP_PROXY HTTPS_PROXY http_proxy https_proxy
git config --global --unset http.proxy
git config --global --unset https.proxy

環境変数の影響を受けるのは、それらを読み取るプロセスだけです。デスクトップアイコンからCursorを起動した後、内蔵ターミナルで変数を設定しても、すでに動作しているエディターのメインプロセスがその値を逆に継承することは通常ありません。エディターにターミナル環境を継承させるには、先に変数を設定して同じターミナルからアプリを起動します。またはシステムプロキシ、TUNモード、エディター自身が対応するプロキシ設定を使います。

HTTPプロキシ、SOCKS5、TUN

HTTPプロキシはHTTPSリクエストや多くのコマンドラインツールに適しており、設定も分かりやすい方式です。SOCKS5はより汎用的な接続を扱えますが、リモートDNS解決に対応するかは各ツールの引数と実装を確認してください。TUNモードはシステムのネットワーク層で通信を引き受けるため、エディター、拡張機能、子プロセスまでカバーしやすくなります。一方で、会社のVPN、仮想マシン、コンテナネットワーク、ローカル開発用のネットワーク帯域とルーティングが競合しやすくなります。

DNS漏洩、分割ルーティング、プラットフォーム別の違い

DNS解決はアクセス経路と一致させる

システムプロキシは通常、アプリの接続だけを引き受け、システムDNSまでは制御しないことがあります。ドメインをローカルネットワークで先に解決し、HTTPS通信だけをプロキシ経由で送ると、解決結果と出口地域が一致しない、ドメイン解決に失敗する、ローカルキャッシュが誤って使われるといった問題が起きる可能性があります。TUNモードはDNSもより統一して制御しやすいものの、クライアントで対応設定が有効か確認する必要があります。

DNS漏洩を調べるときは、ブラウザーのページだけを見ないでください。システムDNS、プロキシクライアントのログ、対象ドメインの解決経路を同時に確認します。設定変更後はシステムとアプリのキャッシュを消去し、リクエストを再実行します。ターミナルだけ失敗してエディターが正常なら、ターミナルの環境変数とコマンドラインツール独自の名前解決方式を重点的に確認します。

分割ルーティングはドメインと用途に沿って設計する

グローバルモードは、問題の原因が分割ルーティングにあるかを素早く確認するのに便利ですが、それだけで結論を出す方法ではありません。ルールモードでは、AIサービスのAPI、認証ドメイン、静的リソース、関連拡張機能のリクエストが同じ出口を使うようにします。メインサイトのドメインだけをプロキシに通し、認証やAPIのドメインを漏らすと、ウェブページは開くのに拡張機能へログインできないことがあります。

ローカルリポジトリ、LAN上の開発サービス、データベース、デバイスのデバッグアドレスは通常、直結にします。そうしないとプロキシ経由で遠回りになったり、エディターからローカルサービスへ接続できなくなったりします。ルールを変更したら、以前の経路を古い接続が再利用しないよう、関連する拡張機能やエディターのプロセスを再起動してください。

Windows、macOS、Linuxで設定するポイント

WindowsではシステムプロキシとTUNを区別します。グラフィカルなシステムプロキシを自動的に読み取らないコマンドラインプログラムもあるため、環境変数を個別に設定する必要があります。TUNを有効にした後は、仮想ネットワークアダプターの優先順位と、スリープ復帰後のルーティングも確認します。

macOSのクライアントは通常、システムネットワーク拡張またはシステムプロキシを通じて通信を制御します。初めて該当モードを有効にするときは、システム権限の確認が必要です。ターミナルから起動したアプリは現在のシェル環境を継承しますが、Finderから起動したアプリは一時的な環境変数を自動的に読み取りません。そのため、起動方法によって結果が異なる場合があります。

Linuxのデスクトップ環境では、システムプロキシの対応が完全に統一されていません。ターミナルツールは環境変数に依存することが多く、TUNには適切なネットワーク権限が必要です。リモート開発、コンテナ、サブシステムを使う場合は、ホストと開発環境のルーティングを個別に確認します。ローカルクライアントが隔離されたすべてのネットワークを自動的にカバーすると考えてはいけません。

よくある障害の切り分け方

エディターにはログインできるのに、補完が待機し続ける

まず現在のプロジェクトだけで起きているか確認します。プロジェクトのインデックス異常やコンテキスト過多でも待ち時間は増えます。次に小さなファイルを作成して通常の補完を試し、短いチャットを送ります。短いリクエストは正常で長いタスクだけ頻繁に中断するなら、長時間接続の維持と応答の揺らぎを重点的に比較します。すべてのリクエストが失敗する場合は、認証ドメイン、APIドメイン、システム時刻を確認してください。

ブラウザーは正常なのに、Copilot拡張機能でネットワークエラーが出る

これは通常、ブラウザーと拡張機能が同じ経路を使っていないことを示します。エディターのプロキシ設定、拡張機能のメインプロセスが継承した環境変数、クライアントがブラウザーだけをプロキシしていないかを確認します。ルールモードを使っている場合は、拡張機能のリクエストがプロキシログに現れるか確認してください。記録がまったくなければ、問題はアプリ側の設定か分割ルーティングの入口より前にある可能性が高いでしょう。

ターミナルのGitは使えるのに、Cursor Agentは使えない

Gitの設定はGitにだけ適用され、エディター内のモデルリクエストを自動的に上書きしません。反対に、Cursorでチャットできても内蔵ターミナルにプロキシが設定されているとは限りません。エディター、拡張機能、Git、パッケージマネージャーをそれぞれ独立したプロセスとして確認するほうが、ノードを何度も切り替えるより効果的です。

経路を切り替えても古い出口に接続される

既存の長時間接続が維持され、DNSやアプリが古い結果をキャッシュしている可能性があります。現在のタスクを停止し、エディターを終了して再起動します。プロキシクライアントの切り替えが完了したことを確認してから、出口地域を確認してください。生成中にノードを連続して切り替えると、実際にどの経路がリクエストを処理したのか判断しにくくなります。

• ✅ ブラウザー、エディター、拡張機能、ターミナル、Gitで個別に接続性を確認する。
• ✅ プロキシログで対象アプリからのリクエストを確認できる。
• ✅ 分割ルーティングのルールがAPI、認証、静的リソースのドメインをすべてカバーしている。
• ✅ ローカル開発アドレス、LANサービス、データベース接続は直結を維持している。
• ✅ 経路の切り替え後にエディターの接続を再構築し、出口地域を再確認する。
• ❌ ウェブページが開くことだけを根拠に、すべての開発プロセスがプロキシ経由だと判断する。

最終的な選び方

日常の中心がコード補完と短いチャットなら、クライアントの互換性が高く、応答が安定した中継経路から試し、ルールベースの分割ルーティングでローカル開発通信への影響を抑えます。Cursor Agent、複数ファイルの変更、長いコンテキストのタスクを頻繁に実行するなら、長時間接続の維持を最優先し、経路を制御しやすい中継またはIEPL系を実測して選びます。

プロトコルは、一般的なTCP経路が幅広い互換性を持ちます。Hysteria2とTUICはUDPが使える環境で比較対象に加えられますが、すべてのネットワークに対する固定解ではありません。クライアントは、システムプロキシ、TUN、DNS、分割ルーティングの状態を明確に表示できるものを優先します。設定が透明であるほど、障害を切り分けやすくなります。

最後は、速度テストの数字ではなく「エディターで作業を完了できるか」を合格基準にします。出口地域を固定して、作業中の経路切り替えを減らします。エディター、拡張機能、ターミナルを個別に検証し、分割ルーティングとDNSも定期的に確認しましょう。ここまで行えば、CursorとCopilotのネットワーク問題を「たまに遅い」という曖昧な状態から、明確な原因ごとに分類できます。