> 「プラットフォームエンジニアリングはDevOpsを置き換えたのではない。DevOpsの約束をようやくプロダクト化したのだ」 — あるSREリードの言葉

本記事は **2026年5月時点のIDP(Internal Developer Platform)市場マップ** である。BackstageはCNCFを卒業して事実上の標準となり、Spotify自身がPortal for Backstageという商用パッケージを投入、RoadieはマネージドBackstageとしてYC出身らしい速度で地歩を固めた。その周りにPort、OpsLevel、Cortex、Configure8、HumanitecなどのSaaS勢が「Backstageは重い」をマーケティングメッセージとして市場を取りに来ている。Atlassian CompassはJira/Confluenceの生態系を引き連れて参入した。

本稿ではカタログ、スコアカード、ゴールデンパス、セルフサービスインフラ、ソフトウェアテンプレートの五つの軸で各ツールを比較する。最後にカラット、トス、サイバーエージェントCIU、メルカリの実例を取り上げ、「うちのチームはIDPを導入すべきか」という意思決定ガイドで締める。

1. 2026年のIDPマップ — なぜ今プラットフォームエンジニアリングか

2020年代初頭、DevOpsは「全員が全部をやる」と解釈され、副作用が積み上がった。バックエンドエンジニアがKubernetesマニフェストを直接書き、Terraformを手で書き、GitHub Actionsワークフローを毎日磨き、Helmの値ファイルを環境別に五つずつ管理する。結果として「機能開発に使う時間30%、インフラ/ツールに使う時間70%」という認知負荷が生産性を蝕んだ。

プラットフォームエンジニアリングはこの認知負荷を **社内プロダクト** として吸収しようという運動である。その成果物がIDPだ。2026年の市場は大きく四つに分かれる。

- **オープンソース標準**: Backstage (CNCF graduated, 2024)

- **マネージドBackstage**: Spotify Portal、Roadie

- **SaaSカタログ/スコアカード**: Port、OpsLevel、Cortex、Atlassian Compass、Configure8

- **セルフサービスインフラオーケストレーション**: Humanitec、Crossplaneベースのツール群

Gartnerは2026年までに大規模ソフトウェアエンジニアリング組織の80%がプラットフォームチームを持つと予測した。実際、Stack Overflow Developer Survey 2025では回答者の38%が「会社に専任のプラットフォームチームがある」と回答している。

2. IDPの中核概念 — カタログ / Scorecard / Golden Path / セルフサービス

IDPを評価する共通語彙がある。五つの軸で整理する。

**1) Software Catalog(ソフトウェアカタログ)**. 会社が保有する全サービス、ライブラリ、API、データパイプラインを一箇所で検索可能にするメタデータストア。Backstageの `catalog-info.yaml` が事実上の標準フォーマットになった。

**2) Scorecard(スコアカード)**. サービスが満たすべき基準のチェックリスト。「テストカバレッジ70%以上」「Datadogアラート設定済み」「ランブック存在」「オーナー明示」などの項目を継続的に自動評価し、点数化する。OpsLevelとCortexがこの機能を強くプッシュ、BackstageはTech Insightsプラグインで類似機能を実装する。

**3) Golden Path(ゴールデンパス)**. 新規サービスを作る際の推奨経路。「Goサービス=chiルータ+zapロガー+OpenTelemetry+標準GitHub Actionsワークフロー」。逸脱は可能だが明示的な正当化が必要となる。

**4) Self-Service Infrastructure(セルフサービスインフラ)**. 開発者がチケットを切らずに新しいデータベース、キュー、S3バケットを自分で作れるワークフロー。バックエンドはCrossplaneやTerraform Cloud、フロントエンドはBackstage Software TemplateやPort Actionとして公開される。

**5) Software Template(ソフトウェアテンプレート)**. 新規リポジトリ/サービスのボイラープレートを自動生成するスキャフォルダ。`@backstage/plugin-scaffolder` が代表。Cookiecutter、YeomanのIDP版と思えばよい。

この五つの中で **カタログこそIDPの心臓** である。カタログのないIDPはただのWikiだ。

3. Backstage — CNCF卒業、事実上の標準

Backstageは2020年にSpotifyがオープンソース公開したIDPフレームワーク。2022年にCNCF Incubating、2024年にGraduated段階へ進んだ。React + Node.js + TypeScriptで書かれ、プラグインアーキテクチャが強みだ。

**アーキテクチャの核心**:

catalog-info.yaml — Backstageの事実上の標準メタデータ

apiVersion: backstage.io/v1alpha1

kind: Component

metadata:

name: payment-service

description: 決済処理サービス

annotations:

github.com/project-slug: myorg/payment-service

pagerduty.com/integration-key: PD123

datadoghq.com/service-name: payment

spec:

type: service

lifecycle: production

owner: team-payments

system: payments

dependsOn:

- resource:postgres-payments

- component:user-service

Backstageの **強み**:

- プラグインエコシステムが圧倒的に大きい(2026年時点で公式・コミュニティ合わせて200個以上)

- 完全オープンソース、データロックインなし

- CNCF卒業によりガバナンスが安定

- 主要クラウド全てでセルフホスト可能

Backstageの **弱み**:

- セットアップが重い。本番デプロイまで平均3〜6か月

- React/Node.jsフルスタック運用力が必要

- プラグイン互換性の崩れが頻発した(1.0以降は安定化進行中)

- UIカスタマイズはコードを直接触る必要がある

**誰が選ぶべきか**: エンジニア100人以上の組織、インフラ/プラットフォームチームが5人以上いるところ、データロックインを絶対回避したいところ。Netflix、Spotify、American Airlines、Expedia、LinkedIn、Twilioなどがセルフホスト運用している。

4. Spotify Portal for Backstage — 商用パッケージ

2024年、Spotifyは本家らしく **Portal for Backstage** という商用製品を発表した。オープンソースBackstageの上にSpotify社内で実証済みのプレミアムプラグイン群を載せた形態である。

含まれる主要プラグイン:

- **Soundcheck**: Spotifyが内部で使ってきたスコアカードシステム。OpsLevel/Cortexの直接競合

- **Skill Exchange**: 社内メンタリング/出向マッチング

- **Insights**: Backstage利用分析ダッシュボード

- **RBAC**: 権限管理(オープンソースには基本RBACしかない)

- **AiKA**: AI Knowledge Assistant。社内ドキュメント/カタログをLLMで検索

価格モデルはシートあたり月額と報じられており、セルフホストのBackstageインスタンスにプラグインをインストールする方式。つまり **ホスティングは自前、プレミアム機能はライセンス購入** となる。

**誰が選ぶべきか**: 既にBackstageをセルフ運用中でスコアカード/AI検索/RBACを自前実装したくない組織。「Backstage本家の保証」が意思決定基準になる保守的なエンタープライズ。

5. Roadie — マネージドBackstage (YC)

RoadieはY Combinator出身のスタートアップで **ホスト済みのBackstage** を提供する。Backstageの運用を外注するイメージだ。

特徴:

- Backstageコアをそのまま使用、ロックイン最小化

- 30以上の統合が即座に動く(GitHub、GitLab、PagerDuty、Datadog、Sentry、AWS、GCP、ArgoCD)

- TechDocs(Backstageのドキュメントシステム)が箱に入っている

- スコアカード機能内蔵(SoundcheckやOpsLevelと類似)

- 価格: シートあたり月額、小規模チームは無料ティアあり

**Roadieを検討する理由**:

1. Backstageは良いが運用人員がいない

2. 6か月かかるセットアップを1週間に短縮したい

3. カタログデータはGitHubに置いておきたい(`catalog-info.yaml` がそのまま生きる)

**限界**: 深いカスタマイズはセルフホストより制限的。一部プラグインはマネージド環境で動作しない。

6. Port — 意見の強い速いIDP

Portは2022年にテルアビブで創業したIDP SaaSだ。2024年にSeries Bを完了。「Backstageは重い、我々は軽くて意見が強い」が中核メッセージ。

Portの **データモデル** はBackstageと異なる。BackstageはComponent / API / Resource / System / Domainという固定種類を使うが、Portは **ユーザーが自分でBlueprint(エンティティ種類)を定義** する。例:

Port Blueprint 例

identifier: microservice

title: Microservice

icon: Microservice

schema:

properties:

language:

type: string

enum: [Go, TypeScript, Python, Rust]

tier:

type: string

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

on_call:

type: string

format: user

slo:

type: number

relations:

team:

target: team

required: true

database:

target: postgres_instance

many: true

Portの **強み**:

- セットアップ1日〜1週間。Backstage比で圧倒的に速い

- Self-service actions: 「新規マイクロサービス作成」「ステージング環境起動」のようなアクションをGUIで定義可能

- Datadog/PagerDuty/AWS統合が箱で動く

- UIが洗練されていて非エンジニアにも優しい

Portの **弱み**:

- カタログデータがPortクラウドに保存される(ロックイン懸念)

- プラグインエコシステムはBackstage比でかなり狭い

- 深いカスタマイズはBackstageより制限的

**誰が選ぶべきか**: 50〜300人規模のエンジニアリング組織、早期導入が重要なところ、プラットフォームチームが2〜3人レベルのところ。

7. OpsLevel — サービスオーナーシップ

OpsLevelは2018年にカナダで創業したIDP SaaS。**サービスカタログ+スコアカード(品質グレード)** が核。

OpsLevelの差別化ポイントは **Maturity Rubric** だ。各サービスをA〜Fでグレード自動評価する:

- Aグレード: テストカバレッジ90%以上、SLO定義、ランブック存在、オンコールローテーション明示、OpenTelemetry計装

- Fグレード: オーナー不明、アラートなし、ドキュメントなし

このグレードは毎日自動再計算され、チーム別ダッシュボードに表示される。CTOが「なぜ我々のチーム平均がCなのか」を聞き始めると行動が変わる。

OpsLevelの **強み**:

- Rubricシステムが直観的で強力

- GitHub/Jira/PagerDuty/Datadog統合が深い

- サービスオーナーシップ追跡が業界で最も精緻(オーナー不在サービスを自動検出)

**弱み**:

- Backstageほどカタログ自体は柔軟ではない

- 価格が高め(シートあたり月30〜50ドル程度と報道)

- セルフサービスインフラアクションはPortより弱い

**誰が選ぶべきか**: 「うちの会社のサービス品質がバラバラ、まず測定から始めるべき」が核心問題の組織。

8. Cortex — エンジニアリング卓越性

CortexはOpsLevelと事実上同じ市場を見ている。両者は頻繁に比較され入札でぶつかる。Cortexは2019年米国創業でSeries Cまで進んだ。

CortexがOpsLevelと違う点:

- **スコアカードエンジンがより表現力が高い**。CQLという独自クエリ言語で任意の条件を定義可能

- **Initiative** 概念: 「四半期OKRで全サービスにOpenTelemetry導入」のようなキャンペーンをツール内で追跡

- **Eng Intelligence**: DORAメトリクス、デプロイ頻度、MTTRを自動収集してダッシュボード化

- AI駆動の **Cortex Copilot**: カタログ自然言語検索

**誰が選ぶべきか**: OpsLevelとほぼ同一。入札時にデモを試してチーム好みに合う方を選ぶべき。一般的にOpsLevelは「厳格なガバナンス」、Cortexは「柔軟なキャンペーン」寄りの印象。

9. Atlassian Compass — Jira/Confluenceとの統合

Atlassianが2023年12月にGAリリースした **Compass** はJira、Confluence、Bitbucketユーザーに直撃メッセージを送る。「既に弊社ツールを使っているのだからIDPも同じ場所で」。

CompassのデータモデルはBackstageの `catalog-info.yaml` と互換性がある(`compass.yml` というほぼ同一フォーマットを使用)。つまりBackstageからCompass、またはその逆への移行が容易だ。

Compassの **強み**:

- Jiraチケット、Confluenceページ、Bitbucket PRとの統合がネイティブ

- Atlassian Rovo(AI)統合により「このサービスを最後にデプロイしたのは誰か」を自然言語で問える

- 価格が合理的(シートあたり月額、Atlassianパッケージ割引)

- Scorecard機能内蔵

**弱み**:

- プラグインエコシステムはBackstage比で貧弱

- Atlassianエコシステム外との統合が弱い(GitHub、GitLab、PagerDutyなど可能だが一級市民ではない)

- セルフサービスアクション機能が弱い

**誰が選ぶべきか**: 既にAtlassianスタックを使う組織。「IDP導入決定」より「Atlassian決済追加」のほうが政治的に簡単なケースが多い。

10. Humanitec / Configure8 — 新興勢力

**Humanitec** はIDPという語より **Platform Orchestrator** を好む。核心は **Score** というワークロード仕様フォーマット(CNCF Sandboxプロジェクト)。Scoreは環境別Kubernetesマニフェストを自動生成するIaC抽象レイヤだ。

score.yaml — Humanitec/Score の例

apiVersion: score.dev/v1b1

metadata:

name: hello-world

containers:

hello:

image: nginx:latest

variables:

DB_HOST: ${resources.db.host}

DB_USER: ${resources.db.user}

resources:

db:

type: postgres

このファイル一つでdev/staging/prod環境のKubernetesマニフェスト+Helm+Terraformが全て生成される。セルフサービスインフラのバックエンドを作りたい時に強力だ。

**Configure8** はY Combinator出身の新規参入者。2024年GA。Portと似たカタログ+アクションモデルだが「より軽く、より意見が強い」をマーケティングメッセージとする。スタートアップ/スケールアップ市場を狙う。

**Effx** を覚えている人もいるだろうが、2022年にLinkedInに買収されその後LinkedIn社内IDPに吸収された。一時期IDP市場のダークホースだったが外部プロダクトとしてはもはや存在しない。

11. DORA / SPACEメトリクス — IDPが測定するもの

IDPが測定する中核指標は二つのフレームワークから来る。

**DORA (DevOps Research and Assessment) 4キーメトリクス**:

1. **Deployment Frequency**: どれだけ頻繁に本番デプロイするか

2. **Lead Time for Changes**: コードコミットから本番デプロイまでの時間

3. **Change Failure Rate**: デプロイが事故を引き起こす割合

4. **Mean Time to Recovery (MTTR)**: 事故から復旧までの時間

DORA 2024レポートは「Elite」グレード組織が1日複数回デプロイ、1時間未満のリードタイム、5%未満の障害率、1時間未満の復旧時間を示すと定義する。

**SPACEフレームワーク**(Microsoft Research, 2021):

- **S**atisfaction and well-being

- **P**erformance

- **A**ctivity

- **C**ommunication and collaboration

- **E**fficiency and flow

SPACEはDORAでカバーできない「開発者満足度」「フロー」「協業品質」を測定する。実際のIDPツールの採用パターン:

- **Cortex Eng Intelligence**: DORA自動収集 + SPACE一部

- **OpsLevel**: Maturity RubricがSPACEのPerformance/Efficiencyを代替

- **Port**: DORAダッシュボード内蔵

- **Backstage**: Tech Insights + 独自プラグインの組み合わせで自前実装

核心は **収集より定義が難しい** という点。「デプロイ1回」の定義がチームごとに異なる(PRマージ?カナリア開始?100%トラフィック?)。IDPツール導入でこの定義作業は消えない。

12. Backstage vs Port — セルフホスト vs SaaS

最も頻繁にぶつかる決定がBackstage(セルフホスト)対Port(SaaS)。五つの軸で比較する。

| 軸 | Backstage | Port |

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

| セットアップ時間 | 3〜6か月 | 1〜7日 |

| 運用コスト | プラットフォームチーム2〜5人必要 | シート購読料のみ |

| データロックイン | ほぼなし(セルフホスト) | 中(Portクラウド保存) |

| カスタマイズ | 無制限(コード) | 中(Blueprint + Action) |

| プラグイン数 | 200以上 | 60以上 |

| 価格(100人組織年間) | 人件費50〜100万ドル + インフラ | シートあたり月20〜50ドル |

**一般ガイド**:

- エンジニア50人未満 → RoadieまたはPort。セットアップコストが決定的

- 50〜300人 → Port、OpsLevel、Cortex、Compassのいずれか

- 300人以上 → Backstageセルフホスト + Spotify Portalまたは自前プラグイン

このルールに例外は常にある。30人のフィンテックがBackstageをセルフホストすることも(セキュリティ/ロックインポリシーのため)、1,000人のゲーム会社がPortを使うこともある(速度優先)。

13. 韓国(カラット、トス)/ 日本(サイバーエージェント、メルカリ)IDP事例

**韓国 — カラット (Karrot)**: カラットは2022年から自前のBackstageベースIDPを運用する。社内呼称は「Karrot Platform」または「DX Console」。`catalog-info.yaml` を全マイクロサービスに必須化し、SoundcheckスタイルのスコアカードでサービスSLO遵守、セキュリティパッチ適用、コスト可視性を測定する。2024年以降は自社LLMベースのカタログ検索を追加した。

**韓国 — トス (Toss)**: トスは社内で「トス開発者プラットフォーム」と呼ぶ自前IDPを運用する。初期にBackstageを評価したが最終的に自社構築を選択。理由は(1)金融業界のセキュリティ要件、(2)トスのモノレポ構造とカスタムビルドシステムがBackstage抽象と衝突したこと。自前カタログ、自前セルフサービスインフラ(Kubernetesネームスペース作成、RDS作成)、自前DORAダッシュボードを備える。

**日本 — サイバーエージェント CIU (CyberAgent group Infrastructure Unit)**: サイバーエージェントにはグループ全体に共通インフラを提供するCIUという組織がある。CIUはCycloudという自前IDPを運用、Kubernetes/OpenStackベースのマルチテナントインフラをグループ100社余りの子会社にセルフサービス提供する。外部SaaS IDPを採用しなかった理由は(1)多数の子会社を束ねる隔離要件、(2)コスト。

**日本 — メルカリ**: メルカリは2020年代初頭にBackstageを評価し、2023年に自社構築の「Microservices Platform」の一部として統合した。カタログは `catalog-info.yaml` 互換フォーマットを使うがUIはメルカリが自前React appで実装。Spinnaker、ArgoCD、Datadog、Sentry統合は自前プラグインで書いた。メルカリエンジニアリングブログに詳細記事シリーズがある。

共通パターン: **グローバルビッグテック/スケールアップはセルフホスト(または自社構築)比率が高く、100〜500人規模の韓国/日本スケールアップはSaaS(特にPort/OpsLevel)導入が急速に増加** している。

14. うちのチームはIDPを導入すべきか — 意思決定ガイド

5段階チェックリスト。

**ステップ1: 問題が存在するか?**

- 新規入社者の初回デプロイまで平均何日かかるか?(1週間超 → 問題)

- 「このサービスのオーナーは誰?」の問いに答えが出ないか?(YES → 問題)

- セキュリティパッチ適用SLAを守れないか?(YES → 問題)

- インシデント発生時にランブックを見つけるのに30分以上かかるか?(YES → 問題)

3つ以上該当ならIDP導入を検討すべき。2つ以下ならWiki整備で十分かもしれない。

**ステップ2: 組織規模マッチング**

| エンジニア数 | 推奨 |

|---|---|

| 〜30人 | Wiki + GitHub README + 自作スクリプトで十分。IDPコスト正当化困難 |

| 30〜80人 | PortまたはRoadie。セットアップ高速なSaaSが正解 |

| 80〜300人 | Port、OpsLevel、Cortex、Compass、Configure8のいずれか。入札進行 |

| 300人以上 | Backstageセルフホスト + Spotify Portal検討。プラットフォームチーム5人以上確保 |

**ステップ3: プラットフォームチーム人員**

IDPは「ツールを買えば終わり」ではない。カタログデータを充填し、スコアカードルールを定義し、ゴールデンパステンプレートを作り、開発者に使用法をトレーニングする人員が必要。**最低1.5名 (FTE)** が6か月以上専任しないと意味のある結果は出ない。

**ステップ4: カタログデータソース**

サービスメタデータをどこから取得するか?

- 既に `catalog-info.yaml` を使っている → Backstage/Compass/Roadieが自然

- 全情報がWiki/Confluenceに散らばっている → Portがマイグレーションツールが良い

- 全情報がJira/Confluenceにある → Compass

**ステップ5: 測定目標**

IDP導入後に測定するKPIを事前に決める:

- Time to First Deploy(新規入社者の初回デプロイまでの時間) — 30日 → 7日

- Service Owner Coverage(オーナー明示済みサービス比率) — 60% → 95%

- Scorecard Average — 平均グレードC → B

- Self-Service Action Adoption(セルフサービスで処理されたインフラ要求比率) — 0% → 40%

6か月後にこの数字が動かないなら導入失敗か、データ充填失敗か、どちらかである。

IDPは魔法ではない。**コンテキストとガバナンスをコードに移したもの** に過ぎない。ツール選択は二次的問題で、第一の問題は「弊社が何を標準と呼ぶか」を決める政治的合意である。この合意があればBackstageでもPortでもどのツールでも成功する。合意がなければどのツールを買ってもWikiが増えるだけで終わる。

参考 / References

- Backstage (CNCF) — https://backstage.io

- Backstage CNCF Graduation 発表 — https://www.cncf.io/announcements/2024/03/12/backstage-graduates/

- Spotify Portal for Backstage — https://backstage.spotify.com/

- Roadie — https://roadie.io

- Port — https://www.getport.io

- OpsLevel — https://www.opslevel.com

- Cortex — https://www.cortex.io

- Atlassian Compass — https://www.atlassian.com/software/compass

- Configure8 — https://www.configure8.io

- Humanitec — https://humanitec.com

- Score (CNCF Sandbox) — https://score.dev

- DORA — https://dora.dev

- DORA 2024 State of DevOps Report — https://cloud.google.com/devops/state-of-devops

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

- CNCF Platform Engineering Whitepaper — https://tag-app-delivery.cncf.io/whitepapers/platforms/

- Spotify Backstage 元発表 (2020) — https://engineering.atspotify.com/2020/03/announcing-backstage/

- Karrot Engineering ブログ — https://about.daangn.com/blog/

- Toss Tech ブログ — https://toss.tech

- CyberAgent CIU 発表資料 — https://developers.cyberagent.co.jp/blog/archives/category/infrastructure/

- Mercari Engineering ブログ — https://engineering.mercari.com/en/blog/

- platformengineering.org コミュニティ — https://platformengineering.org