自動化の失敗に耐える設計 — フォールバックとサーキットブレーカー

要点
- 自動化は必ず失敗する。失敗を前提とした設計だけが、実運用に耐える。
- フォールバックは「劣化しても止まらない」経路、サーキットブレーカーは「悪化を止めるために自動で停止する」仕組み。両方が要る。
- 失敗時の権限は、平時よりも狭い範囲に自動的に縮退する設計が有効。
- ただし、フォールバックとサーキットブレーカーを組みすぎると、平時の運用が過度に慎重になり、自動化のメリットが薄れる。
失敗しない自動化は、まだ本番に出ていない自動化だ
実運用に入った自動化は、必ずどこかで失敗する。モデルが誤った出力を返す、外部APIが応答しない、入力データの形式が突然変わる、認証トークンが切れる、想定外の入力が届く——原因は無数にある。「よくテストしたから大丈夫」で運用に出す設計は、失敗の瞬間に被害を最大化する。
ソフトウェア工学の分野では、失敗を前提とした設計パターンが古くから整備されている。分散システム論の Martin Fowler は “Circuit Breaker” パターンを、Google の SRE 本は “graceful degradation” と “load shedding” を、いずれも失敗の連鎖を止める仕組みとして紹介している。これらの考え方は、AIワークフローにもそのまま応用できる。
フォールバック — 劣化しても止まらない経路
フォールバックは、AI経路が失敗したときの代替経路を、事前に用意しておく仕組みだ。例えば、AIによる回答生成が失敗したら、事前定義済みのテンプレート返答に切り替える。分類モデルが低信頼度の結果を返したら、既定の分類(例:人へ引き渡し)に落とす。
重要なのは、フォールバック経路が「劣化した状態でも業務が継続する」ように設計されていることだ。フォールバックが完全な機能を提供する必要はない。むしろ、通常経路より機能が制限されていることを、利用者側にも明示できるほうがよい。「ただいまAI応答は縮退運転中です。定型応答をお送りしています」という表示は、劣化を隠すよりも信頼を維持しやすい。
サーキットブレーカー — 悪化を止めるための停止
フォールバックが「動き続ける」ための設計だとすれば、サーキットブレーカーは「動き続けないための」設計だ。連続失敗、異常率の急上昇、応答時間の激増などをトリガーに、自動でシステムを停止させ、人の介入を待つ。
金融取引システムのサーキットブレーカーが有名な例だ。株価の急変時に取引を一時停止することで、暴落や暴騰の連鎖を止める。AIワークフローでも、同じ考え方が有効になる場面がある。分類モデルが 10 件連続で低信頼度の結果を返している——これは入力データの性質が突然変わった兆候かもしれない。自動でワークフローを止め、人が状況を把握するまで再開しない、という設計が要る。
権限の縮退
失敗の兆候が検知されたとき、システムの権限を自動で縮退させる設計は、AIエージェントで特に有効に働く。エージェントに委任する範囲を平時と失敗時で分け、失敗時は書き込み系ツールをすべて無効化する、あるいは特定の低リスクなツールだけを残す。
この考え方はセキュリティ工学の “principle of least privilege” と同根で、システムが不安定な状態にあるとき、権限を狭めて被害を局所化する。AI が想定外の応答を続けている状況で、そのままフルの権限を維持することは、失敗の被害を最大化する設計になる。
組みすぎるという副作用
もっとも、フォールバックとサーキットブレーカーを組みすぎると、平時の運用が過度に慎重になる。閾値をぎりぎりに設定した結果、通常の変動でもサーキットブレーカーが頻繁に発動し、そのたびに人が介入する——これでは自動化の実効性が薄れる。
一方で、閾値を緩めに設定しすぎると、実際の失敗を検知できない。閾値の設定は、運用開始後のログを踏まえて調整していく必要がある。着手時に完璧な閾値を決めるのは実務的ではない。ROIの見積もりと同じで、閾値も運用データを見ながら書き直すものと捉えたほうがよい。
失敗の記録が、次の自動化を強くする
フォールバックとサーキットブレーカーの発動時には、必ず記録を残す設計が要る。「なぜ発動したか」「その時点の入力データは何だったか」「切り戻しに何を要したか」——これらの記録は、次の自動化案件の設計に直接使える資産になる。失敗を隠さずに構造化する組織は、二度目の同じ失敗を避けやすい。
参考
- Fowler, M. “Circuit Breaker.” martinfowler.com, 2014.
- Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. “Site Reliability Engineering: How Google Runs Production Systems.” O’Reilly, 2016.
- Saltzer, J. H. & Schroeder, M. D. “The Protection of Information in Computer Systems.” Proceedings of the IEEE, 1975(”principle of least privilege” 初出).
OYOMAX編集部 編集長 尾山 陽平Yohei Oyama
AI活用と業務設計を10年以上取材。ツールに振り回されない意思決定の型づくりを主題に据える。
あわせて読む
何を自動化するか — ROIから逆算する自動化の選定
「自動化できるか」ではなく「自動化して割が合うか」が問いになる。ROIの分子と分母のどちらも、簡単な数字にはならない。
AIエージェントに、どこまで委任するか
「エージェント」という言葉が広がるにつれ、委任の粒度が曖昧になっている。ツール呼び出しの数ではなく、判断責任の所在で委任範囲を決める。
AIネイティブ世代を採用するということ
AIを標準の作業パートナーとして学生時代を過ごした世代が、新卒として実務に入り始めた。「AIを禁じる職場」の採用競争力は、静かに下がりつつある。