監視外注と内製の比較

どちらを選ぶかを左右する3つの条件

1. ワークロード特性とコンプライアンス

規模・変動・規制の3点でまず絞り込みます。台数やマイクロサービス数が少なく、夜間の変動も穏やかなら内製でも十分回せます。一方、トラフィックの昼夜差が激しく、セールやリリースで負荷プロファイルが頻繁に変わるなら、24時間365日の待機と自動化が欠かせません。個人情報や医療・金融系のデータを扱う場合、監視データの保管先・操作ログ・権限委譲の監査まで求められるため、外注ならば監査証跡とアクセス境界の設計を契約前にすり合わせることが前提です。

2. 組織の成熟度（SRE/オンコール/Runbook）

外注してもRunbookが空白ならMTTRは短くなりません。内製であっても、当番表・エスカレーション・ポストモーテムが回っていなければ、夜間対応は属人化します。SLOとエラーバジェット、検知（MTTD）・応答（MTTA）・復旧（MTTR）の目標が、チームで合意されているかが分かれ目です。ここが未整備なら、外注を“監視と一次受け”に限定し、内製は“サービス知識と二次対応”に集中させるハイブリッドが安全です。

3. 24/365の必要性とタイムゾーン

平日日中のみで影響が済むなら輪番で内製可能です。深夜・祝日も影響が大きいなら、3交代または他タイムゾーン活用が必要です。外注はここが強みですが、対応言語・コミュニケーション手段（電話/Slack/チケット）・一次切り分けの深さに大きな差が出ます。SLAの「一次応答5分」が“既読”なのか“暫定封じ込め”なのか、定義を数行の文章ではなくステップで確認しましょう。

コストの実数と試算テンプレ

人数と時間でまず概算します。24/365で一次対応を内製で回すには、最低でも平準化後3.5〜4.5人月の稼働（休日・夜間・引き継ぎを含む）が必要です。採用・離職・教育を含む年次TCOを見るのがポイントです。

• 内製固定費（目安）：オンコール手当3〜6万円/人月、監視ツール利用料（メトリクス＋ログ＋APM）でサーバ100台規模なら月70〜150万円、教育・運用改善に月1人日。
• 外注費（目安）：サーバ/エンドポイント単価×台数＋時間帯オプション。24/365一次受けで月120〜300万円、二次対応や自動化開発は別見積もりが一般的。
• 隠れコスト：アラート設計・Runbook作成の初期整備（30〜90人時）、変更管理の事前調整時間、SLA違反時の調停工数。

ブレークイーブンの簡易計算は次で足ります。

• 外注月額 −（内製人件費＋ツール費＋オンコール手当）＝ Δコスト
• Δコスト ÷（外注により削減できる自動化・停止損失・夜間障害の減少額）
• 回収期間が6〜12カ月以内なら外注優位、18カ月超なら内製・ハイブリッドを検討。

補助的に、アラート当たりの完全処理コストも見ます。外注で1件あたり2,000〜6,000円、内製で1,500〜4,000円が多い印象ですが、誤検知率が10％を超えると一気に逆転します。アラート設計品質の改善投資が最も費用対効果に効きます。

品質を決める運用設計：外注でも内製でも共通

アラート設計とRunbook

重要度を3段階に分け、トリガーは「症状ベース＞原因ベース」で設計します。例：CPU高騰ではなく“p95レイテンシ＋エラーレート”。Runbookには「観測→暫定対処→恒久対策の起票」までを1ページで。生成AIを使うと初期作成が早いです。ChatGPTやClaudeでログ例から判別フローを起草し、Copilotでヘルスチェックや自動フェイルオーバーのスクリプト雛形を作る、といった分担が実用的です。インシデント要約やポストモーテムのドラフトはGeminiに箇条書きを投げると時短になります。

エスカレーションとSLAの落とし穴

• 一次応答＝受付、二次応答＝暫定封じ込め、三次＝恒久対応の切り分けを明記。
• MTTA目標（例：重大3分/高10分/中30分）、MTTR目標（例：重大30分以内に暫定復旧）。
• SLAは“回復時間”ではなく“回復率(稼働率)”とセットで。エラーバジェット消費を週次レビュー。
• 変更凍結期間・緊急変更の権限（誰が/いつ/どこまで自動実行OKか）をRunbookに固定。

ハイブリッド運用の型

• 外注：一次受け＋監視基盤運用＋定常タスク自動化。
• 内製：サービス知識の二次対応＋キャパ計画＋性能試験＋障害訓練。
• 四半期ごとにシャドーオンコールを入れ替え、ナレッジを双方向に同期。

身近な企業活用例：中堅ECの失敗と改善

AWS上でコンテナ60、RDS、Redis、CDNを利用。注文は平常1,200/日、セールで5倍。内製監視は疲弊し、昨年は外注に切り替えました。一次応答5分のSLAに安心していたものの、実態は“受付5分・暫定対処はベストエフォート”。ブラックフライデー当日、DBのロック競合でレイテンシ悪化。外注側はCPU高騰のしきい値に到達せずエスカレーションが遅れ、RDSフェイルオーバーのRunbookも未承認で、復旧に90分。売上大幅減とチームの不信感が残りました。

改善はハイブリッド化でした。外注は一次受けとログ集約・メトリクス運用に絞り、内製SREが二次対応と自動化を担当。ChatGPTとClaudeで既存障害のログを要約し、Runbookを15本作成。Copilotでスロークエリ検知と接続数制御の自動化Lambdaを生成、Geminiでインシデント要約と週次レポートを生成。アラートは症状ベースに再設計、MTTAは8分→3分、暫定復旧のMTTRは70分→18分に短縮。外注費は▲20％、内製稼働は月40時間から25時間へ。セール当日は、RDS接続数スパイクを自動緩和し、誤検知は月3件まで低減しました。

結局のところ、外注か内製かではなく、責務分担とRunbookの粒度、アラートの設計品質が核心です。意思決定は次の3点で締めると迷いません。

• 24/365の必要性とコンプラ要件を満たす最小構成（内製/外注/ハイブリッド）。
• 一年のTCOと3カ月の回収計画（自動化と誤検知削減で何を止めるか）。
• MTTA/MTTRの目標とSLA定義（応答・封じ込め・回復の用語をステップで明記）。

サーバ監視運用事業の現場では、この分解ができていれば、どの体制でも事故は減り、スループットは上がります。外注も内製も手段であり、監視の設計と運用の成熟度こそが、サービスの信頼性を安定させる近道です。