MENU

Azure DatabricksのContinuous Job変更で実行がキャンセルされる条件と自動化修正【2026年8月】

Azure

Azure DatabricksでContinuous JobをAPIやDeclarative Automation Bundles、運用スクリプトから管理している場合は、2026年8月上旬までに自動化の見直しが必要です。

結論として、Continuousスケジュールの追加・削除、Continuous JobのPause、active runのStopは、実行中のrunをキャンセルする動作になります。さらに、Pause中のContinuous JobをRunすると、単発実行ではなくJob自体がUnpauseされます。

従来の「Pauseしても現在のrunは継続する」「runを止めてもContinuous Jobが自動的に次のrunを開始する」といった前提で作られた自動化は、データ処理の中断や予期しない再開を引き起こす可能性があります。公式発表では変更時期を「2026年8月上旬」としており、2026年7月23日時点では正確な適用日は示されていません。(Microsoft Learn)

目次

8月のContinuous Job変更で変わる5つの動作

Azure Databricksが発表しているContinuous Jobの新動作を整理すると、次のようになります。(Microsoft Learn)

操作active runへの影響Continuous Jobの状態主な注意点
Continuousスケジュールを追加active runをキャンセル指定した状態でContinuous化PAUSEDで追加してもキャンセルされる
Continuousスケジュールを削除active runをキャンセルContinuousではなくなるAPIの設定漏れでも削除扱いになる可能性がある
Continuous JobをPauseactive runをキャンセルPaused「次回起動だけを止める」操作ではなくなる
Paused状態のJobをRunJobをUnpauseUnpaused単発実行のつもりでも継続実行が再開する
active runをStoprunを停止し、JobもPausePausedContinuous Jobが自動復旧しなくなる

特に重要なのは、ContinuousスケジュールをPaused状態で追加した場合でも、既存のactive runがキャンセルされる点です。

「実行を開始させないためにPausedで設定するのであれば安全」という判断はできません。スケジュールの状態ではなく、Continuousスケジュールを追加するという構成変更そのものがキャンセル条件になります。

現在のPause動作との違い

現在の一般的なジョブトリガーのドキュメントでは、トリガーをPauseしても、すでに開始しているrunは継続すると説明されています。また、Continuousトリガーを再開した時点でrunが実行中なら、そのrunの完了を待って次のrunを開始する動作になっています。(Microsoft Learn)

しかし、2026年8月上旬以降のContinuous Jobでは、Pauseするとactive runもキャンセルされます。

つまり、次のように認識を変更する必要があります。

従来の認識8月以降のContinuous Job
Pauseは新しいrunの開始だけを止めるPauseはactive runもキャンセルする
Stopした後はContinuous設定により再実行されるStopするとJob自体がPauseされる
Paused JobのRunは単発実行RunするとJob全体がUnpauseされる
Paused状態でContinuous設定を追加すれば安全Pausedで追加してもactive runはキャンセルされる

一般的なスケジュールやトリガーの説明を、そのままContinuous Jobへ適用しないことが重要です。

Continuous Jobの仕組みを理解しておく

Continuous Jobは、1つのrunを永久に動かし続ける仕組みとは限りません。現在のrunが完了または失敗すると、新しいrunを開始することでジョブを継続的に動かします。(Microsoft Learn)

そのため、次の2つは別の状態として管理する必要があります。

  • 現在のrunが実行中か
  • Continuous Job自体がPausedかUnpausedか

8月の変更後は、この2つの状態が連動するようになります。

たとえばactive runをStopすると、そのrunが終了するだけではありません。Continuous Job自体もPausedになるため、そのままでは次のrunが開始されません。

逆に、Paused状態のJobをRunすると、runを1回だけ開始するのではなく、Continuous Job自体がUnpauseされます。以後も継続的な実行が続く可能性があります。

実行キャンセルが発生する条件

Continuousスケジュールを追加したとき

Continuous設定を持っていないJobにContinuousスケジュールを追加すると、そのJobで実行中のrunがキャンセルされます。

これは追加する設定が次のどちらでも同じです。

continuous:
  pause_status: PAUSED
continuous:
  pause_status: UNPAUSED

Declarative Automation Bundlesでは、Continuous Jobの状態をcontinuous.pause_statusで定義でき、値にはPAUSEDまたはUNPAUSEDを指定します。(Microsoft Learn)

したがって、既存JobをContinuous Jobへ変更するデプロイは、単なる設定変更ではなく、active runを中断する変更として扱う必要があります。

Continuousスケジュールを削除したとき

JobからContinuous設定を削除した場合も、active runがキャンセルされます。

明示的に削除する処理だけでなく、次のようなケースにも注意が必要です。

  • JSONテンプレートからcontinuousが欠落した
  • 環境変数の展開に失敗し、Continuous設定が出力されなかった
  • 全設定を再登録する処理でContinuous設定を含め忘れた
  • IaCツールがContinuous設定を一度削除してから再作成した
  • PausedとUnpausedを切り替える過程でリソースを作り直した

特にJobs APIのresetを利用している自動化は要確認です。

jobs.updateは既存Jobの一部設定を追加・変更・削除するAPIですが、jobs.resetはJobの設定全体を置き換えます。resetのペイロードにContinuous設定が含まれていなければ、既存のContinuous設定が失われる可能性があります。(Databricks Documentation)

Continuous JobをPauseしたとき

8月以降は、Continuous JobをPauseするとactive runもキャンセルされます。

これまで次のような手順を使っていた場合は修正が必要です。

  1. Continuous JobをPauseする
  2. 現在のrunが自然に完了するまで待つ
  3. 設定やライブラリを更新する
  4. Jobを再開する

新動作では、手順1の時点でactive runがキャンセルされます。

ストリーミング処理や長時間のETLでは、チェックポイントの更新タイミングによって、再開後に一部処理が再実行される可能性があります。Pauseの前に、処理の冪等性、チェックポイント、外部システムへの書き込み状況を確認してください。

Paused状態のContinuous JobをRunしたとき

Paused状態のContinuous Jobに対するRun操作は、今後はJobのUnpauseも意味します。

jobs.run_nowは保存済みJobのrunを開始するAPIですが、Paused状態のContinuous Jobに対して使用すると、8月以降はContinuous JobそのものがUnpauseされます。(Databricks Documentation)

次のような運用は危険です。

本番Continuous JobはPauseしたまま、確認のため1回だけRunする

この操作を行うと、確認用の1回だけではなく、Continuous Jobの継続実行が再開します。

単発テストが必要な場合は、次のいずれかへ変更します。

  • 同じタスクを持つ手動実行専用Jobを用意する
  • 本番Jobを複製した検証用Jobを使う
  • 適用できるワークロードではjobs.runs.submitによる一回限りの実行を利用する

jobs.runs.submitはJob定義を受け取り、その場で1回実行します。保存済みContinuous Jobの状態を変更せずに検証できる可能性があります。(Databricks Documentation)

active runをStopしたとき

active runをStopすると、runが終了するだけでなくContinuous JobもPauseされます。

次のような自動復旧スクリプトは、そのままでは動かなくなります。

異常なrunを検出
↓
runをキャンセル
↓
Continuous設定により次のrunが自動開始されることを期待

8月以降は、runを停止した時点でJobもPausedになるため、次のrunは自動開始されません。

修正後は、次の流れにします。

異常なrunを検出
↓
runをStop
↓
runが完全に終了するまで待機
↓
JobがPausedになったことを確認
↓
原因を解消
↓
明示的にUnpauseまたはRun
↓
新しいrunの開始を確認

runのキャンセルAPIは非同期です。APIが正常終了しても、対象runが直ちに終了しているとは限りません。次の設定変更や再実行へ進む前に、runが終了状態になったことを確認する必要があります。(Databricks Documentation)

影響を受けやすい自動化

Jobs APIのupdateとreset

最優先で確認すべきなのは、Job設定を定期的に再同期するスクリプトです。

特に次の実装は影響を受けやすくなります。

  • 毎回Job定義全体をresetしている
  • 差分がなくてもContinuous設定を削除して再追加する
  • 環境ごとにContinuous設定の有無を切り替えている
  • デプロイ前にContinuous設定を一度削除している
  • Job設定のシリアライズ時に未指定フィールドを削除している

公式発表は、既存のContinuous設定を同一内容で再送した場合の動作までは説明していません。

そのため、「同じ設定を再適用するだけならキャンセルされない」と断定せず、非本番Jobで実際の差分適用方法を確認してください。重要なのはAPI名ではなく、最終的にContinuous設定が「なしからあり」「ありからなし」へ変化するかどうかです。

Declarative Automation Bundles

Declarative Automation Bundlesでは、次の設定が影響確認の対象になります。

resources:
  jobs:
    data_ingestion:
      continuous:
        pause_status: UNPAUSED

また、Bundleのカスタムプリセットでは、複数のトリガーやスケジュールをまとめてPAUSEDにできます。開発モードでも、デプロイしたトリガーやスケジュールをPauseする動作が利用されます。(Microsoft Learn)

これまでPAUSEDを「デプロイ後に新規実行を開始させないための安全設定」として利用していた場合、8月以降はactive runをキャンセルする可能性があります。

次の項目を確認してください。

  • 本番ターゲットにtrigger_pause_status: PAUSEDが適用されないか
  • 環境別の上書きでcontinuous.pause_statusが変化しないか
  • デプロイ時にContinuous設定が一時的に削除されないか
  • Job名やリソースキーの変更により再作成にならないか
  • 開発用設定を共有の本番Jobへ適用していないか

監視・自己修復スクリプト

監視処理でrunの停止や再実行を自動化している場合は、状態遷移を明示的に実装します。

修正前の想定が次のようになっていないか確認してください。

  • runをStopすればContinuous Jobが自動的に再起動する
  • Pauseしても現在のrunは最後まで動く
  • Paused JobをRunしてもPaused状態は維持される
  • Continuous設定を削除しても現在のrunは継続する
  • Continuous設定を追加しても既存runには影響しない

これらは、8月以降の動作と一致しません。

安全な自動化へ修正する手順

状態変更を「破壊的操作」として分類する

次の操作は、active runがある場合に中断を発生させる操作として扱います。

ADD_CONTINUOUS
REMOVE_CONTINUOUS
PAUSE_CONTINUOUS
STOP_ACTIVE_RUN

Paused JobへのRunはキャンセル操作ではありませんが、JobをUnpauseするため、別の破壊的な状態変更として扱います。

RUN_PAUSED_CONTINUOUS

active runを事前確認する

設定変更前に、対象Jobのactive runを取得します。

概念的な処理は次のようになります。

active_runs = list_active_runs(job_id)

if action in {
    "ADD_CONTINUOUS",
    "REMOVE_CONTINUOUS",
    "PAUSE_CONTINUOUS",
    "STOP_ACTIVE_RUN",
}:
    if active_runs and not maintenance_window_approved:
        raise RuntimeError(
            "Active runが存在するため、Continuous Jobの状態変更を中止します"
        )

perform_action(action)

wait_until_previous_runs_are_terminal()
verify_expected_job_state()

実際には、次の情報もログへ残します。

  • Job ID
  • 変更前のContinuous状態
  • 変更前のactive run ID
  • 実行した操作
  • 変更を実行したユーザーまたはサービスプリンシパル
  • 変更時刻
  • runの最終結果
  • 変更後のPaused／Unpaused状態
  • 再開後のrun ID

メンテナンス時間帯で状態変更する

Continuous Jobは常時runが存在する運用が多いため、「active runがなくなるまで待つ」という方法が現実的でない場合があります。

その場合は、次の操作をメンテナンス対象にします。

  • Continuousスケジュールの追加
  • Continuousスケジュールの削除
  • Continuous JobのPause
  • active runのStop
  • Built-in Continuous PipelineからContinuous Job管理への切り替え
  • Job定義全体のreset
  • BundleによるContinuous設定の変更

状態変更の前後で、データソース側の取り込み停止、チェックポイント、下流処理、外部APIへの書き込みを確認してください。

Stop後の再開を明示する

Stop処理と再開処理を1つの曖昧な「再起動」関数にまとめず、次のように分離します。

stop_run()
wait_for_terminal_state()
verify_job_is_paused()
resolve_problem()
unpause_job()
verify_new_active_run()

Stopに失敗した場合と、Stopには成功したもののUnpauseに失敗した場合を、別の障害として通知できるようにします。

単発実行とContinuous実行を分離する

同じJobを単発実行とContinuous実行の両方に使うと、Run操作の意味が分かりにくくなります。

本番運用では、次のように分離する方法が安全です。

用途推奨構成
本番の継続取り込みContinuous Job
手動での再処理Manual Job
パラメーターを変えた検証検証専用Job
一回限りの処理jobs.runs.submitまたはManual Job
障害復旧専用Runbookから明示的にStop、修復、Unpause

これにより、確認作業のRunが本番Continuous Jobを意図せずUnpauseする事故を防げます。

自動化テストへ追加すべきケース

少なくとも次のテストを非本番環境へ追加します。

初期状態操作期待する結果
通常Jobにactive runがあるPausedのContinuous設定を追加既存runがキャンセルされ、JobはPausedのContinuous状態になる
通常Jobにactive runがあるUnpausedのContinuous設定を追加既存runがキャンセルされ、JobはUnpausedのContinuous状態になる
Continuous Jobにactive runがあるContinuous設定を削除active runがキャンセルされ、Continuous設定がなくなる
UnpausedのContinuous Jobにactive runがあるPauseactive runがキャンセルされ、JobがPausedになる
PausedのContinuous JobRunrunが開始され、JobがUnpausedになる
Continuous Jobにactive runがあるStoprunが停止し、JobもPausedになる
Continuous Jobにactive runがある同一設定を再適用使用ツールが削除・再追加を行わないか実測する
Continuous Jobにactive runがあるBundleを再デプロイactive runが維持されるか、設定差分とともに確認する

テストでは、APIリクエストが成功したかだけでなく、次の事後条件まで検証します。

  • 変更前のrunがキャンセルされたか
  • JobがPausedかUnpausedか
  • 意図しない新しいrunが開始していないか
  • 再開が必要なケースで新しいrunが開始したか
  • キャンセル通知や監視アラートが過剰発火していないか
  • 下流システムに重複データが発生していないか

新しい読み取り専用APIフィールドへの対応

8月の変更では、Continuous Jobの状態を追跡する新しい読み取り専用APIフィールドも追加される予定です。ただし、2026年7月23日時点の公式案内では、フィールド名や詳細なスキーマは示されていません。(Microsoft Learn)

現時点でフィールド名を推測してコードへ組み込むべきではありません。

自動化は次の方針で準備します。

  1. APIレスポンスの未知フィールドを無視できるようにする
  2. 厳格なJSONスキーマ検証で新フィールドをエラーにしない
  3. SDKとCLIを更新できる手順を用意する
  4. 公式APIリファレンス更新後にフィールドを状態確認へ利用する
  5. 設定上の希望状態と、実際の稼働状態を別々に記録する

たとえばcontinuous.pause_statusは設定上の希望状態です。新しい読み取り専用フィールドは、実際のContinuous Jobの状態を確認する用途になると考えられますが、正式なフィールド仕様が公開されるまでは断定できません。

Continuous PipelineはContinuous Jobでラップする

2026年8月上旬以降、Lakeflow Pipelinesの画面からContinuousスケジュールを設定できるようになります。この方法で設定すると、PipelineがContinuous Jobでラップされ、JobがPipelineの実行ライフサイクルを管理します。

Databricksは、新しくContinuous Pipelineを作成する場合、Pipeline内蔵のContinuous設定よりも、Continuous Jobでラップする構成を推奨しています。JobレベルのPerformance modeなども設定できます。(Microsoft Learn)

新規Pipelineの推奨構成

Continuous Job
└─ Pipeline task
   └─ Lakeflow Pipeline

この構成では、Pause、Unpause、Stop、再実行といったライフサイクル管理をJob側へ集約できます。

既存Pipelineは直ちに移行しなくてもよい

Pipeline内蔵のContinuous設定は、8月の変更後も削除される予定ではありません。

そのため、既存Pipelineを一斉に移行する必要はありません。次の条件に該当するPipelineから移行を検討します。

  • JobとPipelineの状態管理を統一したい
  • Jobレベルの設定を利用したい
  • APIやBundleでライフサイクルを一元管理したい
  • 運用担当者がPipelineとJobを別々に管理している
  • 新しいContinuous Pipelineを構築する

既存Pipelineの移行は、実行中の処理を中断する可能性がある変更として非本番環境で確認し、必要に応じてメンテナンス時間帯に実施してください。

8月上旬までに確認するチェックリスト

  • Jobs APIを利用するコードからcontinuous、pause_status、reset、updateを検索する
  • run-nowを呼び出す監視ツールや外部オーケストレーターを確認する
  • runのStopやCancel後に自動再開を期待している処理を修正する
  • Paused状態の本番Continuous Jobを単発実行している手順を廃止する
  • Bundleのtrigger_pause_statusとcontinuous.pause_statusを確認する
  • Job設定全体を置き換える処理でContinuous設定が欠落しないようにする
  • 状態変更前にactive runを確認するガード処理を追加する
  • StopやCancelの完了を待ってから次の操作へ進む
  • 5つの新動作を自動化テストへ追加する
  • 新規Continuous PipelineはContinuous Jobでラップする
  • 非本番のカナリアJobで8月の動作変更を確認する
  • 新しい読み取り専用APIフィールドの正式仕様を確認する

まとめ

2026年8月上旬の変更後は、Continuous JobのPauseやStopを、単なるスケジューラー制御として扱えません。

Continuousスケジュールの追加・削除、Pause、active runのStopは、実行中のrunをキャンセルする操作になります。また、Paused JobへのRunはJobをUnpauseするため、単発実行として利用できません。

まず既存のAPI、Bundle、監視スクリプト、手動Runbookから、continuous、pause_status、run-now、reset、runのStop処理を洗い出してください。そのうえで、active runの事前確認、メンテナンス時間帯での状態変更、Stop後の明示的な再開、単発JobとContinuous Jobの分離を実装します。

新しいContinuous Pipelineについては、Pipeline内蔵のContinuous設定ではなく、Continuous Jobでラップする構成を基本とするのが、今後のライフサイクル管理に合わせた運用方法です。

Azure
Azure Databricks Jobs API Lakeflow Jobs Lakeflow Pipelines Continuous Job

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次