AI SRE（障害対応をAIが支援する仕組み）を検討しているSREやオンコール担当者に向けた内容です。導入すればMTTR（平均復旧時間、障害発生から解決までの平均時間）が劇的に縮む、という期待だけで進めると、思ったほど効果が出ない落とし穴にはまります。
よくある誤解は「アラートに気づくのが遅いからMTTRが伸びる」という前提です。ページャーやアラート基盤がすでに整備された環境では、検知から一次通知までは十分速いことがほとんどです。時間が本当に消えているのは、アラートが鳴った後の「何が起きているか調べる」区間です。
何が起きるか：時間はどこで消えているか
MTTRは1つの数字として語られがちですが、実際には複数の小さな時計の合計です。検知、確認、状況把握、調査、緩和、検証、連絡、解決、記録という段階に分解できます。
このうち検知と確認（アラートに気づいて一次対応を始めるまで）は、監視ツールとページング基盤の進化で既にかなり短縮されています。問題は「調査」の段階です。ここは1つの作業ではなく、圧力下での探索作業になります。
エンジニアはダッシュボード、ログ、トレース、デプロイ履歴、フィーチャーフラグの状態、所有者マップ、直近のプルリクエスト、依存関係図、過去の障害記録、ランブック（対応手順書）、顧客報告、そして「前にも似たことがあった気がする」という記憶の間を行き来します。機械的な作業と判断が必要な作業が同時進行するため、時間の見積もりが難しくなります。
もう1つ見落とされがちな時計が、緩和後から事後分析（ポストモーテム）完了までの区間です。サービスが安定した後、チャットログとダッシュボードとタイムスタンプから障害の経緯を再構成する作業に数日かかることもあります。記憶が薄れた状態で書かれた再発防止策は、当然ながら精度が落ちます。
なぜ起きるか：AI導入だけでは解決しない構造的な原因
AI SREが効果を出すのは「アラートから根拠のある仮説」までの時間を圧縮できる場合です。裏を返せば、入力となるデータの質が悪ければ、AIは弱い材料から推論することになり、結果として速い誤診が生まれます。
原因を段階的に分解すると、次の3層になります。
1つ目は、アラート自体の設計品質です。アラートが症状ベース（ユーザー影響に基づく）ではなく原因ベース（内部指標の閾値超えなど）で発報されていたり、重複や無関係なノイズが多い場合、AIによるトリアージ（重要度の仕分け）は機能しません。AIは悪いアラート設計を救済してくれません。
2つ目は、根拠が残っていないことです。ロールバックが安全かどうかを判断するには、直近のデプロイ履歴・エラー率の変化・依存先サービスの健全性という具体的な証拠が必要です。これらが散在したままだと、AIも人間と同じように探索コストを払うことになります。
3つ目は、権限と自動化の境界が曖昧なことです。トリアージや調査の自動化と、本番環境への変更を自動で実行することは全く別の話です。ここを混同すると、AIに任せられる範囲を過大評価してしまいます。
自分のプロジェクトが該当するか確認する方法
次の項目を確認すると、AI SRE導入で効果が出やすいかどうかの見立てができます。
- アラートルールがSLO（サービスレベル目標、ユーザー体験の許容範囲を数値化したもの）のエラーバジェット消費に紐づいているか、それとも個別の内部メトリクス閾値だけで発報されているか
- 直近のインシデントで「アラートから仮説特定まで何分かかったか」をログや振り返り記録から追えるか
- ランブックが最新のアーキテクチャ（サービス依存関係やデプロイ経路）を反映しているか、更新日を確認する
- IaC（Infrastructure as Code、TerraformやPulumiなどでインフラ定義をコード管理する仕組み）を使っている場合、直近の変更履歴（
terraform planの実行ログやGitのコミット履歴）が障害調査時にすぐ参照できる状態か - オブザーバビリティツール（Datadog、Grafana、Honeycombなど）でログ・メトリクス・トレースが同じインシデントIDやトレースIDで横断検索できるか
特に最後の2つは実際にコマンドで確認できます。Terraformを使っている場合は次のように直近の変更を洗い出せます。
# 直近のapply履歴をステートのシリアル番号やタイムスタンプで確認
terraform show -json terraform.tfstate | jq '.terraform_version, .serial'
# Gitでインフラ変更のコミット履歴を時系列で確認
git log --since="3 days ago" --oneline -- infra/これで「障害発生時刻の直前にどのインフラ変更があったか」を数十秒で洗い出せるかどうかが分かります。もし手作業で複数のリポジトリやSlack履歴を漁らないと分からない状態なら、AI SRE以前にまず証拠の一元化が課題です。
対策の手順：AI SREを効果的に組み込むステップ
ステップ1: アラートを症状ベースに整理する
内部メトリクス（CPU使用率など）だけでなく、ユーザー影響（レイテンシ悪化、エラー率上昇）に紐づいたアラートに寄せます。SLOのエラーバジェット消費速度をアラート条件に使う設計が代表例です。
ステップ2: 調査に必要な情報を1箇所に集約する
デプロイ履歴、依存関係図、所有者マップ、過去のインシデント記録を、インシデント発生時に自動で引ける状態にします。オブザーバビリティ基盤側でトレースIDを共通キーにして横断検索できるようにしておくと、AIによる自動要約の精度も上がります。
ステップ3: AIの役割を「読む・要約する」範囲に限定する
最初の導入では、アラートのグルーピング、重複抑制、影響範囲の要約、類似インシデントの提示といった読み取り中心のタスクに絞ります。本番変更の自動実行は含めません。
ステップ4: 緩和直後に証拠を保存する仕組みを作る
インシデントがまだ記憶に新しいうちに、AIがチャットログとメトリクスのスナップショットを自動保存する運用を入れます。これによりポストモーテムの質が「誰がメモを取ったか」に依存しなくなります。
ステップ5: 効果測定は「アラートから仮説確定まで」の時間で行う
MTTR全体ではなく、調査区間の時間を個別に計測します。導入前後でこの区間がどれだけ縮んだかを見れば、AI SREの実際の貢献度を切り分けられます。
まとめ
AI SREはオンコール担当者を置き換える技術ではなく、アラートから根拠ある仮説までの時間を縮める補助として位置づけるのが実態に近い使い方です。
効果が出るかどうかは、アラート設計の質と、調査に必要な証拠がどれだけ一元化されているかに大きく左右されます。
まず着手できるのは、直近のインシデントで「アラートから仮説特定まで何分かかったか」を洗い出すことと、Terraformやgit logで変更履歴がすぐ追える状態かを確認することです。この2点が整っていない状態でAI SREを導入しても、期待した効果は出にくいと考えて準備を進めるのが現実的です。