GitHub Actionsにロックファイルが来るぞ

2026年夏頃から、GitHub Actionsの依存関係をコミットSHAでピン留めするための公式拡張機能「gh actions-lock」コマンドがTechnical Previewとして公開されているので紹介します。

本記事で紹介するのはTechnical Preview中の機能です。
2026年9月時点の動作を紹介しています。今後、正式リリースまでの間に破壊的変更が入る可能性があります。

3行まとめ

• GitHub Actionsの依存関係はコミットSHAでバージョンをピン留めした方がよい
• しかし従来サポートされていた方法は扱いづらかった
• 公式の「gh actions-lock」コマンドを利用すると楽

従来のGitHub Actionsバージョン管理

GitHub Actionsの依存関係はバージョン指定とコミットSHA指定の2種類があり、後者の方が推奨されています。

-      - uses: actions/checkout@v7
+      - uses: actions/checkout@3d3c42e5aac5ba805825da76410c181273ba90b1

バージョン指定の方法では、攻撃者にタグやブランチの参照が上書きされた場合に、悪意のあるコードが混入するリスクがありました。こうしたサプライチェーン攻撃対策のため、コミットSHAの指定が推奨されています。

一方で、コミットSHAによるピン留め方法にはいくつか問題がありました。

問題1: 依存先のActionの内部がコミットSHAでピン留めされているとは限らない

以下のような場合を考えます。あなたが管理しているリポジトリのworkflowは、ある3rd party actionに依存しています。その3rd party actionは、また別の3rd party actionに依存しています。（これを推移的依存といいます。）

自分で管理しているリポジトリ内についてはSHAでピン留めできているため、一見するとサプライチェーン攻撃のリスクを下げられているように見えます。

しかし、3rd party actionが更に別の3rd party actionに依存しており、かつそこがコミットSHAでピン留めされていない場合は、依然としてサプライチェーン攻撃のリスクがあります。

このようなケースは、人気の3rd party actionでも起こっています。
例えばgoogle-github-actions/run-gemini-cli (Star 2.1k)は依存先をSHAピン留めしていないため、google-github-actions/run-gemini-cliの利用者は暗黙的にサプライチェーン攻撃のリスクに晒されています。他にもSHAピン留めしていない人気3rd party actionは多数あります。

問題2: SHA指定ではDependabotアラートが効かない

ドキュメントによると、コミットSHA指定で参照されているAction依存関係については、Dependabot alertsの対象外とされています。

Dependabot alerts にはいくつかの制限があります。

• GitHub Actionsアラートは、SHA バージョン管理ではなく、セマンティック バージョン管理を使用するアクションに対してのみ生成されます。

問題3: コミットSHA指定はめんどう

バージョン指定の代わりにコミットSHAを調べて指定するのは、単純にめんどうです。

コミットSHA指定を行うための3rd party製ツールもありますが、管理しているすべてのリポジトリに導入するかと言われると、まだまだ心理的なハードルがあると感じます。

現状の仕組みは使い勝手が今ひとつです。筆者としては、SHAのピン留めがセキュリティ的に重要であるからこそ、初心者でももっと手軽に使える仕組みが必要だと考えていました。

公式拡張機能gh actions-lockの紹介

こうした状況は公式のGitHub CLIによって改善されそうです。

まず、2026年3月に公開されたGitHubのセキュリティロードマップにおいて、GitHub Actionsの依存関係管理の新しい方法が導入されることが発表されました。

次に、2026年4月に、GitHub CLIのissueにてgh actions pinサブコマンドのRFCがopenされ、設計についての議論が開始されました。

その後、2026年7月ごろからgithub/gh-actions-lockリポジトリにてこの機能のTechnical Previewが始まりました。

2026年9月時点ではまだ正式リリースされていません。組み込みのサブコマンドではなくGitHub CLIの拡張機能(extension)であるgh actions-lockコマンドとして配布されています。

また、ロックファイルの形式など、今後破壊的変更が入る可能性があります。

1. インストール

Technical Preview中のため、GitHub CLIの組み込みコマンドではなく、extensionとして提供されています。そのため、以下のコマンドでインストールします。

$ gh extension install github/gh-actions-lock

2. Actionsのバージョンをピン留めする

リポジトリ内のバージョン指定Actionを、コミットSHA指定に切り替えてみます。

コマンドは以下です。

$ gh actions-lock

コマンドを実行すると、actions.lockファイルが自動生成されます。

.github/workflows/actions.lock (自動生成)

# This file is machine-generated by `gh actions-lock`.
# Do not edit by hand; run `gh actions-lock` to update.
# Docs: https://gh.io/actions-lockfile
version: 'v0.0.2'
workflows:
    '.github/workflows/test.yml':
        - 'actions/checkout@v7.0.1'
dependencies:
    'actions/checkout@v7.0.1':
        ref: 'v7.0.1'
        commit: 'sha1-3d3c42e5aac5ba805825da76410c181273ba90b1'
        owner_id: 44036562
        repo_id: 197814629

このファイルはリポジトリ内のactionsの依存関係をすべて管理します。

併せて、リポジトリ内のworkflowファイルが以下のように書き換わります。

.github/workflows/test.yml

+# This workflow is managed by gh actions-lock.
+
 on:
   push:
 
     runs-on: ubuntu-slim
     steps:
       - name: Checkout
-        uses: actions/checkout@v7
+        uses: actions/checkout@v7.0.1
 
       - name: Echo
-        uses: ./.github/actions/echo
+        uses: $/.github/actions/echo

書き換わる点は3つです。

• 先頭に# This workflow is managed by gh actions-lock.コメントが追加される
• uses:で参照している3rd party actionがパッチバージョンまで含めてバージョン指定される
• Composite Actionは$/経由での参照に変更される

特定のworkflowファイルのみロックファイルを生成するには、gh actions-lock <path to file>を実行すればいいようです。

また、従来方式で問題だった「3rd party actionが更に依存する3rd party action(推移的依存)のバージョン指定」についても、この方式では解消されています。gh actions-lockは依存関係を再帰的に辿り、すべての3rd party actionのバージョンをコミットSHAでピン留めします。

3. コミットSHAでピン留めされているかを確認する

CIなどで3rd party actionのバージョンが固定されているか確認するためのコマンドも用意されています。

$ gh actions-lock --no-fix

試しにロックファイルを削除した状態で上記コマンドを実行してみると、以下のようにピン留めされていない依存関係が検出され、exit code 1で終了しました。

✗ 1 of 1 workflow failed verification

  ! Not pinned actions/checkout@v7
    used in workflow but not pinned in lockfile (actions/checkout@v7)
    see: how to fix this
    ↳ .github/workflows/test.yml
  Re-run without --no-fix to apply fixes.

CIのLint stepにこのチェックを含めておくと良さそうです。

周辺ツールの対応状況

さて、ロックファイルが生成されても、それが実際に利用されなければ意味がありません。

対応状況を確認してみました。

GitHub Actionsで指定したバージョンが使われるか → ✅ 対応済み

GitHub Actionsは既にactions.lockファイルをサポートしています。

試しに、actions.lockファイルを手動で編集し、全く関係のないコミットSHAを参照するようにしてみました。

すると、GitHub Actionsは下の画像のようにエラーになりました。

このように不正なコミットSHAを正しく検出できていることから、GitHub Actions側は既にactions.lockをサポートしていると考えられます。

Dependa bot → ❌ 2026/9現在では未対応

Dependa botによる依存関係の更新が対応しているかを確認してみました。

意図的に古いバージョンを参照した上でDependa botを走らせたところ、自動アップデートのpull requestは作成されました。

ただし、workflowファイルのバージョンが更新されるだけで、actions.lockファイルが自動的に更新されるわけではありませんでした。

本来ならばworkflowファイルの更新に併せてactions.lockが指すコミットSHAも更新されなければなりませんが、これはまだ手動で行う必要がありそうです。

ただし、機能としては実装が進んでいるようです。

拡張機能側では、2026/6にDependa bot向けのjson出力を行う機構が実装されました。

また、Dependa bot側もactions.lockへの対応作業は完了しており、あとはこの機能が一般ユーザーに解放されるのを待つだけとなっています。

近い将来、Dependa botが作成するプルリクエストもactions.lockに対応しそうです。

Dependa bot Alertへの対応

Dependa bot Alertがactions.lockに対応しているかは確認できませんでした。

（セキュリティアラートが上がっているバージョンを入れるわけにもいかず、検証できなかった）

試してみて対応状況が分かった方がいたら教えてください。

まとめ

GitHub Actionの依存関係のバージョンをピン留めするgh actions-lockコマンドについて紹介しました。

2026年9月現在ではまだTechnical Preview中で情報も少ないですが、興味のある方はぜひ使ってみてください。