GitHub Actionsのワークフロー依存ロックファイルが一般提供、読みやすい参照のまま正確なコミットを実行

GitHubは2026年10月28日、GitHub Actionsのワークフロー依存関係ロックファイルを一般提供（GA）にしたと発表した。対象はGitHub Enterprise Cloud、データレジデンシー付きのGitHub Enterprise Cloud、そしてTeamとFreeのプランである。ロックファイルを使うと、ワークフローは読みやすいタグやブランチの参照を保ったまま、ロックした正確なコミットを実行する。参照があとで動いても同じである。変更履歴は、一般提供版に公開プレビューで導入された機能が入ると述べている。

解決しようとしているのは、可変の参照の問題だ。ワークフローがタグやブランチ上のアクションを使うと書いていれば、ジョブの開始時にその名前が指すコミットが実行される。名前が動けば、ジョブは気づかないうちに別のコードを実行する。ロックファイルは、その名前の裏にあるコミットを、アクション自体と推移的依存、つまりそのアクションが使うほかのアクションについて記録する。GitHub CLIのgh actions-lock拡張が.github/workflows/actions.lockを生成する。ワークフローには読みやすい参照が残り、実際に動くものはロックファイルが決める。

導入は段階的にできる。チームはワークフローを1つずつ有効にする。有効にしたワークフローでは、GitHub Actionsはすべての依存がロックファイルに載っていることを求め、記録されたコミットを実行する。そのため、すべてのワークフローを一度に対象にする必要はない。厳格な規則が必要なら、企業、組織、リポジトリの管理者が「ロックファイルを必須にする」ポリシーで導入を強制できる。方針に違反したワークフローがどうなるかは変更履歴に書かれていないので、管理者は広く適用する前に小さい範囲で試すべきだ。

ファイルを正確に保つ機能が2つある。Dependabotが有効化済みワークフローのアクションのバージョン更新を提案するとき、同じプルリクエストで対応するロックファイルの項目も再生成し、追加設定は要らない。別に作り直す手間が省ける。古くなったロックファイルの確認もできる。確認はファイルを変更せずに最新かどうかを検証するので、CIの検査として動かし、誰かがワークフローだけ変えてロックファイルを忘れたときにビルドを失敗させられる。

GitHubは限界をはっきり述べている。ロックファイルは予期しない依存関係の変化から守る助けになるが、依存が安全かどうかは判断しない。ロックした時点で悪意や脆弱性のあるコミットは、ロック後もそのままである。GitHubは、ロックする前に依存を確認するよう勧める。つまりロックファイルは、確認の時点をロック時とDependabot更新のたびに前倒しするもので、確認の代わりにはならない。変更履歴はセルフホストランナーやGitHub Enterprise Serverにも触れていないので、該当するチームはドキュメントを見る必要がある。

使い始めるには、gh-actions-lockリポジトリから拡張を入れ、ロックファイルを生成し、ロックファイルとワークフローの変更を確認してコミットする。GitHubは、ロックファイルのドキュメントと、フィードバック用のコミュニティ議論や課題追跡を案内している。

サードパーティのアクションに頼るチームにとっての実利は、パイプラインが実際に動かしたコードの確認できる記録と、ずれをプルリクエストで見えるようにできることだ。