Cursor / Copilot がつながらない?AI コーディングツールの通信と回線を実測比較

Cursor や Copilot がつながらないとき、原因はたいていエディタ側ではありません。補完リクエストは認証サービス、推論 API、維持された長接続の3つを通り、どこか1区間でも揺らぐと「エディタが固まった」ように見えます。本記事はこの3経路に分けて、まずどの層で問題が起きているかを見極め、そのうえで回線を変えるのか、出口地域を変えるのか、クライアントの分流ルールを書き換えるのかを判断します。

本記事では具体的な速度測定値は出しません。回線品質は時間帯・地域・キャリアによって変わり、固定値として書いた遅延や帯域は再現性がなく、かえって誤解を招くだけです。以下で比較するのは経路の特性、失敗のパターン、向いている用途で、この部分は安定しており、そのまま切り分けに使えます。

まず層を特定:補完・チャット・ログインはそれぞれ別の経路を通る

つながらないときに一番やりがちなのが、いきなりノードを変えることです。エディタが送るリクエストは実際には3種類あり、失敗の現れ方もまったく違います。まず層を切り分ければ、調査時間の大半を節約できます。

認証系リクエストはログイン、トークン更新、サブスクリプションの検証を担い、本文が小さく頻度も低めです。失敗するとログイン画面でエラーが出るか、しばらくすると再ログインを求められます。推論系リクエストは2種類あり、インライン補完は高頻度の小さなパケット、チャットはストリーミング応答で、1本の接続が数十秒から数分にわたって出力し続けます。リソース系リクエストは拡張機能マーケット、モデル一覧、アップデート確認を担い、通常の HTTPS で通信します。

3つの症状は異なり、対処法も異なります。まず現象を層に当てはめてから、設定に手を入れてください。

この表を手元に置いて、問題が起きたらまず当てはめてみてください。「つながらない」の多くは2列目で特定でき、回線を触る必要はありません。

AI コーディングツールが本当に見ている3つの指標

開発用の回線選びは、動画配信用の回線選びとは別物です。動画は数秒のバッファリングなら我慢できますが、補完が2秒待たされると思考が途切れます。開発シーンで体感を左右するのは次の3つで、いずれもピーク帯域ではありません。

ピーク帯域より安定した上りが重要

補完リクエスト1回の本文はふつう数 KB しかありませんが、パケットロスに極めて敏感です。トランスポート層がロスを検知するとウィンドウを縮めて再送するため、「入力中は補完がなかなか出ず、しばらくしてから一度に現れる」という挙動になります。帯域は高くなくてもロスが安定している回線のほうが、ピークは高くても時間帯で揺れる回線より体感が良くなります。スピードテストの下りピーク値はこの点を何も示してくれません。

長接続が持ちこたえるか

チャット形式のリクエストはストリーミングで、サーバーが生成しながら逐次 push します。この接続は数十秒から数分生きている必要があり、途中で出口の切り替え、NAT テーブルのタイムアウト、回線のジッタが起きると「出力が途中で止まる」わけです。この種の中断はログ上はふつうリクエストのタイムアウトではなく接続リセットとして現れ、両者の調査方針はまったく別です。

出口地域の一貫性

同じアカウントが短時間に複数の国からログインすると、リスク管理に引っかかります。「パスワードは合っているのにログインできない」の多くは、前回の接続が A 国、今回が B 国だったことが原因です。開発環境には出口を1つ固定するほうが、毎日「より速い回線」に乗り換えるよりはるかに役立ちます。

• ✅ まずパケットロスとジッタを見て、そのあとスピードテストの下りピークを見る
• ✅ 出口が固定された回線を選び、接続のたびに地域が変わるのを避ける
• ✅ 長時間のストリーミング接続に耐え、途中で切れない回線を確認する
• ❌ 動画配信の解除ラベルを開発用回線の選定基準にする
• ❌ 1日のうちに複数の国の出口を何度も行き来する

出口地域とアカウントの地域:ログイン失敗で最も多い原因

AI コーディングツールのアカウント体系は、通常は登録地域に紐づいています。出口 IP の地域がアカウントの地域と一致しないと、サーバー側は追加の本人確認を求めたり、ログイン要求をそのまま拒否したりします。こうした失敗は明確な理由を返さず、汎用のエラー表示だけが出ることが多く、パスワードやネットワークの問題だと誤解しがちです。

対処は難しくありません。開発用の出口をアカウントの地域と一致する回線に固定し、クライアントの「最速ノードを自動選択」のような、出口をランダムに変える機能をオフにします。どうしても複数地域を切り替える必要があるなら、間隔をできるだけ空け、同じセッションの中で行き来しないことです。

もう1つ見落とされがちなのがシステム時刻です。VMess のようにタイムスタンプ検証を行うプロトコルでは、クライアントとサーバーの時刻が大きくずれるとハンドシェイクの時点で失敗し、見た目は「回線が通っていない」とまったく同じになります。OS の時刻自動同期を有効にしておけば、この手の問題をまとめて除外できます。

回線タイプの選び方:IEPL・中継・直接接続の違い

先に結論を書くと、開発シーンでは安定性を優先し、その次に地域を見ます。3種類の回線は経路の特性が異なり、向く負荷も異なります。

IEPL 専用線の利点は、国際区間で他人と公共出口を奪い合わないため揺らぎが小さく、長時間接続を保つ用途に向くことです。中継は中継拠点自体の負荷に左右され、当たりを引けば十分、外すと夜のピークに落ちます。直接接続は最も手軽ですが、時間帯に非常に敏感です。

C6VPN の回線一覧では3種類のバッジでこれらを区別しており、250+ の回線に3タイプすべてが揃っています。選ぶ順序は、まず用途で回線タイプを決め、次にアカウントの地域で出口国を決め、最後に同タイプの中から都市を選ぶ、という流れです。

どれを選べばいいか分からないときは IEPL から試し、具体的な問題が出たら下げていくのがおすすめです。逆に一番安い直接接続から始めると、回線の揺らぎをツール自体の不具合と誤認しやすく、クライアントを一通り替えても解決しない、という結末になりがちです。

プロトコルとトランスポート:VMess・VLESS・Trojan・Hysteria2 の使い分け

プロトコルが決めるのは「トラフィックをどう包むか」であり、回線品質ではありません。同じ物理リンクでプロトコルを変えたときの体感差は、主にヘッダのオーバーヘッドと輻輳制御から来るもので、「どれが速いか」ではありません。

Shadowsocks

軽量な暗号化プロキシプロトコルで、AEAD 暗号を使い、TCP と UDP の転送に対応します。ヘッダのオーバーヘッドが小さく、遅延に敏感な短いリクエストに向きます。設定も最も簡単なので、切り分けの際の比較対象として有用です。

VMess と VLESS

VMess は V2Ray 系のネイティブプロトコルで、タイムスタンプ検証を伴い、クライアントとサーバーの時刻が大きくずれるとそのまま接続できません。VLESS は内蔵の暗号化を外し、外側の TLS に依存するためヘッダのオーバーヘッドがさらに小さくなります。開発シーンでの差は大きくなく、要点は時刻同期を正しく行うことです。

Trojan

標準の TLS を使うため、トラフィックの見た目は通常の HTTPS リクエストと同じです。443 番ポートだけが許可されたネットワーク環境では接続を確立しやすく、通信制限の厳しいオフィス環境に向いています。

Hysteria2 と TUIC

どちらも QUIC 上で動作し、輻輳制御を内蔵しているため、パケットロスの多いリンクでは TCP 系プロトコルより安定します。代償は UDP への依存で、利用するネットワークが UDP を制限・遮断している場合、これらは明確に性能が落ちます。TCP 系に戻して再測定が必要です。

クライアントで分流する:エディタだけをプロキシ経由にする

開発マシンのトラフィックを全部海外に出する必要はありません。エディタ関連のリクエストだけを分流し、それ以外は直接接続にすれば、無駄な遠回りを減らせるうえ、ローカルサービスがプロキシ規則に巻き込まれる事故も防げます。

1. まずエディタがシステムプロキシを読むかどうかを確認します。一部のツールは独自のネットワークスタックを使い、システムプロキシ設定に従いません。その場合は TUN モードでトラフィックを引き受け、ルールで他のアプリを直接接続に戻します。
2. 認証サービスと推論 API のドメインサフィックスをプロキシ規則に追加します。IP 規則よりドメイン規則のほうが安定し、サーバー側の IP が変わっても設定を直す必要がありません。
3. クライアントがプロセス規則に対応していれば、エディタのメインプロセスを直接マッチさせます。ドメインを1つずつ並べるより手間が少なく、そのプロセスがシステムコンポーネント経由で発行するリクエストもカバーできます。
4. それ以外のトラフィックは既定で直接接続にし、ローカル網と社内サービスはプロキシに入れないでください。そうしないとローカルのデバッグ用 API が原因不明のタイムアウトを起こします。
5. 規則を変更したら、エディタを完全に終了して再起動します。多くのクライアントはプロセス起動時に一度だけプロキシ設定を読むため、再起動しないと反映されません。

規則を書いたら、「グローバルプロキシ」と「ルールプロキシ」で同じ操作をそれぞれ1回ずつ試します。グローバルでは正常でルールでは異常なら、原因は回線ではなく規則のドメイン漏れです。この場合に回線を変えても無駄に終わります。

プラットフォーム別クライアントの違いと注意点

同じサブスクリプションでも、OS によって挙動は完全には同じではありません。つまずきやすいのは次の数点です。

Windows

システムプロキシ設定は、独自のネットワークスタックを使うアプリには効かないことがあります。「ブラウザは開けるのにエディタはだめ」という場合は、まず TUN モードを有効にして再試行してください。これで規則の問題か、プロキシが読まれていないのかを切り分けられます。

macOS

TUN モードはネットワーク拡張の許可が必要で、初回有効時に OS が確認ダイアログを出します。許可しても効かない場合は、他のネットワークツールが同じ拡張を占有していないか確認してください。2つのツールが同時に引き受けると、互いに押し出し合います。

Linux

コマンドライン環境ではプロキシの環境変数を明示的に設定する必要があり、GUI クライアントとは別扱いです。TUN モードには相応の権限設定が要ります。この種の環境では「GUI は正常なのにターミナル内のツールだけつながらない」が起きやすく、両者が読む設定ファイルが同じではないことが原因です。

モバイル

スマートフォンやタブレット上のエディタは機能が限られるため、通常は TUN で全トラフィックを引き受け、分流規則を1つずつ書く必要はありません。モバイル回線は出口地域が変わりやすいぶん、出口の固定にはむしろ注意が必要です。

各プラットフォームのクライアントとサブスクリプションはログイン後のパネルから取得できます。プラットフォームに合ったインストール方法を選んでください。

順番に実行する切り分けチェックリスト

ここまでの内容を、実行できる順序にまとめます。各ステップで変える変数は1つだけにし、変更後すぐ同じ操作で再テストしてください。そうしないと、どのステップが効いたのか判断できません。

1. 別のネットワークで再現させる。別のブロードバンド回線かスマホのテザリングで同じ操作を行い、それでも失敗するなら回線かアカウント、正常に戻るならローカルネットワークの問題です。
2. システム時刻が自動同期されているか確認する。特にタイムスタンプ検証を行うプロトコルを使う場合は必須です。
3. 現在の出口地域がアカウントの地域と一致していることを確認し、自動でノードを切り替えるオプションをオフにします。
4. 一時的にグローバルプロキシに切り替えて再試行する。グローバルで正常なら、分流規則にドメイン漏れがあります。
5. 同じ地域内で回線タイプを変えてみる。直接接続、中継、IEPL の順に同じ操作の差を比較します。
6. クライアントのログに接続リセットやハンドシェイク失敗の記録がないか確認し、エラーの種類に応じて該当する章に戻ります。

結論:まず層を分け、それから回線を語る

AI コーディングツールのネットワーク問題は、まず層を分けてから手を動かします。認証・推論・リソースの3種類のリクエストは失敗の現れ方が異なり、対処法も異なります。認証の問題は出口地域とシステム時刻、推論の問題はパケットロスと長接続、リソースの問題は分流規則を見ます。層が分からないまま回線をいくら変えても、当てずっぽうにすぎません。

回線選びでは、開発シーンではピーク帯域よりも安定性と出口の一貫性を優先します。C6VPN は 110+ の国・地域と 250+ の回線を用意し、同時接続デバイスは台数無制限、月額プランは ¥9.9 からで 60GB を含み、初回のお支払いから 30 日以内なら理由を問わず返金を申請できます。長時間チャットと補完を走らせるなら、IEPL 回線から試すほうが時間の節約になります。