GitHub Actions: ワークフローの依存を lockfile（actions.lock）で固定する

何がうれしいか

タグやブランチは後から付け替えられるので、レビューしたときと別のコードが CI で動くことがある（tj-actions の乗っ取りなど）。これまでは GitHub Actions: pinact で uses: をコミット SHA に固定する してワークフロー本体を @<sha> # v6 の形に書き換えるのが定番だった。lockfile 方式では SHA を別ファイルに持つので、ワークフローは読みやすいまま。さらに、

• action の中で使われている 推移的な依存（composite action が呼ぶ action）と、reusable workflow もまとめて固定する
• ロックしたコミットが、記録したリポジトリの、実在するブランチ上にあるかを検証する（なりすましコミット対策）
• リポジトリの名前変更・差し替えも実行時に検出してブロックする

手順

gh extension install github/gh-actions-lock
cd your-repo
gh actions-lock            # .github/workflows/ を走査し actions.lock を生成
git diff                   # ← lockfile 以外も変わるので全体をレビュー

• 生成時に uses: の参照がより具体的なバージョンに書き換わることがある（例: @v3 → @v3.1.0。指すコミットは同じ）。
• ワークフローは 1本ずつ onboard できる。onboard 済みのワークフローは、依存がすべて lockfile に載っていないと実行されない。
• CI では lockfile が最新かを検証だけする（ファイルは書き換えない）モードを使う（フラグ名は gh actions-lock --help で確認）。
• 依存を変えたら gh actions-lock を再実行。Dependabot は onboard 済みワークフローの action を上げるとき、lockfile も同じ PR で更新してくれる。
• @v3 や @main のような動く参照は、通常は lockfile の値が信頼され再解決されない。上流でタグが動いたと報告されたら、まず上流の履歴を確認し、正当なら gh actions-lock --relock。元のコミットが消えている（force-push など）なら --relock --accept-moved。

組織で強制する

Enterprise / Organization / Repository の管理者は Require lockfile ポリシーで lockfile を必須にできる（これもプレビュー）。先に各リポジトリで lockfile を作ってから有効にしないと、準備できていないワークフローが止まる。「フル SHA 固定を必須にする」ポリシーと併用でき、lockfile 対象の依存はロックした SHA で判定される。

注意点

• 2026-10-14 時点の公式発表では対象は GitHub Enterprise Cloud（データ所在地版を含む）。個人・Free / Team プランでの扱いは公式ドキュメントで確認すること。
• 拡張はまだ 1.0 前で、lockfile の形式やフラグが変わる可能性がある。
• 実際に入れてみた @songmu さんによると、Dependabot の自動更新にも対応済み。

参考

• GitHub Changelog: github.blog
• Docs: docs.github.com

出典

• @azukiazusa9 · 2026-10-15
• @songmu 2026-10-15（導入してみた）: @songmu · 2026-10-15