信頼性アーキテクチャ

私たちは「安定性」を製品の最重要機能と位置づけています。本ページでは、それをどのように実現しているか、そして何か問題が起きたときに何が起こるかを説明します。

信頼性はなぜこれほど難しいのか？

公式 API に直接接続する開発者は、次のような問題に直面します。

• 地域ごとのレート制限 / 利用不可
• 単一の支払いチャネルやアカウントが凍結される
• モデルバージョン切り替え時の互換性問題
• ピーク時のキューイングと初回トークン遅延の急増

リレーサービスが単なる単純なプロキシであれば、これらの問題はそのまま素通しでユーザーに渡されるか、さらに悪化することさえあります。私たちのアプローチは、「上流は不安定である」という前提でシステムを設計することであり、それを例外として扱うことではありません。

私たちのマルチソースルーティングアーキテクチャ

すべての API 呼び出しについて、リクエストは以下の経路で処理されます。

コアメカニズム：

• マルチ上流プール：同じモデルの背後に複数の独立したチャネルを配置し、単一障害点を回避します
• ヘルスプロービング：各上流の成功率、初回トークン遅延、レート制限率を継続的に監視し、不健全なチャネルは自動的に重み付けを下げるか除外します
• 自動フェイルオーバー：プライマリチャネルが 5xx / レート制限 / タイムアウトを返した場合、リクエストはミリ秒単位でバックアップチャネルに切り替わり、通常はお客様側への影響はありません
• ストリーム中断の再接続：ストリーミング応答が途中で切断された場合、それをサポートするプロトコルでは再開を試みます

サービスレベル（SLA）

私たちの外部へのコミットメントは「実際に提供できるもの」に基づいており、空約束はしません。

Economy 階層は、最高のコストパフォーマンスを求め、時折の変動を許容できる個人開発者向けです。ビジネスに厳格な信頼性要件がある場合は、Enterprise 階層を選択するか、営業チームにお問い合わせのうえカスタムプランをご相談ください。

可用性の測定方法：

• 私たちは「LMU AI 側」でのリクエスト成功率のみをカウントし、ユーザー側のネットワーク問題、パラメータエラー、上流モデル自身によるコンテンツ拒否は除外します
• 60 秒未満の単一障害はカウントしません
• 月次レポートには、モデル別および時間帯別に分解した成功率と P95 遅延が含まれます

障害発生時に何が起こるか

短時間の揺らぎ（5 分未満）

• ルーティング層が自動的に上流を切り替え、告知は行いません
• ステータスページ にイベントが記録されます

単一上流の障害（1 時間未満）

• ルーティング層が切り替えを完了します。一部のユーザー / モデルに影響が見える場合は、ステータスページに掲載します
• Standard および Enterprise ユーザーにはメールで通知します

地域規模または複数上流への同時影響

• イベントはステータスページに固定表示され、定期的に更新されます
• Enterprise ユーザーには進捗をメールでリアルタイムに通知します
• イベント終了後 48 時間以内にポストモーテムを公開します

私たちが行わないこと

ユーザーに誤解を与えないため、現時点では以下を約束しません：

• ゼロ遅延・シームレスな切り替え：フェイルオーバーはミリ秒から秒単位の追加遅延を生じさせるため、完全にシームレスになることは決してありません
• クロスモデル互換性の補償：上流モデル自体が廃止された場合（例：あるモデルバージョンがプロバイダーによって提供終了になった場合）、私たちは別のモデルへ黙って切り替えるのではなく、告知を行います
• 無制限のリトライ：失敗したリクエストはポリシーに従って限られた回数だけリトライされるため、予期しない繰り返し呼び出しの料金を支払うことはありません

FAQ

最終更新：2026-09-10