AIシステムは従来のソフトウェアよりも脆弱です。なぜなら、最も不安定な要素である外部LLMやサードパーティAPIを主要な処理経路に組み込んでいるからです。これは杞憂ではありません。OpenAIのような大手プロバイダーであっても、常に公表通りの可用性を維持できているわけではなく、2025年6月には世界中のユーザーに影響した数時間規模の障害が発生しました。レート制限エラーも本番環境で頻発する障害要因の一つであり、AIワークフローが外部APIの呼び出しを増やすほど、こうしたエラーはさらに頻発するようになります。こうして状況を並べると、依存先の障害は稀な異常ではなく毎月遭遇する常態であることがわかります。信頼性を本当に左右するのは、設計段階で「障害の瞬間にどう持ちこたえるか」をあらかじめ決めているかどうかです。
信頼性投資で最もよくある誤りは、100%無停止を際限なく追い求めることです。現実的なやり方は、まずダウンタイムコストを算出することです。Gartnerが長年引用している基準は平均で1分あたり約5,600ドル、1時間あたり約33.6万ドルです。ITICの2024年の調査ではさらに、中堅・大企業の9割以上が1時間の停止で30万ドル超の損失を出し、うち約4割が100万〜500万ドルの損失に及ぶと指摘しています。この数字があれば、必要な稼働率を逆算できます。重要な認識は、稼働率が9を1つ増やすごとにコストは線形ではなく段階的に増大する、ということです。
| 稼働率 | 年間の許容ダウンタイム | 適した処理 |
|---|---|---|
| 99% | 約3.65日 | 社内ツール、リアルタイム性の低いバッチ処理 |
| 99.9% | 約8.8時間 | 一般的な対外サービス、社内の中核システム |
| 99.99% | 約52分 | 取引、リアルタイム顧客対応などの重要業務 |
1時間あたりのダウンタイムコストに目標稼働率を掛ければ、予算承認に持っていける数字が得られます。1時間で数十万元の損失が出る取引処理なら、99%から99.9%へ引き上げること（年間で約3日の停止削減）に対して追加のアーキテクチャ投資は割に合います。一方、社内のレポートツールに99.99%を無理に当てはめるのは無駄です。この数字がなければ、信頼性投資は過少か過剰のどちらかになります。
信頼性をシステムに組み込むために頼るのは、より高価なサーバーではなく、大規模に検証された3つの障害処理パターンです。これらはNetflixのHystrixライブラリによって普及しました。現在Hystrixはメンテナンスモードに入り、新規プロジェクトの多くはResilience4jを採用していますが、パターン自体は依然として業界標準です。
| パターン | 何を解決するか | 注意すべき代償 |
|---|---|---|
| リトライ | 一時的な揺らぎ、散発的なタイムアウト | 指数バックオフと重複排除が必須。さもないとトラフィックを増幅し二重課金を招く |
| サーキットブレーカー | 依存先が継続的に失敗する状態 | 作動中は機能が停止するため、定期的に復旧を試す必要がある |
| フォールバック | 主経路が完全に利用不能 | 予備の品質は低いため、許容できる簡易版を事前に定義する必要がある |
リトライは「もう一度試せばたいてい成功する」一時的な障害に対処します。要点は指数バックオフにランダムなジッター（full jitter）を加えることで、式はおよそ sleep = random(0, min(上限, 基数 × 2^回数)) となり、上限は32〜60秒、回数は3〜5回以内に抑えます。これにより全リクエストが同時にリトライしてサンダリングハード現象で依存先を圧迫するのを防ぎます。4xxエラーのうち通常リトライする価値があるのは429（レート制限）だけで、応答にRetry-Afterがあればそれに従います。決済や書き込みを伴う処理では、リトライが二重に効かないよう冪等キー（idempotency key。StripeやPayPalが標準としています）を加える必要があります。サーキットブレーカーは逆で、ある依存先が連続して失敗したら即座にフェイルファストし、呼び出しを停止して定期的に試します。フォールバックは最後の防衛線で、主経路が本当にダウンしたら、キャッシュした古い結果・より単純なモデル・人間による処理に切り替えます。
これら3つは択一ではなく、同じリクエスト経路上に順に積み重ねます。LLM呼び出しを例にすると、2026年の本番水準での妥当な順序は次の通りです。
このチェーンの価値は、ある層で止められなかった障害を次の層が受け止める点にあります。マルチエージェント（multi-agent）システムでは特に重要です。各ステップの成功率が85%なら、10ステップをつないだエンドツーエンドの成功率は約19.7%まで下がり、エラーが経路に沿って複利的に増幅されます。したがって防御チェーンに加えて、「ステップは少ないほどよく、各ステップに関門を設ける」ことも併せて行わなければ、この連鎖的な障害を防げません。
フォールバックは利点しかないように聞こえますが、実務では直感に反する罠が潜んでいます。予備モデルが主モデルより高価な場合、障害中にトラフィックが全て予備へ流れ込むと、業務がすでに損害を受けている最中にコストまで押し上げてしまうのです。そのため2026年のマルチモデルルーティング（multi-model routing）の実務では、フォールバックチェーンをコスト調整後の品質で並べることを強調します。例えば主モデル → 別プロバイダーの同等モデル → 同プロバイダーのより安価なモデル → 自前のオープンソースモデル、という順にして最悪ケースの費用に上限を設けます。同時にフォールバックは明示的でテスト可能な挙動でなければなりません。不適切なモデルへ静かに切り替わることは、はっきりと失敗を返すよりも悪い場合が多いのです。
すべての機能に一度で完全な防御を施す必要はありません。現実的な順序は、まずダウンタイムコストが最も高く、かつ外部サービスへの依存が最も重い1〜2本の重要経路を特定し、タイムアウトとリトライを整え、次に最も不安定な依存先にサーキットブレーカーとフォールバックを加え、最後に残りの処理へ広げることです。層を追加するたびに障害注入（fault injection）で実際に模擬し、ある依存先を手動で止めてシステムが停止せず優雅に縮退するかを観察します。本当に障害が起きた日に防御が効いていないと気づくのでは遅すぎます。信頼性は一度で完成するプロジェクトではなく、依存先やトラフィックの変化に応じて継続的に調整する長期的な投資です。
信頼性エンジニアリングの難しさは、サーキットブレーカー・フォールバック・リトライという用語を知っていることではなく、どの経路に投資する価値があるか、各層の閾値と退避挙動をどう設定するか、そして縮退時にどうコストを抑えるかを的確に判断することにあります。これには業務上の損失とシステム実装の双方への理解が必要です。恩梯科技のAIシステムコンサルティングと受託開発サービスは、まず重要業務のダウンタイムコストを明確に洗い出し、それに見合った信頼性設計へと対応づけます。これにより、システムは稼働開始の初日から依存先の障害を耐え抜く能力を備え、障害が起きて業務が損害を受けた後で慌てて補修する事態を避けられます。
これらの手法を自社に導入したいですか？
LINEで無料相談
技術共有
多くのブランドはチャネルごとに別々のAIボットを設置し、音声・チャット・CRMがかみ合わず、同じ顧客がつながりのない断片に分割されています。本記事では、CXMのチャネル横断統合を三層——統一顧客ビュー、システム統合、チャネル横断のオーケストレーション——として実データとともに読み解き、あらゆる接点が同一の顧客レコードの上に成り立つ仕組みを示します。
技術共有
会話が長くなるほど AI はなぜ高く、そして散漫になるのでしょうか。本稿は Chroma や Anthropic などの最新研究データをもとに、スライディングウィンドウ、要約圧縮（compaction）、分割による外部退避、重要情報のピン留めという四つの戦略と、その組み合わせ方を解き明かします。
技術共有
多くの企業は AI への権限委譲を白か黒かのスイッチとして扱い、全件を人が審査するか、すべてをシステムに自動で任せるかのどちらかになりがちです。しかし Gartner は、リスク管理の不足により agentic AI プロジェクトの 40% 超が 2027 年までに中止されると予測しています。本記事は人間工学と AI エージェントの実在する分級枠組みをもとに、全件人手審査から完全自律までの五段階の権限委譲の階段を示し、定量的な昇格基準と品質低下時のサーキットブレーカーによるフォールバックまでを扱います。
サポートが必要ですか？
ここをクリックしてお問い合わせください！
