今回のニュース：名前ではなく、動かすコミットを記録する

GitHubは2026年10月14日、Actionsのワークフロー用ロックファイルのpublic previewを発表しました。レビュー後に参照タグが動き、次の実行で別のコードを使ってしまう問題への対策です。

発表ではEnterprise Cloud、データレジデンシー付きEnterprise Cloud、Team、Freeを対象に挙げています。一方、10月15日に確認した導入Docsの対象欄はEnterprise Cloud表記でした。資料の表記差があるため、すべての契約・環境で利用できるとは断定しません。 公式拡張のREADMEではGitHub Enterprise Serverは非対応です。

この記事は公式資料の確認に基づく解説です。拡張をインストールしたり、当サイトの公開設定を変更したりした実証記事ではありません。

タグとコミットの違いを、荷物の伝票で考える

理解のための架空例です。あるサイトの公開処理が「Action Aのv3」を使っています。v3というラベルが同じでも、配布元が指す先を変えれば、受け取る中身が変わる可能性があります。

ロックファイルは、ラベルに加えて「今回確認した荷物の識別番号」を控えるようなものです。ただし、その荷物が最初から安全か、別便で取得する部品まで同じかは別問題です。この例は仕組みの説明で、実際の事故を示していません。

公式の概念説明では、.github/workflows/actions.lock に解決先のコミットやリポジトリの識別情報を記録します。導入したワークフローは記録されたコミットを使い、許可されたActionのポリシーもそのコミットに対して確認されます。ファイルは手書きせず、公式ツールで生成するものです。

全部の依存関係を一括で守れる、とは考えない

重要なのは再利用ワークフローの境界です。呼び出される再利用ワークフローの内部依存関係は、その定義元リポジトリのロックファイルが担当します。 呼び出し側に一つ作れば、その先の内部依存関係まで全部固定できるという意味ではありません。

当サイトの点検案では、自分のワークフロー、共有ワークフロー、その定義元の管理担当を分けて整理します。さらに、実行中にスクリプトが取得するファイル、パッケージ、コンテナ、ランナー環境まで含めた「ビルド全体の再現性」は別に調べます。ロックファイルを、そのすべての保証と読み替えないことが大切です。

導入前の点検：いきなり本番の公開処理で試さない

以下は当サイトの段階的な確認案です。実環境の実行手順を検証したものではありません。

  1. 棚卸しする：どのワークフローが外部Actionや共有ワークフローを呼ぶか、誰が管理しているかを確認する。
  2. 先に中身と版を確認する：古い・不要な依存関係を、そのまま固定しない。固定したい版の変更履歴や必要権限をレビューする。
  3. 承認済みの検証ブランチで一つから試す：導入Docsには、公式CLI拡張で特定ワークフローを指定して生成する方法がある。現在のヘルプと仕様を確認し、元に戻せる差分を残す。
  4. 生成された全差分を見る：ロックファイルだけでなく、ワークフローや同一リポジトリのAction参照が書き換わる場合もある。想定外の変更はマージしない。
  5. 許可ポリシーと実行を点検する：タグを指定した許可設定は、ロックされたコミットに一致しなくなる場合がある。停止しても保護を無効化せず、担当者が必要なコミットの許可範囲を確認する。
  6. 更新担当と記録を決める：対象ファイル、確認したコミット、差分レビュー、検証結果、残る確認事項を残す。PR作成・マージ・公開成功を同一視しない。

これは読者が自分の管理対象を点検するための案です。トークンの公開、新しい強い権限、他人のリポジトリへの操作は必要ありません。

固定したまま放置しない：検証と更新は別の作業

公式拡張のREADMEは、形式やコマンドが変更され得るpre-1.0のプレビューだと明記しています。gh actions-lock --verify は書き込みなしの検査ですが、オフライン用の --verify-local は記録の信頼性まで確認するものではありません。名前が似ていても役割を混同しないでください。

通常の生成処理で、既存のブランチ参照や部分バージョンを毎回最新版へ進めるわけでもありません。参照先の移動でエラーが出た場合は、配布元の履歴を調べてから更新を判断します。検査を通すためだけに、移動を無条件で受け入れてはいけません。

Dependabotの公式説明では、導入済みワークフローのActionにバージョン更新PRを作る際、対応するロックファイルの記録も同じPRで再生成します。ただし、Dependabotが未導入のワークフローを自動で導入済みにするわけではありません。バージョン更新と、既知の脆弱性に対するセキュリティ更新も別の機能です。

当サイトの評価：レビューした対象を追いやすくする一手

有用なのは「その名前を使っていた」から「どのコードを動かすと決めたか」へ記録を進められる点です。配布元の参照が動いたときの切り分けにも役立つと考えます。

一方、ロックしたコードが安全になるわけでも、脆弱性修正が自動で本番へ届くわけでもありません。プレビューの提供条件、共有ワークフロー側の対応、実行環境の互換性は未確認として残します。パッチ適用の優先順位と合わせて、固定・レビュー・更新・公開確認を一つずつ管理しましょう。