プラットフォームエンジニアとは｜仕事内容・年収・SRE/DevOpsとの違い

プラットフォームエンジニアとは何か

結論から言うと、プラットフォームエンジニアは「開発者を顧客とする社内SaaSの担当者」に近い立ち位置です。 インフラ運用の一部を担うだけの職種ではありません。

背景にあるのはDevOps疲れとチーム認知負荷

2010年代を通じてDevOpsの考え方が広がった結果、多くの現場では「アプリチームがCI/CDもインフラも監視も見る」体制が採用されました。しかしKubernetes・マイクロサービス・オブザーバビリティ・セキュリティ要件が積み重なり、アプリ開発者が扱うべき技術範囲が肥大化。書籍『Team Topologies』が指摘したチームの認知負荷（Cognitive Load）の限界が現場に来た、というのがコンセンサスになりつつあります。

この負荷を吸収する内部プロダクトを提供する専任チーム、その職能名がプラットフォームエンジニアです。背景要因はDevOps疲れだけでなく、クラウドネイティブ化・組織拡大・セルフサービス化需要など複合的で、Platform Engineeringコミュニティや先進企業の実践で繰り返し論点になっています。参考：Team Topologies 公式サイト。

Platform Engineeringの位置づけ

Platform Engineeringは、CNCF（Cloud Native Computing Foundation）やplatformengineering.orgなどのコミュニティで用語が整備されてきた比較的新しい概念です。中心思想はシンプルで、アプリチームがビジネスロジックに集中できるように「golden path（黄金の道）」を提供するというもの。

golden pathとは、たとえば「マイクロサービスを新規に立ち上げるとき、テンプレートを選んでCLIを叩けば、Kubernetes上へのデプロイ・監視・アラート・シークレット管理まで一式が揃った状態で始められる」といった、社内標準の開発体験を指します。

プラットフォームエンジニアと関連職種の関係

• インフラ寄りの土台はインフラエンジニアやクラウドエンジニアが担当することが多い

• 信頼性の指標を握るのがSRE

• 開発と運用の間のプロセスを整えるのがDevOpsエンジニア

• そのうえで「開発者向けの内部プロダクト」を作るのがプラットフォームエンジニア

役割が重なる部分は当然ありますが、成果指標（KPI）と対象顧客が違います。次章の比較表で整理します。

ミニFAQ

Q. プラットフォームエンジニアリングは一時的なバズワードですか？

A. 用語の定着は今後に依存しますが、DevOpsが広まる過程で発生した「開発者への負荷集中」を分業やセルフサービス化で解こうとする動きは、今後も続く可能性が高いと見られています。名前が変わっても、開発者体験を専任で守るチームは残る可能性が高いです。

Q. SREをやっていれば同じ？

A. 重なりは大きいですが目的が違います。SREは信頼性（SLO/エラーバジェット）を管理する役割、プラットフォームエンジニアは信頼性を含む開発者体験を製品として提供する役割です。同じ人が兼務する組織もあります。

プラットフォームエンジニアの仕事内容

結論、日々の業務は「IDPというプロダクトを開発・運用すること」に集約されます。 具体的な作業は以下のレイヤーに分かれます。

Internal Developer Platform（IDP）の設計・構築

IDPは、社内開発者に対して「共通基盤への統一されたインターフェース」を提供する仕組みです。代表的な構成要素は次のとおりです。

このうちどこまで自作するか、どこまでマネージドサービスに寄せるかを設計するのが、プラットフォームエンジニアの腕の見せどころです。参考：Backstage 公式サイト。

セルフサービス化の推進

IDPの価値は「アプリチームがチケットを起票して待つ時間を大幅に減らせるか」で決まります。 具体的には次のような依頼を、事前に用意したテンプレート・APIで裁けるようにします。

• 新しいマイクロサービスの雛形作成（言語別テンプレート、CI設定、権限、監視まで一式）

• ステージング環境の複製

• 本番向けのデータベース払い出し（承認フロー付き）

• シークレット・APIキーの発行と更新

• 新しいクラスタ／リージョンへの展開

セルフサービス化が進むと、アプリチームはビジネスロジックに時間を使えるようになります。SRE寄りの信頼性指標（可用性・レイテンシ）だけでなく、リードタイム・デプロイ頻度といったDORA指標にも直接効いてきます。

プラットフォームのプロダクト運営

ここが「単なる基盤担当」との一番の違いです。プラットフォームエンジニアは社内開発者を顧客とみなし、要望収集・ロードマップ策定・ドキュメント整備・オンコール対応まで一貫して行うのが基本です。

• 開発者向けのアンケート・NPS計測

• サービスカタログとテンプレートのバージョン管理

• 破壊的変更のリリースノート

• 「移行のしかた」を含むランブック整備

• SREから運用移管された共通基盤のオンコール

プロダクトマネジメント寄りの動き方が求められるため、エンジニアリングマネージャー(EM)やテックリードと協働する場面も多くなります。

ミニFAQ

Q. 「golden path」は必ず用意する？

A. 用意する組織のほうが多いですが、必須ではありません。開発チーム数が10未満の小規模組織では、テンプレートよりドキュメントで足りるケースもあります。組織規模に応じて投資判断する領域です。

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

先に結論、目的・KPI・顧客がそれぞれ異なります。 求人票のタイトルだけで判断せず、業務内容とKPIで見分けるのが実務的です。

目的とKPIの違い

「開発者を顧客とするか、エンドユーザーを顧客とするか」で線を引くと整理しやすくなります。

対象範囲の違い

同じKubernetesクラスタを見ていても、視点が違います。

• SRE：Podの安定稼働、SLI/SLO、障害対応、ポストモーテム

• プラットフォームエンジニア：クラスタを「開発者にどう見せるか」（テンプレート、CLI、権限、ダッシュボード）

• インフラエンジニア：ネットワーク・ノード・ストレージなど土台のリソース確保

• DevOpsエンジニア：チームプロセスとパイプラインの最適化

職種比較のケース例

• 「本番でSLO違反が続いている」→ SREの領域

• 「新しいマイクロサービス立ち上げが週次でボトルネックになっている」→ プラットフォームエンジニアの領域

• 「AWSのNAT Gatewayコストが跳ねている」→ インフラ/クラウドエンジニアの領域

• 「CIジョブが不安定で開発者がリトライを繰り返している」→ DevOps／プラットフォームエンジニアの領域

役割の兼務も一般的です。組織規模が数十人〜数百人の会社では、SREとプラットフォームエンジニアを同じチームが担当し、成熟度に応じて分割する流れが目立ちます。

必要なスキルセット

土台はSRE・DevOpsと共通ですが、プラットフォームエンジニア特有の要素として「プロダクト思考」と「API設計」が上乗せされます。

コンテナ・オーケストレーション

現代のIDPはKubernetesが中核になるケースが多く、以下は最低ラインの理解が必要です。

• Kubernetes：Deployment、Service、Ingress、Namespace、RBAC、Operatorパターン

• Docker：マルチステージビルド、イメージのサイズ最適化、脆弱性スキャン

• サービスメッシュ：IstioなどによるmTLS、トラフィック分割

IaC・構成管理

IDPは「同じ環境を何度でも再現できる」ことが前提です。

• Terraform（HCL）とモジュール設計

• Terraform Cloud／Atlantisなどによるレビュー付き適用フロー

• AnsibleやChefでのプロビジョニング

CI/CDと自動化

• GitHub Actions、GitLab CI、CircleCI、Jenkinsなど主要ツールの経験

• ArgoCDを代表とするGitOpsの実装

• Renovate等による依存更新の自動化

可観測性（Observability）

信頼性を握るのはSREでも、その基盤を用意するのはプラットフォームエンジニアであることが多いです。

• OpenTelemetryによるログ・メトリクス・トレースの標準化

• Grafana、Prometheus、Lokiなどのスタック運用

• SLI/SLOダッシュボードのテンプレート提供

プロダクト思考・API設計

• 社内ユーザー（開発者）のヒアリング、要望のプライオリタイズ

• CLI・Web UI・APIをどう組み合わせて提供するかの設計

• RESTやgRPCによる社内向けAPI設計

• ドキュメント整備（Backstage TechDocs等）

ソフトスキル

• 社内SaaSとしての「利用者コミュニケーション」

• 破壊的変更の合意形成

• ステークホルダー調整（EM、テックリード、セキュリティチーム、法務）

プロダクトを内向きに提供するだけで、ソフトスキルの要求水準が上がります。 純粋な技術力と同等かそれ以上に、対話・調整の力が問われます。

年収相場とキャリアパス

先に結論、2026年7月時点で確認できる公開求人・公開案件では、会社員700〜1,300万円台の求人提示例、フリーランス月75〜130万円前後の案件が目立ちます。ただしいずれも母集団が限定的なので目安として扱ってください。

会社員の年収レンジ

• 主要な求人サイトの公開掲載（doda、ビズリーチ、Findy等）で「Platform Engineer」「Platform Engineering」「SRE／DevOps兼務を含む関連求人」の掲載条件を確認すると、想定年収の下限は600〜700万円、上限は1,200〜1,500万円の提示が目立ちます（2026年7月時点）

• 外資系クラウド事業者、SaaS企業、メガベンチャー等が高い水準を提示するケースが多く、事業会社の社内IT部門よりも高めに出る傾向があります

• 数値の母集団はあくまで求人サイトの掲載条件であり、実際の入社年収と一致するとは限りません

フリーランス単価の目安

• 2026年7月時点で、主要フリーランスエージェントの公開案件（週3〜5日・業務委託・首都圏中心）を見る限り、Platform Engineer／SRE兼務案件は月75〜130万円の提示が目立ちます

• Kubernetes・IaCの実務3年以上、かつ英語ドキュメントを苦にしないシニア層向けの一部案件では、月120〜160万円の提示例もあります

• 高単価が出るケースにはマルチクラウド運用経験、大規模マイクロサービスでのIDP構築経験、CNCFプロジェクトへのコントリビュート経験などの条件を満たす人物像が想定されており、経歴・スキル・経験年数の裏付けが求められる傾向があります

キャリアパス

主流のキャリア分岐は次のとおりです。

• 技術深耕：シニア・プラットフォームエンジニア → プリンシパルエンジニア／スタッフエンジニア

• マネジメント：Platform Team Lead → EM／プラットフォーム統括

• 横スライド：SRE、テックリード、クラウドアーキテクト

• 独立：フリーランスとしてIDP構築支援、複数社のプラットフォーム顧問

フリーランス案件の実態と勝ち筋

結論、「Platform Engineer」というタイトルで表に出ている案件はまだ少なく、SRE案件・DevOps案件・クラウド基盤刷新案件として募集されているケースが実務的な主戦場です。

現状の案件動向

• 求人票のタイトルとしては「SRE」「DevOpsエンジニア」「クラウド基盤エンジニア」が引き続き多数

• ただし業務内容の欄には「Backstage導入」「開発者向けCLIの整備」「テンプレートリポジトリの整理」など、プラットフォームエンジニアリング相当のタスクが明記されているケースが増えつつあります

• 公開案件を見る限り、タイトルではなく業務内容で見分けにいくのが実務的です

参画しやすい入り口

• Kubernetes運用のスケール支援（マルチテナント化、マルチクラスタ化）

• CI/CDパイプラインの標準化と横展開

• 監視基盤の共通化（OpenTelemetryへの移行、Grafana統合）

• IaCモジュールの棚卸しと共通ライブラリ化

• Backstage／Port等の開発者ポータル導入PoC

高単価に届く条件

• 直近3年以内にプロダクトとしての社内基盤運用の経験がある

• 100サービス超のマイクロサービス環境での運用実績がある

• SLO運用・ポストモーテム文化を導入した経験がある

• CI/CDと権限管理をコードで統一運用した経験がある

• 英語での技術ドキュメント執筆・レビューが可能

フリコンでも、SRE／DevOps／プラットフォーム関連の非公開求人を含めて相談できます。単価交渉は「プロダクトとしての基盤運用経験の有無」が効く領域なので、職務経歴書ではKPI（DORA指標の改善実績、削減した開発者オンコール件数等）を数字で示すと通りやすくなります。

プラットフォームエンジニアになるためのロードマップ

結論、いきなり狙うより「隣接領域を1〜2年経て移行」が現実的です。

すでにインフラ／SRE経験がある場合

1. Kubernetes運用経験に加えて、マルチテナント／権限設計の視点を持つ

2. IaCの共通モジュール化と、開発者向けドキュメント整備を経験する

3. 社内で使うCLI・ポータル（Backstage等）の導入PoCを主導してみる

4. DORA指標を実際に計測し、改善提案を出す

開発者出身の場合

1. アプリ側での運用経験（オンコール、SLO運用、CIの改善など）を積む

2. Docker・Kubernetesの実務経験を1年以上作る

3. TerraformなどIaCを触り、レビュー経験を得る

4. Platform Engineering系のカンファレンス（PlatformCon、KubeCon等）で最新の設計思想を追う

学習リソースの目安

• 書籍『Team Topologies』（Manuel Pais、Matthew Skelton著）

• CNCFの技術ラダー（CNCF Landscape）

• platformengineering.orgのホワイトペーパー

• Puppet／DORA／Google Cloudが公表するState of DevOps Report

実践チェックリスト

このセクションは、実務で求められやすい要件を自己点検する目安として使えます。

• ☐

  Kubernetesクラスタを本番運用で1年以上見ている

• ☐

  Terraformでモジュールを設計・共有した経験がある

• ☐

  CI/CDパイプラインを複数チーム向けに標準化した経験がある

• ☐

  SLO／エラーバジェット運用に触ったことがある

• ☐

  Backstage／Port／Humanitecなど開発者ポータルを触ったことがある

• ☐

  社内向けドキュメントを継続的に運用したことがある

• ☐

  破壊的変更の移行計画を立てて、実施した経験がある

• ☐

  マルチクラウドまたはマルチリージョンの運用経験がある

• ☐

  監視スタック（Prometheus、Grafana、OpenTelemetry）の設計経験がある

• ☐

  開発者アンケート等でフィードバックを回収した経験がある

6つ以上該当していれば、関連案件に応募を検討しやすい実務経験が揃っている可能性があります。

まとめ

プラットフォームエンジニアは「開発者向けの社内SaaS」を運営する新興ロールです。 SREやDevOpsと重なる部分は多いものの、KPIと顧客がずれるため、キャリア設計上は別トラックとして整理するのが実務的です。

要点を整理します。

• 中核業務はIDP（Internal Developer Platform）の構築とプロダクト運営で、単なるインフラ担当ではない

• SRE・DevOps・インフラエンジニアとKPIと顧客が違うため、同じKubernetesを触っていても視点が別

• 求人サイトの掲載条件では会社員700〜1,300万円台、フリーランス案件は月85〜130万円前後の提示が目立つ（母集団は公開案件）

• 独立初年度から狙うのではなく、隣接領域（SRE／DevOps／クラウド）を1〜2年経てから移行するのが現実的

• 案件はまだ「SRE」「クラウド基盤エンジニア」のタイトルで募集される場合が多く、業務内容で見分けにいくのが実務的

次のステップとしては、SREやDevOpsエンジニアの職種記事もあわせて確認し、自分の現在地から最短でPlatform Engineer相当の案件に届くルートを設計してみてください。フリコンでは、SRE／DevOps／プラットフォーム関連の非公開案件を含めた提案が可能です。単価交渉に必要な材料整理も一緒に進められます。

参照：Team Topologies / platformengineering.org / Backstage / State of DevOps Report