ワークフローの定義（CI設定のファイル）を直すPRをmainにマージしても、ほかのPRのワークフローを再実行（re-run）するだけでは、修正後の定義で動かないことがあります。再実行は、最初の実行と同じコミットをそのまま使うためです。
この記事でわかること
- 分かれ目は、修正がmainに入ったのか、そのPR自身のブランチに入ったのかです
- mainに入った修正を効かせるには、再実行ではなく、PRのブランチを更新します
- 赤いままなら、修正を疑う前に、実行ログに出るベース側のコミットSHAを見ます
再実行は元のイベントのコミットを使う
再実行では、元のイベントと同じGITHUB_SHA（コミットSHA）とGITHUB_REF（ref。Gitでブランチなどを指す名前）が使われます。1
pull_requestイベントのマージブランチ
pull_requestイベントでは、GITHUB_REFはマージブランチ（refs/pull/PULL_REQUEST_NUMBER/merge）になります。GITHUB_SHAは、そのブランチ上の最後のマージコミットです。2
マージコミットは、PRのブランチとベースブランチ（多くはmain）を仮にマージしてできるコミットです。あとから定義の修正をmainにマージしても、ほかのPRの実行が使っていたマージコミットは変わりません。そのため再実行では、最初の実行時のコミットと、そこにある修正前の定義が使われます。
図の上の段は、再実行で使われる当時のマージコミットを示しています。ブランチを更新すると、下の段のように、修正後のmainを含む新しいマージコミットが作られ、ワークフローが新たに実行されます。そこで修正後の定義が読まれます。
確かめた時点の状態があとで変わる問題は、並行して動くAIエージェントとTOCTOUで扱っています。
「直したのに赤いまま」の原因を取り違えかけた
再実行しても赤いままというだけでは、修正が効いていない証拠になりません。 このサイトを運営するシステムで、定義の不具合を直すPRをmainにマージしました。そのあと、ほかのPRのワークフローを再実行しても赤いままでした。一度は「修正が効いていない」と取り違えかけました。
実行ログに出ているベース側のコミットSHAを見ると、修正前のコミットのままでした。そのPRのブランチを更新する（mainの変更を取り込む）とワークフローが新たに実行され、新しいベース側のコミットSHAで、直した検査が通りました。
例えば、定義の誤りで、開いているPRのワークフローがすべて失敗したとします。修正をmainにマージしてから各PRで再実行しても、失敗のままのことがあります。ブランチを更新すれば、修正後の定義で動かせます。
| 操作 | 使うコミット | 読まれる定義 |
|---|---|---|
| 再実行 | 元のイベントと同じコミット（変わらない） | 最初の実行時の定義 |
| ブランチの更新・新しいpush | 新しく作られるマージコミット | いまのベースブランチとPRのブランチを合わせた定義 |
画面ではどちらも実行をやり直す操作に見えますが、修正後の定義が読まれるのは下の行だけです。
手順は2つ
- 定義を直すPRをmainにマージしたら、修正を効かせたいほかのPRは、ブランチを更新します。再実行では足りません
- 再実行しても赤いままなら、実行ログのチェックアウトの手順に出るマージコミット（「Merge 〜 into 〜」）の、ベース側のSHAを確かめます。修正前のSHAなら、修正が効いていないのではなく、修正前の定義で動いただけです
修正をそのPR自身のブランチにpushしたのであれば、ワークフローが新たに実行されるので、この問題は起きません。問題が起きるのは、修正がmainに入り、ほかのPRのワークフローを内容を変えずにやり直す再実行のときです。 定義の修正に限らず、コードの修正でも同じです。
検査対象をわざと壊して、検査が本当に効くかを確かめる手順は、故障注入を完了条件にするで扱っています。
よくある質問
Q. なぜ再実行は修正前の定義のまま動くのですか。
再実行の目的は、同じ入力でもう一度動かし、結果が再現するか、一時的な失敗だったかを確かめることです。実行のたびに定義が変わると、この確認が成り立ちません。
Q. すべてのイベントで同じ動きになりますか。
この記事で確かめたのは、pull_requestイベントの動きです。GITHUB_REFの設定はイベントの種類で違うので、ほかのイベントはそれぞれの仕様を確かめてください。
Q. mainへのpushで動くワークフローでも、同じ問題は起きますか。pushイベントは、pushされたブランチのrefを直接使います。修正を含むコミットをそのブランチにpushすれば、以降の実行は修正後の定義で動きます。今回の問題は、修正がmainに入り、PRのブランチは変わっていないpull_requestイベントに特有です。
出典
- Re-run workflows and jobs — GitHub Docs（参照 2026-08-14）
- Events that trigger workflows — GitHub Docs（参照 2026-08-14）
