「SREってよく聞くけど、インフラエンジニアと何が違うの？」
この疑問を持ったまま転職活動を進めると、求人票の読み違いや面接での的外れな回答につながります。SREとインフラエンジニアは業務が重なる部分も多く、混同されがちですが、アプローチ・スキルセット・評価指標の3点で明確な違いがあります。
この記事でわかること
- SREエンジニアの定義と誕生背景
- インフラエンジニアとSREの3つの違い
- SRE・DevOps・インフラエンジニアの役割の整理
- SREエンジニアの年収相場と市場動向
- インフラエンジニアからSREへ転職するために必要なスキル
対象読者: インフラエンジニア・運用エンジニアとしての経験があり、SRE転職を検討している方。SREという職種を調べ始めた段階の方にも対応しています。
SREエンジニアとは
SRE（Site Reliability Engineer）とは、ソフトウェアエンジニアリングの手法を使ってシステムの信頼性を向上させるエンジニアです。2003年にGoogleのBen Treynor Slossが提唱した概念で、現在は国内外の多くの企業が導入しています。
一言で表すと、 「開発者の思考を持つ運用エンジニア」 です。手作業による運用タスクをコードで自動化し、SLO（サービスレベル目標）に基づいてシステムの信頼性を数値で管理します。
SREの誕生背景
Googleが急速にサービスを拡大するなかで、従来の手作業による運用では限界が生じました。サービス規模が大きくなればなるほど、障害対応・デプロイ・スケーリングのたびに人力オペレーションが増え、エンジニアが疲弊していったのです。
そこでGoogleが採用したのが「運用の問題をソフトウェアエンジニアリングで解く」というアプローチです。運用エンジニアの代わりにコードを書き、繰り返し発生するオペレーション（トイル）を自動化することで、スケールしてもエンジニアの工数が増えない組織を目指しました。
この考え方をまとめた書籍「Site Reliability Engineering」（通称SRE本）をGoogleは無償公開しており、SREの実践指針として広く参照されています。
SREの3つのコア概念
SREを理解する上で欠かせない3つの概念を押さえておきます。
SLI（Service Level Indicator）
サービスの信頼性を測る指標です。「リクエスト成功率」「レイテンシ」「エラーレート」などが代表的なSLIです。
SLO（Service Level Objective）
SLIに対する目標値です。「成功率99.9%以上」「P99レイテンシ200ms以下」のように設定します。SLOはエンジニアチームとビジネスサイドが合意した基準であり、優先度判断の根拠になります。
エラーバジェット
「許容できる障害の余裕」を数値化したものです。SLOが99.9%であれば、月あたり約43分のダウンタイムが許容されます。エラーバジェットが残っている間は新機能のデプロイを進め、消費しきったら安定化に専念する、というトレードオフ管理に使います。
SREエンジニアが担う主な業務
- SLO設計・運用: サービスの信頼性目標を設定し、継続的にモニタリングする
- トイル削減: 手作業による繰り返し業務をコードで自動化する
- インシデント対応・事後分析: 障害発生時のオンコール対応とポストモーテム実施
- CI/CDパイプライン整備: デプロイの自動化と安全化
- キャパシティプランニング: リソース使用量の予測とスケーリング設計
- 可観測性（Observability）基盤構築: メトリクス・ログ・トレースの収集・分析環境を整備する
インフラエンジニアとは
インフラエンジニアは、企業のIT基盤（サーバー・ネットワーク・ストレージ・クラウド）を設計・構築・運用するエンジニアです。システムが安定して動き続けるための土台づくりが主な役割です。
インフラエンジニアの業務範囲
- サーバー・ネットワーク機器の設計・構築・設定
- クラウドサービス（AWS・GCP・Azure）の構築・管理
- 監視設定・アラート管理
- 障害対応・メンテナンス
- セキュリティ設定・バックアップ管理
- 手順書・設計書の作成・管理
インフラエンジニアに求められるスキル
- Linux/Windowsサーバーの構築・運用
- ネットワーク（TCP/IP・DNS・ロードバランサー）の知識
- クラウドサービスの知識（AWS SAAレベルが目安）
- 監視ツールの操作（Zabbix・Datadog・CloudWatchなど）
- シェルスクリプトによる自動化の基礎
SREとインフラエンジニアの違い【3つの視点】
①アプローチの違い：手順書 vs コード
インフラエンジニアは、設計書・手順書に基づいた確実なオペレーションでシステムの安定を守ります。特に金融・官公庁などの厳格な環境では、承認フローを経た手順書通りの作業が求められます。
SREは、そのオペレーション自体をコードに置き換えることを目指します。
たとえば「新しいサーバーの初期設定」という作業であれば：
- インフラエンジニア的アプローチ: 手順書にしたがってSSHで接続し、コマンドを1つずつ実行する
- SRE的アプローチ: Ansible・TerraformでIaC化し、コマンド1つで同一環境を何度でも再現できるようにする
Googleのガイドラインでは、SREの業務時間のうちトイル（手作業の繰り返し）は50%以下に抑えることが推奨されており、残りの時間はエンジニアリング作業（自動化・改善）に充てるべきとされています。
②求められるスキルセットの違い
| スキル | インフラエンジニア | SRE |
|---|---|---|
| Linux・ネットワーク基礎 | ◎ 必須 | ◎ 必須 |
| クラウド（AWS等） | ○ 必要 | ◎ 必須 |
| プログラミング（Python・Go等） | △ あれば望ましい | ◎ 必須 |
| IaC（Terraform・Ansible） | △ 環境による | ◎ 必須 |
| コンテナ・Kubernetes | △ 環境による | ○ 必要 |
| SLO設計・エラーバジェット | × 不要なことが多い | ◎ 必須 |
| 可観測性（Prometheus・Datadog等） | ○ 監視ツール操作 | ◎ 設計から担当 |
| ソフトウェア設計・アーキテクチャ | △ | ○ 必要 |
最大の差はプログラミング能力とSLO設計の知識です。SREはインフラの知識に加えて、ソフトウェアエンジニアとしての開発力が求められます。
③評価指標の違い
インフラエンジニアの評価は「手順書通りに作業できたか」「障害を未然に防げたか」「ダウンタイムをゼロに近づけられたか」といった定性的・安定性重視の指標になりがちです。
SREの評価は数値で行います。「SLO達成率は何%か」「エラーバジェットの消費ペースは計画通りか」「トイル率を50%以下に抑えられているか」といった定量的な指標で健全性を測ります。
この違いは、ビジネスとの対話にも影響します。SREはSLOという共通言語を使ってエンジニアリングとビジネスの優先度を調整します。「エラーバジェットが残り20%なので今月はデプロイを控えましょう」という会話が成立するのはSREのアプローチがあってこそです。
SRE・DevOps・インフラエンジニアの関係を整理する
この3つを混同しているケースは多いため、整理します。
DevOpsは文化・哲学、SREは実装手法
DevOpsは「開発（Development）と運用（Operations）のサイロをなくし、協力して速くリリースし続ける」という文化・哲学です。具体的な手順や役職を定義するものではありません。
SREはDevOpsの思想を実現するための具体的な方法論です。Googleは「SREはDevOpsの一つの実装形態」と位置づけています。
インフラエンジニアはシステムの基盤を担う職種で、DevOpsやSREとは職能の軸が異なります。DevOps文化のある組織でインフラを担当するエンジニアが「インフラエンジニア」であり、SRE的なアプローチ（IaC・SLO・自動化）を取り入れているエンジニアが「SRE」です。
役割の重複と使い分け
思想・文化: DevOps
↓
実装手法: SRE
↓
担当職能: インフラエンジニア（SRE的アプローチを採用する場合もある）
実務では「インフラエンジニアがSREの手法を取り入れて働いている」ケースも多く、職種名が会社によってバラバラなのはこのためです。求人票を見るときは職種名より業務内容・使用ツール・評価指標を確認する方が実態に近いです。
SREエンジニアの年収・市場価値
平均年収の相場
SREエンジニアの年収は、スキルと経験によって幅があります。
| レベル | 年収目安 |
|---|---|
| 未経験〜2年 | 400〜600万円 |
| 3〜5年 | 600〜800万円 |
| 5年以上・シニア | 800〜1,200万円 |
| 外資・大手テック | 1,000〜1,500万円以上 |
転職ドラフトのデータ（2024年）では、SRE経験者の平均提示年収は約685万円で、一般的なバックエンドエンジニアより高い傾向にあります。
需要が急拡大している理由
SRE需要が急拡大している背景には、クラウドネイティブへの移行加速があります。
モノリシックなシステムからマイクロサービス・Kubernetes構成に移行した結果、運用の複雑さが格段に増しました。従来の手作業による運用では対応できなくなり、SLO設計・自動化・可観測性に強いSREの需要が急増しています。
転職ドラフトの指名数データでは、2020年以前はSRE経験者への指名が全体の4%以下でしたが、2021年には約7.9%まで上昇しています。クラウド移行が加速している現在、SRE需要はさらに拡大しています。
インフラエンジニアからSREへ転職するために必要なスキル
インフラエンジニアからSREへの転向は、3つのスキルギャップを埋めることが最短経路です。
①プログラミングスキル（Python・Go）
SREが最も必要とするのは自動化のためのコーディング力です。Python（スクリプト・自動化）またはGo（パフォーマンス重視のツール開発）を習得します。
現実的な目標: 既存の手作業オペレーションを1つPythonスクリプトに置き換えられるレベル。APIを呼び出してSlackに通知する程度のスクリプトが書けると転職活動で実績として話せます。
②IaC（Infrastructure as Code）
TerraformによるAWSリソースのコード管理を習得します。インフラエンジニアがコンソール操作でやっていた作業をTerraformで再現することから始めると、既存知識が活きます。
現実的な目標: AWSのVPC・EC2・RDSをTerraformで構築・管理できるレベル。GitHub ActionsでTerraform planを自動実行できると評価が高まります。
③SLO設計とモニタリング
SREの中核であるSLO設計を理解し、PrometheusやDatadogで実際にメトリクスを設計・設定できるようにします。
現実的な目標: 自分が担当するサービスにSLIを定義し、Grafanaダッシュボードで可視化したポートフォリオを作る。エラーバジェットの概念を自分の言葉で説明できること。
転職先の選び方
SREポジションを募集している企業は、求人票の以下の記載で実態を判断します。
- 実質SRE: 「SLO/SLI設計」「エラーバジェット管理」「トイル削減」の記載がある
- 名前だけSRE（インフラ運用）: 「監視設定」「障害対応」「手順書作成」のみの記載
- DevOps寄り: 「CI/CD構築」「デプロイ自動化」がメインで信頼性指標の記載なし
SREとして成長したい場合は、SLOやエラーバジェットの概念が組織に根付いている企業を選ぶことが重要です。
まとめ
SREエンジニアとインフラエンジニアの違いを3つの視点で整理しました。
- アプローチ: 手順書によるオペレーション vs コードによる自動化
- スキル: インフラ知識 vs インフラ知識 ＋ プログラミング ＋ SLO設計
- 評価指標: 定性的な安定性 vs SLO達成率・エラーバジェットによる定量評価
インフラエンジニアからSREへの転職は、プログラミング（Python/Go）・IaC（Terraform）・SLO設計の3つを習得することが最短ルートです。インフラの実務経験はSREとして大きな強みになります。
SRE転職を本格的に考えている場合は、IT特化の転職サービスを活用することで非公開求人や年収交渉のサポートを受けられます。
SRE転職に強い転職サービス（無料登録）
- Green — IT・Web業界特化。SREポジションの掲載数が多い
- Findy — GitHubスコアで自動マッチング。エンジニア向け
- レバテックキャリア — エンジニア専門エージェント。年収交渉に強み
SREのスキルを体系的に学びたい場合は、AWS環境でSRE実務を学べるUdemyコース「 AWS×SRE入門 」も参考にしてください。インフラエンジニアがSREへ転向するために必要なスキルを実践ベースで習得できます。
コメント