LASSIC Media らしくメディア

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

SREとは何か——従来の運用保守との違い

SRE（Site Reliability Engineering）の運用外注とは、システムの信頼性向上を工学的手法で継続するエンジニアリング機能を、外部の専門パートナーに委ねる委託形態です。

Googleが提唱したSREは「ソフトウェアエンジニアに運用チームを設計させたらどうなるか」という問いから生まれました^*1。従来の運用保守がインシデント発生後の手動対応を中心とするのに対して、SREはコード・自動化・計測を通じてシステムの信頼性を工学的に高める点が根本的に異なります。

従来の運用保守は「稼働させ続けること」が主目標です。一方、SREは「信頼性目標（SLO）を設定し、その達成を自動化・計測によって持続的に高めること」を目標に置きます。この違いが、外注の設計方針にも直接影響します。

担当者が増えるほど手動作業も増える「人手依存型」の運用保守とは異なり、SREはサービス成長に比例して自動化が拡張される設計を指向します。そのため、SREを外注する際にも「手順書通りに動く運用要員」ではなく「信頼性を継続的に高めるエンジニアリングチーム」として位置づけることが大切です。

SLI・SLO・エラーバジェット——信頼性を数値で管理する

SRE外注を検討する担当者が最初に理解すべき概念が、SLI・SLO・SLA・エラーバジェットの4つです。これらはGoogle SREの公式ドキュメント（sre.google）に定義されており、委託先との合意基準の骨格を形成します^*2。

SLI（Service Level Indicator）は、サービス提供レベルの定量的な測定値です。リクエスト遅延・エラー率・スループット・可用性などが典型例として挙げられています^*2。SLIは「何を計測するか」を定める指標です。

SLO（Service Level Objective）は、SLIに対して設定する目標値またはその範囲です。例えば「99.9%の検索リクエストを100ミリ秒未満で返す」といった具体的な目標を指します^*2。SLOは「どこまでを達成目標とするか」を定める基準です。

SLA（Service Level Agreement）は、SLOの達成・未達成時に何が起きるかを定めたユーザーとの契約です。財務的なペナルティなど明確な結果が伴います^*2。外注契約においては、SLOを内部目標、SLAを外向けの契約条件として区別することが実務上重要です。

エラーバジェットは、SLOから算出される「許容できる不可用性の余白」です。Google SRE本では「完全可用性はほぼすべてのサービスにとって誤った信頼性目標である」と明記されています^*1。可用性99.9%のSLOであれば、月あたり約43分がエラーバジェットとなり、この余白をどのリスクに使うか（新機能リリース・変更作業・負荷試験など）を開発チームとSREチームが協議しながら管理します。

外注契約を設計する際、これらの概念を委託先と共有せずに「稼働率99.9%保証」だけを記載しても、エラーバジェットの消費管理や改善施策の優先づけまでは担保されません。委託先との合意書にSLI・SLO・エラーバジェットの取り扱い方針を明記することが、SRE外注の品質を左右します。

トイル削減とオブザーバビリティ——SRE外注で得られる実務改善

SRE外注で得られる実務上の効果として、トイル削減とオブザーバビリティ（可観測性）の強化が挙げられます。

Google SRE本ではトイルを「本番サービス運用に紐づく手動・反復的・自動化可能・戦術的で永続的な価値を持たない作業」と定義しています^*3。具体的には定型的なアラート対応・手動バックアップ・定期的な設定変更確認などが該当します。SRE組織はトイルを各エンジニアの作業時間の50%以下に保つことを目標とし、残り50%以上の時間をトイル削減や機能改善のエンジニアリングに充てます^*3。

内製チームがトイルにより時間を消費している状況では、SRE外注先がこれらを自動化スクリプト・CI/CDパイプライン整備・モニタリング設定変更で引き受けることで、社内エンジニアはプロダクト開発に集中できるようになります。

オブザーバビリティ（可観測性）とは、システム内部の状態を外部の出力（メトリクス・ログ・トレース）から把握できる性質を指します。単なる「監視（モニタリング）」が事前設定したアラートに反応する仕組みであるのに対して、オブザーバビリティは「未知の問題を発見・診断できる能力」です。Google SREのモニタリング指針では「アラートは人間が介入すべき状況のみに絞り込み、ログは診断用に留める」という設計原則が示されています^*1。

外注先がオブザーバビリティ基盤（Prometheus・Grafana・Datadog・New Relicなどのツール選定と設定）を整備することで、障害の発見から根本原因特定までのMTTR（平均復旧時間）を短縮することが期待できます。ただし効果の程度は自社システムの複雑度や既存ログ設計に依存するため、外注前に現状のログ・メトリクス取得状況を棚卸しすることをお勧めします。

インシデント対応とポストモーテム——再発防止を仕組み化する

SREの特徴的な実践の一つが、インシデント対応とポストモーテム（事後分析）の組み合わせです。Google SRE本はポストモーテムを「インシデントの影響・対応アクション・根本原因・再発防止策の書面記録」と定義しており、ブレームレス（責任追及しない）文化のもとで運用します^*4。

ブレームレスとは「関係者全員が保有していた情報に基づき正しい判断をした」と前提し、個人ではなくシステム・プロセスの改善に焦点を当てる考え方です^*4。責任追及が先行する文化では問題が隠蔽されやすいのに対して、ブレームレスポストモーテムはインシデントをシステム強化の機会として扱います。

外注先にポストモーテム文化を求める場合、「障害発生後〇営業日以内にポストモーテムレポートを提出する」という契約条項と、レポートのフォーマット・共有範囲を事前に合意しておく必要があります。ポストモーテムが形骸化しないよう、改善アクションの実行状況を月次でレビューする体制を内製チームと外注先が共同で運営することが有効です。

インシデント対応については、外注先がオンコール（当直）体制を提供するケースとアラート通知後に対応するケースでは費用・体制が大きく異なります。24時間365日のオンコール体制を外注先が担う場合、内製チームの夜間・休日対応負荷が軽減されますが、エスカレーション手順と権限委譲の範囲を契約前に詳細に定めなければ、重大障害時に意思決定が遅れるリスクがあります。

SRE運用を外注するメリットと向いているケース

SRE運用を外注することで得られる主なメリットは以下の4点です。

• SREエンジニアの採用コスト・時間を省ける：SREは高度なスキルセット（ソフトウェアエンジニアリング＋インフラ＋データ分析）を要求するため、採用市場での競争は激しく、即戦力確保には相当のリードタイムを要します。
• SLO設計・監視基盤整備のノウハウを即時活用できる：外注先が複数社のSRE構築経験を持つ場合、ゼロから試行錯誤するよりも整備期間を短縮できます。
• オンコール体制の整備が不要になる：24時間対応が必要なサービスでも、外注先が当直体制を担うことで内製チームの夜間負担が軽減されます。
• エラーバジェット管理によりリリース判断を客観化できる：外注先がエラーバジェットを継続的に計測・報告することで、開発速度と信頼性のバランスを定量的に議論できるようになります。

一方で、SRE外注に向いているケースには条件があります。社内でサービスの要件・アーキテクチャを把握しているオーナーエンジニアが不在のままでは、外注先への要件伝達が不十分となり、SLO設定が実態から乖離するリスクがあります。外注先に「任せきり」にできるのではなく、業務理解と意思決定を担う内製エンジニアが少なくとも1名は必要です。

向いているケースとしては、①新規サービスの立ち上げ期でSRE基盤を早期に整備したい、②急成長期でインフラ変更頻度が高くオンコール負荷が増大している、③既存チームのトイルが常態化し開発速度が低下している、といった状況が挙げられます。

外注先選定の5つの評価軸——SRE委託を成功させる要件定義

SRE外注先を選定する際に確認すべき評価軸は5つあります。単純な費用比較だけでは、稼働開始後にミスマッチが発生するリスクがあります。

選定プロセスでは、提案書・費用見積もりの段階で「SLO設計のサンプルを提示してほしい」と依頼することを推奨します。SLO設計ができない外注先は、トイル削減・エラーバジェット管理の実務も対応困難である可能性が高いです。

また、元請（プライムベンダー）として一気通貫で受ける体制を持つベンダーか、複数の下請け企業が関わるマルチベンダー構成かによって、責任の所在・エスカレーション速度が大きく異なります。SRE外注では責任の一元化が品質に直結するため、元請としての責任体制を持つパートナー選定が有効です。

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

SRE運用外注の費用は、対象システムの規模・SLO目標・オンコール体制の有無・自動化範囲によって大きく異なります。以下は市場参考値であり、一次資料に基づく確定数値ではありません。あくまで検討初期の目安としてご参照ください。

費用を比較する際は「SLO設計・監視基盤構築の初期費用」と「継続的な運用費用（オンコール体制・インシデント対応・改善施策）」を分けて見積もりを取ることが大切です。初期費用が安くても継続運用費用が高い構成や、逆に初期費用が高いが自動化投資により継続費用が低減するケースがあります。

また、外注費用と内製で対応した場合の機会費用（SREエンジニアの採用・育成コスト・既存エンジニアのトイル対応時間）を比較することで、外注の経済合理性を判断できます。内製でSREエンジニアを確保するには採用・育成に相当のリードタイムを要することを念頭に置いてください。

内製チームと外注SREの役割分担——ハイブリッド体制の設計

SRE外注を導入する際、「全部を外注する」のではなく「内製と外注の役割を設計する」という視点が実務上重要です。役割が曖昧なままでは、インシデント時の意思決定遅延や責任の押し付け合いが発生しやすくなります。

特に注意が必要なのは「意思決定権限」の設計です。外注SREがエラーバジェット枯渇を検知した場合、リリース停止・変更凍結を実行する権限を持つのか、内製チームへの報告にとどまるのかを契約前に明確にしておく必要があります。権限が不明確なまま稼働を始めると、緊急時に判断が遅れてSLO違反が拡大するリスクがあります。

SREエンジニアを内製で採用・育成する予定がある企業では、外注先に「知識移転（Knowledge Transfer）の義務」を契約に含めることを検討してください。外注先が構築した自動化基盤・監視設計の内部ロジックを内製チームが理解できる状態を保つことで、将来的な内製化・ベンダー変更のリスクを低減できます。

SRE外注の進め方——4フェーズで整備するロードマップ

SRE外注を実際に進める際には、段階的なアプローチが有効です。いきなり全機能を外注先に移管するのではなく、4つのフェーズで整備することで、リスクを管理しながら体制を確立できます。

1. フェーズ1：現状棚卸しとSLO候補の合意
   現行システムのログ・メトリクス・アラート設定の棚卸しを実施します。外注先と協力してSLI候補を整理し、事業上の優先度に基づいてSLO目標値を設定します。この段階で「何を測るか」「どこまでを目標とするか」を合意せずに次フェーズに進むと、後工程の設計がブレます。
2. フェーズ2：監視基盤・オブザーバビリティの整備
   合意したSLIを計測する監視基盤を構築します。アラートルールの整備、ダッシュボードの設計、ログ収集パイプラインの整備がこのフェーズの主な作業です。外注先がツール選定（Prometheus・Grafana・Datadogなど）を主導し、内製チームがレビューする体制が有効です。
3. フェーズ3：インシデント対応・ポストモーテム体制の確立
   オンコール体制・エスカレーションフロー・ポストモーテムテンプレートを整備します。試験運用期間中に小規模インシデントをシミュレーションし、対応フローの実効性を確認します。この段階で内製チームと外注先の役割分担の穴が明確になるため、修正のタイミングとして活用します。
4. フェーズ4：トイル削減・継続改善のサイクル確立
   エラーバジェットの定期レビュー、トイル削減施策の実施、ポストモーテムアクション項目の進捗管理を月次サイクルで運営します。定例レビュー会議（SLOレビュー・ポストモーテムレビュー）を外注先と内製チームが共同で開催する体制を固定することで、改善が継続するサイクルが生まれます。

フェーズ1〜2を委託開始後3か月を目安に完了させ、フェーズ3〜4を並行して進めることが一般的です。ただし、対象システムの複雑度・現状の監視成熟度によって期間は大きく変わります。フェーズ1の棚卸し結果を見て外注先と計画を見直すことを推奨します。

まとめ——SRE外注を成功させる3つの判断軸

本稿では、SRE（Site Reliability Engineering）の運用外注について、基礎概念から外注先選定・費用・役割分担・進め方まで整理しました。要点を3つに集約します。

第一に、SLI・SLO・エラーバジェットを外注先と合意できているかが品質の前提です。Google SRE本が定義するこれらの概念なしに委託しても、信頼性向上は起きません。契約前にサンプルSLO設計を提示させることが選定の有効な判断材料になります。

第二に、内製チームの「意思決定権限」と外注先の「実行権限」を明文化できているかが運用品質を左右します。特にインシデント時のエスカレーションフローとエラーバジェット枯渇時の権限は、契約書に記載するレベルで合意することが大切です。

第三に、知識移転の仕組みが契約に含まれているかです。外注先が構築した自動化基盤・監視設計を内製チームが理解・引き継げる状態を保つことで、将来の内製化・ベンダー変更に備えられます。この3つの軸を確認してから外注先を選定することで、SRE委託の成果につながる体制を構築できます。

よくある質問

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

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

1. *1　出典：Google「Site Reliability Engineering Book — Introduction」（sre.google）
2. *2　出典：Google「Site Reliability Engineering Book — Service Level Objectives」（sre.google）
3. *3　出典：Google「Site Reliability Engineering Book — Eliminating Toil」（sre.google）
4. *4　出典：Google「Site Reliability Engineering Book — Postmortem Culture: Learning from Failure」（sre.google）

Tweet