公開中のサイトや業務システムに不具合が出たとき、Cloudflare Workersなら wrangler rollback で直前の版に戻せます。障害対応の最中なら、画面に「SUCCESS」と出た時点で戻ったと判断し、次の確認に移るのが自然です。
ところが、ロールバックを途中で中止したのに、その直後に「SUCCESS … has been deployed to 100% of traffic.」と表示される不具合がありました。戻したつもりで、実際には問題のある版が配信され続けていることになります。2026年10月16日公開の wrangler 4.151.1 で修正されています。
本記事では、Wranglerの変更履歴（CHANGELOG）と、npmに公開された 4.131.1・4.151.0・4.151.1 の実装を確認し、編集部の検証環境でローカルのスタブ（Cloudflare APIの代わりに決まった応答を返す小さなサーバー）に向けて実際に wrangler rollback を動かしました。Cloudflareの実アカウントでのロールバックは行っていません。
何が起きていたか
wrangler rollback は、戻す先の版と今の版でシークレット（APIキーなどの秘密の値）が違うと、追加の確認を出します。この確認は 3.62.0（2024年6月）から入っています。
The following secrets have changed since version … was deployed. Please confirm you wish to continue with the rollback
ここで「no」と答えた場合の扱いに不具合がありました。4.151.1 の変更履歴には次のように書かれています。
Previously, declining the “The following secrets have changed…” confirmation printed “Aborting rollback…” and then also printed a success message and the target version as the “Current Version ID”, even though no deployment was made and the original version was still live.
中止の表示の後に成功の表示と、戻す先の版のIDが「Current Version ID」として出る。しかしデプロイは行われておらず、元の版が配信されたまま、という内容です。npmの各版の実装を読むと、4.151.0 までは中止の表示（cancel("Aborting rollback...")）の後に処理が続き、4.151.1 で return; が加わっていました。
スタブで動かして確かめた
検証環境（Linux、Node.js v22.22.0）で、CLOUDFLARE_API_BASE_URL をローカルのスタブに向けて実行しました。スタブは、1回目のデプロイの要求をシークレットの変更を理由に断り（エラーコード 10220）、?force=true 付きの再送だけを受け付けます。エラーの文言やIDは検証用に作ったもので、Cloudflareの実際の応答ではありません。
4.151.0 で、シークレットの確認に「no」と答えたときの出力の最後です。
╰ X Aborting rollback...
│
╰ SUCCESS Worker Version aaaaaaaa-0000-4000-8000-000000000001 has been deployed to 100% of traffic.
Current Version ID: aaaaaaaa-0000-4000-8000-000000000001スタブの記録では、デプロイの要求は断られた1回だけで、再送はありません。それでも成功と表示されました。2026年9月公開の 4.131.1 でも同じ出力でした。4.151.1 では「Aborting rollback…」で止まり、成功の表示は出ませんでした。
版を上げても残る2つの注意点
検証では、修正とは別に運用で気をつけたい点が2つ見えました。
1つ目は終了コードです。 中止したときの終了コードは、4.151.0 でも 4.151.1 でも 0（成功）でした。中止の表示は画面への出力だけで、終了コードは変わりません。スクリプトから実行して終了コードで成否を判断していると、中止に気づけません。
2つ目は、CIなどの非対話の環境での確認です。 Wranglerは、端末が対話できない環境やCIの環境変数がある環境では、確認に既定の値で答えます。シークレットの確認の既定は「yes」で、CI=1 を付けて実行すると次のように表示され、?force=true 付きで再送して成功しました。
? The following secrets have changed since version aaaaaaaa-0000-4000-8000-000000000001 was deployed. Please confirm you wish to continue with the rollback
* API_TOKEN
* WEBHOOK_SECRET
🤖 Using fallback value in non-interactive context: yesつまり自動化したロールバックでは、シークレットが変わっていても人に確認せずに進みます。force=true で戻したときに、シークレットがどちらの値になるかは、Cloudflareのロールバックの資料（Rollbacks、2026年7月15日更新）には書かれておらず、スタブでも確かめられていません。シークレットを入れ替えた直後のロールバックは、外部サービスとの連携が切れる可能性があるものとして扱ってください。
運用で決めておくこと（編集部の提案）
- Wranglerを 4.151.1 以降にする:
package.jsonで版を固定している場合は、ロールバックの手順書と一緒に見直します。手で実行する人の端末と、CIの両方です - 表示ではなく、配信中の版で確かめる: ロールバックの後に
wrangler deployments statusで、100%配信されている版が戻したい版になっているかを見ます。スクリプトにするなら、次のように比べると、中止や反映漏れを終了コードで検出できます - 自動のロールバックとシークレットの変更を分けて考える: シークレットを変えた直後は、戻す先の版が古い値を前提にしていないかを人が判断する、といった決まりを作ります。今のシークレットの名前は
wrangler versions secret listで確認できます
#!/usr/bin/env bash
# ロールバック後に、本番で100%配信されている版が戻したい版と一致するかを確かめる
set -euo pipefail
TARGET="$1" # 戻したい Version ID
LIVE=$(npx wrangler deployments status --json \
| jq -r '.versions[] | select(.percentage == 100) | .version_id')
if [ "$LIVE" != "$TARGET" ]; then
echo "ロールバックは反映されていません（配信中: ${LIVE:-なし}）" >&2
exit 1
fi
echo "配信中の版: $LIVE"このスクリプトは同じスタブに対して実行し、配信中の版と違うIDを渡すと終了コード1、同じIDを渡すと0になること、2つの版を50%ずつ配信している状態（100%の版がない状態）では「配信中: なし」で1になることを確かめています。
Workersの権限を制作会社などに渡している場合は、誰がロールバックを実行できるかも手順書に書いておきます。Worker単位の権限の分け方はWorker単位で権限を渡す記事で、ブランチごとの確認URLを使った公開前の確認はWorkersのプレビューの記事で整理しています。Cloudflareの新しいCLI「cf」への移行を検討している場合は、cfとWranglerの使い分けもあわせて確認してください。
まとめ
まず、手元とCIで使っているWranglerの版を npx wrangler --version で確かめ、4.151.0 以前ならロールバックの手順に「配信中の版を確かめる」工程を足してください。版を上げた後もこの工程は残しておくと、終了コードやCIの自動の「yes」に頼らずに、戻ったかどうかを判断できます。
2026年10月19日に、cloudflare/workers-sdk の
packages/wrangler/CHANGELOG.md（4.151.1・3.62.0）と、npmに公開された wrangler 4.131.1・4.151.0・4.151.1 のwrangler-dist/cli.js、Cloudflareのロールバックの資料を確認しました（資料調査）。編集部の検証環境（Linux、Node.js v22.22.0）で、ローカルのスタブに向けて3つの版のwrangler rollbackを対話端末とCI=1の両方で実行し、wrangler deployments status --jsonと本文のスクリプトも実行しました（実機検証）。スタブの応答は検証用に作ったもので、Cloudflareの実アカウントでの挙動、force=trueのときのシークレットの値、ダッシュボードからのロールバックは確認していません。
Cloudflare Workersで動かしているサイトや業務システムの、デプロイ・ロールバックの手順づくりやCIの見直しは、グリームハブの開発・AI・自動化のご相談で承っています。構成によって確かめる項目が変わるため、お問い合わせからご相談ください。
