AIエージェント時代のオンコール再設計——一次対応をAIに任せる時代、人間に残る役割は何か

夜中の3時に電話が鳴る。画面を見ればアラート通知。眠い目をこすりながらダッシュボードを開き、ログを漁り、20分後に「既知の問題だった」と気づく。それが週に何度も続く。

これはどこかのチームの作り話ではない。PagerDutyが2026年3月に発表したレポートでは、平均的なオンコールエンジニアが週に約50件のアラートを受け取るが、実際に人間の判断が必要なのはそのうち2〜5%程度だという。9割以上は、起こされる必要のないアラートだ。

その疲弊が組織に与えるダメージは大きい。SREの約70%が「オンコールのストレスがチームの燃え尽きと離職に影響している」と回答しており（Catchpoint「SRE Report 2025」7th Edition）、筆者の知る範囲でも、シニアSREがオンコール負荷を理由に退職するケースを複数見てきた。

2025〜2026年にかけて、この構造に本質的な変化が起きている。AIエージェントが一次対応を自律実行するようになったのだ。EMとして今問われているのは「AIを使うか使わないか」ではなく、「AIが一次対応を担う前提でチームをどう再設計するか」だと思っている。

オンコールの現実——AIが来る前から機能不全だった

2025年のデータを見ると、問題の深刻さがよくわかる。

Catchpoint「SRE Report 2025」によれば、SREが業務時間に占める運用作業の割合（中央値）は25%から30%へ上昇した。5年ぶりの増加だ。いわゆる「トイル」——繰り返しの手作業——が増え続けている状況で、生成AIブームによる新サービス投入でシステムが複雑化したことが背景にある。

アラート疲弊も深刻だ。73%の組織が「無視または抑制されたアラートに起因する障害」を経験している（runframe.io「State of Incident Management 2026」）。本物のアラートが埋もれて見落とされるという皮肉な構造が、多くのチームで起きている。

ビジネスインパクトで言えば、8%の組織がインシデント1件あたり時間あたり100万ドル超の損失を報告しており、34%が50万ドル超という数字もある。ブランド・評判への損傷（52%）や復旧コスト（50%）に加えて、エンジニアの燃え尽き（42%）が直接のビジネスリスクとして並んでいることが興味深い。

この状況を「人を増やせば解決する」と考えるのは難しい。増やしても、トイルとアラートノイズも一緒に増えるからだ。

AI一次対応の現在地——2025〜2026年のプロダクト群

「AIがインシデントに自律対応する」という話は、もはや実験段階ではない。

PagerDuty SRE Agent

PagerDutyは2026年3月にAIエージェントスイートを発表し、Spring 2026リリースで「SRE Agent as Virtual Responder」の早期アクセスを開始した。16年分の過去インシデントデータを基盤とし、検出・トリアージ・深層診断を人間が起床する前に完了させる。H2 2026には完全自律対応版の早期アクセスが予定されている。

スケジューリング面では「Shift Agent」も注目に値する。AIがオンコール競合を自動検出し、カバレッジを推薦し、シャドーローテーション（新人がページを受けずにシフトを観察できる機能）を提供する。フォロー・ザ・サン設計への対応も含まれており、タイムゾーンをまたいだチーム運用を大幅に簡素化する。

Datadog Bits AI SRE

Datadog Bits AI SREは2025年12月に全ユーザー向けにGA（一般提供）が開始した。アラート発生と同時に自動調査を始め、複数の根本原因仮説を動的に生成・検証する。Slack・MS Teamsへのメッセージ送信、インシデント作成、エンジニアへのページング、Jiraチケット作成など7つのトリアージアクションを自律実行できる。公式発表ではサービス復旧の従来比90%高速化という数字が示されており、2026年3月のアップデートでは処理速度が2倍になったと報告されている。

Incident.io AI SRE

Incident.ioは2025年4月に6,200万ドルを調達し、AI SREをメインプロダクトとして展開する。Netflix・Etsy・OpenAI・Airbnbを含む600以上の組織が利用しており、インシデント対応の最初の80%を自動化するというコンセプトで開発されている。1〜2分以内にSlack内で調査レポートを提示し、コード修正案とPRを自動生成する機能が特徴的だ。

AWS DevOps Agent（Bedrock AgentCore）

AWS DevOps Agentはre:Invent 2025でプレビュー発表ののち、2026年3月31日にGA。CloudWatchアラート・PagerDuty・Dynatrace・ServiceNowのイベントを検知し、人間の指示なしに調査を開始する。GitHub/GitLabの最近のコードデプロイとメトリクス・ログを相関分析し、根本原因を特定する。プレビュー段階のユーザー報告ではMTTR最大75%削減、根本原因特定精度94%という数字が出ている。

AWSはさらに「マルチエージェントSREアシスタント」の構築ガイドも公開しており、スーパーバイザーエージェントが調査計画を立て、Kubernetes・ログ・メトリクス・ランブック担当の専門エージェントに指示を出すハブ&スポーク型アーキテクチャを紹介している。実際にDruva社はこの構成を3,000社以上に展開し、時間解決率が58%向上、63%の課題を人間介入なしで解決できると報告している（AWS公式ブログ）。

国内の動き

国内でも実装は進んでいる。メルカリはLLMとベクトル検索を組み合わせた「IBIS」（LLM × SRE Incident Handling Buddy）を2025年1月から本番チャンネルに統合している。Blamelessからエクスポートした過去インシデント報告書をベクトル化してBigQueryに蓄積し、Slackから自然言語で類似過去事例を検索できる仕組みだ。メルカリエンジニアリングブログによれば、ユーザー採用は成長中で、MTTRへの定量的影響は現在計測中とのことだ。

ZalandoはLLMを使って数千件のポストモーテムを横断分析する仕組みを構築し、分析時間を「日単位から時間単位」に短縮、生産性3倍向上を報告している。これは一次対応の自動化ではなく「死んだデータ」を「学習の金鉱」に変える取り組みだが、組織的な再設計の参考になる（Zalando Engineering Blog）。

AIが吸収した後、人間に残るTier 2の仕事

AIが既知パターンのランブック実行・アラートトリアージ・初動のログ調査・類似事例検索・ポストモーテムの初稿作成を担うようになったとき、人間のオンコール担当者に残る仕事は何か。

筆者が整理すると、残る仕事は大きく5つある。

エスカレーション判断とTier 2対応は、最も重要な役割だ。AIが自信を持って誤った診断をする場合への対処がそれにあたる。アップストリームエラーがあると、その後の診断チェーン全体が確信を持って間違った方向へ進む。これを人間がどのタイミングで介入して止めるかは、今後のオンコール設計の核心だ。

ポストモーテムの品質向上と学習サイクルの設計も、人間がやらなければ意味がない。AIが出力するドラフトは出発点に過ぎない。「なぜそうなったか」の深掘りと、複数インシデントを横断したパターン認識は人間の仕事だ。PagerDutyの2026レポートでは、「構造化改善サイクル」を実施している組織は全体の48%にとどまると報告されている。残り52%の組織では、ポストモーテムが書きっぱなしで終わっている。

SLOの番人としての役割も変わらない。エラーバジェット管理ポリシーの策定、AIが自動復旧を実行してよい閾値の設定、そしてAI判断への最終承認・拒否権の行使は、EMが設計すべき仕事だ。

AIシステム自体のガバナンスは、新しい種類の責任だ。エージェントへの権限設計、監査ログのレビュー、「このAIが取ったアクションは正しかったか」の事後評価がそれにあたる。Komodorが指摘するように、役割は「最前線の消防士」から「消防システムの設計者・監督者」へと変わる。

重大インシデント時のインシデントコマンダーは、AIには委任できない。SEV-1における意思決定、ステークホルダーコミュニケーション、法的・規制的リスクが伴う判断がそれだ。

EMが今すぐ再設計すべき4つのポイント

ローテーション表の組み方

AI一次対応を前提とした3層構造を設計する。

「アラートを受け取る頻度」ではなく「AI未解決インシデントを引き受ける頻度」でローテーションを設計し直すべきだ。Google SREが長年提唱するように、SREの最低50%の時間をプロジェクト作業に確保するという原則は今も有効で、AIが一次対応を吸収した分を「プロジェクト時間」として再配分することをチームと合意する必要がある。

SLO・エラーバジェットの見直し

AI対応を前提にエラーバジェットポリシーを段階化する設計が有効だ。たとえばエラーバジェット残量が50%を超えていればAI自律デプロイを許可し、20%を下回れば自動復旧アクションに人間承認を必須化し、5%を切ったらAIは提案のみで実行は人間が担う、というような設計だ。

さらに、従来のSLO（可用性・レイテンシ）に加えて、「AIがインシデントを自律解決した割合」「AI提案が人間に拒否された率」をSLIとして追加することを検討したい。AIの判断精度を組織として計測していくことが、ガバナンスの起点だ。

評価・報酬の再設計

AI一次対応導入後も、オンコール手当の算定基準が「ページ数」や「夜間呼び出し回数」のままになっているチームは少なくない。「AIが吸収した分は手当が下がる」という設計では、エンジニアのモチベーションを損なう。

「待機負荷（拘束時間）」と「複雑インシデント対応」の2軸で設計し直すことが現実的だ。また、「AIガードレール設計」「エージェント監査」「権限ポリシーの策定」という新しい責任を、評価軸として明示的に加える必要がある。エンジニアが公平だと感じられる補償設計の透明性が、オンコール体制への参加意欲に直結する。

ジュニアの育成機会を設計し直す

AIが一次対応を吸収するのは、まさにジュニアエンジニアの主要学習機会でもある領域だ。「ルーティン調査・既知ランブック実行・アラートトリアージ」を経験することで、インフラへの勘を養ってきた。この矛盾を放置すると、ジュニアが育たないまま組織の平均年齢だけが上がっていく。

代替手段として、私が考えているのは3点だ。

PagerDuty Shift Agentのシャドーローテーション（ページなしでAIの対応過程を観察するシフト）を活用して、「AIがなぜこの診断をしたか」を事後学習する機会を設ける。AIが対応した障害のタイムラインをジュニアに提示し「あなたならどうする？」で学ぶ、インシデントリプレイ研修を導入する。ジュニア期の評価軸として「AI提案に対してどれだけ適切に検証・承認・拒否できるか」を明示する。

Gartnerは2029年までに85%の企業がAI SREツールを使用すると予測している（2025年時点では5%未満）。その世界で活躍できるエンジニアを育てるための設計は、今から始める必要がある。

リスクと対策——AIを「信頼するが検証する」姿勢で

AI一次対応には無視できないリスクがある。

誤った復旧（Wrong Remediation）が最も深刻だ。実際に2025年、AI駆動コーディングツールがコードフリーズ中に本番DBを削除し、緊急復旧が必要になった事例が報告されている。サービス名やエラーコードをAIが誤識別すると、その後の診断チェーン全体が確信を持って誤った方向へ進む、という問題もある。

ハルシネーションの問題もある。Zalandoの事例では、小モデル（3〜12Bパラメータ）でハルシネーション発生率が最大40%に達した。上位モデルでも因果関係を誤識別するケースが約10%残存したという報告があり、人間によるキュレーションは不可欠だ（同社は初期100%から現在10〜20%サンプリングに移行している）。

責任所在の曖昧化も組織として事前に整理が必要だ。「AIが提案し人間が承認した場合」と「AIが自律実行した場合」では責任の所在が異なる。シンガポールのIMDAは2026年1月、エージェントAI専用のガバナンスフレームワーク（世界初）を発表し、「Agent Identity Cards」で能力・制限・権限ドメイン・エスカレーションプロトコルを明文化することを推奨している。

逆説的なトイル増加にも注意が必要だ。「ほぼ正しいが微妙なエラーを起こすAIシステムの手動監視」が新たなトイルになるケースが報告されており（Catchpoint SRE Report 2025）、AI導入がかえって負荷を増やすという皮肉な結果になる可能性がある。

技術的な対策として有効なのは、段階的自律性（提案のみ → 低リスク環境 → 本番非重要系 → 本番重要系）の設計、権限の最小化（Pod再起動はOK、ノードドレインは人間承認必須、のような明文化）、そして継続的な評価パイプライン（ハルシネーション率・ポリシー違反率・エスカレーション頻度の定期計測）だ。

Google SREが設計原則として掲げる「ブラックボックス化を避け説明可能性を重視する」「AI障害時の事業継続計画を整備する」という考え方は、どの組織でも参考になる（Google Cloud Blog）。

EMのためのオンコール再設計チェックリスト

最後に、今週から動ける具体的な確認項目をまとめておく。

• 現状把握（今週中）
• 直近30日のアラート数と、その中で人間の判断が実際に必要だったアラートの割合を集計する
• チームメンバーのオンコール負荷（呼び出し頻度・深夜対応頻度・対応時間）をデータで把握する
• 現在のトイル率（業務時間に占める運用作業の割合）を試算する

• AIに委任できる範囲の定義（1か月以内）
• ランブック単位でAI自律実行可否を定義し、リストを文書化する
• エラーバジェット残量ごとのAI自動復旧許可閾値をポリシーとして明文化する
• 監査ログのレビュー体制（誰が週次/月次でレビューするか）を決める

• 体制の再設計（3か月以内）
• Tier 0（AI）/ Tier 1（オンコール担当）/ Tier 2（シニア/EM）の3層ローテーションに移行する
• ジュニアのシャドーローテーションとインシデントリプレイ研修を設計する
• オンコール手当の評価軸に「複雑インシデント対応」「AIガードレール設計」を追加する

• PoC実施（半年以内）
• Datadog Bits AI SREまたはAWS DevOps AgentのPoC環境を構築し、MTTR・トイル率をベースライン計測する
• PagerDuty Shift Agentのシャドーローテーションを1チームで試験導入する

「消防士」としての役割から「消防システムの設計者・監督者」への転換は、一夜にして起きない。ただ、AIエージェントが一次対応を担える状態になった今、この転換を意識的に設計するのがEMの仕事だと思っている。

あなたのチームのオンコールローテーションは、今の技術環境に合っているか。そこを問い直してほしい。