Azure Pipelines：キャンセルしたのに実行が止まらない理由（条件・キャンセルの待ち時間・Force cancel）
Azure Pipelines のキャンセルは、すべてを止めるわけではありません。成功のあとにだけ動くものは止め、条件がまだ真のものは動かし続けます。condition: always() のステージ・ジョブ・ステップや、eq(variables['Build.SourceBranch'], 'refs/heads/main') のように実行の状態を見ない条件のものです。「Why is my build still running after I canceled it?」（キャンセルしたのにビルドがまだ動いているのはなぜ？）への Microsoft の答えは、条件にジョブの状態を調べる関数を足すことです（パイプラインの条件）。2026年10月27日の Sprint 281 の更新からは、それでも止まらない実行を強制的にキャンセルすることもできます。
キャンセルが止めるもの、止めないもの
- キューで待っているあいだ、まだ何も始まっていない実行をキャンセルすると、すべてのステージごと丸ごとキャンセルされます。
- 条件の無いステージ・ジョブ・ステップは既定の
succeeded()なので、キャンセルのあとは始まりません。 succeededOrFailed()は失敗のあとには動き、キャンセルのあとには動きません。always()はどちらのあとでも動きます。- 自分で書いた条件は既定の条件に置き換わります。
succeeded()・failed()・succeededOrFailed()・canceled()のどれも使っていない条件には、キャンセルは関係ありません。Microsoft の例では、eq(variables['Build.SourceBranch'], 'refs/heads/main')だけの条件のステージ・ジョブ・ステップは、mainの実行を前のものが動いている途中でキャンセルしても動きます。 - 飛ばされた親の中のものは、自分の条件が何であれ動きません。キャンセルされたステージに依存するステージの中にある、その
mainの条件のジョブは、ステージと一緒に飛ばされます。
キャンセルで止まる条件を書く
自分の判定の横に、状態を調べる関数を入れます：
- stage: Deploy condition: and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))
失敗のあとには動かし、キャンセルのあとには動かしたくない後片付けには、succeededOrFailed()（自分の判定もあるなら and(succeededOrFailed(), ...)）を使います。always() は、キャンセルのあとでも必ず動かしたいステップだけにして、キャンセルの待ち時間を与えます。
動き続けるステップに与えられる時間
キャンセルのあと、ジョブはまだ動くステップに cancelTimeoutInMinutes の時間を与えます。設定しなければ5分で、1〜35,790 の範囲です。そのあとは止められます。Microsoft がホストするエージェントでは、ジョブが動ける最長の時間の制限もそのまま効きます（Azure Pipelines のジョブのタイムアウトの節）：
jobs: - job: Deploy timeoutInMinutes: 60 cancelTimeoutInMinutes: 2
Force cancel（Sprint 281）
そうした条件のせいで動き続ける実行のために、2026年10月27日の Sprint 281 の更新（Microsoft は2〜3週間かけて展開）が、実行に強制キャンセルの操作を足しました。確認を経てから動きます：
- 動いているステージ・ジョブ・ステップをすべてすぐに止め、そのあとのものは何も動きません。システムが食い違った状態のまま残ることがある、と Microsoft は注意しています。
- 実行は放棄（Abandon）の扱いになり、もう一度実行できません。
- パイプラインの権限が3つ要ります：Manage stage run order・Stop builds・Abandon builds。
長く効く答えは、やはり条件を直すことです。Force cancel が止めるのはその1回の実行だけで、同じパイプラインの次のキャンセルはこれまでと同じように振る舞います。
終わった実行を放棄する
同じ更新で、Failed や Canceled のように終わった実行を、実行のメニューから放棄できるようになりました。放棄した実行は読み取り専用になり、どのステージももう一度実行できないので、誤ったアーティファクトが再びデプロイされるのを防げます。Abandon builds の権限が要り、取り消せません。
見分け方
キャンセルのあとも動いたステージ・ジョブ・ステップには、YAML に独自の条件があり、その中に状態を調べる関数がありません。止まったものには条件が無いか、succeeded() の入った条件があります。テンプレートがそうした条件を持ち込むこともあるので、ステージやジョブのもとになっているテンプレートも見ます。
IntelliJ IDEA と Rider でのビルド検証
Azure DevOps Pull Requests は、Lesstep が作っている JetBrains IDE（2024.1 以降）のプラグインです。プルリクエストを、ブランチ ポリシーを平易な文にして IDE のツールウィンドウに並べるので、失敗したビルドのポリシーはプルリクエストの横に「満たしていない」と出ます。Pro では、失敗したビルドや期限切れのビルドに再実行のリンクが出て、もう一度キューに入れられます。レビューの受信箱とブランチ ポリシーは無料、投票・コメント・完了・ビルドポリシーの再実行・プルリクの作成は Pro（月 US$1・30日間の無料試用つき）です。画面は日本語です。
Azure DevOps は Microsoft Corporation の商標、IntelliJ IDEA と Rider は JetBrains s.r.o. の商標です。このページは Microsoft・JetBrains のいずれとも提携しておらず、承認も受けていません。
ほかに：ビルド検証：期限切れのビルド、手動のキュー、プルリクのビルドが動かない理由 · Ubuntu 26.04 の「Access to the path '/home/vsts' is denied」 · GitHub Actions での同じ問い · English