AIプロバイダーが停止しても、ユーザーは影響を受けるべきではありません。 ShareAIの自動フェイルオーバー リクエストを流し続けるためにルーティングを行います 同じモデル 複数のプロバイダー間で—そのため、体験は一貫性を保ち、緊急パッチを出荷する必要がありません。また、 BYOI（独自のインフラを持ち込む） デフォルトとして、またはプライベートフェイルバック層としてプライベートエンドポイントを実行することもできます。
なぜ障害が痛手となるのか（そしてなぜ単一プロバイダー＝単一障害点なのか）
実際のインシデントパターン
障害はめったに すべてを 停止させることはありません。多くの場合、モデル固有の問題、レート制限の急増、地域的な停電、またはメンテナンスウィンドウが原因です。スタックが単一のAPIに固定されている場合、これらはユーザーに見えるバグとなります。
「再試行して祈る」ことの隠れたコスト“
ルーティングなしの再試行は、遅延を急増させ、クォータを消耗させ、放棄を増加させるだけです。ビジネスコストはSLA、解約率、サポート負荷に現れます。
ShareAIによる「同じモデルのフェイルオーバー」の意味
モデル同等のルーティング
もし model-x Provider Aで失敗し始めた場合、ShareAIは 同じモデル（または最も近い同等品） Provider Bにルーティングします—動作を一貫性のあるものに保つためのガードレール付き。この仕組みによりダウンタイムが ルーティングの決定, となり、製品の停止ではなくなります。
エンドユーザーや製品コードには見えません
あなたの統合は単一のエンドポイントを呼び出します。フェイルオーバーは制御プレーンで行われます—フィーチャーフラグも緊急再デプロイも不要です あなたのアプリに対して。
あなたの目標に合ったポリシー調整
エンドポイントごとのポリシーを設定可能、例えば レイテンシーを優先, コストを優先, 、または 厳密なプロバイダー順序. あなたがどの程度積極的にフェイルオーバーするか、そして誰に対して行うかを決定します。
本番環境でShareAIを使用する2つの方法
デフォルトのオーケストレーション層（常時稼働のマルチプロバイダー）
すべてのリクエストをShareAI経由で送信します。ヘルスチェック、同一モデルルーティング、プロバイダーのA/Bテストがすぐに利用可能です。 モデルマーケットプレイス プライマリとバックアップを選択するために： モデルを閲覧
ドロップイン安全ネット（インシデント時のみ）
現在のSDKを維持しながら、ShareAIを接続します。 フォールバックパス. プライマリが失敗した場合、ユーザーに見える形での中断なしに自動的にShareAIにトラフィックを切り替えます。
機能ごとのルーティング
例：チャットはデフォルトでプロバイダーXを使用し、埋め込みは価格のためにプロバイダーYを使用します。どちらもバックアップへの自動フェイルオーバーを備えています。
ShareAIを使用したBYOI（独自インフラの持ち込み）
プライベート推論を接続
自己ホスト型エンドポイント（VPC、オンプレミス、パートナーPOP）を接続します。BYOIを使用して 主な容量 またはとして プライベートフォールバック あなたの組織だけが見ることができる層。以下から始めてください プロバイダーガイド とダッシュボード： プロバイダーガイド • 10. プロバイダーダッシュボードを通じて
キー、クォータ、トラフィック分割
モデルごとに複数のAPIキー（およびプロバイダー）を添付し、環境/チームごとにクォータとトラフィックシェアを定義します。
地域とデータ居住性
許可された地域にトラフィックを固定するか、以下を通じて新しい地域をリクエストします ジオロケーション設定 コンプライアンスと遅延目標を満たすために： ジオロケーション設定
自動フェイルオーバーの仕組み（内部動作）
ヘルス＆レイテンシープローブ
ShareAIはプロバイダー/モデル/地域のヘルスとレイテンシーを継続的にチェックします。しきい値が作動すると サーキットブレーカーを使用して トラフィックが即座にシフトします。
モデル同等性マップ
キュレーションされたマップは、プロバイダー間でモデルIDを整合させ（「最も近い同等」を評価）、フェイルオーバーが指示に従う動作、トークン化の癖、コンテキスト制限を可能な限り厳密に保持するようにします。
設計による安全なリトライ
冪等性キーと指数バックオフにより、重複作業を回避しつつ、テールレイテンシーを最小化します。
可観測性
あなたは確認できます トレース、フェイルオーバー理由、コスト/レイテンシーの差分 コンソールとログ内で。以下を読む ドキュメント より深い計測に準備ができたら： ドキュメントホーム
クイックスタート：最初の耐障害性リクエストを作成する
5ステップセットアップ
1. サインイン してAPIキーを作成します。 サインインまたはサインアップ • APIキーを作成
2. コンソールでモデルごとに プライマリ プロバイダーを選択します。
3. 追加 バックアップ プロバイダー（およびオプションのBYOIエンドポイント）。
4. 有効化 同一モデルルーティング フォールバックポリシーを定義する（遅延/コスト/順序）。
5. 最初のリクエストを送信し（以下）、インシデントをシミュレートして自動フェイルオーバーを確認します。
コード：1つのリクエスト、自動プロバイダーフェイルオーバー
JavaScript（fetch）
const res = await fetch("https://api.shareai.now/v1/chat/completions", {
method: "POST",
headers: {
Authorization: `Bearer ${process.env.SHAREAI_API_KEY}`,
"Content-Type": "application/json",
},
body: JSON.stringify({
// Pick your canonical model; ShareAI routes to same/closest across providers
model: "gpt-4.1-mini",
messages: [
{
role: "user",
content: "Summarize the key risks of single-provider AI.",
},
],
// Optional routing preferences per request:
// routing: { policy: "prefer_latency" } // or prefer_cost, provider_order
}),
});
const data = await res.json();
console.log(data);
Python（requests）
import os
import json
import requests
api_key = os.getenv("SHAREAI_API_KEY")
url = "https://api.shareai.now/v1/chat/completions"
payload = {
"model": "gpt-4.1-mini",
"messages": [
{"role": "user", "content": "Draft a status note for an AI provider incident."}
],
}
headers = {
"Authorization": f"Bearer {api_key}",
"Content-Type": "application/json",
}
resp = requests.post(url, headers=headers, json=payload)
print(resp.status_code)
print(resp.json())詳細な説明が必要ですか？始めるには APIリファレンス クイックスタート： APIリファレンス. 。またはライブで試してみてください プレイグラウンド （コードを書かずにフェイルオーバーポリシーを検証するのに最適）： プレイグラウンドを開く
インシデント中のスムーズな体験を維持
スマートタイムアウトと部分的な応答
失敗しやすいプロバイダーから迅速に切り替え、UXが対応可能であれば部分的な結果をストリームし、フォールバックで完了させます。
一般的なプロンプトをキャッシュする
静的なプロンプト（FAQ、定型的なシステムプロンプト）をキャッシュして、インシデント時に即座に提供します。
緊急性の低い作業をキューに入れてバッチ処理する
重いジョブ（例：要約）をバッチ処理し、健全な容量が戻り次第再開する—タスクを落とさずに。
透明性のあるコミュニケーション
プロバイダーのステータスと独自のルーティング状態に関連付けられたアプリ内バナーを追加します。読者を以下に誘導します。 リリース/変更履歴 振る舞いが変わった場合： リリースを見る
オンラインを維持しながら支出を管理する
コスト上限とフォールバック順序
設定する 最大倍率 バックアップ用（例：「≤1.2× プライマリ CPM」）。バックアップがこれを超える場合、次の最適な選択肢にルートします。
チームごとの予算とアラート
ワークスペース/プロジェクトごとに予算を適用し、フェイルオーバースパイクに関するアラートを設定して財務部門が驚かないようにします。
インシデント後のレポート
どれだけのトラフィックがフェイルオーバーしたか、理由、そしてコスト/遅延の差異を確認してポリシーを改善します。
プロバイダー間でもセキュリティとコンプライアンスを維持
地域固定: 必要に応じてデータを地域内に保持します。 ゼロ保持モード: 必要に応じてリクエストログを無効化します。 監査可能性: 規制環境向けにログとトレースをエクスポートします。プロバイダーの地理的条件と制御については、 ジオロケーション設定 コンソール内で確認してください: 許可された場所
よくある質問
ShareAIを特定のモデルIDに固定することはできますか？
はい—特定のプロバイダー+モデルIDにロックすることができます。または、完全に同一のモデルが利用できない場合は最も近い同等のフェイルオーバーを許可します。
完全に同一のモデルが存在しない場合はどうなりますか？
使用 最も近い同等の ポリシーを使用して、能力、コンテキストサイズ、コストに基づいて最も近いモデルを選択します。段階的に劣化するか、完全に停止するかを制御できます。
本番環境を停止せずにフェイルオーバーをテストするにはどうすればよいですか？
使用 プレイグラウンド またはステージングキーを使用してプロバイダーの障害をシミュレートします（例: 一時的に1つのプロバイダーをブロックリストに追加）し、トレースを確認します: プレイグラウンド
BYOIはパブリックインバウンドを必要としますか？
いいえ。実行できます プライベート/VPC エンドポイントを作成し、それらを組織内でのみ表示可能なプロバイダーとして登録します。まずは プロバイダーガイド: プロバイダーガイド
結論
障害は避けられません。 ShareAIの自動フェイルオーバー と BYOI, 、それが混乱を引き起こす必要はありません。ルートを 同じモデル プロバイダー間で切り替え、SLAを維持し、コストとコンプライアンスを制御します—アプリコードを変更することなく。プロバイダーが障害を起こした場合でも、ShareAIはオンラインを維持します。