Backstageとは｜開発者ポータルの仕組みと導入判断・案件動向

Backstageとは何か

Backstageは、社内に散らばったサービス情報・ドキュメント・運用ツールを1つのWeb UIに集約するための、開発者ポータル構築用フレームワークです。公式サイトも「Backstage is an open source framework for building developer portals」と、製品ではなくフレームワークだと明記しています（Backstage公式ドキュメント）。

ここが最初の分岐点になります。インストールすれば翌日から全社が使える、という類のものではありません。

Spotify発、CNCFに寄贈されたOSS

もともとはSpotify社内で開発され、社内ツールの入口を統一する目的で育てられました。2020年9月8日にCNCFへ受け入れられ、2022年3月15日にIncubatingへ昇格しています（CNCF Backstageプロジェクトページ）。本記事執筆時点（2026年9月）で公式ページから確認できるステータスはIncubatingで、Graduatedには達していません。成熟度は今後変わりうるため、社内提案に使う際は公式ページで最新のステータスを確認してください。この前提があるため、成熟度を前提条件として社内に説明する場面では、このステータスを正確に伝えておくと話が早く進みます。

2026年3月にはCNCFがBackstageのドキュメンタリーを公開しており、プラットフォームエンジニアリング文脈での参照例として挙がる機会は増えています。

「ポータル」であって「プラットフォーム」ではない

Backstageが提供するのは入口とカタログです。コンテナ実行基盤、CI/CDパイプライン、シークレット管理、監視といった土台そのものは含みません。

つまり、下回りが無い状態でBackstageだけ立てても、表示する中身がありません。KubernetesやTerraformで基盤が組まれていて、ArgoCDなどのデプロイ経路が既にある。そこへ「見える化と入口の統一」を足すのがBackstageの役割です。

Q. 小規模なチームでも導入する意味はありますか？

A. サービス数が10未満、メンバーが5名前後なら、READMEとスプレッドシートで足りるケースが多いです。情報の所在を人に聞いて解決できる規模では、ポータルの維持コストのほうが上回りがちです。

2つの「IDP」：Internal Developer PortalとPlatformの違い

IDPという略語は2つの意味で使われており、ここを混同すると設計の話が噛み合いません。結論から言えば、Backstageは前者（Portal）にあたります。

Portalは、Platformが持つテンプレート生成・環境払い出し・デプロイ状況といった機能を、開発者が操作するためのインターフェースとして機能します。Platform側が未整備のままPortalを先に作ると、リンク集にしかなりません。順番が大事です。

Backstageの中核機能

標準で備わるのは、Software Catalog、Software Templates、TechDocs、そしてプラグインの拡張機構です。それぞれが解決する課題は別物なので、分けて理解しておくと導入範囲を決めやすくなります。

Software Catalog：サービスの戸籍

マイクロサービス、ライブラリ、データパイプライン、Webサイト、MLモデルなどを一覧管理する機能です。各リポジトリにcatalog-info.yamlという記述ファイルを置き、Backstageがそれを収集してカタログを作ります。

効くのは、オーナー不明のサービスが増えてきた組織です。「このAPIは誰が持っているのか」を探す時間が消えます。マイクロサービス構成で運用サービス数が数十を超えてきた段階で、導入効果が実感されやすくなります。

Software Templates：新規作成の標準化

新しいサービスやリポジトリを、組織のベストプラクティスに沿った雛形から起こす機能です。Scaffolderとも呼ばれます。

テンプレートにCI設定・Lint設定・監視の初期設定・オーナー情報まで含めておくと、新規リポジトリが作られた瞬間から社内標準に乗った状態になります。GitHub Actionsのワークフロー雛形を同梱する構成は定番です。

TechDocs：ドキュメント・アズ・コード

Markdownで書いたドキュメントをリポジトリ内に置き、ポータル上で閲覧できるようにする機能です。カタログのエンティティと紐づくため、サービスを開いたらそのサービスの設計書が読める状態を作れます。

ドキュメントがWikiに置かれてコードと乖離していく問題への回答が、この「コードと同じリポジトリで管理する」方式です。

検索とプラグインエコシステム

横断検索に加えて、Kubernetes、CI/CD、監視系など各種ツールと連携するプラグイン群が公開されています。OpenTelemetryや監視基盤の情報をカタログ上に並べる構成もとれます。

ただしプラグインの品質・保守状況は一律ではありません。コミュニティ製プラグインを組み込む場合は、更新頻度とメンテナの状況を必ず確認してから採用を決めてください。ここを軽視すると、Backstage本体のバージョンアップ時に足を引っ張られます。

Q. 全機能を最初から入れるべきですか？

A. Software Catalogだけで始めるのが現実的です。テンプレートとTechDocsは、カタログが埋まって参照されるようになってからで間に合います。

導入の流れと、実運用までの期間目安

手順そのものは公式のガイドに沿えば迷いません。時間を食うのは、技術ではなく情報を集めて登録する工程です。

1. Node.js環境を用意し、公式CLIでアプリの雛形を生成する

2. GitHubなどのソース管理と認証連携を設定する

3. 主要サービスにcatalog-info.yamlを配置し、カタログへ取り込む

4. Kubernetes・CI/CDなど必要なプラグインを組み込む

5. Software Templatesを整備し、新規作成の導線を作る

6. 社内へ展開し、利用状況を見ながら中身を足す

ローカルで最小構成を起動するだけなら1日で終わります。問題はその先です。エンジニア50〜100名・サービス数50前後の組織で、カタログにオーナーと依存関係を入れ切るまでに2〜4週間程度、テンプレート整備と社内展開まで含めると着手から実運用に乗るまで2〜3か月を見込むケースがあります。

この期間は公開された調査データに基づく数字ではなく、専任1名＋兼務数名の体制で進めた導入プロジェクトを想定した目安として読んでください。組織のサービス数、既存基盤の整備度、オーナー情報が既に揃っているかで大きく変動します。片手間の兼務のみで進める場合は、さらに時間がかかると見ておいたほうが安全でしょう。

つまずきやすい3点

• catalog-info.yamlを誰が書くか決まっていない。プラットフォームチームが全部書くと数百件で破綻します。各サービスのオーナーに書いてもらう運用へ、早い段階で切り替える必要があります。

• 認証・権限設計を後回しにする。全社展開の直前で詰まる典型です。RBAC（役割ごとに閲覧・操作範囲を制御する仕組み）の要件は初期に洗い出しておきます。

• バージョンアップ追従の担当が不在。Backstageは更新頻度が高く、自前ビルドである以上、依存関係の更新は自分たちの仕事になります。

運用コストと「誰も使わないポータル」問題

Backstageの導入失敗で最も多いのは、技術的な失敗ではありません。立ち上げたが使われず、情報が古くなり、やがて放置されるという形です。

維持に必要な体制

自前運用である以上、継続的なコストが発生します。ビルドパイプラインの維持、依存パッケージの更新、プラグインの互換性確認、カタログ情報の鮮度管理。これらの担い手が明示的に決まっていない導入は、半年から1年で形骸化しやすい傾向があります。

商用ディストリビューションが存在するのは、まさにこの負担が理由です。Red Hatも「複雑なビルド処理や依存関係の更新、プラグインのサポートに悩まされる代わりに、開発者体験の改善に集中できる」と、商用版の価値をその点に置いています（Red Hat Developer Hub）。

形骸化を防ぐ運用設計

• カタログ情報の更新を、人の善意ではなくCIの自動更新に寄せる

• 月次で「オーナー未設定のエンティティ数」を数え、ゼロに近づける

• ポータルにしか無い情報を1つ作る。デプロイ状況やオンコール担当など、そこを見ないと分からない情報があると自然に開かれます

• 新規サービス作成をテンプレート経由に限定し、利用が業務フローに組み込まれる状態を作る

3番目が効きます。「便利だから使ってください」では人は来ません。

よくある失敗と対策

失敗の多くは、順番の誤りに起因します。基盤が未整備のままポータルだけ先行させる。オーナー運用を決めずに一括登録する。プラグインを盛りすぎてアップグレードできなくなる。いずれも、最小構成で1つの課題を解いてから広げるという進め方で回避できます。

自前OSS運用か、商用・SaaSか

選択肢は大きく3つあります。組織の体力と、ポータルに求めるカスタマイズ度合いで決まります。

商用ディストリビューションの代表例がRed Hat Developer Hubです。Backstageをベースに、ArgoCD・Keycloak・Kubernetes・Tektonなどのプラグインをサポート付きで組み込んだ構成になっています。SaaS型としてはPort、Cortex、Roadieといった製品名が比較検討で挙がります。

判断の軸はシンプルです。ポータルそのものを差別化要素にしたいなら自前、情報の集約が目的ならSaaSで十分というケースが多くなります。Backstageのコードに手を入れる予定が無いのであれば、自前ビルドの維持コストを払う理由は薄くなります。

フリーランス案件でBackstageはどう現れるか

結論として、「Backstageエンジニア募集」という形で単体の職種として切り出された案件は、公開案件を見る限り多くありません。首都圏中心のフリーランスエージェント各社の公開案件募集ページを確認した範囲では、プラットフォームエンジニアリングやSRE・DevOps案件の要件欄に、担当技術の1つとして名前が挙がる形が中心でした。公開案件は全体の一部であるため、この見え方は観測ベースの傾向として捉えてください。

要件文での出方

典型的なのは、Kubernetes・IaC・CI/CDの経験が主要件として並び、その下に「開発者ポータル（Backstage等）の構築経験があれば尚可」と添えられるパターンです。つまり、Backstage単体のスキルで参画するのではなく、SREやプラットフォーム領域の実務経験を土台にして、そのうえに乗る差別化要素として機能します。

案件を探すときは、ツール名で検索するより職種タグで絞ってから要件文を読むほうが早いです。フリコンのインフラエンジニア案件一覧やKubernetes案件一覧から、要件欄に開発者体験・内製化・プラットフォームといった語がある案件を拾っていく形になります。

単価はどう考えるか

まず公開案件ベースの目安から押さえます。フリコンでSRE・DevOps領域の単価を整理した記事では、Kubernetes運用とIaC実装の実務3〜5年で月85〜105万円、SLO/SLI設計や障害対応をリードできる層で月110〜130万円というレンジを示しています。首都圏中心の主要エージェント数社の公開案件募集ページを、週4〜5日稼働の準委任案件に絞って確認した数字です。

非公開案件はこれと分けて考えてください。個別条件で上振れするケースがありますが、再現性の前提にはできません。詳しいレンジと参入目安は「SREフリーランスの単価相場｜DevOps案件の月額レンジと参入目安」で整理しています。

Backstageの経験そのものが単価を押し上げるというより、プラットフォーム全体の設計を任せられる層に入れるかどうかで帯が変わる、という見方のほうが実態に近いでしょう。自分が今どのレンジで見られるのかを把握したい場合は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。

参入ルート

いきなりBackstage構築案件を狙うのは現実的ではありません。順序としては、コンテナ基盤とIaCの実務を固める、CI/CDとデプロイ経路の設計を経験する、そのうえで社内向けの標準化・テンプレート化に関わる、という積み上げになります。職種転換の進め方は「エンジニアの職種転換｜開発からSRE・データ職へ移る順序と段階」も参考にしてください。

導入前チェックリスト

社内で検討に入る前に、以下を確認しておくと判断が早くなります。

6項目のうちYesが4つ未満なら、まずはPlatform側の整備か、SaaS型での小さく始める検討を優先したほうが無駄がありません。

まとめ

Backstageは、社内の開発者ポータルを自前で組み立てるためのフレームワークであり、導入の成否は技術よりも運用の担い手を決められるかどうかで分かれます。

• 本体はOSSのフレームワーク。完成品の製品ではなく、ビルドと継続運用が前提

• CNCFでの成熟度はIncubating（2022年3月15日昇格）。Graduatedには未到達

• 中核はSoftware Catalog、Software Templates、TechDocsの3つ

• 最小構成の起動は1日、実運用に乗せるまでは専任1名体制で2〜3か月が目安

• 自前運用が重い場合は、Red Hat Developer Hub等の商用ディストリビューションやSaaS型が選択肢

• 案件では単体要件になりにくく、プラットフォーム・SRE領域の実務に乗る差別化要素として機能する

向き不向きを一行にすると、実行基盤が整っていて運用担当を置ける組織には向き、まず情報集約だけ実現したい組織ではSaaS型のほうが始めやすい、という切り分けになります。

次に動くなら、まずローカルで最小構成を起動し、自分の関わるサービスを3つほどカタログ登録してみてください。そこで見えてくる「情報が揃わないサービス」の存在こそが、ポータル導入で最初に解くべき課題です。

参照した一次情報は以下のとおりです。

• Backstage公式ドキュメント（What is Backstage?）

• CNCF Backstageプロジェクトページ

• Red Hat Developer Hub 製品ページ