AIリテラシー 可用性（Availability）

可用性（Availability）とは

可用性とは、認可されたユーザーが、必要な時にいつでも情報システムやサービスにアクセスし利用できる能力のことです。SLA（サービスレベル契約）の文脈では、一般的に「稼働率（Uptime Percentage）」として定義され、例えば「月間稼働率99.9%（ダウンタイム約43分以内）」といった数値目標が設定されます。

AIエージェントの場合、可用性は単に「サーバーが落ちていない」こと以上の意味を持ちます。核となるLLM API（OpenAIやAzureなど）の応答遅延、レート制限（Rate Limit）への到達、またはハルシネーションによる機能不全状態も含めて、ユーザーから見て「サービスとして機能しているか」が問われます。

AI特有の「レジリエンス」維持

監査においては、外部APIへの依存度が高いAIエージェントが、障害発生時にどのような挙動をするか（回復弾力性）を検証します。

• リトライ処理とバックオフ: 一時的なAPIエラーに対して、適切な間隔を空けて再試行するロジックが組み込まれているか。
• モデルのフォールバック: プライマリ（例: GPT-4）がダウンした場合、セカンダリ（例: GPT-3.5やClaude）に自動的に切り替えて最低限の機能を維持できるか。
• グレースフル・デグラデーション: AIが全停止しても、ルールベースのチャットボットや有人対応フォームに誘導するなど、サービスを完全に遮断しない設計になっているか。

実務での課題と対策

最も厄介なのは「サイレント障害」です。API自体は正常に応答している（HTTP 200 OK）ものの、生成される内容が無意味な文字列や空の回答であるケースです。これを検知するため、単純なPing監視だけでなく、定期的にテストプロンプトを送信し、回答内容の品質を簡易チェックする「シンセティック監視（外形監視）」の実装が推奨されます。

失敗例・トラブル事例

• レート制限によるサービス停止: ユーザー数が急増した際、LLMプロバイダーのトークン制限（RPM/TPM）に達してしまい、すべてのリクエストがエラー（429 Too Many Requests）となりました。クォータ管理と、ユーザーごとの利用制限（スロットリング）機能の実装漏れが原因です。
• 単一障害点（SPOF）の放置: 特定のモデルAPIに全面的に依存していたため、そのプロバイダーの大規模障害時にサービスが半日間完全に停止しました。マルチモデル対応をしておけば回避できたダウンタイムでした。

関連リンク

• Google SRE Book: Availability Table
• AWS Well-Architected Framework