外部API障害を連鎖させない、AIワークフローの三状態遮断
LLMやOCRの障害中も呼び出しが続き、失敗が膨らむ。プラットフォーム責任者向けに、依存先を三状態で遮断し、安全に復帰させる手順をまとめます。
再試行ではなく「依存先ごとの遮断」を置く
責任者は、LLM、OCR、CRMなど依存先ごとに遮断器を持たせます。通常はClosed、失敗がしきい値を超えるとOpen、待機後は少数の試行だけを通すHalf-Openです。Microsoftも、Openでは処理を即時に拒否し、Half-Openの成否で復帰を決める形を示しています。[1]
再試行は一時的な回復を待ち、遮断は呼び出しを止めます。AWSは、再試行に指数バックオフ、ジッター、最大回数を設けないと、障害中の依存先にさらに負荷をかけ得るとしています。[2]
入力は、依存先一覧、失敗応答、最大待ち時間、代替処理、許容滞留時間です。認証エラーや入力不備は再試行せず、そのジョブを失敗にします。
コピーして使う依存先ポリシー
依存先ごとに設定します。数値は初期値で、応答時間と障害試験から調整します。
dependency_guard:
name: document-ocr
timeout_ms: 8000
retry:
max_attempts: 2
backoff: exponential
jitter: true
honor_retry_after: true
circuit:
failure_window_sec: 60
open_after_failures: 5
open_for_sec: 120
half_open_max_calls: 2
close_after_successes: 2
on_open:
action: queue
queue_ttl_min: 30
user_message: processing_delayed
alert_owner: platform-oncall503応答にRetry-Afterがあれば、その値は次の呼び出しまで待つべき時間を示します。値は日時または秒数です。[3] ただし、待機時間が業務の許容滞留を超えるなら、無期限に待たず、人手処理や期限切れへ分岐させます。
実装は四つの順番で進める
- 失敗を分類する。 タイムアウト、429、503、接続失敗は遮断器の対象にします。400や401は、入力または認証の修正へ送り、同じ条件で繰り返しません。
- ClosedからOpenへの条件を実装する。 直近の時間窓で失敗数を数え、しきい値到達後は外部APIを呼ばず、キュー、キャッシュ、手作業のいずれかへ即時に分岐します。
- Half-Openの入口を細くする。 待機時間後も全ジョブを流さず、最大試行数だけ通します。成功が連続したらClosedへ、1件でも失敗したらOpenへ戻します。
- 状態遷移を記録する。
dependency、from_state、to_state、reason、queued_count、probe_resultをログと通知に残します。
【仮想例】請求書処理でOCRが5回連続タイムアウトしたとします。遮断器はOpenになり、新着20件を30分期限のキューへ移します。120秒後、Half-Openで2件だけ送ります。2件とも成功すればClosedへ戻し、古いジョブから毎秒1件ずつ再開します。1件でも失敗すれば再びOpenにし、当番へ通知します。完了は「外部呼び出しが停止した」「キューに欠落がない」「試行2件だけで復帰判定した」「重複登録なく全件を処理した」の四条件で判定します。
失敗しやすい設計と境界
遮断器を全APIで共有すると、OCR障害だけでCRMまで止まります。依存先、リージョン、認証資格が違うなら状態も分けます。ただし、業務上同じ復旧判断をする単位にそろえます。
Open中に単なるエラーを返すだけでは、上流が再試行して負荷が移ることがあります。queued、manual_review、expiredのように終了先を明示してください。また、復帰直後にキューを一斉放出すると再障害を招くため、流量を段階的に戻します。
ローカル資源への単純な呼び出しで、標準の再試行だけで十分という場合には向きません。メッセージ基盤が依存先ごとの隔離、再試行、デッドレター処理をすでに担う場合も、二重実装を避けます。[1]
明日から使える障害試験表
ステージングで次を順番に注入します。
| 注入する障害 | 期待する動作 | 合格条件 |
|---|---|---|
| 8秒超のタイムアウトを5回 | Openへ遷移 | 6件目は外部送信せずキューへ入る |
503とRetry-After | 指定時間を尊重 | 早過ぎる再送がない |
| Half-Openの1件目が失敗 | Openへ戻る | 追加試行を通さない |
| Half-Openで2件成功 | Closedへ戻る | 段階的にキューを消化する |
| キュー期限を超過 | 人手処理へ送る | ジョブが無言で消えない |
本番投入前に、所有者、Open中の代替先、滞留期限、手動開閉手順まで埋めます。目的は障害の範囲を固定し、回復確認後だけ仕事を戻すことです。
参考資料
- Microsoft Azure Architecture Center: Circuit Breaker pattern
- AWS Well-Architected Framework: REL05-BP03 Control and limit retry calls
- RFC 9110: HTTP Semantics, Retry-After
本記事はAIを活用して作成し、公開前に自動レビューを実施しています。情報の確認日：2026-10-21。
著者
ELYSAI編集部