AIエージェントを安定運用するためのSRE設計 ― 可観測性、SLO、障害対応、継続的改善の考え方

1. AIエージェントのSREが難しい理由

AIエージェントは、モデルが処理手順を決め、必要に応じて複数のツール、Model Context Protocol（MCP）サーバー、外部APIを呼び出します。その結果から回答を組み立てるため、再試行や分岐も発生します。

同じ入力でも回答やツールの選択は完全には一定になりません。正常終了しても意図に合わない回答になり、回答が適切でも不要なツール呼び出しや過剰なトークン消費が隠れる場合があります。

そこで、監視の単位を三つに分けます。一回の入力と応答を確認する「ターン」、一連の処理経路を確認する「トレース」、複数のターンを含む業務のまとまりを確認する「セッション」です。途中のターンが成功しても、セッション全体で申請や問い合わせ対応を完了できなければ、利用者にとっては成功とはいえません。

図1　利用者の依頼からモデル、ツール、外部APIまでを、セッションとトレースで関連付けて観測する

2. 何をSLIとして観測するか

SLI（Service Level Indicator）は、サービスの状態を判断するために実際に測る指標です。本記事では、AIエージェントのSLI候補を「利用者の確認結果」「処理経路」「利用量」の三つに整理します。これはGoogle Cloudの製品分類ではなく、本記事独自の整理です。

利用者の確認結果

最初に、利用者が目的を達成できたかを測ります。業務処理の完了率、適切に回答または拒否できた割合、再質問が必要になった割合、利用者からの評価などを候補にします。

回答品質は単純な正解率だけでは表せません。事実に基づいているか、依頼に沿っているか、必要な根拠があるか、禁止事項を守っているか、会話をまたいで文脈を維持できたかなど、用途ごとの評価基準を定めます。

実際の利用状況を代表するセッションを選び、人が内容を確認します。これに自動評価と利用者のフィードバックを組み合わせます。自動評価だけで正解と判断せず、実際の業務結果と照合します。

処理経路

次に、エージェント内部の処理を測ります。セッション完了までの時間、ターンごとの応答時間、モデル呼び出しのエラー率、クォータ超過、ツール呼び出し成功率、再試行回数、外部APIの応答時間などです。

レイテンシは平均値だけで判断しません。中央値に加えて、処理時間を短い順に並べたときに95％や99％の処理が収まる時間も確認します。平均値では見えにくい、一部の利用者だけが長時間待たされる状態を確認するためです。また、全体の成功率だけでなく、エージェントの版数、モデル、ツール、接続先、環境ごとに分けます。これにより、全体では小さく見える障害も発見しやすくなります。

利用量とコスト

トークン利用量、モデルとツールの呼び出し回数、CPU、メモリ、外部API料金などを確認します。コストは月末の請求額だけでなく、成功したセッション当たりの利用量として追跡します。品質を維持したまま、不要な再試行、長すぎる会話履歴、利用されないツール定義を減らせているかを判断します。

Cloud Billingの利用料データと、セッションID、モデル、トークン、ツール呼び出しなどの利用情報を分析時に対応付けます。料金体系や外部サービス費用も影響するため、トークン数だけで正確なコストを断定しません。

ログ、メトリクス、トレースにも役割の違いがあります。メトリクスは傾向とSLOの判定、トレースは一つの処理がどこで遅延または失敗したかの確認、ログはエラー内容や認可結果など個別事象の確認に使います。

session_id、trace_id、エージェントの版数、環境、モデル、ツール名を共通項目として持たせ、三つの情報を行き来できるように設計します。OpenTelemetryを利用すると、エージェント、モデル、ツールの処理を共通形式のテレメトリとして扱いやすくなります。

3. SLOとエラーバジェットを設計する

SLO（Service Level Objective）は、SLIについて守る水準を定めた目標です。エラーバジェットは、SLOの範囲内で許容できる失敗量を示します。

SLOは、監視画面に表示できる数値から選ぶのではありません。利用者が期待する結果と、障害時の業務影響から定めます。AIエージェントでは、一つのSLOにすべてを詰め込みません。たとえば、対象セッションのうち業務を完了できた割合、定めた時間内に完了した割合、必要なツール呼び出しが成功した割合などを分けます。

回答品質は評価に時間がかかる場合があります。そのため、即時のページ通知に使う指標と、日次や週次で傾向を確認する指標を分けます。コストも信頼性SLOへ混ぜず、予算超過を防ぐための上限や変化率として管理します。

目標値は、業務の重要度、現在の実績、依存先の水準を確認して決めます。根拠のない固定値を採用せず、計測結果と利用者影響を基に見直します。

エラーバジェットを使う場合は、許容した失敗量を使い切ったときの行動まで決めます。消費が速いときは、新しいモデル、プロンプト、ツールの変更を止め、信頼性の回復を優先します。余裕があるときは、段階的な変更や評価を進めます。

エラーバジェットは、変更速度と安定性のどちらを優先するかを、関係者が同じデータで判断するために使います。

4. アラートを設計し、障害を切り分ける

アラートは、異常らしい数値をすべて通知する仕組みではありません。担当者が対応すべき利用者影響があり、実行する手順が決まっているものに絞ります。

可用性やレイテンシのSLOには、エラーバジェットをどの速さで消費しているかを示すバーンレートを利用できます。短時間で急激に悪化する異常と、長時間かけて緩やかに悪化する異常を分けて検知します。ツールの失敗率、モデルのクォータ超過、コスト、回答品質についても、継続時間や影響セッション数を加えて通知条件を定めます。

障害時は、最初に影響範囲を確認します。対象の環境、エージェントの版数、モデル、ツール、利用者、開始時刻を絞ります。次にトレースを開き、Agent Runtimeで処理が開始されたか、モデル呼び出しで止まったか、ツールまたは外部APIが失敗したかを確認します。Agent Gatewayを利用する構成では、認可結果と拒否理由も確認します。

その後、該当箇所のログでエラー内容、認証・認可、再試行、タイムアウトを確認します。最後にメトリクスで同じ問題がどの範囲へ広がっているかを確認し、直前のデプロイ、プロンプト変更、モデル変更、ツール設定、外部サービスの障害と時系列で照合します。

5. 復旧、ロールバック、再実行を設計する

復旧では、まず影響の拡大を止めます。問題のあるツールを一時的に無効化する、同時実行数を下げる、一部機能を止めて最低限の処理だけを継続する、代替モデルへ切り替える、既知の安定版へ戻す、といった手順を事前に定めます。

Agent Runtimeには、不変のリビジョンを作成して複数のリビジョンへトラフィックを分ける機能があります。ただし、2026年8月2日時点ではPublic Previewであり、Agent Gatewayを関連付けたエージェントではリビジョンやトラフィック分割を利用できません。特定機能だけに依存せず、安定版の成果物、設定、プロンプト、ツール定義を管理し、構成に合った復旧手順を準備します。

再実行は、読み取り処理と更新処理を分けます。外部システムを更新するツールを無条件に再実行すると、二重登録や二重送信が起こります。同じ処理を複数回実行しても結果が重複しない性質を「冪等性」と呼びます。処理IDによる重複防止、実行済み状態の記録、ツールの冪等性、再実行前の人による承認を設計します。

自動再試行できる処理と、停止して確認する処理をRunbookへ明記します。アプリケーションを以前の版へ戻しても、外部システムへ反映済みの更新は残るため、プログラムの版と業務上の変更を分けて復旧します。

復旧後は原因を一つの層へ決めつけず、処理経路、検知できなかった理由、復旧に必要だった情報を振り返ります。

図2　観測、SLO判定、検知、切り分け、復旧、評価、改善を繰り返す運用サイクル

6. Google Cloudで観測基盤を構成する

Google Cloudでは、OpenTelemetryでエージェント、モデル、ツール呼び出しを計装し、Cloud Logging、Cloud Monitoring、Cloud Traceで関連情報を確認できるようにします。Cloud Monitoringではメトリクスとアラートを管理し、Cloud Traceではセッション内の処理経路を確認し、Cloud Loggingでは個別イベントの詳細を確認します。

Agent Runtimeは、リクエスト数、レイテンシ、CPU、メモリなどの組み込みメトリクスを自動収集します。ただし、業務完了率や回答品質まで自動的に定義するものではありません。アプリケーション側で業務結果とセッションを関連付け、必要なカスタム指標と評価データを追加します。

Agent Gatewayを利用する構成では、認可結果、MCPのメソッドやツール名、対応するAgent Registryのリソースを切り分けに利用し、Runtimeや接続先の情報と関連付けます。

Agent Observabilityは、セッション、レイテンシ、エラー、トークン、モデル、ツール、ログ、トレースなどを横断して確認するために利用します。2026年6月18日に一般提供されましたが、画面を有効にするだけで運用設計が完成するわけではありません。ダッシュボードやトレースへ情報を表示するには、必要なOpenTelemetryデータを送信します。SLI、SLO、通知先、復旧手順、品質評価は運用者が定めます。

本番トレースを継続的に評価するOnline Monitorや、利用者のフィードバックをセッションやイベントへ関連付けるFeedback serviceもあります。Feedback serviceは2026年8月2日時点でPreviewのため、必須構成とはせず、利用時に提供状況を確認します。

プロンプトや回答には、個人情報、機密情報、認証情報が含まれる可能性があります。全文を常にログへ保存せず、障害調査と評価に必要な項目を先に定めます。保存する場合は、マスキング、アクセス制御、保存期間、保存場所、削除方法、利用者への通知を設計します。

Google Cloudの公式資料では、プロンプトや回答をトレース属性へ直接保存せず、Cloud StorageまたはCloud Loggingへ分けて保存します。大きなデータやマルチモーダルデータには、ライフサイクル管理ができるCloud Storageが推奨されています。

7. 本番運用に向けた確認項目

本番移行前に、次の内容を決定します。

担当者、判断条件、手順、記録場所まで定めます。障害対応訓練では、モデルエラー、ツールのタイムアウト、Gatewayでの拒否、外部API障害など、原因の異なるケースでRunbookを確認します。

8. まとめ

AIエージェントのSREでは、CPU、メモリ、HTTPエラーだけを監視しても、利用者が目的を達成できたかは分かりません。セッション全体の結果、モデルとツールの処理、外部依存先、回答品質、トークン、コストを関連付けて観測します。

そのうえで、業務に合ったSLIとSLOを定め、エラーバジェットに基づいて変更と安定性の優先順位を判断します。異常時はトレースから失敗区間を絞り、ログとメトリクスで原因と影響範囲を確認します。

復旧後のセッションを評価データへ追加し、プロンプト、モデル、ツール、基盤設定、アラート、Runbookを更新します。観測、判断、復旧、評価、改善を繰り返すことで、AIエージェントを一度動かすだけでなく、安定して動かし続ける運用へつなげます。

参考情報

• Agent observability
• Observability overview
• Set up monitoring
• Set up tracing
• View agent traces
• Instrument generative AI applications
• Monitor traffic through Agent Gateway
• Manage revisions and traffic
• Route Agent Runtime traffic through Agent Gateway
• Continuous evaluation with online monitors
• Feedback service overview
• Gemini Enterprise Agent Platform release notes
• Export Cloud Billing data to BigQuery
• Implementing SLOs
• Alerting on SLOs
• Error Budget Policy