AIゲートウェイのSLAは、最初のモデルインシデントが発生するまでは単純に見えるかもしれません。購入者は可用性のパーセンテージ、サポートアドレス、そしてゲートウェイがリクエストをルーティングするという約束を目にします。しかし、本番環境のチームは、どのエンドポイントが対象か、どの上流プロバイダーが失敗したか、フォールバックがモデル契約を変更したか、サポートが必要とする証拠は何か、そして救済措置が自動で行われるかといった、より難しい質問に答えなければなりません。
このAIゲートウェイSLAチェックリストを使用して、ベンダーの言葉を証拠ファイルに変えましょう。目標はスローガンで交渉することではありません。目標は、SLAが何をカバーし、何を除外するのか、ルーティングとフォールバックがどのように証明されるのか、そして更新前にチームが何をレビューすべきかを知ることです。
具体的にFlatkeyについては、2026年7月6日に確認された公開のサービスレベル契約では、対象範囲はFlatkeyが直接運営するホストされたダッシュボード、APIゲートウェイ、ルーティング、メータリング、およびアカウントサービスであると記載されています。対象エンドポイントに対して月間99.5%の可用性を目標とし、サードパーティのAIモデルプロバイダーの停止やプロバイダー側の障害は除外し、サポートのためにはリクエストID、タイムスタンプ、エラー、エンドポイント、アカウントのメールアドレス、影響の概要を顧客が送信するよう求め、別途書面による合意がない限り自動的なクレジットは作成しません。これを最初の証拠として扱い、本番トラフィックがそれに依存する前に、アカウント、トラフィッククラス、フォールバックポリシー、およびサポートプロセスを確認してください。
クイックアンサー：AIゲートウェイSLAに関する質問
| SLA領域 | 署名または更新前に尋ねること | 保持すべき証拠 | |---|---|---| | 対象サービス | どのダッシュボード、APIゲートウェイ、ルーティング、メータリング、アカウント、サポート機能が対象ですか？ | 現在のSLAのURL、契約スケジュール、エンドポイントリスト、日付入りのスクリーンショット。 | | 可用性の計算 | 可用性はベンダーの監視、顧客のプローブ、公開ステータス、または契約レポートによって測定されますか？ | 月次可用性レポート、プローブのログ、インシデントのエクスポート、計算方法。 | | サードパーティプロバイダー | 上流モデルの停止、レート制限、地域制限、モデルの変更、プロバイダー側の障害は除外されますか？ | プロバイダーのステータスリンク、モデルのエラーボディ、ルートログ、ベンダーの除外条項のテキスト。 | | ルーティング | 最初に試行されたモデル、プロバイダー、アカウント、リージョン、またはグループはどれですか？ | リクエストID、選択されたルート、モデルID、エンドポイントファミリー、キーの所有者、タイムスタンプ。 | | フォールバック | どのエラーがリトライ、フォールバック、キューイング、またはフェイルクローズの動作をトリガーしますか？ | フォールバックポリシー、ルートトレース、リトライ回数、最終的なモデル、承認された出力の証明。 | | サポート | どのような証拠を送信する必要があり、どの重要度パスが適用されますか？ | チケットテンプレート、リクエストID、エンドポイント、タイムスタンプ、エラー、影響の概要、応答タイムライン。 | | 救済措置 | サービスクレジットは自動ですか、ケースバイケースですか、それとも別途書面による合意がある場合のみですか？ | SLAの救済条項、契約修正、クレジット要求、財務承認。 | | 更新 | 次の契約期間前に何をレビューする必要がありますか？ | インシデント記録、フォールバックの例外、サポート結果、クォータイベント、価格変更、ルート承認。 |
実践的なAIゲートウェイSLAの答えはこれです：ゲートウェイの責任と上流プロバイダーの責任を分離し、その後ルートをテストすることです。購入者がルート、フォールバック、サポートチケット、月次可用性の証拠を検査できない場合、そのSLAは本番環境のガバナンスに対応できる状態ではありません。
ゲートウェイのアップタイムと上流モデルの可用性を分離する
最初のAIゲートウェイSLAの質問は、ベンダーがゲートウェイ、上流モデル、または完全なエンドユーザーの成果のいずれを約束しているかです。これらは異なるレイヤーです。
Flatkeyの現在の公開SLAでは、その分離が明確にされています。対象となるFlatkeyが運営するサービスはスコープ内ですが、サードパーティのモデルプロバイダー、プロバイダーの停止、プロバイダーのレート制限、ポリシーの変更、地域制限、モデルの動作、プロバイダー側の障害はSLAの対象外です。これはゲートウェイの購入において非常に一般的であるため、調達部門は単一のアップタイムパーセンテージを「すべてのモデルリクエストが成功する」と見なすべきではありません。
証拠ファイルでは、この分割を使用してください：
| レイヤー | 障害が発生する可能性のあるもの | 購入者の証拠 | |---|---|---| | クライアントとSDK | 不正なベースURL、不正なキー、サポートされていないエンドポイント、低すぎるタイムアウト、パーサーエラー。 | クライアント設定、SDKバージョン、リクエストボディ、タイムアウト、ローカルログ。 | | ゲートウェイ | 認証、ルーティング、メータリング、ゲートウェイエンドポイント、ダッシュボード、使用ログ、アカウントサービス。 | ゲートウェイSLA、リクエストID、ルートトレース、ステータス、使用記録、サポートチケット。 | | 上流プロバイダー | プロバイダーの停止、プロバイダーのクォータ、モデルの廃止、地域ブロック、ポリシーによる拒否、モデル固有の動作。 | プロバイダーのステータス、プロバイダーのクォータページ、上流のエラーボディ、モデルID、フォールバックの決定。 | | ビジネスワークフロー | ユーザーへの影響、キューの深さ、劣化した出力、内部目標の未達。 | インシデントのタイムライン、影響を受けたトラフィッククラス、顧客への影響の概要、ロールバックの決定。 |
ここが、AIゲートウェイSLAが運用可能になるポイントです。購入者は、月間のアップタイム数値だけでなく、ルートレベルのトレースを要求すべきです。
ルーティングとフォールバックに関する質問
ルーティングは、AIゲートウェイSLAの中で最も仕様が不十分になりがちな部分です。ゲートウェイは複数のモデルやプロバイダーをサポートするかもしれませんが、本番環境の信頼性は、各トラフィッククラスに対してどのルートが許可されていたかに依存します。
他のベンダーの公式ゲートウェイドキュメントは、詳細がなぜ重要かを示しています。VercelのAI Gatewayのドキュメントでは、ルーティング順序やフォールバック動作の制御を含む、プロバイダーのルーティングとモデルのフォールバックについて説明されています。そのモデルフォールバックのドキュメントには、プライマリモデルが失敗したり利用できなかったりした場合に、バックアップを順番に試すことができると記載されています。Pydantic AI Gatewayのドキュメントでは、優先度と重みがフェイルオーバーまたはロードバランシングを決定するルーティンググループについて説明されており、優先度の高いメンバーが利用できない、レート制限されている、またはエラーが発生した場合にフォールスルーが発生します。これらは有用なカテゴリの例であり、Flatkeyの保証ではありません。これらは、購入者がFlatkeyを含むあらゆるゲートウェイに対して尋ねるべき質問を示しています。
自動フォールバックを承認する前に、このルーティングテーブルを使用してください:
| 障害シグナル | デフォルトの購入者の質問 | 安全な証拠 | |---|---|---| | ゲートウェイ 401 または 403 | キー、アカウント、環境、またはポリシースコープが間違っていましたか？ | キー所有者、環境、認証エラー、およびポリシー拒否の記録。 | | モデルが見つかりません | リクエストされたモデルはこのアカウントの現在のカタログに存在しましたか？ | カタログの行、モデルID、エンドポイントファミリー、および公開日またはテスト日の証明。 | | プロバイダー 429 | このアカウント、リージョン、モデル、またはデプロイメントのクォータが使い果たされましたか？ | クォータページ、アップストリームのエラーボディ、retry-afterデータ、およびフォールバックポリシー。 | | プロバイダー 5xx またはタイムアウト | ゲートウェイはリトライ、同じモデルのルート切り替え、キューイング、またはフェイルクローズすべきですか？ | ルートトレース、リトライ回数、タイムアウトしきい値、最終結果、およびコスト記録。 | | コンテキスト制限またはサポートされていない入力 | バックアップモデルがコンテキスト、ツール、ビジョン、またはメディアの動作を変更する場合、フォールバックは許可されますか？ | モデル契約、機能テスト、承認済み出力チェック、およびプロダクトオーナーの承認。 | | ポリシーまたは安全性の拒否 | 別のプロバイダーが同じリクエストを受信することは許可されていますか？ | データ境界、プロバイダーの承認、プロンプトの分類、およびコンプライアンスの承認。 | | 不明な障害 | 停止条件は何ですか？ | インシデントランブック、最大試行回数、フェイルクローズルール、およびサポートエスカレーション。 |
最も強力なAIゲートウェイSLAの証拠は、開始ルート、フォールバックルール、最終ルート、および各遷移が発生した理由を明記したルートトレースです。
フォールバックは必ずしも信頼性の向上につながるわけではない
調達部門は、ゲートウェイに自動フォールバック機能があるかどうかをよく尋ねます。プラットフォームチームは、2つ目の質問で答えるべきです。「何にフォールバックするのか？」と。
承認済みの同じモデルに対して、あるアカウントから別のアカウントへの自動切り替えは合理的である場合があります。あるモデルファミリーから別のモデルファミリーへの切り替えは、品質、データ処理、レイテンシー、出力形式、ツールの動作、画像や動画のポリシー、およびコストを変更する可能性があります。隠れたフォールバックがインシデントを悪化させる可能性があるため、一部のトラフィックはフェイルクローズすべきです。
トラフィッククラスごとにフォールバックを定義します:
| トラフィッククラス | フォールバックの姿勢 | 理由 | |---|---|---| | 顧客チャット | 承認済みの同等ルートのみを使用するか、制御されたエラーを返す。 | ユーザー向けの品質と安全性は予測可能でなければならない。 | | 内部要約 | リトライ、キューイング、またはより低コストの承認済みルートを使用する。 | レイテンシーはコストと完了率と引き換えにできる。 | | 評価とベンチマーク | フェイルクローズする。 | 隠れたモデルの変更は比較データを破損させる。 | | 財務的に機密性の高いバッチジョブ | キューイングするか、フォールバック前に承認を要求する。 | リトライとバックアップモデルは支出を倍増させる可能性がある。 | | ツールを使用したエージェントワークフロー | ツールコールの動作がテストされた後にのみフォールバックする。 | ツールのスキーマとストリーミングの動作はプロバイダーによって異なる場合がある。 | | 規制対象または顧客分離トラフィック | バックアッププロバイダーとリージョンが事前承認されていない限り、フェイルクローズする。 | データ境界と調達の証拠は、自動完了よりも重要である。 |
これは購入者所有のテストです。同じプロンプトをプライマリルートと提案されたフォールバックルートの両方で実行し、レスポンスの形状、ログ、コスト、レイテンシー、承認済み出力、およびサポートの証拠を比較します。フォールバックの証拠が存在するまで、AIゲートウェイSLAを完全なものとして扱わないでください。
証拠パケットに関するサポートへの質問
Flatkeyの現在のSLAでは、お客様にアカウントのメールアドレス、影響を受けたエンドポイント、利用可能な場合はリクエストID、タイムスタンプ、エラーメッセージ、および影響の概要を添えてサポートに連絡するよう求めています。これは、あらゆるAIゲートウェイSLAのサポートプロセスにとって有用なテンプレートです。
ローンチ前に、これらのフィールドを含むサポートパケットを作成してください:
| フィールド | なぜ重要か | |---|---| | アカウントのメールアドレスとワークスペース | サポートが正しいテナント、キー、および資格を見つけるのに役立つ。 | | 影響を受けたエンドポイント | チャット、レスポンス、メッセージ、画像、動画、およびダッシュボードのインシデントを区別する。 | | リクエストID | アプリのログをゲートウェイおよびアップストリームのトレースに接続する。 | | タイムゾーン付きのタイムスタンプ | 月間の可用性とインシデントウィンドウがずれるのを防ぐ。 | | モデルIDとルートクラス | どのルートポリシーとプロバイダーファミリーが関与していたかを示す。 | | エラーメッセージとステータスコード | 認証、クォータ、タイムアウト、プロバイダー、およびパーサーの障害を区別する。 | | 影響の概要 | 影響を受けたユーザー、収益、ジョブ、キューの深さ、または内部ワークフローを説明する。 | | 顧客側のリトライ | 重複した試行がコストや負荷を増加させたかどうかを示す。 | | 必要なアクション | 診断、ルートの無効化、クレジットの見直し、または契約のフォローアップが必要かどうかを明確にする。 |
このサポートパケットを監査ログAI APIの使用状況プロセスにリンクしてください。インシデント後にリクエストIDとルートの証拠が利用できない場合、サポートプロセスは記憶力に頼る作業になってしまいます。
救済措置とクレジットに関する質問
AIゲートウェイSLAの救済措置のセクションは、購入者が実際に何を回復できるかを定義することが多いため重要です。クレジット条項のない99.5%の目標は、自動サービスクレジット、書面による通知要件、除外事項、および請求期限が定められたコミット済みSLAとは異なります。
Flatkeyの公開SLAには、別の書面による合意で異なる救済措置が提供されない限り、自動サービスクレジット、返金、違約金、または損害賠償の予定はないと記載されています。善意による調整、残高修正、またはサポートによる是正措置は、ユーザー契約および適用されるポリシーに基づき、ケースバイケースで処理されます。
だからといってSLAが使えないわけではありません。これは、調達部門が適切な質問をすべきであることを意味します:
- 公開されているSLAが契約のすべてですか、それとも別のエンタープライズ向けスケジュールがありますか？
- クレジットが存在する場合、請求期間はどのくらいですか？
- 顧客はどのような証拠を提出する必要がありますか？
- ゲートウェイがそのアップストリームを選択した場合でも、アップストリームプロバイダーの障害は除外されますか？
- 計画メンテナンスや緊急のセキュリティ対策は除外されますか？
- レイテンシー、モデル品質、スロットリング、フォールバックの動作は対象ですか、それとも可用性のみが対象ですか？
- 救済措置は、前払い残高、請求クレジット、返金、サポートによる修復、または契約解除権に適用されますか？
- 財務部門の誰が最終的な請求を承認しますか？
その答えは、AI APIベンダーリスク評価と同じベンダーファイルに記載されるべきです。法務部門と財務部門は、プラットフォームエンジニアがインシデントレビュー中に使用するのと同じ証拠を必要とします。
クォータ、レート制限、およびプロバイダー依存関係
アップストリームプロバイダーのクォータが使い果たされたためにリクエストが失敗した場合でも、AIゲートウェイのSLAは有効である可能性があります。これが、クォータの証拠をSLAレビューに含めるべき理由です。
MicrosoftのAzure OpenAIクォータドキュメントには、トークン/分およびリクエスト/分の制限が、リージョン、サブスクリプション、モデルまたはデプロイメントタイプごとに設定されていると記載されています。同様に、AWS Bedrockのドキュメントでは、チームはBedrockリソースのサービスクォータを参照するように指示されており、モデルの推論はトークン使用量クォータによって制御されると記されています。これらのプロバイダーに関する事実は、Flatkeyの約束ではありません。これらは、実際のインシデント中にフォールバックが利用可能かどうかを、アップストリームアカウントの構成が決定しうることを思い出させるものです。
これらのチェックをローンチファイルに追加してください：
| 依存関係チェック | 証拠 | |---|---| | アップストリームクォータのスコープ | リージョン、アカウントまたはサブスクリプション、モデル、デプロイメントタイプ、TPM/RPMまたはプロバイダーの同等物。 | | ゲートウェイクォータのスコープ | キー、チーム、環境、モデルグループ、予算上限、リセット期間。 | | リトライ予算 | 最大リトライ回数、ジッター/バックオフポリシー、コストガードレール。 | | フォールバック容量 | バックアップルートのクォータ、モデルの可用性、プロバイダーの承認。 | | スロットリングの動作 | エラーコード、retry-afterシグナル、サポートエスカレーション、ユーザー向けの処理。 |
クォータがルーティングと同じ所有者によって測定されていない場合、AIゲートウェイのSLAレビューは最も一般的な障害モードを見逃すことになります。つまり、ルートは存在するが、アカウントが本番トラフィックを吸収できないという状況です。
Flatkeyステージングレビュー
Flatkeyの場合、2026年7月6日にチェックされた公開製品の証明は、1つのAI APIゲートウェイ、1つのAPIキー、OpenAI互換のルーターベースURL https://router.flatkey.ai/v1、ダッシュボード指向の使用状況と請求の可視性、価格レビュー、およびルーティング関連のポジショニングをサポートしています。ライブ価格APIのスナップショットは、success: true、価格バージョンa42d372ccf0b5dd13ecf71203521f9d2、45のモデル行、48のベンダー、Anthropicメッセージ、Gemini generateContent、画像生成、OpenAIチャット補完、およびビデオのリクエストに対応したエンドポイントメタデータ、さらに行全体でavailableおよびunknown_failureの可用性状態を返しました。
これは日付の入った公開証拠としてのみ使用してください。これは、あなたのアカウントのSLA救済措置、サポートティア、ルートの成功、フォールバックの適格性、永続的なモデルの可用性、レイテンシー、コンプライアンスの範囲、またはアカウント固有の価格設定を証明するものではありません。
Flatkey AIゲートウェイのSLAステージングレビューには、以下を含めるべきです：
- 現在の価格ページを開き、正確なモデルまたはルートファミリーを選択します。
- アカウントまたはダッシュボードでモデル行とエンドポイントファミリーを確認します。
https://router.flatkey.ai/v1を介して低リスクのリクエストを実行します。- リクエストID、モデルID、エンドポイント、タイムスタンプ、ステータス、使用単位、コストの証拠、およびキーの所有者をキャプチャします。
- 承認された障害テストを1つ実行します：不正なモデル、クォータ境界、タイムアウト、または無効化されたフォールバック。
- ログのどこにサポートの証拠が表示されるかを確認します。
- どのトラフィッククラスがフォールバックでき、どれがフェイルクローズドでなければならないかを決定します。
- インシデントランブックにサポートパケットのフィールドを追加します。
- 現在のSLA、価格、ルートの証明、およびサポートパスをベンダーの証拠フォルダに保存します。
その証拠が存在すれば、プラットフォーム、調達、財務の各部門は、スクリーンショットから議論するのではなく、同じファイルを評価できます。
更新トリガーチェックリスト
AIゲートウェイのSLAを一度だけレビューしないでください。購入者ファイルが最新の状態に保たれるように、更新トリガーを追加してください。
| トリガー | 再確認する内容 | |---|---| | SLAページまたは契約の更新 | 範囲、除外事項、救済措置、サポートプロセス、連絡先詳細。 | | 新しいモデルファミリー | エンドポイント、プロバイダー、クォータ、データ境界、価格単位、フォールバックポリシー。 | | 新しい本番トラフィッククラス | フェイルオーバーの態勢、サポートの重要度、所有者の承認。 | | インシデントまたはニアミス | ルートトレース、サポートのタイムライン、ユーザーへの影響、コストへの影響、予防措置。 | | プロバイダーのクォータ変更 | バックアップ容量、スロットリングの動作、トラフィックの割り当て。 | | 価格変更 | リクエストレベルのコスト、リトライ予算、フォールバックモデルのコスト、財務のしきい値。 | | セキュリティまたはコンプライアンスのレビュー | ロギングの範囲、保持期間、プロバイダーの承認、アクセスレビュー。 |
このチェックリストをエンタープライズAI APIゲートウェイチェックリストに結びつけてください。SLAはエンタープライズの証拠パッケージの一部であり、独立した信頼の証ではありません。
よくある間違い
| 間違い | なぜ問題なのか | より良い確認方法 | |---|---|---| | ゲートウェイのアップタイム目標をモデル成功の保証として扱う | アップストリームプロバイダー、クォータ、ポリシー、モデルの動作は除外される可能性があります。 | ゲートウェイ、プロバイダー、クライアント、ビジネスワークフローの証拠を分割します。 | | フォールバックが存在するかどうかを尋ねるが、何に切り替わるかを尋ねない | バックアップモデルは、出力、データ境界、機能、コストを変更する可能性があります。 | トラフィッククラスとモデル契約によってフォールバックを承認します。 | | リクエストIDを保持しない | サポートは顧客ログとルートログを確実に接続できません。 | すべての本番ルートにリクエストIDのキャプチャを追加します。 | | クォータの範囲を無視する | バックアップルートは存在しても、ピークトラフィック中にスロットリングされる可能性があります。 | アップストリームとゲートウェイのクォータの証拠を一緒に保存します。 | | クレジットが自動的であると仮定する | 多くのSLAでは、別途の合意、請求プロセス、またはケースバイケースのレビューが必要です。 | 立ち上げ前に救済条件と請求所有者を保存します。 | | 購入時にのみレビューする | モデルカタログ、クォータ、サポートパスは変更されます。 | 更新トリガーとインシデント駆動の再確認を追加します。 |
よくある質問
AIゲートウェイSLAとは何ですか？
AIゲートウェイSLAは、ベンダーが運用するゲートウェイサービスの可用性目標、範囲、除外事項、サポートプロセス、および救済策を定義します。サードパーティのモデルプロバイダーの停止、クォータ制限、モデルの動作、顧客の設定、またはすべてのフォールバック結果をカバーしない場合があります。
AIゲートウェイSLAは、すべてのモデルリクエストが成功することを保証しますか？
いいえ。AIゲートウェイSLAは、ゲートウェイの可用性をカバーする一方で、アップストリームプロバイダーの障害、プロバイダーのレート制限、ポリシーの変更、モデルの動作、顧客の認証情報、計画メンテナンス、または顧客側の問題を除外することができます。除外テキストとルートの証拠を確認してください。
調達部門はモデルのフォールバックについて何を尋ねるべきですか？
調達部門は、どのエラーがフォールバックをトリガーするのか、どのモデルまたはプロバイダーが承認されたバックアップであるのか、フォールバックがデータ処理や出力の動作を変更するのか、再試行がどのように請求されるのか、インシデント後にルートの証拠がどこに保存されるのかを尋ねるべきです。
SLAインシデント中にサポートはどのような証拠を受け取るべきですか？
サポートは、アカウントのメールアドレス、影響を受けたエンドポイント、リクエストID、タイムスタンプ、エラーメッセージ、モデルID、ルートクラス、影響の概要、および顧客の再試行動作を受け取る必要があります。Flatkeyの公開SLAは現在、エンドポイント、リクエストID、タイムスタンプ、エラー、影響の概要など、これらのフィールドのいくつかを要求しています。
サービスクレジットは自動的に付与されますか？
必ずしもそうではありません。Flatkeyの公開SLAでは、別途書面による合意がない限り、自動的なサービスクレジット、返金、違約金、または損害賠償額は発生しないと記載されています。購入者は、救済条項、請求期限、および承認経路を確認する必要があります。
チームはどのくらいの頻度でAIゲートウェイSLAを見直すべきですか？
AIゲートウェイSLAは、購入時、更新時、主要なルート変更時、新しいモデルファミリーの導入時、新しい本番トラフィッククラスの導入時、価格変更時、クォータ変更時、およびすべての重大なインシデントまたはニアミスの後に見直してください。
最終的な推奨事項
AIゲートウェイSLAは、テスト可能になって初めて有用になります。公開または契約済みのSLAから始め、ゲートウェイの範囲をアップストリームプロバイダーの範囲から分離し、ルートおよびフォールバックテストを実行し、リクエストIDを保存し、サポートの証拠を定義し、更新トリガーを追加します。
Flatkeyは、チームがモデルアクセス、ルーティング、価格レビュー、および使用証拠を1つのゲートウェイワークフローの背後で一元化するのに役立ちます。本番環境への展開前に、アカウントの正確なモデル、エンドポイント、ルートの動作、サポートプロセス、およびSLAの証拠を確認してください。その後、実際のステージングトラフィックでAIゲートウェイSLAワークフローをテストする準備ができたら、キーを取得してください。
