Backstage基礎：カタログエンティティを理解しよう

皆様新年あけましておめでとうございます。日本一（？）のBackstage推し、ACS事業部亀崎です。今回は2026年最初の投稿です。新年最初ということで、いつものアイキャッチも特別バージョンとして背景に初日の出を入れてみました（Generated by Gemini）。いかがでしょうか。

そして新年最初の投稿ということで、あらためてBackstageの基礎知識、カタログの種別についてお伝えしたいと思います。

Backstageとは

まずはBackstageについて簡単にご紹介したいと思います。Backstageとは、音楽配信サービスの Spotify が開発効率を上げるために開発し、現在はオープンソース（CNCF寄贈）として公開されている「内部開発者ポータル（Internal Developer Portal, IDP）」を構築するためのプラットフォームです。

一言でいうと、バラバラに散らばった開発ツールやドキュメントを「一つの画面」に集約し、開発者が迷わず作業できるようにするための「開発者のための入り口」です。

このブログでも2023年に紹介しています。

techblog.ap-com.co.jp

Backstage のカタログEntity

さきほど『バラバラに散らばった開発ツールやドキュメントを集約し』と説明しました。この集約対象のデータをBackstageではカタログ、集約してくるデータの１つ１つのデータをカタログエンティティと呼んでいます。

カタログエンティティは「Core（コア）」「Organizational（組織）」「Others（その他）」の３つの種別グループにわけられ、その中に複数の種類が定義されています。

その１つ１つを見ていきましょう。

Core Entity

ソフトウェアの機能的な構成要素を表す中心的な種別です。

Domain

用語、ビジネス目的、ドメインモデルなどを共有するシステムの集合です。大規模な組織において、Domain Entityは関連するシステムを「境界づけられたコンテキスト（Bounded Context）」としてグループ化します。これにより、ビジネス上の文脈に基づいた整理が可能になります。

Domain Entityの例としては「決済（Payments）」ドメイン、「検索（Search）」ドメイン、「広告（Ads）」ドメインになります。

Domain Entityは別のドメインの子（subdomain）になることができ、組織構造に合わせた階層管理が可能です。

System

特定の機能を実行するために協力し合うコンポーネントとリソースの集合体です。 System Entityは複雑なソフトウェアを抽象化するためのレベルとして機能します。外部の利用者に対しては、内部の実装詳細（個々のコンポーネントやリソース）を隠蔽し、公開されているAPIのみを見せることで結合度を下げることができます。

System Entityの例としては「プレイリスト管理システム」というシステムが、更新用サービス（Component）、クエリ用サービス（Component）、保存用データベース（Resource）を内包し、外部には1つのRPC API（API)を公開する、といった構成が考えられます。

Component

ソフトウェアの個別の構成要素を表す、カタログで最も中心的な種別です。開発者が「ソフトウェアの1単位」と見なすものを指し、通常はソースコードと密接に結びついたデプロイ可能な成果物を指します。 Component Entityとしてはバックエンドサービス、ウェブサイト、ライブラリ、データパイプラインなどが想定されます。

Resource Entityや他のComponentとの関係を依存（dependsOn）として関係づけることができます。また、他のComponent Entityが提供するAPIを消費（consumes）したり、自身がAPIを提供（provides）したりします。

Resource

コンポーネントを動作させるために必要なインフラストラクチャを指します。実行時に必要な物理的または仮想的な資産をモデル化することで、リソースの利用状況（フットプリント）を可視化し、それらに関するツールを提供できるようにします。 Resource Entityとしては、データベース（BigTable, SQLなど）、メッセージキュー（Pub/Sub）、ストレージ（S3バケット）、CDN、Kubernetesクラスターなどを表すことを想定しています。

API

コンポーネント間の境界（インターフェース）を定義するエンティティです。 API Entityはエコシステム内で既存の機能を検索・発見するための主要な手段であり、コンポーネント間の抽象化層として機能します。インターフェースの形式として、OpenAPI, AsyncAPI, GraphQL, gRPC などの機械読み取り可能な形式で定義されたものとなります。公開範囲（パブリック、制限付き、プライベート）を持つことができ、Backstage上でのドキュメント化や検索をサポートします。

Organizational Entity

組織構造を定義するための種別です。

Group

Group は、チーム、事業部、あるいは特定の関心を持つ集団などの組織単位を表します。組織の階層構造（ツリー構造）を形成し、ソフトウェアの「所有権（Ownership）」をチーム単位で管理するために重要です。グループは紐づけられた認証機構の組織単位と同期させることが可能です。

グループはparentOf（および逆方向のchildOf）関係を通じて階層的に他のグループと関連付けることができます。

User

User はBackstageを利用できるユーザーを表します。 Backstage エコシステム内での認証と紐付けられ、エンティティの所有者として個人の責任を明確にするために使用されます。

memberOf（および逆方向の hasMember）関係を通じてグループと紐付けられます。

Other Entity

Template

Templateは新しいソフトウェアを「標準化された手順で生み出すための金型」で、ソフトウェアを新規作成（スキャフォールディング）する際の手順やパラメータを定義するエンティティです。開発者が新しいコンポーネントを作成する際のウィザード画面（Scaffolder などのプラグイン）を動かすための定義ファイルとなっています。

Location

Location は、カタログデータの取得先を参照するための「マーカー」として機能するエンティティです。GitHubなど、カタログデータを外部ソースから取得する際の位置情報を保持します。

登録例

Others EntityのTemplateやLocationは少し特殊な用途なので、ここでは割愛しますがCore EntityやOrganizational Entityの実際の登録例は次のようなイメージになります。

このように組織内のシステムをわかりやすく登録していくとができます。

PlaTTのご紹介

ソフトウェア開発資産のカタログ管理として有効なBackstageですが、OSSということもあり、ツールの立ち上げ、必要な機能の追加やアップデート等の管理が面倒なものです。また、導入して終わりというものでもなく、使い方を探求することでその能力を100％発揮できるようになるものも多いです。こういうところを１つ１つ解消するのって面倒ではありませんか？そんな面倒さを解消するのが、私たちが提供するBackstageのManaged Service「PlaTT」です。