GitHub Actionsにロックファイル、依存をコミットで固定【2026年10月】

GitHub Actions でサードパーティの action を @v4 のようなタグで使っている人に、関係の深い発表がありました。

2026年10月14日（米国時間）、GitHub は GitHub Actions のワークフローが使う action を、特定のコミットに固定する「ロックファイル」をパブリックプレビューとして公開しました。GitHub Changelog で発表されています。

GitHub Actions workflow lockfiles in public preview

npm の package-lock.json や Go の go.sum にあたる仕組みが、ようやく Actions にも公式に入った形です。「レビューしたコードと、実際に動くコードを一致させる」ための基盤という位置づけです。

GitHub Actions のロックファイルとは？一言でまとめると

ワークフローが使う action（その action が内部で使う action も含む）を、コミット SHA に固定して記録するファイルです。一度ロックすれば、タグやブランチが後から動いても、ロックしたコミットで実行されます。

ロックファイルは手で編集せず、必ず gh actions-lock で生成・更新するものとされています。

なぜ必要？タグが「動く」問題

GitHub Actions では、uses: 作者/action名@v3 のようにタグやブランチで action を指定するのが一般的です。ところが、タグやブランチは後から別のコミットに付け替えられます。

GitHub Docs は、この点を次のように説明しています。

• タグやブランチは実行時に、その時点で指しているコミットに解決される
• そのため、レビューしたときのコードと、実際に動くコードが同じとは限らない
• action の作者のアカウントが乗っ取られてタグが付け替えられると、自分のリポジトリを何も変えていないのに、悪意のあるコードが動く

これは机上の話ではありません。GitHub は2026年3月の「Actions 2026 セキュリティロードマップ」で、tj-actions/changed-files、Nx、trivy-action などの事例を挙げ、攻撃者が CI/CD の自動化そのものを狙っていると指摘していました。今回のロックファイルは、このロードマップで予告されていた「依存の固定」の第一弾です。

なお、ロードマップの時点ではワークフローの YAML 内に dependencies: セクションを書く案が示されていましたが、公開されたのは別ファイル（actions.lock）にまとめる方式です。

何ができる？4つのポイント

① 推移的な依存まで固定できる

action が内部で使っている action（推移的依存）や、再利用ワークフローの依存もまとめてロックできます。従来の SHA ピン留めでは、自分のワークフローに書いた action しか固定できませんでした。

ただし、他のリポジトリにある再利用ワークフローの依存は、そのワークフローが定義されたリポジトリのロックファイルが担当します。共通ワークフローを持つ組織は、そのリポジトリから先に導入するよう Docs は勧めています。

② ワークフロー単位で段階的に導入できる

いきなり全部を切り替える必要はありません。ワークフローを1つずつ「オンボード」できます。オンボードしたワークフローは、使う依存がすべてロックファイルに載っていないと実行できなくなります。

③ 実行時にリポジトリの「すり替え」も検出する

ロックファイルには、コミット SHA に加えて取得元リポジトリの数値 ID（owner_id と repo_id）も記録されます。名前が同じでも中身のリポジトリが違えば、実行時に止められます。

公式拡張の README によると、ジョブ開始時にリポジトリの改名・移管がないか、固定したコミットがまだ存在するかなども確認され、確認に失敗すると実行がブロックされます。

④ CI で「古いロックファイル」をチェックできる

gh actions-lock --verify で、ファイルを書き換えずにロックファイルが最新かどうかを検証できます。プルリクエストの必須チェックにする使い方が想定されています。

SHA ピン留めとの違い

これまで GitHub は、サードパーティの action を完全なコミット SHA で指定する（ピン留め）よう推奨してきました。Docs は、ロックファイルを導入したリポジトリでは、ワークフロー内での SHA ピン留めは不要になるとしています。

Docs は、ロックファイルの方が優れている理由として推移的依存への対応、ワークフローの読みやすさ、取得元リポジトリの記録を挙げています。

Dependabot と「Require lockfile」ポリシー

Dependabot がロックファイルも一緒に更新

すでにオンボードしたワークフローで Dependabot が action のバージョンを上げると、同じプルリクエストの中でロックファイルの該当箇所も作り直されます。追加の設定は不要です。

ただし、Dependabot はワークフローの新規オンボードはしません。ロックファイルに載っていないワークフローでは「オンボードが必要」と報告するだけです。

「Require lockfile」ポリシーで組織全体に強制

Require lockfile ポリシーもパブリックプレビューです。Enterprise・Organization・リポジトリの管理者が、ロックファイルの利用を必須にできます。

Docs は、いきなり有効にせず、次の順で進めるよう勧めています。

1. 対象を一部のリポジトリ・ワークフローに絞り、Evaluate（評価）モードで試す（Evaluate モードは GitHub Enterprise のみ）
2. Dependabot、ロック更新用のワークフロー、pre-commit フックなどでロックファイルを自動で最新に保つ
3. actions.lock を CODEOWNERS に入れ、ロックファイルの変更をビルドセキュリティの担当者がレビューする
4. 準備ができたら Active モードで強制する

Docs は「ロックファイルは、誰かが差分を読んで初めてセキュリティ対策になる」とも書いています。

料金・提供状況：どのプランで使える？

Changelog は、発表当日に「対象プランを更新した」という編集注記を付け、Free と Team を対象に加えています。一方、GitHub Docs の手順ページの「Who can use this feature?」は、2026年10月15日時点で GitHub Enterprise Cloud のままです。Free / Team で使う場合は、Docs の更新も確認しておくと安心です。

公式拡張の README は「1.0 未満で、ロックファイルの形式やコマンドが予告なく変わる可能性がある」と明記しています。本番の重要なワークフローに入れる場合は、この点を踏まえて判断しましょう。

導入手順：gh actions-lock で始める

Docs の手順を要約すると、次のとおりです。

1. 各ワークフローの uses が、ロックしたいバージョンを指しているか確認する（今の参照先がそのまま固定されるため）
2. GitHub CLI に拡張を入れる

gh extension install github/gh-actions-lock

gh actions-lock
gh actions-lock .github/workflows/ci.yml

注意したいのは、拡張がロックファイル以外も書き換える点です。

• @v3 のような参照が、解決した具体的なバージョン（例: @v3.1.0）に書き換わる
• 同じリポジトリ内の action の参照 uses: ./… が、新しい書き方 uses: $/… に書き換わる
• 許可する action を指定している組織では、actions/checkout@v6 のようなタグ指定の許可リストが一致しなくなる。ワイルドカードか完全な SHA に直す必要がある

タグが正当に付け替えられた場合は gh actions-lock --relock、元のコミット自体が消えた場合は --relock --accept-moved で更新します。どちらも、上流リポジトリの履歴を確認してから実行するよう Docs は注意しています。

プルリクエストまわりの自動化では、AI によるコードレビューも広がっています。

あわせて読みたい

Claude Code Reviewとは？AIがPRを自動レビューする仕組みと使い方【2026年3月リリース】

同じ週のセキュリティ更新：Anthropic の API キーを既定でブロック

10月13日には、シークレットスキャン（コード内の認証情報の検出）の更新も発表されています。

• Anthropic の新しいシークレット種別（anthropic_service_api_key / anthropic_user_api_key）と、Cloudsmith の API キーを検出対象に追加
• Anthropic の2種類は、push protection（プッシュ時のブロック）の既定の対象に。シークレットスキャンが有効なリポジトリ（無料の公開リポジトリを含む）では、これらを含むコミットが自動でブロックされる
• Salesforce がシークレットスキャンのパートナーに加わった

Claude Code などで Claude の API キーを扱う機会が増えているだけに、うっかりキーをコミットしてしまう事故を防ぐ網が一つ増えた形です。

あわせて読みたい

Claude Code「auto mode」とは？承認地獄から解放される新モードを解説【2026年3月】

開発者の反応

公式のロックファイルが出る前から、コミュニティでは同じ課題が議論されてきました。Changelog では、協力者として Andrew Nesbitt 氏、François Proulx 氏、Jesse Houwing 氏、William Woodruff 氏の名前を挙げて謝意を示しています。

• 「GitHub Actions にはロックファイルがない」という問題提起: パッケージ管理に詳しい Andrew Nesbitt 氏は、2025年12月のブログで、有志が作ったロックファイルツールを紹介しつつ、ワークフローの一ステップとして検証する方式では、検証の前に action がダウンロードされてしまうという限界を指摘していました（出典）。今回の公式版は、実行時に GitHub 側で検証する方式です
• ロックしても完全に再現できるわけではない: 有志のロックファイルツールが紹介された Hacker News のスレッドで、woodruffw 氏は「action を推移的にロックしても、実行の完全な再現性までは保証できない」と指摘しています。たとえば Python をセットアップする action が、ランナーの状態や新しいパッチ版によって入れるバージョンを決めるためです（出典）
• 公式対応を求める声: 同じスレッドでは、「他のエコシステムではとっくに解決済みの問題だ」として、ロックファイルを標準機能にすべきだという声も上がっていました（出典）

公式発表自体も「ロックは依存そのものが安全かどうかを判定するものではないので、ロックする前に依存をレビューしてほしい」としています。

IT Picks的な所感

サプライチェーン攻撃への対策として、「タグではなく SHA で固定せよ」は以前から言われていたものの、読みにくさと更新の手間から徹底しにくい——という状況がありました。ロックファイルはこの手間を CLI と Dependabot に任せられるので、SHA ピン留めをためらっていたチームにとって現実的な選択肢になると思います。

特に評価したいのは、推移的な依存と取得元リポジトリの確認まで、GitHub 側の実行時に検証する点です。有志のツールでは難しかった部分で、公式にしかできない対策と言えます。

一方で、まだパブリックプレビューで、拡張も 1.0 未満です。対象プランの記述も Changelog と Docs で揃っていません。まずは重要度の高いリリース用・デプロイ用のワークフローから試し、--verify を CI に入れて運用の手間を見極めるのがよさそうです。ロードマップで予告されている正式版の時期にも注目したいところです。

まとめ

GitHub Actions のロックファイルのポイントをまとめます。

• 発表日：2026年10月14日（GitHub Changelog）
• 状態：パブリックプレビュー（仕様変更の可能性あり）
• 仕組み：.github/workflows/actions.lock に、action と推移的依存のコミット SHA を記録
• 作り方：GitHub CLI の拡張 gh actions-lock
• 対象プラン：Free / Team / Enterprise Cloud（Changelog）。GHES は非対応
• 関連機能：Dependabot 連携、「Require lockfile」ポリシー
• 同じ週の更新：シークレットスキャンが Anthropic の API キーを既定でブロック

サードパーティの action を使っているなら、まずは1つのワークフローで gh actions-lock を試し、生成された差分を確認してみましょう。

IT Picks 編集部

ITツール・Webサービス紹介メディア

IT Picks 編集部。VPS・クラウド・AIツール・SaaSを中心に、実際に検証した情報を届けるITメディアです。「本当に使えるか」を基準に、初心者からエンジニアまで役立つ記事を制作しています。