---
title: "SREとは？サイト信頼性エンジニアリングの意味・DevOpsとの違いをわかりやすく解説"
url: "https://www.issoh.co.jp/column/details/3080/"
published: 2024-07-16
updated: 2026-07-21
categories: ["品質管理"]
publisher: "株式会社一創"
---

# SREとは？サイト信頼性エンジニアリングの意味・DevOpsとの違いをわかりやすく解説

SRE（Site Reliability Engineering／サイト信頼性エンジニアリング）は、Googleが2003年に生み出した「ソフトウェアエンジニアリングの手法でシステム運用の課題を解決する」考え方です。障害ゼロを目指すのではなく、**どこまで壊れてよいかをSLOという数値で定め、その予算内で開発スピードと安定性を両立させる**点に特徴があります。この記事では、SREの定義から基本原則、DevOpsやインフラエンジニアとの違い、仕事内容や年収、導入の進め方までを一度に整理します。

## まとめ：この記事の要点

- **SREとは**：Google発祥の運用手法で、信頼性を「SLO（目標値）」として数値化し、その達成を工学的に管理する。
- **中核となる指標**：SLI（実測値）・SLO（目標）・SLA（契約）と、SLOの裏返しである**エラーバジェット**で意思決定する。
- **DevOpsとの関係**：DevOpsが「開発と運用の協働」という思想なら、SREはそれを具体的な指標と手順で実装した実践版。
- **役割**：SREエンジニアは監視・自動化・障害対応を担い、手作業（トイル）を全業務の50%未満に抑えることを目標にする。
- **始め方**：全社導入ではなく重要サービス1つのSLO設定から始める。運用が安定した小規模システムに無理に入れる必要はない。

## SRE（サイト信頼性エンジニアリング）とは

### SREの定義と読み方

SREは「エスアールイー」と読み、Site Reliability Engineeringの略です。提唱したのはGoogleで、2003年に同社のBen Treynor Sloss氏が立ち上げたチームが起点とされます。従来の運用（インフラの手動管理）を、コードやソフトウェアエンジニアリングの発想で置き換えるのがねらいです。Googleはこの考え方を「**運用の問題をソフトウェアで解く**」と表現しており、監視・復旧・キャパシティ管理といった作業を、可能な限り自動化・仕組み化します。

### SREが生まれた背景

Webサービスが大規模化すると、機能を速く出したい開発チームと、止めたくない運用チームの利害がぶつかります。SREはこの対立を「感情論」ではなく「信頼性の数値目標」で調停します。**100%の可用性を目標にしない**のがSREの割り切りで、コストが跳ね上がるうえユーザー体験の改善にほとんど寄与しないため、あえて許容できる故障の量を先に決めます。

## SREを支える基本原則

### SLI・SLO・SLA：信頼性を数値で定義する

SREは信頼性を感覚ではなく指標で扱います。3つの用語は役割が異なります。

| 用語  | 意味          | 例                |
| --- | ----------- | ---------------- |
| SLI | 実測した指標      | 過去30日の可用性 99.95% |
| SLO | 社内で定める目標    | 月間可用性 99.9%以上    |
| SLA | 顧客との契約・返金条件 | 99.5%を下回れば利用料を返金 |

SLAが対外的な約束、SLOがそれより厳しめの社内目標、SLIが日々測る実測値、という三層構造です。SLOを起点に運用判断を下すのがSREの基本姿勢です。

### エラーバジェット：どこまで壊れてよいかを決める

エラーバジェットは「許容される失敗の量」で、SLOの裏返しとして自動的に決まります。月間可用性SLOを99.9%と定めれば、残りの**0.1%（30日換算で約43分）が1か月に使ってよい障害の予算**です。予算が余っていれば新機能を積極的にリリースし、使い切ったら安定化を優先して機能追加を止める——この判断基準があることで、開発と運用が同じ物差しで議論できます。

### トイル削減：手作業を50%未満に抑える

トイル（toil）とは、手作業で・繰り返し・自動化可能で・恒久的な価値を生まない運用作業を指します。Googleは**SREが運用作業に費やす時間の上限を50%とし、残りを自動化やツール開発に充てる**ことを推奨しています。トイルを放置するとチームが日々の対応に忙殺され、信頼性を高める本来の仕事ができなくなるためです。

### 4つのゴールデンシグナル：まず監視すべき指標

何を監視すべきか迷ったら、Googleが挙げる4指標から始めます。

- **レイテンシ**：リクエストへの応答時間（成功と失敗を分けて計測する）
- **トラフィック**：システムにかかっている需要量（秒間リクエスト数など）
- **エラー**：失敗したリクエストの割合
- **サチュレーション**：CPUやメモリなどリソースの逼迫度

この4つはユーザー体験に直結するため、少ない指標でサービスの健康状態を素早く把握できます。

## SREとDevOpsの違い

両者はよく混同されますが、抽象度が異なります。**DevOpsは「開発と運用が協力すべき」という文化・思想**であり、SREは**その思想を具体的な指標（SLO）と手順（エラーバジェット、トイル削減）で実装した実践形**です。Google自身「class SRE implements DevOps（SREはDevOpsを実装したものだ）」と説明しています。DevOpsを含む開発手法全体の位置づけは[ウォーターフォール・アジャイル・スクラムの違い](https://www.issoh.co.jp/column/details/1348/)で整理しています。

| 観点  | DevOps   | SRE              |
| --- | -------- | ---------------- |
| 性質  | 文化・思想    | 具体的な実践手法         |
| 指標  | 明確な定義なし  | SLI/SLO/エラーバジェット |
| 担い手 | 開発・運用の全員 | 専門のSREチーム        |

## SREエンジニアの役割と他職種との違い

### SREエンジニアの主な仕事内容

SREエンジニアは、監視基盤の構築、障害対応とオンコール、リリースの自動化、キャパシティ計画、SLOの設計と運用を担います。コードを書いて運用を仕組み化する点で、単なるサーバー管理者ではなく**「運用課題を解決するソフトウェアエンジニア」**と位置づけられます。

### インフラエンジニア・DevOpsエンジニアとの違い

インフラエンジニアがサーバーやネットワークの構築・維持を主とするのに対し、SREエンジニアは**信頼性という成果指標に責任を持ち、そのためにソフトウェアを書く**点が異なります。DevOpsエンジニアは開発と運用をつなぐパイプライン整備が中心で、SREはさらに一歩進んで信頼性を数値目標で管理します。ここから派生して、開発者が自律的に運用できる基盤を整える**プラットフォームエンジニアリング**という職域も生まれ、SREと役割を補い合います。

### SREエンジニアの年収と案件の傾向

SREはクラウドとソフトウェア開発の両方のスキルを求められるため、国内でも需要に対して人材が不足しており、求人票ではインフラエンジニアより高めの給与レンジが提示される傾向があります。求人・案件では、Kubernetesや監視ツールの運用経験、SLO設計やIaC（Infrastructure as Code）の実務が重視されます。具体的な金額は市況で変動するため、最新の相場は求人媒体で確認してください。

## SREのインシデント対応とオンコール体制

SREでは、障害を「起きるもの」と前提に置き、検知から復旧までの時間を短くする仕組みを整えます。オンコール担当を交代制で置き、アラートの優先度を設計し、復旧手順（Runbook）を文書化しておきます。プロセスの全体像はITILの枠組みと重なる部分が多く、[インシデント管理とは？ITIL準拠のプロセスと監視・オンコールの実装](https://www.issoh.co.jp/tech/details/13805/)で運用手順を詳しく解説しています。

### ポストモーテムで再発を防ぐ

障害収束後には**非難なき（ブレームレス）ポストモーテム**を実施します。個人の責任追及ではなく、なぜ検知や復旧に時間がかかったのかを仕組みの問題として振り返り、再発防止策を残すのがSRE流です。人を責めない前提だからこそ、当事者が事実を正確に共有でき、同じ障害を繰り返さない改善につながります。

## SREの導入ステップと注意点

### スモールスタートの進め方

SREは全社一斉ではなく、影響の大きいサービス1つを対象にSLOを1つ決めるところから始めます。手順はおおむね次の通りです。

- 対象サービスで最も重要なユーザー体験（例：ログインの成功率）を選ぶ
- それをSLIとして計測し、現実的なSLOを設定する
- エラーバジェットを可視化し、超過時のルール（機能追加の停止など）を合意する
- トイルの大きい作業から順に自動化していく

### SREを導入すべきでない場面

SREは万能ではありません。**アクセスが少なく更新頻度も低い社内システムや、すでに手作業の運用コストがほとんど発生していない小規模サービスに、専任チームを置くのは過剰投資**です。SLOやエラーバジェットの管理自体が新たなトイルになりかねません。まずはトイルの総量が大きく、障害がビジネスに直結するサービスから適用するのが費用対効果の高い判断です。

## SREで使われる主要ツール

SREの実践では、指標を集める監視・可観測性ツールが中核になります。メトリクス収集にPrometheus、可視化にGrafana、統合監視SaaSとしてDatadogやNew Relicがよく使われ、インフラの構成管理にはTerraform、コンテナ基盤にKubernetesが用いられます。監視をログ・メトリクス・トレースの3本柱で捉える考え方は、[オブザーバビリティ（可観測性）とは？監視との違い・3本柱・主要ツール](https://www.issoh.co.jp/column/details/3077/)で詳しく整理しています。

## よくある質問（FAQ）

### SREをわかりやすく言うと何ですか？

「システムをどこまで壊れてよいかを数値で決め、その範囲内で開発スピードと安定運用を両立させる、Google発祥の運用手法」です。障害ゼロではなく、許容できる故障の予算（エラーバジェット）を管理するのが特徴です。

### SREとDevOpsの違いは何ですか？

DevOpsは「開発と運用が協力する」という文化・思想で、SREはそれをSLOやエラーバジェットといった具体的な指標と手順に落とし込んだ実践方法です。SREはDevOpsの考え方を実装したもの、という関係にあります。

### SREとインフラエンジニアの違いは何ですか？

インフラエンジニアはサーバーやネットワークの構築・維持が主な役割です。SREエンジニアは信頼性という成果に責任を持ち、運用課題をソフトウェアで自動化・仕組み化する点が異なります。

### SREエンジニアの年収は高いですか？

クラウドとソフトウェア開発の双方のスキルが求められ人材が不足しているため、一般的にインフラエンジニアより高めのレンジで募集される傾向があります。具体的な金額は市況で変わるため、最新の求人情報で確認してください。

### SRE導入には何から始めればよいですか？

最も重要なサービスを1つ選び、そのユーザー体験をSLIとして計測し、現実的なSLOを1つ設定するところから始めます。全社一斉導入より、影響の大きいサービスへのスモールスタートが失敗しにくい進め方です。

## 関連記事

- [オブザーバビリティ（可観測性）とは？監視との違い・3本柱・主要ツールを解説](https://www.issoh.co.jp/column/details/3077/)
- [インシデント管理とは？ITIL準拠のプロセスと監視・オンコールの実装を運用目線で解説](https://www.issoh.co.jp/tech/details/13805/)
- [ウォーターフォール・アジャイル・スクラムの違い｜3つの開発手法の比較と使い分け](https://www.issoh.co.jp/column/details/1348/)
- [DR対策（災害復旧）とは？定義・目的と企業への重要性](https://www.issoh.co.jp/column/details/9439/)

---

出典: [SREとは？サイト信頼性エンジニアリングの意味・DevOpsとの違いをわかりやすく解説](<https://www.issoh.co.jp/column/details/3080/>)（株式会社一創）