
はじめに
皆さんこんにちは。エーピーコミュニケーションズ ACS事業部亀崎です。
今年もやってまいりました、5月4日。2022年から毎年5月4日に記事を1つずつ投稿してまいりました。 (5月4日がなんだ?というのは最後になるとわかります)
- 2022年 AKSでDaprを使ってみる (3) App InsightsでTracing - APC 技術ブログ
- 2023年 Platform Engineeringのポイントは共同責任モデルと関心事の分離 - APC 技術ブログ
- 2024年 Backstage Kubernetes PluginでAKS 上のアプリケーション情報を表示しよう - APC 技術ブログ
- 2025年 GitHub Actionsのセキュリティ対策 - APC 技術ブログ
そして今年のテーマは「 Backstage New Frontend System (NFS)入門 」です。
それでははじめていきましょう。
Backstage New Frontend System(NFS)
2026年3月にAmsterdamで開催されたKubeCon EU 2026 / BackstageCON 2026 EUにおいて 「BackstageのNew Frontend SystemがまもなくGAになる」、と紹介されました。
ところで、New Frontend System(NFS)とはどういったものでしょうか? 今回はNFSのポイントを簡単に確認していきたいと思います。
New Frontend Systemの歴史
BackstageのNew Frontend Systemは、導入・利用を簡単にしようという構想のもと 2023年から開発されていたものです。
Backend側が先行して開発が進められ、New Backend SystemはすでにGAとなっており、Old Backend Systemはすでに削除されています。 そしてついに今回、Frontend側もGAのレベルに到達ということになります。
新しくBackstageのコードを生成した(create-appを実行した)場合、
2026年3月に公開された v1.49.0 以降デフォルトでNFSに対応したコードを生成するようになりました。
こうした意味で、すでにNFSがGAに準じた扱いになっていることがわかります。
New Frontend Systemとは
New Frontend Systemをひとことで言うと、 手続き的(imperative)な設定から宣言的(declarative)な設定への移行です。
以前の記事でもご紹介していますが、従来のBackstageの導入はコード生成を伴うものです。 Frontend Systemでは、以下のようにいくつものコードが生成され、 Pluginを追加する際には、それに対応したコードを利用者自身が追記する必要がありました。


コードで変更できるという点はカスタマイズが可能であることにつながり、 利用者が「 自分たちの欲しいものを、欲しい形で実現することができる 」ことから 拡張性に優れたフレームワークとして受け入れられていました。 しかし、拡張性が高い反面、導入のハードルが高くなり、その設定も面倒である ということが指摘されてきました。 このようにコードで記述することから従来のOld Frontend System(OFS)は 「 手続き的(imperative) 」な設定と言われています。
この状況を改善するために開発が進められたのがNew Frontend System(NFS)です。 NFSの場合、Pluginを導入するためのコードを書く必要はありません。 (yarn add plugin-name コマンドでinstallする必要はあります)
NFSではPluginは自動的に取り込まれます。そしてその動作は以下のような形式で app-config.yaml 内に設定します。 この点が「 宣言的(declarative) 」な設定と言われている理由になります。
(app-config.yamlにおける Frontend Systemの設定例)
app: extensions: - <id>: attachTo: id: <parent-id> input: <input-name> disabled: <true/false> config: <extension-specific-config>
各Pluginには拡張してよい機能(拡張ポイント)が定義されており、 利用者がその機能を拡張したい場合は、利用者自身が機能拡張のための Extension Pluginを記述することで 機能を追加、または上書きすることもできます。 この場合はPluginコードを書かなければなりませんが、 すでに必要とするExtension PluginがOSSとして公開されていることが多いため、 利用者自身がコードを記述する必要はあまりなく、Extension Pluginの導入と それにあわせた app-config.yaml の定義だけで利用することができるようになります。
このように機能拡張を容易にするフレームワークの定義と、app-config.yamlによる カスタマイズ設定が New Frontend Systemのポイントになります。
まとめ
2023年から時間が経過しましたがやっとNew Frontend Systemがデフォルトと なる日がきました。これによって今まで面倒だなと思っていたBackstageに 関する導入作業がだいぶ楽になっていくと思います。
Backstage 1.50.x 時点の新旧のコード生成内容が比較できるよう、 それぞれ生成した結果をGitHub上に公開してあります。
興味のある方は以下のリポジトリからご確認ください。
今回は新規に作成した場合の内容になりますが すでにBackstageを立ち上げられている方々が気になるのは、 移行はどうなるのか?これまでコードで設定していた内容は反映できるのか? といった点になると思います。私も移行について検討していますが、 ちょっと考え方を変えないといけない部分があることを確認しています。 このため移行については別途お伝えできればと思っています。 ( ちょこっとBackstage でその移行を実現しようと思います)
さらに、Backstageでは Dynamic Plugin Loading という、さらに導入を簡単にする方式の 開発が進んでいます。こちらについても引き続き情報を提供できればと考えております。
最後に
弊社では、Backstageのマネージドサービスである「PlaTT」 を提供しています。 開発者ポータルの前提となる Platform Engineeringの導入支援も行っております。 開発者体験を向上し、開発生産性を高めたいとご検討の皆様、ぜひ弊社までご相談ください。
それでは最後に。(これを書きたいがために5月4日に記事を書いているというわけです)
May (the) force(4th) be with you.