Azure Pipelines YAML 完全ガイド｜Stages/Jobs/Steps・Templates・Variable Groups・Approval Gate

Azure Pipelines は Azure DevOps Services のビルド・リリース自動化サービスで、YAML 構文で CI/CD パイプラインを定義する『Pipelines as Code』方式。 Microsoft が GitHub Actions と並行して主力 CI/CD サービスとして提供しており、Azure DevOps Services を採用する企業の事実上の標準です。 本記事では、Azure Pipelines YAML の基本構造・Templates・Variable Groups・Environments・Workload Identity Federation を網羅的に整理します。

YAML パイプラインの基本構造

Azure Pipelines YAML は階層構造で定義します。

最小サンプル: Hello World

trigger:
  branches:
    include:
      - main

pool:
  vmImage: ubuntu-latest

steps:
  - script: echo "Hello, Azure Pipelines!"
    displayName: 'Print greeting'

Stages / Jobs / Steps の使い分け

Stages

• 大きな論理ブロック (Build → Test → Deploy to Dev → Deploy to Prod)
• Stage 間は順次実行 (依存設定可)
• Stage ごとに Approval Gate 設定可能

Jobs

• Stage 内の並列実行単位
• Agent ごとに 1 Job
• 複数 OS でマルチプラットフォームビルドなど

Steps

• Job 内の順次実行単位
• 最小実行単位

Multi-stage パイプラインの例

stages:
  - stage: Build
    jobs:
      - job: BuildJob
        steps:
          - script: npm install
          - script: npm run build
          - publish: dist
            artifact: webapp

  - stage: DeployDev
    dependsOn: Build
    jobs:
      - deployment: DeployToDev
        environment: dev
        strategy:
          runOnce:
            deploy:
              steps:
                - download: current
                  artifact: webapp
                - task: AzureWebApp@1
                  inputs:
                    azureSubscription: 'AzureServiceConnection'
                    appName: 'myapp-dev'
                    package: '$(Pipeline.Workspace)/webapp'

  - stage: DeployProd
    dependsOn: DeployDev
    jobs:
      - deployment: DeployToProd
        environment: prod
        strategy:
          runOnce:
            deploy:
              steps:
                - download: current
                  artifact: webapp
                - task: AzureWebApp@1
                  inputs:
                    azureSubscription: 'AzureServiceConnection'
                    appName: 'myapp-prod'
                    package: '$(Pipeline.Workspace)/webapp'

Pipeline Templates

Pipeline Templates は YAML パイプラインの再利用可能なコンポーネント。3 種類:

• Stage Templates: Stage 全体の再利用 (e.g. 標準ビルドステージ)
• Job Templates: Job レベルの再利用 (e.g. 標準テストジョブ)
• Step Templates: Step 列の再利用 (e.g. NuGet install + Build)

Step Template の例

# templates/build-node.yml
parameters:
  - name: nodeVersion
    type: string
    default: '20.x'
  - name: workingDirectory
    type: string

steps:
  - task: NodeTool@0
    inputs:
      versionSpec: ${{ parameters.nodeVersion }}
  - script: npm install
    workingDirectory: ${{ parameters.workingDirectory }}
  - script: npm run build
    workingDirectory: ${{ parameters.workingDirectory }}

Template の呼び出し

steps:
  - template: templates/build-node.yml
    parameters:
      nodeVersion: '20.x'
      workingDirectory: 'frontend'

Variables と Variable Groups

Variable 定義方法

• Pipeline 内インライン: variables: { appName: 'myapp' }
• Variable Group: Azure DevOps Library で集中管理
• Variable Template: 再利用可能な変数セット
• Key Vault 統合: Azure Key Vault の Secret を直接マッピング

Key Vault 連携の例

variables:
  - group: KeyVaultGroup  # Azure DevOps Library で Key Vault Reference 設定済み

jobs:
  - job: Deploy
    steps:
      - script: |
          echo "Database connection: $(DB_CONNECTION_STRING)"
        env:
          DB_CONNECTION_STRING: $(DB_CONNECTION_STRING)

Key Vault 統合により、Secret 値が Azure DevOps を経由せず Pipeline 実行時に Key Vault から動的取得。Secret ローテーション時も Pipeline 修正不要で、本番運用では必須パターンです。

Environments と Approval Gate

Environments は、デプロイ先 (Dev・Stage・Prod) を Azure DevOps 上で論理的に管理する機能。各 Environment に以下を設定可能。

• Approval: Required Reviewers (1-3 人の承認者必須)
• Gates: Branch Restriction・Time Window・Azure Monitor Alerts・Service Now チケット確認
• Resources: Kubernetes / VM Resource を Environment と紐付け

Production Environment への Deploy Stage で『2 人の Approver による承認必須』『業務時間外のみデプロイ可』『直前 1 時間に Azure Monitor アラートなし』のような複合 Gateを構成し、安全な本番リリースを実現。 Environment は Deploy 履歴も保存し、誰がいつ何をデプロイしたかの監査トレースを提供。SOC2 / ISO 27001 のコンプライアンス対応に必須の機能です。

Service Connections と Workload Identity Federation

Service Connections は Azure DevOps から外部システム (Azure・GitHub・Docker・Kubernetes) へのアクセス認証を集中管理する機能。

Azure 認証の進化

1. Service Principal + Secret (レガシー、Secret ローテーション必要)
2. Service Principal + Certificate (中程度)
3. Workload Identity Federation (WIF) (現代主推奨、Secret 不要)

WIF は 2023 年に Azure Pipelines でサポート開始、Service Principal に Federated Credential を構成して OIDC トークンで Azure 認証。 Secret や Certificate の管理が完全不要で、CI/CD パイプラインでのシークレット漏洩リスクをゼロ化。詳細は Managed Identity vs Service Principal 記事を参照、新規 Azure DevOps プロジェクトでは WIF 一択というのが業界標準です。

デプロイ戦略

ベストプラクティス

1. YAML を必ずバージョン管理 (Git で履歴・レビュー)
2. Templates で再利用性確保 (共通リポジトリで集中管理)
3. Variable Groups + Key Vault 統合 (Secret 管理の堅牢化)
4. Environments + Approval Gate (本番リリースの安全性)
5. Workload Identity Federation (シークレットレス CI/CD)
6. Self-hosted Agent でセキュア環境 (機密 IaC を Public Agent で実行しない)
7. Artifact のバージョン管理 (Azure Artifacts で nuget/npm/maven 集中管理)
8. パイプライン実行時間 30 分以内 (長時間は分割や並列化を検討)
9. 失敗時の Notification (Teams / Slack 統合)
10. Pipeline as Code を Linter で検証 (azure-pipelines-vscode 拡張機能)

Azure Pipelines vs GitHub Actions

関連認定試験

• AZ-400 (DevOps Engineer Expert): ドメイン 3 (Build and Release Pipelines 40-45%) で深く問われる本領域の本命認定。
• AZ-104 (Administrator): Azure リソースのデプロイ基礎。
• AZ-204 (Developer Associate): 開発者視点での CI/CD。
• AZ-305 (Solutions Architect Expert): アーキテクト視点での DevOps 戦略。
• SC-100 (Cybersecurity Architect Expert): DevSecOps。

よくある質問

本記事の技術情報は Azure Pipelines Documentation に基づいています。 本記事は Microsoft Corporation の公式商品ではなく、いかなる提携・後援関係もありません。 Microsoft、Azure、Azure DevOps、GitHub は Microsoft group of companies の商標です。 情報は 2026 年 5 月 24 日時点の公式公開資料に基づきます。最新情報は必ず公式ページをご確認ください。