Golden Pathは「文化を実装する」もっとも強力なレバー
Platform EngineeringコミュニティでGolden Pathという言葉が定着して数年、2026年のいま「どのテンプレートを提供しているか」で組織のエンジニアリング文化が露骨に読み取れる時代になった。Spotifyが最初に提唱したこの概念は「舗装された道を歩けば迷わず目的地に着ける」比喩で、技術選択の疲労と意思決定コストを取り除き、開発者が本質的な問題にフォーカスできる環境を作る仕組みである。
Golden Pathが従来のテンプレートと決定的に違うのは、「強い意見」が埋め込まれている点だ。使う言語、使うテストフレームワーク、使うCIパイプライン、使うObservabilityスタック、使うSecret管理、すべてが組織として「これで行く」と定めた形で提供される。単なるボイラープレート削減ではなく、プラットフォームチームが責任を持つ運用環境のフロントエンドそのものである。
Backstage Software Templates: 変数置換とActionsの力
Backstage Software TemplatesはBackstageのScaffolderプラグインで提供される機能で、template.yamlにパラメータとアクションのシーケンスを記述する。パラメータはJSON Schemaで定義され、UIは自動生成される。アクションは事前定義されたfetch:template、publish:github、catalog:register、github:actions:dispatchなどを組み合わせるほか、カスタムActionをTypeScriptで追加できる。
最小のテンプレートは以下のような構造になる。
```yaml apiVersion: scaffolder.backstage.io/v1beta3 kind: Template metadata: name: nodejs-microservice title: Node.js Microservice (Golden Path) spec: owner: platform-team type: service parameters: - title: Service Info properties: name: { type: string, pattern: "^[a-z][a-z0-9-]+$" } owner: { type: string, ui:field: OwnerPicker } tier: { type: string, enum: [tier1, tier2, tier3] } steps: - id: fetch action: fetch:template input: url: ./skeleton values: { name: ${{ parameters.name }} } - id: publish action: publish:github input: repoUrl: github.com?owner=acme&repo=${{ parameters.name }} - id: provision-secrets action: vault:provision input: path: services/${{ parameters.name }} - id: register action: catalog:register input: repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }} ```
この型に沿ってテンプレートを増やしていくのが定石だが、実務では「何を標準にするか」の議論に工数の7割が消える。技術的な書き方は30分で覚えられる。
Cookiecutter: 軽量で移植性が高い選択肢
Backstageを導入していない組織、あるいはIDPの外でも使いたいケースでは、Cookiecutterが選ばれる。Python製でJinja2テンプレートを処理する、2013年から続く老舗ツールだ。2026年時点でも現役で、GitHub組織テンプレートやCI経由で呼び出すユースケースが健在である。
Cookiecutterの強みは「GitHubリポジトリがそのままテンプレートになる」単純さと、cookiecutter.jsonによる入力プロンプトの明快さ。hooks/pre_gen_project.pyとpost_gen_project.pyで事前検証・事後処理を書けるため、「生成後に必ずgit initしてpre-commitを設定する」「生成名がNGリストに含まれたら中断する」といった厳格な運用が可能だ。
ただしCookiecutter単体ではGitHubリポジトリ作成・Secret登録・Catalog登録といった「テンプレート生成の後処理」は扱えない。Backstage Actions相当の仕組みを自前で書く必要がある。結果、Backstageが既にあるなら統合した方が楽、まだないなら当面Cookiecutterで繋ぐ、という割り切りが多い。
Nx Plugins: モノレポ時代のGolden Path
モノレポ文化が定着した組織ではNxが強力な選択肢になる。Nrwl（現Nx）のNx Pluginは、`nx g @acme/workspace:microservice my-service`のようなジェネレータを提供し、既存モノレポに新モジュールを追加する形でGolden Pathを実装する。
Backstageが「独立リポジトリを生成する」のに対し、Nxは「巨大モノレポに新しいprojectを追加する」アプローチのため、以下の特性が生まれる。一つ目は、共通ライブラリ・ビルド設定・CI設定が再利用可能なこと。二つ目は、project.jsonの型付きでタスク・タグ・依存関係を宣言できること。三つ目は、nx affectedによって影響範囲のみビルド・テストが走ることだ。
Nx Pluginジェネレータの骨格は、`@nx/devkit`の`Tree`APIを使ってファイル生成・workspace更新を行うTypeScriptコードになる。Backstage Templatesよりプログラマブルで、条件分岐や動的生成が自然に書ける反面、非モノレポ組織では導入メリットが薄い。
CI統合: 「テンプレートがCIを持って生まれる」こと
Golden Pathの価値の半分はCI統合にある。2026年の標準構成は概ね以下のどれかだ。GitHub Actionsのreusable workflow、GitLab CI includes、CircleCI orbs、Tekton Pipelines/ChainsのClusterTask。共通するのは「CIの実装詳細をテンプレート利用者から隠蔽する」原則である。
テンプレート生成直後に、.github/workflows/ci.ymlは数行で済むようにしたい。
```yaml name: CI on: [push, pull_request] jobs: build: uses: acme/workflows/.github/workflows/nodejs-tier1.yml@v2 with: service_name: ${{ github.event.repository.name }} secrets: inherit ```
実体のnodejs-tier1.ymlには、lint・type check・unit test・SAST（SemgrepまたはCodeQL）・SBOM生成（Syft）・コンテナイメージビルド・Cosign署名・SLSA provenance生成・ArgoCDへのmanifest更新PR作成が全部入っている。利用者はこれを知らなくていい。
Secret自動プロビジョニング: ゼロタッチが唯一の正解
Golden Pathが形骸化するもっとも多い理由が「Secretの手動設定」である。テンプレートでリポジトリは作れても、DATABASE_URLやAWSクレデンシャルの払い出しが手動だと、結局人間のチケットが必要になり、scaffoldのメリットが霞む。
- 年の推奨構成は、HashiCorp VaultあるいはAWS Secrets ManagerとKubernetesのExternal Secrets Operatorの組合せだ。Backstage ActionでVaultに専用path（`kv/services/${name}`）を作成・policy付与し、GitHub Actions側はOIDCでVaultにauthenticateする。DB本体はCrossplaneまたはTerraform CloudでIaC払い出しされ、接続文字列がVaultに自動登録される。利用者側は`vault:kv/services/my-service`をKubernetesマニフェストで参照するだけで済む。
Opinionの埋め込み: 強制と説得の配分
Golden Pathの成否を決めるのは技術ではなく「どこまで強制し、どこから選ばせるか」の線引きだ。強制してよい項目は、セキュリティ要件（SAST・SBOM・署名）、ログ形式、メトリクスエクスポート方式、ヘルスチェックエンドポイントなど、全社横断で統一しないと運用が壊れるもの。選ばせるべき項目は、DBのスキーマ、API設計、ドメイン固有のライブラリ選択など、プロダクトチームの裁量に属するもの。
実務では「推奨と例外申請」の構造が機能する。Tier 1サービスはテンプレート外の技術選択にPlatform Review Boardの承認を要する、Tier 2は届け出のみ、Tier 3は自由、といった段階だ。これをScorecardで可視化すると、逸脱が自然に炙り出される。
Contract Design: PMとエンジニアの橋渡し
Golden Pathはプラットフォームチーム単独では作れない。プロダクトマネージャとエンジニアの間にContract Designが必要になる。具体的には以下の要素が合意されるべきだ。
テンプレートが保証するSLO（ビルド時間、初回デプロイ完了時間）、テンプレート変更のDeprecation期間、Breaking Changeの通知プロセス、サポートチャネルとレスポンスSLA、使用率のKPI（採用率・満足度・不満点）、そしてテンプレート廃止の判断基準。これらを「Platform Product Spec」としてドキュメント化し、四半期ごとにレビューする運用が、2026年のベストプラクティスになっている。
Golden Pathは一度作って終わりではない。言語バージョン更新、脆弱性対応、新しい組織ポリシー反映で、常に生きて変化する製品である。その意識を持てるかどうかが、Platform Engineeringの実装成熟度を左右する。