SREエンジニアの年収は「求人票の上限」では決まらない｜本人申告の中央値700万円と求人62件の分析でわかる評価軸【2026年9月版】

「SREエンジニア 年収」で検索すると、「平均800万〜1,500万円」「年収1,000万円以上の求人多数」といった景気のいい数字が並びます。一方で、実際にSREとして働いている人の申告データを見ると、中央値は700万円です。

どちらも嘘ではありません。見ているデータの種類が違います。この記事では、インフラエンジニアやバックエンドエンジニアがSREへの移行を考えるときに必要な数字を、本人申告・求人票・人材紹介会社の3種類のデータに分けて整理し直しました。そのうえで、求人票62件を実際に読み込み、どの要件があると提示年収の上限が上がるのかを集計しています。

SREの職務内容や転職ロードマップ全体はSRE転職ロードマップ（年収相場・「やめとけ」論・移行戦略）にまとめています。この記事は「年収の数字をどう読むか」と「何が年収を決めるか」に絞った内容です。

SLI-01 / DATASREエンジニアの年収は？3種類のデータで数字が違う理由

SREの年収として出回っている数字は、出どころで大きく3種類に分かれます。まずは並べてみます。

「平均800万〜1,500万円」系の記事は、多くがロバート・ハーフのような人材紹介会社の想定レンジや、求人票の上限側を根拠にしています。紹介会社のデータは、その会社が扱う案件（外資系・ハイクラス層）に引っ張られます。求人票の上限は「その枠で出せる最大値」で、全員に出る金額ではありません。

いまの自分の市場価値を測るなら本人申告の分布、応募先を選ぶなら求人票の下限と上限の両方を見る、という使い分けが現実的です。

本人申告データの分布：中央値700万円、上位10%で1,245万円

PROJECT COMPは、エンジニアが自分の年収を匿名で登録するデータベースです。主スキルを「SRE」として登録している66人の分布は次のとおりでした。

※ 自己申告のため、年収の高い人ほど登録しやすい偏りがある可能性があります。年次別では1年目の中央値が562万円（n=12）、11〜14年目が905万円（n=9）でしたが、年次ごとのサンプルは数件〜十数件と少ないため参考値です。

SLI-02 / COMPARE「SRE」の肩書きで中央値は上がらない。差がつくのは上位層

SREへの移行を考えるインフラエンジニアやバックエンドエンジニアにとって一番気になるのは、「SREになると年収は上がるのか」でしょう。同じPROJECT COMPのデータで、主スキル別の分布を並べました。

単位は万円。出典: PROJECT COMP 主スキル別データ（2026年9月28日取得）。

読み取れることは2つあります。

1つ目は、SREの中央値700万円はサーバーサイド開発と同じで、インフラ（680万円）ともほぼ変わらないことです。「SREに職種名が変わった」だけでは、典型的な年収はほとんど動きません。

2つ目は、P75・P90ではSREが頭ひとつ抜けることです。P75はサーバーサイドより95万円、インフラより85万円高く、P90は1,245万円でサーバーサイドを80万円、インフラを165万円上回ります。SREは「平均的な人の年収が高い職種」というより、上位層の年収の伸びしろが大きい職種だと読むのが正確です。

では、その上位層に入る人は何が違うのか。これは求人票の側から見ると分かりやすくなります。

SLI-03 / JOB POSTS求人票62件を集計：下限は600万円で横並び、上限が要件で動く

2026年9月28日時点で、求人サイトGreenで「SRE」スキルが付いた求人は737件（313社）ありました。年収条件で絞り込むと、「800万円以上」で615件、「1,000万円以上」でも455件（全体の約62%）がヒットします。「SRE求人は高年収」と言われるのはこのためです。

ただし、この検索条件は「レンジのどこかがその金額に届く求人」を拾います。そこで、検索結果から取得できた62件について、年収レンジの下限と上限を分けて集計しました。

単位は万円。Green掲載のSRE求人のうち、年収レンジを取得できた62件（2026年9月28日取得）。全737件のうちの一部であり、偏りがある可能性があります。

上限1,000万円以上の求人は62件中44件（71%）ある一方、下限が800万円以上の求人は11件（18%）しかありません。典型的なSRE求人は「600万〜1,000万円」という400万円幅のレンジで出ていて、本人申告の中央値700万円はそのレンジの下から4分の1あたりに当たります。

どの要件があると上限が上がるのか

62件の求人本文（仕事内容・応募要件・歓迎要件）を読み、キーワードの記載がある求人とない求人で、下限と上限の中央値を比べました。

単位は万円。各項目の件数が少ないため、1件の違いで中央値が動きます。傾向を見るための目安として使ってください。

ここから言えるのは次の3点です。

• 下限はほぼどの要件でも600万円で動かない。スキル要件は「入口の金額」ではなく「上限の高さ」に効いている。
• IaCは差別化にならない。92%の求人がTerraform等を要件に書いており、書いていない5件はむしろ上限が高い（マネジメント職など職務の中心が別の求人）。IaCは「できて当然」の前提として扱われている。
• 「運用保守」「監視」が前面に出ている求人は下限が低い。SREという名前が付いていても、中身が従来の運用業務に近い求人は、入口の金額で差がつく。

SLI-04 / EVALUATIONSREの年収を決める4つの評価軸

求人票の傾向を、SREの仕事の成熟度に沿って並べ直すと、4段階の評価軸になります。GoogleのSRE本は、SREの時間のうち運用作業（トイル）を50%未満に抑えることを目標に掲げています。自動化で運用を減らすのはスタート地点で、その先で何を作れるかが年収の上限を分けます。

L1：運用の自動化（トイル削減・IaC）＝入口の条件

Terraformでのインフラのコード化、CI/CDの整備、手作業の手順のスクリプト化。求人票の下限600万円を提示される条件がここです。インフラエンジニアから移る人は、「構築した」だけでなく「どの作業を何時間減らしたか」を数字で言えるようにしておくと、同じL1でも評価が変わります。

L2：信頼性の設計（SLO・可観測性）＝上限+100万円

ユーザー体験に沿ったSLIを選び、SLOを合意し、エラーバジェットでリリース判断を回す。メトリクス・ログ・トレースを整えて障害の原因を早く絞れるようにする。「監視を入れた」と「SLOを決めて開発チームとリリース判断に使った」は別物として評価されます。面接では、SLOの数値そのものより「なぜその指標と閾値にしたか」「バジェットを使い切ったときに何を止めたか」を聞かれることが多い領域です。

L3：インシデント運営（オンコール・ポストモーテム）＝上限+200万円

今回の集計で上限への効き方が最も大きかったのがここです。障害に対応できることではなく、オンコール体制、エスカレーション、ポストモーテム（責任追及をしない振り返り）の文化を作れることが評価されています。「ポストモーテム」を本文に書いている求人は、下限も645万円と他より高めでした。

L4：組織への展開（チーム・マネジメント）＝上限+150万円

SREチームの立ち上げ、開発チームへのSRE文化の浸透、プラットフォーム化、メンバー育成。ここまで来ると、SREとしての専門性を深めるか、エンジニアリングマネージャー寄りに進むかの分岐も見えてきます。その判断軸はスペシャリストとマネジメントどっちを選ぶかで整理しています。

Goでの運用ツール開発など、L1〜L2の実装力を固めたい場合はGo学習ロードマップ（インフラ・SREトラック）が参考になります。クラウド資格の位置づけはAWS資格はエンジニアに必要かで検証しています。

SLI-05 / ON-CALLオンコール手当は求人票から読めない：面接で聞くべき5項目

SREの年収を考えるうえで見落とされがちなのが、オンコール（障害時の待機・呼び出し対応）の扱いです。年収の額面が同じでも、オンコールの頻度と手当の有無で、実質的な時給は大きく変わります。

今回、求人64件の詳細ページを確認したところ、オンコールや深夜・休日対応に触れている求人は14件ありました。そのうちオンコール手当の金額を書いている求人は0件です。書き方は次の3パターンに分かれていました。

労働基準法第37条により、22時〜翌5時の深夜労働には25%以上の割増賃金が必要です。ただし、自宅で呼び出しを待つだけの「待機」の時間が労働時間にあたるかは、拘束の強さによって扱いが変わります。そのため、待機手当と出動時の割増は分けて確認する必要があります。

参考までに、GoogleのSRE本は、オンコールに使う時間を全体の25%以内に抑え、12時間のシフトあたりのインシデントは最大2件を目安としています。オフ時間の対応には代休か金銭で報いる（給与全体に対する上限あり）としています。日本企業でここまで明文化している例は多くありませんが、質問するときの基準にはなります。

複数の内定を年収以外の軸も含めて比べる方法はエンジニアの複数内定を「3層」で比較するにまとめています。額面から手取りへの換算はエンジニアの年収手取り計算シミュレーションが使えます。

SLI-06 / MIGRATIONインフラ・バックエンドからSREに移るとき年収はどう動くか

ここまでのデータを、移る前の職種別に当てはめてみます。

インフラエンジニアから移る場合

本人申告の中央値はインフラ680万円・SRE700万円で、職種を変えただけでは20万円程度の差しかありません。インフラエンジニアの年収は、職種よりも商流（元請けか下請けか）と工程（運用・保守か設計・構築か）で大きく動くことが分かっています（詳しくはインフラエンジニアの年収は「低い」のか）。

そのため、SIerや下請けの運用ポジションから自社サービス企業のSREに移る場合は、SREという職種ではなく「商流が浅くなる」ことで年収が上がる余地があります。逆に、すでに自社サービス企業でインフラを担当している人は、L2〜L3の実績を作ってから動かないと、横ばいのオファーになりやすいと考えておくべきです。SIerからWeb系への移動で年収がどう変わるかはSIerからWeb系への転職で年収は上がるのかで検証しています。

バックエンドエンジニアから移る場合

サーバーサイド開発の中央値も700万円で、SREと同じです。バックエンドからSREへの移動は、中央値で見れば横移動です。年収の上積みを狙うなら、アプリケーションのコードを読めるという強みを、SLO設計や障害の原因調査（L2〜L3）に直結させて示す必要があります。

注意したいのは、SREとしての実務経験がない状態で応募すると、求人票の下限（600万円前後）付近で提示されやすいことです。現職ですでに700万円を超えている人は、現職の中でSREの業務（SLOの導入、オンコール体制への参加、ポストモーテムの主導）を経験してから移る方が、年収を下げずに済む可能性が高くなります。

年収交渉をエージェントにどこまで任せられるかはエンジニアの年収交渉をエージェントに任せる前にで整理しています。もし転職後に年収が下がってしまった場合の対処はエンジニア転職で年収が下がった時の対処法を参照してください。

SLI-07 / RISK「名ばかりSRE」の求人を年収面で見分ける

集計で見たとおり、「運用保守」「監視業務」が前面に出ているSRE求人は、下限の中央値が504万円と低めでした。職種名がSREでも、実態が従来の運用業務に近い求人では、年収の上限側に行くための経験（L2〜L4）が積めません。応募前に次の点を確認しておくと、入社後に年収が伸び悩むリスクを減らせます。

なお、今回の62件では、受託・技術支援・内製化支援の企業（25件）と自社サービス企業（37件）で、下限・上限の中央値に差はほとんどありませんでした（下限600万円、上限1,000万円前後で同水準）。「支援会社だから低い」とは言えず、見るべきは会社の業態よりその求人で担当する仕事の中身です。

よくある質問

まとめ：SREの年収は「肩書き」ではなく「評価軸のどこまで示せるか」で決まる

• SREの本人申告年収は中央値700万円。サーバーサイド（700万円）やインフラ（680万円）とほぼ同じで、差がつくのはP75・P90の上位層。
• 求人票のレンジは下限600万円・上限1,000万円前後が典型。上限1,000万円以上の求人が多くても、多くの人の着地点は下限寄り。
• 上限を押し上げている要件は、ポストモーテム（+200万円）、マネジメント（+150万円）、SLO・Kubernetes・可観測性（各+100万円）。IaCは92%が要件にしている前提条件。
• オンコール手当の金額は求人票からは読めない。待機手当と出動時の割増を分けて、オファー面談で確認する。
• インフラ・バックエンドからの移行は、中央値で見ると横移動。年収を上げるなら、商流の浅い企業に移るか、L2〜L3の実績を作ってから動く。

参考・出典

福朗

フリーランスAIエンジニア。AIパイプライン開発と技術キャリアについて発信しています。

Zenn