AIは魔法ではありません。ソフトウェアです。ソフトウェアには故障があります。AIが機能しないときでも、ビジネスを継続させる方法をここにまとめました。
AIの稼働率の現実
| プロバイダー | 一般的な稼働率 | 停止頻度 |
|---|---|---|
| OpenAI | ~99.9% | 時間/年 |
| Anthropic | ~99.9% | 時間/年 |
| Google AI | ~99.95% | 時間/年 |
| 自社サーバー | 変動あり | 設定に依存 |
停止の原因
- トラフィックの急増:一度に多すぎるユーザーがアクセス
- インフラの故障:サーバー、ネットワークの問題
- 不具合のあるアップデート:プロバイダーによるバグのあるコードのデプロイ
- レート制限:使用量制限に達した
- モデルの廃止:旧モデルの提供終了
フォールバック戦略
| 戦略 | 実装方法 | 最適用途 |
|---|---|---|
| マルチプロバイダー | OpenAI + Anthropic | 高可用性 |
| キャッシュ | 一般的な回答を保存 | 繰り返されるクエリ |
| 有人バックアップ | スタッフが対応を引き継ぐ | 顧客対応 |
| シンプルなルール | ルールベースのフォールバック | 基本的な回答 |
| 再試行キュー | 後で再試行する | 緊急でないもの |
マルチプロバイダー構成
最高の回復力:
- プライマリ: OpenAI (例: GPT-4o)
- セカンダリ: Anthropic (Claude)
- フェイルオーバー:プライマリが失敗した時に自動切り替え
- テスト:定期的なフェイルオーバー訓練
グレースフル・デグラデーション（段階的な機能縮退）
スマートに失敗を処理する方法:
- 失敗を検知:APIがエラーまたはタイムアウトを返す
- ログを記録:分析のために記録する
- フォールバックを試行:セカンダリプロバイダーまたはキャッシュを使用
- ユーザーへのメッセージ:「問題が発生しています。代替手段を試行中...」
- すべてが失敗した場合:明確な制限メッセージを表示
ユーザーへのコミュニケーション
ユーザーに伝えるべきこと:
- 正直かつ安心させる内容:「問題が発生しています」
- 専門用語は避ける:「APIタイムアウト」とは言わない
- 代替案:「数分後に再度お試しください」
- 有人オプション:「お急ぎの場合はサポートまでご連絡ください」
AIのヘルスモニタリング
- レスポンスタイム:レイテンシを追跡し、遅延時にアラートを出す
- エラー率:失敗したリクエストを監視する
- プロバイダーのステータス:ステータスページを購読する
- ヘルスチェック:定期的なテストコール
監視すべきステータスページ
- OpenAI: status.openai.com
- Anthropic: status.anthropic.com
- Google Cloud: status.cloud.google.com
レート制限への対処
自爆的な停止:
- 制限を知る:1分あたりのリクエスト数
- バックオフの実装:制限に達したときは速度を落とす
- キューシステム:リクエストを消失させない
- ティアのアップグレード:継続的に制限に達する場合
ディザスタリカバリ（災害復旧）計画
- 文書化:各AIが失敗したときに何が起こるか
- 割り当て:誰が停止に対応するか
- コミュニケーション:事前に用意されたユーザー向けメッセージ
- テスト:月次の停止訓練
- レビュー:実際の停止後のポストモーテム（事後分析）
冗長化のコスト
| 戦略 | 追加コスト | 信頼性の向上 |
|---|---|---|
| マルチプロバイダー | +20-30% | 非常に高い |
| キャッシュ | 最小限 | 中程度 |
| 有人バックアップ | 人件費 | 高い |
| シンプルなルール | 最小限 | 低い |