本ブログはグローバルで公開された「How to achieve zero-downtime updates in large-scale AI agent deployments」の抄訳版です。
Webサイトがダウンすれば、すぐに気づきます。アラートが鳴り、ユーザーから苦情が入り、売上が止まることもあります。ところが、AIエージェントが「壊れた」とき、そうしたことは何一つ起こりません。エージェントは応答を続けます。ただ、間違った応答を返すだけです。
エージェントは完全に稼働しているように見えながら、ポリシーの詳細をハルシネーションしたり、セッションの途中で会話のコンテキストを失ったり、レート制限でシャットダウンされるまでトークン予算を燃やし続けたりすることがあります。
AIエージェントのゼロダウンタイムは、インフラの稼働時間とは別物です。それは、すべてのデプロイ、更新、スケーリングイベントを通じて、振る舞いの連続性を維持し、コストをコントロールし、意思決定の品質を保つことを意味します。本記事は、それを実現する責任を担うチーム向けです。
主なポイント
- AIエージェントのゼロダウンタイムは「可用性」ではなく「振る舞い」の問題である。 エージェントは「稼働中」であっても、ハルシネーションを起こしたり、コンテキストを失ったり、密かに予算を超過していたりする。
- システム稼働よりも機能的稼働のほうが重要。 正確な意思決定、一貫した振る舞い、コントロールされたコスト、保持されたコンテキスト――これらこそがエージェントが本当に「使える」状態かどうかを決める。
- エージェントの障害は従来のモニタリングでは見えないことが多い。 振る舞いのドリフト、オーケストレーションのミスマッチ、トークンスロットリングはインフラのアラートを発火させない。代わりにユーザーの信頼を蝕む。
- 可用性は3つの階層で管理する必要がある。 インフラ稼働、オーケストレーション継続性、エージェントレベルの振る舞い――それぞれに専用のモニタリングとオーナーシップが必要。
- オブザーバビリティは譲れない要件。 正確性、レイテンシー、コスト、振る舞いを相関的に把握できなければ、スケールしながら安全にデプロイすることは不可能。
なぜAIエージェントにとって「ゼロダウンタイム」は意味が違うのか
Webサービスは応答するか、しないかのどちらかです。データベースはクエリを受け付けるか、失敗するかです。ところが、AIエージェントはそうは動きません。エージェントは会話を通じてコンテキストを記憶し、同じ入力に対して異なる出力を生成し、レイテンシーが累積する複数ステップの意思決定を下し、処理するトークンごとに実コストを消費します。
エージェントにおいて「動作している」と「失敗している」は二値ではありません。これがエージェントのモニタリングを難しくし、安全なデプロイをさらに難しくしている要因です。
システム稼働 vs 機能的稼働
システム稼働は二値です。インフラが応答する、エンドポイントが200を返す、ログに動作記録が出る――それだけです。
本当に重要なのは機能的稼働です。エージェントが正確で、タイムリーで、コスト効率が良く、ユーザーが信頼できる出力を生成しているかどうかです。
その違いは以下のように現れます。
- カスタマーサービスエージェントは即座に応答する（システム）が、ポリシーの詳細をハルシネーションする（機能）
- ドキュメント処理エージェントはエラーなしで動く（システム）が、重要な契約書の80%を処理した時点でタイムアウトする（機能）
- モニタリングダッシュボードは100%可用性を示す（システム）一方で、ユーザーは苛立ちのあまりエージェントを見限る（機能）
「立ち上がって動いている」と「意図通りに機能している」ことは同じではありません。エンタープライズAIにとって意味があるのは後者だけです。
なぜエージェントはクラッシュせず「ソフトに」失敗するのか
従来のソフトウェアはエラーを投げます。AIエージェントはそうではありません。代わりに、自信たっぷりに間違った答えを返してきます。LLM（大規模言語モデル）は非決定的なため、障害は500エラーではなく、微妙に劣化した出力として表面化します。ユーザーにはモデルの限界とデプロイ問題の区別がつかず、チームの誰かが異常に気づく前に信頼が失われていきます。
エージェントのデプロイ戦略では、エラー率だけでなく振る舞いの劣化を検知する必要があります。従来のDevOpsは、クラッシュではなく劣化するシステム向けには設計されていません。
ゼロダウンタイムAIエージェント可用性のための階層モデル
エンタープライズAIエージェントにおける真のゼロダウンタイムは、3つの異なる階層を管理することを要求します。それぞれライフサイクルへの登場タイミングが異なり、オーナーも異なります。
- インフラ可用性：基盤
- オーケストレーション可用性：知能レイヤー
- エージェント可用性：ユーザーが体験する現実
ほとんどのチームは階層1を押さえています。本番エージェントを破壊するギャップは、階層2と階層3に潜んでいます。
階層1：インフラ可用性（基盤）
インフラ可用性はエージェントの信頼性にとって必要条件ですが十分条件ではありません。この階層は、コンピュート、ネットワーク、ストレージを稼働させ続けるプラットフォームチーム、クラウドチーム、インフラチームのものです。
完璧なインフラ稼働が保証するのは、ただ一つ――エージェント成功の可能性だけです。
インフラ稼働は前提であってゴールではない
従来のSLAは重要ですが、エージェントワークロードには不十分です。
CPU使用率、ネットワークスループット、ディスクI/Oは、エージェントがハルシネーションを起こしているか、トークン予算を超過しているか、不完全な応答を返しているかについて何も教えてくれません。
インフラの健康状態とエージェントの健康状態は同じ指標ではありません。
コンテナオーケストレーションとワークロード分離
KubernetesやスケジューリングやリソースアイソレーションがAIワークロードに与える影響は、従来のアプリケーションよりも大きくなります。GPUの競合は応答品質を劣化させます。コールドスタートは会話の流れを中断します。一貫性のないランタイム環境は、ユーザーが「不安定」と感じる微妙な振る舞いの変化を生みます。
セールスアシスタントが基盤インフラの変更によって急にトーンや推論アプローチを変えたなら、稼働ダッシュボードが何と言おうと、それは機能的ダウンタイムです。
階層2：オーケストレーション可用性（知能レイヤー）
この階層は、機械が動いていることから、モデルとオーケストレーションが正しく協調して機能することへと焦点が移ります。MLプラットフォーム、AgentOps、MLOpsチームの領域です。レイテンシ、スループット、オーケストレーションの整合性が、ここで重要となる可用性指標です。
モデルロード、ルーティング、オーケストレーションの継続性
エンタープライズAIエージェントが単一モデルに依存することはまずありません。オーケストレーションチェーンがリクエストをルーティングし、推論を適用し、ツールを選択し、応答をブレンドします。多くの場合、リクエストごとに複数の専門モデルを横断します。
任意のコンポーネントを単独で更新すると、チェーン全体を壊すリスクが生じます。デプロイ戦略は、複数モデルの更新を独立したバージョニングではなく一つの単位として扱う必要があります。推論モデルだけ更新されてルーティングモデルが更新されないと、その後の振る舞いの不整合は、ユーザーが影響を受けるまで従来のモニタリングでは表面化しません。
トークンコストとレイテンシーは可用性の制約条件
予算超過は隠れたダウンタイムを生みます。エージェントが月の途中でトークン上限に到達すれば、インフラ指標が何を示そうと、機能的には利用不可能です。
レイテンシーも同じように積み上がります。連続する5回の推論呼び出しに各500ミリ秒の遅延があれば、ユーザーから見ると2.5秒の遅延となります。これは体験を悪化させるには十分ですが、アラートを発火させるには足りません。従来の可用性指標はこの累積効果を考慮しません。あなたの指標はそれを考慮する必要があります。
なぜ従来のデプロイ戦略はこの層で破綻するのか
標準的なデプロイアプローチは、クリーンなバージョン分離、決定的な出力、既知の良好な状態への確実なロールバックを前提としています。エンタープライズAIエージェントでは、これらの前提はどれも成立しません。
ブルーグリーン、カナリア、ローリングアップデートは、ステートフルで非決定的、かつトークンベースの経済性を持つシステム向けに設計されたものではありません。エージェントのデプロイで安全に使うには、それぞれに意味のある適応が必要です。
階層3：エージェント可用性（ユーザーが体験する現実）
この階層こそ、ユーザーが実際に体験する部分です。AIプロダクトチームとエージェント開発者がオーナーとなり、タスク完了率、正確性、インタラクションあたりのコスト、ユーザーの信頼で測定されます。AI投資のビジネス価値が実現される、あるいは失われる場所です。
ステートフルなコンテキストとマルチターン継続性
コンテキストの喪失は機能的ダウンタイムに該当します。
顧客がサポートエージェントに問題を説明したのに、デプロイのロールアウト中に会話の途中でそのコンテキストが失われたなら、システム指標が何を報告しようと、それは機能的ダウンタイムです。セッションアフィニティ、メモリの永続化、引き継ぎの継続性は、「あったらいい」ではなく可用性要件です。
エージェントは会話の途中での更新にも耐えなければなりません。これには、従来のアプリケーションが必要としないレベルのセッション管理が要求されます。
ツールおよび関数呼び出しという隠れた依存関係
エンタープライズエージェントは、外部API、データベース、社内ツールに依存します。スキーマや契約の変更は、何のアラートも発火させずにエージェント機能を壊し得ます。
製品カタログAPI構造へのちょっとした更新が、エージェントのコードを一行も触っていないのに、セールスエージェントを使い物にならなくすることがあります。バージョン管理されたツール契約と段階的な機能縮退（graceful degradation）は、オプションではなく可用性要件です。
最も検出しづらい障害――振る舞いのドリフト
プロンプトの微妙な変更、トークン使用量の変化、オーケストレーションの調整は、指標には現れないがユーザーにはすぐ気づかれる形で、エージェントの振る舞いを変える可能性があります。
デプロイプロセスは、コードの実行だけでなく振る舞いの一貫性を検証する必要があります。エージェントの正確性は、リリース時の一回限りのチェックではなく、継続的なモニタリングを必要とします。
エージェント型システムのためのデプロイ戦略を再考する
従来のデプロイパターンが間違っているわけではありません。ただ、エージェント特有の適応がなければ不完全なのです。
エージェント向けブルーグリーンデプロイ
エージェント向けブルーグリーンデプロイには、セッション移行、スティッキールーティング、そしてモデルロード時間とコールドスタートペナルティを考慮したウォームアップ手順が必要です。並列環境を稼働させることで、移行期間中はトークン消費が倍増します――エンタープライズスケールでは無視できないコストです。
最も重要なのは、カットオーバー前に振る舞いの検証を行わなければならないことです。新しい環境は同等の応答を生成するか？ 会話のコンテキストを維持するか？ 同じトークン予算制約を尊重するか？ これらのチェックは、従来のヘルスチェックよりも重要です。
エージェント向けカナリアリリース
1〜5%といった小さなカナリアトラフィック割合でも、エンタープライズスケールでは有意なトークンコストが発生します。推論ループに陥った問題のあるカナリアは、誰かが気づく前に不釣り合いなリソースを消費する可能性があります。
エージェント向けの効果的なカナリア戦略には、従来のエラー率モニタリングに加えて、出力比較とトークントラッキングが必要です。成功指標には、エラー率だけでなく正確性とコスト効率が含まれていなければなりません。
ローリングアップデートがエージェントでうまくいかない理由
ローリングアップデートは、ほとんどのステートフルなエンタープライズエージェントとは相性が悪いものです。バージョン混在の環境を作り出し、マルチターンの会話に一貫性のない振る舞いを生みます。
ユーザーがバージョンAで会話を開始し、ロールアウト中に新バージョンBで継続した場合、推論は――微妙にではあれ――シフトします。バージョン間のコンテキスト処理の違いは、質問の繰り返し、情報の欠落、会話フローの断絶を引き起こします。これは、サービスが技術的にオフラインにならなくても、機能的ダウンタイムです。
ほとんどのエンタープライズエージェントにおいて、安全なオプションは慎重なセッションハンドリングを伴う環境一括スワップだけです。
オブザーバビリティは機能的稼働の屋台骨
AIエージェントにおけるオブザーバビリティ（可観測性）は、エージェントが何をしているか、なぜしているか、それが正しく行われているかなどの振る舞いに関するものです。これがデプロイ安全性とゼロダウンタイム運用の基盤です。
正確性、コスト、レイテンシーを相関的にモニタリングする
単一指標でエージェントの健康状態を捉えることはできません。正確性、コスト、レイテンシーを相関的に可視化する必要があります。それぞれが、無視できない形で独立に動きうるからです。
正確性が向上したがトークン消費が倍増したなら、それはデプロイ判断です。レイテンシーは横ばいだが正確性が劣化したなら、それはリグレッションです。個別指標ではどちらも表面化しません。相関的なオブザーバビリティだけがそれを捉えます。
ユーザーが気づく前にドリフトを検知する
ユーザーがエージェントの問題を報告する頃には、すでに信頼は損なわれ始めています。それを防ぐのがプロアクティブなオブザーバビリティです。
効果的なオブザーバビリティは、応答の意味的なドリフトを追跡し、推論パスの変化にフラグを立て、エージェントが定義された境界の外側にあるツールやデータソースにアクセスしたときにそれを検知します。これらのシグナルがあれば、リグレッションがユーザーに到達した後ではなく、到達する前に捉えることができます。
エージェントを動かし続けるために必要なステップを踏む
エージェントの障害は単なる技術的問題ではありません。信頼を蝕み、コンプライアンスリスクを生み、AI戦略全体を危険に晒します。
それを解決するには、デプロイをエージェントファーストな分野として扱う必要があります。インフラ・オーケストレーション・振る舞いを横断する階層化されたモニタリング、ステートフルさとトークン経済性のために構築されたデプロイ戦略、ユーザーよりも先にドリフトを検知するオブザーバビリティ。
DataRobotのエージェントワークフォースプラットフォームは、これらの課題を一か所で解決します。エージェント特化のオブザーバビリティ、すべてのレイヤーを横断するガバナンス、企業がスケールしながら安全にエージェントをデプロイ・更新するために必要な運用コントロールを提供します。
FAQ
なぜAIエージェントには従来の稼働指標では不十分なのか？
従来の稼働指標は、インフラが応答しているかどうかしか教えてくれません。AIエージェントは、不正確な答えを生成していたり、会話状態を失ったり、コストやレイテンシーの問題でワークフロー途中で失敗したりしながらも、健全に見えることがあります。これらはすべてユーザーにとっては機能的ダウンタイムです。
システム稼働と機能的稼働の違いは何か？
システム稼働はサービスに到達できるかを測ります。機能的稼働は、エージェントが正しく振る舞い、コンテキストを維持し、許容可能なレイテンシー内で応答し、予算内で運用しているかを測ります。エンタープライズAIの成功は後者にかかっています。
なぜAIエージェントはクラッシュせず「ソフトに失敗」するのか？
LLMは非決定的で、徐々に劣化します。エラーを投げる代わりに、エージェントは微妙に悪い出力、矛盾する推論、不完全な応答を生成し、結果として障害は検知しにくく、信頼へのダメージはより大きくなります。
AIエージェントにはどのデプロイ戦略が最適か？
従来のローリングアップデートは、ステートフルなエージェントを壊すことが多いです。ブルーグリーンデプロイとカナリアデプロイは機能し得ますが、セッション継続性、振る舞いの検証、トークン経済性、複数モデルオーケストレーション依存性のために適応された場合に限ります。
チームはどうすれば真のゼロダウンタイムAIデプロイを実現できるか？
チームには、エージェント特化のオブザーバビリティ、デプロイ中の振る舞い検証、コスト感度のあるヘルスシグナル、インフラ・オーケストレーション・アプリケーション層を横断するガバナンスが必要です。DataRobotのエージェントワークフォースプラットフォームは、これらの機能を一つのコントロールプレーンで提供し、更新、スケーリング、変更を通じてエージェントの信頼性を維持します。