低コストと高可用性を実現する最適なマルチプロバイダーLLMサービスとは？

マルチプロバイダーLLMサービスにおける「高可用性」の意味
マルチプロバイダーLLMサービスのSLO設計
プロバイダー健全性監視基準
プロバイダー劣化のためのアラートアーキテクチャ
マルチプロバイダーLLMサービスのインシデントプレイブック
フォールバックポリシーガバナンス
Novita AIがマルチプロバイダーアップタイム運用をどのようにサポートするか
本番稼働前の運用準備チェックリスト
FAQ
おすすめ記事

低コストと高可用性を実現する最適なマルチプロバイダーLLMサービスとは、適切なルーティングアーキテクチャと明確な運用プラクティス（定義されたSLO、継続的なプロバイダー健全性監視、テスト済みインシデントプレイブック、管理されたフォールバックポリシー）を組み合わせたものです。ルーティング設計が利用可能なモデルを決定します。運用は、そのルーティングが導入された後、サービスが実際にアップタイムコミットメントを満たすかどうかを決定します。

この記事では、運用レイヤーに焦点を当てます。ルーティング設計自体（フォールバックポリシー、コスト層別モデル選択、サーキットブレーカー、リトライ予算）については、低コストとダウンタイムを実現する最適なマルチプロバイダーLLMプラットフォームを参照してください。

マルチプロバイダーLLMサービスにおける「高可用性」の意味

LLMサービスのアップタイムは、サーバー可用性と同じではありません。プロバイダーのステータスページが「正常」を示していても、ユーザーがレイテンシの増加、出力品質の低下、またはエージェントワークフローでのサイレントな部分障害を経験している可能性があります。

マルチプロバイダーLLMサービスにおける実用的なアップタイムSLOは、以下をカバーする必要があります。

成功完了率: レイテンシ予算内で有効で使用可能な応答を返すLLMリクエストの割合
最初のトークンまでの時間（P95）: 平均レイテンシだけでなく、インタラクティブユーザーが経験するレイテンシ
エージェントワークフロー完了率: エージェント型ワークロードにおいて、正常な終了状態に達したマルチステップジョブの割合
タスク成功あたりのコスト: リトライ、フォールバック、または長い出力が正常な完了を増やさずに支出を膨らませた場合に上昇する効率シグナル

サービスが99.9%のサーバー可用性を持っていても、モデルの劣化、レート制限の枯渇、またはサンドボックス障害がサイレントエラーを引き起こす場合、ユーザーから見えるアップタイムSLOを達成できない可能性があります。

マルチプロバイダーLLMサービスのSLO設計

ワークロードクラスごとにSLOを定義し、プロバイダーごとには定義しない

プロバイダーの信頼性は、モデル、リージョン、ティアによって異なります。SLO目標は、プロバイダーレベルではなく、ワークロードクラスレベル（ユーザー向け操作）で定義します。

ワークロードクラス	SLO目標の例	エラーバジェット（30日間）
インタラクティブチャット（P95レイテンシ ≤ 2秒）	99.5% 成功完了率	3.6時間
エージェントワークフロー完了	99.0% ジョブが終了状態に到達	7.2時間
バッチ抽出 / 分類	99.9% SLAウィンドウ内で完了	43分
ストリーミング生成（P95 TTFT ≤ 1秒）	99.0% リクエストがTTFT予算を満たす	7.2時間

ワークロードクラスSLOにより、エラーバジェットを正確に割り当てることができます。インシデントがインタラクティブチャットのバジェットを消費してもバッチバジェットを消費しない場合、信頼性作業をどこに集中すべきかがわかります。

可用性SLOと品質SLOを分離する

マルチプロバイダーシステムは、高可用性（リクエストが応答を受信する）を維持しながら、品質が低下する（フォールバックモデルが弱い回答を生成する）可能性があります。両方を追跡します。

可用性SLO: レイテンシ予算内での非エラー応答率
品質SLO: 最低品質しきい値（人間によるラベル付け、自動評価、ユーザーの低評価率）を満たす応答の割合

インシデント中にフォールバックルートがアクティブになった場合、品質SLOバーンレートは、低下モードが許容可能か、システムがキューイングまたは停止すべきかを示すシグナルです。

プロバイダー健全性監視基準

効果的なマルチプロバイダー監視は、プロバイダーのステータスページだけを監視するものではありません。観測されたトラフィックから独自の健全性シグナルを構築します。

シグナル	測定内容	アラートしきい値の例
プロバイダー + モデル別エラー率	1分あたりの4xx/5xx応答数	5分間のウィンドウで > 5%
プロバイダー + モデル別P95レイテンシ	最初のトークンまでの時間、合計完了時間	3分連続でベースラインの2倍以上
レート制限ヒット率	リクエストに占める429応答の割合	2分間のウィンドウで > 2%
フォールバックアクティベーション率	セカンダリモデルにルーティングされたリクエスト	5分間持続して > 10%（プライマリの劣化を示す可能性あり）
エージェントワークフロー障害率	終了状態に達しなかったマルチステップジョブ	10分間のウィンドウで > 1%
タスク成功あたりのコスト	(入力トークン + 出力トークン) × 料金 / 成功完了数	7日間のベースラインより20%以上
品質スコアのドリフト	自動評価合格率またはユーザーのネガティブフィードバック率	7日間のベースラインから15%以上の相対的低下

Novita AI LLM APIを使用するチームの場合、OpenAI互換チャット補完エンドポイントは、これらのシグナルに直接供給できる標準HTTPステータスコードとレイテンシヘッダーを返します。すべてのリクエストでモデルID、プロバイダーパス、リトライ回数をログに記録し、監視がエンドポイントレベルだけでなくモデル固有であることを確認します。

すべてのLLMリクエストログで出力すべき項目

{
  "request_id": "req_abc123",
  "workload_class": "interactive_chat",
  "primary_model": "meta-llama/llama-3.1-70b-instruct",
  "routed_model": "meta-llama/llama-3.1-8b-instruct",
  "route_reason": "primary_rate_limited",
  "provider": "novita",
  "latency_ms": 1240,
  "ttft_ms": 380,
  "input_tokens": 512,
  "output_tokens": 148,
  "retry_count": 1,
  "status": "success",
  "quality_eval": "pass",
  "cost_usd": 0.00031
}

route_reasonは、ほとんどのチームが省略するフィールドです。これがないと、ダッシュボードで正常なフォールバック（想定内の動作）と劣化したフォールバック（プロバイダーインシデント）を区別できません。

プロバイダー劣化のためのアラートアーキテクチャ

アラートは2つのレベルで発生する必要があります。戦術的（オンコールエンジニアが今すぐ行動）と戦略的（ルーティングポリシーの変更が必要なトレンド）です。

戦術的アラート（オンコールエンジニアにページング）

プロダクションワークロードクラスでプロバイダーエラー率が5分間で5%を超える
インタラクティブチャットでP95レイテンシが3分連続でベースラインの2倍を超える
エージェントワークフロー障害率が10分間で1%を超える
品質SLOバーンレートが1時間で月間エラーバジェットの5%を超える

戦略的アラート（Slackチャンネル、ページングなし）

フォールバックアクティベーション率が30分間持続して10%を超える（ルーティングポリシーの調整が必要な可能性あり）
タスク成功あたりのコストが2時間で7日間ベースラインより20%以上高い
プライマリモデルのレート制限ヒットが24時間で増加傾向（キャパシティプランニングのシグナル）
品質スコアドリフトアラート：バックアップモデルの品質が7日間のウィンドウで低下

ワークロードクラス別のアラートルーティング

すべてのアラートを同じチャンネルに送信しないでください。適切なチームが行動できるように、ワークロードクラスごとに戦術的アラートをルーティングします。内部コパイロットの429スパイクは、顧客向けエージェントワークフローでの同じスパイクよりも優先度の低いイベントです。

マルチプロバイダーLLMサービスのインシデントプレイブック

ルーティングポリシーは自動的に何を行うかを決定します。インシデントプレイブックは、自動動作では不十分な場合やインシデントが曖昧な場合に、オンコールエンジニアをガイドします。

プレイブック：プライマリプロバイダーのエラー率上昇

トリガー: プロダクションワークロードクラスでプライマリモデルエラー率 > 5% が5分間継続。

確認: プロバイダーのステータスページと自身のエラーログを確認します。一時的なスパイクと持続的な劣化を区別します。
影響評価: 影響を受けるワークロードクラスはいくつですか？フォールバックモデルはすでにアクティブで、品質SLOを満たしていますか？
フォールバックがアクティブで品質SLOを満たしている場合: 復旧を監視します。30分後のレビューチェックポイントを設定します。
フォールバックはアクティブだが品質SLOが燃焼している場合: 高リスクワークロード（法務、財務、安全重視）をキューまたは手動保留に移動します。関係者に通知します。
フォールバックが利用できない場合: 低下モードをアクティブにします（ユーザーに表示される通知、緊急でないリクエストはキューイング）。インシデントコマンダーにエスカレーションします。
復旧: プライマリエラー率が10分間1%未満に戻ったら、徐々にトラフィックを戻します。すべてのトラフィックを一度に切り替えないでください。
インシデント後: インシデント期間、影響を受けたワークロードクラス、品質SLOの燃焼、コスト影響、および発見されたフォールバックポリシーのギャップを記録します。

プレイブック：レート制限の枯渇

トリガー: プライマリモデルの429レートが2分間で2%を超える。

クォータダッシュボードを確認: これは持続的なキャパシティ問題ですか、それともトラフィックスパイクですか？
スパイクの場合: バックオフとリトライ予算をアクティブにします。対象ワークロードのオーバーフローをセカンダリモデルティアにルーティングします。
持続的な場合: 優先度の低いワークロードに対してリクエストキューイングを実装します。予測可能な高トラフィックワークロードを専用エンドポイントに移動することを検討します。Novita AI GPU Cloudまたは専用LLMエンドポイントは、共有APIレート制限を超えたワークロードに対して、より予測可能なキャパシティを提供できます。
無制限にリトライしない: リトライ予算を適用します。各429をワークロードクラスとモデルとともにログに記録し、どの呼び出しパターンが最も影響を受けているかを特定します。

プレイブック：エージェントワークフロー障害の急増

トリガー: エージェントワークフロー障害率 > 1% が10分間継続。

障害タイプを区別: 障害はLLM呼び出し（モデルエラー、レート制限、コンテキストオーバーフロー）ですか、それとも実行レイヤー（サンドボックスタイムアウト、ツール呼び出しの不正な出力、ファイル操作エラー）ですか？
LLMレイヤーの障害の場合: 上記のプライマリプロバイダーエラー率プレイブックに従います。
サンドボックスまたは実行障害の場合: Novita Agent Sandboxのログを確認します。問題が体系的なものか（不正なツール呼び出しを引き起こす悪いプロンプトテンプレート）、環境的なものか（サンドボックスキャパシティ、ネットワークタイムアウト）を特定します。
影響を受けるワークフロータイプを分離: ブラウザ自動化の障害は、独立している場合、コード実行ワークフローの停止をトリガーするべきではありません。
復旧ゲート: 完全なトラフィックを復元する前に、影響を受けるワークフローを通じて代表的なゴールデンプロンプトのセットを実行し、障害率がベースラインに戻ったことを確認します。

プレイブック：フォールバック中の品質SLO低下

トリガー: フォールバックモデルがアクティブな間に、品質スコアが7日間ベースラインから15%以上低下。

影響を受けるワークロードクラスを特定: 品質低下は多くの場合、ワークロード固有です。フォールバックモデルは単純な分類をうまく処理できても、長文推論では低下する可能性があります。
ワークロードクラス固有のフォールバック制限を適用: 品質低下が許容されるワークロードにのみ、低下したフォールバックを制限します。高リスクタスクはキューイングまたは停止します。
顧客向けの影響について関係者に通知 します。
インシデント後: バックアップモデルで観測された品質制限を反映するように、フォールバック承認マトリックスを更新します。

フォールバックポリシーガバナンス

ルーティングポリシーは、どのフォールバックモデルが利用可能かを決定します。ガバナンスは、どのフォールバックが各ワークロードクラスに対して承認されているか、そして自動フォールバックがまったく発生すべきでない場合を決定します。

フォールバック承認マトリックス

ワークロードクラスごとに文書化されたフォールバック承認マトリックスを維持します。

ワークロードクラス	プライマリモデル	承認されたフォールバック	条件	禁止フォールバック
カスタマーチャット	モデルA（大）	モデルB（中）	ゴールデンセットでの品質評価合格	承認リストにないモデル
内部コパイロット	モデルA（大）	モデルB（中）、モデルC（小）	品質評価合格	なし
法務 / コンプライアンス文書	モデルA（大）	キューイングのみ	自動フォールバックなし	より小さいモデル
バッチ分類	モデルC（小）	モデルD（代替プロバイダー）	品質評価合格	大規模モデル（コスト管理）
ブラウザエージェント	モデルA（大）+ サンドボックス	キューイング	サンドボックス実行が確認されている必要あり	ツールサポートなしのテキストのみモデル

このマトリックスは毎月、およびフォールバック動作が予期せぬものであったり不適切であったインシデントの後にレビューします。

フォールバックポリシーの変更は誰が所有するか？

フォールバックポリシーの変更には、エンジニアリングチーム（システムが変更をサポートできるか？）とプロダクトまたはリスクチーム（品質のトレードオフは許容可能か？）の両方からの承認が必要です。品質基準に関する人間の承認なしに安価なモデルに自動的に切り替えるルーティングシステムは、サイレントなプロダクトリスクを生み出します。

各変更を文書化します：どのモデル、どのワークロードクラス、実行された品質評価、承認者、ポリシーレビューをトリガーする条件。

Novita AIがマルチプロバイダーアップタイム運用をどのようにサポートするか

Novita AIは、AIおよびエージェントクラウド（LLM API、Agent Sandbox、GPU Cloud）として運営されており、チームはここで説明した種類の運用プラクティスを実装できます。

LLM APIは、すべてのリクエストで標準HTTPステータスコード、レイテンシヘッダー、トークン数を返し、プロバイダー健全性監視とSLO追跡のための生のシグナルを提供します。モデルライブラリは現在のモデル可用性を一覧表示し、実際にサポートされているモデルに対してルーティングポリシーを構築できます。OpenAI互換チャット補完APIにより、既存の可観測性ツール（リクエストロギング、レイテンシ追跡、エラー率ダッシュボード）がカスタムインストルメンテーションなしで動作します。

Novita Agent Sandboxは、エージェント型ワークフロー向けの管理された実行環境を追加します。同じワークフローログでLLM呼び出し結果とサンドボックス実行結果の両方を観察できる機能は、エージェントワークフロー障害プレイブックに直接関連します。モデル障害とサンドボックス実行障害を区別するには、両方のレイヤーからのログが必要です。

Novita AI GPU Cloudと専用エンドポイントは、共有APIレート制限が信頼性の制約となる場合に、チームに運用上のパスを提供します。429が繰り返し発生するインシデントトリガーとなるワークロードの場合、専用キャパシティに移行することで、共有API運用モデルからあるクラスのインシデントを排除できます。

本番稼働前の運用準備チェックリスト

マルチプロバイダーLLMサービスが運用準備完了かどうかを評価する際は、このチェックリストを使用します。

SLO定義

[ ] 各プロダクションワークロードクラスに対してSLO目標が定義されている（可用性 + 品質）
[ ] エラーバジェットが計算され文書化されている
[ ] 各SLOに対してバーンレートアラートが設定されている

監視

[ ] すべてのLLMリクエストがログに記録されている：モデル、プロバイダー、ルート理由、レイテンシ、トークン、リトライ回数、ステータス、品質評価結果
[ ] ダッシュボードがエラー率、P95レイテンシ、フォールバックアクティベーション率、タスク成功あたりのコストを表示 — ワークロードクラスごとに分類
[ ] プロバイダー健全性シグナルがステータスページだけでなく、観測されたトラフィックから導出されている

アラート

[ ] プロダクションワークロードクラスに対して戦術的アラート（ページング）が設定されている
[ ] コストドリフトとフォールバック率トレンドに対して戦略的アラート（Slack）が設定されている
[ ] アラートルーティングがワークロードクラスを所有チームにマッピングしている

インシデントプレイブック

[ ] プレイブックが作成されアクセス可能である：プライマリプロバイダーエラースパイク、レート制限枯渇、エージェントワークフロー障害、品質SLO低下
[ ] 各プレイブックに対して復旧ゲートが定義されている（完全なトラフィックを復元する前に真でなければならない条件）
[ ] インシデント後レビュープロセスが文書化されている

フォールバックガバナンス

[ ] フォールバック承認マトリックスが存在し最新である
[ ] 高リスクワークロードクラスに対して禁止フォールバック条件が文書化されている
[ ] ポリシー変更承認プロセスが定義されている（エンジニアリング + プロダクト/リスク）
[ ] 毎月のレビューが予定されている

インフラストラクチャのエスケープハッチ

[ ] 共有APIレート制限が繰り返しの制約となるワークロードに対して、専用エンドポイントまたはGPU Cloudパスが特定されている

FAQ

マルチプロバイダールーティング設計とマルチプロバイダー運用の違いは何ですか？

ルーティング設計はポリシーを決定します。どのモデルがプライマリでフォールバックか、いつリトライするか、特定のエラータイプをどのように処理するかです。運用は、ポリシーが機能していることを確認する継続的なプラクティスです。SLOの燃焼を監視し、機能していない場合にインシデントプレイブックを実行し、ポリシーへの変更を管理します。アップタイムコミットメントを確実に満たすサービスには、両方が必要です。

マルチプロバイダーLLMサービスに対して現実的なアップタイムSLOを設定するにはどうすればよいですか？

まず、代表的なトラフィックウィンドウにわたって現在の成功完了率とP95レイテンシを測定します。ルーティングポリシーが利用可能なエラーバジェットで現実的にサポートできるレベルにSLO目標を設定します。新しいサービスの場合、99.0%～99.5%の成功完了率は妥当な開始目標です。最初の数回のエラーバジェットウィンドウを観察した後に調整します。

フォールバック承認マトリックスはどのくらいの頻度でレビューすべきですか？

最低でも毎月、およびフォールバック動作が予期せぬものであったり、フォールバック中に品質が低下したインシデントの後には必ずレビューします。モデルの機能と価格は頻繁に変更されるため、第1四半期に有効なマトリックスが第3四半期には有効でない可能性があります。

マルチプロバイダーフォールバックを自動化すべきでないのはいつですか？

ワークロードクラスに安全性、法務、財務、コンプライアンスの機密性があり、フォールバックモデルがその特定のタスクタイプで評価されていない場合です。そのような場合、キューイングまたはユーザーに表示される利用不可状態は、低品質の自動応答よりも安全です。

Novita AIはこの運用モデルにどのように適合しますか？

Novita AIは、上記のプラクティスを使用してチームが計装および運用するインフラストラクチャレイヤー（推論用LLM API、エージェント実行用Agent Sandbox、専用キャパシティ用GPU Cloud）を提供します。サービスを信頼性の高いものにするSLO定義、監視構成、プレイブック、ガバナンス決定を置き換えるものではありません。これらはチームの運用プラクティスから生まれます。

低コストと高可用性を実現する最適なマルチプロバイダーLLMサービスとは？

マルチプロバイダーLLMサービスにおける「高可用性」の意味