GitHub Actionsのワークフローロックファイルがパブリックプレビューに

GitHubは2026年10月14日、GitHub Actionsのワークフロー依存関係ロックファイルをパブリックプレビューにしました。新しいファイル.github/workflows/actions.lockは、ワークフローが使うすべてのアクションの背後にある正確なコミットを記録します。後の実行で、別のコードがひそかに取り込まれることはなくなります。これは、チームがこれまで手作業でふさぐ必要があったサプライチェーン上の穴です。

GitHub Actionsは、コードが変更されたときに、テストやデプロイなどの自動ジョブを実行するGitHubの仕組みです。これらのジョブは、アクションと呼ばれる再利用可能なステップで組み立てられます。ほとんどのアクションは、他人のリポジトリに置かれています。

ロックファイルが解決する問題

ワークフローは通常、actions/checkout@v6のように、タグやブランチでアクションを指定します。その名前が、明日には別のコードを指しているかもしれません。GitHubのchangelogは、「ワークフローをレビューした後でタグやブランチが動く可能性があるため、後の実行で別のコードが実行されるかもしれません」と述べています。GitHubのドキュメントは、それが起こる一つの例として、上流のメンテナーのアカウントが乗っ取られ、タグが移される場合を挙げています。

これまでの主な防御策は、ワークフローファイルの中で、各アクションを完全なコミットハッシュ（SHA）に固定することでした。GitHubのドキュメントは、ロックファイルを導入したリポジトリでは、それは「もう必要ない」としています。手作業での固定では、ほかのアクションが取り込むアクションも見落とされていました。ロックファイルは、そうした間接的な依存関係、つまり推移的な依存関係もカバーします。

actions.lockの仕組み

ファイルを書き出すのは、gh actions-lockというコマンドラインツールです。これは、GitHubのコマンドラインクライアントghの拡張機能です。gh extension install github/gh-actions-lockでインストールし、リポジトリのルートでgh actions-lockを実行します。ファイルの冒頭には、手で編集しないよう求める警告があります。

各依存関係のエントリーには、4つの値が保存されます。参照、解決されたコミット、そして数値のオーナーIDとリポジトリIDです。実行時には、ActionsがこれらのIDを確認します。これにより、その名前の背後にあるリポジトリが、ロックしたときと同じものであることが確かめられます。

項目	内容
ファイル	.github/workflows/actions.lock
ツール	gh actions-lock（GitHub CLIの拡張機能）
対象	直接のアクション、推移的なアクション、再利用可能なワークフローの依存関係
プレビュー対象のプラン	Free、Team、Enterprise Cloud、データレジデンシー付きEnterprise Cloud
強制	Enterprise、組織、リポジトリの管理者向けの「Require lockfile」ポリシー
状況	2026年10月14日からパブリックプレビュー

チームは、ワークフローを1つずつでも、一度にまとめてでも導入できます。たとえばgh actions-lock .github/workflows/ci.ymlのように実行します。その後は、ワークフローが使うすべてのアクションにエントリーが必要になり、Actionsは記録されたコミットを実行します。このツールは、@v3のような緩い参照を、見つかった正確なバージョン（たとえば@v3.1.0）に書き換えもします。

上流のタグが正当な理由で移動した場合は、gh actions-lock --relockでエントリーを更新します。force-pushの後などに、ロックしたコミットが消えてしまった場合は、ドキュメントが--relock --accept-movedを案内しています。

誰が使えるか、Dependabotは何をするか

changelogには、Free、Team、Enterprise Cloud、データレジデンシー付きEnterprise Cloudの4つのプランが挙がっています。編集者注によると、GitHubは10月14日にこのリストを変更しました。OpenToolsを含む初期の報道は、プレビューをEnterprise Cloud限定と伝えていました。セルフホスト版のGitHub Enterprise Serverについては、どの情報源も触れていません。

同じくプレビュー中の「Require lockfile」ポリシーを使うと、管理者はロックファイルを必須にできます。このポリシーは、Enterprise、組織、リポジトリの各レベルで機能します。

Dependabotは、GitHubの依存関係更新ボットです。ロックファイルを導入済みのワークフローでDependabotがアクションを更新すると、同じプルリクエストの中で、対応するロックファイルのエントリーも再生成するようになりました。GitHubのドキュメントによると、Dependabotが新しいワークフローを自動で導入することはありません。

ロックファイルがしないこと

ロックファイルはコードを固定しますが、検査はしません。GitHubのchangelogは、ロックする前に依存関係をレビューするようチームに求めています。開発者のDave Kurian氏も、DEV Communityのガイドで同じ点を指摘しています。同氏は「ロックは、ワークフローの依存関係がどのコミットに解決されるかを記録するもので、アクションが安全かどうかを評価するものではありません」と書いています。

再利用可能なワークフローには、注意点が1つあります。再利用可能なワークフローとは、ほかのワークフローから呼び出される、1つのまとまったワークフローです。これは、呼び出す側ではなく、それが定義されているリポジトリのロックファイルでカバーされます。ドキュメントは、1つの中央リポジトリからワークフローを共有しているチームに、まずそのリポジトリをロックするよう勧めています。

開発者にとっての意味

• まず1つのワークフローから始めましょう。 最初にデプロイやリリースのワークフローをロックしてください。こうしたワークフローは、通常もっとも強い認証情報を持っているからです。範囲を広げる前に、何回かの実行を見守りましょう。
• 許可リストを修正しましょう。 一部の組織は、actions/checkout@v6のようにタグでアクションを許可しています。GitHubのドキュメントによると、そうしたエントリーはロックされたワークフローと一致しなくなります。ワイルドカードか完全なSHAに切り替えてください。
• 先にアクション向けのDependabotを有効にしましょう。 Dependabotは同じプルリクエストの中でロックファイルのエントリーを最新に保つので、ロックされたワークフローが古くなりません。
• CIで古いロックファイルを確認しましょう。 このツールは、ファイルを一切変更せずにエントリーを確認できます。OpenToolsは、古いロックファイルで失敗する必須チェックと、ファイルに対するコードオーナーのレビューを提案しています。
• カバー範囲が整うまで、ポリシーは保留しましょう。 「カバー範囲と更新の自動化が整う前にポリシーをオンにすると、ワークフローの実行がブロックされる可能性があります」と、OpenToolsは警告しています。まず測定し、それから強制してください。
• オーナーIDやリポジトリIDの変化は警報として扱いましょう。 GitHubのドキュメントによると、そうした変化はまれなはずです。マージする前に調べてください。