Backstageエンティティのアイデンティティ、kindフィールドを完全に理解する（ComponentからResourceまで）

6月 29, 2026

—

こんにちは！今日は、Backstageの核中の核であり、すべてのメタデータの出発点とも言えるcatalog-info.yamlファイルのkindフィールドについて深く掘り下げていきます。🚀

Backstageを設定する際に最初に遭遇するこのフィールドが正確に何を意味し、どのような種類があるのかを知ることで、サービスカタログを設計する視野が完全に変わるでしょう。💡

🏗️ kindフィールドとは何か？

Backstageのソフトウェアカタログは、すべてのリソースを「エンティティ(Entity)」という単位で管理します。このとき、kindフィールドは「このエンティティがどのような種類のモノなのか？」を定義する最も基本的な分類体系です。

オブジェクト指向プログラミングに例えるなら、kindはクラス(Class)のようなもので、私たちが作成する個々のYAMLファイルはそのクラスから生成されたインスタンス(Instance)だと理解すると簡単です。😊

🌟 主要なkindタイプ総まとめ

Backstage標準モデル(Core Entities)でサポートされている代表的なkindについて詳しく見ていきましょう。

1. kind: Component (ソフトウェアの最小単位) 🧩

最もよく使われるタイプです。コードリポジトリにある実際のサービス、ウェブアプリ、ライブラリなどを表します。

役割: ビジネスロジックを実行する実際のソフトウェアを定義します。
例: マイクロサービス、フロントエンドのReactアプリ、共通ユーティリティライブラリ。

2. kind: API (システム間の対話窓口) 🔌

サービスが外部に公開するインターフェースを定義します。

役割: REST、gRPC、GraphQLの仕様を管理し、サービス間の契約を明示します。
特徴: ComponentがこのAPIを「提供(Provides)」したり「消費(Consumes)」したりする関係を設定できます。

3. kind: System (関連するリソースの集合) 🏰

複数のコンポーネントとAPIを一つの論理的な単位にまとめる役割を果たします。

役割: 「決済システム」、「注文管理システム」のように、大きな単位のビジネス機能を表します。
利点: 複雑なアーキテクチャを抽象化し、一目で把握できるようにします。

4. kind: Resource (インフラおよび外部サービス) 💾

ソフトウェアが動作するために必要な物理的/論理的なリソースを指します。

役割: データベース(PostgreSQL, Redis)、S3バケット、クラウドクラスターなどを定義します。
管理: どのサービスがどのDBを使用しているかを追跡する際に役立ちます。

👥 組織構造を定義するkind

Backstageはソフトウェアだけでなく、そのソフトウェアを作成する人も管理します。

5. kind: Group & kind: User 👥

User: 個々の開発者やチームメンバーを表します。
Group: チーム、本部、同好会など、組織単位を表します。
接続: Componentのownerフィールドに特定のGroupを指定することで、「このサービスはどのチームが担当しているのか？」を明確にします。🎯

🛠️ catalog-info.yamlの例で見るkind

実際のファイルではどのように使われるか見てみましょう。

YAML

apiVersion: backstage.io/v1alpha1
kind: Component        # ここがその部分です！
metadata:
  name: order-service
  description: 주문을 처리하는 핵심 마이크로서비스
spec:
  type: service
  lifecycle: production
  owner: team-alpha    # Groupエンティティに接続
  system: order-management-system

上記の例では、kind: Componentは、このファイルがソフトウェアコンポーネントを定義していることを宣言しています。もしこのファイルがAPIの仕様であれば、kind: APIに変わっていたでしょう？

❓ kindを正確に設定することがなぜ重要なのか？

UIレンダリング方式の決定: Backstageはkindに応じて、画面に表示するプラグインやタブを異なるように構成します。（例：APIはSwaggerビューアを表示し、ComponentはCI/CDの状況を表示する）
関係図(Graph)の形成: エンティティ間のつながりを正しく形成するには、それぞれの役割を正確に定義する必要があります。
検索およびフィルタリング: 数千のリソースの中から必要なものを見つける際、kindは最も強力なフィルターとなります。🔍

🏁 結論: kindはエンティティのアイデンティティです！

Backstageのkindフィールドは単なる文字列ではなく、そのリソースの性質と責任、そして他のリソースとの関係を規定するアイデンティティのようなものです。

皆さんのインフラとソフトウェアをBackstageモデルに合わせて適切に分類すること（Kind設計）が、優れた開発者ポータルを構築する第一歩です。🚀