コマンドラインのプロセスではプロキシを明示的に確認する
ターミナルツールがシステムプロキシを使うかどうかは、OS、Shell、ランタイム、使用するクライアントによって異なります。切り分けでは、まず現在のターミナルから見える環境変数を確認し、同じターミナルから実際のプログラムを起動してください。設定変更後も変化がない場合は、古いプロセスが起動時の環境を使い続けないよう、ターミナルを開き直します。
リクエスト先が除外リストで迂回対象になっていないかも確認してください。迂回ルールが広すぎると、ブラウザは拡張機能経由で正常にアクセスできても、AI APIは直接接続されるという一見矛盾した結果になります。
IDEとプラグインは独自のネットワークスタックを使う場合がある
Cursor、Copilotなどのエディタプラグインは、エディタ本体のプロセス、拡張機能ホスト、バックグラウンドの子プロセスからリクエストを送る場合があります。システムプロキシが有効でも、すべてのプラグインが自動的に継承するとは限りません。プロキシ変更後はエディタを完全に再起動し、ログイン、モデルへのリクエスト、内蔵ターミナルを個別に確認してください。
プラグインだけが失敗してブラウザは正常な場合は、エディタのプロキシ設定、証明書処理、拡張機能のログを確認してください。複数地域を連続して切り替えるとアカウント環境の変化が増え、かえって元の障害を隠してしまいます。
CI環境では出口の固定とタスク分離を考慮する
自動化タスクは通常、独立した環境で実行され、個人のPCの回線設定を継承しません。設定時には、タスクの送信元、利用する出口、ビルド手順から対象サービスへアクセスできるかを明確にしてください。複数の並列タスクでは、第三者プラットフォームの呼び出しルールとレート制限にも従う必要があります。
ネットワークの再試行は一時的な接続失敗だけを対象にし、認証失敗やパラメータエラーを無制限に繰り返さないでください。エラーをネットワーク、権限、クォータ、リクエスト内容に分類すると、無効な呼び出しを減らし、問題がネットワーク層とアプリケーション層のどちらで起きたかも特定しやすくなります。
認証情報とネットワーク設定を分けて管理する
APIキーは管理された環境変数またはシークレット管理システムに保存し、スクリプト、ログ、公開リポジトリには書き込まないでください。プロキシアドレス、認証情報、業務用キーも分けて管理し、ネットワークの切り分け中に機密情報を誤って出力しないようにします。ログを共有する前に、リクエストヘッダー、クエリパラメータ、環境変数を削除してください。