OpenRouterがタイムアウトするとき、どこから調べる？

OpenRouterへのリクエストがタイムアウトしたら、接続前、最初の応答前、ストリーミング途中のどこで止まったかを確認します。 取得できるエラー本文とリクエストIDを保存してください。すぐに待ち時間を延ばしたり提供元を切り替えたりすると、原因を区別しにくくなります。

この記事は、一般的なHTTP通信とクライアント側の診断をOpenRouterへのリクエストに当てはめたものです。OpenRouter全体の障害や失敗率を示すものではなく、本稿の作成にOpenRouterの実APIテストは行っていません。

3つの症状を分ける

レート制限とタイムアウトは対処が異なります。Kimiの429については既存のレート制限ガイドを参照してください。本稿では、どこで処理が止まったかを先に調べます。

経路を変える前にクライアントを確認する

ライブラリとバージョン、接続先、モデル、ストリーミングの有無を記録します。SDKが自動で再試行する設定になっていないかも確認してください。見た目は1回の呼び出しでも、複数回の試行が行われている可能性があります。

アプリケーションサーバーやプロキシに、より短いタイムアウトが設定されている場合もあります。計測できるなら、接続までの時間、最初のバイトまでの時間、全体の時間を分けます。ストリームでは、HTTPヘッダーを受け取れたことだけで生成完了とは判断できません。

公開の問い合わせにAPIキー、認証ヘッダー、非公開の入力を載せないでください。必要な情報だけを残し、機密情報を含まない短い入力で再現します。

1回のリクエストに絞って再現する

1. 元のエラーと時刻を保存します。
2. 利用権限のあるモデルで、小さな入力を送ります。
3. クライアント側の試行回数を確認します。診断のため自動再試行を止める場合は、そのクライアントの正式な設定を使います。
4. プロキシ、ストリーミング、入力サイズなど、変更する条件を一つに絞ります。
5. 別の経路を試すときも、同じ入力で比較します。他社ゲートウェイの設定をそのまま使えるとは限りません。

小さいリクエストが成功しても、本番の信頼性を確認したことにはなりません。失敗した場合も、ログなしに故障箇所までは特定できません。

エラー資料の対象を確認する

OpenAIのエラー資料は、接続失敗、タイムアウト、APIから返されるエラーの違いを理解する参考になります。ただし、OpenAIのサービスとSDKについての資料です。実装では、実際に返された応答と使用中のクライアントの仕様を確認してください。

2026年9月16日に撮影した英語の原典画面です。エラー分類の参考として掲載しており、OpenRouterの管理画面やOpenRouterで再現した障害ではありません。

再試行で同じ処理を二重に実行しない

繰り返してよい操作か確認し、回数を制限した方針で再試行します。待機時間などがサービスから案内される場合は、その仕様に従います。原因が変わらないまま無制限に繰り返すことは避けてください。

クライアントが応答を受け取れなくても、上流では処理が済んでいる可能性があります。エージェントが指示したツール操作をアプリ側で実行済みの場合もあります。再送する前に、アプリの状態と取得できる利用履歴を照合します。

途中までの出力は未完了として扱います。再生成した全文をそのまま継ぎ足して、一つの正しい回答として保存しないでください。Codexの受信中断ガイドも、再開地点の確認に役立ちます。

問い合わせに必要な記録をまとめる

UTCの時刻、モデル、機密情報を除いたID、ライブラリとバージョン、受信方式、待ち時間、試行回数、小さい入力でも再現するかをまとめます。分からないことは、分からないまま明記します。

提供元の確認チェックリストには、経路と請求の記録方法もあります。提供元を変えて成功しただけで、前の提供元に原因があったと確定するわけではありません。