LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

インシデント対応・オンコール外注とは——障害実務代行の全体像

インシデント対応・オンコール運用の外注とは、システムやサービスで障害が発生した際に、アラート受信から初動確認・エスカレーション判断・復旧対応までを外部の専門パートナーに委託する形態を指します。監視ツールの導入やアラート転送の設定とは異なり、「障害が起きたときに実際に対応する人員・プロセス」を代行する点が本質です。

夜間・休日に対応できる技術者を社内で確保し続けることは、中堅・中小規模の組織にとって大きな負担です。特定エンジニアへの依存が深まると、退職・異動による体制崩壊のリスクも高まります。

インシデント対応とオンコール体制の定義

Google SRE Book（Googleが公開するサイト信頼性エンジニアリングの実践書）では、オンコール（On-Call）を「勤務外の時間を含め通話対応が可能な状態を保つ職務」と定義しています^*1。オンコール担当者は本番システムの保護者として、割り当てられた業務を管理し障害に対応します。

インシデント管理は、障害の認識・宣言から対応・復旧・事後分析までの一連のプロセスを指します。Google SRE Bookでは、インシデント管理を「認識と宣言」「対応と復旧」「事後対応」の3段階で整理しています^*2。外注する場合は、このプロセスのどの段階を委託し、どの段階を自社で持つかを明確にする必要があります。

監視外注・SRE外注との役割の違い

インシデント対応外注は、「監視外注」「SRE外注」とは担うフェーズが異なります。監視外注はアラートを検知・転送するところまでが主な範囲です。SRE（サイト信頼性エンジニアリング）外注はSLI/SLO設定やエラーバジェット管理など、システムの信頼性をエンジニアリング的に向上させる機能全体を対象とします。

一方、インシデント対応外注は「アラートが鳴った後、実際に対応する人員とプロセス」に特化します。夜間・休日を含む全時間帯で、誰が電話を受け、何を確認し、誰にエスカレーションするかを代行してもらうサービスです。三者の違いを把握したうえで、自社の課題に合った委託範囲を設計することが大切です。

オンコール体制を内製するコストと限界——夜間障害が担当者を疲弊させる理由

オンコール体制を内製で維持するには、プライマリ担当者とその不在時のバックアップとなるセカンダリ担当者の双方を確保するローテーション設計が求められます。Google SRE Workbookでは、単一拠点チームで信頼性あるオンコールを回すには最低8名のSREが必要と述べています^*3。中堅・中小の運用組織では、この人数を専任で確保することは容易ではありません。

12時間シフトの上限と必要人数

Google SRE Workbookは、オンコールシフトを12時間以内に制限することを推奨しています^*3。睡眠不足がエラー発生率を高めるため、24時間以上の継続的なオンコールは持続不可能と判断されています。12時間シフトを昼夜交代で運用するには、最低でも2名の専任担当者が必要です。さらに休暇・病欠・育児などのバッファを考慮すると、現実的には3〜5名規模の専任チームでなければ安定運用は難しくなります。

オンコール担当者のエンジニアリング業務比率についても、Google SRE Bookは「オンコール時間は全業務時間の25%以下・エンジニアリング業務は50%以上を確保する」という基準を示しています^*1。この基準を守れない場合、担当者のモチベーションや技術力の維持が難しくなります。

属人化・採用難・疲弊が引き起こすリスク

現実の運用現場では、少人数で夜間対応を担うケースが少なくありません。深夜に呼び出しが続くと、担当者の睡眠が慢性的に阻害されます。疲労状態でのインシデント対応は判断ミスや対応漏れのリスクを高め、障害の長期化につながる可能性があります。

採用の面でも、オンコール義務が発生するポジションへの応募は一般的に少なく、優秀なエンジニアほど夜間呼び出しを嫌う傾向があります。担当者が退職した場合、引き継ぎ先がいないまま特定の技術者に負荷が集中するリスクも生じます。こうした悪循環を断つ手段の一つとして、インシデント対応の外注が検討されます。

外注するインシデント対応の範囲——一次対応・エスカレーション・ポストモーテムの分担

インシデント対応外注では、委託する範囲を「一次対応」「エスカレーション」「ポストモーテム」の3層に分けて設計するとスコープが明確になります。どこまでを外注に任せ、どこからを自社エンジニアが引き取るかを事前に合意しておくことが、委託成功の前提条件です。

一次対応——アラート受信から初動確認・重大度判断まで

一次対応は、監視アラートを受信してからインシデントの重大度を判断し、担当対応者へエスカレーションするかどうかを決めるフェーズです。外注先がここを担う場合、あらかじめ定めたランブック（対応手順書）に従って対象サービスの死活確認・エラーログの一次確認・影響範囲の特定を行います。

一次対応の速度がサービス停止時間の長短に直結します。外注先に求める初動応答時間（例：アラート受信後15分以内の確認完了）をSLAとして契約に明記することが大切です。ランブックの整備が不十分なまま委託を開始すると、外注先が正確な初動を取れず問題が長期化する恐れがあります。

エスカレーション——担当エンジニアへのブリッジング

Google SRE Bookのインシデント管理では、インシデント司令官（Incident Commander）・運用リード（Operations Lead）・コミュニケーション担当（Communications Lead）の役割分担を明確にすることが推奨されています^*2。外注先が一次対応を担う場合、重大障害時に自社の担当エンジニアや開発チームへ状況を引き渡す「コミュニケーション担当」的な役割も担います。

エスカレーション先のリストとその連絡順序（だれに・何の条件で・どの手段で連絡するか）はエスカレーションマトリクスとして事前に作成します。このマトリクスの精度が低いと、外注先が誰に連絡すべきか判断できず初動が遅れます。委託前の設計フェーズでしっかり作り込む必要があります。

ポストモーテム——事後分析・再発防止の外注・共同実施

Google SRE Bookでは、ポストモーテム（事後分析）を「インシデントの書面記録であり、影響・対応・根本原因・再発防止アクションを含むもの」と定義しています^*4。ポストモーテムは特定の個人を責めない「blameless（非難なし）」の文化で実施することで、組織の学習効果が高まります。

ポストモーテムは外注先と自社が共同で作成する形が一般的です。外注先がインシデントの経緯とタイムラインを整理し、自社側が根本原因の分析と再発防止策の意思決定を担うという役割分担が現実的です。外注先にポストモーテムレポートの提供を義務づけるかどうかは、選定時の重要確認事項の一つです。

外注の進め方——4フェーズで体制を整備する

インシデント対応を外注する際は、準備なしに委託先を決めてもうまく機能しません。現状把握→設計→選定→移行の4フェーズで段階的に進めると、委託後のトラブルを大幅に減らせます。

フェーズ1：現状棚卸し——インシデント件数・重大度・時間帯を整理する

まず自社のインシデント発生状況を定量的に把握します。過去6〜12か月間のアラート・障害ログを振り返り、「月あたりの発報件数」「障害の重大度分布（P1/P2/P3など）」「時間帯分布（業務時間内外・曜日別）」を整理します。この棚卸しで委託の必要性と規模感の根拠が得られます。

現在のオンコール担当者の負荷（週あたりの呼び出し回数・深夜対応の頻度）も数値化しておきます。担当者本人へのヒアリングと合わせて、現状の「疲弊度」を可視化することが、外注移行の社内稟議を通す際にも有効です。

フェーズ2：エスカレーション設計——ICS役割と連絡経路を定める

外注先が一次対応を担う前提で、エスカレーション設計を文書化します。インシデントの重大度ごとに「誰（役職・担当領域）に」「何分以内に」「どの手段（電話・Slack・メール）で」連絡するかを定めます。これを「エスカレーションマトリクス」として1枚のシートに整理すると、外注先との認識合わせがしやすくなります。

Google SRE Bookで示されたインシデント管理の役割（Incident Commander・Operations Lead・Communications Lead）を参考に、自社体制での役割を定義します^*2。全員が一つの役割を兼ねる小規模チームの場合でも、「誰が最終判断者か」を明確にしておくことで、外注先との連携がスムーズになります。

フェーズ3：外注先選定・RFP——5つの評価軸でパートナーを選ぶ

エスカレーション設計が固まったら、外注先候補に対してRFP（提案依頼書）を提示して提案を受けます。評価軸は「対応SLA」「エスカレーション設計の透明性」「技術スタック・業種実績」「契約形態の柔軟性」「ポストモーテム提供の有無」の5軸が基本です。詳細は次のセクションで解説します。

フェーズ4：移行・定常化——ランブック整備と訓練で定着させる

外注先の選定が完了したら、自社のランブック（対応手順書）を外注先に引き継ぐ形で整備します。ランブックはサービスごとの対応手順・連絡先・系統図をまとめた文書で、外注先が初動を迷わず取れる精度に仕上げることが大切です。

移行後の初期3か月は定例会議（週次または隔週）を設定し、対応品質・応答時間・エスカレーション漏れを確認します。問題があればランブックを随時更新し、定常化後は月次レビューに移行します。

外注先選定で確認すべき5つの評価軸

インシデント対応の外注先を選ぶ際は、価格だけで判断することは避けるべきです。実際の障害対応品質を左右する5つの軸で評価します。

対応SLA——初動時間と復旧目標を数値で契約する

SLA（サービスレベル合意）の中でも「初動応答時間」は特に重要です。アラート受信から担当者が状況確認を開始するまでの時間が、障害の影響時間を左右します。契約書に「重大障害（P1）は受信後〇分以内に一次確認を完了」という形で明記することを求めます。

「24時間365日対応」という表現は業者によって意味が異なります。常時有人対応なのか、当番制でコールバックまでのタイムラグがあるのかを事前に確認します。夜間・休日の実際の対応体制を見積もり段階で詳細に確認することが大切です。

エスカレーション設計の透明性——連絡経路の書面化を求める

外注先の「どの条件でどの担当者に連絡するか」がドキュメント化されているかを選定時に確認します。自社担当者の異動・連絡先変更に迅速対応できる更新プロセスも確認事項です。

技術スタック・業種実績——現場対応力の根拠を確認する

インシデント対応では、アラートの意味を正しく読み取り的確な初動を取るために、対象システムへの深い理解が必要です。自社が利用しているクラウドサービス（AWS・Azure・GCPなど）・データベース・アプリケーションフレームワークに関する実績を具体的に確認します。同業種の運用経験がある場合は、業務特性を理解したうえでの対応が期待できます。

ポストモーテム提供の有無——学習する組織につなげるか

外注先がポストモーテムを提供できるかどうかは、「障害対応を繰り返すだけ」か「改善し続ける体制」かを分ける分岐点です。blameless（非難なし）の原則に沿ったポストモーテムを作成できるパートナーを選ぶことで、再発防止の仕組みを外注を通じて社内に根付かせていくことができます^*4。

費用の考え方——契約形態と市場参考レンジ

以下の費用情報は市場参考値であり、一次資料に基づく確定値ではありません。実際の費用は対応体制・技術スタック・SLAレベル・インシデント頻度によって大きく異なります。複数社からの見積もりを取得して比較判断することを勧めます。

主な契約形態と特徴

インシデント対応外注の契約形態は主に3種類に分類されます。月額固定制は一定の月額を支払うことで、インシデント件数に関わらず対応を受けられる形態です。インシデント頻度が高い場合や、予算の見通しを立てやすくしたい場合に向いています。

呼出従量制はインシデントが発生した際にのみ費用が発生する形態です。インシデント頻度が低い場合は費用対効果が高く、システムの安定稼働期には月額固定より有利になります。ただし重大障害が連続する月は費用が大きく膨らむリスクがあります。

ハイブリッド制は基本料金（小額固定）＋呼出従量の組み合わせで、スタンバイ費用と実対応回数の両面でバランスを取れる形態です。

費用に影響する主な要因

外注費用は対応時間帯・SLAの厳しさ・対象システムの複雑さ・ポストモーテムの有無によって変動します。

• 対応時間帯の範囲：夜間・休日対応を含むほど費用は高くなります。深夜帯（0〜6時）の対応を含む場合は、日中のみ対応と比べて費用が大きく変わります。
• SLAの厳しさ：初動応答時間が短い（例：5分以内）ほど常時スタンバイの人員コストが高くなり、費用に反映されます。
• 対象システムの複雑さ：マイクロサービス・複数クラウド・レガシーシステムが混在する環境では、対応に習熟コストがかかるため費用が高くなります。
• ポストモーテムの有無：事後分析レポートの作成・提供が含まれる契約は、対応のみの契約より費用が上がります。

内製との費用比較は、人件費（深夜割増含む）・採用コスト・ツール費用を合算したうえで行うことで、判断精度が上がります。

まとめ——インシデント対応外注の3つの判断軸

本稿では、インシデント対応・オンコール運用を外注する際の全体像・体制設計・外注先選定・費用の考え方を整理しました。要点を3つに集約すると次の通りです。

第一に、外注するのは「障害に対応する実務プロセス全体」であること。監視外注・SRE外注との役割の違いを把握し、自社の課題に合ったスコープを設計することが出発点です。

第二に、外注移行の前にエスカレーション設計（誰に・何分以内に・どの手段で）を文書化しておくこと。設計なき委託は障害対応の長期化リスクを生みます。

第三に、SLA・技術スタック・ポストモーテム提供の有無の3軸で外注先を評価すること。価格だけでなく実際の対応品質を担保するパートナーを選ぶことが、外注成功の分岐点です。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Google「Site Reliability Engineering — Being On-Call」（2017年・Google SRE Book）
2. *2　出典：Google「Site Reliability Engineering — Managing Incidents」（2017年・Google SRE Book）
3. *3　出典：Google「The Site Reliability Workbook — On-Call」（2018年・Google SRE Workbook）
4. *4　出典：Google「Site Reliability Engineering — Postmortem Culture: Learning from Failure」（2017年・Google SRE Book）

Tweet