先に要点
- GitHub Actions のワークフローのロックファイルが、2026年10月28日に一般提供になりました。ワークフローに
actions/checkout@v4のようなタグで書いたままでも、ロックしたコミットだけが実行されるようになる仕組みです。ファイルは.github/workflows/actions.lockで、GitHub CLI の拡張機能gh actions-lockが作ります。 - タグやブランチは、付け替えられます。アクションの作者のアカウントが乗っ取られてタグが悪意のあるコミットに向け直されると、自分のワークフローが、確かめていないコードを動かしてしまうのが問題でした（実際に2025年3月に起きています）。
- 従来の対策は、コミット SHA を直接書いて固定する方法でした。ロックファイルは、間接的に使われるアクションまで固定でき、参照先のリポジトリが同じものかも実行時に確かめます。GitHub のドキュメントは、導入したリポジトリでは SHA 固定は不要としています。
- ロックファイルは安全を保証するものではありません。固定する前にアクションの中身を確かめる必要があり、再利用ワークフローの呼び出しや、入力・シークレット・ランナーのイメージは対象外です。
GitHub Actions で CI/CD を動かしている方向けの記事です。「@v4 のようなタグ指定のままで大丈夫なのか」「SHA 固定は面倒で続かない」と感じていた方が、ロックファイルで何が変わるのか、どう導入するのかを判断できるようにまとめました。
この記事は、GitHub の Changelog（2026年10月28日）と GitHub Docs のロックファイルの解説・導入手順・必須化の手順、過去の事例の GitHub Advisory Database の記載（いずれも2026年10月30日に確認）をもとにしています。実際に拡張機能を動かした検証は、この記事では行っていません。コマンドや挙動は公式ドキュメントの記載で、拡張機能の版が上がると変わる可能性があります。
何が変わったのか：一般提供の内容
Changelog によると、ロックファイルはGitHub Enterprise Cloud、データ所在地指定の GitHub Enterprise Cloud、Team、Free のプランで一般提供になりました。GitHub Enterprise Server については、Changelog に記載がありません（使っている方は、自社の GitHub の案内を確かめてください）。
| できること | 内容 |
|---|---|
| ロックの作成 | GitHub CLI の拡張機能 gh actions-lock で、アクションとその間接的な依存を .github/workflows/actions.lock に記録する |
| 段階的な導入 | ワークフローを1つずつ対象にできる。対象にしたワークフローは、すべての依存がロックファイルに載っていないと動かない |
| Dependabot との連携 | 対象のワークフローでアクションの版を上げる PR を Dependabot が作るとき、同じ PR でロックファイルの該当の行も作り直す（追加の設定は不要） |
| 必須にする方針 | Enterprise・組織・リポジトリの管理者が「Require lockfile」の方針で導入を強制できる |
| 古さの検査 | ファイルを書き換えずに、ロックファイルが最新かを確かめられる。CI の検査にも使える |
なぜタグ指定は危ないのか：2025年3月の事例
ワークフローで uses: octo-org/deploy-action@v3 のようにタグやブランチを指定すると、GitHub Actions は実行の時点で、そのタグが指しているコミットを取ってきます。GitHub のドキュメントも、タグやブランチは付け替えられるため、「最初に確かめたコードが動く保証がない」と説明しています。
実際に起きた事例が、GitHub Advisory Database にあります（GHSA-mrrh-fwg8-r2c3、CVE-2025-30066）。人気のアクション tj-actions/changed-files が侵害され、過去のバージョンのタグが、悪意のあるコミットに付け替えられました。2025年3月14日から15日のあいだに、2万3千以上のリポジトリが影響を受け、ワークフローのログにシークレットが書き出されたと記載されています。
タグの付け替えで、確かめていないコードが動くまで
- 1アクションの作者のアカウントやリポジトリが侵害される
攻撃者が、アクションのリポジトリに書き込める状態になる。
- 2既存のタグが、悪意のあるコミットに向け直される
v1 や v35 のような既存のバージョンのタグが、攻撃者のコミットを指すように付け替えられる。名前は同じなので、利用者の側からは変わったように見えない。
- 3利用者のワークフローが、次の実行でそれを取ってくる
uses にタグを書いているワークフローは、実行のたびにタグの指す先を取る。悪意のあるコードが、利用者のランナーで動く。
- 4
ロックファイルは、この流れの3段目を止める仕組みです。タグが付け替えられても、ロックファイルに記録したコミットが実行されます。ただし、記録した時点でそのコミットが悪意のあるものだった場合は防げません（後述）。サプライチェーン攻撃全般の考え方は サプライチェーンとは で解説しています。
ロックファイルの仕組み
ロックファイルは、リポジトリの .github/workflows/actions.lock に置かれます。手で編集せず、必ず gh actions-lock で作ります。対象にしたワークフローは、次のように動きます。
依存はすべて載っている必要がある
対象のワークフローが使うアクションは、間接的に使われるもの（アクションが中で使うアクション）も含めて、すべてロックファイルに載っていなければなりません。載っていないと実行できません。
動くのは記録したコミット
実行されるのは、ロックファイルに記録されたコミットです。許可するアクションを制限する方針の確認も、このコミットに対して行われます。
コミットの出どころを確かめる
記録したコミットは、アクション自身のリポジトリで、記録したブランチかタグから到達できる必要があります。フォークにしか無いコミットや、到達できなくなったコミットは、実行時に拒否されます。
リポジトリの同一性も確かめる
リポジトリを数値の ID でも記録し、実行時に「名前の先にあるリポジトリが、ロックしたものと同じか」を確かめます。名前を乗っ取られても気づけます。
ファイルの中身は、ドキュメントによると、次のような形です（形式の版は変わる可能性があります）。
# gh actions-lock が生成するファイル。手で編集しない
version: "v0.0.3"
workflows:
".github/workflows/ci.yml":
- "octo-org/deploy-action@v3.1.0"
dependencies:
"octo-org/deploy-action@v3.1.0":
ref: "v3.1.0"
commit: "sha1-..."
owner_id: 44036562
repo_id: 197814629
workflows の節に、各ワークフローが使う依存が、dependencies の節に、それぞれの参照が解決されたコミットが記録されます。ref は解決元のタグやブランチ、commit は実行されるコミット、owner_id と repo_id は参照先リポジトリの数値の ID です。
SHA 固定との違い
GitHub は従来、サードパーティのアクションをフルレングスのコミット SHA で固定することを推奨してきました。ワークフローに uses: actions/checkout@（40桁のコミット SHA） と書く方法です。ロックファイルは、これを置き換えるものと位置づけられています。
| 観点 | コミット SHA 固定 | ロックファイル |
|---|---|---|
| ワークフローの読みやすさ | 40桁の文字列で、何の版か分かりにくい | タグの表記のまま読める |
| 間接的な依存 | 固定できない（アクションが中で使うものは対象外） | 間接的な依存も記録して固定する |
| 参照先の同一性 | 確かめない（フォークの SHA を書いてもそのまま動く） | リポジトリの ID を実行時に確かめる |
| 版を上げる作業 | SHA とコメントの版を手で直す（Dependabot が対応） | Dependabot が同じ PR でロックファイルも直す |
| 組織での強制 | SHA 固定を必須にする方針がある | 「Require lockfile」の方針がある |
GitHub のドキュメントは、ロックファイルを導入したリポジトリではワークフローの中の SHA 固定は不要とし、「利用できるなら最も強い保護」と書いています。また、ロックファイルを導入したワークフローは、別の方針である「コミット SHA での固定を必須にする」にも適合すると説明されています。ロックファイルを導入できないリポジトリでは、従来どおり SHA 固定が使えます。
導入の手順
導入は、リポジトリへの書き込み権限があれば、管理者でなくても行えます。
リポジトリへの導入の流れ（公式の導入手順より）
- 1アクションの参照を確かめる
ロックは、現時点のタグやブランチが指すコミットに固定する。uses の参照が、サポート中の最新の版を指しているかを先に確認する。Dependabot で GitHub Actions を管理しているなら、先に有効にしておく。
- 2拡張機能を入れる
GitHub CLI を入れ、gh extension install github/gh-actions-lock を実行する。更新は gh extension upgrade gh-actions-lock。
- 3ロックファイルを作る
リポジトリのルートで gh actions-lock を実行する。.github/workflows/ のすべてのワークフローを調べ、解決できるアクションをコミットに固定して、ファイルを書く。1つだけ対象にするなら、ワークフローのパスを渡す。
- 4差分を確認してコミットする
拡張機能はロックファイル以外も書き換える。差分全体を確認してからコミットする。
- 5以降は最新に保つ
ワークフローの依存を足したり変えたりしたら、gh actions-lock をもう一度実行する。
# 拡張機能を入れる
gh extension install github/gh-actions-lock
# すべてのワークフローを対象にして、ロックファイルを作る
gh actions-lock
# 1つのワークフローだけを対象にする
gh actions-lock .github/workflows/ci.yml
# ロックファイルが最新かを、ファイルを書き換えずに確かめる（CI の検査に使える）
gh actions-lock --verify
差分の確認では、次の2点が要注意です（公式の手順に書かれています）。
uses の参照が具体的な版に書き換わる
拡張機能は、ワークフローの uses を、解決した具体的な版に書き換えます。たとえば @v3 が @v3.1.0 になります。指すコミットは変わりません。
許可するアクションの一覧に注意
リポジトリ・組織・企業が「指定したアクションだけ許可」にしている場合、対象にしたワークフローでは、許可の確認が固定したコミット SHAに対して行われます。タグで書いた許可の項目は一致しなくなるので、ワイルドカードかフルの SHA に直します。
自分のリポジトリ内のアクション（uses: ./… のローカルパス）は、実行時の作業ディレクトリの中身をそのまま動かすため、拡張機能は固定も、その中身の調査もできません。ローカルのアクションが別のアクションを使っている場合、拡張機能はエラーを出して何も書きません。--migrate-local-actions を付けると同じリポジトリの参照に書き換えて固定でき、--ignore-local-actions を付けると警告にとどめます。後者は、依存がロックされていないと実行時に失敗することがあるので、公式の説明を確かめてから使ってください。
運用：最新に保ち、差分を読む
ロックファイルは、古くなったり、読まれなかったりすると意味がなくなります。公式のドキュメントが示している運用は、次のとおりです。
Dependabot に任せる
アクションの版の更新は Dependabot に任せます。対象のワークフローでは、同じ PR でロックファイルも作り直されます。ただし、まだロックファイルに載っていないワークフローは、Dependabot は新しく対象にしません（既存の対象を保つだけです）。
動いたタグへの対応
ブランチや v3 のような部分的な版は、ロックしたコミットのまま警告が出ます。進めるときは上流の履歴を確かめてから --relock を使います。履歴が書き換えられた場合は --accept-moved が必要ですが、自動化の中では使わないよう公式が注意しています。
差分は依存の更新として読む
コミットが変わった行は、実行されるコードが変わったという意味です。通常の依存の更新と同じように確かめます。owner_id や repo_id が変わるのは稀で、名前の先のリポジトリが別物になったことを意味するため、マージする前に調べます。
組織で必須にする：試行運用から始める
組織・企業の管理者は、「Require lockfile」の方針で導入を強制できます。ただし、公式の手順はいきなり有効にしないことを強く勧めています。この方針は、ロックファイルに載っていない対象のワークフローの実行を止めるためです（uses の依存が無いワークフローも含みます）。
Require lockfile の導入の流れ（公式の手順より）
- 1試行する
導入済みのリポジトリと、導入済みのワークフローだけを対象にして、まず評価モード（Evaluate）で動かす。結果は Policy insights で確かめる。評価モードは GitHub Enterprise Cloud だけで使える。
- 2最新に保つ仕組みを入れる
Dependabot と、gh actions-lock --verify を動かす検査のワークフローを入れて、開発者が更新を覚えていなくても古くならないようにする。
- 3差分の確認体制を作る
actions.lock を CODEOWNERS に入れて、ビルドのセキュリティを見るチームに自動で確認を依頼する。コードオーナーの承認をブランチ保護で必須にする。
- 4有効にする
ロックファイルが整い、最新に保たれると確信できてから、方針を有効（Active）にする。対象のすべてのワークフローが導入済みか、事前に確かめる。
呼び出す再利用ワークフローが別のリポジトリにある場合は、その元のリポジトリも導入済みにしておく必要があります。呼び出し側のロックファイルは、再利用ワークフローの依存をカバーしないためです。元のリポジトリが未導入だと、方針によって呼び出し側の実行が止まります。
ロックファイルでできないこと
Changelog にも、「ロックファイルは予期しない依存の変更から守るが、依存が安全かどうかは判断しない。ロックする前に依存を確かめる」と書かれています。ロックは、確かめたコミットを動かし続けるための仕組みです。最初に固定するコミットが悪意のあるものなら、そのまま固定されます。アクションの作者・更新の履歴・権限を確かめてから導入します。
| 対象外のもの | 理由・対処 |
|---|---|
再利用ワークフローの呼び出し（jobs.<job_id>.uses） |
ロックファイルは固定しない。フルのコミット SHA で参照して固定する |
| 入力パラメータ・シークレット・ランナーのイメージ | ロックファイルは、アクションのコードだけを制御する |
| 再利用ワークフローの中の依存 | 呼び出し側ではなく、定義されているリポジトリのロックファイルで扱う |
ローカルパスのアクション（./） |
実行時の作業ディレクトリの中身を動かすため、固定できない |
ほかのシークレットの扱いや権限の最小化は、別の対策です。CI/CD の基本は GitHub Actions 入門 も参考にしてください。
よくある質問
すでに SHA で固定しています。ロックファイルに移すべきですか？
GitHub は、ロックファイルが使えるなら、より強い保護と位置づけています。間接的な依存まで固定でき、リポジトリの同一性も確かめられます。ただし、移すには拡張機能の導入と、許可するアクションの一覧の見直しなどの作業が要ります。重要なリポジトリから、段階的に移すのが現実的です。
導入すると、毎回ロックファイルを手で直す必要がありますか？
Dependabot でアクションを管理していれば、版の更新はロックファイルも含めて自動で PR になります。手で実行するのは、ワークフローを新しく足す・依存を追加または削除するときです。
GitHub Enterprise Server でも使えますか？
2026年10月30日時点で、Changelog に Enterprise Server の記載はありません。使っている方は、自社が運用している版のドキュメントで確かめてください。
ロックファイルを手で編集してもよいですか？
いいえ。公式は手で編集しないよう明記しています。おかしくなったときは、ワークフローを直してから、ロックファイルを作り直します。
タグが付け替えられたら、ロックファイルで検知できますか？
完全なバージョンのタグ（v3.1.0 など）が、ロックしたコミットと別のコミットを指すようになった場合、拡張機能がエラーを出します。部分的な版やブランチは、ロックしたコミットのまま警告が出ます。いずれも、実行されるのはロックしたコミットです。
まとめ
- GitHub Actions のワークフローのロックファイル（
.github/workflows/actions.lock）が、2026年10月28日に一般提供になった。Enterprise Cloud・Team・Free のプラン - タグが付け替えられても、ロックしたコミットだけが実行される。2025年3月の tj-actions/changed-files の事例のように、タグの付け替えで確かめていないコードが動くことを防ぐ
- SHA 固定と比べて、間接的な依存を固定でき、リポジトリの同一性も確かめられ、ワークフローが読みやすい
- 導入は
gh actions-lock。差分でタグの書き換えと、許可するアクションの一覧への影響を確認する。Dependabot と--verifyで最新に保つ - 組織で必須にするなら、評価モードで試行してから有効にする。ロックは安全性を保証しないので、固定する前に依存を確かめる
公開リポジトリでフォークからの Pull Request に反応する pull_request_target も、2026年12月2日から既定でブロックされます。影響の確かめ方はpull_request_target が12月2日に既定ブロックで整理しています。
参考リンク
- GitHub Actions workflow lockfiles are generally available（GitHub Changelog、2026年10月28日）
- Workflow dependency lockfiles（GitHub Docs）
- Locking action dependencies in a repository workflows（GitHub Docs）
- Enforcing lockfiles for action dependencies（GitHub Docs）
- Secure use reference（GitHub Docs）
- tj-actions changed-files supply chain attack（GHSA-mrrh-fwg8-r2c3、CVE-2025-30066）
- github/gh-actions-lock（拡張機能のリポジトリ）