開発ツール12分で読める

内部開発者プラットフォーム入門——Backstage vs Port vs Cortex徹底比較

開発ツールオープンソースエンタープライズ
加木谷 直俊ソース記事を見る

「Kubernetesのマニフェストを書き、Terraformでインフラを構築し、ArgoCD でデプロイし、Datadogで監視し、PagerDutyでアラートを受け取る」——現代の開発者が扱うべきツールとコンテキストは爆発的に増加している。Gartnerの調査（2025年）によれば、平均的なエンタープライズ開発者は15以上の異なるツールを日常的に切り替えており、この「認知負荷（Cognitive Load）」が生産性の最大のボトルネックになっている。

この問題を解決するのがIDP（Internal Developer Platform：内部開発者プラットフォーム）だ。IDPは、開発者が必要とするすべてのインフラ操作を単一のセルフサービスポータルに統合し、プラットフォームエンジニアリングチームが裏側の複雑さを抽象化する。2026年現在、Gartnerは上位のエンジニアリング組織の80%が2027年までにIDPを導入すると予測している。

IDPとは何か

プラットフォームエンジニアリングの台頭

プラットフォームエンジニアリングは「開発者のための開発者」チームだ。DevOpsの「You Build It, You Run It（作った人が運用する）」の理念は正しかったが、すべての開発者にインフラの専門知識を求めるのは現実的ではなかった。

IDPは以下の要素で構成される。

以下の図は、IDPの典型的なアーキテクチャを示しています。

内部開発者プラットフォームのアーキテクチャ。開発者ポータル、サービスカタログ、テンプレート、スコアカードの4層構造

IDPの4つの柱

  1. サービスカタログ: 全マイクロサービス、API、インフラリソースを一覧化。オーナーシップ、依存関係、ドキュメントを集約
  2. セルフサービステンプレート: 新規サービスの作成、環境構築、データベースのプロビジョニングをボタンクリックで実行
  3. スコアカード/ガードレール: セキュリティ、品質、コンプライアンスの基準をサービスごとに可視化
  4. ドキュメント統合: API仕様書（OpenAPI）、Runbook、ADR（Architecture Decision Records）を一元管理

主要IDPツール比較

項目BackstagePortCortex
提供元Spotify → CNCFPort (イスラエル)Cortex (米国)
ライセンスApache 2.0 (OSS)商用SaaS商用SaaS
ホスティングセルフホストSaaSSaaS
サービスカタログ○ (Software Catalog)○○
テンプレート○ (Software Templates)○ (Self-Service Actions)○ (Scaffolder)
スコアカード△ (プラグイン)○ (Scorecards)○ (Scorecards)
プラグインエコシステム200+ (最大)API統合中心統合数中程度
初期構築コスト高い (セルフホスト)低い (SaaS)低い (SaaS)
カスタマイズ性非常に高い中程度中程度
料金無料 (インフラ費のみ)$0〜/月 (Free〜Enterprise)要問合せ
大規模導入実績Spotify, Netflix, ExpediaZoom, Miro, LegalZoomDropbox, Indeed, TripAdvisor

Backstage — OSSのデファクトスタンダード

Backstageは2020年にSpotifyがOSSとして公開し、2022年にCNCFのIncubatingプロジェクトに採用された。2026年現在、CNCFのGraduatedプロジェクトへの昇格が議論されている。

強み:

  • 200以上のコミュニティプラグインによる圧倒的な拡張性
  • React + Node.jsで構築されており、フロントエンド開発者が容易にカスタマイズ可能
  • GitHub Copilot、PagerDuty、Datadog、ArgoCD等との豊富な統合
  • CNCF傘下の安定したガバナンス

弱み:

  • セルフホストのため、構築・運用に2-3名のプラットフォームエンジニアが必要
  • 初期セットアップが複雑（TypeScriptの知識必須）
  • スコアカード機能は標準では弱く、プラグインに依存
# Backstage アプリの作成
npx @backstage/create-app@latest
cd my-backstage-app
yarn dev

Port — SaaS型のリーダー

Portは「コードゼロ」で IDPを構築できるSaaS型プラットフォームだ。UIベースでサービスカタログのスキーマを定義し、スコアカードやセルフサービスアクションを設定できる。

強み:

  • セットアップが高速（数時間で基本的なIDPを構築可能）
  • ノーコードでカタログスキーマ・スコアカードを定義
  • APIファーストの設計で、既存のCI/CDパイプラインから操作可能
  • Free tierで小規模チームは無料利用可能

弱み:

  • カスタマイズの自由度はBackstageに劣る
  • SaaS依存（データを外部に送信する必要がある）
  • プラグインエコシステムはBackstageほど充実していない

Cortex — エンタープライズ向け

Cortexは、特にサービスの品質・成熟度の可視化に強みを持つIDPだ。

強み:

  • スコアカード機能が最も充実（セキュリティ、可用性、ドキュメント完備度を細かく評価）
  • CTO/VP of Engineeringレベルのダッシュボードが充実
  • インシデント管理との統合が深い

弱み:

  • 価格が非公開（エンタープライズ向けの高価格帯）
  • カスタマイズ性はBackstageに劣る

IDP導入の効果

以下の図は、IDP導入による開発者体験の改善効果を示しています。

IDP導入効果の定量データ。環境構築時間97%削減、オンボーディング90%短縮など

定量的な効果

Gartnerおよび各社の公開データに基づく平均的な効果を整理する。

指標IDP導入前IDP導入後改善率
新規環境構築時間2週間30分97%削減
新メンバーのオンボーディング1カ月3日90%短縮
デプロイ頻度月2回日次15倍
インシデント対応時間2時間30分75%短縮
開発者がインフラ対応に費やす時間30%5%83%削減

Spotifyの事例

Backstageの生みの親であるSpotifyでは、2,000以上のマイクロサービスと2,000名以上の開発者を管理するためにBackstageを開発した。導入後の効果は以下のとおり。

  • 新規マイクロサービスの作成が数分で完了（以前は数日）
  • サービスのオーナーシップが100%追跡可能に
  • 「誰に聞けばいいかわからない」問題が解消
  • API仕様書の整備率が90%以上に向上

IDP選定ガイド

チーム規模別の推奨

チーム規模推奨ツール理由
10-50名Port (Free)構築コストゼロ、SaaSで即導入
50-200名Port or Backstageコスト vs カスタマイズ性のトレードオフ
200-1000名Backstageプラグインエコシステムとカスタマイズ性が活きる
1000名+Backstage + 専任チーム大規模エンタープライズ向けのフルカスタマイズ

Dockerを活用したBackstageのローカル検証

BackstageはDocker Composeで手軽に検証できる。

# docker-compose.yml
version: '3'
services:
  backstage:
    image: backstage/backstage:latest
    ports:
      - "7007:7007"
    environment:
      POSTGRES_HOST: db
      POSTGRES_PORT: 5432
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: backstage

日本ではどうなるか

日本での採用状況

日本のプラットフォームエンジニアリングは急速に注目度が上がっている。

  • メルカリ: Backstageをベースにした内部開発者ポータルを構築・運用。日本最大級の事例
  • サイバーエージェント: 独自のIDPを内製。複数事業部にまたがるサービスカタログを統合
  • LINE (LY Corporation): 大規模マイクロサービス環境の管理にBackstageを検討・試行
  • 楽天: プラットフォームエンジニアリングチームを設立し、IDP構築を推進中

コミュニティ

  • Platform Engineering Meetup: 日本最大のプラットフォームエンジニアリングコミュニティ。月次で勉強会を開催
  • CloudNative Days Tokyo: 毎年プラットフォームエンジニアリングのトラックが設けられている
  • Backstage JP Users Group: Backstageの日本語コミュニティが2025年に発足

日本特有の課題

  • SIerとの関係: 日本企業ではSIerにインフラ運用を委託しているケースが多く、セルフサービス化のモチベーションが低い場合がある
  • 英語ドキュメント: Backstageのドキュメントは英語のみ。日本語化は有志による翻訳が進行中だが、まだ不完全
  • 組織文化: 「自分で環境を作る」文化がない組織では、IDPを導入しても利用率が低いケースがある。トップダウンでの推進とチャンピオンユーザーの育成が重要

まとめ：IDP導入のアクションステップ

IDPは「あったら便利」ではなく、エンジニアリング組織のスケーラビリティの基盤だ。以下のステップで導入を進めてほしい。

  1. 認知負荷の可視化: 開発者が日常的に使っているツール数、環境構築にかかる時間、インフラ関連のSlack質問数をカウントする
  2. スモールスタート: まずサービスカタログから始める。全サービスのオーナーシップ、ドキュメント、依存関係を一覧化するだけでも大きな価値がある
  3. ツール選定: チーム規模50名以下ならPort（SaaS）、50名以上でカスタマイズが必要ならBackstage（OSS）を推奨
  4. Golden Path（推奨パス）の設計: 「新規マイクロサービスの作成」「データベースのプロビジョニング」など、最も頻度の高い操作からテンプレート化する
  5. KPIの設定: 環境構築時間、オンボーディング期間、デプロイ頻度、開発者満足度（NPS）を定期的に計測し、IDP投資のROIを経営層に報告する

プラットフォームエンジニアリングは「DevOpsの次のフェーズ」であり、IDPはその実装基盤だ。開発者の認知負荷を下げ、本来の仕事——優れたプロダクトの開発——に集中できる環境を作ることが、エンジニアリング組織の競争力の源泉となる。

この記事をシェア

XはてブLinkedIn

「開発ツール」カテゴリの記事

「開発ツール」の記事をもっと見る

関連記事

新着記事