AIエージェント運用Runbook設計：異常時に人間が迷わない手順書の作り方

TL;DR

• AI運用では「自動で直す」前に「安全に止める」手順が必要
• Runbook は 検知・初動・切り戻し・再開条件 の4要素で設計できる
• 人間の判断ポイントを先に固定すると、夜間対応でも迷いにくい
• エスカレーション設計や可観測性と組み合わせることで Runbook の実効性が上がる

はじめに

AIエージェントを本番環境で動かし始めると、想定外の出力やループ暴走、外部API障害など「止めなければいけない瞬間」が必ずやってくる。そのとき手元に手順書がなければ、オンコール担当者は判断に迷い、対応が遅れる。

この記事では、AIエージェント運用に必要な Runbook（運用手順書） の設計方法を、4つの構成要素に分けて解説する。

:::message 想定読者は、AIワーカーや自動化フローを本番運用し始めた開発チームです。「障害が起きたときに何をすればいいかわからない」状態を脱するための最初の一歩として活用してください。 :::

1. なぜ AI 運用に Runbook が必要か

従来のソフトウェア運用でも Runbook は使われてきたが、AIエージェント運用では以下の理由で 重要度がさらに高い。

• 出力が非決定的: 同じ入力でも異なる出力を返す可能性があり、「正常」の定義が曖昧になりやすい
• 連鎖的な影響: エージェントが自律的に次のアクションを選択するため、1つの異常が連鎖して被害が拡大する
• 判断の属人化: 「AIの出力がおかしいかどうか」の判断が特定のメンバーに依存しがち

特に自律ループを回すエージェントは、停止タイミングを逃すとリソースを浪費し続ける。Runbook で「いつ・誰が・どう止めるか」を事前に定義しておくことが不可欠だ。

想定する障害パターン

AIエージェント固有の障害パターンを把握しておくと、Runbook の粒度を適切に設計できる。

2. Runbook の4構成要素と初動・切り戻し設計

Runbook は以下の4要素で構成する。各要素に 判断基準（いつ） と 手順（何をするか） を明記することがポイントだ。

要素1: 検知 — 異常をどう見つけるか

可観測性の基盤が整っていれば、検知はアラートで自動化できる。最低限、以下の指標を監視対象にする。

• エラー率: 直近N分間のタスク失敗率が閾値を超えたらアラート
• ループ回数: 同一タスクの再試行回数が上限を超えたらアラート
• コスト: API呼び出しコストが日次予算の80%を超えたらアラート

# alert-rules.yaml（例）
rules:
  - name: agent-loop-runaway
    condition: "retry_count > 5 AND task_id = same"
    severity: critical
    action: page-oncall

  - name: agent-cost-warning
    condition: "daily_api_cost > budget * 0.8"
    severity: warning
    action: notify-slack

要素2: 初動 — 最初の5分で何をするか

アラートを受けたオンコール担当者が、最初の5分で実行する手順を定義する。

1. エージェントの一時停止: 実行中のジョブをgracefulに停止する
2. 影響範囲の確認: どのタスク・データが影響を受けたかをログから特定する
3. ステークホルダーへの通知: Slackチャンネルに状況を投稿する

# エージェントの一時停止（例）
curl -X POST https://api.internal/agents/pause \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"agent_id": "worker-01", "reason": "runbook-triggered"}'

重要なのは、初動の段階では原因究明をしない こと。まず止めて、安全を確保してから調査に入る。

要素3: 切り戻し — 安全な状態に戻す

エージェントが行った変更を元に戻す手順を事前に用意する。

• データの復元: エージェントが更新したレコードをバックアップから復元する
• 成果物の取り消し: 生成されたファイルやPRをrevertまたはクローズする
• 依存サービスへの通知: 下流システムに「このデータは無効」と伝える

# 直近のエージェント操作をrevert（例）
git log --author="ai-agent" --since="1 hour ago" --oneline
git revert <commit-hash> --no-edit

切り戻し手順は障害パターンごとに分岐させる。ループ暴走なら停止だけで済むが、幻覚出力によるデータ破損は復元が必要になる。

要素4: 再開条件 — いつ動かしていいか

再開の判断基準を曖昧にすると「とりあえず動かしてまた壊れる」を繰り返す。以下を すべて満たした場合のみ 再開する。

• 根本原因が特定され、修正がデプロイされた
• 切り戻し後のデータ整合性が確認された
• 監視アラートの閾値が適切か再評価された
• 再開判断者（チームリーダー以上）の承認を得た

3. Runbook の実効性を高める運用のコツ

Runbook は書いただけでは機能しない。以下の運用を組み合わせることで実効性が上がる。

エスカレーションとの連携: Runbook の初動で解決しない場合、エスカレーション設計に従って判断を上位者に委ねる。Runbook に「エスカレーション条件」を明記しておくと、担当者が自分の判断範囲を超えたときに迷わない。

ガバナンスへの組み込み: Runbook は単独のドキュメントではなく、デリバリー統治の仕組みの一部として管理する。変更レビューや定期監査の対象に含めることで、陳腐化を防ぐ。

チーム全体での訓練: AIチーム運用の役割分担に基づいて、誰がRunbookのどのステップを担当するかを明確にし、月次で机上訓練（テーブルトップエクササイズ）を行う。実際にアラートを鳴らして対応する模擬訓練が最も効果的だ。

定期的な見直し: 新しい障害パターンが発生したら、ポストモーテム（事後振り返り）の結果をRunbookに反映する。最低でも四半期に一度はRunbookの全体を見直す。

まとめ

AIエージェント運用のRunbookは、検知・初動・切り戻し・再開条件 の4要素で設計する。ポイントは「自動で直す」前に「安全に止める」手順を最優先にすること、そして人間の判断ポイントを事前に固定しておくことだ。

まずは「誰が止めるか」「どこまで自動で戻すか」だけでも先に言語化してほしい。Runbookは完璧を目指して書くものではなく、最初の一版を作ってから訓練と振り返りで育てるものだ。

次のアクション:

• 自チームのAIエージェントが起こしうる障害パターンを3つ洗い出す
• 各パターンに対して4要素（検知・初動・切り戻し・再開条件）を1行ずつ書いてみる
• エスカレーション設計と合わせて、判断の委譲ルールを決める