前のジョブで決めたバージョン番号や、変更があったかどうかの判定を、後のジョブへ渡す。GitHub Actionsでは、ジョブの outputs と needs コンテキストを使います。ところが、値が空のときの扱いと、再実行したときの扱いを知らないと、「デプロイしないはずのジョブが動いた」「再実行したのに古いバージョン番号でタグを打った」といった取り違えが起きえます。
GitHubのドキュメントのリポジトリ（github/docs）に、2026年11月6日、この2点を明記する記述が加わりました。本記事では、追加された原文と、Actionsのランナー（actions/runner）のソースコードから挙動を確かめ、ワークフローの書き方を整理します。
空の値の出力は「設定されない」
ジョブの出力を定義する節に、次の一文が加わりました。
出力の値が空文字列に評価された場合、その出力は設定されない。ステップのデバッグログが有効なら、ジョブのログに
Skip output 'OUTPUT-NAME' since it's emptyというデバッグのメッセージが出る。
ランナーのソースコード（src/Runner.Worker/JobExtension.cs）でも、ジョブの出力を評価したあと、値が空なら Skip output '…' since it's empty をデバッグとして記録し、その出力を飛ばす処理になっています。その次に、シークレットを含むおそれのある値を Skip output '…' since it may contain secret. という警告とともに飛ばす処理が続きます。
ポイントは、空のときのメッセージがデバッグだという点です。ステップのデバッグログが出るのは、ワークフローのあるリポジトリのシークレットか変数で ACTIONS_STEP_DEBUG を true にしたときか、再実行のときに「Enable debug logging」を選んだとき（GitHub CLIでは gh run rerun に --debug を付けたとき）です。通常の実行ログには何も出ないため、出力が空で飛ばされたことに気づきにくくなっています。
後のジョブからは、空で設定されなかった出力と、そもそも値が取れなかった出力を区別できません。コンテキストの説明のページには、存在しないプロパティを参照すると空文字列に評価される、とあります。needs.build.outputs.version は、空で設定されなかった場合も、ステップの id の書き間違いで値が取れなかった場合も、空文字列です。id を書き間違えた場合は、ジョブの出力の式そのものが空文字列に評価されるので、ランナーの処理では「空なので飛ばした」と同じ扱いになるはずです（ソースからの推論で、試してはいません）。
行列のジョブでは、空の値が上書きしない
行列（matrix）で同じジョブを複数動かす場合の警告も更新されました。
Actionsは行列のジョブの実行順を保証しない。出力の名前は一意にすること。そうしないと、最後に実行されて出力を設定したジョブの値で上書きされる。空の値の出力は設定されないので、ほかの行列のジョブが設定した値を上書きしない。
たとえば、3つのジョブのうち1つだけが changed=true を出し、ほかの2つが空を出す作りなら、空の2つは上書きしないので true が残ります。しかし、ほかのジョブが changed=false を出す作りに変えると、実行順によって true と false のどちらが残るかが変わります。行列から1つの判定を受け取るときは、「設定するのは条件に当てはまったときだけ」にするか、出力の名前を行列の値ごとに分けて、後のジョブで toJSON(needs.<job>.outputs) などを使ってまとめて見るのが確実です。後者は公式ドキュメントの例と同じ形で、output_1〜output_3 の3つの出力を定義し、行列の各ジョブは自分の番号の出力だけを書き出します。ほかの2つは空なので設定されず、上書きも起きません。
再実行では、対象外のジョブの出力が使い回される
再実行のページには、次の記述が加わりました。
失敗したジョブや特定のジョブを再実行すると、それに依存するジョブも再実行される。再実行の対象に含まれないジョブは、前回の試行での出力をそのまま持ち、新しく実行されるジョブはその出力を使える。
同じページには、再実行は最初に実行した人の権限で動くこと、最初のイベントと同じ GITHUB_SHA（コミット）と GITHUB_REF を使うこと、1つの実行は最大50回まで再実行できること、最初の実行から30日以内に限られることも書かれています。
使い回しが問題になるのは、出力が「その時点の外の状態」から作られている場合です。たとえば、ビルドのジョブがその日の日付や、外部のレジストリに問い合わせた最新の番号から出力を作り、デプロイのジョブが失敗したとします。デプロイのジョブだけを再実行すると、ビルドのジョブは再実行されないので、出力は前回の値のままです。出力がコミットの内容だけから決まるなら、コミットは同じなので問題ありません。しかし外の状態が変わっていれば、前回の値で処理が進みます。
取り違えを防ぐ書き方
ここからは、上の原文をもとにした編集部の提案です。実際のリポジトリで再実行を試した結果ではありません。
空かどうかで分岐しない。 「出力が空ならデプロイしない」という判定は、ステップの id の書き間違いや、値を作るコマンドの失敗でも同じ結果になります。判定に使う値は true / false のように必ず何かを書き出し、後のジョブでは needs.build.outputs.deploy == 'true' のように、期待する値と一致したときだけ進む書き方にします。
値を作るステップで、空なら失敗させる。 バージョン番号のように必ず値があるはずの出力は、$GITHUB_OUTPUT に書き出す前に空でないかを確かめ、空なら終了コード1で止めます。後のジョブに空が渡ってから気づくより、原因に近い場所で止まります。
- id: version
run: |
v="$(node -p "require('./package.json').version || ''")"
if [ -z "$v" ]; then echo "version is empty" >&2; exit 1; fi
echo "value=$v" >> "$GITHUB_OUTPUT"ジョブの側では、outputs に version: ${{ steps.version.outputs.value }} のように書いて受け渡します。|| '' を付けているのは、package.json に version がないと node -p が文字列の undefined を出力し、空のチェックをすり抜けるためです。手元のmacOS（bash 3.2.57、Node.js 22.23.4）でこの run の中身だけを bash -e で動かし、version がないとき・空のとき・package.json がないときは終了コード1で止まり、version が 1.2.3 のときは value=1.2.3 が書き出されることを確かめました。|| '' を付けない形では、version がないときに value=undefined が書き出されて通りました。Actionsの上では動かしていません。
外の状態に依存する出力は、使うジョブの中で作り直す。 日付や外部の最新番号に依存する値を再実行のあとも正しく使いたい場合は、その値を使うジョブの中で取得するか、「すべてのジョブを再実行」を選ぶ運用にします。
調べるときはデバッグログを有効にして再実行する。 再実行の画面では、デバッグログを有効にするかを選べます。Skip output のメッセージを確かめれば、空だったのか、シークレットとして伏せられたのかを区別できます。ただし、上で書いたとおり id の書き間違いも空として記録されるはずなので、空になった原因まではこのメッセージだけでは分かりません。出力の大きさの上限（1ジョブ1MB、1つの実行の合計50MB）にも注意します。
ワークフローの依存の固定はactions.lockでタグ参照を固定する記事、ログに鍵が出た場合の検出はActionsのログのシークレットスキャンの記事で扱いました。
確認した範囲
2026年11月9日に、github/docsのコミット 6abed3d（2026年11月6日、「Document that empty job outputs aren’t set and that jobs not re-run keep their outputs」）の差分と、確認時点（8cd1075）のジョブの出力・再実行・デバッグログ・コンテキストの原稿、actions/runnerのmainブランチ（77e8fff、2026年11月9日）の
JobExtension.csを確認しました（資料調査）。2026年11月11日に、docs.github.comの公開ページと最新の原稿（7c3387d）で同じ記述を確かめ、actions/runnerのmain（5f626f1）と最新のリリース v2.338.2（2026年10月26日）のJobExtension.csに同じ処理があることも確かめました。GitHubがホストするランナーで今どの版が動いているかは確かめていません。同じ日に GitHub Changelog（10月28日〜11月11日）も見ましたが、ジョブの出力や再実行に関する告知はありませんでした。GitHub上でのワークフローの実行と再実行は試していません。本文のYAMLは、runの中身だけを手元で動かしました。
CI/CDの見直しや、デプロイの判定の作り方は、グリームハブの開発・AI・自動化のご相談で承っています。リポジトリの構成や運用の体制によって進め方が変わるため、お問い合わせからご相談ください。
