AIエージェントを本番運用するための設計パターン｜サーキットブレーカー・ヘルスチェック・段階的劣化の使い方

AIエージェントの本番運用とは、障害を防ぐのではなく封じ込める設計方針です。

デモではうまく動くAIエージェントが本番で崩れる理由は、モデル精度ではなく運用インフラ側の欠落にあります。モデルを差し替えるより先に、失敗したときに系全体を止めない仕組みを作るほうが効きます。本記事では、海外エンジニアがAIエージェント運用で実践してきた3層のパターン——サーキットブレーカー、ヘルスチェック、段階的劣化（Graceful Degradation）——を日本語で整理し、それぞれの意味と実務での使い方を解説します。Google SRE Book、Microsoft Azure Architecture Center、AWS Well-Architected Framework、Kubernetes 公式ドキュメントといった一次ソースの定義に当たりながら、AIエージェント運用へ翻訳していきます。

AIエージェントが本番で壊れる理由

AIエージェントの本番運用で壊れる原因とは、モデル精度の問題ではなく、周辺インフラに障害封じ込めの仕組みがないことです。デモ環境で問題なく動いていたエージェントが、本番では急に沈黙する——この現象は珍しくありません。

元記事の筆者は、35体以上のAIエージェントを本番で数か月運用した経験から、「信頼性とは失敗を防ぐことではなく、失敗を封じ込めることだ」と述べています。モデルが落ちる、エージェントがハングする、メモリが失効する。そのたびに「自律」を謳っていたシステムが人手による手動再起動を要求し、結局オペレーターが張り付く羽目に陥ります。

「信頼性とは、すべての失敗をなくすことではなく、ユーザーへの影響を許容範囲内に保ち続けることだ」Google「Site Reliability Engineering: How Google Runs Production Systems」Chapter 3: Embracing Risk

こうなる根本原因は、AIエージェントがWebサービスと違って「いつ・どう壊れるか」の予測が立てにくいところにあります。LLM APIは外部依存であり、プロンプト入力も想定外の形で飛んでくる。セールス現場のAIアシスタントが予期せぬ異論（Objection）に突き当たるように、本番のエージェントも未知の入力に絶えず晒される状況です。

ここで効くのが、Webサービス運用で培われた SRE（Site Reliability Engineering）の発想です。Google が公開している SRE Book でも、すべての障害をゼロにする方針ではなく、エラーバジェット（許容失敗予算）を定めて影響範囲を抑える運用が推奨されていますGoogle SRE Book「Service Level Objectives」。AIエージェントでも同じ考え方が使えます。具体的には、失敗したコンポーネントを系から切り離す「サーキットブレーカー」、死活を常時確認する「ヘルスチェック」、主系が落ちても機能を残す「段階的劣化」の3層構成。以降のセクションで順番に見ていきます。

なお、AIエージェントが本番で期待通り動かない原因としてはモデル側ではなく指示設計の問題も大きいことが指摘されています。このテーマは AIエージェント失敗の88%はモデルのせいではない｜真因は「コンテキスト設計」にある で詳しく扱っていますので、合わせて参照してください。

サーキットブレーカーで連続失敗を遮断する

サーキットブレーカーとは、呼び出し先が連続して失敗した際に自動で遮断し、代替経路へ切り替える制御パターンです。電気回路のブレーカーが過電流で落ちる仕組みと同じ発想で、ソフトウェア工学では長く使われてきた手法。Martin Fowler が 2014 年に整理した記事が広く参照されており、Microsoft Azure Architecture Center も公式パターンとして文書化していますMartin Fowler「CircuitBreaker」Microsoft Learn「Circuit Breaker pattern」。

AIエージェント運用では、LLM APIや外部ツール呼び出しがタイムアウトを繰り返す局面で効いてきます。元記事の筆者は、運用閾値として「3回連続で失敗したら以後はリトライせず、フォールバック先にルーティングする」という設計を採っていると報告しています。ポイントは「叩き続けない」こと。壊れた相手に要求を送り続けるとスループットが落ち、周辺サービスまで連鎖障害を起こします。

リトライとサーキットブレーカーの違い

両者は混同されがちですが、役割は別物です。リトライは一時的なネットワークゆらぎを吸収するもので、短時間の再試行を前提にします。サーキットブレーカーは「相手が明確に壊れている」状況を検知して、そもそも叩くのをやめる制御。

言い換えれば、リトライは楽観的、サーキットブレーカーは悲観的な仕組み。両方を組み合わせ、「リトライ2〜3回で復帰しなければブレーカーを開く」という二段構えにするのが実務的です。AWS Well-Architected Framework の信頼性ピラーでも、リトライにはエクスポネンシャルバックオフとジッターを組み合わせ、そのうえで上位にブレーカーを置く構成が推奨されていますAWS「Reliability Pillar – AWS Well-Architected Framework」。

サーキットブレーカーの3状態モデル

Martin Fowler の整理では、ブレーカーは Closed（通常）／ Open（遮断）／ Half-Open（半開、試験的に通す）の3状態を遷移します。Half-Open は復旧チェック専用の状態で、一定時間が経った後に少数のリクエストだけ通し、成功すれば Closed に戻し、失敗すれば再び Open に戻す動きです。

この3状態モデルを実装している主要ライブラリには Java 系の Resilience4j、Python の pybreaker、Go の sony/gobreaker などがあります。AIエージェントのオーケストレーション層に組み込む場合、LLM API クライアントごとに独立したブレーカーを持たせ、Open/Closed の遷移ログを構造化ログ基盤に流す構成が運用しやすい配置です。

フォールバック先の設計

遮断後にどこへ流すかは、タスクの性質で変わります。選択肢は主に次の3つです。

• 軽量モデルへのフォールバック（品質は落ちるが応答は返せる）
• キャッシュ済み応答やルールベース回答（固定的な質問なら十分機能する）
• 人間オペレーターへのエスカレーション（金額が大きい決裁や誤答リスクが高い領域）

どれを選ぶかは、「失敗したときに誰が損害を被るか」で決めるのが筋。社内の下書き生成なら軽量モデルで十分ですが、顧客対応でウソの回答を返すと信頼を失います。タスク重要度とユーザー影響度を踏まえて、フォールバック経路を事前設計しておきたいところ。Anthropic 公式ドキュメントでも、レート制限超過時にエラーが返る挙動を前提に、上位アプリケーション側でリトライとフォールバック先を用意する設計が示されていますAnthropic API「Rate limits」。

ヘルスチェックでエージェントの生死を監視する

ヘルスチェックとは、稼働中のエージェントが定期的に生存信号を送り、反応が途絶えたら自動的に系から隔離する監視の仕組みです。Webサーバー運用では当たり前の手法ですが、AIエージェントでは実装が遅れがちな領域。Kubernetes はこれを Liveness Probe（プロセスが死んでいないか）、Readiness Probe（リクエストを受け付けられる状態か）、Startup Probe（起動が完了したか）の3種類に分けて定義しており、AIエージェントを Pod として動かす場合もそのまま流用できますKubernetes 公式「Configure Liveness, Readiness and Startup Probes」。

元記事の運用例では「5分ごとに生存シグナル（heartbeat）を発信し、2回続けて欠落したエージェントは自動隔離してオペレーションに通知する」という設計が紹介されています。間隔と閾値は扱うタスクの許容停止時間に合わせて調整するのが現場の判断。

死活だけでなく品質も監視する

AIエージェント特有の難しさは、「プロセスは生きているのに中身がおかしい」ケース。HTTPの200 OKは返ってくるのに、生成内容が意味不明な文字列、あるいは同じ応答を繰り返す——こうした静かな故障（silent failure）は、死活監視だけでは捉えられません。Microsoft の Health Endpoint Monitoring パターンでも、単純な生死判定にとどまらず、依存サービスの応答時間や応答内容を含めたエンドツーエンドの健全性確認が推奨されていますMicrosoft Learn「Health Endpoint Monitoring pattern」。

対策は、応答内容のサンプリング検査を監視層に組み込むこと。たとえば生成結果の長さが極端に短い、同一出力が連続する、特定エラーパターンに合致する、といった品質シグナルを定期ウォッチする設計。これは純粋な死活監視より重い処理になるため、本番トラフィック全量ではなく一定サンプリング率で回す運用が落としどころ。OpenTelemetry のように構造化トレースを LLM 呼び出し単位で残しておくと、品質劣化の原因切り分けが速くなります。

隔離後の復旧判断

隔離しただけで終わらせないことが大事。復旧フローを明文化しておかないと、隔離されたエージェントが放置されて実質的にサービス低下が続きます。手順は3段階に整理できます。

第1段階は自動再起動。再起動で復旧するなら、一時的なメモリ不足やコネクション切れが原因だった可能性が高い。第2段階は依存先の状態確認。LLM API側の障害情報を照合します。Anthropic Status などのステータスページは過去インシデントも含めて公開されており、自社の障害が単独事象か外部要因かをすぐ判別できますAnthropic Status。第3段階が手動介入。ログを精査してコード修正やプロンプト改善に進むフェーズです。

段階的劣化でコア機能を守る

段階的劣化（Graceful Degradation）とは、主要コンポーネントが障害を起こしても、機能を完全に止めるのではなく品質を落としてサービスを継続するパターンです。「遅くても動く方が、黙って止まるよりマシ」という考え方。Netflix がオープンソース化した Hystrix では、フォールバックメソッドを必須項目として扱う設計が採用されており、業界では古くから蓄積のある手法です。

元記事では、主モデルが失敗した際に軽量なフォールバックモデルへ切り替え、コア機能だけは維持する実装例が示されています。表現の装飾や高度な推論は落ちても、最低限のタスクは完遂する——この線引きが段階的劣化の中心点です。

優先度の決め方

何を捨てて何を守るか。この優先順位を事前に決めておかないと、障害発生時に場当たり判断になります。判断材料として、ユーザーがその機能を期待している度合いと、その機能が落ちたときの代替の有無を見ていきます。

たとえば社内ドキュメント検索エージェントなら、要約生成は落としても検索ヒット一覧は返すべきです。ユーザーは「見つけてくれる」ことを期待しており、要約は付加価値に過ぎないため。一方、カスタマーサポートのトリアージエージェントは、優先度判定が落ちたら代替がない。こちらはルールベースのフォールバックを用意してでも機能を残す必要があります。

劣化状態を利用者に伝えるUI設計

無言で品質が落ちるのは利用者にとって一番困る状況。「いつもと違う応答が返ってくるが、何か壊れているのか？」と不安にさせます。段階的劣化を導入するなら、劣化状態を可視化する仕組みがセットで必要です。

具体策としては、応答にステータスバナーを添える、ログAPIで劣化モードをクライアントに通知する、監視ダッシュボードで現在のモードを表示する、といったものが挙げられます。内部的に切り替わっているだけで外部に何も見えない実装は、トラブル時の問い合わせが激増する原因に。Microsoft が公開している Reliable web app pattern でも、ユーザーへの状態通知をフォールバック設計の構成要素として扱っていますMicrosoft Learn「Reliable web app pattern」。

3パターンの違いを一覧で確認する

サーキットブレーカー・ヘルスチェック・段階的劣化は守備範囲が重なる部分もあるため、整理して比較すると役割分担が見えやすくなります。

3つは独立しているわけではなく、上位から下位へ情報が流れる構成にすると噛み合います。ヘルスチェックが異常を検知 → サーキットブレーカーが該当ノードを遮断 → 段階的劣化が代替経路で応答を返す、という連鎖です。

LLM 特有の障害モードと3層の対応

AIエージェントが直面する障害は、従来のWebサービスにはなかったタイプも含まれます。それぞれに対して3層のどれが効くかを整理しておくと、設計のヌケが減ります。

表中の「ステップ上限」は、エージェントが取れるアクション回数に上限を設定する制御です。LangChain 系の実装では max_iterations として標準装備されており、無限ループ防止策として広く使われています。

3層を組み合わせた運用チェックリスト

3層を統合するとは、サーキットブレーカー・ヘルスチェック・段階的劣化を連携させて、障害検知から隔離、代替稼働までを自動化する運用設計です。単独ではなく組み合わせて初めて効いてきます。

導入前に確認したい観点は、次の項目に整理できます。SLO（Service Level Objective：サービス水準目標）として何を守るかを明文化しているか。エスカレーション先の連絡経路が決まっているか。フォールバック経路で発生したリクエストも含めて課金・制限管理ができているか。劣化モード中のログが通常モードと区別できる形式で残るか。これらが揃わないと、せっかく3層を実装しても運用で破綻します。

SLO と error budget で運用品質を測る

3層を入れたあとは、運用品質を数字で測る仕組みも必要です。Google SRE Book は SLI（Service Level Indicator：実測値）、SLO（目標値）、SLA（外部契約値）の3点セットでサービス品質を管理する手法を示しています。AIエージェントの SLI 候補としては、応答成功率、平均応答時間、フォールバック発動率、silent failure 検出率などが挙げられます。

SLO は厳しすぎても緩すぎても機能しません。たとえば月間 99.9% の応答成功率を目標にすると、許容失敗分（error budget）は月あたり約 43 分です。月初に大きな障害でこの予算を使い切ったら、新機能のリリースを止めて安定化に注力する——こうした運用ルールを事前に決めておくと、開発と運用の優先度判断が楽になります。Google SRE Book ではこの error budget 運用を「リリース速度と信頼性のトレードオフを定量的に扱う仕組み」として位置付けています。

よくある質問

Q. 小規模なAIエージェント1体でも、ここまでの仕組みは必要ですか？

すべて実装する必要はありません。ただし外部LLM APIに依存している時点でサーキットブレーカーだけは入れる価値があります。API障害時に無限リトライして課金が膨らむ事故を防げるためです。Anthropic と OpenAI のいずれも、レート制限・過負荷時の HTTP エラーコードを公開しており、クライアント側での適切な遮断はベンダー側も推奨しています。

Q. 既存のフレームワークで実現できますか？

サーキットブレーカーやヘルスチェックは汎用ライブラリが多数存在し、AIエージェント専用でなくても流用できます。Java なら Resilience4j、Python なら pybreaker や tenacity（リトライ中心）、Go なら sony/gobreaker といった選択肢があります。段階的劣化はアプリケーション固有の判断が必要なため、自前実装になるケースが一般的です。

Q. 軽量モデルへ切り替えると、どれくらい品質は落ちますか？

タスク次第で大きく変わるため一概に言えません。実運用では主モデルと軽量モデルで同じ評価セットを流し、自社ユースケースでの許容ラインを事前に測っておくのが現実的なやり方です。Anthropic や OpenAI の公開資料には用途別のモデル比較が掲載されており、コストと品質のトレードオフを判断する参考材料になります。

Q. ヘルスチェックの間隔はどう決めればよいですか？

許容停止時間（MTTR の上限）から逆算します。たとえば検知から復旧まで5分以内に収めたい場合、ヘルスチェック間隔は1分、欠落2回で隔離（= 2分で検知）、自動再起動に2〜3分という配分が現実的です。Kubernetes の Probe では periodSeconds と failureThreshold で同様の調整ができます。

Q. サーキットブレーカーの閾値は何を基準に決めますか？

過去のエラー率と業務影響度から逆算します。普段のエラー率が0.5%なら、瞬間的に5%まで上がっても一過性の可能性があるため、5%超 × 30秒継続で Open に遷移する設定が出発点です。本番運用しながら半年単位で微調整していくのが普通の流れになります。

Q. オンプレ LLM とクラウド LLM で設計に違いはありますか？

基本構造は同じですが、オンプレは GPU メモリ枯渇や VRAM 断片化が主な故障要因になり、クラウドはレート制限と地域別の障害が中心。それぞれヘルスチェックで監視する指標が変わってきます。オンプレでは GPU 使用率と VRAM 残量、クラウドではリクエスト成功率とレイテンシ分布を主に追う運用が現実的です。

まとめ

AIエージェントを本番で安定稼働させる鍵は、モデル性能の追求ではなく障害封じ込めの設計にあります。サーキットブレーカーで連続失敗を遮断し、ヘルスチェックで生死と品質を見張り、段階的劣化でコア機能を守る——この3層をセットで導入することで、壊れたときにオペレーターが慌てない状態を作れます。Google SRE Book、Microsoft Azure Architecture Center、AWS Well-Architected Framework、Kubernetes 公式ドキュメントといった一次ソースは、いずれも同じ方向のパターンを推奨しており、AIエージェントだけが特殊なわけではないとわかります。

最初の一歩としては、自分のエージェントで一番壊れやすい依存先を1つだけ特定し、そこにサーキットブレーカーを入れるところから始めるのがおすすめ。全部を一度に整備しようとすると挫折しがちです。小さく導入して運用で育てる発想が、結局は遠回りに見えて近道です。