重要なリンク
*Service Health ダッシュボードは現在、Enterprise API のお客様のみご利用いただけます。
まず適切なデフォルト設定を確認する
Service Health ダッシュボードを開くと、デフォルトでは次の設定になります。
すべてのプロジェクト
過去 30 日間
1 時間ごとの解像度
この表示は全体像を把握するためにのみ役立ちます。意味のあるトラブルシューティングには、常にフィルタリングが必要です。
調査前にフィルタリングする
正しいフィルタリングは最も重要なステップです。誤解の多くは、モデル、ティア、プロジェクトを混在させることで生じます。
モデルで絞り込む（一度に 1 つ）
必ず単一のモデルに絞り込んでください。
理由:
トラフィックの少ないモデルの問題は、トラフィック量の多いモデルに隠れてしまうことがあります
トラフィック量の多いモデルは、局所的な問題を全体的な問題のように見せることがあります
モデルごとにパフォーマンス目標が異なります
注: 複数のモデルを選択すると集計されます。モデル間を切り替えるわけではありません。
サービスティアで絞り込む
複数のティア（standard、priority、scale）を使用している場合は、調査対象のティアに必ず絞り込んでください。
理由:
ティアごとにパフォーマンス特性が異なります
priority ティアと scale ティアには定義された SLA があります
ティアを混在させると、有料ティアのパフォーマンスが見えにくくなります
これは特にレイテンシ分析で重要です。
プロジェクトで絞り込む
デフォルトでは、Service Health はすべてのプロジェクトを表示します。
トラブルシューティングでは、問題が観測されたプロジェクトに絞り込んでください。
理由:
単一の高トラフィックプロジェクトがメトリクスを支配することがあります
影響を受けている小規模なプロジェクトが、無関係なトラフィックによって見えなくなることがあります
問題が本当に組織全体に及んでいると考えられる場合にのみ、「すべてのプロジェクト」を選択したままにしてください。
エラーのトラブルシューティング
HTTP Requests ビューを使う
エラーを調査するには:
モデルとティアで絞り込みます
Uptime から HTTP Requests に切り替えるには、HTTP Requests タブをクリックします
このビューには、HTTP ステータスコード別の総リクエスト数とエラー数が表示されます。詳細なスパイクや変化を特定するには、分単位の解像度までズームしてください。
エラー数ではなくエラー率を解釈する
一部のエラーは、どの本番システムでも想定されるものです。生の合計数ではなく、エラーの割合に注目してください。
総量が大きいほど、エラー率が極めて低くても、発生し得るエラー数は大きくなります。
Service Health にエラーが表示されない場合
クライアント側のエラーが見えているのに、Service Health に対応するデータがない場合:
リクエストが OpenAI に到達していない可能性があります
通常、問題は上流側にあります（タイムアウト、プロキシ、ネットワーク）
これは、クライアント側のタイムアウト設定が厳しい場合によくあります。
レイテンシのトラブルシューティング
レイテンシ分析が最も有意義なのは、定義された SLA があるpriority ティアとscale ティアです。standard ティアではレイテンシの変動幅がより大きくなることがあり、レイテンシ保証はありません。
主要な指標
これらの各指標を表示するには、該当するタブをクリックしてください。
トークン速度
1 秒あたりに生成されるトークン数
プロンプトサイズには依存しません
リクエスト時間
リクエスト全体の所要時間
出力サイズと推論の影響を強く受けます
最初のトークンまでの時間（TTFT）
最初のトークンが生成されるまでの時間
キャッシュされていない入力プロンプトのサイズと推論の影響を強く受けます
必ず P50 / P75 / P95 パーセンタイルを確認してください。平均値では実際のユーザーへの影響が見えないことがあります。
6. レイテンシとトークン使用量の関連付け
Service Health は、動作がいつ変化したかを示します。Usage データは、その理由がなぜなのかを説明するのに役立ちます。
Usage ダッシュボードでは、Service Health ダッシュボードの表示に関連するデータを見ていることを確認するため、次の操作を行ってください。
Filter で同じプロジェクト、モデルに絞り込みます
該当する場合は、Group by でサービスティア を指定します
レイテンシに最も強く影響する出力トークンに注目します
より詳細に分析するには、Activity Data をエクスポートし、時間の経過に伴うリクエストあたりのトークン数を確認してください。
7. サポートに共有する内容（必要な場合）
サポートに連絡する場合は、次の情報を含めてください。
影響を受ける Org ID （これは重要です）
影響を受けるエンドポイント（Chat Completions、Responses など） （これは重要です）
影響を受けるモデル （これは重要です）
これは scale ティアまたは priority ティアですか？ （これは重要です）
レイテンシまたはエラーが発生した時間帯（タイムゾーン付き） （これは重要です）
関連する x-request-id または X-Client-Request-Id（重要なことが多いため、可能であれば含めてください）
提供したリクエストのタイムスタンプ（タイムゾーン付き、または少なくとも日付）
レイテンシ - 遅いリクエストの例を共有する場合は、そちらの環境でどのくらい時間がかかったかを共有してください。可能であれば、リクエストを送信した時刻と受信した時刻のタイムスタンプも含めてください。
エラー - 失敗またはエラーになったリクエストのおおよその割合、レスポンスコード、エラーメッセージ、エラーレスポンスを受け取るまでにかかった時間を共有してください
リクエストに関連する Project id
これはデータレジデンシーのリクエストに影響していますか？ 影響している場合は、どれですか？
確認している傾向の説明
エラー: 失敗またはエラーになったリクエストのおおよその %
レイテンシ: 影響を受けているパーセンタイル（p50 / p90 / p95 / p99）と、それらが顧客のベースラインと比べてどの程度高いか
両方: エラーまたはレイテンシのデータのスクリーンショットまたは表（エラー率またはレイテンシが予想より高いと、どのように判断しましたか？）
よくあるトラブルシューティング シナリオ
タイムアウトは発生するが Service Health は正常に見える
考えられる原因: リクエストが OpenAI に到達する前にタイムアウトしています。
確認事項:
クライアントまたはプロキシのタイムアウト設定
ローカルネットワークまたはロードバランサーの変更
Service Health ダッシュボードに 499 エラーがあるかどうか（自社のシステムでは 5xx エラーとして表示される場合があります）
デプロイなしでレイテンシが増加した
考えられる原因: 出力トークンサイズまたは推論の使用量が増加した、またはサービスティア間でトラフィックが移動した
確認事項:
Usage ダッシュボードでのリクエストあたりの平均出力トークン数（データのダウンロードと、出力トークンを総リクエスト数で割る計算が必要です）
Service Health ダッシュボードの Request Time と TTFT のパーセンタイル
Priority ティアまたは Scale ティアが遅く見える
考えられる原因: メトリクスがティア間で混在している（つまり、standard ティアのトラフィックが有料ティアのパフォーマンスを見えにくくしている）
確認事項:
フィルタが単一のティアとモデルに限定されていること
ティア間のトークン速度の比較
5XX エラーのスパイク
考えられる原因: 一時的な障害がトラフィックの一部に影響しています。
確認事項:
エラー率の割合
同時にトラフィック量が変化したかどうか
1 つのプロジェクトのみに影響する問題
考えられる原因: プロジェクト固有の設定または使用パターン。
確認事項:
プロジェクトレベルのフィルタリング
影響を受けていないプロジェクトとの比較
最後の要点
メトリクスを解釈する前に、モデル、ティア、および関連する場合はプロジェクト で絞り込んでください
レイテンシ分析では、平均値ではなくパーセンタイルを使用してください
小さなエラー率は想定内です
データが欠落している場合は、通常は上流側の問題を示しています
Usage データはレイテンシがなぜ 変化したかの説明に役立ち、Service Health はいつ変化したかを示すのに役立ちます