公開2026.06.17更新2026.10.19 開発

Platform Engineering（プラットフォームエンジニアリング）とは？CNCF成熟度モデルとBackstageで始める導入手順

Platform Engineering（プラットフォームエンジニアリング）は、インフラ・CI/CD・監視・権限といった開発の下回りを、社内の専任チームが「開発者向けの製品」として提供する取り組みです。この記事では、CNCFとDORAの定義、DevOps・SREとの違い、CNCFの成熟度モデル（4段階×5観点）、Backstageでゴールデンパスを作る最小構成のYAML、Gartner予測とHype Cycle 2026の読み方、DORAが挙げる失敗パターンまでを、一次情報に沿って整理します（2026年9月時点）。

まとめ：Platform Engineeringの定義・成熟度・始め方の要点

定義：CNCFは、プラットフォームを「利用者のニーズに合わせて定義・提示される、機能の統合されたコレクション」と定義しています。対象の利用者は社外の顧客ではなく、社内の開発チームです。
DevOps・SREとの関係：DevOpsは開発と運用をつなぐ文化と実践、SREは本番の信頼性、Platform Engineeringはそれらを各チームが自力で回せるようにする共通基盤の提供を担います。置き換えではなく分担です。
成熟度：CNCFの成熟度モデルは、Provisional（暫定）→Operationalized（運用化）→Scalable（拡張可能）→Optimizing（最適化）の4段階を、投資・採用・インターフェース・運用・測定の5観点で見ます。観点ごとに段階が違ってかまいません。
始め方：DORAは、全部入りの基盤を一度に作らず、最も頻度の高い作業のゴールデンパス1本から「最小限の実用的なプラットフォーム」を作るよう勧めています。
注意点：DORAの2024年調査では、内部開発者プラットフォームは生産性を上げる一方、管理を誤ると変更のスループットと安定性を下げうると報告されています。導入後はFour Keysと開発者満足度の両方を測ります。

以下、定義から順に根拠と手順を説明します。

Platform Engineeringの定義と、DevOps・SREとの役割分担

CNCFとDORAによる定義：社内開発者向けの「製品」としての基盤

CNCF（Cloud Native Computing Foundation）のPlatforms White Paperは、クラウドネイティブのプラットフォームを「an integrated collection of capabilities defined and presented according to the needs of the platform’s users」と定義しています。DBの払い出し、デプロイ、監視、シークレット管理のような機能を、利用者である開発者の使い方に合わせて一つの窓口にまとめたもの、という意味です。

Google CloudのDevOps研究チームであるDORAも、Platform Engineeringを「社会的な側面と技術的な側面の交点に取り組む社会技術的な分野」と位置づけ、その成果物を「Internal Developer Platform（内部開発者プラットフォーム、IDP）」と呼んでいます。両者に共通するのは、プラットフォームを「インフラのチケット処理」ではなく「開発者を顧客とする社内製品」として扱う点です。

DevOps・SRE・Platform Engineeringの守備範囲の違い

三者は目的と成果物で分けると混同しません。

観点	DevOps	SRE	Platform Engineering
主な目的	開発と運用の分断解消	本番サービスの信頼性	開発者の認知負荷の削減
主な対象	組織の文化・プロセス	本番システム	社内の開発チーム
代表的な指標	Four Keys	SLO・エラーバジェット	利用率・満足度・Four Keys
主な成果物	CI/CD・運用の慣行	SLO設計・障害対応	IDP・ゴールデンパス

DevOpsが「作った人が運用まで責任を持つ」ことを広めた結果、各チームがKubernetes、クラウドのネットワーク、セキュリティポリシーまで自前で抱える状態が生まれました。DORAはこの複雑さを開発者から基盤側へ移すことを「shift down」と呼び、Platform Engineeringの主目的に置いています。DevOpsそのものの実践はDevOpsの実践・ツール・導入判断を実装視点で整理した解説、信頼性の担い手としてのSREはSRE（サイト信頼性エンジニアリング）とDevOpsの違いで扱っています。

チームトポロジーにおけるプラットフォームチームの位置づけ

組織設計の側から Platform Engineering を支えているのが、Matthew SkeltonとManuel Paisの『Team Topologies』です。チームを「ストリームアラインドチーム」「イネイブリングチーム」「コンプリケイテッド・サブシステムチーム」「プラットフォームチーム」の4タイプに分け、チーム間のやり取りを「コラボレーション」「X-as-a-Service」「ファシリテーション」の3つに限定します。

プラットフォームチームは、ストリームアラインドチーム（事業の価値を届けるチーム）の開発を速めるサービスを作り、X-as-a-Service、つまり最小限のやり取りで使ってもらう形を目指します。依頼のたびに打ち合わせが要る状態は、この型から外れているサインです。

IDP・ゴールデンパス・セルフサービスという中核要素

CNCFが挙げる、成功するプラットフォームの7つの属性

CNCFのホワイトペーパーは、プラットフォームの成否を分ける属性を次の7つに整理しています。

Platform as a product：利用者の要件から設計し、製品として改善し続ける
User experience：GUI・API・CLI・IDE・ポータルなど、利用者がいる場所で一貫したインターフェースを出す
Documentation and onboarding：ドキュメントと、新規プロジェクトを素早く立ち上げる仕組みを備える
Self-service：DBの払い出しなどを、人手を介さずCLIやフォームで受け取れる
Reduced cognitive load：実装の詳細を隠し、利用者にサービスの運用責任を負わせない
Optional and composable：一部だけ使える／必要なら基盤外で自前調達できる
Secure by default：組織のルールに沿ったセキュリティとコンプライアンスを既定にする

見落とされやすいのが「Optional and composable」です。一部の機能だけを使うことや、基盤にない機能をプロダクトチームが自前で調達・運用できることが明記されています。同じホワイトペーパーは、トップダウンの強制で利用を広げようとするプラットフォームチームは利用者の反発を招くとも書いています。使われる理由は強制ではなく、便利さで作るものです。

ゴールデンパスと「最も薄いプラットフォーム」の考え方

CNCFは、Kubernetes上のWebアプリをビルド・スキャン・テスト・デプロイ・監視するまでのワークフローを、初期テンプレートとドキュメントと一緒に提供する一式を「golden path」と説明しています。新サービスを作るたびに言語・リポジトリ構成・CI/CD・監視の設定を調べ直す手間を、選ぶだけで済む状態に置き換えるものです。

同じホワイトペーパーは、プラットフォームを「thinnest reasonable layer」、つまり既存の実装の上に一貫性を与える最も薄い層にすべきだとも書いています。例として、各機能の申請手順へのリンクを並べたWikiページでさえ、最小のプラットフォームになりうるとしています。ポータル製品を入れることがPlatform Engineeringの条件ではありません。下回りの自動化はIaC（Infrastructure as Code）やKubernetes上のCrossplaneのような制御基盤が担い、ポータルはその入口にあたります。

CNCF Platform Engineering Maturity Modelの4段階と5つの観点

CNCFのTAG App Deliveryが公開している「Platform Engineering Maturity Model」は、組織のプラットフォームへの取り組みを4段階で表します。段階の名前だけが引用されがちですが、実体は5つの観点ごとに段階を判定する表です。

観点	1 Provisional	2 Operationalized	3 Scalable	4 Optimizing
Investment（投資）	有志・一時的	専任チーム	製品として投資	エコシステム化
Adoption（採用）	散発的	外から推す	自発的に選ばれる	利用者が貢献
Interfaces（接点）	個別の手順	標準ツール	セルフサービス	既存ツールに統合
Operations（運用）	依頼ベース	中央で追跡	中央で自動実行	マネージド化
Measurement（測定）	場当たり的	一貫して収集	戦略的な洞察	定量＋定性を文化に

表の語はCNCF原文の見出し（例：Adoptionは Erratic／Extrinsic push／Intrinsic pull／Participatory）を短く訳したものです。

段階の読み方：OperationalizedとScalableの境目

多くの組織がつまずくのは、2段階目から3段階目への移行です。Operationalizedの採用は「Extrinsic push」、つまり組織が価値を認めて使うよう働きかけている状態を指します。Scalableの採用は「Intrinsic pull」で、プロダクトチームの利用者が、認知負荷が減り品質も上がるという明確な価値を理由に自分から選ぶ状態です。CNCFは、Scalableでは利用者が代替手段より社内の実装を選ぶとも書いています。

利用率の数字が高くても、それが義務化や申請ルールによるものなら、採用の観点ではまだOperationalizedです。段階を測るときは、利用率と同時に「強制されていない場面で選ばれているか」を見ます。

自社の現在地を測る手順

CNCFはモデルの使い方として、まず自社が当てはまる位置を見つけ、次に隣接する段階から取り組む機会を探すよう勧めています。実務では次の順で進めると判定がぶれません。

5観点それぞれについて、4段階の説明文を読み、最も近いものを1つ選ぶ（観点ごとに段階が違ってよい）。
最も低い観点を特定する。Measurementが「場当たり的」のままだと、他の観点の改善を証明できない。
その観点だけを1段階上げる施策を決め、四半期ごとに判定し直す。

最上位を目指す必要はありません。CNCF自身が「no level is inherently good or bad」、つまりどの段階も本質的な良し悪しはなく、チームの状況次第だと明記しています。

Backstageで作るゴールデンパスの最小構成

IDPの入口（開発者ポータル）を作る代表的なOSSが、Spotifyが開発したBackstageです。2020年9月8日にCNCFへ受理され、2022年3月15日からIncubating（育成段階）のプロジェクトです。2026年9月29日時点の最新リリースはv1.55.3です。ここでは、公式ドキュメント（v1.55.3タグ）の仕様に沿って、ゴールデンパスを1本作るのに必要な2つのYAMLを示します。

catalog-info.yamlでサービスと所有チームを登録する

ソフトウェアカタログに載せる単位がComponentです。kind: Component では spec.type・spec.lifecycle・spec.owner の3つが必須で、spec.system は任意です。

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: order-api
  description: 注文受付API
spec:
  type: service
  lifecycle: production   # experimental / production / deprecated
  owner: team-order       # 責任を持つチーム（Groupエンティティ）
  system: ec-platform
  providesApis:
    - order-api

owner には個人ではなくチームを入れます。公式ドキュメントも、所有者を「最終的な責任を負う単一のエンティティ（一般にはチーム）」と説明しています。障害時の連絡先がカタログから引ける状態になるだけでも、口頭の問い合わせが減ります。

Software Templateで新規サービスの作成をセルフサービス化する

ゴールデンパスの本体はSoftware Templateです。apiVersion: scaffolder.backstage.io/v1beta3 の Template に、入力フォーム（parameters）と、順番に実行する処理（steps）を書きます。

apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: node-api-golden-path
  title: Node.js APIサービス（標準構成）
spec:
  owner: team-platform
  type: service
  parameters:
    - title: サービス情報
      required:
        - name
        - owner
      properties:
        name:
          title: サービス名
          type: string
        owner:
          title: 所有チーム
          type: string
          ui:field: OwnerPicker
          ui:options:
            catalogFilter:
              kind: Group
    - title: リポジトリ
      required:
        - repoUrl
      properties:
        repoUrl:
          title: 作成先
          type: string
          ui:field: RepoUrlPicker
          ui:options:
            allowedHosts:
              - github.com
  steps:
    - id: fetch
      name: 雛形の展開
      action: fetch:template
      input:
        url: ./skeleton   # Dockerfile・CI設定・監視設定・catalog-info.yamlを同梱
        values:
          name: ${{ parameters.name }}
          owner: ${{ parameters.owner }}
    - id: publish
      name: GitHubへ公開
      action: publish:github
      input:
        repoUrl: ${{ parameters.repoUrl }}
        defaultBranch: main
    - id: register
      name: カタログへ登録
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}
        catalogInfoPath: /catalog-info.yaml
  output:
    links:
      - title: リポジトリ
        url: ${{ steps.publish.output.remoteUrl }}
      - title: カタログで開く
        icon: catalog
        entityRef: ${{ steps.register.output.entityRef }}

開発者はポータルのフォームにサービス名・所有チーム・作成先リポジトリを入れるだけで、リポジトリ作成、CI/CD・監視込みの雛形展開、カタログ登録までが一度に終わります。ゴールデンパスの価値は skeleton ディレクトリの中身で決まるため、ここには組織の標準（CIのワークフロー、ログとメトリクスの出力設定、脆弱性スキャン）を入れます。なお publish:github を動かすには、Backstageのバックエンドに GitHub 用のscaffolderモジュールを追加し、app-config.yaml の integrations.github にトークンかGitHub Appを設定しておく必要があります。CI/CDの組み方はCI/CDの仕組みとGitHub Actionsの設定例が参考になります。

Backstageは自社で作り込む前提の土台です。プラグインの開発や、月次で出る版への追従に工数がかかる点は見込んでおくべきでしょう。専任の担当者を置けないなら、CNCFの「最も薄い層」に従ってテンプレートリポジトリとWikiから始める手もあります。ドキュメントとテンプレートでゴールデンパスを出せていれば、成熟度モデルのInterfacesでは2段階目（Standard tooling）の水準です。

なお、AWSがマネージドで提供していたテンプレート型の払い出し基盤AWS Protonは、2026年10月7日にサポートを終了しました。終了後に残るリソースの扱いと移行先はAWS Protonとは：2026年10月7日のサポート終了で残るものと移行手順で整理しています。

Gartner予測・Hype Cycle 2026・DORA調査で見る普及の実態

Gartnerの「80%」予測は2種類ある

Gartnerの解説記事「What is platform engineering?」には、よく引用される「80%」の予測が2つ載っています。

2026年までに、大規模なソフトウェアエンジニアリング組織の80%が、アプリケーション提供のための再利用可能なサービス・部品・ツールを社内に提供するプラットフォームエンジニアリングチームを設置する（2022年は45%）。
2027年までに、大規模組織の80%が、ハイブリッドクラウド環境でDevOpsを拡大するためにプラットフォームエンジニアリングを採用する（2023年は30%未満）。

どちらも対象は大規模組織です。数十人規模の開発組織に「80%の企業がやっている」と当てはめるのは、この予測の読み方として誤りです。

Hype Cycle for Platform Engineering 2026で目立つAI関連の技術

Gartnerは「Hype Cycle for Platform Engineering」を毎年発行しています（2025年版は同社ドキュメントID 6586902）。2026年版は有料レポートで本文は公開されていませんが、掲載された各社が2026年5〜6月に掲載を発表しています。Endor Labs（2026年5月21日）はSoftware Supply Chain Securityの分類に、TrueFoundry（2026年6月4日）はGenAI Model Routers・AI Gateways（いずれもピーク前の「On the Rise」）とAI Engineering（ピーク期、効果は「Transformational」）に載ったと公表しています。

ここから読めるのは、プラットフォームの守備範囲が、人間の開発者向けの基盤から、AIモデルへの通信の統制やAIエージェントの実行基盤まで広がっていることです。ただし位置づけの詳細はベンダーの紹介文を経由した情報のため、採否の判断には原典を確認してください。

DORA調査：IDP利用は90%、ただし安定性の低下に注意

DORAのPlatform Engineeringの解説によると、2025年の調査では組織の90%が内部開発者プラットフォームを使っていると答え、76%が専任のプラットフォームチームを置いていました。2025年の調査の主題は「AIは増幅器である」で、プラットフォームの品質が高い組織ほどAI導入が組織の成果に結びつき、品質が低いとその効果はほぼ出ないとしています。

一方で2024年の調査（Accelerate State of DevOps Report 2024）は、IDPの利用が個人の生産性・チームと組織のパフォーマンスを高める一方、変更の安定性とスループットを下げうると報告しました。DORAはこのため、デプロイ頻度・変更のリードタイム・変更失敗率・復旧時間などのデリバリー指標と、開発者満足度を組み合わせて測るよう勧めています。指標の定義と計算方法はFour Keys（DORA 4指標）の定義と計算方法にまとめています。

導入が失敗するパターンと、導入を見送るべき組織の条件

DORAは、Platform Engineeringで繰り返し見られるアンチパターンを5つ挙げています。

作れば使われる（Build it and they will come）：利用者調査をせず想定で作り、実際の困りごとに合わず使われない。
象牙の塔（Ivory tower）：中央チームが硬直した標準を押し付け、回避策としてのシャドーITを生む。
チケット運用（Ticket-ops）：依頼をさばく「自動販売機」のまま、セルフサービスの機能を作れない。
ビッグバンリリース：全部入りの完成まで出さず、公開時には開発者のニーズが変わっている。
画一化（One-size-fits-all）：データサイエンスやモバイルなど異なるニーズを無視した「黄金の檻」を作る。

3つ目のチケット運用は、日本の情報システム部門やインフラチームがそのまま名前を変えた場合に起きやすい失敗です。申請フォームをポータルに移しただけで、裏で人が手作業している状態は、成熟度モデルのInterfacesでは標準の窓口がある2段階目（Standard tooling）止まりで、保守担当の支援なしで使える3段階目（Self-service solutions）には届いていません。

そもそも導入を見送るべき組織もあります。本番で動くサービスが数本で、開発者全員が日常的に直接話せる規模なら、専任のプラットフォームチームは作らない方がよいと考えます。小規模な組織では、基盤の保守コストが削減できる手間を上回りやすいためです。まずは新サービスの雛形リポジトリと手順書を1つにまとめ、DORAの言う「最小限の実用的なプラットフォーム」を兼務で持つ段階で止めておき、同じ問い合わせや設定ミスが繰り返し起きるようになってから専任化を検討します。

国内の動向：Platform Engineering Kaigi 2026と日本語の参考書

主催者が国内最大級とするカンファレンス「Platform Engineering Kaigi 2026」は、一般社団法人クラウドネイティブイノベーターズ協会の主催で、2026年9月26日（土）に中野セントラルパークカンファレンスで開催されました（現地とオンラインのハイブリッド）。3回目の今回のテーマは「AI Native Platform Engineering」で、主催者の告知では、キーノートはPlatformConの創設者でHumanitecの創業者でもあるKaspar von Grünberg氏による「Architecting Agentic Development Platforms」です。主催者の発表では、2024年の初回に約1,000名が参加しています。

体系的に学ぶなら、Camille FournierとIan Nowlandの『プラットフォームエンジニアリング ―成功するプラットフォームとチームを作るガイドライン』（オライリー・ジャパン、2025年11月29日発行、346ページ）が日本語で読める専門書です。CNCFのホワイトペーパーと成熟度モデルは無料で読めるため、社内で用語をそろえる最初の資料にはこちらが向いています。

Platform Engineeringについてよくある質問

プラットフォームエンジニアリングとDevOpsは何が違いますか？

DevOpsは開発と運用の分断をなくす文化と実践で、Platform Engineeringはそれを各チームが自力で回せるよう、共通基盤を社内製品として提供する取り組みです。DevOpsを置き換えるものではなく、チームが増えてもDevOpsを続けられるようにする手段と捉えます。

SREとPlatform Engineeringの違いは何ですか？

SREはSLOとエラーバジェットで本番サービスの信頼性を守る役割で、利用者はサービスの最終ユーザーです。Platform Engineeringの利用者は社内の開発者で、目的は開発者の認知負荷を下げることです。監視や障害対応の仕組みをプラットフォームに組み込む場面では、両者が協力します。

プラットフォームエンジニアリングの成熟度モデルとは何ですか？

CNCFのTAG App Deliveryが公開している「Platform Engineering Maturity Model」を指すのが一般的です。Provisional・Operationalized・Scalable・Optimizingの4段階を、投資・採用・インターフェース・運用・測定の5観点ごとに判定します。CNCFはどの段階にも本質的な良し悪しはないとしており、全観点で最上位を目指すものではありません。