社内開発者プラットフォーム(IDP) 2026 — Backstage / Port / OpsLevel / Cortex / Compass / Roadie 徹底比較

「プラットフォームエンジニアリングは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を検討する理由:

Backstageは良いが運用人員がいない
6か月かかるセットアップを1週間に短縮したい
カタログデータは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キーメトリクス:

Deployment Frequency: どれだけ頻繁に本番デプロイするか
Lead Time for Changes: コードコミットから本番デプロイまでの時間
Change Failure Rate: デプロイが事故を引き起こす割合
Mean Time to Recovery (MTTR): 事故から復旧までの時間

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

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

Satisfaction and well-being
Performance
Activity
Communication and collaboration
Efficiency 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