AI API に使う回線の選び方は、動画視聴用のノードを選ぶのとは別の話です。Web 画面が固まっても再読み込みすれば済みますが、プログラムが固まるとタスクを一括でやり直すことになります。この記事の目的は、「どの回線が速いか」というすぐ古くなる結論を、何度でも使える判断方法に置き換えることです。
本記事では「最速回線ランキング」は書きません。回線の品質は時間帯で変わるため、固定した順位は数日で意味を失います。示せるのは観測項目、比較手順、そしてどの場面でどのタイプの回線を選ぶかです。
なぜ API 呼び出しと Web 画面は別物なのか
Web 画面で 1 回のリクエストが失敗しても、ユーザーが再試行を押せば済みます。API の 1 回の失敗の背後には、ストリーミング応答、バッチ処理、あるいは最初のバイトを待っている対話ウィンドウがあるかもしれません。違いは体験だけにとどまりません:
- リクエストの形が違う:Web 画面は単発の短いリクエストがほとんどですが、API では長い接続とストリーミング応答が一般的で、1 本の接続を数十秒維持します。
- 失敗のコストが違う:再試行は冪等でなければなりません。重複送信は二重書き込みや二重課金につながります。
- リスク判定の視点が違う:サービス側が見るのは出口 IP です。IP が頻繁に切り替わったり、所在地が漂ったりすると、異常な送信元と判定されやすくなります。
- 切り分けの手順が違う:ブラウザで見えるエラーはクライアントからは見えず、ログとステータスコードに頼るしかありません。
ですから回線を選ぶ前に、まず 3 つの問いに答えてください。出口は安定しているか、同時接続は足りるか、タイムアウトはどう設定するか。この 3 つは「どの回線が速いか」よりも呼び出しの成功率に影響します。
まず選択肢を並べます。以下は本サービスの仕様であり、個々の回線の瞬間的な性能とは関係ありません。何が選べるかだけを示します:
成否を分ける 3 つの指標
固定出口:まず「どこから出るか」を決める
固定出口とは、API を呼ぶときに常に同じ(または同じ小さなグループの)出口 IP を使い、しかもその IP の所在地が安定していることを指します。開発者にとって直接の利点は 3 つあります:
- 許可リストを維持できる:一部のプラットフォームや自前のゲートウェイは IP 単位の許可に対応しており、出口が固定であればリストを毎日書き換えずに済みます。
- リスク判定が連続する:同じ IP からの呼び出しは挙動が一貫し、毎日地域が変わることで追加の検証を招くことがありません。
- 切り分けができる:問題が起きたとき、回線が変わったのかコードが変わったのかを特定できます。
注意したいのは、固定出口は専有出口ではないという点です。共有ノードでは他の利用者の通信がその回線の瞬間的な性能に影響します。変わるのは、外に出ていく IP が一定であることだけです。安定性を重視する業務では、専用線の性格を持つ回線を優先し、クライアント側で API ドメインを個別に振り分けてください。
同時接続:コネクションプールとノードの上限
同時接続の問題はコードの中ではなく、経路の上で起きます。リクエストが詰まる場所は 3 つあります:
- クライアントのコネクションプール:多重化すれば複数のリクエストを 1 本の接続に載せられますが、ストリーミング応答は接続を長時間占有するため、プールはすぐ埋まります。
- ノード側の上限:共有ノードには 1 IP あたりの同時接続数に上限があり、超えると待たされるか拒否されます。
- 再試行の嵐:タイムアウト後に際限なく再試行すると、同時接続が一気に倍増し、小さな揺らぎが雪崩に変わります。
実際の対処は難しくありません。同時接続に明確なセマフォ上限を設け、バッチ処理は分割して投入し、再試行は指数バックオフにランダムなゆらぎを加え、全クライアントが同じ秒に一斉再送しないようにします。
タイムアウトと再試行:失敗を予測可能にする
タイムアウトは少なくとも 2 種類に分けます。接続タイムアウト(どこまでつながらなければ失敗か)と読み取りタイムアウト(つながってからどれだけ新しいデータが来なければ失敗か)です。ストリーミング応答では読み取りタイムアウトに十分な余裕を持たせないと、最初のバイトが届く前に自分のクライアントに切られてしまいます。curl で 3 つの所要時間を観測するのが一番手軽です:
curl https://api.example.com/v1/chat/completions \
-H "Authorization: Bearer $API_KEY" \
-H "Content-Type: application/json" \
-d @payload.json \
--connect-timeout 5 \
--max-time 120 \
-w "connect=%{time_connect} ttfb=%{time_starttransfer} total=%{time_total} code=%{http_code}\n"再試行は再試行可能なエラーにだけ開きます。接続失敗、タイムアウト、429、5xx です。リクエスト形式などの 4xx は何度試しても結果は同じで、枠を無駄に消費するだけです。
| 項目 | 推奨の出発点 | 説明 |
|---|---|---|
| 接続タイムアウト | 5 秒 | 超えてもつながらないなら、数値を大きくする前に回線を疑う |
| 読み取りタイムアウト(非ストリーミング) | 60 秒 | 長文生成では緩めてもよい |
| 読み取りタイムアウト(ストリーミング) | 120 秒 | 「新しいデータが何秒来ないか」で数える。総時間ではない |
| 1 台あたりの同時接続上限 | 8 本 | ノードの余力と業務量に合わせて調整し、一度に開放しない |
| 再試行回数 | 3 回 | 指数バックオフとゆらぎを付け、再試行可能なエラーに限る |
回線タイプの比較:専用線・中継・直結
3 つの道の違いは、データがローカルから海外のサーバーまでどう進むかにあります。進み方が違えば、夜のピーク時間帯の挙動も変わります。
| 回線タイプ | データの進み方 | 安定性 | 向いている API 用途 |
|---|---|---|---|
| IEPL 専用線 | 端から端まで専用線で、公共の国際出口を奪い合わない | 夜のピークでも変動が比較的小さい | 長い接続、ストリーミング応答、バッチ処理 |
| 中継 | まず中継ノードへ入り、そこから海外へ出る | 中継ノードの負荷次第 | 通常の呼び出し、コストを抑えたい業務 |
| 直結 | ローカル回線から直接海外へ出る | 国際出口の混雑の影響を強く受ける | 軽量で再試行でき、リアルタイム性の低い処理 |
補足 3 点:
- 専用線が実現するのは経路の予測しやすさであり、絶対にパケットロスしないことではありません。夜のピークに安定するのは、公共の国際出口の渋滞に並ばないからです。
- 中継のボトルネックは通常、中継ノードそのものにあります。ノードの負荷が高いと、直結より遅くなることもあります。
- 直結はオフピークなら十分ですが、長い接続は切られやすいため、いつでも再試行できる軽い処理に向いています。
実測のやり方:再現できる比較手順
API の場面で見るべきは単発の速度ではなく、継続的な可用性です。次の 5 ステップで進めれば、結果に比較可能性が生まれます:
- スクリプトを固定する:同じリクエスト、同じ入力長で、接続時間、最初のバイトまでの時間、総時間、ステータスコードを記録します。
- 時間帯を分けて回す:午前、夜のピーク、深夜をカバーし、各時間帯で複数回続けて実行して、最小値ではなく分布を取ります。
- 失敗の種類を分ける:接続失敗、読み取りタイムアウト、429、5xx は別々に集計します。対処法がまったく違うからです。
- 回線を替えて繰り返す:同じスクリプトを専用線、中継、直結でそれぞれ実行し、一度の最良値ではなく傾向を比べます。
- 生ログを残す:タイムスタンプ、出口 IP、ステータスコード、所要時間の 4 つがそろって初めて振り返りができます。
判断基準はシンプルで構いません。夜のピークの失敗が接続失敗と読み取りタイムアウトに集中しているなら経路の問題で、回線を替える意味があります。429 に集中しているなら同時接続か割り当ての問題で、回線を替えても無駄です。まず同時接続を下げてください。
クライアント、プロトコル、サブスクの取り込み
回線の品質はサーバー側で決まり、クライアント側が決めるのはその回線を安定して使えるかどうかです。
プロトコルの違い
一般的なプロトコルにはそれぞれ一長一短があります。ここでは API 呼び出しに関係する部分だけを述べます:
- Shadowsocks:軽量で、TCP/UDP 転送に基づき、互換性が高く、通常のリクエストに向いています。
- VMess:時刻検証があり、クライアントの時刻のずれが大きいと接続できません。切り分けではまず時刻合わせを。
- Trojan:TLS を使うため通信の特徴が通常の HTTPS に近く、偽装性が求められるネットワーク環境に向いています。
- VLESS:ステートレスでオーバーヘッドが小さく、TLS 系の転送と組み合わせて使われることが多い方式です。
- Hysteria2 と TUIC:QUIC(UDP)ベースで、パケットロスや揺らぎに強く、不安定な回線でも快適です。ただし UDP が使えることが前提です。
プロトコル自体は出口の位置を変えず、速度も保証しません。影響するのはハンドシェイクのコスト、パケットロスへの耐性、妨害を受ける確率です。
DNS と振り分け
見落としやすい 2 点:
- DNS リーク:ドメインをローカルで解決すると、近くのノードに解決されたり、問い合わせ内容が露出したりします。クライアントは DNS 問い合わせをトンネルに入れるか、API ドメインだけ解決方法を別に指定してください。
- 振り分けルール:API ドメインと認証ドメインは一緒にプロキシ経由にし、ローカルサービス、LAN、日本国内のサイトは直結にします。片方のドメインだけをプロキシして認証ドメインを漏らすと、つながるのに 401 が返り続けるという典型的な症状になります。
各プラットフォームのクライアントの違いは、主に通信の取り込み方にあります:
| プラットフォーム | 取り込み方 | 注意点 |
|---|---|---|
| Windows | システムプロキシまたは TUN | TUN モードでは他の仮想 NIC との競合に注意 |
| macOS | システムプロキシまたは TUN | 初回有効化時はシステム設定でネットワーク拡張を許可する必要がある |
| iOS | ネットワーク拡張 | Wi-Fi とモバイル回線を切り替えた後、接続が維持されているか確認する |
| Android | VpnService | 省電力設定がバックグラウンド接続を回収することがある |
| Linux | コア + ルールセット | ルールファイルを書き間違えると、通知なく直結になる |
サブスクの取り込み
サブスクリプションの URL を取り込むと、クライアントはノード一覧を自動で取得し、サブスクを更新すれば回線も更新されます。注意点は 2 つ。1 つはサブスクのアドレスを他人に転送しないこと。もう 1 つは、よく使う API 回線を固定選択にして自動切り替えを切ることです。長い接続の途中で出口が変わると、サーバー側から見えるのは別の IP になり、リスク判定も許可リストも機能しなくなります。
開発者向け回線選定チェックリスト
ここまでの内容を 1 枚のチェックリストにまとめました。回線を選ぶ前に 1 項目ずつ照合してください:
- ✅ テスト中、出口 IP が変わらず、所在地も安定している。
- ✅ 接続タイムアウトと読み取りタイムアウトを分けて設定し、ストリーミング応答だけ別に緩めている。
- ✅ 再試行はタイムアウト、429、5xx のみを対象にし、指数バックオフとゆらぎを付けている。
- ✅ API ドメインと認証ドメインを一緒に振り分けルールへ入れ、DNS 問い合わせはトンネル経由にしている。
- ✅ サブスクの URL は環境変数に置き、コードリポジトリにもチケットのスクリーンショットにも残さない。
- ❌ グローバルプロキシで全通信を通し、ローカルサービスまでプロキシしてしまう。
- ❌ ピーク時の 1 回の速度測定だけで回線を決めつける。
- ❌ タイムアウト後に無限に再試行し、一度の揺らぎを同時接続の嵐に変えてしまう。
結論:固定出口を優先し、同時接続とタイムアウトで補う
最初からテストスクリプトを組むのが面倒なら、最小コストで検証できます。1 か月のサブスクを選び、API ドメインだけ個別に振り分け、いくつかの時間帯で続けて実行し、失敗がどの種類に集中するかを見るだけです。本サービスは 90+ か国、190+ 回線、月額サブスクは ¥9.9 からで 60GB 込み、同時接続台数は無制限、7 日間の理由不要の返金対応、メールアドレスなしで登録できます。検証コストはかなり低く抑えられます。