Azure Pipelinesで「本番環境へのデプロイ前に承認を挟みたい」「特定のブランチ以外からのリリースを止めたい」「深夜のメンテナンス時間までデプロイを待たせたい」と考えているなら、見るべき機能が Pipeline deployment approvals、つまり Azure Pipelines の 承認とチェック です。
結論から言うと、Pipeline deployment approvals は、デプロイステージを実行してよいかどうかを YAMLだけではなく、環境・サービス接続・変数グループなどのリソース側で制御する仕組み です。特に本番環境や共有リソースを使うパイプラインでは、承認者、タイムアウト、ブランチ制御、営業時間、排他ロックを見直すことで、誤デプロイや無断リリースのリスクを大きく下げられます。Microsoft Learnでは、承認やチェックは YAML ファイルではなく Azure Pipelines の Web インターフェイスからリソース管理者が管理する仕組みとして説明されています。(Microsoft Learn)
2026年5月8日に更新された Azure DevOps の .NET client libraries 公式情報では、Microsoft.Azure.Pipelines.Policy.Client が pipeline approvals、checks、authorization の public REST APIs へのアクセスを提供することも示されています。手動承認だけでなく、承認状況の取得や運用監査、自動化との連携を検討する開発者・管理者にとっても確認しておきたいポイントです。(Microsoft Learn)
Pipeline deployment approvalsとは
Pipeline deployment approvals は、Azure Pipelines のステージが実行される前に、承認や条件チェックを行うための機能です。
たとえば、次のような制御ができます。
- 本番環境へのデプロイ前に、責任者の承認を必須にする
mainやreleaseブランチ以外からのデプロイを防ぐ- 営業時間外やメンテナンス時間帯だけデプロイを許可する
- Azure Monitor のアラートが出ている場合は次のステージへ進ませない
- 複数のパイプラインが同じ環境へ同時にデプロイしないようにする
重要なのは、承認とチェックが パイプライン作成者ではなく、リソース所有者の管理下に置かれる 点です。Microsoft Learnでは、環境、サービス接続、エージェントプール、変数グループ、セキュリティで保護されたファイルなど、パイプラインが依存するリソースに対してチェックを定義できると説明されています。(Microsoft Learn)
つまり、アプリ開発者が YAML を変更しても、本番環境に設定された承認チェックを勝手に回避することはできません。これは、開発スピードとガバナンスを両立するうえで大きな意味があります。
何が変わるのか：YAML中心ではなくリソース中心でデプロイを止める
Pipeline deployment approvals のポイントは、「パイプライン内に承認処理を書く」ことではありません。むしろ、守るべき環境やサービス接続の側に、承認・条件・制限を設定する ことです。
これにより、同じ本番環境を複数のパイプラインが使っている場合でも、環境側に承認チェックを設定すれば、すべての対象パイプラインに共通ルールを適用しやすくなります。
| 観点 | 従来ありがちな運用 | Pipeline deployment approvalsで目指す運用 |
|---|---|---|
| 承認の場所 | YAML、手順書、個別パイプラインに分散 | 環境やサービス接続などのリソース側で一元管理 |
| 承認者 | 個人名で固定しがち | 役割に応じたユーザーまたはグループで管理 |
| 本番反映のタイミング | 承認されたらすぐ実行 | 承認の延期や営業時間チェックで実行時間も制御 |
| ブランチ制御 | レビュー運用に依存 | Branch controlで許可ブランチを明示 |
| 同時デプロイ | 担当者が手動調整 | Exclusive lockで排他制御 |
| 自動化・監査 | UI確認が中心 | REST APIやクライアントライブラリ連携も検討可能 |
実務上の変更点は、YAMLの書き方そのものよりも、誰が、どのリソースに、どのチェックを設定するか を整理し直すことです。
対象になるリソースと影響範囲
承認とチェックは、すべてのステージに無条件で効くわけではありません。ステージが使用するリソースに対してチェックが設定されている場合、そのリソースを消費する前に評価されます。
Microsoft Learnでは、チェックを構成できるリソースとして、環境、サービス接続、リポジトリ、変数グループ、セキュリティで保護されたファイル、エージェントプールが挙げられています。また、ステージで使われるすべてのリソースのチェックが満たされるまで、Azure Pipelines はステージの実行前に一時停止します。(Microsoft Learn)
| リソース | 主な確認ポイント | 影響を受ける例 |
|---|---|---|
| Environment | 本番・検証・ステージング環境の承認、履歴、権限 | Production へのデプロイ前に承認を要求 |
| Service connection | Azure サブスクリプションや外部サービスへの接続制御 | 本番用 Azure Resource Manager 接続の利用前に承認 |
| Repository | ブランチやテンプレート利用の制御 | 許可されたブランチ以外のリリースを防止 |
| Variable group | 機密値や環境変数の利用制御 | 本番DB接続文字列を含む変数グループを保護 |
| Secure files | 証明書やキーファイルの利用制御 | 署名証明書を使う前に承認を要求 |
| Agent pool | 特定のビルド・デプロイ実行基盤の利用制御 | 本番デプロイ用のセルフホストエージェントを制限 |
特に注意したいのは サービス接続を変数で指定できない 点です。Microsoft Learnでも、service connections cannot be specified by variable と明記されています。サービス接続を環境ごとに切り替える設計をしている場合は、YAMLテンプレートやステージ分割で明示的に参照する設計へ見直す必要があります。(Microsoft Learn)
承認とチェックの実行順序
Azure Pipelines の承認とチェックには実行順序があります。公式情報では、静的チェック、事前承認、動的チェック、事後承認、排他ロックの順に評価されると説明されています。(Microsoft Learn)
| 実行順 | 種類 | 主な用途 |
|---|---|---|
| 1 | 静的チェック | Branch control、Required template、Evaluate artifact |
| 2 | 事前チェック承認 | デプロイ前の人による承認 |
| 3 | 動的チェック | Azure Function、REST API、Business Hours、Azure Monitor alerts など |
| 4 | 事後チェック承認 | デプロイ後の確認や次工程への承認 |
| 5 | Exclusive lock | 同時デプロイの排他制御 |
この順序を理解していないと、承認者に通知が届くタイミングや、外部チェックが繰り返し実行されるタイミングを誤解しやすくなります。
たとえば、パフォーマンスチェックやセキュリティスキャンが通った後にだけ人間の承認を求めたい場合は、承認の位置付けを慎重に設計する必要があります。単に「承認者を設定する」だけでは、現場が期待するリリースフローにならないことがあります。
主なチェックの種類と使い分け
Pipeline deployment approvals では、単なる手動承認だけでなく、さまざまなチェックを組み合わせられます。重要なのは、すべてを入れることではなく、リスクに応じて必要なものを選ぶことです。
| チェック | 使うべき場面 | 実務上の注意点 |
|---|---|---|
| Approvals | 本番・準本番へのデプロイ前に責任者確認が必要な場合 | 承認者、自己承認の可否、タイムアウトを明確にする |
| Deferred approvals | 承認は日中に行い、実行は夜間にしたい場合 | 承認時刻と実行可能時刻を混同しない |
| Branch control | main や release など、許可ブランチのみデプロイしたい場合 | ブランチ名は refs/heads/<branch name> の形式で指定する |
| Required template | 共通のデプロイテンプレート利用を強制したい場合 | サービス接続など重要リソースで有効 |
| Evaluate artifact | コンテナーイメージに対してポリシー評価したい場合 | 公式情報ではコンテナーイメージ成果物が対象とされている |
| Business Hours | メンテナンス時間帯だけデプロイしたい場合 | 他チェックで遅延すると翌日の再評価になる可能性がある |
| Invoke Azure Function | 独自ロジックでデプロイ可否を判定したい場合 | 短時間で応答するHTTPトリガーとして設計する |
| Invoke REST API | 外部承認、セキュリティスキャン、変更管理システムと連携したい場合 | タイムアウトと評価間隔を運用に合わせる |
| Query Azure Monitor Alerts | カナリアリリースや段階的ロールアウトで監視結果を使いたい場合 | アラートルールの範囲と評価タイミングを確認する |
| Exclusive lock | 同じ環境への同時デプロイを防ぎたい場合 | 既定の runLatest と sequential の違いを理解する |
Branch controlでは、許可されたブランチからビルドされているか、保護が有効かを確認できます。複数のリソースがリンクされている場合は、それらのソースも検証対象になります。ブランチ名は完全修飾形式である refs/heads/<branch name> が必要です。(Microsoft Learn)
管理者が確認すべき設定
管理者は、まず「どのリソースを保護すべきか」を決める必要があります。多くの組織では、本番環境だけでなく、本番用のサービス接続、変数グループ、セキュアファイルも保護対象になります。
承認者と自己承認の設定
承認チェックでは、ユーザーまたはグループを承認者として追加し、必要に応じて承認者向けの指示、自己承認の許可・制限、タイムアウトを設定します。指定したタイムアウト内に承認が完了しない場合、ステージはスキップとして扱われます。(Microsoft Learn)
実務では、次のように決めておくと運用が安定します。
| 設定項目 | 推奨される考え方 |
|---|---|
| 承認者 | 個人ではなく、運用責任を持つ少人数グループを基本にする |
| 自己承認 | 本番環境では原則として制限する |
| 指示文 | 「何を確認してから承認するか」を具体的に書く |
| タイムアウト | 業務時間、夜間対応、休日対応を考慮して決める |
| グループ承認 | グループ内の1人が承認すれば進むため、メンバー範囲を絞る |
見落としやすいのは、承認を確認できるユーザーの一覧が、承認とチェックの実行開始時点で固定される点です。チェック開始後に承認者グループを変更しても、その実行中の承認要求には反映されません。(Microsoft Learn)
権限とリソース所有者の整理
Environmentを使う場合、Creator、Administrator、User、Reader のロールを整理しておく必要があります。公式情報では、Environment の Creator、Administrator、User は approvals and checks を管理できますが、Reader は管理できないと説明されています。(Microsoft Learn)
本番環境では、少なくとも次の分離を意識してください。
- YAMLを編集する開発者
- 本番環境を管理する運用担当者
- サービス接続を管理するクラウド管理者
- 承認を行うリリース責任者
この分離が曖昧だと、承認チェックを設定しても「誰でも環境設定を変えられる」「承認者が自分のデプロイを承認できる」といった抜け道が残ります。
バイパスと無効化の扱い
緊急修正では、チェックをバイパスしたくなる場面があります。Azure Pipelinesでは、チェックが定義されているリソースの管理者権限がある場合にのみ、承認やBusiness Hours、Azure Function、REST APIチェックをバイパスできます。バイパスした場合は、誰がバイパスしたかがチェックパネルに表示されます。(Microsoft Learn)
ただし、バイパスは日常運用ではなく、例外運用として扱うべきです。次のルールを事前に決めておくと、監査時にも説明しやすくなります。
| 項目 | 決めておく内容 |
|---|---|
| 使用条件 | 障害対応、重大なセキュリティ修正などに限定 |
| 実行権限 | 本番環境の管理者に限定 |
| 記録 | チケット番号、理由、実施者、影響範囲を残す |
| 事後確認 | 通常チェックを通した再デプロイやレビューを行う |
一方、チェックの無効化は主にデバッグ用途です。一時的に無効化したまま戻し忘れると、保護しているつもりの環境が無防備になります。無効化した場合は、復旧確認までを作業手順に含めてください。
開発者が確認すべきYAMLと実装上の注意点
開発者側で重要なのは、承認チェックを設定したリソースを、ステージが正しく消費しているかどうかです。チェックは、ステージ条件が満たされ、かつ対象リソースがステージで使われることで評価されます。定義したチェックが開始されない場合は、リソースにチェックを追加した後の実行であること、そしてそのステージが対象リソースを使用していることを確認する必要があります。(Microsoft Learn)
たとえば、Environment に承認チェックを設定した場合は、デプロイジョブでその Environment を参照します。
stages:
- stage: Deploy_Prod
displayName: Deploy to production
condition: succeeded()
jobs:
- deployment: DeployWeb
displayName: Deploy web app
environment: production
strategy:
runOnce:
deploy:
steps:
- script: echo "Deploy to production"この例では、production Environment に承認チェックが設定されていれば、Deploy_Prod ステージの実行前にチェックが評価されます。
conditionとapprovalは役割が違う
YAMLの condition は、ステージやジョブを実行対象にするかどうかを決める条件です。一方、approvalやcheckは、対象リソースを使ってよいかどうかを判断する仕組みです。
つまり、次のように考えると整理しやすくなります。
| 機能 | 管理する人 | 主な役割 |
|---|---|---|
YAMLの condition | パイプライン作成者 | 成功時だけ実行、特定ブランチだけ実行などの制御 |
| Approvals and checks | リソース所有者・管理者 | 環境やサービス接続の利用可否を制御 |
| ManualValidationタスク | パイプライン作成者 | パイプライン内に手動確認ステップを置く |
| Classic release approvals | Classic release pipelineの管理者 | Classic release pipelineのステージ承認 |
Classic release pipelineでは、各ステージの開始前または終了後に手動承認を設定できます。指定された承認者が承認、拒否、再割り当てを行うまでデプロイが一時停止されます。YAML pipelines の Environment ベースの承認とは設定場所や考え方が異なるため、移行時には混同しないようにしましょう。(Microsoft Learn)
排他ロックで同時デプロイを防ぐ
本番環境でよくある事故の一つが、複数のパイプライン実行が同時に同じ環境へデプロイすることです。Exclusive lockを使うと、保護されたリソースを使うステージを1つずつ進められます。
公式情報では、lockBehavior には runLatest と sequential の2つがあり、指定がない場合は runLatest が既定値として使われると説明されています。runLatest は最新の実行のみがロックを取得し、sequential はすべての実行が順番にロックを取得します。(Microsoft Learn)
stages:
- stage: Deploy_Prod
lockBehavior: sequential
jobs:
- deployment: DeployWeb
environment: production
strategy:
runOnce:
deploy:
steps:
- script: echo "Deploy sequentially"使い分けの目安は次のとおりです。
| 設定 | 向いているケース | 注意点 |
|---|---|---|
runLatest | 古いデプロイ要求を進める意味がないWebアプリ更新 | 先にキューに入った実行が期待通り進まない場合がある |
sequential | すべての変更を順番に反映する必要があるDB更新や段階的移行 | キューが詰まりやすいため、不要な実行の整理が必要 |
本番環境では、どちらが正しいかはシステム特性によって変わります。単純なWebアプリなら runLatest が適することもありますが、マイグレーションやデータ更新を伴う場合は sequential のほうが安全な場合があります。
REST API・クライアントライブラリ連携でできること
2026年5月8日更新の Azure DevOps .NET client libraries 公式情報では、Microsoft.Azure.Pipelines.Policy.Client が pipeline approvals、checks、authorization の public REST APIs へのアクセスを提供するとされています。(Microsoft Learn)
これにより、組織によっては次のような連携を検討できます。
- 承認待ちのパイプラインを一覧化してダッシュボードに表示する
- 承認・拒否・バイパスの履歴を監査レポートに集約する
- 変更管理システムやチケット番号とデプロイ承認をひも付ける
- 外部サービスからチェック結果を取得し、デプロイ可否の判断に使う
ただし、API連携は「承認を楽にする」ためだけに使うと危険です。特に本番環境では、誰が、何を根拠に、どの実行を承認したのかを追跡できる設計にしてください。
よくある失敗と対策
Pipeline deployment approvals は強力ですが、設定場所や評価タイミングを誤ると「承認が効かない」「ステージが進まない」といった問題が起こります。
| 失敗しやすいケース | 主な原因 | 対策 |
|---|---|---|
| 承認を設定したのにステージが止まらない | ステージが対象リソースを使っていない | deployment jobでEnvironmentを参照しているか確認 |
| 承認者を変更したのに反映されない | チェック開始時点で承認者リストが固定される | 実行中のランには反映されない前提で再実行を検討 |
| ブランチチェックで失敗する | ブランチ名が完全修飾形式でない | refs/heads/main のように指定する |
| 予定時間にデプロイされない | Business Hours以外のチェックで待機している | 承認、外部チェック、タイムアウトをまとめて確認 |
| 古い実行がデプロイされない | Exclusive lockの既定が runLatest | 順番にすべて反映したい場合は sequential を指定 |
| チェックが開始されない | ステージ条件が満たされていない、またはリソースが未使用 | condition とリソース参照を確認 |
| 本番サービス接続を変数で切り替えようとして失敗 | サービス接続は変数指定できない | ステージやテンプレートで明示的にサービス接続を分ける |
| グループ承認で想定外の人が承認する | グループ内の1人の承認で進む | 承認グループのメンバーを最小限にする |
特に「承認を設定したのに効かない」場合は、YAML側だけを見ても原因が分からないことがあります。Azure Pipelines のリソース側、Environment側、Service connection側の Approvals and checks を確認してください。
移行・展開時の進め方
既存のパイプラインに Pipeline deployment approvals を導入する場合は、いきなり本番環境に適用するのではなく、段階的に進めるのが安全です。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 1 | 保護対象を洗い出す | 本番Environment、Azureサービス接続、変数グループ、セキュアファイル |
| 2 | 現在の承認方法を確認する | Classic release、ManualValidation、手順書、チャット承認の有無 |
| 3 | リソース所有者を決める | 誰がApprovals and checksを管理するか |
| 4 | 検証環境で承認チェックを設定する | 承認者、自己承認、タイムアウト、通知 |
| 5 | Branch controlやBusiness Hoursを追加する | デプロイ可能なブランチと時間帯 |
| 6 | テスト実行する | ステージが正しく一時停止・再開・失敗するか |
| 7 | 本番環境へ展開する | バイパス手順と監査ログの確認も含める |
| 8 | 運用手順を更新する | 承認時に見る項目、緊急時対応、責任範囲 |
移行時におすすめなのは、まず本番Environmentに手動承認だけを設定し、その後にBranch control、Business Hours、Exclusive lockを追加していく方法です。最初からすべてのチェックを入れると、どの設定が原因で止まっているのか分かりにくくなります。
本番環境での設計例
本番環境向けの実用的な構成例は次のようになります。
| レイヤー | 設定例 | 目的 |
|---|---|---|
| Environment | production にApprovalsを設定 | 本番反映前に責任者が確認 |
| Branch control | refs/heads/main のみ許可 | 未レビュー・未統合ブランチからの反映を防ぐ |
| Required template | 共通デプロイテンプレートを必須化 | 独自YAMLによる抜け道を減らす |
| Business Hours | メンテナンス時間帯のみ許可 | 利用者影響の少ない時間に反映 |
| Azure Monitor alerts | 重要アラートがない場合のみ続行 | 障害中の追加デプロイを防ぐ |
| Exclusive lock | sequential または runLatest | 同時デプロイを防止 |
| REST API連携 | 承認状態や履歴を集約 | 監査・運用レポートに利用 |
この構成にすると、開発者は通常どおりパイプラインを実行できますが、本番環境に入る直前で、組織が定めた承認・安全確認・時間制限が適用されます。
まず確認すべきチェックリスト
Azure Pipelines の Pipeline deployment approvals を使っている、またはこれから導入する場合は、次の項目を確認してください。
- 本番EnvironmentにApprovals and checksが設定されているか
- 本番用Service connectionにも必要なチェックがあるか
- 承認者が個人退職や異動の影響を受けない構成になっているか
- 自己承認を許可すべきか制限すべきか決めているか
- タイムアウトが短すぎてステージが意図せずスキップされないか
- Branch controlのブランチ名が
refs/heads/main形式になっているか - Business Hoursと承認の順序が実際の運用に合っているか
- Exclusive lockの
runLatestとsequentialを使い分けているか - チェックのバイパス権限が必要最小限に絞られているか
- API連携や監査レポートで承認履歴を追えるか
Pipeline deployment approvals は、単に「承認ボタンを追加する機能」ではありません。Azure Pipelines におけるデプロイ統制を、パイプライン作成者のYAMLから、リソース所有者の管理へ移すための仕組みです。
まずは本番Environmentと本番用Service connectionを開き、Approvals and checks の設定を確認してください。承認者、タイムアウト、ブランチ制御、営業時間、排他ロックを見直すだけでも、誤デプロイや無許可リリースを防ぐ効果があります。そのうえで、REST APIやクライアントライブラリ連携を使い、承認状況の可視化と監査まで整えると、Azure Pipelines のデプロイ運用はより安全で管理しやすくなります。
コメント