顧客に SLA クレジットを約束する前に、AI API 停止証拠台帳を構築する

上流モデルのプロバイダにインシデントが発生した場合、顧客はプロバイダがダウンしたかどうかを尋ねるだけではありません。彼らは、リクエストが失敗したかどうか、どのキーとモデルが影響を受けたか、停止が SLA にカウントされるかどうか、どのクレジットを受け取る必要があるかを尋ねます。プロバイダーのステータス ページは役に立ちますが、それだけではテナント固有の質問に答えることはできません。

AI API ゲートウェイは、プロバイダーのシグナル、合成プローブの結果、リクエストレベルの症状、テナントの影響ウィンドウ、属性の決定、クレジット調整など、停止の証拠を第一級の台帳として扱う必要があります。目的は、より分かりやすいインシデントのタイムラインを作成することではありません。目標は、顧客が直面する停止に関する決定を説明可能かつ再現可能にし、過剰クレジットと過小クレジットの両方に耐性のあるものにすることです。

プロバイダー ステータス ページで証明できることと証明できないこと

事実: Atlassian Statuspage では、概要、ステータス、コンポーネント、未解決のインシデント、インシデント、および定期メンテナンスのパブリック API エンドポイントが公開されています。 OpenAI と Anthropic は、コンポーネントとインシデントのデータを含む Statuspage スタイルの JSON エンドポイントを公開します。 Google クラウドは Service Health API とダッシュボードを文書化し、フィードを通じて公衆衛生情報も公開します。クラウド プロバイダーは、一部のイベントのインシデント後のレビューも公開しています。

これらのフィードは有用な入力です。プロバイダーがインシデントを認識したこと、どの広範なコンポーネントが影響を受けたか、インシデントがいつ調査、特定、監視、解決、事後検証などの状態に移行したかを知ることができます。 AI API再販業者運営 プログラムの顧客クレジットを決定するには十分ではありません。

ステータス ページは、実際の顧客への影響に遅れることがよくあります。これらは、モデルのエイリアス、プロバイダー アカウント、リージョン、デプロイメント、サービス層、またはテナントのホワイトリストに明確にマッピングされずに、チャット、応答、埋め込み、画像、ファイルなどの広範なコンポーネントを記述する場合があります。また、特定の顧客のリクエストが上流の機能低下、ゲートウェイのスロットル、予算の使い果たし、無効な入力、クライアント側のタイムアウト動作、またはローカル ネットワークの問題によって失敗したかどうかもわかりません。

推奨事項: プロバイダーのステータスをクレジット トリガーとしてではなく、1 つの証拠ストリームとして使用します。クレジットは、テナントの影響に関する証拠と、リクエスト ログ、使用量の決済、プロバイダー インシデントの更新が利用可能になった後の調整パスに依存する必要があります。

必要な台帳記録

プロバイダー全体のインシデントとテナント固有の影響の両方を表すことができる永続的な停止記録から始めます。後の分類変更によって元の検出証跡が消去されないように、レコードは追加専用であるか、バージョン管理されている必要があります。

{
  "incident_id": "inc_2026_05_29_openai_azure_eastus_latency",
  "provider": "azure_openai",
  "provider_account_id": "acct_prod_shared_01",
  "surface": "chat_completions",
  "model_or_deployment": "gpt-4o-prod-eastus",
  "region": "eastus",
  "source_signals": ["provider_status", "synthetic_canary", "request_symptoms"],
  "confidence": "confirmed",
  "provider_started_at": "2026-05-29T11:42:00Z",
  "provider_acknowledged_at": "2026-05-29T12:05:00Z",
  "detected_at": "2026-05-29T11:45:11Z",
  "mitigated_at": "2026-05-29T12:31:44Z",
  "recovered_at": "2026-05-29T12:48:00Z",
  "affected_tenant_ids": ["ten_123", "ten_456"],
  "linked_request_ids": ["req_a", "req_b", "req_c"],
  "credit_policy_version": "sla_2026_04",
  "credit_status": "pending_reconciliation"
}

プロバイダーのインシデント時間とテナントの影響時間は別のフィールドです。プロバイダーは 11:30 から 13:00 までの大規模なインシデントを報告する可能性がありますが、許可されたモデルが別のプロバイダーを使用していたため、1 つのテナントは影響を受けなかった可能性があります。別のテナントでは、ルーティングによってフォールバック モデルに移行されたため、11:47 から 12:18 までの間だけ障害が発生した可能性があります。 3 番目のケースでは、待ち時間は長くなりましたが、リクエストの失敗は発生しなかった可能性があります。クレジットがお金になるとき、これらの違いは重要です。

3 つの証拠ストリームを取り込む

1.プロバイダー ステータス API

インシデント中に、スケジュールに基づいてオンデマンドでプロバイダーのステータス データを収集します。生のペイロード ハッシュ、取得時間、プロバイダー コンポーネントの識別子、インシデントの状態、インシデントの URL またはプロバイダーの参照、およびテキストの概要を保存します。古い状態を上書きしないでください。インシデントが調査から特定、監視に移行する場合は、それぞれの移行を保存します。

プロバイダ コンポーネントを独自のゲートウェイ ディメンションに正規化します:

• プロバイダー: OpenAI、Anthropic、Azure OpenAI、Google、または別のアップストリーム
• 表面: チャット、応答、埋め込み、画像、バッチ、オーディオ、リアルタイム、ファイル、モデレーション
• モデルまたはデプロイ: アップストリーム モデル、内部エイリアス、またはクラウド デプロイ名
• 地域: 該当する場合
• アカウントまたは資格情報プール: 共有アカウント、テナントにバインドされたアカウント、または BYOK 資格情報
• サービス階層: 標準、優先、プロビジョニング、バッチ、または内部階層名

トレードオフ: プロバイダー ステータスの取り込みは低コストで信頼性が高く、承認が可能ですが、遅れたり、範囲が広かったり、不完全だったりする可能性があります。疑惑を引き起こし、顧客とのコミュニケーションに役立ちますが、自動的にクレジットを生成するべきではありません。

2.合成カナリア

合成カナリアは、運用トラフィックと同じゲートウェイ パスを介して送信される、小規模で制御されたリクエストです。考えられるすべてのプロバイダー機能ではなく、販売する組み合わせをカバーする必要があります。たとえば、リセラーは、有料プランで使用されるプロバイダー、サーフェス、モデル層、およびリージョンごとにカナリアを実行する場合があります。

各カナリア結果には次のものが含まれている必要があります:

• canary_id とスケジュール バージョン
• プロバイダー、サーフェス、モデル、リージョン、認証情報プール、およびルート プロファイル
• 開始時間、最初のバイト時間、完了時間、およびタイムアウトしきい値
• HTTP ステータス、プロバイダー エラー コード、ゲートウェイ エラー コード、および再試行回数
• 合格か不合格かだけではないレイテンシ パーセンタイル バケット
• リクエスト相関 ID と編集されたレスポンス メタデータ

カナリア諸島は顧客からの生のプロンプトを避ける必要があります。固定された非機密プロンプトを使用し、応答の検証をシンプルに保ちます。カナリアは、エンドポイントがリクエストを受け入れ、ストリームが完了し、遅延がしきい値内に収まっていることを検証できます。停止クレジットを決定するためにモデルの品質を判断する必要はありません。

トレードオフ: カナリアは、顧客が問題を報告する前に独立した証拠を提供します。また、コストが追加され、プロバイダーにストレスがかかるとクォータが消費される可能性があります。アクティブなインシデントの間はカナリアを抑制し、アップストリームの負荷につながる積極的な再試行動作を回避します。

3.実際のリクエストの症状

リクエストレベルの証拠は、テナントへの影響の最も強力な情報源です。すべてのゲートウェイ リクエストには、テナント、キー、ユーザーまたはエンド ユーザーの識別子、モデル エイリアス、プロバイダー ルート、リージョン、ステータス、遅延、トークンの使用状況、および請求状態がすでに含まれている必要があります。停止レポートの場合は、アップストリームの症状と顧客およびゲートウェイの原因を区別する分類フィールドを追加します。

役立つ症状のクラスには次のものがあります:

• provider_5xx: アップストリーム HTTP 5XX または同等のプロバイダー サーバー エラー
• provider_timeout: ゲートウェイのタイムアウト前にプロバイダーの応答がありません
• provider_429_spike: 通常のベースラインを超えるアップストリーム レート制限
• stream_abort_upstream: プロバイダー ストリームが予期せず終了しました
• latency_degraded: 完了したリクエストがポリシーのしきい値を超えました
• gateway_throttle: テナント制限または公平性ポリシーにより、ゲートウェイがリクエストを拒否しました
• customer_error: 無効なリクエスト、サポートされていないモデル、不正な認証、または不正な形式のペイロード
• budget_exhausted: テナントの支出またはクレジット制限により発送がブロックされました

通常、最初の 5 つだけが停止症状としてカウントされますが、その場合でも原因が判明した後にのみカウントされます。アップストリーム 429 の急増はプロバイダーの問題である可能性がありますが、1 つのテナントが予約されたスループットを超えていることが原因である可能性もあります。タイムアウトはプロバイダの機能低下が原因である可能性がありますが、クライアントの切断や、ゲートウェイのタイムアウトよりも短いアプリケーション レベルのタイムアウトによって発生することもあります。

これは、チーム用のマルチモデル API ゲートウェイに規律あるイベント モデリングが必要な場合です。ルート決定、再試行、フォールバック結果、最終応答、および請求決済は、相関 ID によって結合できる必要があります。

プロバイダー インシデント ウィンドウをテナント影響ウィンドウから分離する

プロバイダーによる広範なインシデント期間を顧客にクレジットしないでください。あなたのポリシーに基づいて対象となるトラフィックに影響を与えたインシデントの部分について、彼らの功績を認めてください。

少なくとも 5 つのウィンドウ マーカーを使用します:

• 検出時刻: システムが異常な動作を最初に検出した時刻
• 最初に影響を受けたリクエスト: 停止の症状がある最初の対象となるテナント リクエスト
• プロバイダーの確認時刻: 上流のプロバイダーがインシデントを公開または確認したとき
• 緩和時間: ゲートウェイがフォールバック、トラフィック シェーピング、ルートの無効化、または別の緩和策を適用したとき
• 回復の確認: カナリアと実際のトラフィックがしきい値を下回った場合

テナントの影響ウィンドウは、テナントごと、キーごと、モデル エイリアスごと、およびサービス層ごとに計算できます。例:

tenant_id: ten_123
model_alias: support-fast
eligible_requests: 842
failed_provider_requests: 96
degraded_latency_requests: 211
first_affected_at: 2026-05-29T11:47:08Z
last_affected_at: 2026-05-29T12:22:31Z
mitigation_applied_at: 2026-05-29T12:04:19Z
credit_status: provisional

この分離により、過剰なクレジットも防止されます。プロバイダーのインシデント中にテナントにトラフィックがなかった場合、クレジットがない可能性があります。テナントが影響を受けないモデルのみにルーティングされている場合、クレジットがない可能性があります。すべての失敗が無効なリクエストまたは予算の拒否であった場合、インシデント レポートにはプロバイダーを責めることなくその旨を記載する必要があります。

事件の前に信用ポリシーを定義する

クレジット ポリシーはテーブルまたはバージョン管理された構成である必要があり、圧力を受けて即席でサポートを判断するものではありません。ポリシーは完全に自動である必要はありませんが、資格と承認のルールを明示する必要があります。

次のフィールドを含めます:

• 対象となる症状: プロバイダー 5XX、アップストリーム タイムアウト、ストリームの中断、重大な遅延の低下、またはその他のクラス
• 最小期間: たとえば、連続 5 分間、または影響を受けるリクエストのしきい値数
• レイテンシーしきい値: 固定しきい値、パーセンタイル ベースライン、またはサービス層固有のターゲット
• 除外される原因: 顧客のエラー、予算の枯渇、テナントのスロットル、不正な形式のリクエスト、サポートされていないモデル、クライアントの切断
• 再試行処理: 成功したフォールバック リクエストが失敗、低下、または緩和としてカウントされるかどうか
• クレジットの式: 影響を受ける使用量の割合、固定ウォレット調整、プランベースの SLA クレジット、または手動レビュー
• 承認権限: 制限未満では自動、制限を超えると運用の承認、大規模テナントの財務の承認
• プロバイダー クレジットの処理: 顧客クレジットとは別にパススルー、共有、保持、または個別に処理されます
• 証拠の保持: インシデント、リクエスト、カナリア、信用記録が照会可能な期間

推奨事項: 暫定および最終の信用決定ごとに信用ポリシーのバージョンを保存します。後でポリシーを改訂する場合でも、その時点でどのルールが適用されていたかを過去の決定によって説明する必要があります。

最終クレジットの前に調整

インシデント発生中、顧客はステータスを迅速に更新する必要があります。信用決定は暫定的なものになる可能性があります。最終的なクレジット パスは、ログが完了し、遅延した使用状況イベントが解決し、再試行とフォールバックが分類され、プロバイダーのインシデント後の情報がレビューされた後に行われる必要があります。

実際の調整ワークフローは次のようになります:

1. プロバイダーのステータス、カナリア アラート、またはリクエストの症状のしきい値からインシデント レコードを作成または更新します。
2. 影響を受けるルート プロファイルを凍結するか、劣化としてマークして、新しいルーティング決定で可能な限り回避できるようにします。
3. リクエスト ログとカナリア タイムラインから暫定テナントの影響ウィンドウを生成します。
4. 分類ルールを使用して顧客側とゲートウェイ側の原因を除外します。
5. 使用状況と請求の記録を結合して、影響を受けるリクエストを決済済みの費用と顧客請求の記録に結び付けます。
6. クレジット ポリシーのバージョンを適用し、暫定的なクレジット行を生成します。
7. あいまいなケース、特に部分的なレイテンシの低下や価値の高いテナントを確認します。
8. インシデント記録へのリンクを使用して、最終的なクレジット調整をウォレットまたは請求書台帳に投稿します。

これにより、サポート チケットに手動メモとしてクレジットを残すのではなく、停止処理が 統合 AI API 請求に関連付けられます。調整は、誰が承認したか、どのポリシーが適用されたか、どのリクエストが適格であったか、調整が最終的なものであるか、元に戻せるものであるかなど、監査可能である必要があります。

顧客とパートナー API ビューを公開

顧客は、社内のトレース ストア全体ではなく、インシデントの明確な説明を必要としています。 API を再販または埋め込む下流プラットフォームも、独自のポータル内にインシデント ステータスを表示する必要がある場合があります。パートナー API エンドポイントは、テナント スコープのインシデント ビューを公開できます。

GET /partner/incidents/{incident_id}/tenant-impact?tenant_id=ten_123

{
  "incident_id": "inc_2026_05_29_openai_azure_eastus_latency",
  "status": "final",
  "summary": "Elevated upstream latency and intermittent failures affected selected chat requests.",
  "affected_windows": [
    {
      "model_alias": "support-fast",
      "first_affected_at": "2026-05-29T11:47:08Z",
      "last_affected_at": "2026-05-29T12:22:31Z",
      "eligible_failed_requests": 96,
      "eligible_degraded_requests": 211
    }
  ],
  "affected_keys": ["key_live_abc"],
  "credit_status": "applied",
  "credit_adjustment_id": "adj_789",
  "evidence": {
    "canary_ids": ["canary_chat_eastus_01"],
    "sample_request_ids": ["req_a", "req_b"]
  }
}

このビューの範囲を限定してください。合成カナリア ID、リクエスト相関 ID、影響を受けるモデル、影響を受けるキー、および最終的なクレジット状態が含まれます。デフォルトでは、生のプロンプトと完全な応答本文を避けてください。顧客がより詳細な証拠を必要とする場合は、編集と承認チェックを備えた制御されたエクスポートを提供します。

顧客インシデント レポート テンプレート

台帳が完全であれば、有用な顧客レポートは短くても構いません。確認された事実と運用上の解釈を区別する必要があります。

事実

• 影響を受けるプロバイダーとサーフェス
• テナントの影響期間
• 対象となる失敗、タイムアウト、中止、または機能低下したリクエストの数
• 影響を受けるモデルのエイリアス、リージョン、顧客キー
• 緩和策の適用と回復の確認時間

ゲートウェイの評価

• 症状がプロバイダー、ゲートウェイ、テナント構成、または顧客のリクエスト動作に起因するかどうか
• フォールバック ルーティングによって影響が軽減されるかどうか
• インシデントが信用ポリシーのしきい値を満たしているかどうか
• クレジットが暫定、承認、適用、または拒否かどうか

制限

• プロバイダーのインシデントの詳細は、事後分析の公開後に変更される可能性があります
• レイテンシー低下のしきい値はポリシーによって定義されており、普遍的なものではありません
• 顧客エラーまたは予算の拒否として除外されたリクエストは、プロバイダーの停止の影響としてカウントされません

予測と設計上の賭け

予測: 顧客向けの停止レポートは、AI API 再販プラットフォーム、特に自社ブランドで AI 機能を公開している SaaS ベンダーの通常の機能になるでしょう。 AI ワークロードが実験から本番環境に移行するにつれて、顧客はクラウド インフラストラクチャ ベンダーから受けるのと同じインシデントの説明責任を期待するようになります。

予測: プロバイダーのステータス ページは引き続き必要ですが、不十分です。遅延の急増、ストリーミングの中断、地域の容量の問題、品質の低下、ツール呼び出しの失敗、アカウント固有のクォータ動作など、部分的な劣化を伴うインシデントがさらに多くなります。このようなケースでは、リクエスト レベルとテナント レベルの証拠が必要です。

推奨事項: 強力な SLA クレジットを約束する前に台帳を作成してください。係争中の停止後にインシデント証拠を改修するには費用がかかり、多くの場合決定的ではありません。

実用的な結論

プロバイダーのステータス ページが顧客クレジットの信頼できる唯一の情報源にならないようにしてください。プロバイダーのインシデント フィード、合成カナリア、リクエストの症状、ルート決定、テナントの影響期間、請求記録、および最終的なクレジット調整を結合する停止証拠台帳を構築します。

最小限の有用なバージョンは簡単です。プロバイダーのステータス JSON を取り込み、販売されたモデル リージョン層に対して少量のカナリアを実行し、リクエストの失敗を原因別に分類し、テナントの影響ウィンドウを計算し、調整後にバージョン管理されたクレジット ポリシーを適用します。これにより、サポート、財務、エンジニアリング、下流のパートナーに同じ証拠ベースが提供されます。また、上流のステータス ページをやみくもにミラーリングしたり、顧客が苦情を申し立てるたびに手動で善意のクレジットを発行したりすることなく、インシデントを説明することもできます。

関連資料

• 顧客向けの使用状況および調整レポート