午前3時、オンコール担当のスマートフォンが1回だけ鳴ります。EventOps編で整えたイベント処理のおかげで、100件のアラートは「外部LLM APIの応答遅延により、問い合わせ対応エージェントのタイムアウト率が上昇」という1件に束ねられています。ここまでは理想どおりです。
問題はその先です。担当者は社内Wikiで「タイムアウト」と検索し、2年前に書かれた手順書を見つけます。書かれているコマンドは今の構成では動かず、肝心なところには「状況に応じて適切に判断すること」とだけ書いてあります。モデルを切り替えてよいのか、エージェントを止めてよいのか、誰に連絡すべきか——手順書は答えてくれません。結局、担当者は寝ているシニアエンジニアに電話をかけます。手順書はあるのに、夜中に誰も使えないのです。
筆者はネットワーク機器ベンダーのNOC（ネットワーク運用センター）とTAC（テクニカルアシスタンスセンター）で長く働き、手順書を書き、使い、直すことを繰り返してきました。その経験から言えるのは、手順書は書いた瞬間から古くなり始めるということです。手順書の価値は「あるかどうか」ではなく、「今夜、初めて当番に入った人がそのまま実行できるかどうか」で決まります。
そしてAIエージェントの運用では、もう1つ新しい論点が加わります。手順書を人だけでなくエージェントが実行するようになることです。人が読めない手順書は夜間対応を属人化させますが、条件のあいまいな手順書をエージェントに実行させれば、今度は自動化が暴走します。
本稿は、AIエージェントを業務で運用している企業の運用担当者、SRE、情報システム部門、そしてAgentOpsの仕組みづくりを任された方を対象に、ランブック（Runbook：定型対応の手順書）を”実行できる手順書”として運用し続けるための規律を整理します。
- はじめに——手順書の”有無”ではなく”実行できるか”を設計する
- 本稿の位置づけ
- なぜ”手順書はあるのに使えない”が起きるのか
- ランブック運用の全体像——5つの規律
- 規律1：アラートとランブックを1対1でひもづける
- 規律2：判断分岐と停止条件を明記する
- 規律3：”人が読む手順”から”エージェントが実行する手順”へ段階的に自動化する
- 規律4：実行ログで手順書の鮮度を管理する
- 規律5：ランブック適用率と手順書起因の失敗率で測る
- 運用サイクル——いつ、何を見るか
- よくある落とし穴
- ランブック運用（RunbookOps）チェックリスト
- よくある質問（Q&A）
- まとめ——”手順書がある”から”今夜、誰でも実行できる”へ
- 参考リンク
- 関連記事
はじめに——手順書の”有無”ではなく”実行できるか”を設計する
多くの組織では、ランブックは「作ること」がゴールになっています。障害が起きるたびに手順書が増え、Wikiのページ数は増えていきます。しかし、アラートが鳴ったときにどの手順書を開けばよいかが分からず、開いても古く、判断の分かれ目が書かれていなければ、手順書が何百ページあっても夜間対応は楽になりません。
本稿で扱う「ランブック運用（RunbookOps）」とは、次の3つを仕組みとして回すことを指します。
- 見つかる：アラート・既知のエラー・変更作業から、該当する手順書に1クリックでたどり着ける
- 実行できる：判断分岐と停止条件が明記され、人でもエージェントでも同じ結果になる
- 古くならない：実行ログによって、手順書が今も正しく動くかを継続的に確認できる
本稿の位置づけ
AgentOpsシリーズの中で、本稿は「1件に絞り込まれたアラートが届いたあと、最初の15分で何をするか」を扱います。既存の記事との関係は次のとおりです。
| 記事 | 扱う範囲 | 本稿との関係 |
|---|---|---|
| インシデント運用編（9/5） | 重大度の判定、指揮系統、事後レビューなどの体制 | 本稿は、体制の中で現場の担当者が実行する手順そのものを扱う |
| AI-SOAR編（9/22） | 自動復旧・自動対応の仕組み | 本稿は、自動化してよい手順と人が判断すべき手順の境界線を運用で管理する |
| 問題管理（ProblemOps）編（10/17） | 再発分析とKEDB（既知のエラーのデータベース） | KEDBに”登録”した暫定回避策を、本稿では“実行できる形”にして保守する |
| 構成管理（CMDB）編（10/20） | 依存関係の地図と影響範囲分析 | 手順書の対象（どのCIに対する手順か）を特定する土台 |
| イベント管理（EventOps）編（10/23） | アラートを束ねて1件にする | 本稿は、その1件に何をするかを扱う（直接の続編） |
なぜ”手順書はあるのに使えない”が起きるのか
1. 見つからない
手順書がWiki、チャットのピン留め、個人のメモ、チケットのコメント欄に散らばっていると、担当者はアラートを見てから手順書を「探す」ことになります。夜間の15分のうち10分を検索に使っていては、手順書の意味がありません。
2. 書いた人にしか読めない
「いつものように確認する」「必要に応じて再起動」「状況に応じて判断」——こうした表現は、書いた本人の頭の中では明確でも、他の人には実行できません。特に判断の分かれ目と止めどころが書かれていない手順書は、経験者にしか使えない”暗黙知のメモ”にとどまります。
3. 古い
モデルのバージョン、プロンプトの版、ツールの接続先、権限の設定——AIエージェントの構成は従来のシステム以上に頻繁に変わります。変更作業のたびに手順書が更新されなければ、手順書は静かに古くなり、ある夜「書いてあるとおりにやったのに直らない」という形で表に出てきます。
4. エージェントに実行させると”止まらない”
AIエージェントに手順書を実行させる場合、新しい失敗が生まれます。人であれば「何かおかしい」と感じて手を止める場面でも、停止条件が書かれていなければエージェントは手順を最後まで進めます。再起動を繰り返す、フォールバック先のモデルにも同じ負荷をかける、影響範囲の大きい操作を確認なしに実行する——あいまいな手順書は、人には属人化を、エージェントには暴走をもたらします。
ランブック運用の全体像——5つの規律
| 規律 | やること | 防ぐ失敗 |
|---|---|---|
| 規律1 | アラート・既知のエラー・変更作業と手順書を1対1でひもづける | 見つからない |
| 規律2 | 判断分岐と停止条件を標準フォーマットで明記する | 書いた人にしか読めない／止まらない |
| 規律3 | “人が読む手順”から”エージェントが実行する手順”へ段階的に自動化する | 自動化の暴走／いつまでも手作業 |
| 規律4 | 実行ログで手順書の鮮度を管理する | 古い |
| 規律5 | ランブック適用率と手順書起因の失敗率で測る | 改善の手がかりがない |
規律1：アラートとランブックを1対1でひもづける
アラートの本文に手順書のリンクを入れる
最も効果が大きく、最も簡単な対策は、すべてのアラートの本文に、対応する手順書のURLを入れることです。Prometheus Alertmanagerなど多くの監視ツールは、アラートに注釈（annotation）として手順書のURLを持たせられます。担当者はアラートを開いた瞬間に手順書にたどり着けます。
原則は「1つのアラートルールに、1つの手順書」です。1つの手順書が複数のアラートを受け持つのは構いませんが、手順書を持たないアラートルールはゼロにすることを目標にします。
アラート以外の”入口”からもひもづける
手順書を開くきっかけはアラートだけではありません。
| 起点 | ひもづけ方 | 例 |
|---|---|---|
| アラートルール | アラートの注釈に手順書URLを記載 | 「エージェントのタイムアウト率上昇」→ RB-012 |
| 既知のエラー（KEDB） | KEDBの各レコードに暫定回避策の手順書IDを記載 | KE-034「特定ツールの認証トークン期限切れ」→ RB-027 |
| 変更作業（MOP） | 作業手順書の切り戻し項目から手順書IDを参照 | モデル版の切り替え作業 → 切り戻し手順 RB-041 |
| CMDBのCI | CIごとに関連する手順書の一覧を保持 | 「問い合わせ対応エージェント」→ RB-012、RB-027、RB-041 |
ProblemOps編で触れたKEDBは、「この症状には、この暫定回避策」を記録する仕組みでした。本稿では、その暫定回避策を手順書として独立させ、IDで参照することを勧めます。KEDBの本文に回避策を直接書き込むと、手順の更新がKEDBの更新に埋もれ、どれが最新か分からなくなるためです。
手順書のないアラートは”鳴らす資格”を問い直す
NOCの現場では「対応手順が書けないアラートは、鳴らしてはいけない」という考え方がありました。手順が書けないということは、受け取った人が何をすべきか決まっていないということです。その場合の選択肢は3つです。
- 手順書を書く：対応すべきアラートなら、最低限の初動手順を書く
- 通知先を変える：即時対応が不要なら、ページングではなくチケットやダッシュボードに回す
- アラートを廃止する：誰も何もしないなら、EventOps編の棚卸しの対象にする
規律2：判断分岐と停止条件を明記する
標準フォーマットをそろえる
手順書の書き方がページごとに違うと、読み手は毎回「どこに何が書いてあるか」を探すことになります。全手順書を同じフォーマットにそろえます。
| 項目 | 内容 |
|---|---|
| ID・タイトル | RB-012「問い合わせ対応エージェント：タイムアウト率上昇」 |
| 対象とトリガー | 対象のCI、ひもづくアラートルール・KEDBレコード |
| 影響と緊急度 | 業務への影響、放置した場合に何が起きるか |
| 前提条件・必要な権限 | 実行に必要なアクセス権、事前に確認すべきこと |
| 確認手順 | 状況を把握するための確認（読み取りのみの操作） |
| 判断分岐 | 確認結果に応じて、どの対応に進むか |
| 対応手順 | 変更を伴う操作。1ステップ1操作で記載 |
| 停止条件 | この条件に当てはまったら手順を中断し、エスカレーションする |
| 復旧確認 | 何がどうなれば「直った」と言えるか |
| エスカレーション先 | 誰に、どの手段で、どの情報を添えて連絡するか |
| 実行モード・最終確認日 | 人が実行／エージェントが提案／エージェントが実行、など（規律3）と、最後に正しく動いた日（規律4） |
ポイントは「確認手順」と「対応手順」を分けることです。読み取りだけの確認は誰が何度実行しても安全ですが、変更を伴う対応はそうではありません。この区別は、後で自動化の範囲を決めるときにもそのまま使えます。
判断分岐は”観測できる事実”で書く
「状況に応じて判断」を、観測できる事実と数値に置き換えます。
【RB-012 判断分岐の例】
確認1：提供元のステータスページに障害情報が出ているか
→ 出ている：分岐Aへ（外部要因）
→ 出ていない：確認2へ
確認2：直近24時間に、このエージェントの変更作業（モデル版・プロンプト版・ツール設定）があったか
→ あった：分岐Bへ（変更起因の可能性。変更作業の切り戻し手順 RB-041）
→ なかった：確認3へ
確認3：タイムアウト率が5分間平均で20%を超えているか
→ 超えている：分岐Aへ
→ 超えていない：経過観察。15分後に再確認し、改善しなければエスカレーション
分岐A：フォールバック用モデルへの切り替え（RB-012-A）
停止条件：切り替え後10分でタイムアウト率が改善しない／
フォールバック先でもエラー率が上昇した
→ 手順を中断し、二次対応チームへエスカレーション
数値の閾値は最初から完璧である必要はありません。書いておけば、外れたときに直せるからです。書かなければ、判断は永遠に個人の頭の中に残ります。
停止条件とエスカレーションを必ず書く
手順書で最も書き忘れられやすく、最も重要なのが停止条件です。「この手順で直らないとき、どこで止まり、誰に渡すか」が書かれていない手順書は、人に対しては「直るまで一人で抱え込め」と言っているのと同じであり、エージェントに対しては「直るまで繰り返せ」と言っているのと同じです。
停止条件には、次のような項目を含めます。
- 時間：手順開始からN分経っても復旧しない
- 回数：同じ操作（再起動、再試行など）をN回実行した
- 想定外の結果：手順書に書かれていない出力やエラーが出た
- 影響の拡大：対応中に影響を受けるユーザーやサービスが増えた
- データへの影響：データの削除・上書き・外部送信が疑われる
AIエージェントならではの手順をそろえておく
従来の「再起動」「切り戻し」に加え、AIエージェントの運用では次のような手順を標準として用意しておくと、初動が速くなります。
- フォールバック用モデル・別リージョンのエンドポイントへの切り替え
- プロンプト・システム指示の版を1つ前に戻す
- 特定のツール（MCPサーバーなど）の一時的な無効化
- エージェントの自律実行を止め、”提案のみ”モードや人の承認待ちに切り替える
- レート制限・同時実行数の引き下げ
- 処理待ちのタスクの一時停止と、再開時の重複実行の防止
規律3：”人が読む手順”から”エージェントが実行する手順”へ段階的に自動化する
自動化は5段階で進める
手順書を一気にエージェントに任せるのではなく、段階を踏んで実行の主体を移していきます。
| レベル | 状態 | 人の関与 | 次の段階に進む条件の例 |
|---|---|---|---|
| L0：文書 | 人が手順書を読み、手で実行する | すべて | 標準フォーマットで書かれ、判断分岐と停止条件がある |
| L1：確認の自動化 | 確認手順（読み取りのみ）を自動で実行し、結果をアラートに添付する | 判断と対応 | 確認結果が手で行ったものと一致し続ける |
| L2：提案 | エージェントが判断分岐をたどり、実行すべき対応を提案する | 承認と実行 | 提案が人の判断と一致する率が十分に高い |
| L3：承認付き実行 | 人が承認すると、エージェントが対応手順を実行する | 承認 | 実行の成功率が高く、手順書起因の失敗がない期間が続く |
| L4：自動実行 | 停止条件の範囲内でエージェントが自動で実行し、事後に報告する | 事後確認と例外対応 | —（継続的に監視し、必要なら段階を下げる） |
多くの組織にとって最初の現実的な目標はL1です。確認手順を自動化して結果をアラートに添えるだけで、担当者が最初の5分で行っていた調査が不要になります。読み取りのみの操作なので、失敗しても被害が出にくいのも利点です。
自動化してよい手順の条件
L3・L4へ進めてよいのは、次の条件をすべて満たす手順に限ります。
- 判断分岐が観測できる事実だけで書けている（「状況に応じて」が残っていない）
- 操作が元に戻せる（切り戻し手順が存在し、検証されている）
- 影響範囲が限定されている（1つのエージェント、1つのサービスにとどまる）
- 人の実行でも十分な回数、成功している（実行ログで確認できる）
- 停止条件が機械的に判定できる（時間、回数、閾値で書かれている）
逆に、データの削除、顧客への連絡、課金や契約に関わる操作、セキュリティ上の判断を伴う操作は、L2（提案）までにとどめ、実行は人が行うのが原則です。この境界線は、HumanOps編で扱った承認キューの設計とあわせて決めておきます。
ガードレールを手順書の”外側”に置く
エージェントが手順書を実行する場合、停止条件を手順書の中に書くだけでは不十分です。エージェントが手順書を読み違える可能性があるからです。手順書の外側、つまり実行基盤の側に、次のようなガードレールを設けます。
- 実行回数の上限：同じ手順を一定時間内にN回以上実行できない
- 権限の最小化：その手順に必要な操作だけを許可した専用の実行権限を使う
- 影響範囲の上限：一度に操作できる対象の数を制限する
- ドライラン：変更を伴う操作は、まず実行内容を出力させて確認する
- キルスイッチ：人がいつでも自動実行全体を止められる
段階は”下げられる”ようにしておく
自動化のレベルは一方通行ではありません。手順書起因の失敗が起きた、対象の構成が大きく変わった、停止条件に該当するケースが増えた——こうした場合には、レベルを1段階下げることをあらかじめルールにしておきます。L4の手順を”事故が起きてから”止めるのではなく、”兆候が出た時点で”L3に戻せる運用が、自動化の暴走を防ぎます。
規律4：実行ログで手順書の鮮度を管理する
手順書は”実行された記録”で生きているかが分かる
手順書の鮮度を「最終更新日」で管理している組織は多いですが、更新日が新しくても内容が正しいとは限りませんし、古くても今なお正しく動く手順書もあります。鮮度を測る最も確かな方法は、実行されたかどうか、実行して成功したかどうかの記録です。
人が実行した場合も、エージェントが実行した場合も、次の項目を記録します。
- 手順書ID・版
- きっかけ（アラート、KEDB、変更作業など）
- たどった判断分岐
- 結果（復旧した／停止条件で中断した／手順どおりに動かなかった）
- 手順どおりに動かなかった場合、どのステップで、何が違ったか
最後の項目が最も重要です。「手順書のステップ4のコマンドが、今の構成では失敗した」という記録は、そのまま手順書の修正チケットになります。NOCでは、対応後に”手順書との差分”を必ず報告させることで、手順書を現場の実態に追従させていました。
鮮度を判断する3つのシグナル
| シグナル | 状態 | 対応 |
|---|---|---|
| 実行され、成功している | 新鮮 | 最終確認日を更新する |
| 実行されたが、手順どおりに動かなかった | 腐敗 | すぐに修正し、修正後に検証する |
| 一定期間（例：90日）実行されていない | 不明 | ゲームデー（訓練）や検証環境で実行して確かめる |
3つ目の「不明」が見落とされがちです。めったに鳴らないアラートの手順書ほど、いざというときに古くなっています。定期的な訓練の場で、実行されていない手順書を優先的に試します。
変更作業をレビューのトリガーにする
手順書が古くなる最大の原因は構成の変更です。ChangeOps編で扱った変更作業の承認プロセスに、「この変更で影響を受ける手順書はどれか。更新したか」という確認項目を加えます。CMDBでCIと手順書がひもづいていれば、影響を受ける手順書の一覧は自動で出せます。
規律5：ランブック適用率と手順書起因の失敗率で測る
2つの失敗を同時に測る
ランブック運用には、2つの方向の失敗があります。手順書が使われない（属人化）失敗と、手順書が間違っている（または自動化が暴走する）失敗です。片方だけを追うと、もう片方が悪化します。
| 指標 | 計算方法 | 何が分かるか |
|---|---|---|
| ランブック適用率 | 手順書にしたがって対応したインシデント数 ÷ 全インシデント数 | 手順書が実際に使われているか |
| ランブック網羅率 | 手順書がひもづいたアラートルール数 ÷ ページングするアラートルール数 | “手順書のないアラート”がどれだけ残っているか |
| 手順書起因の失敗率 | 手順どおりに動かなかった・手順書の誤りで悪化した実行数 ÷ 全実行数 | 手順書の品質と鮮度 |
| 停止条件の発動率 | 停止条件で中断した実行数 ÷ 全実行数 | 手順書がカバーできない状況の多さ。高すぎれば分岐の不足、ゼロなら条件が機能していない可能性 |
| 初動時間 | アラート発生から最初の対応操作までの時間 | 手順書が”最初の15分”を短くしているか |
| 自動化レベルの分布 | L0〜L4それぞれに属する手順書の数 | 自動化の進み具合と偏り |
適用率を上げようとして手順書の数だけを増やせば、手順書起因の失敗率が上がります。自動化レベルを上げようとして停止条件を緩めれば、停止条件の発動率が下がり、見かけ上は順調に見えたまま事故につながります。適用率と失敗率、自動化レベルと停止条件の発動率を、必ず組で見ることが大切です。
手順書ごとに棚卸しする
全体の数字に加えて、手順書ごとに実行回数、成功率、最終確認日、自動化レベルを一覧にし、定期的に棚卸しします。「よく使われるが失敗が多い手順書」は最優先で直し、「長く使われていない手順書」は訓練で確かめるか、関連するアラートとあわせて廃止を検討します。
運用サイクル——いつ、何を見るか
| 頻度 | やること | 担当 |
|---|---|---|
| 対応のたび | 実行ログの記録、手順書との差分の報告 | オンコール担当（人・エージェント） |
| 毎週 | 手順書起因の失敗の修正、新しいアラートへの手順書の追加 | 運用チーム |
| 変更作業のたび | 影響を受ける手順書の更新と検証 | 変更作業の担当者 |
| 毎月 | KPIの確認、自動化レベルの見直し（上げる・下げる） | 運用リーダー |
| 四半期ごと | 未実行の手順書の訓練（ゲームデー）、手順書の棚卸しと廃止 | 運用チーム全体 |
よくある落とし穴
- 手順書を”作って終わり”にする：作成をプロジェクトとして完了させ、更新の担当と仕組みがない
- 1つの手順書にすべてを書く：何十ステップもある巨大な手順書は、夜中には読み切れない。初動と詳細調査を分ける
- 判断を”経験者に確認”で済ませる：エスカレーション先として書くのはよいが、判断基準そのものを書かないと永遠に属人化する
- 自動化の成功だけを報告する：停止条件で止まったケースや、提案が却下されたケースこそ、手順書を改善する材料になる
- エージェントに手順書全文を渡して”よしなに”実行させる：判断分岐や停止条件をエージェントの解釈に委ねると、規律2・3が意味をなさなくなる
- 手順書をKEDBやチケットに埋め込む：同じ手順が複数の場所にコピーされ、どれが最新か分からなくなる
ランブック運用（RunbookOps）チェックリスト
| 領域 | 確認項目 |
|---|---|
| ひもづけ | ページングするすべてのアラートに手順書のURLが入っているか |
| ひもづけ | KEDBの暫定回避策、変更作業の切り戻しが手順書IDで参照されているか |
| フォーマット | 全手順書が同じ標準フォーマットで書かれているか |
| フォーマット | 確認手順（読み取り）と対応手順（変更）が分かれているか |
| 判断分岐 | 「状況に応じて判断」が観測できる事実と数値に置き換えられているか |
| 停止条件 | 時間・回数・想定外の結果・影響拡大の停止条件とエスカレーション先が書かれているか |
| 自動化 | 手順書ごとに自動化レベル（L0〜L4）が決まっているか |
| 自動化 | 自動実行の外側に、実行回数の上限、最小権限、キルスイッチがあるか |
| 自動化 | レベルを下げる条件があらかじめ決まっているか |
| 鮮度 | 実行ログ（たどった分岐、結果、手順書との差分）が記録されているか |
| 鮮度 | 変更作業の承認時に、影響を受ける手順書の更新を確認しているか |
| 鮮度 | 一定期間実行されていない手順書を訓練で確かめているか |
| 測定 | 適用率・網羅率・手順書起因の失敗率・停止条件の発動率を定期的に見ているか |
よくある質問（Q&A）
Q1. 手順書がほとんどない状態から、何を優先して書けばよいですか？
過去3か月にページングが発生したアラートを、発生回数の多い順に並べ、上位から初動手順を書くのが現実的です。最初は確認手順・判断分岐・停止条件・エスカレーション先の4つだけでも構いません。完璧な手順書を1本書くより、最低限の手順書を10本そろえるほうが、夜間対応は確実に楽になります。
Q2. 手順書はWikiとコード（自動化スクリプト）のどちらで管理すべきですか？
人が読む部分はWikiやドキュメント、エージェントや自動化基盤が実行する部分はコードとしてバージョン管理するのが一般的です。重要なのは、両者が同じ手順書IDでひもづき、片方を更新したらもう片方も確認する運用になっていることです。L1以上に自動化した手順は、コードとして変更履歴とレビューを残すことを勧めます。
Q3. LLMに手順書を書かせてもよいですか？
過去の対応記録や事後レビューから、手順書の下書きを作らせるのは有効です。ただし、判断分岐の閾値や停止条件は、実際の運用経験を持つ人が確認し、検証環境や訓練で一度は実行してから正式な手順書にしてください。もっともらしいが動かない手順書は、手順書がない状態より危険です。
Q4. エージェントに手順書を実行させると、運用担当者のスキルが落ちませんか？
その懸念はもっともです。対策として、L2（提案）やL3（承認付き実行）の段階では、エージェントがどの分岐をなぜ選んだかを担当者に示し、担当者が判断の根拠を理解したうえで承認する形にします。また、訓練（ゲームデー）では自動化を止め、人が手順書を使って対応する機会を意図的に作ります。
Q5. 停止条件の発動率はどの程度が適切ですか？
一律の正解はありませんが、ゼロが続く場合は「停止条件が緩すぎる」「そもそも判定されていない」可能性を疑ってください。逆に高い場合は、判断分岐が現実の状況をカバーできていないサインです。停止条件で中断したケースを毎週振り返り、分岐を追加するのか、エスカレーションが正しい対応なのかを判断していくことで、適切な水準に近づいていきます。
まとめ——”手順書がある”から”今夜、誰でも実行できる”へ
ランブックは、アラートを受け取った担当者が最初の15分で何をするかを決めるものです。手順書の価値は、量ではなく、今夜初めて当番に入った人——そしてエージェント——が、同じ結果を出せるかどうかで決まります。
1. 見つかるようにする。 アラート・既知のエラー・変更作業と手順書を1対1でひもづけ、手順書を持たないアラートはゼロにします。
2. 止まれるようにする。 判断分岐を観測できる事実で書き、停止条件とエスカレーション先を必ず明記します。それが人の属人化と、エージェントの暴走の両方を防ぎます。
3. 実行の記録で育てる。 自動化は段階的に進め、いつでも下げられるようにします。実行ログで鮮度を確かめ、適用率と手順書起因の失敗率を組で測ります。
手順書は書いた瞬間から古くなり始めます。だからこそ「書く、使う、記録する、直す」を回し続けることが、手順書を”実行できる手順書”にし続ける唯一の方法です。
参考リンク
- Google SRE Book: Being On-Call
- Google SRE Book: Eliminating Toil
- Google SRE Workbook: On-Call
- Prometheus Alertmanager
- AWS Systems Manager Automation
- NIST SP 800-61 Rev. 3: Incident Response Recommendations and Considerations for Cybersecurity Risk Management
関連記事
- 【AgentOps・イベント管理（EventOps）編】”アラートが100件鳴って、原因は1つ”をなくす
- 【AgentOps・問題管理（ProblemOps）編】再発分析と既知のエラー管理
- 【AgentOps・構成管理（CMDB）編】依存関係の地図と影響範囲分析
- 【AgentOps・変更管理（ChangeOps）編】変更カレンダー・MOP・切り戻し
- 【AgentOps・HumanOps編】承認キューとエスカレーション
免責事項
本記事は、AIエージェントの運用における手順書（ランブック）管理の一般的な考え方を整理したものであり、特定の製品・サービスの動作や効果を保証するものではありません。設計・導入にあたっては、ご自身のシステム構成、利用するツールやサービスの仕様、社内の規程を必ずご確認ください。
コメント