プラットフォームエンジニアの年収相場｜社内基盤の評価軸と企業タイプ差252万円

プラットフォームエンジニア（社内開発者基盤／内製プラットフォーム）の年収は、扱うクラウド製品やツールの知識ではなく、社内の開発者の生産性にどこまで責任を持つかで決まります。基盤を作ること自体ではなく、作った基盤が実際に使われている状態まで持っていけるかが評価の対象になります。

まず、条件を揃えたときにレンジがどう動くかを確認します。

企業タイプで252万円開く

実務6〜9年／東京勤務／スキル中位という条件を固定して、企業タイプだけを変えるとこうなります。

上端のメガベンチャー・外資と下端のSESで 252万円。職種名ではなく、どの構造の会社で働いているかによる差です。

この表の読み方には注意点があります。プラットフォームエンジニアという職種は、専任のチームを置ける組織にしか求人が存在しません。 開発者が数名の会社では、基盤の整備は各チームの片手間の作業として扱われ、独立した職務になりません。そのため実際の募集は表の上側の企業タイプに偏り、下側の行は「同じ仕事をしても年収がこうなる」という比較というより、「そもそも募集が少ない」帯として読むほうが実態に近くなります。

逆に言えば、この職種を目指すことは、職種の選択であると同時に応募先の構造の選択でもあります。企業タイプによる差が何から生まれているかは企業タイプ別のエンジニア年収相場で扱っています。

経験年数別のレンジ

同じ上場・大手／東京／スキル中位で、経験年数だけを動かすとこうなります。

プラットフォームエンジニアの求人は、この表の下のほうの行には基本的に出てきません。社内の開発者を利用者として扱う仕事は、開発者として何に困るかを知っていることが前提になるためです。アプリケーション開発かインフラ運用で数年の実務を経たあとに移る職種であり、未経験から直接目指す経路は現実的ではありません。

一方で、経験年数が長いほど自動的にレンジの上に行くわけでもありません。同じ実務6〜9年でも、スキルスコア30と85では推定の中央値が変わります。

• スキル下位（スコア30）：589〜691万円
• スキル上位（スコア85）：723〜848万円

同じ年数を過ごしても開くこの幅が、次に述べる評価軸の差にあたります。

SRE・クラウドエンジニアとの境界

3つの職種は重なりますが、責任の向き先が違います。SREはサービスの信頼性に、クラウドエンジニアは基盤そのものの設計と運用に、プラットフォームエンジニアは社内の開発者が使う道具の使いやすさに責任を持ちます。

具体的な違いは、障害が起きたときに何を直すかに表れます。SREは落ちたサービスを復旧させ、再発しない仕組みを作ります。プラットフォームエンジニアは、その障害が「基盤の使い方を間違えやすい形になっていたこと」に起因するなら、間違えられない形へ作り替えます。前者は事象への対応、後者は利用者の行動を変える設計です。

ただし、この切り分けが組織の中でそのまま採用されているとは限りません。同じ職種名で募集していても、実態は監視当番の増員である場合もあれば、社内向けの開発チームを一から立ち上げる場合もあります。職種名の定義に寄りかからず、募集の背景を確認してください。信頼性側の責任範囲についてはSRE・インフラエンジニアの年収相場、製品知識と設計の範囲についてはクラウドエンジニアの年収相場で扱っています。

評価軸1：社内の開発者を利用者として扱えるか

この職種で最初に問われるのは、技術力よりも利用者を特定できているかです。基盤の利用者は社内の開発者であり、彼らが今どこで詰まっているかを把握していない状態で作ったものは、作った側の想定した手順でしか動きません。

評価される人は、着手の前に利用者の作業を観察します。新しいサービスを立ち上げるとき何日かかっているか、デプロイのたびに誰に確認を取っているか、といった実際の手数を数えたうえで、どこを削るかを決めます。逆に評価されにくいのは、流行している構成をそのまま持ち込み、移行を各チームに依頼して終わる進め方です。技術の選択は正しくても、利用者の手数が減っていなければ成果になりません。

注意すべき例外もあります。利用者の要望をそのまま実装し続けると、基盤は個別対応の集合になり、維持できなくなります。聞くべきは要望そのものではなく、その裏にある作業の詰まりです。この線引きができるかどうかが、次の軸につながります。

評価軸2：セルフサービスの範囲をどこまで広げたか

次に問われるのは、開発者が自分で完結できる範囲をどこまで広げたかです。依頼を受けて代わりに作業する運用は、件数が増えるほどチームの負荷が増え、開発者側の待ち時間も消えません。

分かりやすい指標は、基盤チームへの依頼の件数です。環境の払い出し、権限の追加、設定の変更といった定型の依頼が、申請から自動実行される形に置き換わっているかを見ます。件数が減っていれば、同じ人数でより多くの開発者を支えられます。この「支えられる開発者の数」が、そのままチームの価値として説明できる数字になります。

ただし、すべてをセルフサービスにできるわけではありません。本番データへのアクセスや権限の昇格のように、意図的に人の承認を残す領域があります。この区別を説明できないまま自動化の範囲を広げると、監査の指摘を受けて元に戻ることになります。何を自動化し、何を承認のまま残したかを、理由と一緒に言えることが求められます。

評価軸3：標準と自由度のバランスを設計できるか

3つ目は、標準を決める仕事です。基盤の価値は、各チームが別々にやっていたことを揃えることで生まれます。一方で、揃えすぎると各チームの事情に合わなくなり、基盤を迂回する動きが出ます。

実務では、必ず通す部分と、選ばせる部分を分けます。 たとえば、本番環境への変更経路と権限の扱いは全社で1つに揃え、その中で使うフレームワークやテストの構成はチームに任せる、といった切り分けです。禁止で縛るのではなく、標準の経路を通るほうが楽になる状態を作れているかが評価されます。

この軸は、技術より合意形成の比重が大きくなります。既存のやり方を変えてもらう以上、各チームの納得が必要で、その説明を他人任せにできません。求人票に「全社標準の策定」と書かれていても、実際に標準を決める権限がその部署にあるとは限らない点には注意してください。権限のない標準化は、ほとんど進みません。

評価軸4：コストと信頼性に数字で責任を持つか

4つ目は、基盤のコストと信頼性を数字で持てるかです。開発者基盤は全社の土台になるため、止まったときの影響範囲も、かかる費用も大きくなります。ここに責任を持てる人は、レンジの上側で評価されます。

具体的には、基盤自体の可用性をどの水準で維持するか、変更を入れる時間帯をどう決めるか、費用が増えたときにどの単位で内訳を出せるかといった設計です。費用を各チームに配賦できる形にしておくと、使う側にも判断材料が渡り、削減の議論が基盤チームだけの持ち出しになりません。

一方、数字を持つことと、数字を守るために止めることは違います。信頼性を理由に変更の頻度を下げると、基盤の改善そのものが止まります。どこまでの失敗を許容し、どこから止めるかを事前に決めておく必要があり、この判断を任されている範囲が、そのまま等級の高さに対応します。等級と年収の関係は等級・グレード制度の読み方で扱っています。

評価軸5：使われる状態まで持っていけるか

最後の軸は、導入を進める力です。作った基盤が使われていなければ、技術的な完成度は評価の対象になりません。この職種で最も差が出るのがここです。

進め方には型があります。最初から全社に展開せず、困っている度合いが大きいチームを1つ選んで一緒に移行し、そこで出た問題を直してから次に広げます。移行の作業を相手チームの工数として押し付けず、初期の数チームは自分たちで手を動かすことも多くなります。移行できた数と、移行後に戻らなかった事実が、次の提案を通す根拠になります。

ここでの失敗例は、社内広報だけで導入を進めようとすることです。資料と説明会を重ねても、移行の手間が残っているかぎり各チームは動きません。使われない基盤は、維持コストだけが残り、いずれ廃止の対象になります。廃止された基盤の担当経験は、転職市場でも説明が難しくなります。

求人が成立する組織の条件

この職種の求人は、どの会社にも出るわけではありません。専任のチームを置く判断が成り立つのは、社内の開発者が一定数を超え、各チームが同じ作業を重複して行っている状態が見えているときです。

判断の材料になるのは、開発組織の人数と、プロダクトの数です。1つのプロダクトを1チームで作っている会社では、基盤を切り出しても揃える相手がいません。逆に、複数のプロダクトが別々の方法でデプロイしている会社では、揃えるだけで効果が出ます。応募先を選ぶときは、この条件が満たされているかを先に確認してください。

なお、人材の不足という文脈だけで応募先を選ぶのは危険です。79万人が不足するという推計はありますが、これはIT人材全体の話であり、特定の職種の求人が自社にあることを保証しません。求人倍率も同様で、情報処理・通信技術者全体では1.39倍です。

求人票で確認する4項目

職種名と製品名の羅列からは、実態がほとんど読めません。確認するのは次の4点です。

1. 対象となる開発者の人数 — 支える相手が何人かで、仕事の性質が変わる
2. 基盤の利用が任意か必須か — 任意の場合、導入を進める力がそのまま成果になる
3. 標準を決める権限の所在 — 別部署にある場合、実態は運用代行に近づく
4. オンコールの有無と頻度 — 全社の土台を持つため、対象範囲が広くなりやすい

このうち3番目が最も見落とされます。募集要項に全社標準という言葉があっても、決定権が情報システム部門や別の技術委員会にある場合、提案を通す工数のほうが大きくなります。面談では「直近で標準を変更した例」を聞くと、実態が分かります。

求人票に書かれた年収レンジの読み方そのものは求人票の年収レンジを読む確認点で扱っています。レンジの上限は、募集している等級の上限であって、入社時の提示額ではありません。

移る前に揃えておく実績

バックエンドやSREからこの職種へ移る場合、選考で問われるのは基盤の知識より、他チームを動かした経験です。現職で作れる実績には次のようなものがあります。

• 自チームのCI/CDの待ち時間を計測し、短縮した
• 環境構築の手順書を、実行できる形に置き換えた
• 他チームにも使われるようになった社内ツールを作った
• 権限や秘密情報の扱いを、レビューできる形に整理した

いずれも、規模の大きさより「他人が使う状態にしたか」が要点です。自分専用の改善は、面接で説明しても評価の材料になりにくくなります。逆に、社内で数名にでも使われているものがあれば、利用者からの要望をどう扱ったかまで話せます。

職務経歴書では、導入した技術の名前ではなく、変わった作業を先に書きます。「Kubernetesを導入した」ではなく「新規サービスの立ち上げに要していた作業を、テンプレートの適用で完結する形にした」と書くほうが、何に責任を持っていたかが伝わります。書き分けの型は職務経歴書で提示年収が変わる理由にまとめています。

転職で上がる人と上がらない人

実績データを見ると、転職で年収が上がるのは全員ではありません。dodaエージェント経由で2025年9月に転職が決定した人のうち、年収が増加したのは60.4%でした。増加した人の平均増加額は73.1万円です。

この分岐は、職種の選択だけでは決まりません。プラットフォームエンジニアという職種名で応募しても、応募先の企業タイプと、任される意思決定の範囲が変わらなければ、レンジは動きません。上がっている人は、支える開発者の数が増えるか、標準を決める権限が広がるか、そのどちらかを伴う移り方をしています。

なお、社内で同じ職種に移る場合は、年収の動き方が違います。社内異動では等級の枠が先にあり、昇給は評価サイクルの中で処理されます。情報通信業の賃金改定率は3.9%で、これを大きく超える増額は昇格を伴わないかぎり起きにくくなります。

年収が伸びにくくなる状態

この職種には、年数を重ねても評価が伸びにくくなる典型的な状態があります。1つ目は、依頼を受けて代行する運用から抜け出せていない場合です。件数をこなしても、支えられる開発者の数が増えないため、価値の説明が難しくなります。

2つ目は、基盤の技術的な新しさを追い、利用者が置き去りになっている場合です。移行のたびに各チームの作業が発生し、利用者からの信頼が下がります。新しい構成を入れること自体ではなく、入れ替えの負担を誰が引き受けたかが見られます。

3つ目は、社内でしか通じない独自の仕組みに深く入り込んでいる場合です。社内では価値があっても、転職市場では説明の相手が変わります。独自の部分と、一般的な技術で説明できる部分を分けて話せる状態にしておくと、市場価値の目減りを抑えられます。

面談で確認しておくこと

条件の確認は、金額より先に役割の範囲から入るほうが噛み合います。誰の困りごとを解くチームなのか、成果をどの指標で見ているのか、直近で導入が進んだ例と止まった例は何か、といった質問です。答えが具体的であるほど、入社後の期待値のずれが減ります。

オンコールの条件も、この職種では確認の優先度が高くなります。全社の土台を持つため、対象となる範囲が広くなりやすく、手当の有無や当番の頻度が実質的な時給に効きます。手当の扱いはオンコール・障害対応の当番手当で扱っています。

年収の妥当性を判断するときは、平均値との比較を根拠にしないでください。ITエンジニア全体の平均469万円には未経験も10年以上も含まれており、特定の職種と等級を説明する数字にはなりません。比較するのは、経験年数・企業タイプ・勤務地を揃えたレンジです。

まとめ

• 評価されるのは製品知識ではなく、社内の開発者の生産性にどこまで責任を持つか
• 実務6〜9年・東京・スキル中位でも、企業タイプだけで252万円の差がある
• 求人票では対象となる開発者の人数、利用が必須か、標準を決める権限、オンコールの4点を確認する