Azure Pipelines 入門：CI/CD の概要と YAML 実装ガイド

Contents

1 Azure Pipelines の位置付けと主な特徴
- 1.1 概要
- 1.2 主な特徴
2 初めてのパイプラインを作成する手順
- 2.1 手順概要
- 2.2 UI と YAML の関係
3 Hello World パイプラインの最小構成
- 3.1 各要素の役割
4 ブランチフィルター・手動実行・変数・シークレットのベストプラクティス
5 テンプレートでパイプラインを再利用する方法
6 他 CI ツールとの記法比較とよくあるエラー対策
7 まとめ

スポンサードリンク

Azure Pipelines の位置付けと主な特徴

概要

Azure Pipelines は Azure DevOps Services に組み込まれたフルマネージド型 CI/CD プラットフォームです。コードがリポジトリにプッシュされるたびに、ビルド・テスト・デプロイの一連の処理を自動で実行できます。

主な特徴

項目	内容
マルチプラットフォーム	Windows、Linux、macOS のいずれでも同じ YAML 定義で実行可能
ホステッド／セルフホストエージェント	Microsoft が提供する `ubuntu-latest`・`windows-2022` などのイメージか、社内サーバー上に構築したエージェントを選択できる
統合アーティファクト管理	ビルド成果物は自動的に Azure Artifacts に保存され、次工程や別パイプラインで再利用可能
スケールアウトが容易	エージェントプールを増減させるだけで同時実行数を調整できる
YAML 定義による IaC	パイプラインそのものをコードとして管理し、Pull Request でレビュー・変更履歴の追跡が可能

参考：公式ドキュメントは Azure Pipelines の概要に詳しく記載されています。

初めてのパイプラインを作成する手順

手順概要

Azure DevOps 組織にサインインし、対象プロジェクトを開く。
左メニュー → Pipelines > Pipelines を選択し、New pipeline ボタンをクリック。
ソースリポジトリ（例：Azure Repos Git または GitHub）を指定。
「YAML を使用してパイプラインを構成する」画面で Starter pipeline（空のテンプレート）を選択 → エディタが表示される。
エディタ上部の Save → Run で最初の実行を開始。

UI と YAML の関係

Azure DevOps ポータルは YAML エディタ（Web ベース）と Classic editor（GUI）を併用できますが、IaC を徹底したい場合は必ず YAML で定義します。
保存時に自動的にリポジトリの azure-pipelines.yml としてコミットされるため、コードレビューと同様のフローでパイプライン変更を管理できます。

公式ガイド：手順は Microsoft Learn – Azure Pipelines の最初のパイプライン作成を参照してください。

Hello World パイプラインの最小構成

以下は 最もシンプルな「Hello, World」 パイプラインです。
インデントは 2 スペースで統一し、trigger → stages → jobs → steps の階層を守ります。

# azure-pipelines.yml
trigger:
- main   # main ブランチへの push で自動実行

stages:
- stage: HelloWorld          # 任意のステージ名
  jobs:
  - job: SayHello            # ジョブ名はユニークにすること
    pool:
      vmImage: ubuntu-latest # ホステッドエージェントを使用
    steps:
    - script: |
        echo &quot;Hello, Azure Pipelines!&quot;
      displayName: 'Bash Hello World'

    - pwsh: |
        Write-Host &quot;Hello from PowerShell!&quot;
      displayName: 'PowerShell Hello World'

# azure-pipelines.yml

trigger:

- main # main ブランチへの push で自動実行

stages:

- stage: HelloWorld # 任意のステージ名

jobs:

- job: SayHello # ジョブ名はユニークにすること

pool:

vmImage: ubuntu-latest # ホステッドエージェントを使用

steps:

- script: |

echo "Hello, Azure Pipelines!"

displayName: 'Bash Hello World'

- pwsh: |

Write-Host "Hello from PowerShell!"

displayName: 'PowerShell Hello World'

各要素の役割

要素	説明
`trigger`	どのブランチ・タグでパイプラインを自動起動するかを指定。省略すると手動実行のみになる。
`stages`	大まかなフェーズ（例：Build、Test、Deploy）。ステージ単位で条件分岐や承認設定が可能。
`jobs`	ステージ内の処理単位。エージェントプールや変数スコープはここで定義する。
`steps`	ジョブ内部で実行される個々のコマンド・タスク。順序通りに走る。

このファイルをリポジトリにコミットすれば、main ブランチへのプッシュ時に自動で「Hello, World」が出力されます。

ブランチフィルター・手動実行・変数・シークレットのベストプラクティス

1. ブランチフィルター（自動トリガー）

trigger:
  branches:
    include:
      - main           # 本番ブランチだけ自動実行
    exclude:
      - feature/*     # フィーチャーブランチは除外

trigger:

branches:

include:

- main # 本番ブランチだけ自動実行

exclude:

- feature/* # フィーチャーブランチは除外

include と exclude は同時に記述でき、最も具体的なマッチが優先されます。
タグでのトリガーは tags: を併用すれば実現できます。

2. 手動実行だけにしたい場合

Azure Pipelines のデフォルトは 自動トリガーなし → UI から手動実行 が可能です。以下の記述で自動起動を完全にオフにします（resources は不要）。

trigger: none   # CI トリガー無効化
pr: none        # PR トリガー無効化

trigger: none # CI トリガー無効化

pr: none # PR トリガー無効化

この状態でも Azure DevOps の UI から Run pipeline → Run を選べば手動で実行できます。

3. 変数のスコープと書き方

種類	定義場所	参照方法	評価タイミング
テンプレート展開前に評価されるコンパイル時変数	`variables:` ブロック（トップレベル）	`${{ variables.myVar }}` または `$[ variables.myVar ]`	テンプレート展開・ステージ/ジョブ作成時
実行中に評価されるランタイム変数	任意のスクリプト／タスク内	`$(myVar)`	ジョブ実行時
シークレット変数	Library → Variable groups またはパイプラインレベルで `isSecret: true`	`$(mySecret)` （ログには出力されない）	実行時に環境変数として注入

例：コンパイル時変数とランタイム変数の併用

variables:
- name: buildConfiguration
  value: Release          # コンパイル時に展開

jobs:
- job: Build
  pool:
    vmImage: ubuntu-latest
  steps:
  - script: |
      echo &quot;Configuration = $(buildConfiguration)&quot;   # ランタイム参照
    displayName: 'Show build configuration'

variables:

- name: buildConfiguration

value: Release # コンパイル時に展開

jobs:

- job: Build

pool:

vmImage: ubuntu-latest

steps:

- script: |

echo "Configuration = $(buildConfiguration)" # ランタイム参照

displayName: 'Show build configuration'

例：シークレット変数の安全な渡し方

variables:
- group: MySecrets        # Library に作成した Variable group をインポート

steps:
- script: |
    echo &quot;Connecting to DB...&quot;
    # パスワードはログに表示されない
  env:
    DB_PASSWORD: $(dbPassword)   # 環境変数としてシークレットを渡す
  displayName: 'Connect to database (secret hidden)'

variables:

- group: MySecrets # Library に作成した Variable group をインポート

steps:

- script: |

echo "Connecting to DB..."

# パスワードはログに表示されない

env:

DB_PASSWORD: $(dbPassword) # 環境変数としてシークレットを渡す

displayName: 'Connect to database (secret hidden)'

ポイント
- シークレットは必ず Library → Variable groups（もしくはパイプライン UI の「Variables」タブ）で isSecret を設定し、コード内に平文を書かない。
- 変数名の大文字・小文字は区別されるため、一貫した命名規則を策定すると混乱が防げます。

4. まとめ

ブランチフィルターで実行対象を絞り、手動トリガーで必要時だけ走らせる。
コンパイル時変数はテンプレートやステージ定義に、ランタイム変数はスクリプト内に使い分ける。
シークレットは Library に保存し、環境変数経由で渡すことでログ漏洩を防止できる。

テンプレートでパイプラインを再利用する方法

1. テンプレートの基本構文

# templates/build-stage.yml
parameters:
  vmImage: 'ubuntu-latest'
  script: |
    echo &quot;Building...&quot;

stages:
- stage: Build
  jobs:
  - job: BuildJob
    pool:
      vmImage: ${{ parameters.vmImage }}
    steps:
    - script: ${{ parameters.script }}
      displayName: 'Run build script'

# templates/build-stage.yml

parameters:

vmImage: 'ubuntu-latest'

script: |

echo "Building..."

stages:

- stage: Build

jobs:

- job: BuildJob

pool:

vmImage: ${{ parameters.vmImage }}

steps:

- script: ${{ parameters.script }}

displayName: 'Run build script'

2. メインパイプラインからの呼び出し

# azure-pipelines.yml
trigger:
- main

stages:
- template: templates/build-stage.yml
  parameters:
    vmImage: 'windows-latest'      # Windows エージェントへ差し替え
    script: |
      echo &quot;Building on Windows&quot;

# azure-pipelines.yml

trigger:

- main

stages:

- template: templates/build-stage.yml

parameters:

vmImage: 'windows-latest' # Windows エージェントへ差し替え

script: |

echo "Building on Windows"

ポイント

項目	説明
`template:`	外部 YAML ファイルへの相対パスを指定。`stages`, `jobs`, `steps` のいずれでも使用できる。
`parameters:`	テンプレート側で定義した変数に値を渡す。デフォルトはテンプレート内で設定可能。
`variables:` と同様にインデントは正確に（2 スペース）保つことが必須。

3. 複数テンプレートの組み合わせ例

stages:
- template: templates/build-stage.yml
  parameters:
    vmImage: 'ubuntu-latest'

- template: templates/test-stage.yml
  parameters:
    vmImage: 'ubuntu-latest'
    testScript: |
      echo &quot;Running unit tests&quot;

- stage: Deploy
  jobs:
  - deployment: ProdDeploy
    environment: Production
    pool:
      vmImage: 'windows-latest'
    strategy:
      runOnce:
        deploy:
          steps:
          - script: echo &quot;Deploy to prod&quot;

stages:

- template: templates/build-stage.yml

parameters:

vmImage: 'ubuntu-latest'

- template: templates/test-stage.yml

parameters:

vmImage: 'ubuntu-latest'

testScript: |

echo "Running unit tests"

- stage: Deploy

jobs:

- deployment: ProdDeploy

environment: Production

pool:

vmImage: 'windows-latest'

strategy:

runOnce:

deploy:

steps:

- script: echo "Deploy to prod"

このように ステージ単位でテンプレート化すれば、プロジェクト間でビルド・テストロジックを共通化でき、変更があった場合はテンプレートだけ更新すれば全パイプラインに反映されます。

公式リファレンス：
- YAML テンプレートの概要 (Azure DevOps)

他 CI ツールとの記法比較とよくあるエラー対策

1. 記法比較表（2024 年時点）

項目	Azure Pipelines	GitHub Actions	GitLab CI
基本単位	`stage → job → step`	`job → steps`	`stage → job → script`
トリガー指定	`trigger:` / `pr:`	`on:`	`only:` / `except:`
変数参照	`${{ variables.xxx }}`、`$(var)`	`${{ env.VAR }}`, `${{ secrets.SECRET }}`	`$VARIABLE`, `$CI_VARIABLE`
テンプレート呼び出し	`- template: path.yml`	`uses:`（外部アクション）	`include:`
エージェント指定	`pool: vmImage:`	`runs-on:`	`tags:`
シークレット管理	Library → Variable groups (`isSecret`)	Repository/Organization Secrets	CI/CD Settings → Variables (masked)

※上記は公式ドキュメントと一般的なベストプラクティスに基づく比較です。実装ごとに細かい差異がありますので、各サービスの最新マニュアルをご確認ください。

2. 初心者が陥りやすいエラーと対処法

エラーメッセージ	主な原因	デバッグ手順
`##[error]Unexpected value 'steps'`	`steps` が正しい階層に配置されていない（インデント不足）	2 スペース単位のインデントを再確認。Azure DevOps の Validate ボタンで構文チェック。
`##[error]A job with name 'Build' already exists`	同一ステージ内に同名ジョブが重複	ジョブ名をユニークに変更し、`jobs:` 配列の中身を整理する。
`##[warning]Variable is not defined: mySecret`	シークレット変数が Library に未登録、または名前ミス	Pipelines > Library でシークレットを作成し、正しい名前で参照。ビルドログの Variables タブで実際に渡されているか確認する。
`##[error]Invalid value for parameter 'trigger'`	手動トリガー設定が不適切（例：`resources.pipelines.trigger.enabled` の誤用）	手動だけにしたい場合は `trigger: none` と `pr: none` をトップレベルで記述するだけで OK。

デバッグのヒント

System diagnostics を有効にすると、内部的な変数展開やステージ評価の詳細がログに出力されます（パイプライン設定 → Run pipeline → Enable system diagnostics）。
YAML Validator（Azure DevOps の UI に組み込まれている）で事前に構文エラーを検出。
エラーメッセージの行番号が指す箇所だけでなく、直前の 2 行までインデントやキー名を確認する。

3. ビルドログの活用法

タブ	内容
Summary	ステージ・ジョブ単位の成功/失敗ステータスが一覧表示。承認待ちや保留中も可視化。
Logs	各ステップの標準出力／エラー出力をリアルタイムで閲覧可能。`##[error]` などの詳細メッセージはここに。
Download logs	全ログを ZIP ダウンロードでき、社内レビューや外部サポートへの提供が容易。

ベストプラクティス：失敗したジョブだけでなく、成功したジョブの System diagnostics も取得しておくと、インフラ側のタイムアウトやリソース不足など、見落としがちな原因を追跡できます。

まとめ

Azure Pipelines は コード変更 → ビルド・テスト・デプロイ を一貫して自動化できる、Azure DevOps の中心的 CI/CD サービスです。
初期設定は UI 上の数クリックで完了し、生成された azure-pipelines.yml がそのまま IaC として機能します。
ブランチフィルターや手動実行、変数・シークレットを正しく使うことで、本番環境への安全なデリバリーが実現できます。
テンプレート機能により ステージ単位の再利用 が可能となり、複数プロジェクトで共通ロジックを一元管理できるため保守コストが大幅に削減されます。
他 CI ツール（GitHub Actions・GitLab CI）と比較すると、階層構造や変数展開の書き方に違いはありますが、概念は共通です。インデントエラーや変数名ミスは初心者が最も陥りやすいポイントなので、YAML バリデータと System diagnostics の活用を習慣化しましょう。

以上が Azure Pipelines を導入・運用する際の基本的な知識と実践的なテクニックです。ぜひ本稿を参考に、まずは「Hello World」パイプラインから作成し、段階的に機能拡張してみてください。

スポンサードリンク

Azure Pipelines 入門：CI/CD の概要と YAML 実装ガイド

Azure Pipelines の位置付けと主な特徴

概要

主な特徴

初めてのパイプラインを作成する手順

手順概要

UI と YAML の関係

Hello World パイプラインの最小構成

各要素の役割

ブランチフィルター・手動実行・変数・シークレットのベストプラクティス

1. ブランチフィルター（自動トリガー）

2. 手動実行だけにしたい場合

3. 変数のスコープと書き方

例：コンパイル時変数とランタイム変数の併用

例：シークレット変数の安全な渡し方

4. まとめ

テンプレートでパイプラインを再利用する方法

1. テンプレートの基本構文

2. メインパイプラインからの呼び出し

ポイント

3. 複数テンプレートの組み合わせ例

他 CI ツールとの記法比較とよくあるエラー対策

1. 記法比較表（2024 年時点）

2. 初心者が陥りやすいエラーと対処法

デバッグのヒント

3. ビルドログの活用法

まとめ

Hello World パイプラインの最小構成