銀行でプラットフォームエンジニアリングをやる — Backstageとガバナンスの結婚

[従来]  サービスごとに異なる構成
  点検 = サービス数 x 点検項目数  (手作業、漏れの可能性)

[IDP]   ゴールデンパスへの収斂
  点検 = テンプレート数 x 点検項目数  (コードレビューで代替可能)
  + テンプレート違反の自動検知 (ポリシーエンジン)

# template.yaml — 金融規制要件を内蔵した新規サービステンプレート
apiVersion: scaffolder.backstage.io/v1beta3
kind: Template
metadata:
  name: secure-spring-service
  title: Spring Bootサービス (セキュアデフォルト内蔵)
  description: セキュリティスキャン、監査ロギング、暗号化が既定で有効な標準サービス
  tags:
    - recommended
    - java
    - compliance-ready
spec:
  owner: platform-team
  type: service

  parameters:
    - title: サービス基本情報
      required:
        - serviceName
        - ownerGroup
        - dataClassification
      properties:
        serviceName:
          title: サービス名
          type: string
          pattern: '^[a-z0-9-]+$'
        ownerGroup:
          title: 所有組織 (人事システムの部署コードと連携)
          type: string
          ui:field: OwnerPicker
        dataClassification:
          title: データ等級 (資産管理報告に使用)
          type: string
          enum:
            - public
            - internal
            - personal-credit    # 個人信用情報 — 追加統制を自動適用
          default: internal

  steps:
    # 1) スケルトン生成 — セキュリティ設定が既に含まれたコードベース
    - id: fetch
      name: 標準スケルトン生成
      action: fetch:template
      input:
        url: ./skeleton
        values:
          serviceName: ${{ parameters.serviceName }}
          owner: ${{ parameters.ownerGroup }}
          dataClass: ${{ parameters.dataClassification }}

    # 2) データ等級がpersonal-creditなら暗号化モジュールを強制注入
    - id: inject-crypto
      name: フィールド暗号化モジュール注入
      if: ${{ parameters.dataClassification === 'personal-credit' }}
      action: fetch:template
      input:
        url: ./addons/field-encryption
        targetPath: ./src

    # 3) 社内Git作成 + ブランチ保護 + CODEOWNERS自動設定
    - id: publish
      name: リポジトリ作成
      action: publish:gitlab
      input:
        repoUrl: gitlab.bank.internal?owner=${{ parameters.ownerGroup }}&repo=${{ parameters.serviceName }}
        defaultBranch: main
        protectDefaultBranch: true

    # 4) セキュリティパイプライン登録 (SAST + SCA + イメージスキャン + 署名)
    - id: pipeline
      name: 標準パイプライン接続
      action: bank:pipeline:register
      input:
        repo: ${{ steps.publish.output.repoContentsUrl }}
        stages: ['sast', 'sca', 'image-scan', 'cosign-sign']

    # 5) 電子決裁の起案 — 新規資産登載の承認 (カスタムアクション、後述)
    - id: approval
      name: 資産登載決裁の上申
      action: bank:approval:submit
      input:
        docType: NEW_SERVICE_REGISTRATION
        serviceName: ${{ parameters.serviceName }}
        dataClass: ${{ parameters.dataClassification }}
        requester: ${{ user.entity.metadata.name }}

    # 6) カタログ登録 — 資産台帳義務の自動充足
    - id: register
      name: カタログ登録
      action: catalog:register
      input:
        repoContentsUrl: ${{ steps.publish.output.repoContentsUrl }}
        catalogInfoPath: '/catalog-info.yaml'

// plugins/scaffolder-backend-module-bank/src/actions/submitApproval.ts
// 概念コード: 電子決裁システム連携のカスタムアクション
import { createTemplateAction } from '@backstage/plugin-scaffolder-node';

export const submitApprovalAction = () => {
  return createTemplateAction<{
    docType: string;
    serviceName: string;
    dataClass: string;
    requester: string;
  }>({
    id: 'bank:approval:submit',
    description: '電子決裁システムに起案を上申し、承認を待機する',
    schema: {
      input: {
        required: ['docType', 'serviceName', 'dataClass', 'requester'],
        type: 'object',
        properties: {
          docType: { type: 'string' },
          serviceName: { type: 'string' },
          dataClass: { type: 'string' },
          requester: { type: 'string' },
        },
      },
    },
    async handler(ctx) {
      const { docType, serviceName, dataClass, requester } = ctx.input;

      // 1) 決裁文書の作成 — データ等級によって決裁ラインが変わる
      //    internal: チームリーダー専決 / personal-credit: リーダー + 情報保護 + CISO
      const approvalLine = dataClass === 'personal-credit'
        ? ['TEAM_LEAD', 'INFOSEC_REVIEW', 'CISO']
        : ['TEAM_LEAD'];

      const doc = await approvalClient.createDocument({
        type: docType,
        title: `新規サービス登載: ${serviceName}`,
        body: renderTemplate(docType, ctx.input),
        approvers: approvalLine,
        drafter: requester,
      });
      ctx.logger.info(`決裁上申完了: ${doc.id}`);

      // 2) 承認待機 — ポーリング (Webhook受信が可能ならイベント駆動で)
      const result = await approvalClient.waitForCompletion(doc.id, {
        timeoutHours: 72,
        pollIntervalSec: 60,
      });

      if (result.status !== 'APPROVED') {
        throw new Error(`決裁差し戻し: ${result.comment ?? '理由未記載'}`);
      }

      // 3) 承認証跡を出力に — 後続ステップとカタログ注釈に記録
      ctx.output('approvalDocId', doc.id);
      ctx.output('approvedAt', result.completedAt);
      ctx.output('approvers', result.approverHistory);
    },
  });
};

# catalog-info.yaml — 監督報告項目とマッピングされるメタデータ
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: loan-application-api
  description: ローン申込受付API
  annotations:
    bank.example.com/asset-id: "AST-2026-0142"        # 資産管理番号
    bank.example.com/approval-doc: "APR-2026-08731"   # 作成承認の決裁文書
    bank.example.com/last-vuln-assessment: "2026-03"  # 直近の脆弱性評価
  labels:
    bank.example.com/data-class: personal-credit
    bank.example.com/criticality: critical
    bank.example.com/dr-tier: tier-2
spec:
  type: service
  lifecycle: production
  owner: group:retail-lending-dev        # 人事システムの部署コードと同期
  system: loan-origination
  dependsOn:
    - resource:loan-db
    - component:customer-master-api

[インターネット区間 — 搬入専用]
  registry.npmjs.org      ghcr.io / docker.io     プラグインソース
        |                       |                       |
        v                       v                       v
  +---------------------------------------------------------+
  |  搬入ゲートウェイ (定期同期 + 脆弱性スキャン + 承認)         |
  +---------------------------------------------------------+
        |                       |
        v                       v
[内部網]
  Nexus/Verdaccio          Harbor
  (社内npmミラー)           (社内イメージレジストリ)
        |                       |
        +----------+------------+
                   v
            Backstageビルド/デプロイ
            (yarn.lockのresolvedを社内ミラーURLに固定)

[導入前 — 21営業日]
D1~D3   : Gitリポジトリ申請書の作成、決裁待ち、インフラチームの手動作成
D4~D8   : パイプライン登録依頼、CI担当者のキュー待ち
D6~D10  : ファイアウォール開放申請 (DB、社内API2件) — セキュリティチームのレビューキュー
D8~D12  : DBアカウント発行、シークレットの手動受け渡し (メッセンジャーで... 事故リスク)
D10~D15 : セキュリティ審査 — チェックリスト手作業作成、差し戻し1回
D15~D18 : 資産台帳への登載、監視登録依頼
D19~D21 : 本番デプロイ決裁、初回デプロイ
開発者の実感: 「コードより申請書を多く書いた」

[導入後 — 1営業日]
09:00  Backstageポータルでsecure-spring-serviceテンプレートを実行
       (サービス名、所有組織、データ等級 = personal-creditを入力)
09:01  リポジトリ・パイプライン・監視・カタログを自動作成
       ファイアウォール標準ポリシー自動申請 (DB1件は標準ポートで自動承認)
09:02  データ等級がpersonal-creditのため決裁を自動上申
       (リーダー + 情報保護レビュー — スキャン結果と依存グラフを自動添付)
14:30  情報保護チーム承認 (レビューに必要な情報がすべて添付済みで迅速)
14:31  本番ネームスペースのプロビジョニング、シークレットはボールト参照で自動注入
16:00  初回本番デプロイ完了 — 作成からデプロイまで全証跡が自動保存
開発者の実感: 「午前に作って午後にリリースした」