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