Executive Summary
AIシステムを本番運用するSREにとって重要なのはGPUだけではありません。
LLM/APIの可用性、Rate Limit、Token Cost、Agentの長時間実行、Toolの障害、AI品質のRegression、Trace、Security Boundaryまでが運用対象になります。
従来の「HTTP 200なら正常」という監視から、タスクが正しく完了したかを監視する運用へ移行する必要があります。
最終確認日: 2026-10-08
背景と重要性
AIシステムではインフラ障害とAI品質障害が別々に発生します。
HTTP 200
Latency 1.2 sec
Error rate 0%
でも回答は間違っている
という状態があり得ます。
さらにAgentになると、
User
↓
Agent
├─ LLM
├─ Search
├─ Database
├─ MCP Server
└─ Code Sandbox
と依存先が増えます。
AWSのAmazon Bedrock AgentCoreは、本番Agent向けにRuntime、Gateway、Identity、Memory、Observability等を提供し、トークン利用量、レイテンシ、セッション時間、エラー率などを監視対象として挙げています。
OpenAIもAgents APIで長時間セッション、サンドボックス、サブエージェント等を提供しています。
SREがAgent Runtimeを理解する必要がある時代です。
主要トピックと最新動向
AI Gateway
複数のアプリが直接外部AI APIへ接続すると、
- API Key管理
- モデル管理
- Rate Limit
- Cost Attribution
- Audit
- Data Policy
が分散します。
そこで、
という共通レイヤーが有効です。
ただし、全ベンダー機能を「最小公倍数API」に押し込むと高度なTool CallingやAgent機能を失うため、
共通:
認証 / 監査 / Cost / Routing / Redaction
Provider-specific:
特殊なTool / Reasoning / Agent機能
のように分けるのがおすすめです。
SLOを二層にする
AIサービスには少なくとも、
System SLO
- availability
- latency
- error rate
と、
AI Quality SLO
- task success rate
- groundedness
- tool success
- policy violation rate
が必要です。
TraceがLogより重要になる
Agentでは最終回答だけを保存しても原因分析できません。
最低限、
trace_id
├─ model request
├─ retrieval
├─ model response
├─ tool call
├─ tool result
├─ model response
└─ final answer
を追跡できるようにします。
OpenTelemetryではGenAIクライアント、Agent、MCP等を対象とするSemantic Conventionsが整備されています。
OpenTelemetry GenAI Semantic Conventions
Agentは長時間ジョブとして扱う
Agent実行が数十秒から数時間になると、
同期HTTPリクエストだけでは扱いづらくなります。
必要になるのは、
- Durable execution
- Retry
- Idempotency
- Timeout
- Cancellation
- Checkpoint
- Dead Letter Queue
です。
これはLLM特有というより、分散システムの基本へ戻る話です。
CostをObservabilityに含める
Agentではモデル呼び出し回数がユーザーリクエスト数と一致しません。
そのため、
cost / API call
だけではなく、
cost / completed task
cost / user
cost / tenant
cost / feature
を見る方が有効です。
実務での活用例
本番Agent基盤
障害時の切り分け
AI機能が遅い
|
+-- Provider latency?
+-- Queue backlog?
+-- Agent loop増加?
+-- Retrieval latency?
+-- Tool timeout?
+-- Token/context増加?
AIでは「モデルが遅い」で終わらせないことが重要です。
実務チェックリスト
Reliability
- AI Providerごとにtimeoutを設定した
- Retry対象と非対象を分類した
- Exponential Backoffを設定した
- Rate Limitを吸収する仕組みがある
- Queue / Backpressureを検討した
- Agentをキャンセルできる
- Tool CallにIdempotencyを持たせた
- Provider障害時のFallback方針がある
Observability
- request / agent / toolを同じTraceで追跡できる
- model IDを記録する
- prompt versionを記録する
- retrieval versionを記録する
- latencyを工程別に分解する
- token usageを記録する
- task successを記録する
- tenant単位のCostを確認できる
Security
- API KeyをSecrets Manager等で管理する
- Agent Sandboxからのegressを制御した
- MCP Serverをallowlist化した
- Toolごとの権限を最小化した
- AI Traceの機密情報をredactする
- Kill Switchを用意した
導入時の注意点とリスク
Retry Storm
AI APIの429や5xxに対して全Workerが同時Retryすると障害を悪化させます。
通常の分散システムと同じように、
- exponential backoff
- jitter
- circuit breaker
- queue
を使います。
Agent Loop
Agentが、
Search
→ Think
→ Search
→ Think
→ Search
...
を繰り返す可能性があります。
必ず、
- max steps
- max tokens
- max duration
- max cost
などの実行Budgetを設定します。
Trace自体の情報漏洩
Agent Traceには、
- User Prompt
- 社内文書
- DB検索結果
- Tool引数
- APIレスポンス
が含まれ得ます。
Observability Platformを「単なるログ置き場」と考えず、機密データストアとして扱います。
推奨情報源
- Amazon Bedrock AgentCore
- OpenAI Agents API
- OpenAI Developers
- OpenTelemetry GenAI Semantic Conventions
- MCP Specification
- NIST AI Risk Management Framework