AIでSRE引き継ぎ資料を整える方法｜夜間対応と運用知識の断絶を防ぐ

こんな悩みを抱えていませんか

「オンコール担当が変わるたびに、同じ質問が飛んでくる」「深夜にアラートが鳴っても、対応手順がSlackの過去ログに埋もれていて探せない」「ベテランSREが退職したら、その人しか知らない暗黙知が丸ごと消えた」——こうした悩みは、SREやインフラ運用チームであれば一度は経験しているはずです。

特に深刻なのが夜間対応時の知識断絶です。日中は詳しい先輩にすぐ聞けても、深夜のオンコールでは頼れる人がいません。Runbookが古い、手順が口頭伝承のまま、障害対応のたびに似たようなポストモーテムを書いているのに再発防止策が形式化されていない——こうした状態は、対応時間の長期化やヒューマンエラーの直接的な原因になります。

本記事では、AI（生成AI・LLM）を活用してSREの引き継ぎ資料・運用ドキュメントを効率的に整備し、属人化を防ぐための具体的な方法を解説します。ツールの比較や実践手順、よくある疑問への回答まで、実務にそのまま使える内容にまとめました。

なぜSREの引き継ぎ資料は属人化しやすいのか

まず前提として、SRE領域のドキュメントが陳腐化しやすい理由を整理しておきましょう。

変化の速度が速い: インフラ構成やサービス依存関係は頻繁に変わるため、ドキュメントを書いた瞬間から古くなり始める
緊急対応中は記録が後回しになる: 障害対応の最中はドキュメント整備どころではなく、収束後も疲弊してメモを取らないまま終わることが多い
暗黙知が言語化されにくい: 「このエラーが出たら大体あのサービスが原因」といった経験則は、本人にとって当たり前すぎて文書化する発想に至らない
ドキュメントのフォーマットが統一されていない: 個人ごとに書き方が違うため、読む側の負荷が高く、結局読まれずに廃れる

これらは人力だけで解決しようとすると継続コストが高く、結局は「気づいたら誰も更新しなくなる」という結末を迎えがちです。ここにAIを組み込むことで、記録・整理・更新のハードルを大きく下げることができます。

AI活用 vs 従来手法の比較

項目	従来の手動運用	AI活用型の運用ドキュメント整備
作成コスト	高い（担当者が都度執筆）	低い（ログ・Slack・チケットから自動生成）
更新頻度	低い（後回しになりがち）	高い（定期的な差分検知・自動要約が可能）
表記のばらつき	大きい（個人差が出る）	小さい（テンプレート・AIによる統一）
暗黙知の抽出	本人任せ	対話ログやインシデント記録から抽出可能
検索性	Slack検索頼みで低い	ベクトル検索・要約により高い
新人のキャッチアップ速度	遅い（先輩への質問が必須）	速い（AIチャットで自己解決しやすい）

このように、AIは「ゼロから資料を書く」作業を代替するのではなく、既にある情報（インシデント記録、Slackのやり取り、チケット、Runbookの断片）を集約・要約・構造化することで力を発揮します。

AIでSRE引き継ぎ資料を整える具体的な手順

ステップ1: 既存の情報ソースを洗い出す

まずは散在している情報を棚卸しします。典型的なソースは以下の通りです。

インシデント管理ツールのチケット（PagerDuty、Opsgenieなど）
Slack/Teamsの障害対応チャンネルのログ
既存のRunbook・Wiki（Confluence、Notionなど）
モニタリングツールのアラート履歴とダッシュボード設定
オンコール担当者の個人メモ

これらをAIに読み込ませる前提で、まずはエクスポート可能な形式にまとめておくことが重要です。

ステップ2: インシデント記録をAIで要約・構造化する

過去のインシデント対応ログをLLMに投入し、「発生事象」「初動対応」「原因」「恒久対応」「再発防止策」という一定のフォーマットで要約させます。これにより、バラバラだったポストモーテムが検索可能な知識ベースに変わります。

プロンプト例:

以下はインシデント対応時のSlackログです。
「発生事象」「検知方法」「初動対応」「根本原因」「恒久対応」の
5項目に分けて、Runbook用に構造化してください。
専門用語はそのまま残し、推測は含めないでください。

ステップ3: Runbookをテンプレート化してAIに補完させる

サービスごとに共通のRunbookテンプレート（「よくあるアラート」「確認コマンド」「エスカレーション先」「復旧手順」）を用意し、既存の対応履歴からAIに埋めさせます。人間はレビューと承認に集中できるため、作成時間を大幅に短縮できます。

ステップ4: 定期的な差分チェックを自動化する

インフラ構成やサービス構成が変わった際に、ドキュメントとの乖離をAIに検知させる仕組みを作ります。IaC（Terraformなど）の変更履歴とRunbookの内容を突き合わせ、「この手順は古い可能性があります」とアラートを出す運用が理想です。継続的なドキュメント運用の考え方は [INTERNAL: sre-documentation-culture] でも詳しく解説しています。

ステップ5: オンコール担当向けのAIアシスタントを整備する

夜間対応時に「このアラート、どう対処すればいい？」とAIに聞ける社内チャットボットを用意しておくと、Runbookを探す時間そのものを削減できます。社内Wikiやインシデント履歴をベクトルDBに格納し、RAG（検索拡張生成）構成でLLMに回答させる仕組みが一般的です。

運用に定着させるためのポイント

AIを導入しても、それだけでは資料は自動的に整いません。以下の運用ルールをセットで導入することをおすすめします。

インシデント対応後24時間以内にAI要約を回す: 記憶が新しいうちに一次情報を残す
月次でRunbookのレビュー会を設ける: AIが生成した差分レポートをもとに、実際のインフラと乖離がないか人間が確認する
オンボーディング時にAIチャットボットの利用を必須化する: 新人が先輩に聞く前にまずAIに聞く文化を作る
ドキュメントのオーナーを明確にする: AIが生成した内容でも、最終的な責任者（レビュー担当）を各サービスに割り当てる

こうした運用ルールについては [INTERNAL: oncall-onboarding-checklist] にもチェックリスト形式でまとめています。

FAQ

Q1. AIが生成したRunbookをそのまま本番運用に使っても大丈夫ですか？ A. いいえ、必ず人間のレビューを挟んでください。AIは既存情報の要約・整理には強いですが、誤った推測を含む可能性があります。特に復旧コマンドなど実行を伴う手順は、経験者による検証を経てから公開する運用にしましょう。

Q2. 小規模チームでもAI活用の効果はありますか？ A. あります。むしろ人数が少ないチームほど属人化のリスクが高いため、少ない工数でドキュメントを維持できるAI活用のメリットは大きいです。まずはインシデント要約の自動化など、小さく始めるのがおすすめです。

Q3. 機密情報を含む障害対応ログをAIに読み込ませても問題ないですか？ A. 利用するAIサービスのデータ取り扱いポリシーを必ず確認してください。社内利用限定のプライベート環境で動作するLLMや、学習に利用されない契約形態のサービスを選ぶことが重要です。機密性の高い情報は、社内で完結するRAG構成を推奨します。

Q4. 既存のRunbookが古すぎて使い物にならない場合、どこから手をつければいいですか？ A. 直近3〜6ヶ月のインシデント対応ログをAIに要約させ、頻出するアラートやサービスから優先的にRunbookを再構築するのが効率的です。すべてを一度に整備しようとせず、対応頻度の高いものから着手しましょう。

Q5. AI導入後、ドキュメントの品質はどう評価すればよいですか？ A. 「新人オンコール担当が一人で初動対応できたかどうか」を指標にするのが実務的です。定期的にドライラン（模擬インシデント対応）を実施し、Runbookだけで対応できるかを検証すると品質のギャップが見えてきます。

まとめ：次にやるべきこと

SREの引き継ぎ資料整備は、放置すると属人化が進み、夜間対応の負荷や障害対応の質に直結する重要な課題です。AIは「ゼロから書く」負担を減らし、既存のインシデント記録や対話ログから継続的に知識を抽出・構造化する強力な手段になります。

まず今日からできる最初の一歩として、直近のインシデント対応ログをひとつ選び、AIに「発生事象」「初動対応」「根本原因」「恒久対応」の4項目で要約させてみてください。この小さな一歩の積み重ねが、半年後には検索可能で信頼できるRunbook群に育ちます。

継続的なドキュメント運用の仕組み化については [INTERNAL: sre-documentation-culture]、オンコールのオンボーディング設計については [INTERNAL: oncall-onboarding-checklist] もあわせてご覧ください。ドキュメント整備ツールの選定に迷った場合は、[AFF_LINK: notion_ai] や [AFF_LINK: ai_meeting_notes_tool] のような既存ワークフローに組み込みやすいツールから試してみることをおすすめします。