Platform Engineeringとは｜SRE・DevOpsとの違い

開発者を顧客にする

アプリケーションを作るには、コードだけでなく、テスト環境、認証、配信、監視などが必要です。Platform Engineeringが扱うのは、そうした共通の能力を開発者へどう届けるかです。利用者は社内にいても、使いにくさや困りごとを聞き、改善を続ける点は顧客向けのプロダクトと変わりません。

CNCF（Cloud Native Computing Foundation）の成熟度モデルは、対象を技術だけに限定せず、人、プロセス、方針、事業上の成果まで含めています。「共通ツールを買った」「基盤チームを改名した」だけでは、取り組みの中身は決まりません。CNCFの成熟度モデル

たとえば検証環境の作成を頼むたびに、開発者が担当者を探して要件を説明しているとします。自動化する対象はサーバー作成だけではありません。申請できる人、必要な入力、作成後の接続方法、失敗時の問い合わせ先までそろって、はじめてひとつの使える機能になります。以下は、その違いを考える編集部の整理です。

基盤側の作業だけを見る	開発者が完了したい仕事を見る
サーバーを作成する	テスト用のURLへアクセスできる
アカウントを発行する	必要な範囲でログインして作業できる
ログを保存する	失敗した処理のログへたどり着ける
手順書を公開する	はじめての人が手順を最後まで実行できる

この見方では、チケットを処理した件数と、利用者の仕事が終わった件数は別です。基盤を提供する側の「完了」が、使う側の「開始できる」と一致しているか。最初に確認したいのは、その境界です。

DevOps・SREとの違い

DevOpsは開発と運用を分断せず、人・プロセス・技術を通じて協働する考え方です。特定の製品名や部署名ではなく、計画から開発、配信、運用までをつなぎます。MicrosoftのDevOps解説

SRE（Site Reliability Engineering）は、ソフトウェア工学を運用へ適用する実践です。Googleの説明では、手作業を仕組みで置き換え、サービスの信頼性と変更の速度を両立させることを扱います。GoogleのSRE解説

Platform Engineeringは、そうした協働や運用の知見を、社内の開発者が使う共通の仕組みへまとめます。次の表は公式の職務規定ではなく、各資料をもとに目的と責任を見分けるための編集部による比較です。指標と失敗例は、導入を検討する際の例示です。

比較軸	DevOps	SRE	Platform Engineering
組織の見方	開発・運用などの協働	信頼性を継続的に扱う実践・チーム	社内向けプロダクトの提供・運営
中心の目的	開発から運用までの分断を減らす	信頼性と変更速度を両立する	開発者の共通作業を使いやすくする
主な受益者	プロダクトに関わる人と顧客	サービスの利用者と開発チーム	社内の開発チーム
成果物の例	継続的な配信・改善の流れ	信頼性の目標、運用自動化	環境作成機能、テンプレート、利用ガイド
指標の例	変更を届ける時間や変更後の不具合	信頼性の目標達成、反復作業の負担	待ち時間、利用継続、利用者の評価
失敗の例	ツール導入後も責任を押し付け合う	障害対応だけで改善の時間がなくなる	基盤は完成したが使われない

3つは排他的な選択肢ではありません。同じ組織で、DevOpsの協働を進めながら、SREが信頼性を扱い、プラットフォームチームが共通の環境を提供できます。少人数なら同じ人が役割を兼ねる場合もあります。肩書きを増やすより、何を誰が継続して引き受けるかを決めるほうが、責任の抜けを見つけやすくなります。

IDPは入口だけではない

Internal Developer Platform（IDP）は、社内開発者のための基盤を指します。Platform Engineeringが設計・提供・改善の取り組みであるのに対し、IDPはそこで提供する仕組みです。Microsoftは、本番までの推奨経路を段階的に整える考え方を説明しています。MicrosoftのPlatform Engineering解説

ポータル画面は、その仕組みへの入口のひとつです。画面があっても、裏側で毎回担当者が手作業をしているなら、申請の窓口が変わっただけかもしれません。コマンドを入力するCLIや、プログラムから操作する窓口であるAPIを使うほうが自然な利用者もいます。

用語	指すもの	混同しやすい点
Platform Engineering	基盤を設計・運営する取り組み	ツールひとつの導入ではない
IDP	社内開発者へ提供する仕組み	ポータル画面だけではない
Golden Path	推奨され、支援される開発の進め方	すべての用途に唯一の手順を強制する意味ではない
セルフサービス	利用者自身が必要な能力を取得できること	承認や権限をなくす意味ではない

CNCFの白書は、テンプレートや説明文を含む推奨経路、セルフサービス、利用者に合わせたインターフェースを取り上げています。また、基盤の裏側をすべて自作する必要はなく、既存の社内サービスやマネージドサービスを組み合わせられます。CNCF Platforms White Paper

ここから導ける実務上の判断は、入口を作る前に、そこから何ができるかを決めることです。「作成ボタンを押せる」だけでなく、作成状況を知る、失敗理由を確認する、不要になった環境を削除する、といった一連の操作を検討します。

3チームで考える設計例

ここでは架空のA・B・Cチームを使います。実在企業への取材や、導入効果の実測ではありません。3チームとも新機能の検証環境を使い、その都度、共通基盤の担当者へ作成を依頼していると仮定します。

最初に標準化するのは、3チームのアプリケーション全体ではなく、「期限付きの検証環境を作る」というひとつの操作です。業務の違いを残しながら、同じ説明を繰り返している部分を取り出します。

場面	申請型の例	セルフサービス型の設計例
Aチームが環境を作る	担当者へ構成を説明する	許可された構成と利用期限を選ぶ
Bチームが進捗を知る	チャットで確認する	作成中・完了・失敗を確認する
Cチームが利用を終える	削除を依頼する	期限終了や明示操作で削除する
基盤担当が支援する	3者の同じ操作を個別に代行する	共通機能の不具合と例外を扱う

ただし、入力が同じなら何でも自動化してよいわけではありません。この設計例では、検証用のデータと、本番の顧客データを使う環境を分けます。後者の権限や承認まで、前者と同じ流れへ無条件に載せないためです。

責任分担も決めます。たとえばアプリケーションの不具合は開発チーム、共通の環境作成機能の不具合は基盤担当、権限の例外判断は組織で決めた承認者、という具合です。実際の分担は各社で決める必要がありますが、「何かあれば基盤担当へ」だけでは問い合わせが再び一か所へ集まります。

図：共通機能を使う側と、保守する側の関係。編集部作成の概念図であり、実在組織の構成ではありません。

この例からまず確認できるのは、導入後の速さではなく、作業と責任の変化です。自動化にかかる保守時間や、例外への対応時間も残ります。「申請が減った分だけ工数が減る」とは置かず、試行後に差を測ります。

小さく始め、待ち時間を測る

何人になったら専任チームを作るか、という人数だけの基準はこの記事では置きません。CNCFの成熟度モデルも、最上位へ到達すること自体を目標とせず、必要な投資と自組織への価値を検討するよう説明しています。成熟度モデルの使い方

先ほどの設計例を試すなら、編集部では次の順に確認する方法を提案します。全社導入の標準手順ではなく、効果を判断できる小さな試行にするための手順です。

1. 3チームの担当者に、最近の環境作成を最初から再現してもらう。
2. 入力のやり直し、担当者待ち、接続方法の確認を分けて記録する。
3. 頻出する構成をひとつ選び、既存サービスで提供できるか調べる。
4. 試行するチームと、利用期限・失敗時の連絡先を決める。
5. 同じ種類の依頼について、導入前後の待ち時間と作業負担を比べる。

確かめたいこと	この試行での測り方	数字を読む際の注意
利用者が早く仕事を始められるか	依頼開始から接続確認までの経過時間	サーバー作成時間だけを測らない
使い続けられるか	対象チームのうち再利用したチーム数	利用対象外のチームを分母に入れない
問い合わせが移動しただけではないか	操作の質問と不具合の相談を分ける	件数減だけで満足したと推定しない
基盤側に負担が偏っていないか	保守、例外対応、改善の時間を分ける	初期構築費を無視しない

比較期間に依頼件数や構成が変われば、所要時間の差をすべて基盤の効果とは呼べません。件数、成功・失敗、対象の構成も残します。自動化後に入力のやり直しが増えたなら、利用者の理解より画面の都合を優先していないか、確認する材料になります。

一方、依頼がほとんど繰り返されず、毎回用途も違うなら、専用の仕組みより手順の整理が先かもしれません。導入しない判断も含め、消したい待ち時間がどこにあるのかを説明できる状態から始めます。

共通の仕組みを作った後、誰が変更し、例外をどう受け付けるかを決める論点は、デザインシステムの運用にもつながります。対象は異なりますが、作成と継続運用を分けて考える際の参考になります。

よくある質問

DevOpsは不要になるか

不要にはなりません。Platform Engineeringでも、開発者と運用側が要件や責任を共有する協働は必要です。共通基盤があれば意思疎通を省ける、という関係ではありません。

SREチームが兼任できるか

兼任する設計は可能ですが、担当サービスの信頼性を扱う時間と、社内利用者向けの機能を改善する時間を分けて考える必要があります。既存のSREへ依頼を足すだけでは、責任範囲と優先順位が曖昧になります。

Kubernetesは必須か

必須条件ではありません。Platform Engineeringは特定の実行基盤ではなく、開発者へ共通の能力を提供する取り組みです。使っている環境と、解決したい作業に応じて構成を決めます。

ポータルを先に作るのか

必ずしも先ではありません。利用者がどこで困るかを調べ、提供する機能を定めてから入口を選びます。既存の開発手順に組み込むほうが使いやすい場合もあります。

最初に何を決めるのか

誰が、どの作業で、何を待っているかです。その作業の開始と完了を定義すると、対象範囲、必要な機能、導入後に測る指標をそろえやすくなります。

まとめ

• Platform Engineeringは、社内開発者へ共通の能力を届け、改善する取り組みです。基盤の完成ではなく、利用者が仕事を進められるかで考えます。
• DevOps・SREとは中心に置く課題が異なり、同じ組織で併用できます。名称より、責任と成果物を分けると役割が見えます。
• 導入の入口は、繰り返されるひとつの作業です。待ち時間と保守負担を一緒に測れば、広げるか、範囲を絞るかを判断できます。

出典・参考

• CNCF Platforms White Paper
• CNCF Platform Engineering Maturity Model
• Microsoft Learn: What is platform engineering?
• Microsoft Learn: What is DevOps?
• Google: Site Reliability Engineering, Introduction

資料確認日：2026年9月15日。比較表・3チームの設計例・試行時の測定表は、資料を踏まえた編集部の整理です。実在組織の運用実績や導入効果を示すものではありません。