長期実行の版管理

対象本文

第14章の長期実行を含むrollout、旧版排出、段階配備、migration boundaryを補います。単純なstateless requestのtraffic splitではなく、履歴・session・side effectを持つ実行を対象にします。

収集方法

2026年7月10日にAWS Step Functions、Google Cloud Workflows、Microsoft Durable Task、Temporal、Cloudflare Workersの版管理一次資料を同じ軸で比較しました。

現在の答え

各社は、新版と旧版を同時に扱い、既存実行を無条件で新版へ差し替えない方向へ収斂しています。差は、版をstate machine、workflow revision、orchestration instance、worker deployment、script bundleのどこへ結ぶかにあります。

基盤版の単位新規実行既存実行注意する境界
AWS Step Functionsimmutable state machine versionとaliasaliasのrouting configurationでversionへ配分開始時に解決したversionで実行alias変更は新規開始に作用。external task/resource版は別
Google Cloud Workflowsdeploymentごとのrevision現行revisionで開始更新は進行中executionへ影響せず、executionにrevision IDを記録called service、secret、container imageはworkflow revision外
Microsoft Durable Taskorchestration versionとworkerの適合strategyclient/worker設定でversionを関連付けinstance作成時のversionを基準に対応workerへroutecode changeのreplay compatibilityとmigrationを検証
TemporalWorker Versioning、deployment/version、pinningrouting/rampでcompatible deploymentへ配分pinned workflowは対応workerへ。Continue-As-New等を更新境界にできるpatching、activity版、child workflow、external side effect
Cloudflare WorkersWorker versionとdeploymentdeploymentで複数versionへ割合配分version affinityで一連のrequestを同版へ寄せられるDurable Object/Workflow/storage stateはbundle版に自動包含されない

安全な既定は次です。

  1. 新規実行だけを段階配分する。
  2. 既存実行は開始時のrelease_id、workflow版、model/prompt/tool版へ固定して排出する。
  3. migrationはconversation boundary、human approval待ち、Continue-As-New等の明示的な安全境界だけで行う。
  4. input、checkpoint、policy、side effect、compensationが新旧で互換だと試験できない限り、running instanceを書き換えない。

rollbackも一つではありません。入口trafficを旧版へ戻すこと、running workflowを停止すること、作用済み結果を補償すること、modelやtoolだけを戻すことを分けます。Cloudflareのversion affinityはHTTP request群の一貫性に役立ちますが、durable workflow history全体の版固定と同じ保証ではありません。

一次資料

既知の未知

変更履歴