GitHub Actionsに、ワークフローで使うアクションを「決まったコミット」に固定できるロックファイル（actions.lock）の機能が登場しました。GitHub公式が2026年10月14日にパブリックプレビューとして発表したものです。
この記事では、この新機能だけにしぼって、何を防げるのか・どう始めるのかをやさしく解説します。GitHub Actionsそのものの基本は、GitHub Actionsの基礎から始めるCI/CD入門をご覧ください。
ロックファイルで何が変わる？
ワークフローでは uses: actions/checkout@v4 のように、タグやブランチでアクションを指定するのが一般的です。ところが、タグやブランチは後から別のコミットに動かすことができます。そのため、レビューしたときとは違うコードが、あとの実行で動いてしまう可能性があります。
公式は、アクションが乗っ取られた場合、タグやブランチを動かされるだけで、自分のリポジトリを何も変えていないのに悪意のあるコードがワークフローに入りこむおそれがあると説明しています。
ロックファイルを使うと、ワークフローの書き方（タグやブランチの指定）はそのままに、ロックしたときのコミットそのものが実行されるようになります。
注意：ロックしても「安全なアクション」になるわけではない
公式は「ロックは、依存そのものが安全かどうかを決めるものではない」と明記しています。ロックする前に依存（アクション）の中身を確認することが大切です。
主な特徴
- 対象プラン：GitHub Enterprise Cloud（データレジデンシー版を含む）、Team、Free（パブリックプレビュー）
- ファイル：
.github/workflows/actions.lockに、アクションとその推移的な依存（アクションがさらに使っているアクション）、再利用ワークフローの依存を、確認できるコミットとして記録 - 少しずつ導入できる：ワークフローごとに導入（オンボード）できる。導入したワークフローは、依存がロックファイルに載っている必要があり、記録されたコミットが実行される
- 古いロックファイルのチェック：ファイルを書きかえずに、ロックファイルが最新か確かめられる（CIのチェックにも使える）
- 「Require lockfile」ポリシー（パブリックプレビュー）：エンタープライズ・組織・リポジトリの管理者が、ワークフローにロックファイルの使用を必須にできる
- Dependabot対応：導入済みのワークフローでDependabotがアクションの更新プルリクエストを作るとき、対応するロックファイルの記録も同じプルリクエストで作り直す
始め方
ロックファイルは、GitHub CLI（gh）の拡張機能「gh-actions-lock」で作ります。公式リポジトリのREADMEによると、流れは次のとおりです。
- GitHub CLI（
gh）をインストールする - 拡張機能を入れる：
gh extension install github/gh-actions-lock - リポジトリで
gh actions-lockを実行する（.github/workflows/内のワークフローを調べ、アクションをコミットに固定してロックファイルを更新） - 生成されたロックファイルとワークフローの変更を確認して、コミットする
CIなどで「書きかえずに確認だけ」したいときは gh actions-lock --verify を使います。新しいワークフローを作ったときや、uses の依存を追加・削除したときは、もう一度 gh actions-lock を実行します。
なお、READMEには「公開プレビュー中で1.0未満のため、ロックファイルの形式やオプション、動作は予告なく変わることがある」と書かれています。また、GitHub Enterprise Server（GHES）には対応していません。
まとめ
- actions.lockは、ワークフローの依存をコミット単位で固定し、タグやブランチが動いても同じコードを実行させる仕組み
- 2026年10月14日からパブリックプレビュー（Enterprise Cloud・Team・Free）
gh actions-lock拡張で作成。Require lockfileポリシーやDependabotにも対応- ロックは依存の安全性を保証しないので、ロック前の確認が必要
関連記事：GitHubのAI Scan for pull requestsとは？
コメント