AIツール
高速化と回線選び

Web版の会員資格とAPI権限は別

Web版はブラウザーのセッション、Cookie、対話型ログインを利用します。一方、APIでは通常、アクセス用認証情報、プロジェクト権限、利用枠、呼び出しルールが必要です。Web版でチャットできても、APIが使えるとは限りません。APIで認証や残高に関するメッセージが返っても、まず回線の問題と決めつけないでください。公式ドキュメントでエンドポイント、モデル、権限を確認したうえで、ネットワーク接続エラーとサービス側の応答エラーを切り分けましょう。

CLI：使用中のターミナルのプロキシ環境を確認

コマンドラインツールの中にはHTTP_PROXY、HTTPS_PROXY、ALL_PROXYを参照するものがありますが、独自設定のみを使うものもあります。利用するSDKやクライアントのドキュメントに従い、環境変数の設定有無、プロキシのプロトコル、NO_PROXYによって対象ドメインが直接接続になっていないかを確認してください。プロキシアドレスは、使用中のローカルクライアントの設定を参照し、別の端末のポートをそのまま流用しないでください。

環境変数を変更しても、起動済みのプロセスには自動で反映されない場合があります。対象のターミナルや開発ツールを終了して再起動し、最小限のリクエストで確認しましょう。ログにはエラーの種類やリクエストの段階を記録できますが、共有前にアクセス用認証情報、認証ヘッダー、アカウント情報、リクエスト全文を削除してください。デバッグ出力をそのまま公開しないでください。

IDEプラグイン：画面とバックグラウンドプロセスを個別に確認

Cursor、GitHub CopilotなどのIDEプラグインは、エディター設定、システムプロキシ、プラグイン独自の設定を使って接続する場合があります。エディター内のターミナル、拡張機能のホスト、ログイン時に開くブラウザーで、同じ設定が引き継がれるとは限りません。まずエディターの公式なプロキシ設定方法を確認し、コード補完、チャット、認証後のコールバックを個別にテストしてください。複数のプロキシ設定を同時に重ねるのは避けましょう。

コンテナ、リモートホスト、リモート開発拡張機能を使う場合は、リクエストがローカルとリモートのどちらで実行されるかも確認してください。ローカルのブラウザーが正常でも、コンテナやリモートプロセスのネットワークが設定済みとは限りません。コンテナ内のローカルアドレスは通常コンテナ自身を指すため、ホスト側のプロキシ待ち受けアドレスに接続できるとは限りません。プロキシの待ち受け範囲とアクセス制御にも注意してください。

CI：リクエストを送るのは実行ランナー

継続的インテグレーションのリクエストは実行ランナーから送信されるため、個人のPCにあるクライアント設定は自動では反映されません。ランナーの所在地域、プラットフォームの外向き通信ポリシー、組織で許可されている接続方法を確認し、プロキシの要否を判断してください。呼び出し用の認証情報はCIプラットフォームの保護されたシークレット設定に保存し、リポジトリ、ビルド成果物、ログには書き込まないでください。信頼できないジョブから認証情報を読み取れないようにすることも重要です。

ストリーミングリクエストでは、SDKの読み取りタイムアウト、ジョブ全体のタイムアウト、プロキシのアイドルタイムアウト、プラットフォームのレート制限をあわせて確認してください。タイムアウトを延ばせば待ち時間不足は改善できますが、権限エラーは解決できません。ネットワーク切断後に無制限の再試行をするのも避け、APIの再試行ルールに従ってください。再送信によって呼び出し料金が重複する可能性にも注意が必要です。