Software Catalog

カタログは 2 層 - 自動で増える一覧と人が書く定義

サービスが数十を超えると、障害のたびに「誰が持っていて、何に依存しているか」を人に聞いて回る時間が生まれます。Datadog の Software Catalog はこの問いに答える台帳で、公式ドキュメントでは Internal Developer Portal (IDP) の「Catalog」として整理されています (2026 年 9 月時点・出典: Catalog)。台帳に載る条件は 3 つで、Datadog がテレメトリから検出したとき、利用者が定義ファイル (Entity Definition) で宣言したとき、Backstage や ServiceNow などの外部から取り込んだときです。つまり「観測データから自動で増える層」と「人が書き足す層」の 2 層構造で、前者が網羅性を、後者が所有者や文書のような観測からは出てこない情報を担います。この分担を知っていれば、「入れたのに持ち主が空欄」が仕様どおりで、埋めるのは定義ファイルの仕事だと分かります。

自動で入るのは APM、USM、RUM が見つけたサービス

既定で台帳を埋めるのは APM、Universal Service Monitoring (USM)、RUM の 3 つです。APM は計装したアプリのトレースからサービスと依存関係を描き、USM はコードに手を入れず eBPF でリクエスト数 / エラー / 所要時間を検出して依存を結び、RUM のアプリはフロントエンドアプリとして載ります (2026 年 9 月時点・出典: Set Up Catalog)。ログ、ホスト / コンテナ / ネットワーク / プロセスの指標からも取り込めますが、これは DD_SERVICEタグを検索して拾う方式で、公式はタグが整備されている場合に限るよう注意しています。タグの値が揃っていなければ、同じサービスが別名で 2 行になります。各サービスには span.type から決まる型 (Web / DB / Cache / Serverless function / Custom) が付き、絞り込みの軸になります。

定義ファイルに何を書くのか

人が足す層の器が定義ファイルで、Kubernetes 風の YAML で書き、台帳の正と位置づけられています (2026 年 9 月時点・出典: Set Up Catalog)。スキーマには v3.0 / v2.2 / v2.1 / v2.0 の 4 版があり、v3.0 はシステム / キュー / データストアなど複数の種類 (kind) を扱え、複数チームの所有と依存の手動宣言に対応します (同時点・出典: Entity Model)。要点は 1 つで、定義の name を統合サービスタグ付けの service タグと完全一致させることです。一致しなければ観測データと定義が結び付きません。登録経路は画面、Git に置いてソースコード連携で同期 (変更は数分で反映)、自動化の 3 つです。定義ファイルをサービスのリポジトリに同居させ、レビューを通して更新する形が、所有者情報を古くさせない方法です。

カタログの画面で何が見えるか

台帳は一覧を眺めるだけの道具ではありません。公式ドキュメントはカタログのビューとして Ownership / Reliability / Performance / Security / Costs / Software Delivery / Relationships / Infrastructure の 8 つを挙げます (2026 年 9 月時点・出典: Catalog)。

同じ台帳を 8 つの切り口で引ける意味は、障害対応と組織運営の両方で 1 つの名簿を使える点にあります。依存グラフのサービスからはそれが動くインフラ資源へ直接移れ、インフラ資源の収集はインフラ監視の契約者なら無料と明記されています。ダッシュボードには「Developer Portal」データソースがあり、所有者や tier ごとにエンティティ数を集計するウィジェットも置けます。

APM のサービスページとは役割がどう違うか

カタログで 1 つのサービスを選ぶと APM のサービスページに移ります。公式はサービスを「同じ仕事をするプロセスの集合」と定義し、サービスページにはサービスヘルス、モニターの状態、Watchdog の洞察、依存関係、リソース一覧、デプロイなどが並ぶと説明しています (2026 年 9 月時点・出典: Service Page)。サービスヘルスはモニター、インシデント、Watchdog の信号を 1 つの状態 (Critical / Warning / Ok) にまとめます。役割の違いは時間軸です。サービスページは「このサービスは今どうか」を答え、カタログは「このサービスは何で、誰のもので、何に依存するか」を答えます。障害対応では Ownership で連絡先を取り、サービスページで症状を見る往復になります。カタログに出るスパンの要約とサービス統計は最長 30 日の保持で、それより長い分析はメトリクス側で行う前提です (同時点・出典: Catalog)。

Backstage、ServiceNow、スコアカードとの位置づけ

Backstage や ServiceNow CMDB の台帳は作り直さずに使えます。Backstage はプラグインか記述ファイルの取り込み (API / Terraform / GitHub) の 2 通り、ServiceNow は CI テーブルの定期クエリで同期します (2026 年 9 月時点・出典: Set Up Catalog)。価値は各行に観測データが結び付く点です。カタログの上に載るのがスコアカードで、Production Readiness / Observability Best Practices / Documentation & Ownership の 3 組が既定で、全エンティティを 24 時間ごとに合否評価し Slack へ配信できます (同時点・出典: Scorecards)。所有者未記入のサービス数を毎日出せます。IDP 全体はカタログ、スコアカード、セルフサービスアクション、エンジニアリングレポートの 4 部品です (同時点・出典: IDP)。

料金はどう見るか - 単独の単価は公開表に無い

Software Catalog には、2026 年 8 月時点の公式料金ページに独立した SKU の記載がありません。本記事では単価を書かず、確認は Datadog Pricing の公開価格表に委ねます。押さえる点は 2 つです。ひとつは、台帳を自動で埋める材料が APM / USM / RUM のテレメトリであり、それぞれの製品の課金が土台になることです。もうひとつは、Relationships や Infrastructure ビューで使うインフラ資源の収集が、インフラ監視の契約者には無料と公式ドキュメントに明記されていることです (2026 年 9 月時点・出典: Catalog)。費用対効果は「新しい SKU を買うか」ではなく、既に払っている APM やインフラ監視のデータをどれだけ台帳として活かせるか、で測ります。SKU ごとの積み上げの読み方は料金体系の読み解き方を参照してください。本記事は課金の仕組みを解説するものです。具体的な単価や料金は Datadog 公式の料金ページで確認してください。

持ち主不明のサービスを潰す 3 段の運用順

カタログを入れただけでは「持ち主不明」は減りません。減るのは、次の順で運用を組んだときです。

順番が逆だと壊れます。定義ファイルを先に書いても、テレメトリ側の service の値が揃っていなければ結び付かず、所有者を書いたのに観測データが空の行と、観測データはあるのに所有者が空の行が並びます。1 段目を飛ばさないことが、この製品で最も費用の安い改善です。3 段まで回ると、SLO の担当や本番準備度の点検も「サービスごとに責任者がいる」前提で組めるようになり、台帳は一覧表から運用の土台に変わります。無いと障害の最初の 10 分が「誰に聞くか」で消え、あると最初の 1 分で連絡先と runbook が開く、というのがカタログの効きどころです。