本番環境でAIエージェントにSREの原則を適用する—オーナーシップ、可観測性、SLO、ランブック、そしてキルスイッチ・パターン。
私は1年間、AIエージェントが現場でどのように失敗するのかを深く研究してきました—インシデント、ポストモーテム、そして実際の運用パターンの中でです。そして気づき続けているのは、誰も話題にしないギャップがあるということです。チームは「能力」を称えます。運用上の準備ができていることは誰も作りません。
以下は、そのギャップが何をコストとして生み、どう埋めるかです。
ギャップ：AIエージェントはサービスではなく“機能”として扱われがち
従来のSREでは、すべての本番サービスに：
✅ ページャを持つ指名オーナー
✅ 定義されたSLO
✅ オンコールのローテーション
✅ ランブック
✅ ポストモーテムのプロセス
ほとんどのAIエージェントにはデモ動画とSlackチャンネルがあります。
これはカテゴリの誤りです。エージェントは“機能”ではありません。自律的な意思決定を行うサービスであり、あなたの自動化の速度で動きます。失敗したとき、壊れたボタンのように静かにフェイルするわけではありません。失敗率はあなたの自動化のスループットに比例して起きます。しかも多くの場合、外部への副作用を伴います：送信されたメール、呼び出されたAPI、書き込まれたレコード。
誰も話題にしない失敗
誰もが備えるのに、最もあるのは“致命的な失敗”です。例外が投げられる、タイムアウトする、500エラーになる。これらは捕捉しやすい。CloudWatchのアラーム、SNS通知、完了。
しかし誰も備えていないのは“サイレントな劣化（silent degradation）”です。
エージェントはタスクを完了します。ダッシュボードは緑のままです。ですが直近6時間、推論が微妙に間違っていました—誤ったツールを選び、スコープを誤って解釈し、正しそうに見えるものの実際には違う出力を生成している。
これが最悪のケースです。失敗ではなく、“もっともらしいが検知されず、誤った行動がスケールしてしまう”こと。
従来の可観測性では捕まえられません。新しいレイヤーが必要です。
HERの導入：Human Escalation Rate（人手へのエスカレーション率）
エージェントの健全性について、私が見た中で最も役立つシグナルは、多くのチームが追跡していないものです：
HER =（人の介入が必要だった意思決定 / 総意思決定）× 100
HERは、AIエージェントにとってエラー率がAPIに対して果たす役割と同じです。エージェントの判断が維持できているかどうかが分かります。
シンプルな実装例は以下です：
pythondef publish_her_metric(agent_id: str, human_overrides: int, total_decisions: int):
her = (human_overrides / total_decisions) * 100 if total_decisions > 0 else 0
# メトリクスストアにプッシュ
metrics.gauge(
"agent.human_escalation_rate",
her,
tags=[f"agent_id:{agent_id}"]
)
# 指標が閾値を超えたらアラート
if her > THRESHOLD:
alert_oncall_owner(agent_id, her)
return her
HERが閾値を超えたら、指名された人間がページを受けます。チームではありません。Slackチャンネルではありません。人です。
本番投入の前に：どのAIエージェントにも最低限必要な3つの要件
私が観察し、学んだすべてに基づくと、譲れない条件は以下です。
- ページされる指名の人間オーナー オーナーシップのモデルは、ツールよりも重要です。 すべてのエージェントには、HERが閾値を超えたときに責任を持つ“指名された個人”が必要です。共有オーナーシップはオーナーシップではありません。「AIチームが所有している」というのは、誰も所有していないことを意味します。 書き残してください： yamlagent: name: document-processor-v2 owner: ajay.devineni@company.com pager: +1-xxx-xxx-xxxx slack_handle: "@ajay" escalation_policy: p1-sre-rotation
- 少なくとも4つの失敗モードをカバーするランブック エージェントがリリースされる前にランブックが存在していなければなりません。最低限のカバレッジ： 失敗モード何を見るか即時のアクションTool failureツールエラー率のスパイク依存関係の健全性を確認し、進行中タスクを評価Context degradation出力長の増加、HERの急上昇会話履歴を確認し、プロンプトをロールバックPrompt drift行動のベースラインからの逸脱デプロイを凍結し、プロンプトのバージョンを比較Blast radius event定義されたスコープ外で動作しているキルスイッチを起動し、副作用を監査 ランブックは20ページである必要はありません。深夜2時でも“正しくて辿り着ける”ことが必要です。
- SLOを設定する前に30日間の行動ベースライン 最も多くのチームが飛ばしてしまうのはこれです。遅いと感じるからです。 計測していない信頼性にはコミットできません。 エージェントを30日間シャドーモードで実行してください—実際の入力を処理し、実際の出力を生成しますが、行動の前にレビューします。この期間中は、すべて測定します：
タスク完了率
人手へのエスカレーション率（ベースラインHER）
ツール呼び出しの正確さ
意思決定の遅延（p50/p95/p99）
コンテキストウィンドウの利用率
同一入力に対する出力品質スコアのばらつき
30日経った後で初めてSLOを書きます。ベースラインがSLOの土台です。
yaml# ベースライン後に書いた例のSLO
agent_slo:
valid_from: "after-30d-baseline"
objectives:
- metric: task_completion_rate
target: 99.2%
baseline_observed: 99.6% # 余裕を意図的に組み込む
- metric: human_escalation_rate
target: "< 3%"
baseline_observed: 1.8%
alert_threshold: 5%
キルスイッチ・パターン
本番環境のすべてのエージェントにはキルスイッチが必要です。コードをデプロイせずに、実行を即座に停止する仕組みです。
pythondef check_kill_switch(agent_id: str) -> bool:
"""
設定ストアでキルスイッチの状態を確認します。
SSM Parameter Store、LaunchDarkly、
あるいは任意の機能フラグシステムで動作します。
"""
status = config_store.get(f"agents/{agent_id}/kill-switch")
return status == "ACTIVE"
def agent_task_loop(agent_id: str, tasks: list):
for task in tasks:
# 起動時だけでなく、あらゆる意思決定の前にチェック
if check_kill_switch(agent_id):
log_halt(agent_id, task)
raise AgentHaltException("Kill switch active")
execute(task)
キルスイッチは以下であるべきです：
デプロイなしで切り替え可能（コードではなく設定ストア）
起動時だけではなく、すべての意思決定の前に確認されること
監査される—すべてのチェックと、すべての有効化をログに残すこと
可観測性スタックは実際にはこう見える
エージェント実行時
│
├──▶ 構造化ログ（JSON、意思決定ごとに1エントリ）
│ └── フィールド：session_id、tool_calls、human_override、confidence、latency
│
├──▶ カスタムメトリクス
│ └── HER、ツールエラー率、コンテキスト利用率、意思決定の遅延
│
├──▶ 分散トレース
│ └── 入力 → LLM → ツール呼び出し → 出力までのエンドツーエンド
│
├──▶ イベントストリーム（エージェントの意思決定ごとに1イベント）
│ └── アラートルールと下流の監査を可能にする
│
└──▶ 意思決定監査ログ（不変）
└── S3 / ブロブストアに保持し、ポストモーテム分析のために保持する
すべてのエージェントの意思決定は、構造化ログのエントリを出力すべきです：
json{
"timestamp": "2025-01-15T14:23:01Z",
"agent_id": "doc-processor-v2",
"session_id": "sess_abc123",
"tools_called": ["search", "summarize"],
"tool_success": [true, true],
"human_override": false,
"context_utilization_pct": 47.1,
"latency_ms": 3420,
"task_completed": true
}
これが監査証跡です。これがポストモーテムで持ち込むものです。
誰も聞かないポストモーテムの問い
従来のサービスでインシデントが起きた後、ポストモーテムでは次を尋ねます：
何が失敗したのか？
なぜ失敗したのか？
再発を防ぐにはどうするのか？
AIエージェントでは、ほとんど誰も聞かない4つ目の問いがあります：
エージェントが間違っていた“期間”があって、私たちがそれに気づいていなかったのでは？
ダッシュボードが緑だったため、サイレントな劣化の期間は従来のポストモーテムでは見えません。すべてのポストモーテムテンプレートに行動ベースラインの比較を追加することで、この問いを表に引きずり出せます。
あなたのエージェントは本番投入に対応できているか、それともデモ用か？
返却形式: {"translated": "翻訳されたHTML"}
SREコミュニティは、分散システムを確実に運用する方法を学ぶのに20年を費やしてきました。その教訓――オーナーシップ、可観測性、SLO、ランブック、ポストモーテム――は、会議室で考案されたものではありません。停電・障害（アウトేజ）を通じて得られたものです。
AIエージェントは、予測不能性という追加の次元を備えた分散システムです。つまり、彼らは意思決定を行います。
次のエージェントが出荷される前に、次のチェックリストを実行してください。
ページャが割り当てられた人間の責任者（Named human owner）
ツールの失敗、コンテキストの劣化、プロンプトのドリフト、影響範囲（blast radius）をカバーするランブック
HERメトリクスが計測され、アラートが設定されている
キルスイッチが実装され、テスト済み
30日間のシャドーモードのベースラインが完了している
ベースラインデータから書かれ、導出されたSLO
ポストモーテムのテンプレートを更新し、行動ベースラインとの比較を含める
どれか1つでもチェックが外れている場合、あなたのエージェントはデモに向けて準備済みです。プロダクション向けではありません。
著者: Ajay Devineni | LinkedIn でつながる
