AI APIの実測比較：固定出口・同時接続・タイムアウト

AI API VPNは、Web版での体感だけを基準に選ぶことはできません。Webチャットでは通常、ブラウザがセッションを維持するため、一時的な揺らぎはページの停止として現れることがあります。一方、API利用では出口アドレス、コネクションの再利用、同時接続キュー、ストリーミング応答、クライアントのタイムアウトが複合的に影響します。国際回線が開発環境に適しているか判断する際は、単発のリクエストが速いかではなく、同じテストを繰り返し、同時接続数を増やし、プロトコルを切り替えたときに説明可能な結果が得られるかを確認することが重要です。

本記事でいう「実測比較」は、前提のない速度の数字を並べることではなく、再現可能な確認方法を示すものです。同じリクエスト、同じモデル、同じクライアント設定を使い、Webアクセス、通常のAPIリクエスト、ストリーミング出力、同時実行タスクを個別に検証し、どの層で失敗したかに応じて回線を調整します。こうして得た結論は、単発の速度測定より実際の本番負荷に近いものになります。

Web版とAI APIでネットワーク要件が異なる理由

Web版とAPI版は同じサービスにアクセスする場合でも、トラフィックの形態は異なります。ブラウザはスクリプト、スタイル、APIリクエスト、長時間接続を読み込み、ブラウザ独自のプロキシやDNS方針を使うこともあります。開発プログラムはランタイム、コマンドラインツール、コンテナ、サーバープロセスからリクエストを送ることが多く、プロキシを経由するかどうかは、システムプロキシ、環境変数、アプリ設定、ルーティングルールが同時に有効かどうかで決まります。

よくある誤解は、ブラウザでAIのWebページを開けるため、プログラムのAPIリクエストも必ず同じ回線を通ると考えることです。実際には、端末のプロセスがシステムプロキシを無視したり、コンテナが独立したネットワークを使ったり、SDKにプロキシ設定を明示的に渡す必要があったりします。切り分けでは、まずブラウザではなくAPIプロセスの出口を確認してください。

もう一つの違いはストリーミング出力です。通常のWebコンテンツは読み込みが完了すれば接続を終了できますが、AI APIのストリーミング応答ではデータを継続的に読み取る必要があります。中継ノード、クライアントのネットワーク処理、アプリケーション層の読み取り方法が接続を早く閉じると、「リクエストは確立したのに、生成途中で停止する」状態になります。この問題はモデルを替えたり再送したりするだけでは解決できません。読み取りタイムアウト、プロキシ接続の状態、回線切り替えの挙動を確認する必要があります。

固定出口はノード名ではなく、実際の通信で確認する

開発環境でいう固定出口とは、通常、同じ回線を継続利用している間、公衆向けの出口アドレスまたは出口範囲が安定していることを指します。永久的な専有アドレスと同じではなく、ノード名に地域名が含まれていることとも別の話です。サービス側が負荷分散、入口と出口の分離、複数の出口プールを採用している場合もあるため、APIリクエストが実際に使ったネットワーク経路から検証しなければなりません。

再現可能な確認手順

1. テスト環境を固定します。デバイス、クライアント、プロトコル、回線を変えず、自動選択とフェイルオーバーを停止します。テスト中に別の経路へ切り替わらないようにしてください。
2. ブラウザとAPIプロセスを分けて確認します。信頼できる出口確認用のAPIを使い、ブラウザ、コマンドライン、アプリのランタイム、コンテナ内からそれぞれ1回ずつ確認します。表示された出口地域とアドレスが一致するかを確認してください。
3. 接続を繰り返し確立します。プロキシ接続をいったん閉じて再確立し、同じ確認を行います。出口が変わった場合は、回線の仕様による振り分けなのか、クライアントが別のノードを自動選択したのかを確認してください。
4. リクエストのコンテキストを記録します。アプリのログに時刻、回線名、プロトコル、エラー種別、サービス側のリクエスト識別子を記録します。鍵、リクエスト本文全体、機密性のある応答はログに残さないでください。
5. 実際のAPIを再テストします。出口が一致していることを確認してから、通常のリクエストとストリーミングリクエストを実行します。これにより、出口の変化とモデル応答の問題を分けて分析できます。

固定出口の主な価値は、変数を減らせることです。同じ開発タスクで出口地域が頻繁に変わると、サービス側にはセッション環境が変化し続けているように見え、開発者自身もエラーがアカウント、サービス地域、ネットワークのどこに起因するか判断しにくくなります。送信元アドレスの許可リストを設定するAPIでは、出口を予測できることが特に重要です。共有出口を利用する場合は、サービス提供元がそのネットワーク形態を受け入れるかを事前に確認してください。

出口が安定していても、すべてのリクエストが成功するとは限りません。権限不足、リクエスト形式の誤り、サービス側のレート制限、上流障害によってもエラーは返ります。ネットワーク層のエラーとAPIが返したステータス情報を同時に保存し、すべての失敗を回線の問題と決めつけないことが重要です。

同時接続テストでは、接続性能とサービス側のレート制限を分けて確認する

同時接続は、単純に多くのリクエストを同時起動することではありません。1回のAPI呼び出しは、名前解決、プロキシのハンドシェイク、暗号化通信、上流接続、サービス側のキュー、応答の読み取りを経ます。どの層でもキューが発生すれば、アプリが観測する総時間は長くなります。異常をすべて「VPNが不安定」と分類すると、本当のボトルネックを見落とします。

テストは単一タスクのベースラインから始め、通常応答とストリーミング応答が完了することを確認してから、段階的にタスク密度を上げます。各ラウンドでは、同時接続方式だけを変えるなど、1つの変数だけを変更し、モデル、リクエスト内容、回線、プロトコルは固定します。注目すべきなのは見栄えのよい数字ではなく、負荷を上げたときにエラー種別が規則的に変化するかどうかです。

• 接続を確立する前に失敗する場合は、まずDNS、プロキシの待受、プロトコルのハンドシェイク、出口回線を確認します。
• 接続確立後、最初の応答が長時間返らない場合は、上流のキュー、サービス側の状態、読み取りタイムアウトを同時に確認します。
• ストリーミング応答が途中で止まる場合は、長時間接続の維持、クライアントの読み取り処理、プロキシの切り替え、中継経路を確認します。
• 同時接続時だけ拒否される場合は、まずAPIサービスのレート制限を確認し、その後にローカルのコネクションプールとプロキシの処理能力を確認します。
• 一部のタスクがプロキシを迂回する場合は、ルーティングのマッチング、環境変数の継承、コンテナネットワーク、SDK独自のプロキシ設定を確認します。

コネクションの再利用もテスト結果を変えます。再利用に対応したHTTPクライアントは、繰り返しのハンドシェイクを減らせますが、異常な接続を再利用すると複数のリクエストが連続して失敗することもあります。テストレポートには、コネクションプールを使ったか、ストリーミング応答を有効にしたか、失敗後に接続を再利用したか再確立したかを明記してください。条件が揃って初めて、回線同士を比較する意味が生まれます。

リトライ戦略には上限が必要です。接続失敗、一時的な上流エラー、サービス側のレート制限に、まったく同じ処理を適用すべきではありません。無条件に短い間隔で再試行すると同時接続の負荷を増幅し、一時的な障害を長いキューへ変えてしまう可能性があります。より安全なのは、エラー種別に応じて再試行の可否を決め、バックオフとランダムなジッターを加え、タスク全体に締切時間を設定する方法です。すでに内容の返却が始まっているストリーミングリクエストでは、自動再試行の前に重複出力と課金上の扱いも考慮してください。

タイムアウトの切り分けは、接続・読み取り・全体の締切に分ける

「リクエストのタイムアウト」は結果として現れた症状にすぎません。開発ツールは異なる段階の失敗を似た例外として扱うことがありますが、解決方法はまったく異なります。接続タイムアウトは上流接続を確立する前に発生し、読み取りタイムアウトは接続確立後に長時間データを受信できない場合に発生します。全体の締切時間は、タスク全体が使用できる時間を制限します。これらを1つの設定にまとめると、短いリクエストを長く待ちすぎたり、長い応答を早く中断したりします。

接続フェーズ

接続フェーズには、DNS名前解決、ローカルプロキシへの接続、プロキシプロトコルのハンドシェイク、出口ノードまでの転送、出口から対象サービスへの接続が含まれます。この段階で失敗した場合は、まず対象ドメインがプロキシルールに一致しているかを確認し、次にクライアントログでハンドシェイクまたはルーティングエラーがないかを確認します。この時点でモデルパラメータを調整しても、通常は解決につながりません。

応答読み取りフェーズ

接続は成功しているのに応答内容がなかなか届かない場合、サービス側のキュー、リクエスト本文の大きさ、上流処理の遅延、中継経路による接続維持の失敗などが考えられます。ストリーミングAPIでは、リクエスト開始からの経過時間ではなく、「新しいデータが何秒間届いていないか」を基準に読み取りタイムアウトを設定します。アプリ側も応答ストリームを正しく消費し、ローカルのバッファが詰まっただけなのにネットワーク停止と誤判定しないようにしてください。

タスク全体の締切時間

全体の締切時間は、タスクがリソースを無期限に占有するのを防ぎます。キュー待ち、再試行、接続、読み取りを含めて設定し、キャンセル時には下流へ伝播させる必要があります。アプリが待機を止めるだけで下層のリクエストを閉じなければ、バックグラウンド接続がコネクションプールを消費し続け、後続タスクが次第に遅くなることがあります。

タスク開始
  ├─ ルーティングとプロキシ入口を確認
  ├─ 接続を確立
  ├─ 最初の応答を待機
  ├─ ストリームを継続的に読み取り
  ├─ エラー種別に応じてバックオフ再試行を判断
  └─ タスクの締切条件に達したらキャンセルして接続を解放

ログでは少なくとも、接続前と接続後のどちらで失敗したか、応答ヘッダーを受信したか、ストリーミング出力が一度でも返ったか、現在の回線とプロトコルは何か、再試行が発生したか、最終的に何がタスクをキャンセルしたかを確認できる必要があります。これらの状態を構造化して記録すると、「timeout」の一言だけを保存するより原因を特定しやすくなります。

プロトコル、IEPL専線、中継、直結がAPIに与える影響

Shadowsocks、VMess、Trojan、VLESS、Hysteria2、TUICはいずれもプロキシトラフィックの転送に利用できますが、ハンドシェイク方式、通信のカプセル化、ネットワークへの適応性は異なります。プロトコル名だけで回線品質を判断することはできません。同じプロトコルでも、入口、中継、出口が異なれば性能に大きな差が出る場合があります。また、クライアントによってプロトコル機能の実装も異なります。

Shadowsocksは比較的シンプルな構成で、対応クライアントも多いプロトコルです。VMessとVLESSは複数の転送方式に対応するクライアントでよく使われ、VLESSは組み合わせる転送方式とセキュリティ層への依存度が高くなります。Trojanは通常、TLSと組み合わせて利用されます。Hysteria2とTUICはQUIC系の転送設計に基づき、パケットロスや揺らぎのあるネットワークで適応しやすい場合があります。ただし、ローカルネットワークがUDPに適していなければ、TCPベースの方式より実際の性能が劣ることもあります。

IEPL専線とは、通常、国際区間で通信事業者の法人向け専線リソースを使う経路を指し、入口と出口の間が一般的な公衆ネットワーク転送だけに依存しません。中継回線は近い入口に接続してから中継経路で対象の出口へ転送し、直結回線は利用者のネットワークから遠隔ノードへ直接接続します。AI APIにおいて専線や中継が持つ主な意味は、国際区間の経路を管理しやすくすることです。ただし最終的な性能は、ローカル接続、出口品質、対象サービスのネットワークにも左右されます。

プロトコルの比較は、同じ出口地域、同じテスト環境で行ってください。プロトコル、ノード、出口を同時に替えると、改善要因を特定できません。APIのワークロードでは、ダウンロード速度だけでなく、接続確立、最初の応答、ストリーミングの継続性、同時接続時のエラー種別を個別に確認することをおすすめします。

DNSリークとルーティングルールでAPIが想定回線を迂回する

DNSリークとは通常、ドメインの名前解決が想定したプロキシや管理下の解決経路を通らず、ローカルの名前解決元が露出したり、プロキシ出口と一致しない解決結果が返ったりする状態を指します。APIの失敗に直結するとは限りませんが、対象アドレスの選択異常、地域判定の不一致、ルーティングルールの無効化につながる可能性があります。

確認時は、システムDNS、ブラウザのセキュアDNS、プロキシクライアントによるリモート解決、アプリ内蔵の名前解決を分けて考えます。ブラウザで正常でも、コマンドラインのランタイムが同じDNS経路を使っているとは限りません。アプリによっては解決結果を独自にキャッシュするため、回線を切り替えても古いアドレスを使い続けることがあります。プロセスを再起動するか、該当キャッシュを消去してから再テストしてください。

ルーティングルールは、どのドメインやアドレスをプロキシへ送るかを決めます。Webのメインドメインだけを追加しても不十分なことがあります。API、認証、静的リソース、ストリーミングAPIが異なるサブドメインを使う可能性があるためです。より確実なのは、サービス公式のドメイン範囲に基づいてルールを作り、最終的にどのポリシーグループへ振り分けられたかを確認することです。ルールの範囲を無制限に広げると、ローカルの開発依存先、プライベートネットワーク、無関係なサービスまで国際回線へ誤送信する可能性があります。

グローバルプロキシとルール分流の使い分け

グローバルプロキシは、すべての外部リクエストを同じ出口へ送れるため、基準テストに向いています。APIが正常に動作することを確認したら、ルール分流へ切り替え、各ドメインが一致するかを順に確認します。これにより、問題が回線そのものにあるのか、ルールの漏れにあるのかをすばやく判断できます。本番環境では、明確なルールを使いながら、マッチしたルールのログと追跡可能なポリシー名を残す運用が適しています。

各プラットフォームのクライアントと開発環境の違い

WindowsとmacOSのシステムプロキシは、主にシステム設定に従うアプリへ影響します。ただし、コマンドラインツール、仮想マシン、一部のランタイムでは個別設定が必要な場合があります。仮想ネットワークアダプターのモードを有効にすると適用範囲は広がることが多いものの、ローカルネットワーク、開発サービス、コンテナのネットワークセグメントが正しく除外されているかは確認が必要です。

Linuxの開発環境では、環境変数、透過プロキシ、コンテナネットワークが併存するケースがよくあります。プロセスを起動したターミナルはプロキシ変数を継承できますが、サービス管理ツールから起動したタスクが同じ設定を継承するとは限りません。コンテナ内ではローカルループバックアドレスがコンテナ自身を指すこともあるため、プロキシの待受アドレスとネットワーク到達性を個別に確認してください。

iOSとAndroidは、モバイルアプリ、Web操作、モバイルネットワークの切り替えを確認するのに適しています。システムVPN設定で多くのアプリの通信を処理できますが、アプリが異なるDNS、コネクション再利用、証明書ポリシーを使う可能性はあります。モバイル端末のテスト結果だけで、サーバー側APIの長時間運用を代替することはできません。

サブスクリプションリンクは、対応クライアントへノードと回線の設定を配布するために使います。インポート後は、クライアントが設定内のプロトコルに実際に対応しているか、更新後もルーティングルールが保持されているかを確認してください。サブスクリプションリンクはアクセス設定を含む可能性があるため、公開リポジトリ、端末のスクリーンショット、共有ログに書き込まないでください。クライアントへのインポート成功は設定が認識されたことを示すだけであり、出口確認と実際のリクエストで経路が有効になったことを確認する必要があります。

実行可能なAI APIネットワーク比較手順

以上の要素を踏まえ、テストを簡単なものから複雑なものへ段階化できます。各ステップの結果を保存し、異常が出たら1つ前の層へ戻します。回線、プロトコル、コード、リクエストパラメータを同時に変更しないでください。

1. Web版の基準を作ります。対象サービスのWeb入口、アカウント状態、地域要件が正常であることを確認し、現在の出口地域を記録します。
2. APIプロセスの出口を確認します。実際にSDKを実行しているプロセス、コンテナ、サーバーから出口を確認し、想定した回線と一致することを確認します。
3. 最小限の通常リクエストを送ります。有効な最小リクエストで認証、接続、完全な応答を確認し、同時接続と自動再試行は有効にしません。
4. ストリーミング応答を確認します。出力を継続的に読み取り、バッファリング、読み取りタイムアウト、プロキシ切り替えによって接続が早期に閉じられないことを確認します。
5. 同時接続タスクを増やします。タスク密度を段階的に上げ、接続エラー、サービス側のレート制限、読み取り中断、タスクキャンセルを個別に記録します。
6. プロトコルを切り替えて比較します。出口地域とリクエスト条件を固定し、プロトコルまたは回線形態だけを変更して、エラー分布が変化するかを確認します。
7. ルール分流へ戻します。グローバル設定での基準テストから通常の分流設定へ戻し、APIドメイン、認証ドメイン、関連サブドメインが想定したポリシーに一致するかを確認します。
8. 監視項目を定義します。回線、プロトコル、出口、リクエスト識別子、エラーが発生した段階、再試行の理由を保持し、鍵や機密内容は記録しないようにします。

通常のリクエストは安定しているのにストリーミングが中断する場合は、まず読み取りタイムアウトと長時間接続を確認します。単一タスクは正常で同時接続だけ失敗する場合は、サービス側のレート制限とローカルのコネクションプールを分けて確認します。ブラウザは正常なのにプログラムがまったく接続できない場合は、プロセスのプロキシ設定とDNSを確認します。同じタスクで出口が変わり続ける場合は、自動回線選択、フェイルオーバー、出口プールを確認してください。