AIが開発する時代にIDPを作る意味はあるのか？の続編として、今回は設計寄りの内容を扱います。
はじめに
前回の記事では、AIがコードを書く時代にIDPを作る意味について、「ポータルを開く頻度は減っても、組織固有のコンテキスト・アーキテクチャ標準・ガードレールとしての役割は失われない」という整理をしました。今回はその続きとして、実際にBackstageのカタログをAIエージェントが参照できるコンテキスト源として拡張していく際に、どのような設計判断が必要になるかを扱います。
具体的なコード例は本記事では扱いません(TypeScriptの実装やYAMLの詳細な書き方は試行錯誤の途上...)。代わりに、設計方面の判断軸を中心に整理します。
既存のカタログ設計をそのまま使えるか？
そのまま使わない方がいい、というのが私の考えです。理由を具体的なイメージで説明します。
Backstageのカタログは、もともと図書館の蔵書目録のようなものだとイメージしてください。Component、API、Resourceといったエンティティ種別は、「本棚に並んでいる、実際に貸し出せる本」を登録するための棚です。どのジャンルの本か、誰が管理しているか、他のどの本と関連しているか、といった情報が整理されています。
ここで扱われている「本」に共通するのは、実際に動いている、あるいはデプロイされているソフトウェア資産だという点です。オーナーがいて、ライフサイクル（企画中・運用中・廃止予定など）があって、他のサービスとの依存関係がある。これが従来のカタログの前提です。
一方、AIコーディングエージェントが読むルールやスキルは、性質がまったく違います。デプロイもされないし、稼働もしません。たとえるなら、本棚に挟んである「読み方メモ」や「付箋」のようなものです。中身は静的なテキストで、動くわけでも、リクエストを受けて処理をするわけでもありません。
この「付箋」を、間違って「本」の棚にそのまま並べてしまうとどうなるでしょうか。たとえば、プラットフォームチームが「本番稼働中のサービス一覧を検索する」ためにカタログを検索したとします。もし付箋（AIエージェント向けのルールファイル）まで同じComponent種別として登録されていたら、検索結果にそれらが混ざり込んでしまいます。「動いているサービスを探しているのに、実体のないルールファイルまで出てくる」という状態です。
これが積み重なると、カタログ全体の見通しが悪くなります。フィルタで絞り込んでも余計なものが混ざる、ダッシュボードの集計にノイズが入る、といった形で、じわじわと使いにくさが増していきます。「本」と「付箋」は、どちらもカタログという同じ本棚の仕組みに乗せる価値はあるものの、棚を分けて管理すべき別物だ、というのがここでの判断です。
ベストプラクティス案
専用のカタログ種別として独立させる
AIエージェント向けのルールやスキルは、既存のComponent種別の亜種として扱うのではなく、意味的に独立した種別として設計するのが妥当だと考えられます。ここでのポイントは、「独立した種別にする」ことと「既存のガバナンスの仕組みから切り離す」ことは別問題だという点です。オーナーシップ情報、ライフサイクル管理、検索の仕組みは既存のカタログ基盤にそのまま乗せつつ、種別としては別枠にする、という設計が筋がよさそうです。カタログを全社の唯一の情報源として保つという、Backstageがもともと持っていた思想を崩さずに拡張できます。
annotation namespaceを用途ごとに区切る
エンティティにメタデータを付与する際、既存のannotationと同じ名前空間に混在させると、後から「これはAIエージェント向けの設定なのか、それとも別の用途の設定なのか」の判別が難しくなります。用途を明確にした専用のnamespaceを切っておくと、以下のような情報を整理しやすくなります。
- どのAIエージェント（あるいはエージェントの種類）からの参照を許可するか
- 参照だけでなく操作（ツール実行）まで許可するか、その範囲はどこまでか
- どのdisciplines・categoriesに属するスキルか
こうした情報を専用のnamespace配下にまとめておくことで、将来的にAI活用のガバナンスルールが変わった際にも、影響範囲を特定しやすくなります。
公開範囲は既存の権限モデルの延長で管理する
社内全体に公開してよいスキルと、特定チームや特定エージェントに限定すべきスキルは、当然分けて考える必要があります。ここで新しい権限体系をゼロから作るのではなく、既存のBackstageの権限フレームワーク（誰がどのエンティティを見られるか、編集できるか）の延長として設計するのが現実的です。新しい概念を持ち込むほど、運用チームが覚えるルールが増え、形骸化しやすくなるためです。
段階導入は「読み取り専用・開発環境限定」から始める
AIエージェントにカタログへの書き込み権限を最初から与えるのはリスクが高い判断です。まずは読み取り専用の参照から始め、開発環境限定で運用しながら、どのような認証方式が適切か、どこまでのレート制限が必要か、監査ログにどの粒度の情報を残すべきかを見極める進め方が妥当です。書き込み権限や本番環境への適用は、この検証を経てから広げていく方が、後戻りのコストを抑えられます。
エージェントの乱立を避けるための一元管理
複数のチームがそれぞれ独自にAIエージェントを構築し、それぞれ異なる権限やツール接続を持たせてしまうと、組織全体としてはガバナンスが効かない状態になります。カタログを拡張する際は、「どのエージェントが」「どの情報に」「どこまでのツール権限で」アクセスできるかを、個々のエージェントの実装側に埋め込むのではなく、カタログ側で中央集権的に定義しておくことが望ましいと考えられます。
制約・注意点
- 本記事で挙げた設計判断は、まだ業界標準として固まったものではなく、各社・各コミュニティで議論が進行中の内容に基づく整理です。今後の議論の進展によって、より適した設計パターンが出てくる可能性があります。
- 書き込み権限やエージェントレジストリのような、より踏み込んだガバナンスの仕組みについては、組織の成熟度によって必要性が大きく異なるため、本記事の内容がそのまま当てはまるとは限りません。
まとめ
- 既存のComponentなどのエンティティ種別に、AIエージェント向けのルールやスキルを無理に混在させると、カタログの検索性が損なわれます。専用の種別として独立させつつ、ガバナンスの仕組みは既存のカタログ基盤に乗せるのが妥当な設計です。
- annotation namespaceを用途ごとに区切っておくことで、AIエージェント向けの設定を将来的にも見通しよく管理できます。
- 公開範囲・権限は新しい仕組みをゼロから作らず、既存の権限モデルの延長として設計するのが現実的です。
- 導入は読み取り専用・開発環境限定から始め、書き込み権限や本番適用は検証を経てから広げていくのが安全な進め方です。
- エージェントの乱立を防ぐには、権限やツール接続をカタログ側で中央集権的に管理する発想が重要になります。
参考リンク
- Port.io「Backstage Is Dead」（2026年4月・5月）
- Backstage GitHub Issue #33575「RFC: Introduce a new AIContext kind in the Software Catalog」（2026年3月）
- Nitin Jain「Turning Backstage into an AI-Ready Platform with MCP」（Medium、2026年3月）
注意事項
本ブログに掲載している内容は、私個人の見解であり、
所属する組織の立場や戦略、意見を代表するものではありません。
あくまでエンジニアとしての経験や考えを発信していますので、ご了承ください。