RunPod Hub のビルドに時間制限はありますか？

あります。実測では 1800 秒 (30 分) を超えた時点で強制終了され、ログに `Build exceeded maximum time limit of 1800 seconds (30.0 minutes). Build terminated.` と記録されました。手元の構成ではモデル 28.9GB の逐次ダウンロードに 22 分、イメージの書き出しと転送に 8 分かかり、ちょうど上限で打ち切られています。モデルを焼き込む設計では、この 30 分が最初の壁になります。書き出しと転送に 8 分かかるため、ダウンロードに使えるのは 20 分程度が上限です。並列化がその対処の 1 つになります。

Docker のマルチステージビルドで何が速くなりますか？

依存関係のないステージを BuildKit が並列に実行するため、逐次では合計時間だったダウンロードが、最も大きいファイル 1 本ぶんの時間に近づきます。手元では 4 つのモデル (19.12GB / 8.74GB / 0.79GB / 0.24GB) をステージごとに分けました。あわせて最終ステージの COPY もモデルごとに分け、レイヤーを 4 つに保っています。1 つにまとめると 29GB 弱の単一レイヤーになり、書き出しと転送がさらに遅くなるためです。結果として転送方式が変わり、96 秒かかっていた tarball 送信が 33 レイヤーの並列アップロード 34 秒 (1045.9 MB/s) になりました。

worker-comfyui の base イメージはどれを選ぶべきですか？

宣言する CUDA バージョンに合わせてください。素の `5.8.6-base` は comfy-cli が既定で入れる PyTorch を含み、これは CUDA 12.8 より新しい版を対象にしています。`hub.json` で `allowedCudaVersions: ["12.8"]` を指定すると、ワーカーが起動時に `The NVIDIA driver on your system is too old (found version 12080)` と `no kernel image is available` で落ちます。CUDA 12.8 を使うなら `5.8.6-base-cuda12.8.1` を指定してください。厄介なのは、イメージのビルドとレジストリへの push は正常に完了する点です。失敗は実行時にしか現れず、Hub の画面上ではテストのタイムアウトとして表示されます。

RunPod Serverless のコールドスタートはどれくらいかかりますか？

イメージがそのマシンにキャッシュされているかで桁が変わります。34.74GB のイメージを新しいワーカーへ配る場合、実測で delayTime が 724,833 ミリ秒 (12.1 分) でした。ログを追うと大半はレイヤーの pull と展開に費やされています。一方、同じエンドポイントで直後にリクエストを送ると delayTime は 792 ミリ秒でした。つまり初回だけが極端に重く、暖まっていれば一瞬です。既成ワーカーで測った 22.6 秒という値も、他の利用者によってイメージが行き渡ったマシンに当たった結果だと考えられます。

イメージのダウンロード時間は課金されますか？

実測では現れませんでした。12.1 分のコールドスタートを含む時間帯について、Serverless の課金レコードに新しい記録がなく、30 分後に再取得しても合計額が変わりません。公式ドキュメントは課金対象として「初期化・処理・アイドル待機」を挙げ、`You're billed from when a worker starts until it fully stops` と記載していますが、その手前のイメージ取得については触れていません。ただし断定は避けるべきです。生成そのもの (1 秒) の課金も現れておらず、金額が小さすぎて丸められている可能性が残るためです。一方で 12 分ぶんは RTX 4090 の $1.10/h で計算しても $0.22 になり、丸めで消える額ではありません。少なくとも取得時間がそのまま秒課金されてはいない、とは言えます。自分の構成で課金レコードを確認してから判断してください。

GitHub のリリースを作れば Hub は自動でビルドしますか？

検知は 30 分間隔です。Hub のリリース一覧に `Releases are automatically checked every 30 minutes` と表示され、同じ画面の「Check for new release」を押すと即座に取り込まれます。注意点として、`gh release create --target` にコミット SHA を渡してはいけません。RunPod はこの値をブランチ名として `git clone` に渡すため、`Remote branch not found in upstream origin` で失敗します。再ビルドを促したい場合は、SHA ではなくブランチ (main) を対象にタグを打ち直してください。

エンジニアリング

RunPod で ComfyUI ワーカーを自前で作る — 30 分のビルド上限と 4 つの罠

既成ワーカーが 16:9 を出せなかったので、Qwen-Image-Edit-2511 を焼き込んだワーカーを自作しました。RunPod Hub のビルドは 30 分で打ち切られ、モデル 28.9GB を逐次ダウンロードすると間に合いません。マルチステージ化・CUDA の一致・一時障害・リリースの指定方法という 4 つの罠を、実測値つきで記録します。コールドスタート 12.1 分と生成 1.0 秒という極端な差も測れました。AI 駆動開発のクリエイティブスタジオによる検証記録の 2 本目です。

Dodai/ バックエンド / インフラエンジニア·2026年8月18日公開·約 10 分で読めます

#RunPod#ComfyUI#Docker#Qwen-Image-Edit#コールドスタート

RunPod で ComfyUI ワーカーを自前で作る — 30 分のビルド上限と 4 つの罠

この記事のポイント

RunPod Hub のビルドは 1800 秒 (30 分) で強制終了する。モデル 28.9GB を逐次ダウンロードすると 22 分を消費し、イメージの書き出しに間に合わない
モデルごとにビルドステージを分けると BuildKit が並列に取得する。あわせてレイヤーを分けたことでイメージ転送も tarball 96 秒から並列 34 秒へ短縮された
素の `5.8.6-base` に入る PyTorch は CUDA 12.8 より新しい版を対象にしている。`hub.json` で 12.8 を指定すると起動時に `no kernel image is available` で落ちる
コールドスタートは実測 12.1 分。34.74GB のイメージをキャッシュのないマシンへ配る時間で、暖まっていれば 792 ミリ秒
イメージの取得時間は課金レコードに現れなかった。12 分ぶんは $0.22 相当で丸めでは消えないが、生成ぶんも計上されていないため断定は避ける

結論｜30 分の壁は並列化で越えられる。ただし初回起動は 12 分かかる

前回は、RunPod Hub にある既成の Qwen-Image-Edit ワーカーが 16:9 を出せないところで終わりました。API に width を渡しても無視され、出力は正方形のままです。原因はワークフローがイメージに焼き込まれていることで、利用者側からは手が出せません。

そこで、モデルを焼き込んだワーカーを自分で作りました。結果を先に置きます。

項目	既成ワーカー	自前ワーカー
出力サイズ	1024×1024 (制御できない)	1360×768
コールドスタート	22.6 秒	12.1 分 / 暖機時 0.8 秒
生成	27.7 秒	1.0 秒
ワークフローの変更	不可	リクエストごとに可能

ただし条件は揃っていません。既成側は RTX 4090 で既成のワークフロー、自前側は RTX 5090 で 4 ステップの LoRA 入りです。コールドスタートの 22.6 秒も、後述するとおりキャッシュ済みのマシンに当たった値でした。この表は同じ土俵の比較ではありません。

そのうえで、狙いどおり 16:9 は出せました。一方で 初回のコールドスタートが 12.1 分 かかっています。34.74GB のイメージをキャッシュのないマシンへ配る時間です。

そこに至るまでに 4 回つまずき、原因はすべて別でした。以下はその記録です。

設計｜ComfyUI のワークフローをイメージに入れない

既成ワーカーの問題は「ワークフローが固定されていること」でした。ならば逆をやります。

要点

モデルはイメージに焼き込み、ワークフローは API のリクエストごとに渡す。出力サイズもステップ数も LoRA の有無も、再ビルドなしで変えられます。

モデルをネットワークボリュームに置く選択肢もありますが、採りませんでした。ボリュームは存在するだけで容量課金が続き ($0.07/GB/月)、読み出しのぶんコールドスタートも遅くなるためです。焼き込めばイメージは RunPod のレジストリに載り、配布の最適化はプラットフォーム側の仕事になります。

焼き込んだのは 4 つ、合計 28.9GB です。

ファイル	サイズ	役割
`qwen_image_edit_2511_fp8mixed`	19.12GB	拡散モデル本体 (FP8 量子化)
`qwen_2.5_vl_7b_fp8_scaled`	8.74GB	テキストエンコーダ
`Qwen-Image-Edit-2511-Lightning-4steps`	0.79GB	4 ステップ生成用 LoRA
`qwen_image_vae`	0.24GB	VAE

ワークフローのどこがサイズを決めているか

既成ワーカーで出力を正方形にしていたのは ImageScaleToTotalPixels でした。合計 1 メガピクセルへ正規化する設定で、縦横比は入力画像に従います。ここを ImageScale に差し替えれば、幅と高さを直接指定できます。

{
  "11": {
    "class_type": "ImageScale",
    "inputs": {
      "image": ["10", 0],
      "upscale_method": "lanczos",
      "width": 1360,
      "height": 768,
      "crop": "center"
    }
  }
}

このノードの出力は 3 か所へ流れます。潜在表現の元になる VAEEncode と、正負の画像コンディショニング (TextEncodeQwenImageEditPlus) の両方です。つまり 出力の縦横比を決めているのはリクエストの width ではなく、このノード ということになります。

1360×768 は約 1.04 メガピクセルで、ほぼ 16:9 です。Qwen-Image は 1 メガピクセル前後で学習されているため、ここを大きくしすぎると品質が落ちます。配信サイズへの拡大は呼び出し側でやるほうが安全です。

ステップ数と cfg は KSampler にあり、LoRA の有無は LoraLoaderModelOnly を挟むかどうかで決まります。いずれもリクエストごとに変えられるので、画風やポーズをどこまで動かせるかの実験は、再ビルドなしで回せます。それは次回の主題です。

罠 1｜RunPod Hub のビルドは 30 分で打ち切られる

最初のビルドは 30 分で強制終了しました。

#13 exporting layers 386.0s done
#13 sending tarball 96.1s done
#13 CANCELED
ERROR: failed to build: failed to solve: Canceled: context canceled
Build exceeded maximum time limit of 1800 seconds (30.0 minutes). Build terminated.

内訳は、モデルのダウンロードとレイヤー作成に約 22 分、イメージの書き出しと転送に約 8 分。ちょうど上限で切られています。書き出しの 8 分は削れないので、ダウンロード側を詰めるしかありません。

マルチステージで並列に取りに行く

BuildKit は依存関係のないステージを並列に実行します。モデルごとにステージを分ければ、逐次で合計だった時間が、最も大きい 1 本ぶんに近づきます。

FROM runpod/worker-comfyui:5.8.6-base-cuda12.8.1 AS base
 
FROM base AS diffusion
RUN mkdir -p /models/diffusion_models \
 && wget -q --tries=3 -O /models/diffusion_models/qwen_image_edit_2511_fp8mixed.safetensors \
      https://huggingface.co/Comfy-Org/Qwen-Image-Edit_ComfyUI/resolve/main/...
 
FROM base AS text-encoder
RUN ...
 
FROM base AS vae
RUN ...
 
FROM base AS lora
RUN ...
 
FROM base
COPY --from=diffusion    /models/diffusion_models/ /comfyui/models/diffusion_models/
COPY --from=text-encoder /models/text_encoders/    /comfyui/models/text_encoders/
COPY --from=vae          /models/vae/              /comfyui/models/vae/
COPY --from=lora         /models/loras/            /comfyui/models/loras/

最終ステージの COPY をモデルごとに分けているのが 2 つ目の要点です。1 つにまとめると 29GB 弱の単一レイヤーになり、書き出しと転送がさらに遅くなります。

この 2 点で、ビルドは 30 分以内に収まりました。あわせて イメージの転送方式そのものが変わっていました。レイヤーを分けたことが直接の原因かどうかまでは切り分けられていません。

[status] 33/33 layers 34.74GB in 31.46s @ 1130.8 MB/s
✓ Pushed 34.74GB in 34.0s (1045.9 MB/s)
Successfully pushed image to registry.

罠 1 のビルドで 96 秒かけて tarball を送っていた区間が、(base イメージのぶんを含めて) 33 レイヤーの並列アップロード 34 秒になっています。

ダウンロードは wget で絶対パスに落とす

あわせて comfy model download をやめ、wget で絶対パスへ直接落とすように変えました。前者は配置先が comfy-cli の既定ワークスペース設定に依存し、そこが正しいかを一度も検証できていなかったためです。ビルドが最後まで通っていない段階では、モデルが所定の位置に置かれる保証がありません。

罠 2｜ComfyUI の base イメージと CUDA が合わないと起動しない

次のビルドは完走し、レジストリへの push も成功しました。しかしテストが落ちます。ログを開くと理由が書かれていました。

worker-comfyui: FAIL: The NVIDIA driver on your system is too old (found version 12080).
worker-comfyui: GPU is not available or incompatible with this PyTorch build
worker-comfyui: A 'no kernel image is available' error means this torch build lacks kernels for this GPU

12080 は CUDA 12.8 のことです。素の 5.8.6-base には comfy-cli が既定で入れる PyTorch が含まれ、それが 12.8 より新しい CUDA を対象にしていました。hub.json では 12.8 のホストを指定していたので、噛み合いません。

対処は base タグの変更だけです。

- FROM runpod/worker-comfyui:5.8.6-base AS base
+ FROM runpod/worker-comfyui:5.8.6-base-cuda12.8.1 AS base

注意

この失敗は実行時にしか現れません。ビルドログは最後まで健全に見え、Hub の画面上では「テストのタイムアウト」として表示されます。ログをいくら読んでも原因にたどり着けないので、CUDA の指定と base タグの対応を先に確認してください。

罠 3｜理由の書かれない失敗がある

base を差し替えたビルドは、95 秒で終了しました。

03:47:43 Successfully cloned repository ... at main
03:47:46 Build using docker
03:49:17 #6 [internal] load metadata for ...5.8.6-base-cuda12.8.1
03:49:18 #8 transferring context: 2B done
03:49:18 #8 DONE 0.0s

ここで終わりです。エラーメッセージがありません。clone も buildkit の起動も base イメージの解決も通っており、モデルのダウンロードに入る前に落ちています。設定の誤りなら base の解決で止まるはずなので、構成の問題ではなさそうでした。

同じ内容をもう一度投げたところ、今度は完走しました。RunPod 側の一時的な失敗だったと考えられます。ログに理由がないときは、構成を疑う前に一度そのまま再投入するほうが早いことがあります。

罠 4｜RunPod Hub のリリース対象にコミット SHA を指定しない

再ビルドを促すために、同じコミットを指すリリースを作ろうとして --target に SHA を渡しました。これが失敗します。

[WARNING] Git clone failed with return code 128.
warning: Could not find remote branch 6aac241631c05b0311c2ccd4542cee234c63f7f4 to clone.
fatal: Remote branch 6aac241631c05b0311c2ccd4542cee234c63f7f4 not found in upstream origin.

RunPod はリリースの対象をブランチ名として git clone に渡します。SHA は受け付けません。再ビルドしたいときは、ブランチ (main) を対象にタグを打ち直してください。

あわせて Hub の挙動を 2 つ。リリースの検知は 30 分間隔 で、Releases タブの「Check for new release」を押すと即座に取り込まれます。Setup タブにも同じラベルのボタンがありますが、こちらでは反応しませんでした。

実測｜コールドスタート 12.1 分、生成 1.0 秒

ビルドが通り、テストも成功したので、実際に 1360×768 を生成しました。

{
  "status": "COMPLETED",
  "delayTime": 724833,
  "executionTime": 1002
}

出てきたのがこの 1 枚です。既成ワーカーでは正方形にしかならなかった構図が、指定どおり 1360×768 で返っています。

自前ワーカーが出力した 1360x768 の画像。ターコイズの髪に金色の瞳のキャラクターが手を上げ、背景は無地の淡いミント色

delayTime が 724,833 ミリ秒 = 12.1 分。ワーカーのログを見ると、大半はイメージのレイヤー展開に費やされていました。

dad7e654d590 Extracting [==============================>  ] 6.02GB/7.625GB

一方 executionTime は 1,002 ミリ秒です。既成ワーカーの 27.7 秒から桁が変わりました。GPU が RTX 5090 だったことと、4 ステップの Lightning LoRA が効いていると見られます。どちらの寄与が大きいかは分けて測っていません。

そして、暖まった状態で続けて投げると delayTime は 792 ミリ秒 でした。

状態	delayTime
キャッシュのないマシン	12.1 分
イメージがキャッシュ済み	0.8 秒

前回の試算は 1/27 になる

生成が 27.7 秒から 1.0 秒になったので、前回の見積もりが変わります。月 5,000 枚に必要な GPU 時間は 138,500 秒 (約 38.5 時間) と置いていましたが、1.0 秒/枚なら 5,000 秒、約 1.4 時間です。必要な GPU 時間が 1/27 になります。

ここにコールドスタートが乗りますが、後述するとおりその時間は課金レコードに現れませんでした。RTX 5090 の Serverless 単価は前回の単価表に載せていないため、金額の再計算はここでは行いません。

FIXIT

えっ、12 分と 0.8 秒って差がありすぎない？

Dodai

イメージが手元にあるかどうかの差です。34.74GB を配る時間がそのまま出ています。

FIXIT

じゃあ、毎回 12 分待たされるってこと？

Dodai

同じマシンに当たれば待ちません。当たらなければ、また配り直しです。

前回の 22.6 秒は同じ土俵ではなかった

前回の数字に補足を入れておきます。既成ワーカーで測った 22.6 秒のコールドスタート は、他の利用者によってイメージが各マシンへ行き渡った状態での値だったと考えられます。デプロイ数の多い既成ワーカーと、利用者が自分だけの自前ワーカーでは、キャッシュの当たりやすさが違います。

前回 6 回計測したとき、起動時間は 18.5 秒から 159.5 秒まで振れました。あのばらつきも、当たったマシンにイメージがあるかどうかで説明がつきます。

つまり自前ワーカーの弱点は、イメージが大きいことそのものよりも、配布が進んでいないこと にあります。利用が増えれば自然に解消する種類の問題ですが、立ち上げ期には効きます。

課金｜イメージの取得時間は課金されなかった

12 分も待たされたので費用を心配しましたが、その時間は課金レコードに現れませんでした。

期間 2026-08-16 14:00 → 2026-08-17 04:00 UTC
serverless 合計 $0.16972
自前ワーカーのレコード: なし

$0.16972 は前回の検証で使った既成ワーカーのぶんです。30 分後に再取得しても合計額は変わらず、集計の遅れではありませんでした。

公式ドキュメントは課金対象として「初期化・処理・アイドル待機」を挙げ、You're billed from when a worker starts until it fully stops, rounded up to the nearest second. と書いています。ただし その手前のイメージ取得については触れていません。

もっとも、この観測だけで「取得時間は無料」と断じるのは行き過ぎです。生成そのもの (1 秒) の課金も現れていません。 前回はテストの実行分が課金されると書きましたが、今回の 4 回ぶんも同様に見当たりません。金額が小さすぎて丸められている可能性が残ります。

そのうえで、12 分ぶんは丸めで消える額ではありません。RTX 4090 の $1.10/h で計算しても $0.22 になり、合計額の変化として現れるはずです。それが出ていないので、少なくとも取得時間がそのまま秒課金されてはいない、とは言えます。

コツ

モデルを焼き込む設計の弱点は「初回が遅い」ことであって、「初回が高い」ことではなさそうです。ネットワークボリュームが容量ぶん課金され続けるのとは対照的です。

数字は構成と時期で変わるので、自分の課金レコードで確かめてから設計判断に使ってください。

FIXIT の運用 — 失敗の理由を先に分類する

4 回の失敗はすべて別の原因でした。ビルドの時間切れ、実行時の非互換、プラットフォームの一時障害、こちらの指定ミス。同じ「Build failed」の表示でも、対処はまったく違います。

そのため、失敗を見たらまず「ログに理由が書かれているか」で分けるようにしています。書かれていれば読んで直します。書かれていなければ、構成を疑う前に一度そのまま再投入します。今回はこの分類だけで、3 番目の罠に費やす時間がほとんどゼロで済みました。

インフラ側と推論側で担当を分けて調べる進め方は、Claude Code のセッション間メッセージングにまとめています。

まとめ — 16:9 は出せた。次は参照画像から離れる

自前ワーカーで、既成ワーカーが構造的に出せなかった 1360×768 を出せるようになりました。ワークフローをリクエストごとに渡す設計なので、出力サイズもステップ数も LoRA の有無も、再ビルドなしで変えられます。

一方で、画風とポーズはまだ自由になっていません。前回書いたとおり、それらを決めているのは参照画像であって、プロンプトではないからです。ワークフローを自由に変えられるようになった今、cfg やステップ数を動かして、どこまで参照の支配から逃れられるのかを次回試します。

生成 AI の基盤を自前で持つかどうかは、モデルの性能ではなく運用の形で決まります。同じ判断で迷っている場合は、AI 駆動開発やお問い合わせからご相談ください。

本記事の数値はすべて 2026 年 8 月 17 日の実測です。ワーカーのソースは y0n0zawa/runpod-qwen-image-edit (AGPL-3.0) で公開しています。参照した一次情報は RunPod Serverless の料金ドキュメント、RunPod Hub の概要、worker-comfyui、Qwen-Image-Edit-2511 のモデルページです。

よくある質問

Q. RunPod Hub のビルドに時間制限はありますか？: あります。実測では 1800 秒 (30 分) を超えた時点で強制終了され、ログに `Build exceeded maximum time limit of 1800 seconds (30.0 minutes). Build terminated.` と記録されました。手元の構成ではモデル 28.9GB の逐次ダウンロードに 22 分、イメージの書き出しと転送に 8 分かかり、ちょうど上限で打ち切られています。モデルを焼き込む設計では、この 30 分が最初の壁になります。書き出しと転送に 8 分かかるため、ダウンロードに使えるのは 20 分程度が上限です。並列化がその対処の 1 つになります。
Q. Docker のマルチステージビルドで何が速くなりますか？: 依存関係のないステージを BuildKit が並列に実行するため、逐次では合計時間だったダウンロードが、最も大きいファイル 1 本ぶんの時間に近づきます。手元では 4 つのモデル (19.12GB / 8.74GB / 0.79GB / 0.24GB) をステージごとに分けました。あわせて最終ステージの COPY もモデルごとに分け、レイヤーを 4 つに保っています。1 つにまとめると 29GB 弱の単一レイヤーになり、書き出しと転送がさらに遅くなるためです。結果として転送方式が変わり、96 秒かかっていた tarball 送信が 33 レイヤーの並列アップロード 34 秒 (1045.9 MB/s) になりました。
Q. worker-comfyui の base イメージはどれを選ぶべきですか？: 宣言する CUDA バージョンに合わせてください。素の `5.8.6-base` は comfy-cli が既定で入れる PyTorch を含み、これは CUDA 12.8 より新しい版を対象にしています。`hub.json` で `allowedCudaVersions: ["12.8"]` を指定すると、ワーカーが起動時に `The NVIDIA driver on your system is too old (found version 12080)` と `no kernel image is available` で落ちます。CUDA 12.8 を使うなら `5.8.6-base-cuda12.8.1` を指定してください。厄介なのは、イメージのビルドとレジストリへの push は正常に完了する点です。失敗は実行時にしか現れず、Hub の画面上ではテストのタイムアウトとして表示されます。
Q. RunPod Serverless のコールドスタートはどれくらいかかりますか？: イメージがそのマシンにキャッシュされているかで桁が変わります。34.74GB のイメージを新しいワーカーへ配る場合、実測で delayTime が 724,833 ミリ秒 (12.1 分) でした。ログを追うと大半はレイヤーの pull と展開に費やされています。一方、同じエンドポイントで直後にリクエストを送ると delayTime は 792 ミリ秒でした。つまり初回だけが極端に重く、暖まっていれば一瞬です。既成ワーカーで測った 22.6 秒という値も、他の利用者によってイメージが行き渡ったマシンに当たった結果だと考えられます。
Q. イメージのダウンロード時間は課金されますか？: 実測では現れませんでした。12.1 分のコールドスタートを含む時間帯について、Serverless の課金レコードに新しい記録がなく、30 分後に再取得しても合計額が変わりません。公式ドキュメントは課金対象として「初期化・処理・アイドル待機」を挙げ、`You're billed from when a worker starts until it fully stops` と記載していますが、その手前のイメージ取得については触れていません。ただし断定は避けるべきです。生成そのもの (1 秒) の課金も現れておらず、金額が小さすぎて丸められている可能性が残るためです。一方で 12 分ぶんは RTX 4090 の $1.10/h で計算しても $0.22 になり、丸めで消える額ではありません。少なくとも取得時間がそのまま秒課金されてはいない、とは言えます。自分の構成で課金レコードを確認してから判断してください。
Q. GitHub のリリースを作れば Hub は自動でビルドしますか？: 検知は 30 分間隔です。Hub のリリース一覧に `Releases are automatically checked every 30 minutes` と表示され、同じ画面の「Check for new release」を押すと即座に取り込まれます。注意点として、`gh release create --target` にコミット SHA を渡してはいけません。RunPod はこの値をブランチ名として `git clone` に渡すため、`Remote branch <sha> not found in upstream origin` で失敗します。再ビルドを促したい場合は、SHA ではなくブランチ (main) を対象にタグを打ち直してください。