GitHub Actionsのワークフローには、uses: actions/checkout@v4 のように、タグやブランチで外部のアクションを指定する書き方が並びます。タグは後から別のコミットへ付け替えられるため、レビューしたときのコードと、今日のジョブで動くコードが同じとは限りません。アクションの作者のアカウントが乗っ取られ、タグが付け替えられると、そのタグを参照しているリポジトリで不正なコードが動くおそれがあります。
これまでの対策は、ワークフローの uses: を40桁のコミットSHAに書き換えることでした。GitHubは2026年10月28日に、別の方法として「ワークフローの依存関係のロックファイル」を一般提供にしました（10月14日にパブリックプレビュー）。変更履歴が挙げる対象は、GitHub Enterprise Cloud（データの保存場所を選べるものを含む）、Team、Freeのプランです。この記事では、ロックファイルで固定されるもの・されないもの、作り方、組織で強制する前に確かめることを整理します。
ロックファイルが固定するもの
ロックファイルは、リポジトリの .github/workflows/actions.lock に置くファイルです。GitHub CLIの拡張機能 gh actions-lock が生成し、手で編集しないものとされています。ワークフローを「オンボード」（ロックファイルの管理下に入れること）すると、次のように動きます。
- ワークフローが使うアクションは、すべてロックファイルに載っていなければならない
- 実行されるのは、ロックファイルに記録されたコミット
- そのコミットは、アクションのリポジトリで、記録されたタグやブランチからたどれる必要がある。フォークにしかないコミットや、たどれなくなったコミットは実行時に拒否される
記録される項目は、タグやブランチの名前（ref）、解決したコミット（commit）、アクションのリポジトリの数値ID（owner_id・repo_id）です。数値IDは、同じ名前のリポジトリが別物にすり替わっていないかを実行時に確かめるために使われます。
ワークフローのファイルにSHAを書く方法との違いは、ドキュメントが3点挙げています。アクションが内部で使う別のアクション（推移的な依存）まで固定できること、ワークフローのファイルが読みやすいままになること、元のリポジトリの身元を記録することです。ロックファイルを導入したリポジトリでは、ワークフロー内でのSHAの固定は「もう必要ない」と書かれています。
固定されないもの
導入前に把握しておきたいのは、ロックファイルの対象外です。
| 対象外のもの | ドキュメント・READMEの記載 |
|---|---|
ジョブの uses: で呼ぶ再利用可能なワークフロー | 呼び出し側のロックファイルでは固定されない。固定するには完全なコミットSHAで参照する。呼ばれる側の依存は、そのリポジトリのロックファイルが受け持つ |
./ で始まるローカルのアクション | 拡張機能は追跡も固定もしない。中で外部のアクションを使っていると、エラーで書き込みを止める |
| コンテナのイメージ | 固定されない。@sha256: のダイジェストがないイメージは警告になる |
| 入力の値、シークレット、ランナーのイメージ | ロックファイルが制御するのは、ランナーで動くアクションのコードだけ |
ローカルのアクションは、--migrate-local-actions を付けると uses: ./… を uses: $/… に書き換えます。$/ はワークフロー自身のコミットのアクションを指す書き方で、そのコミットに固定され、中で使うアクションもロックできます。もう1つ、v4 や main のような動く参照が、履歴の中の古いコミットへ戻された変更は検知されない、とREADMEは制限に挙げています。ロックファイルの差分を読むか、完全なバージョンのタグを指定することを勧めています。
また、ロックファイルが防ぐのは意図しない依存の変更で、依存そのものが安全かどうかは判定しません。GitHubの変更履歴は、ロックする前に依存を確かめるよう書いています。
作り方と、日々の更新
ドキュメントの手順は、GitHub CLIに拡張機能を入れ、リポジトリのルートで実行するだけです。
gh extension install github/gh-actions-lock
gh actions-lock # .github/workflows/ のすべてを対象にする
gh actions-lock .github/workflows/ci.yml # 1本だけオンボードする拡張機能はロックファイル以外も書き換えます。uses: octo-org/deploy-action@v3 は、解決した版に合わせて @v3.1.0 のように具体的な表記になります（指すコミットは変わりません）。コミットの前に差分全体を確かめます。
更新の扱いは次のとおりです。
uses:を足す・消すたびにgh actions-lockを実行し直す- Dependabotがアクションの版を上げるPRを出すと、オンボード済みのワークフローなら、対応するロックファイルの記録も同じPRで作り直す。オンボードされていないワークフローは、Dependabotが新しくオンボードすることはない
mainやv3のような参照が動いた場合は、記録したコミットのままref-movedの警告が出る。上流の履歴を確かめてから--relockで進める。v3.1.0のような完全なタグが動いた場合は、--relockを実行するかuses:の行を変えるまでエラーになる- 履歴が書き換えられ、記録したコミットが参照の履歴から消えた場合は、
--relockでは直らない。上流の履歴を確かめてから--accept-movedで受け入れる。ドキュメントは、これを自動化の中で使わないよう書いている
レビューでは、commit の変更は動くコードが変わったことを意味します。owner_id や repo_id の変更はまれで、名前の裏のリポジトリが別物になったことを示すため、マージの前に調べるよう書かれています。
組織で強制する前の確認
Enterprise・組織・リポジトリの管理者は、Require lockfile のポリシーで、オンボードされていないワークフローの実行を止められます。対象のワークフローに uses: が1つもなくても止まる点に注意が要ります。呼び出す再利用可能なワークフローが、それ自身のリポジトリでオンボードされていない場合も、呼び出し側の実行が止まります。ドキュメントが勧める順番は次のとおりです。
- ロックファイルを作ったリポジトリとワークフローだけを対象にして、Evaluate モードで試す。Evaluate モードはGitHub Enterprise Cloudでのみ使える
- Policy insights で、止められたはずの実行を確かめる
- ワークフローの変更時に
gh actions-lock --verifyを実行するジョブを、必須のチェックにする。自動でロックファイルを作り直すジョブにはcontents: writeの権限と、workflowのOAuthスコープが要る .github/workflows/actions.lockをCODEOWNERSに入れ、ビルドの安全を担当するチームのレビューを必須にする- 対象の各リポジトリで
gh actions-lock --verifyを実行するか、Policy insights を見て、すべての対象が覆われたのを確かめてから Active に切り替える
許可するアクションを限定しているリポジトリや組織は、もう1つ確認が要ります。オンボード後は、許可リストがタグではなく固定したSHAと照合されるため、actions/checkout@v4 のようにタグで書いた許可の項目は一致しなくなります。ワイルドカードか完全なSHAに書き直します。既存の「完全なSHAへの固定を必須にする」ポリシーは併用でき、オンボード済みのワークフローはロックファイルでその要件も満たします。
当サイトのリポジトリで数えた参照
このサイトのリポジトリのワークフロー3本を数えると、uses: は9か所、使っているアクションは actions/checkout@v4、actions/setup-node@v4、stefanzweifel/git-auto-commit-action@v5 の3種類で、すべてメジャーバージョンのタグでした。3種類目は、取得したデータをコミットしてプッシュする第三者のアクションです。書き込みの権限で動くアクションほど、タグの付け替えの影響が大きくなるため、最初にオンボードする候補になります。
GitHubのサプライチェーン全体の点検の考え方はGitHub Actionsのサプライチェーン継続監査の記事、過去の事件と防御策は2026年のサプライチェーン攻撃まとめで扱っています。
確認した範囲
2026年11月6日に、GitHub Docsの該当ページ4本、拡張機能のリポジトリ（github/gh-actions-lock）のREADME、GitHubの変更履歴の2本を開き、原文と照合しました（資料調査）。対象のプランは変更履歴の記載です。ドキュメントのうち作り方と強制の手順のページは、「Who can use this feature?」の欄にGitHub Enterprise Cloudだけを挙げており、変更履歴と一致しません。個人のProのプランは、どちらにも挙がっていません。Require lockfile のポリシーは、ポリシーの設定のページに「すべての公開リポジトリと、GitHub TeamまたはGitHub Enterpriseのプライベートリポジトリ」と書かれていますが、FreeやTeamの環境で動かして確かめてはいません。拡張機能の実行もしていません。
CI/CDの見直しや、開発の流れの安全の設計は、開発・AI・自動化のご相談からお問い合わせください。
参考資料
- Workflow dependency lockfiles（GitHub Docs）
- Locking action dependencies in a repository’s workflows（GitHub Docs）
- Enforcing lockfiles for action dependencies（GitHub Docs）
- Controlling workflow execution（GitHub Docs）
- github/gh-actions-lock（README）
- GitHub Actions workflow lockfiles are generally available（GitHub Changelog）
- GitHub Actions workflow lockfiles in public preview（GitHub Changelog）
