リクエスト段階別にAI APIタイムアウトを設計する

本番実践ガイド：リクエスト段階別にAI APIタイムアウトを設計する。決定的な成果物、失敗境界、段階的展開の確認、根拠付きの制約を示します。

先に結論

リクエスト段階別にAI APIタイムアウトを設計するは単独のコード変更ではなく、明示的な本番契約です。トラフィック移行前に成功条件、最終失敗状態、ロールバック条件を決め、証拠と推測を分離してください。

connectから始め、決定的なケースで headersを証明し、cancelを公開後の課題ではなくリリース条件にします。

再利用できる技術成果物

各行の証拠が同じリクエスト、テスト期間、または設定バージョンに属する場合だけ合格とします。

確認点	保存する証拠	合格条件
connect	DNS,TCP,TLS_budget_and_failure_class	上限が明示され、超過時は閉じた失敗になります。
headers	request_sent->response_headers	上限が明示され、超過時は閉じた失敗になります。
first_output	headers->first_meaningful_output,separate_from_first_SSE_frame	一つの論理リクエストと具体的試行を結びます。
idle	maximum_gap_between_meaningful_stream_events	上限が明示され、超過時は閉じた失敗になります。
total	absolute_request_deadline_inherited_by_all_child_work	上限が明示され、超過時は閉じた失敗になります。
cancel	client_cancel_reaches_queue,gateway,upstream,and_tool_work	一つの論理リクエストと具体的試行を結びます。

具体例

例は合成データによる決定的なものです。レビュー済みの自社値に置き換え、本番秘密情報や顧客データを含めないでください。

total_deadline_ms: 60000
phases:
  connect_ms: 3000
  response_headers_ms: 10000
  first_meaningful_output_ms: 25000
  stream_idle_ms: 15000
rules:
  - child_deadline_must_not_exceed_total
  - client_cancel_propagates_immediately
  - timeout_records_phase_and_attempt

実装手順

1. 変更前のリクエスト、レスポンス、設定、観測基準を固定します。
2. 決定的な正常ケースを実行し、クライアント結果を完全に保存します。
3. 対応する異常または上限ケースを実行します。
4. 全試行を一つの論理 request ID で結び、機密本文を除いて時間、終端状態、usage を記録します。
5. 停止条件を持つ限定コホートで段階的に展開します。
6. 永続状態と公開挙動を再読し、不変条件が崩れたら準備済みのロールバックを実行します。

失敗パターン

外側の HTTP が成功して見えても、次の状態では結果は無効です。

• 取消がキューと upstream に届かず容量を消費し続けます。
• ルートが保持しない隠れた状態を前提にします。
• 試行予算のない再試行が負荷を増幅します。
• プロンプト、キー、機密引数をテレメトリへ保存します。

Modelflare の境界

Modelflare は OpenAI 互換ルーティング、キー、グループ、usage、失敗処理を集約できますが、設定済みルートは任意機能の対応証明ではありません。モデルとチャネルをネイティブプロトコルで確認し、明示的なゼロ値を保ち、永続的な最終精算だけを課金の正とします。

広い判断境界は親ガイド、現在のクライアント設定はセットアップ文書を参照してください。

公開前チェックリスト

• 背景より先に主質問へ回答する。
• 各フィールド、状態、指標、式の owner を決める。
• 合成識別子だけを使う。
• 全言語で構造、コード、制限、注意を保つ。
• T-1 に契約、対応状況、価格を再確認し、事実が変われば日程を移す。
• 予定時刻前は public API、各言語ルート、sitemap から除外する。

情報源と確認日

情報源は 2026-08-07 に確認しました。未検証ルートの対応を証明するものではありません。

• Go: Context
• RFC 9110: Retry-After