GitHub Actions lockfileプレビュー：固定したコミットもレビューする
レビュー済みのworkflowが後日別のコードを実行したら、何を承認したのでしょうか。GitHubは10月14日、workflow lockfileの公開プレビューを発表しました。重要なのは固定するコミットと次の更新を誰が確認するかです。
先に提供範囲を確認
修正済み発表はGitHub Enterprise Cloud、データレジデンシー対応Enterprise Cloud、Team、Freeを対象にしています。公開プレビューで、公式リポジトリはGHES非対応と1.0以前の変更可能性を明記しています。確認日と拡張機能の版を記録します。
タグと承認済みコミットを分ける
拡張機能は.github/workflows/actions.lockを生成し、導入したworkflowのaction、推移的依存関係、再利用workflowのコミットを記録します。参照の移動による実行コードの静かな変更を防ぐ助けになりますが、固定コードの安全性を保証するものではありません。
小さくレビューできる導入から
ここからは運用提案です。本番シークレットやデプロイ権限のないテストworkflowを選び、uses参照、所有者、目的を整理します。workflowとlockfileの差分を同じPRで読み、実際の実行記録につなげてから適用範囲を広げます。
更新担当者を決める
公式READMEのgh actions-lock --verifyはファイルを書き換えない検査です。--verify-localはオフラインの構造確認で、信頼性検証の代わりにはなりません。CI結果とコードレビューを分け、担当者、停止条件、復旧手順を決めます。本記事では拡張機能をインストールしていません。
発表によると、Dependabotは導入済みworkflowのaction更新時に対応するlockfile項目も同じPRで再生成します。自動差分も承認対象です。参照とコミットを同時に読み、権限や外部通信の変更を確認するのが本記事の提案です。
再現性を安全性の判定と読み違えないでください。公式に記載されたコミュニティの協力から事故削減率や全環境の互換性を推定していません。導入直前にREADMEを確認し、レビュー・固定・更新の三つに担当者を置きます。
公式資料
2026年10月15日確認。製品の機能と運用提案を区別しています。