はじめに
みなさん、こんにちは。エーピーコミュニケーションズ ACS事業部 亀崎です。
先日『Backstage Templateがもたらす開発プラットフォームの変革』というタイトルで ブログを投稿させていただきました。
Backstage Scaffolder Template（以下Backstage Template）は Backstage の基本機能の１つで、ひな形等を利用して リポジトリやクラウドリソースなどを初期化、設定更新するツールです。 Backstage Templateを利用して開発者の認知負荷を低減できる、ということを記事の 中で紹介させていただきました。
同様の機能を持つものとして GitHub Templateというものがあります。
GitHub Templateもリポジトリの初期化設定を簡略化してくれるものですが、Backstage Templateと どういった違いがあるのでしょうか？今回はこの違いをご紹介していきたいと思います。
それぞれの機能の概要
GitHub Template
GitHub Templateはその名の通り、GitHub 上の既存リポジトリをテンプレートとして指定し、 それをベースに新しいリポジトリを開始する機能です。
この機能のメリットは以下のようなものです。
- GitHub の UI 上でチェックを入れるだけで簡単に作成できる。
- コミット履歴を汚さずにクリーンな状態で開始できる。
これに対してデメリットは次のようなものです。
- 変数の置換ができません。ファイル内のプロジェクト名などを自動で書き換える機能はありません。
- 単一リポジトリのみでの完結です。 GitHubリポジトリの設定や外部サービス（クラウド設定など）との連携は別途実施する必要があります。
Backstage Scaffolder Template
Backstage Scaffolder Template（Backstage Template）は、Backstage上でユーザーからの入力を受け取り、 定義されたステップ（Action）を順次実行するツールです。
Backstage Templateのメリットは次のようなものです。
- 高度な変数置換が可能です。ユーザーが入力したサービス名やオーナー名を、リポジトリのファイル内の変数へ動的に埋め込めます。
- マルチステップで自動化できます。 「GitHubリポジトリ作成」→「テンプレート出力」→「リポジトリの設定」→「カタログ登録」といった一連のワークフローを1クリックで完結することができます。
- エコシステムの連携ができます。 Terraform、ArgoCD、など、ソフトウェアの立ち上げに必要な周辺設定も自動化の対象に含められます。
対してデメリットは以下のものが挙げられます。
- template.yaml（アクションを定義するためのYaml） を記述する必要があり、導入・メンテナンスに工数がかかる。
両者の比較
このようにリポジトリの雛形（ボイラープレート）を作成する際、Backstage の Scaffolder と GitHub の Template 機能はよく比較されますが、その性質は大きく異なります。
| 特徴 | GitHub Template | Backstage Scaffolder |
|---|---|---|
| 役割 | リポジトリ構成の「コピー」 | 開発環境一式の「プロビジョニング」 |
| 動作原理 | 既存リポジトリの複製 | 定義されたワークフローの実行 |
| 柔軟性 | 低（ファイル構成は固定） | 高（入力値による動的な内容変更） |
| 自動化範囲 | リポジトリ作成のみ | リポジトリ作成と周辺環境の自動設定 |
使い分けの指針
それではこの両者はどのように使い分けたらよいでしょうか。 どちらを採用すべきかは、単なる機能差だけでなく、 「開発者にどこまでのプロセスをセルフサービス化させたいか」という組織戦略によって決まります。
A: GitHub Template が適しているケース
GitHub Templateが適しているケースは 「スピード感とシンプルさ」を重視するフェーズ です。
- プロジェクトの多様性が高い: サービスごとに言語やフレームワークがバラバラで、共通化できるワークフローが「フォルダ構成」くらいしかない場合。
- 管理コストを最小限にしたい: Backstage 本体の運用保守（Node.jsのアップデートやプラグイン管理）にリソースを割けない少人数のチーム。
- 「まずは雛形があればいい」という段階: リポジトリさえできれば、あとのCI/CD設定やクラウド連携は各自が手動、あるいは使い慣れたスクリプトで行う文化である場合。
B: Backstage Scaffolder が適しているケース
対して Backstage Templateが適しているケースは 前回の記事でもご紹介したような 「ガバナンスと開発者体験（DevEx）」を重視するフェーズ です。
- マイクロサービス・マルチリポジトリ構成: 新しいサービスを頻繁に立ち上げる必要があり、リポジトリ作成から本番デプロイまでのリードタイムを短縮したい場合。
- 情報の集約（カタログ管理）が必須: リポジトリを作って終わりではなく、そのサービスのオーナーが誰で、どのAPIを公開しているのかを自動的に Backstage Catalog へ登録し、可視化したい場合。
- セルフサービス化によるSRE/プラットフォームチームの負荷軽減: インフラのプロビジョニングや権限申請などを、開発者がチケットを切らずに自分で完結できるようにしたい場合。
意思決定のチェックリスト
以下の項目に多くチェックがつく場合は、Backstage Scaffolder の導入価値が非常に高いと言えます。
- [ ] リポジトリ作成後に、毎回手動で書き換える箇所（プロジェクト名等）が複数ある
- [ ] CI/CDの設定ファイル（GitHub Actions等）を毎回別のリポジトリからコピペしている
- [ ] サービス作成時に、SREやインフラ担当者に「権限付与」や「リソース作成」の依頼が必要
- [ ] 誰がどのリポジトリを管理しているのか、一覧化・可視化ができていない
- [ ] 組織全体で「推奨される技術スタック」を固めていきたい
ハイブリッド構成
GitHub TemplateとBackstage Templateの特性の いいとこどり をするハイブリッド構成をすることも可能です。
- ソースコードの雛形は、更新やテストが容易な GitHub Template で管理する。
- リポジトリの設定や外部連携 は、Backstage Template で管理する。
Backstage Template のアクションの中には fetch:template だけでなく、
fetch:plain という「ファイルをそのままコピーする」機能もあります。
これを利用して、
「コードの中身は GitHub Template から取得し、プロジェクト名などの置換やカタログ登録、クラウド連携だけを Backstage が担う」
という役割分担が可能です。
この構成をとることで、テンプレートの中身（ソースコード）を修正したいだけの時に、
複雑な template.yaml を触る必要がなくなり、ひな形のメンテナンス性が劇的に向上します。
おわりに
GitHub Template と Backstage Scaffolder は、一見似ているようでいて、その設計思想は大きく異なります。
- 「リポジトリという箱」が欲しいだけなら GitHub Template
- 「動くサービス環境一式」が欲しいなら Backstage Scaffolder
まずは GitHub Template から始め、組織が拡大して「手動での設定変更」や「情報の分散」が課題になってきた タイミングで Backstage への移行、あるいはハイブリッド構成への拡張を検討するのが、 最もスムーズなステップかもしれません。
自社の開発文化やチームの成熟度に合わせて、最適な「最初の一歩」を選択してみてください。
最後に。
弊社では、Backstageのマネージドサービスである「PlaTT」 を提供しています。
開発者ポータルの前提となる Platform Engineeringの導入支援も行っております。
開発者体験を向上し、開発生産性を高めたいとご検討の皆様、ぜひ弊社までご相談ください。
