この記事の概要
- Gartner 予測通り 2026年末には 80% の組織が Platform チームを設置する見込み
- IDP(Internal Developer Platform)導入企業はオンボーディング期間 2× 短縮・本番障害 50% 削減の実績
- Backstage(開発者ポータル)+ Kratix(オーケストレーション)の組み合わせが Kubernetes 環境の定番構成になりつつある
背景・概要
「Platform Engineering は DevOps の名前を変えただけでは?」——そんな声をよく聞く。
しかし実際には、両者には明確な違いがある。
DevOps が「開発と運用の協力関係」を指すのに対し、Platform Engineering は「開発者が自己完結できる内部基盤(IDP)をプロダクトとして構築・提供すること」だ。
インフラの複雑さを Platform チームが吸収し、アプリケーション開発者には「ゴールデンパス」(正解の道筋)だけを提供する。
2026年現在、この考え方は急速に広まっている。
Gartner は 2027年末までに 80% のソフトウェア組織が Platform チームを設置すると予測し、実際に IDP を導入した企業からは以下のような定量的な改善が報告されている。
- 新入エンジニアのオンボーディング期間: 2× 短縮
- 本番環境のインシデント数: 50% 削減
- デプロイ頻度: 大幅向上(組織によって差はあるが、数倍の事例も)
- 開発者満足度スコア: 向上
詳細解説
IDP の基本構造
IDP は「開発者がセルフサービスでインフラを使えるようにする仕組み」だ。典型的な構成を図解するとこうなる。
開発者
│
│ セルフサービスで操作
▼
┌─────────────────────────────────────────┐
│ 開発者ポータル(Backstage) │
│ ・サービスカタログ │
│ ・スキャフォルダー(テンプレートから作成) │
│ ・TechDocs(ドキュメント) │
│ ・Kubernetes クラスタ管理 UI │
└──────────────────┬──────────────────────┘
│
│ API 呼び出し
▼
┌─────────────────────────────────────────┐
│ プラットフォーム API レイヤー(Kratix) │
│ ・Promise(インフラの約束事を定義) │
│ ・ワークフロー管理 │
│ ・マルチクラスタ orchestration │
└──────────────────┬──────────────────────┘
│
│ プロビジョニング
▼
┌─────────────────────────────────────────┐
│ インフラレイヤー │
│ Kubernetes / Crossplane / Terraform │
│ AWS / GCP / Azure / オンプレ │
└─────────────────────────────────────────┘
Backstage ——開発者ポータルの事実上の標準
Backstage は Spotify が開発し OSS として公開した開発者ポータルフレームワークで、現在は CNCF のインキュベーティングプロジェクトとして成熟している。
2026年現在、Fortune 500 を含む数千の組織で利用されている。
主なコンポーネントは以下の通りだ。
Software Catalog(サービスカタログ)
組織内の全サービス・API・ライブラリの一覧。誰がオーナーか、依存関係はどうか、ドキュメントはどこかを一箇所で管理する。
# catalog-info.yaml(各リポジトリに配置)
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
name: payment-service
description: 決済処理マイクロサービス
annotations:
backstage.io/techdocs-ref: dir:.
github.com/project-slug: myorg/payment-service
pagerduty.com/service-id: PXXXXXX
tags:
- java
- payment
- critical
spec:
type: service
lifecycle: production
owner: group:payment-team
system: e-commerce-platform
dependsOn:
- component:user-service
- resource:payments-db
Scaffolder(スキャフォルダー)
「新しいマイクロサービスを作りたい」という開発者が、承認済みテンプレートから数クリックでリポジトリ・CI/CD・監視設定・ドキュメントをまとめて作成できる仕組みだ。
# template.yaml(サービス作成テンプレートの例)
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
name: microservice-template
title: 新規マイクロサービス作成
description: Go / Python / Java で新しいサービスを作るゴールデンパス
spec:
parameters:
- title: サービス情報
required: [name, language, owner]
properties:
name:
title: サービス名
type: string
language:
title: 言語
type: string
enum: [go, python, java]
owner:
title: オーナーチーム
type: string
ui:field: OwnerPicker
steps:
- id: create-repo
name: GitHub リポジトリ作成
action: publish:github
input:
repoUrl: github.com?repo=${{ parameters.name }}&owner=myorg
- id: create-catalog-entry
name: カタログ登録
action: catalog:register
Kratix ——プラットフォーム API レイヤー
Kratix は Backstage の「裏側」で動く OSS のプラットフォームオーケストレーターだ。
特徴は Promise という概念で、「この環境を作ったら、こういうリソースを自動的に用意する」という約束をコードとして定義できる。
Kubernetes 環境での典型的な使い方は「Platform クラスタ(Kratix が動く)」と「Worker クラスタ(実際のサービスが動く)」を分離する構成だ。
# PostgreSQL データベースの Promise 定義例
apiVersion: platform.kratix.io/v1alpha1
kind: Promise
metadata:
name: postgresql
spec:
api:
apiVersion: marketplace.kratix.io/v1alpha1
kind: postgresql
spec:
properties:
dbName:
type: string
storageGB:
type: integer
default: 10
tier:
type: string
enum: [dev, staging, production]
workflows:
resource:
configure:
- apiVersion: platform.kratix.io/v1alpha1
kind: Pipeline
spec:
steps:
- name: provision-postgres
image: registry.kratix.io/postgresql-pipeline:v1
開発者が「PostgreSQL が欲しい」とリクエストすると、Kratix が Worker クラスタに適切な設定でデータベースをプロビジョニングする。
開発者は Kubernetes の YAML を直接書かなくてよい。
# 開発者が発行するリクエスト(シンプル!)
apiVersion: marketplace.kratix.io/v1alpha1
kind: postgresql
metadata:
name: my-app-db
spec:
dbName: myapp
storageGB: 20
tier: production
Backstage + Kratix の統合
2 つのツールは役割が明確に異なるため、組み合わせることで相乗効果が出る。
開発者体験のレイヤー構造
Backstage(ポータル)
└── 開発者が見る UI・カタログ・テンプレート
Kratix(API レイヤー)
└── Backstage のテンプレートから呼び出される
データベース・Redis・証明書・Namespace 等を
自動プロビジョニング
Kubernetes / クラウドサービス
└── 実際のインフラ
Backstage の Scaffolder から Kratix の Promise を呼び出す連携は、REST API または Kubernetes カスタムリソース経由で実装できる。
段階的な導入ロードマップ
IDP は一度に全部作ろうとすると失敗する。
段階的に導入するのが現実的だ。
Phase 1(1〜3ヶ月):可視化
既存サービスを Backstage のカタログに登録するだけでも、「誰が何を持っているか分からない問題」を解消できる。
まずカタログから始める。
Phase 2(3〜6ヶ月):ゴールデンパスの整備
よく使われるパターン(新規サービス作成・DB プロビジョニング)をテンプレート化する。
Platform チームが「何を標準化すべきか」を開発者へのヒアリングから特定することが重要だ。
Phase 3(6〜12ヶ月):セルフサービス化
Kratix などのオーケストレーションレイヤーを導入し、開発者が Platform チームの手を借りずにインフラをリクエスト・取得できるようにする。
実務での活用方法
最初は 1 チームから
IDP を全社同時展開しようとすると必ず頓挫する。
まず 1 つのプロダクトチームに使ってもらい、フィードバックを集めながら磨いていく。
「プラットフォームはプロダクトだ」という意識が大切だ。
Platform チームの落とし穴を避ける
Platform チームがボトルネックになるパターンがある。
何でも Platform チームを通さないといけない状態は、IDP のゴールであるセルフサービス化の真逆だ。
「ガードレールは設けるが、道は自由に選べる」設計を意識する。
計測できるものを KPI にする
「デプロイまでの時間」「新規サービスのオンボーディング時間」「Platform 経由でプロビジョニングされたリソースの割合」など、測定可能な KPI を最初に設定しておく。
それがない IDP 投資の正当化は難しい。
まとめ
Platform Engineering は「インフラの複雑さを Platform チームが引き受け、アプリケーション開発者が本来の仕事に集中できるようにする」取り組みだ。
Backstage + Kratix の組み合わせは、Kubernetes 環境での IDP 構築における有力な選択肢として 2026年に実用段階に達した。
まず Backstage のソフトウェアカタログだけでも試してみよう。
組織内のサービス一覧を整備する作業そのものが、Platform Engineering の起点になる。
小さく始めて、開発者の反応を見ながら育てていく——それが失敗しない IDP の作り方だ。
参考リンク
– IDP 2026 完全ガイド(Calmops)
– Kratix 公式サイト
– Platform Engineering in 2026(DevOps Tales)
– Backstage 公式ドキュメント
– Platform Engineering Tools TOP20(Spacelift)


コメント