💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

はじめに: 2026年、なぜIDPは必須になったのか

2024年、Gartnerは「2026年までに大規模ソフトウェア組織の80%がプラットフォームチームを運営する」と予測しました。2026年現在、この予測はほぼ実現されています。CNCF 2025 Annual SurveyによればBackstageはGitOpsツールに次いで最も急速に採用されているCNCF Incubatingプロジェクトとなり、PortやCortexのようなSaaS IDPはシリーズC・Dを締めくくり本格拡大期に入りました。

しかし2025年末、ある出来事がIDPコミュニティを揺さぶりました。Spotifyが社内版「Portal」のコア機能をBackstageオープンソースから分離し、別の商用パッケージとしてリリースしたのです。これはBackstageのガバナンスとライセンスモデルに関する激しい議論を引き起こし、「managed Backstage」であるRoadieとセルフホスティングの間のトレードオフを改めて評価させることになりました。

本稿では2026年IDP市場の主要11プレイヤー — Backstage、Port、Cortex、OpsLevel、Humanitec、Mia-Platform、Compass (Atlassian)、Roadie、Configure8、メルカリATLAS、Naver SCM Portal — を深く分析します。

Platform Engineering vs DevOps: 何が違うのか

2010年代のDevOpsムーブメントは「You build it, you run it」の哲学で開発と運用の壁を取り払いました。しかしマイクロサービスが爆発した2020年代半ば、このモデルは限界を露呈します。平均的なフルスタック開発者がKubernetes manifests、Terraform、Helm charts、ArgoCD、Prometheus、Grafana、Datadog、Snyk、SonarQube — これらすべてを深く理解せよという要求は非現実的でした。

Manuel PaisとMatthew Skeltonが2019年に出版した『Team Topologies』はこの問題への答えを示しました: **Stream-aligned team**(価値提供チーム)が高速に動けるよう、**Platform team**(プラットフォームチーム)がセルフサービスインフラを提供しなければならない、というものです。

Platform EngineeringはDevOpsの否定ではなく進化です。DevOpsの文化的価値(協働、自動化、計測、共有)は維持しつつ、認知負荷(cognitive load)を下げるためによく設計された抽象化層を追加するのです。

Team Topologiesと4つのチーム類型

Team Topologiesは4つの基本的なチーム類型を定義します。

1. **Stream-aligned team** — 価値の流れ(決済、検索、推薦など)に沿ったチーム

2. **Platform team** — Stream-aligned teamのためのセルフサービス基盤を提供

3. **Enabling team** — 特定技術領域(セキュリティ、SRE、データ)で他チームを支援・コーチング

4. **Complicated-subsystem team** — 深い専門知識が必要な領域(ML推論エンジン、取引エンジンなど)

プラットフォームチームの黄金律は **「プラットフォームをプロダクトとして扱え(Platform as a Product)」** です。ユーザーはstream-aligned開発者であり、彼らの満足度(NPS)と採用率がプラットフォームチームの成功指標となります。

Backstage 1.30: コアで何が変わったか

2026年5月時点でBackstageは1.30.xラインを維持しています。1.30シリーズの主要変更点は以下のとおりです。

- **New Frontend System (NFS)** GA: 従来のcreatePlugin APIを置き換える新しい拡張モデルが安定化。

- **Catalog database backend** のパフォーマンス改善: PostgreSQL以外にSQLiteのproduction利用は正式にdeprecation段階へ。

- **Permission Framework** 統合強化: カタログエンティティ別のRBACポリシーをOPA(Open Policy Agent)またはCasbinで表現可能。

- **Software Templates** のスキーマがv1beta3からv1へ移行。

最大の運用上の変化は **NFS(New Frontend System)** です。既存プラグインを移行しないと1.32以降サポートが終了します。社内に50以上の自作プラグインを持つ組織(Netflix、Spotify、楽天など)にとっては6〜9ヶ月の移行プロジェクトになります。

Backstageコア概念: Software Catalog

Software CatalogはBackstageの心臓です。すべてのコンポーネント(サービス、ライブラリ、ウェブサイト)、API、リソース(データベース、S3バケット)、システム、ドメインが `catalog-info.yaml` ファイルとして表現されます。

apiVersion: backstage.io/v1alpha1

kind: Component

metadata:

description: Core payment processing service

annotations:

github.com/project-slug: acme-corp/payment-service

backstage.io/techdocs-ref: dir:.

pagerduty.com/integration-key: PAGERDUTY_KEY_REF

sonarqube.org/project-key: payment-service

grafana/dashboard-selector: "tag = 'payment'"

tags:

- java

- spring-boot

- tier-1

spec:

type: service

lifecycle: production

owner: team-payments

system: checkout

providesApis:

- payment-api-v2

consumesApis:

- fraud-detection-api

- notification-api-v1

dependsOn:

- resource:postgres-payments

- resource:redis-payment-cache

このファイルがGitHubにpushされるとBackstage Catalog Processorが発見し、すべてのメタデータ・所有者・依存関係グラフを自動的にインデックス化します。別チームの新人エンジニアが「決済システムは誰が責任を持つ? どのDBを使っている?」と尋ねたとき、答えはコードの隣のYAMLファイルにあります。

Software TemplatesとScaffolder

Software TemplatesはIDPの最も強力な約束を実現します — **「新しいサービスを5分でproductionへ」**。

apiVersion: scaffolder.backstage.io/v1beta3

kind: Template

metadata:

title: Java Spring Boot Microservice (Golden Path)

description: Java 21 + Spring Boot 3.3 + JPA + OpenTelemetry

spec:

owner: team-platform

type: service

parameters:

- title: Service Identity

required: [name, owner, tier]

properties:

name:

type: string

pattern: '^[a-z][a-z0-9-]{2,30}$'

owner:

type: string

ui:field: OwnerPicker

tier:

type: string

enum: [tier-1, tier-2, tier-3]

steps:

- id: fetch-template

action: fetch:template

input:

url: ./skeleton

values:

owner: ${{ parameters.owner }}

- id: publish

action: publish:github

input:

repoUrl: github.com?repo=${{ parameters.name }}&owner=acme-corp

defaultBranch: main

protectDefaultBranch: true

requireCodeOwnerReviews: true

- id: register

action: catalog:register

input:

repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}

catalogInfoPath: /catalog-info.yaml

このテンプレートを一度実行すると、次が自動で起こります: GitHub repo作成、branch protection、CODEOWNERS設定、ArgoCD ApplicationSet登録、Datadog monitorプロビジョニング、OpsGenieオンコールスケジュール連携、SonarCloudプロジェクト作成。開発者は最初のcommitからproductionデプロイまで30分で到達できます。

TechDocs: ドキュメントをコードの隣に

TechDocsはBackstageの「docs as code」実装です。MkDocsをベースにしており、各コンポーネントの `docs/` ディレクトリにmarkdownファイルを置けばBackstage UI上で検索可能なサイトとしてレンダリングされます。

中心となる運用パターンは **TechDocs Out-of-the-box (OOTB) vs Recommended** の分離です。OOTBモードはユーザーがカタログに来たときにon-demandでdocsをビルドするため、200+コンポーネント規模で深刻なレイテンシを生みます。RecommendedモードはCIでMkDocsをビルドしてS3/GCSへpushし、Backstageは単に静的ファイルを配信するだけです。production環境では事実上Recommendedモードが標準です。

Backstageプラグインエコシステム: コアプラグイン5選

Backstageの真の価値はプラグインエコシステムにあります。2026年5月時点で公式+コミュニティのプラグインは350以上。最も採用されているコア5つを紹介します。

1. **@backstage/plugin-kubernetes** — コンポーネント単位でK8s deployment・pod・service・hpaの状態を表示。マルチクラスタ対応が強力で、EKS/GKE/AKS authすべて標準。

2. **@backstage-community/plugin-github-actions** — 各コンポーネントの最近のGHA workflow実行をカタログページに埋め込み。

3. **@backstage-community/plugin-sonarqube** — コード品質メトリクス(coverage, smells, vulnerabilities)をカタログに公開。

4. **@backstage/plugin-techdocs** — 上述のdocs-as-codeエンジン。

5. **@backstage-community/plugin-cost-insights** — コンポーネント別クラウドコストを時系列表示。FinOpsチームが最も愛するプラグイン。

Port: モデル駆動ローコードIDP

Port(getport.io)は2024〜2025年で最も急成長したSaaS IDPです。Backstageが「コードファースト」(YAMLでカタログを定義)であるのに対し、Portは「モデルファースト」です。どのエンティティ型(Blueprint)があり、どのプロパティと関係を持つかをUIまたはJSONで先に定義します。

{

"identifier": "service",

"title": "Service",

"schema": {

"properties": {

"language": { "type": "string", "enum": ["go", "java", "python", "node"] },

"tier": { "type": "string", "enum": ["1", "2", "3"] },

"on_call_rotation": { "type": "string", "format": "url" },

"slo_availability": { "type": "number", "minimum": 0, "maximum": 100 }

"required": ["language", "tier"]

"relations": {

"owning_team": { "target": "team", "required": true, "many": false },

"deployments": { "target": "deployment", "required": false, "many": true }

"calculationProperties": {

"is_production_ready": {

"calculation": ".properties.tier == \"1\" and .properties.slo_availability >= 99.9",

"type": "boolean"

}

Portの強み:

- **Exporters**: AWS、GCP、K8s、GitHub、Snyk、Datadogなど30以上の統合をノーコードで設定可能。

- **Scorecards**: サービス成熟度を定量的に測定。

- **Self-Service Actions**: Slackから `/port deploy` のようなアクションをトリガー。

弱点はSaaS依存とenterprise tierの価格(`$25K`/年〜)、on-prem対応が遅かったことで、韓国の金融業界での採用には依然として障壁が残ります。

Cortex: サービス成熟度を中心に据えたIDP

Cortex(cortex.io)は「Service Maturity」を中心に据えたIDPです。PortやBackstageがcatalogとactionsにバランスを置くのに対し、Cortexは **Scorecards** が第一級市民です。

Cortex Scorecardsは以下のようなルールベース評価をサポートします。

- すべてのサービスにowner teamが存在すること。

- Tier-1サービスはPagerDuty integrationを持つこと。

- 90日以内にSLO定義が更新されていること。

- すべてのproductionサービスにSBOMが登録されていること。

- コードカバレッジ70%以上。

各ルールはweightを持ち、サービス毎に「Bronze / Silver / Gold」レベルが自動計算されます。プラットフォームチームは四半期ごとにweightを調整し、会社の優先事項(セキュリティ強化四半期、信頼性強化四半期など)を反映できます。

OpsLevel: RubricsとCampaigns

OpsLevel(opslevel.com)はCortexと最も直接競合する製品です。コアコンセプトは **Rubrics** と **Campaigns** です。

- **Rubrics**: 各サービスが満たすべきチェック項目(CortexのScorecardに類似)。

- **Campaigns**: 「全社的に30日以内にLog4j 1.xを除去する」のような時間制限付き改善プロジェクト。各チームの進捗をリアルタイム追跡。

OpsLevelの差別化点は **AI Engineer**(2025年リリース) — 自然言語でカタログにクエリできます(「tier-1サービスでPagerDuty連携がないものは?」)。BackstageのRAGベースカタログ検索がまだ実験段階なのと対照的です。

HumanitecとScore: ワークロード仕様の標準化

Humanitec(humanitec.com)は他のIDPとは別の層に位置します。Backstage・Port・Cortexが「ポータル」層なら、Humanitecは「Internal Developer Platform Orchestrator」 — 実際の環境プロビジョニングとデプロイを抽象化するエンジンです。

Humanitecが牽引するオープン仕様が **Score**(score.dev)です。2025年にCNCF Sandboxに加わったScoreは、ワークロード仕様の環境非依存(environment-agnostic)標準を目指します。

apiVersion: score.dev/v1b1

metadata:

containers:

main:

image: ghcr.io/acme/orders-api:v3.4.2

variables:

DATABASE_URL: ${resources.orders-db.connection}

REDIS_URL: ${resources.cache.url}

LOG_LEVEL: info

resources:

requests:

cpu: "200m"

memory: "256Mi"

limits:

cpu: "1000m"

memory: "512Mi"

service:

ports:

http:

port: 8080

targetPort: 8080

resources:

orders-db:

type: postgres

params:

version: "16"

cache:

type: redis

dns:

type: dns

このファイル1つがdevではdocker-compose、stagingではKubernetes + RDS、productionではEKS + Auroraへ自動変換されます。Backstageが「何があるか」に答えるなら、Scoreは「どう動かすか」に答えます。

Mia-Platform: 欧州のIDP強豪

Mia-Platform(mia-platform.eu)はミラノ拠点のIDPで、欧州金融業界で強い存在感を見せます。Backstage UIの上にMia独自のfast-dataエンジン、microservice templates、マルチクラスタデプロイツールを組み合わせたパッケージです。PSD2/GDPR準拠が優先のEU市場でSaaS+セルフホスト併用オプションが強みです。

Compass (Atlassian): Jira/Confluenceとの統合

Atlassian Compassは、すでにJira・Confluence・Bitbucketを使っている組織を狙ったIDPです。強みは何と言っても **ワークフロー統合** です。Compassカタログのサービスから直接Jira ticketを生成でき、変更履歴はConfluenceページに自動publishされます。

ただしCompassは現在Atlassian Cloud専用で、on-prem(Data Center)に留まる日本・韓国の大規模組織の多くが導入を躊躇しています。2026年にAtlassianがData Center向けCompassをリリースするかが見どころです。

Roadie: Managed Backstage

Roadie(roadie.io)は「Backstageを自分で運用したくないが、Backstageの柔軟性は欲しい」組織のためのSaaSです。RoadieはBackstageコアをforkせずにplugins as a serviceとしてパッケージ化し、upstream互換性を維持します。

Roadieを選ぶ判断基準:

- プラットフォームチームが5名以下 → Roadie推奨(Backstage自前運用はフルタイム2〜3名必要)。

- 自作プラグイン開発の必要性が低い → Roadie推奨。

- データ主権(特にEU・韓国金融) → セルフホストBackstage。

- 200以上のサービス → Roadieのマルチテナンシー制約を考慮。

Configure8: 可視化に注力したIDP

Configure8はサービストポロジー可視化に強みを持つ新興IDPです。依存関係グラフ、リアルタイムトラフィックフロー、インシデント発生時の影響範囲可視化などが差別化点。ただしカタログの一貫性とself-service automationはPort/Backstageに比べてまだ成熟度が低いです。

韓国・日本の事例: カカオ、メルカリATLAS、楽天

韓国では **カカオ Cognity** プラットフォームチームがカカオエンタープライズと連携してBackstageベースの社内IDPを運営しています。200以上のマイクロサービスのSLO、コスト、セキュリティコンプライアンスを統合管理。**ネイバーはSCM Portal** という自社開発IDPを運営し、GitHub Enterprise + Jenkins + Argo + 独自K8sコントロールプレーンを束ねます。**LINE (LY Corporation)** はdev portalをBackstageの自社フォークで運用しています。

日本で最も有名な事例は **メルカリのATLAS** です。2022年にMercari Engineeringブログで初公開されたATLASはBackstageベースで、ML Platformチーム、SREチーム、Securityチームのツールを統合した社内ポータルです。2026年現在、Mercariグループ全体の800以上のコンポーネントを管理しています。また **サイバーエージェント** のAKE(AbemaTV Kubernetes Engine)、**楽天** のRakuten One Platformも独自IDPを運営中です。**Sansan** はCompassを導入した日本国内の初期事例の一つとして知られます。

Golden PathsとPaved Roads

「Golden Path」はSpotifyが2020年に導入した概念です。一つの推奨される最も整備された道 — この道を進めばすべてのインフラ、セキュリティ、観測可能性が自動的に揃います。Netflixの同等概念は「Paved Road」 — 道の上は安全で速いが、未舗装路を走るなら自己責任、という発想です。

Golden Pathは強制ではありません。特殊要件のチームは外れることもできますが、その責任(セキュリティ監査、コスト最適化、インシデント対応)を自分で負います。このトレードオフを明確に伝えられるとき、開発者の自律性と組織の標準は共存できます。

DX計測: DORA + SPACEメトリクス

プラットフォームチームは「成功」をどう定義するでしょうか。DORA(DevOps Research and Assessment)の4メトリクスが出発点です。

1. **Deployment Frequency** — どのくらい頻繁にデプロイするか

2. **Lead Time for Changes** — コードcommitからproductionまでの時間

3. **Change Failure Rate** — デプロイ中のインシデント・ロールバック比率

4. **Mean Time to Recovery** — インシデント発生後の復旧時間

しかしDORAだけでは不十分です。Microsoft Researchが2021年に発表した **SPACEフレームワーク** は5つの次元を加えます: Satisfaction、Performance、Activity、Communication/collaboration、Efficiency。とりわけ開発者満足度(Satisfaction)は四半期ごとのNPSで計測すべきです — IDPの本当のユーザーがそれを楽しめないなら、定量メトリクスが嘘をついている可能性が大きいのです。

セルフサービスインフラテンプレート: Terraform Modules + Crossplane

Software TemplatesのDay 0は容易ですが、Day 2(ライフサイクル管理)は難しい。2026年の標準パターンは以下です。

- **Terraform Modules**(またはPulumi/CDK) — クラウドリソースのオプション化された単位。

- **Crossplane Compositions** — Kubernetes-nativeにクラウドリソースを管理。

- **Backstage Scaffolder** がこの二つをトリガーし、結果のリソースをcatalogに登録。

開発者がBackstage UIで「New Postgres DB」をリクエストしたときに起きること

backstage scaffolder run \

--template postgres-database \

--name orders-db \

--tier production \

--size medium

内部的には

git push -> renovate-style PR -> ArgoCD sync ->

Crossplane Composition -> AWS RDS Aurora cluster ->

catalog entity 登録 -> Datadog monitor 作成 ->

PagerDuty service 連携 -> Slack 通知

マルチクラスタアプリ管理

2026年の大規模組織の標準はfleet of clustersです — リージョン別、環境別、チーム別にクラスタが分離されます。Backstage Kubernetesプラグインは30以上のクラスタまでうまく扱いますが、それ以上では次のパターンが必要になります。

- **Cluster locatorのモジュール化**: クラスタメタデータをcatalog entityとしてモデリング。

- **ArgoCD ApplicationSet + Backstage**: 一つのコンポーネントが5リージョンに同時デプロイされる様子を可視化。

- **KubeFleet / Karmada / Liqo** のようなマルチクラスタコントロールプレーン統合。

オープンソースIDP vs SaaS: 意思決定マトリクス

| --- | --- | --- | --- | --- | --- |

| 初期学習曲線 | 高い | 中 | 低い | 低い | 低い |

| カスタマイズ自由度 | 非常に高い | 高い | 中 | 中 | 中 |

| 運用人員 (FTE) | 2〜3+ | 0.5〜1 | 0.5〜1 | 0.5〜1 | 0.5〜1 |

| 開始価格 (年額) | インフラのみ | 約 `$15K` | 約 `$25K` | 約 `$30K` | 約 `$30K` |

| プラグイン数 | 350+ | 100+ (キュレーション) | 30+ 統合 | 20+ 統合 | 25+ 統合 |

価格は2026年5月時点の公開情報による概算で、実際のenterprise契約は別途交渉が必要です。

セキュリティとガバナンス: IDPが生む新しい責務

IDPが持つ権限が強くなるほど攻撃面も広がります。Backstageカタログに露出したPagerDuty key、AWS account ID、GitHub PATがSSRF脆弱性と組み合わさるとcritical incidentになります。2024〜2025年のBackstageセキュリティ勧告(GHSA-9p4x-3v2h-9q4jなど)シリーズは、IDPがもはや単なるカタログではなくsupply chainの中心にあることを示しています。

推奨される統制:

- Permission Frameworkの有効化(default deny)。

- OIDC SSO + step-up auth(センシティブなアクションは二段階認証)。

- すべてのScaffolderアクションのaudit logをSIEMへ送付。

- Catalogのsecret/keyは外部vault参照のみで表現する。

導入ロードマップ: 0 → 1 → N

プラットフォームチームが初めてIDPを導入するときに陥りがちな罠は「一度に全部」です。推奨される段階的アプローチ:

**Stage 0 (Month 1〜2)**: 社内のstream-aligned teamへのインタビュー5〜10件。認知負荷をマッピング。トップ3 pain pointsを特定。

**Stage 1 (Month 3〜6)**: BackstageまたはPortのどちらかでPoC。カタログだけから始める。30〜50の中核サービスをcatalog-info.yamlとして登録。

**Stage 2 (Month 6〜9)**: Software Templateを1つだけ作る。例: 「Java microservice golden path」。5〜10の新規サービスがこのテンプレートから作られれば成功。

**Stage N (Year 2+)**: Scorecards導入。Cost Insights統合。マルチクラスタ可視化。Score workload spec導入。

よくあるアンチパターン7選

1. **カタログを強制する前に価値証明がない** — 上からの命令だけでは採用されない。

2. **一度に多くのTemplateを公開** — 30本のテンプレートより、よく作られた1本のほうが良い。

3. **プラットフォームチームがstream-aligned teamのコードを直接編集** — Topology原則違反。

4. **TechDocs OOTBモードをproductionで使う** — 200以上のサービスで崩壊。

5. **Scorecardのweightを一度決めて永遠にそのまま** — 四半期レビュー必須。

6. **データ residency 方針を確認せずSaaS IDPを導入** — 金融監査で落ちる。

7. **NPS計測なしで定量メトリクスのみ報告** — DORAがgreenでも開発者は嫌いかもしれない。

2026年以降: IDPの未来

3つの大きな流れが今後5年のIDPを規定するでしょう。

1. **AI-Native IDP**: 自然言語コマンド(「stagingに新サービスを作って」)でScaffolderがトリガーされる。OpsLevel AI Engineer、Port AI Agentsが先行例。

2. **Score標準の採用拡大**: K8s manifestsが複雑すぎるという合意が形成され、ワークロード抽象化レイヤーが標準化。

3. **Backstageガバナンスの進化**: CNCF Graduationへの最終段階。Spotify商用フォークの問題がどう整理されるかが焦点。

プラットフォームエンジニアリングはもはやトレンドではありません — 2020年代後半のソフトウェア組織にとっての標準運用モデルです。

References

- [Backstage 公式ドキュメント](https://backstage.io)

- [Backstage 1.30 Release Notes](https://backstage.io/docs/releases/v1.30.0/)

- [getport.io — Port IDP](https://www.getport.io/)

- [cortex.io — Service Maturity Platform](https://www.cortex.io/)

- [opslevel.com — Engineering Excellence](https://www.opslevel.com/)

- [humanitec.com — Internal Developer Platform Orchestrator](https://humanitec.com/)

- [score.dev — Workload Specification](https://score.dev/)

- [teamtopologies.com](https://teamtopologies.com/)

- [dora.dev — DORA Research](https://dora.dev/)

- [SPACE Framework Paper, Microsoft Research](https://queue.acm.org/detail.cfm?id=3454124)

- [Mia-Platform Documentation](https://mia-platform.eu/)

- [Atlassian Compass](https://www.atlassian.com/software/compass)

- [roadie.io — Managed Backstage](https://roadie.io/)

- [Configure8](https://www.configure8.io/)

- [Mercari Engineering — ATLAS Internal Platform](https://engineering.mercari.com/en/blog/)

- [CNCF Annual Survey 2025](https://www.cncf.io/reports/)

- [Spotify Engineering Blog — Golden Paths](https://engineering.atspotify.com/)

- [Netflix Tech Blog — Paved Road](https://netflixtechblog.com/)