GitHubは2026年10月14日、GitHub Actionsの依存関係を固定するロックファイルを試験公開しました。タグやブランチによる参照を残したまま、実際に実行するコードを固定できます。対象はGitHub Enterprise Cloudで、ワークフロー単位の段階導入に対応します。
レビュー時と実行時のコードのずれを防ぐ
GitHubによると、タグやブランチが指す先は移動するため、実行されるコードがレビュー時と変わる恐れがあります。今回のロックファイルは、実行するコミット、つまりコードの特定の変更時点を固定する仕組みです。
固定対象は、ワークフローで使うアクションだけではありません。アクションがさらに利用する依存先や、再利用可能なワークフローの依存関係も含みます。ワークフロー内のタグやブランチの参照を残しながら、固定したコミットを実行できるとしています。
ただし、固定することと、安全性を確認することは別です。GitHubは、ロックが依存先自体の安全性を保証するものではなく、固定前のレビューが必要だと説明しています。情シスと開発担当者が決めるべきなのは、固定するかどうかだけでなく、誰が依存先を確認して変更を承認するかです。
段階導入と必須化に対応、更新はDependabotと連携
作成・管理には、コマンドでGitHubを操作するGitHub CLIの「gh actions-lock」拡張を使います。公開されているgh-actions-lockリポジトリから拡張をインストールし、「.github/workflows/actions.lock」を生成します。生成したファイルとワークフローの変更をレビューし、コミットする手順が案内されています。
導入はワークフロー単位で進められます。ただし、導入済みのワークフローでは、全依存関係をロックファイルに登録する必要があります。ファイルを変更せずに、CIと呼ばれる自動検査の処理でロックファイルの鮮度を検査することもできます。
管理者向けには、ロックファイルを必須にする「Require lockfile」ポリシーも試験公開されました。企業・組織・リポジトリ単位で必須化できます。一部のワークフローで試す段階と、管理単位全体で必須にする段階を分けて検討するのがよいでしょう。
依存関係の更新を支援するDependabotが、導入済みワークフロー内のアクションのバージョン更新PRを作成すると、同じPRで対応するロックファイルのエントリーも再生成します。PRは変更をレビューするための提案です。この同期更新に追加設定は不要としていますが、固定前のレビューが不要になるわけではありません。
影響する会社・しない会社
- 影響する: GitHub Enterprise CloudでGitHub Actionsを利用する会社です。実行する依存先の固定と、その更新手順を検討する対象になります。
- 影響する: GitHub Enterprise Cloud with data residencyを利用する会社も提供対象です。導入後は、対象ワークフローの全依存関係を登録する運用が必要です。
- 影響しない: GitHub Actionsを利用していない会社では、今回の機能を導入するための作業はありません。GitHubを使っているという理由だけで対応対象にする必要はありません。
日本での提供は発表には書かれていません。また、上記以外のプラン・版への提供条件も、発表には書かれていません。契約名だけで判断せず、利用環境で試験導入できるかを確認してください。
情シスが今日やること
- 今日の確認対象を絞ります。GitHubの契約管理担当者に利用プランを確認し、開発責任者にはActionsを使うリポジトリとワークフローの一覧を依頼します。対象プラン以外も使っている場合は、提供条件を未確認として分けます。
- 開発担当者と試験用のワークフローを選びます。対象リポジトリの「.github/workflows」を確認し、アクションや再利用可能なワークフローの依存先を洗い出します。試験開始前に、固定する依存先のレビュー担当者を決めます。
- 試験導入時に、公開gh-actions-lockリポジトリから拡張を導入します。「.github/workflows/actions.lock」を生成し、ワークフローの変更と一緒にレビューします。全依存関係が登録されていることを確認してからコミットします。
- 必須化の判断前に、管理者と開発責任者で適用範囲を合意します。Require lockfileを企業・組織・リポジトリのどの単位で使うかを決め、ロックファイルの鮮度検査とDependabotの更新PRを誰が確認するかも記録します。
