SREとは？仕事内容・年収・必要スキルとDevOpsとの違いをエンジニア視点で解説

SREとは｜信頼性を「コードで担保する」運用の考え方

SRE（Site Reliability Engineering）は、Googleが2003年ごろから組織内で運用してきたシステム運用の方法論です。Ben Treynor Sloss氏が提唱し、書籍『Site Reliability Engineering』（O'Reilly、通称SRE本）で体系化されたことで広く知られるようになりました。

中心にあるのは、「運用業務をソフトウェアエンジニアリングの手法で扱う」という考え方です。サーバの再起動・ログ調査・スケール変更といった運用作業を、人手による手順書ベースではなく、コード・指標・自動化で扱います。結果として、信頼性をビジネス目標として数値で扱える状態を作るのがSREの役割です。

「信頼性をエンジニアリングする」とは具体的に何をするのか

具体的な活動は次のように整理できます。

• サービスの信頼性を数値（SLO）として宣言し、その数値を満たすようインフラ・アプリ両側で改善する

• 障害対応・繰り返し発生する手作業（トイル）をコードで置き換える

• 障害の根本原因分析（ポストモーテム）を非難なしで実施し、再発防止策をプロダクトの仕様に組み込む

• 開発チームと信頼性の予算（エラーバジェット）を共有し、新機能のリリース速度と信頼性のバランスを取る

「サーバを守る」のが従来運用、「サービスの信頼性を持続的に作る」のがSREです。

SREが生まれた背景

GoogleがSREを生んだ背景は単純で、検索やGmailのようなサービスは人手の運用ではスケールしないからです。サーバ台数が万単位に達すると、人がコマンドを打って復旧する運用は破綻します。「運用業務の上限を、エンジニアリングで引き上げる」必要が出てきます。

ここで生まれたのが、運用業務にエンジニアリングの手法を適用する役割としてのSREです。トイルを減らし、信頼性を計測し、コードで自動化する。これが現在の定義として定着しています。

ミニFAQ：定義編

Q. SREとは「役割」ですか、それとも「方法論」ですか？

A. 両方です。最初に「方法論」として始まり、その方法論を実践する人を指す「職種」としても使われるようになりました。求人で「SREエンジニア募集」と書かれているときは、職種としての意味です。

Q. 規模の小さいサービスでもSREの考え方は使える？

A. 使えます。SLOを設定する、トイルを意識的に削減する、ポストモーテムを書くといった実践は、エンジニア1〜2人のチームでも導入可能です。Google規模の体制が前提というわけではありません。

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

SRE・DevOps・インフラエンジニア・プラットフォームエンジニアは、似た領域を扱う言葉ですが指す対象が違います。整理しておかないと、求人票や記事を読むときに混乱します。

4つの役割の関係

DevOpsは開発と運用の壁を壊す思想、SREはその思想を運用側から具体化する手法と職種です。インフラエンジニアは基盤そのものを扱い、プラットフォームエンジニアは開発者の生産性のための基盤を扱います。

Googleの「class SRE implements DevOps」

Googleが提示している「class SRE implements DevOps」というフレーズが一番わかりやすい説明です。オブジェクト指向の比喩で「DevOpsはインターフェース、SREはその実装クラス」という意味になります。DevOpsが目指す世界（開発と運用の継続的な協業、自動化、信頼性）を、具体的な手法・指標・組織で実装したものがSRE、と読み替えれば誤解しません。

インフラエンジニアからSREへ

実務では、インフラエンジニアがSREへ移行するパスが多くなっています。違いは大きく3点です。

1. コードを書く比率が増える。Terraform・Ansible・Pythonでの自動化が日常業務になります

2. 指標で語る比率が増える。「サーバを安定運用しています」ではなく「99.95%のSLOを達成」と語ります

3. アプリケーション側へ踏み込む比率が増える。バグの修正PRをアプリチームに送ったり、コードレビューに参加したりします

インフラエンジニアの業務範囲についてはインフラエンジニアとは？仕事内容や年収、将来性について解説でまとめています。クラウド側の役割と比較したい場合はクラウドエンジニアとは？仕事内容や必要なスキル、年収について解説を参照してください。

ミニFAQ：違い編

Q. DevOpsエンジニアとSREエンジニアの求人は何が違う？

A. 実務の中身は重なる部分が大きいですが、SREの方が「信頼性指標・SLO・エラーバジェット」を明示的に扱う度合いが強い傾向があります。求人票に「SLO」「トイル」「ポストモーテム」が並んでいたらSRE色が濃いと判断できます。

Q. インフラエンジニアからSREに転向する人は多い？

A. キャリアパスとしては定番です。とくにAWS・GCP・Azureなどクラウドの実務経験と、Terraformなどのコード化経験があれば、SREへの移行はスムーズになります。

SREの仕事内容｜信頼性を作る5つの活動

実際にSREが何をしているかを、活動単位で整理します。求人票の記述や案件の業務内容も、ほぼこの5つの組み合わせです。

1. SLI/SLOの設計と運用

サービスの「信頼性」を、可観測な指標（SLI）と目標値（SLO）で宣言します。

• SLI例：API成功率、p99レイテンシ、ジョブ完了率、画面表示時間

• SLO例：「直近30日でAPI成功率99.9%以上」「p99レイテンシ300ms以下」

SLIを「ユーザー視点で意味のある」ものに設定する判断が、SREの最初の腕の見せどころです。サーバCPU使用率は通常、ユーザー向けSLIには置きにくい指標です（内部監視や補助指標として扱うケースはあります）。

2. エラーバジェットの管理

SLOから逆算して、許容できる失敗の量（エラーバジェット）を計算します。

• 月間SLO 99.9% ＝ エラーバジェット 0.1% ＝ 約43分のダウン許容（30日換算）

エラーバジェットが残っているうちは新機能を積極的にリリース、使い切ったらリリース凍結して信頼性改善を優先する、という運用ルールに使います。プロダクトマネージャーや開発チームと共有することで、リリース速度と信頼性のトレードオフを政治ではなく数値で議論できる状態を作ります。

3. トイルの削減と自動化

トイル（toil）とは、手作業・繰り返し・自動化可能・サービス成長に比例して増えるが価値を生まない作業のことです。具体例は次のようなものです。

• 障害アラートに対する手動対応

• 月次のキャパシティ増強作業

• リリースのたびに発生する手動デプロイ手順

• 同じ調査を毎回手動で繰り返すログ確認

トイルをコード化して減らす作業がSREの中心業務のひとつです。GoogleのSRE本では、トイルは業務時間の50%以下に抑えるという考え方が示されています。

4. インシデント対応とポストモーテム

障害が発生したら、復旧と並行して以下を実行します。

• インシデントコマンダー・通信担当・調査担当などの役割を明確化

• 復旧後、24〜72時間以内にポストモーテムを書く

• 「個人を責めない（blameless）」前提で根本原因と再発防止策を共有

「人為ミスでした。気をつけます」で終わらせず、「同じ操作ミスをしてもサービスが落ちないようにガードレールを入れる」という再発防止策を組み込みます。

5. キャパシティプランニングと負荷試験

トラフィックの増加・季節性・キャンペーン施策などに対して、リソースを事前に設計します。

• 平常時負荷からの増加倍率を見積もる

• 負荷試験でボトルネックを特定する

• オートスケーリング設定とリソースリザーブを調整する

クラウドネイティブ環境では、Kubernetes HPA・AWS Auto Scaling・GCP Managed Instance Groupなどを使い、コードで設計します。

ミニFAQ：仕事内容編

Q. SREは夜間オンコール対応をする？

A. SRE求人ではオンコールを含むケースが比較的多く見られます。ただしSREの目的は「夜間対応の頻度を減らす」ことなので、オンコール頻度・通知数自体をSLI/SLOで管理し、削減目標として扱う運用が一般的です。

Q. アプリケーションコードも書きますか？

A. 書くケースが多くなります。アプリ側のバグ修正PRを出したり、ライブラリの計装（メトリクス埋め込み）を提案したりします。アプリチームと地続きで動ける範囲が広いほど、SREとしての価値は上がります。

SREに必要なスキル｜5領域の組み合わせ

SREの求人で求められるスキルは、おおむね次の5領域の組み合わせです。1つだけ尖っていても通用しにくく、T字型に広く・深くを求められます。

5領域のスキルセット

補助的に重視されるソフトスキル

技術スキルだけでは現場で機能しません。以下も同等に重視されます。

• インシデント時の冷静なコミュニケーション：障害中の指揮、ステークホルダーへの状況報告

• ポストモーテムの執筆力：事実と推測を分け、再発防止策を提案する文書作成

• 数値で議論する習慣：「重い」「遅い」ではなく「p99が500ms→1.2sに悪化した」と話せる

• 開発チームとの折衝：信頼性の悪化要因が機能リリースにある場合、エラーバジェットを根拠に交渉する

スキルチェックリスト：今の自分はどこにいるか

未経験〜ジュニアSRE志望者向けに、節目を整理しておきます。

• [ ] LinuxサーバでWebアプリを動かして、モニタリングできる

• [ ] DockerでアプリをコンテナとしてビルドしてEC2/GCEに乗せられる

• [ ] AWSまたはGCPで、TerraformでVPC〜EC2/GKEを構築できる

• [ ] KubernetesでDeploymentを書き、HPA・Service・Ingressまで構成できる

• [ ] PrometheusとGrafanaでメトリクスを収集・可視化できる

• [ ] Goまたは Pythonで、APIサーバ・CLIツールを実装できる

• [ ] 自分の運用しているサービスでSLI/SLOを設計し、ダッシュボード化できる

あくまで目安ですが、上から3つでジュニア帯の応募準備、5つでミドル帯の土台、7つでシニア候補の入り口、というイメージです。求人ごとに重視ポイントは違うため、必須スキルは募集要項を直接読んでください。

ミニFAQ：スキル編

Q. プログラミング経験がほぼない状態からSREを目指すのは現実的？

A. 可能ですが、最低でもインフラ経験＋スクリプト言語1つは必要です。Bash・Pythonで運用ツールを書ける状態がジュニアSREの入り口です。アプリエンジニアからの転向の方が早いケースも多くなっています。

Q. 資格は必要？

A. 必須ではありません。AWS Certified Solutions Architect / DevOps Engineer、CKA（Certified Kubernetes Administrator）、HashiCorp Certified: Terraform Associateなどは知識整理に役立つ程度です。実務経験のほうが優先されます。

SREの年収・単価｜国内市場の傾向

主要転職サービスの公開求人を見ると、SRE職を独立職種として募集する企業が目立ちます。クラウドネイティブ化を進める企業が増え、運用負荷をエンジニアリングで解決できる人材の募集が継続的に出ている領域です。

年収レンジ（正社員）

首都圏の自社開発企業やIT企業の公開求人を中心に見ると、SRE職は以下のような傾向で募集されています。具体的な金額は各社の規模・所在地・契約条件で変動するため、あくまで公開求人ベースの目安として参照してください。

ジュニア層は他のITエンジニア職と大きな差は出ませんが、ミドル以降でクラウド・コンテナ・SLO設計の経験が積み上がると、レンジ上限が伸びやすい特徴があります。

フリーランス・業務委託の単価

主に週4〜5日稼働の公開案件を中心に、フリーランスエージェントの案件情報を参考にすると、SRE案件は次のような単価レンジで募集されているケースが見られます。

• 月額70〜100万円：クラウド構築・運用の実務経験者向け

• 月額100〜140万円：Kubernetes本番運用・SLO設計経験者向け

• 月額140万円以上：技術選定・アーキテクチャ責任を負える層向け

これらの数字は主要フリーランスエージェントの公開案件ベースで観測される目安であり、稼働日数（週3〜5日）・リモート可否・契約形態によって幅があります。実際の提示額はスキル詳細・面談結果・契約期間で決まります。

「月額140万円以上」のレンジで募集されるケースでは、複数サービスのSLO設計を主導した経験、大規模障害（数千ユーザー以上影響）の収束を主導した経験、ベンダ折衝や技術選定の意思決定経験など、チーム/組織レベルの責任範囲を持つ人物像が条件として示される傾向があります。

年収・単価を押し上げる要素

求人票・案件情報を横断的に見ると、レンジの上振れに効きやすい要素は次のとおりです。

• Kubernetes本番運用2年以上（マネージドサービスではなく自社設計の経験）

• マルチクラウド経験（AWSとGCPの両方を本番で運用）

• 大規模ユーザー（DAU 100万以上など）のサービスでのSRE経験

• SLO/エラーバジェットを開発組織に導入し、運用に乗せた経験

• セキュリティ・コンプライアンス領域（PCI DSS / SOC 2 / ISMS）の運用経験

逆に、運用経験のみでコード化やSLO設計の経験がないと、レンジは上がりにくいというのが市場の傾向です。

ミニFAQ：年収編

Q. 副業でSRE案件はある？

A. あります。週1〜2日のスポット稼働で、SLO設計のレビュー・障害対応プロセス策定・Terraformリファクタリングなどを担当する案件が公開されているケースがあります。本業との競業避止義務を確認してから検討してください。

Q. 未経験からのSRE転職で年収は下がる？

A. インフラ・サーバサイドからの転向であれば、現年収を維持または上げる形での転職事例が見られます。完全未経験からは少数で、まずは現職でSRE的な活動（監視整備・トイル削減・障害分析）を実績として積むのが定石です。

フリーランスSREの動向と注意点

正社員ではなくフリーランスSREとして案件を取りに行く人も増えています。codebridge登録者の中にも、社内SREから独立してフリーランスSREに転向するケースが見られます。

フリーランスSRE案件の特徴

主要フリーランスエージェントの公開案件を見る限りでは、次のような傾向があります。

• 月額100万円超の募集が比較的見られる（経験・スキル次第）

• テーマ限定の支援案件では、週2〜3日稼働の募集も見られる

• リモート可の案件は比較的多めに見られるが、セキュリティ要件で出社・ハイブリッドを求める案件もある

• 「SLO設計支援」「Kubernetes移行支援」「障害対応プロセス策定」など、テーマが明確な短期案件もある

独立する前にやっておくべきこと

社員SREからフリーランス転向を検討するなら、最低限以下を整えておきます。

1. 直近2年でリードしたSREプロジェクトの具体例を整理（規模・課題・自分が出した変化を数字で）

2. ポートフォリオ的なドキュメント・登壇資料・OSSへのコミットなど、外部から検証可能な実績

3. 単価交渉のために、自分の市場相場を複数のフリーランスエージェントで確認

4. 確定申告・国保・国民年金など税務・社会保険まわりの初期設計

税務・社会保険の初期設計についてはフリーランスエンジニアの確定申告｜やり方・必要書類・期限をわかりやすく解説、会社員時代との手取り比較はフリーランスエンジニアと会社員の違い｜手取り・働き方・リスクを徹底比較で扱っています。40代以降での独立を考えている場合は40代フリーランスエンジニアになるには｜案件動向・単価相場・独立の進め方を解説も参考にしてください。

フリーランスSREに向いていない人

正直に書くと、向き不向きはあります。

• 安定した固定業務ではなく、変化の多い課題を渡される働き方が苦手な人

• ドキュメント・ポストモーテム・ナレッジ共有を書くのが嫌いな人

• 単独で意思決定して短期で成果を出すより、チームで時間をかけて作り込む方が好きな人

これらに該当する場合は、社員SREの方が活躍しやすいことが多くなります。

学習・キャッチアップに使えるリソース

未経験〜ミドル層が体系的に学ぶときの代表的なリソースをまとめます。

• 書籍『Site Reliability Engineering』（O'Reilly、通称SRE本）：Google SRE公式サイトで無料公開

• 書籍『The Site Reliability Workbook』：実践編

• 書籍『Building Secure & Reliable Systems』：信頼性とセキュリティの統合

• Google Cloud Architecture Center: SRE：クラウドベンダーのSRE実装ガイド

• Kubernetes公式ドキュメント kubernetes.io

• HashiCorp Learn learn.hashicorp.com：Terraform / Vault / Consulのチュートリアル

書籍は英語版も無料で読めるため、まずはSRE本の第1〜3章を通読してSRE文化の基礎を押さえるのが王道のスタートです。

よくある失敗と対策

SREを目指す/取り組む人がつまずきやすい典型例を挙げます。

失敗1：SLOを「達成可能な甘い目標」に設定する

99.99%や99.999%といった見栄えの良い数字を、計測可能な根拠なしに設定すると、運用が破綻します。現状のSLI観測値より少し高い数値から始め、3〜6ヶ月単位で見直すのが現実的です。

失敗2：トイルを「忙しさの自慢」と勘違いする

「夜中のアラート対応で頑張っています」を成果として語る文化があると、SREは機能しません。トイルは減らすべき指標で、対応量ではなく削減量で評価する運用に切り替えます。

失敗3：ポストモーテムが個人攻撃になる

「誰のミスか」を追求すると、隠蔽が発生し、ポストモーテム自体が機能しなくなります。blameless（非難なし）の前提を組織で合意してから運用を始めるのが鉄則です。

失敗4：監視を入れて満足する

Datadog・New Relic・Grafanaを導入しただけで「観測している」と勘違いするケースです。SLIに直結するメトリクスのみを残し、ノイズダッシュボードを削る作業まで含めて初めて運用に乗ります。

失敗5：開発チームと敵対関係になる

エラーバジェットを「リリース禁止の根拠」として一方的に押し付けると、チーム間で対立が生まれます。信頼性とリリース速度のトレードオフ判断を一緒にする立場としてSREが機能するよう、合意形成のプロセスを先に整えます。

SRE関連用語チートシート

求人票・案件情報・社内議論で頻出する用語を、最低限のレベルで一覧化しておきます。

まとめ｜SREは「信頼性をエンジニアリングで作る」役割

最後に要点を整理します。

• SREは信頼性をコードと指標で作る役割。手作業運用ではなく、SLI・SLO・エラーバジェット・トイル削減・ポストモーテムが軸になる

• DevOpsは思想、SREは実装。「class SRE implements DevOps」の関係

• 必要スキルはクラウド・コンテナ・IaC・監視・プログラミングの5領域。とくにKubernetes・Terraform・Prometheus・Goは頻出

• 公開求人・公開案件ベースで見ると、国内の正社員年収は中堅で700〜1,000万円前後のレンジで募集されるケースが見られる。フリーランスは経験5年前後でも月額単価が高めに設定される案件もある

• 未経験からはインフラ/サーバサイド経験を1〜2年積み、SRE的な活動を実績化してから転向するのが定番ルート

SRE職は、運用とエンジニアリングの境界に立てる人にとって、技術的な伸びしろもキャリアの選択肢も広がる役割です。社員として深掘りするか、フリーランスとして複数組織を支援するかで動き方は変わりますが、いずれも「信頼性を数字で作れる」という核は変わりません。

フリコンでは、SRE経験を活かした案件のご相談・年収/単価のすり合わせ・独立準備のサポートが可能です。現職での経験整理から始めたい人も、すでに独立を決めている人も、まずは面談で状況を共有してください。

参考リンク

• Google SRE 公式サイト（書籍も無料公開）

• Google Cloud Architecture Framework: 信頼性

• Kubernetes 公式ドキュメント

• HashiCorp Developer（Terraform 等）