この記事の要点（30秒まとめ）
- SREは「運用業務をソフトウェアエンジニアリングで解決する」職種。手作業でサーバーを守るのではなく、自動化と仕組みで運用そのものを消す。
- 中核概念はSLO（サービス品質目標）とエラーバジェット。100%の信頼性を目指さず、許容できる失敗の枠内で攻めの開発スピードと両立させる。
- 評価軸の特徴は「トイル（価値を生まない反復作業）」の削減。Googleでは業務時間のトイル比率50%以下が目標値。
- 年収レンジはジュニア500〜750万円、シニア1,000〜1,800万円、外資テックは1,800〜4,000万円。同経験のバックエンドより1〜2割高い傾向。
- プログラミングは必須。Go/Python/Rustで運用ツールを書けない人はSREとして成立しない。
SREとは何か
SRE（Site Reliability Engineer）は、ソフトウェアの「信頼性」をエンジニアリングする職種だ。Googleのベン・トレイナーズ・スロスらが定義した概念で、「運用業務をソフトウェアエンジニアリングで解決する」という哲学が中核にある。
伝統的な運用エンジニア（オペレーター）が「手作業でサーバーを守る」のに対し、SREは「自動化と仕組みで運用業務を消す」。具体的にはSLO（Service Level Objective）の設定、エラーバジェット運用、ポストモーテム文化の醸成、信頼性のためのソフトウェア開発を行う。
SREを理解する最大の鍵が「エラーバジェット」という考え方だ。100%の可用性は技術的にも経済的にも不可能だと認め、たとえばSLOを99.9%に設定する。すると残りの0.1%が「失敗してよい予算（エラーバジェット）」になる。この予算が余っているうちは新機能を攻めてよく、使い切ったら安定化に振る──リリース速度と信頼性のせめぎ合いを、数字で裁定する仕組みである。
SRE・DevOps・インフラエンジニアの違い
「インフラ系」とまとめられがちだが、SRE・DevOps・インフラは起源も主軸も違う。境界を押さえると、自分がどの軸で評価されるかが見えてくる。
| 職種 | フォーカス | 起源 |
|---|---|---|
| SRE | 信頼性、SLO、エラーバジェット | |
| DevOpsエンジニア | 開発と運用の融合、CI/CD | 米国の運動論 |
| インフラエンジニア | サーバ・ネットワーク・基盤 | 伝統的なIT |
| プラットフォームエンジニア | 開発者体験、内部基盤 | DevOps発展形 |
実態としては企業ごとに境界が曖昧で、SRE職の求人にインフラ業務が含まれることも多い。より広い基盤づくりに興味があるならインフラエンジニア、開発プロセスの自動化に惹かれるならDevOpsエンジニアのガイドも合わせて読むと、自分の軸足が定まる。
SREの主な仕事内容
SREの仕事は「障害対応」だけではない。むしろ障害が起きない仕組みづくりと、起きたときに素早く学ぶ文化の運営が本丸だ。
| 領域 | 業務内容 |
|---|---|
| SLO設計 | サービス品質目標の定義、SLI測定 |
| エラーバジェット運用 | リリース速度と安定性のバランス調整 |
| 可観測性 | メトリクス、ログ、トレース、アラート設計 |
| 障害対応 | インシデント対応、ポストモーテム |
| 自動化 | トイル削減、運用業務のコード化 |
| 信頼性のための開発 | 自前ツール、Chaos Engineering |
| キャパシティプランニング | スケーリング設計、コスト最適化 |
障害が起きたあとの「ポストモーテム（事後分析）」をどう運営するかも、SRE文化の要だ。個人を責める犯人探しではなく、仕組みの欠陥を洗い出す「ブレームレス（非難なし）」な振り返りを徹底する。人を責めると情報が隠れ、隠れると同じ障害が繰り返す。だから責めない。これは技術論である以上に、組織の学習速度を上げるための設計思想だ。
トイル（Toil）の削減が中心命題
SREの仕事の評価軸として最も特徴的なのが「トイル（Toil）」の削減だ。トイルとは「手作業で、繰り返し発生する、本質的価値を生まない作業」を指す。Googleでは「業務時間のトイル比率を50%以下に抑える」がSREの目標値になっている。
トイルを放置すると、運用エンジニアはサービスの成長に比例して疲弊し、やがて改善に使う時間がゼロになる。だからSREは「同じ作業を3回手でやったら自動化を検討する」。手作業を自分の仕事の証だと考えず、消すべきコストだと捉える。この発想の転換が、旧来の運用職とSREを分ける決定的な違いだ。
SREに必要なスキル
土台はLinux・ネットワーク・クラウド。その上にプログラミング、可観測性、SLO設計、インシデント対応が必須として乗る。分散システムの理解が深さを決める。
| スキル | 重要度 | 内容 |
|---|---|---|
| Linux/ネットワーク | 必須 | TCP/IP、DNS、Linux内部 |
| クラウド（AWS/GCP/Azure） | 必須 | 主要サービスの設計と運用 |
| プログラミング | 必須 | Go、Python、Rustで自動化ツール開発 |
| 可観測性ツール | 必須 | Prometheus、Grafana、Datadog、OpenTelemetry |
| インシデント対応 | 必須 | ランブック、ポストモーテム、根本原因分析 |
| SLO設計 | 必須 | SLI測定、エラーバジェット運用 |
| 分散システム理解 | 推奨 | CAP定理、結果整合性、サーガパターン |
| Chaos Engineering | あると有利 | Gremlin、Chaos Mesh |
プログラミングできないSREはありえない
DevOps以前の運用エンジニアと最大の違いがこれだ。SREは「運用業務をソフトウェアで解決する」職種なので、プログラミング能力なしには成立しない。Go、Python、Rustなどで自前ツールを開発できることが必須条件になる。
求められるのは派手なアルゴリズムではなく、「毎晩2時に走る復旧スクリプト」「アラートの閾値を自動調整する仕組み」「障害時に状況を集約するCLI」といった、運用の痛みを消す実装だ。コードでインフラを御せるかどうかが、SREの市場価値を決める。
SREの年収相場
SREは2020年代に最も需要が伸びた職種のひとつで、平均年収は同経験年数のバックエンドエンジニアより1〜2割高い傾向がある。信頼性を数字で守れる人材は希少だからだ。
| 経験段階 | 年収レンジ | 想定企業 |
|---|---|---|
| ジュニアSRE（1〜3年） | 500〜750万円 | Web系、SaaS |
| ミドルSRE（3〜7年） | 750〜1,200万円 | メガベンチャー、上位SaaS |
| シニアSRE（7年以上） | 1,000〜1,800万円 | 上場テック、外資 |
| スタッフSRE／プラットフォームリード | 1,500〜2,500万円 | 上位企業 |
| 外資テック（Senior以上） | 1,800〜4,000万円 | Google、Stripe、Datadog等 |
SREのキャリアパス
SREは「信頼性」という横断的なテーマを扱うため、その先の選択肢が広い。技術を深めても、組織を率いても、専門を尖らせても通用する。
| 次のキャリア | 内容 |
|---|---|
| SRE → プラットフォームエンジニア | 開発者体験方面 |
| SRE → アーキテクト | 全社的な信頼性戦略 |
| SRE → セキュリティエンジニア | クラウドセキュリティ |
| SRE → エンジニアリングマネージャー | マネジメント |
| SRE → CTO／VPoE | 経営参画 |
未経験からSREになるには
SREはいきなり目指す職種というより、開発か運用の地力を付けてから移る職種だ。システムを作り、動かし、壊れる様子を見た経験が土台になる。
- バックエンドかインフラで実務3〜5年：システムを構築・運用し、障害を自分の手で経験する。
- SREの教科書を読む：Googleの『Site Reliability Engineering』3部作で思想と語彙を身につける。
- 可観測性ツールを実務で使う：Prometheus、Grafana、Datadogでダッシュボードとアラートを設計する。
- 個人プロジェクトでChaos Engineeringを体験：擬似的に障害を注入し、復旧を自動化してみる。
- SRE職に転職／社内異動：明確に信頼性領域を担当するポジションへ移る。
開発側から来るならバックエンド、基盤側から来るならインフラが王道の入口だ。どちらの経験もSREでそのまま武器になる。
よくある質問（FAQ）
Q. インフラエンジニアからSREへ転身できる？
できる。むしろ王道ルートのひとつだ。ただしプログラミング力（Go、Python）の習得が前提になる。手作業の運用を「コードで消す」発想に切り替えられるかが分かれ目だ。
Q. SREとDevOpsエンジニアはどちらが上？
上下関係はない。SREは「信頼性」、DevOpsエンジニアは「開発・運用プロセス」を主軸とする別の職種だ。企業によっては同じ仕事を別名で呼んでいるだけのこともある。
Q. SREはオンコール（夜間対応）がある？
多くの企業で発生する。ただしトイル削減と自動化が進んだ組織ほどオンコールの頻度は下がる。アラートの質を上げ、自動復旧を増やすこと自体がSREの仕事でもある。
Q. SLOは何%に設定すればいい？
サービスの性質で変わる。決済や医療なら99.99%以上を狙うが、社内ツールなら99%でも十分なことがある。重要なのは「ユーザーが許容できる失敗の量」から逆算することで、闇雲に高くしないのが鉄則だ。
Q. 小さな会社にもSREは必要？
専任は不要でも、SRE的な考え方は規模を問わず効く。SLOを1つ決め、ポストモーテムを残すだけでも運用は安定する。役割ではなく実践として取り入れる企業が増えている。
まとめ──SREは「壊れない仕組み」を作る職種
SREの本質は、壊れたものを直すことではなく、壊れる前提でシステムを設計することにある。完璧な可用性は不可能だと認め、エラーバジェットの範囲内で許容する。リスクを定量化し、自動化で覆い尽くす。
サービスが落ちた朝、誰よりも先に原因を3つ思い浮かべられるなら、あなたにはSREの素養がすでにある。火を消す英雄ではなく、火事が起きない街を設計する人。それがSREという仕事の醍醐味だ。
参考・出典
- Google『Site Reliability Engineering』『The Site Reliability Workbook』
- Datadog / DORA「State of DevOps」系レポート（2024年）
- 各種転職サービスの公開年収データ（2025〜2026年）をもとにレンジを整理
ここまで職種の全体像を見てきたが、実務経験を積んだ先には「フリーランスとして独立する」というキャリアの分岐もある。会社員として年収を上げる道と並んで、案件単価で稼ぐ独立も現実的な選択肢だ。少しでも独立を視野に入れているなら、登録・面談が無料のフリーランスエージェントで、自分のスキルにどの程度の単価が提示されるかを確かめておくと判断がぶれない。情報収集だけの利用もできる。
- MidworksPR（給与保障・案件数が豊富）
- PE-BANKPR（業務系の安定案件に強い）
- IT求人ナビ フリーランスPR（AIマッチング・全国／フルリモート対応）
