Lesstep
GitHub Actions・actions.lock・2026年11月5日に確認

「lockfile missing pin for …」：GitHub Actions のワークフローのロックファイル（actions.lock）、Set up job で落ちるジョブ、ロックファイルの作り直し方

2026年10月28日から、リポジトリはワークフローが使うアクションと、そのアクションが使うアクションを、.github/workflows/actions.lock に固定できます（GitHub の changelog・パブリックプレビューは10月14日から）。このファイルは GitHub CLI の拡張機能 gh actions-lock が作り、ワークフローは1つずつ載せられます。ワークフローを載せると、GitHub Actions はロックファイルに記録したコミットを動かし、そのワークフローが使うアクションのすべてにエントリが要ります。1つでも欠けると、実行はたいていステップの前で止まります。直すには、ロックファイルを手で書き換えるのではなく、gh actions-lock をもう一度実行し、ワークフローとロックファイルを一緒にコミットします。

見え方

ほかのアクションが呼ぶアクションにエントリが無いと、ワークフローのすべてのジョブが Set up job で、そのアクションと参照を挙げて失敗します（msgvault #1740・2026年11月2日）：

##[error]lockfile missing pin for actions/cache@55cc8345863c7cc4c66a329aec7e433d2d1c52a9

このリポジトリでは、1つのマージのあと、main とすべてのプルリクエストの実行が、変更の中身に関係なくこの形で失敗し、再実行しても通りませんでした。呼ぶ側のアクションが別のリポジトリのものなら、ログにはまずそのダウンロードが出ます（cicd-suite #33）：

Download action repository 'hyperpolymath/cicd-suite@c5270b0e0a0a7177d6ee77fc4451f38978b612f0'
##[error]lockfile missing pin for hyperpolymath/deed-ecosystem@f9d999b60cb5f383679ea19912bcdc49c944973a

ワークフロー自身の uses: の行にエントリが無いと、実行はジョブが始まる前に、ロックファイルに無いアクションを参照する不正なワークフローファイルとして失敗し（metadatastician/standards #784）、実行にはジョブが1つもありません（statistikles #117）。どちらもパブリックプレビューより前の報告です。

./ のパスで使うアクションは例外です。それがエントリの無いアクションを呼ぶと、ジョブはそのステップに来たところで失敗し、その前のステップはもう動いています、と GitHub のドキュメントにあります。

なぜ

ロックファイルには2つの節があります。workflows は載せた各ワークフローが使う参照の一覧、dependencies は参照ごとのタグかブランチ、コミット、リポジトリの数字の owner_id と repo_id です。エントリのキーは owner/repo@ref なので、同じコミットでも別の ref（タグでなく SHA）にはエントリがありません。msgvault では、ロックファイルにあるのは actions/cache@v6.1.0 で、リポジトリの2つのコンポジットアクション（$/.github/actions/go-cache-restore と $/.github/actions/go-cache-save として呼ぶ）が使っていたのは actions/cache/restore@55cc8345… # v6.1.0、つまり同じコミットを SHA で書いたものでした。

こうなるよくある形：

直し方

リポジトリのルートで：

gh extension upgrade gh-actions-lock
gh actions-lock --verify
gh actions-lock

--verify はファイルを1つも変えずに同じ確認をし、問題ごとに種類を出します（下）。引数なしの実行は、欠けたエントリを足し、どのワークフローも使わないエントリを消します。uses: の行を解決したバージョンに書き換えることもあり、@v3 が同じコミットの @v3.1.0 になります。差分を全部見てから、ワークフローとロックファイルを一緒にコミットします。

または、uses: の行を、ロックファイルにすでにある参照に合わせます。msgvault はこちらで直しました（msgvault #1727）：

-      uses: actions/cache/restore@55cc8345863c7cc4c66a329aec7e433d2d1c52a9 # v6.1.0
+      uses: actions/cache/restore@v6.1.0

拡張機能の問題解決のガイドは、ロックファイルを手で書き換えないこと（参照と合わないエントリは拡張機能が断ります）、エラーを消すために消さないことを挙げています。固定した参照はそのまま残るので、ファイルが無いと、すべての参照がいま指すコミットへ解決し直され、動いたタグも警告なしに受け入れられます。変更を戻すには、既定のブランチ（ここでは main）から戻して作り直します：

git fetch origin
git checkout origin/main -- .github/workflows/actions.lock
gh actions-lock

./ のパスで使うアクションがほかのアクションを呼んでいると、拡張機能は local-action のエラーを出し、何も書きません。gh actions-lock --migrate-local-actions は ./ を $/ に書き換え、アクションをワークフローのコミットで動かし、それが呼ぶものを固定します。--ignore-local-actions は ./ のまま残し、それが呼ぶものにはエントリが付きません。

gh actions-lock --verify が出すもの

問題にはそれぞれ見出しと種類があります。終了コードは、エラーが残っていなければ 0、止める問題があれば 1、読めないロックファイルなど道具そのものが失敗したら 2 です。gh-actions-lock のリポジトリの問題解決のガイドから：

ロックファイルの入れ方

gh extension install github/gh-actions-lock
gh actions-lock

これで .github/workflows の下のワークフローがすべて載ります。1つだけなら .github/workflows/ci.yml のようにパスを渡します。コミットの前に確かめることを、GitHub のドキュメントは3つ挙げています：

保つためには、プルリクエストで gh actions-lock --verify を動かすワークフローを必須のチェックにすること（gh-actions-lock のリポジトリの verify-lockfile.yml が例です）と、変わったコミットをだれかが見るように、ロックファイルを CODEOWNERS に入れることを GitHub は勧めています。管理者は Require lockfile のポリシーも設定でき、これは対象のワークフローのうち載っていないもの（uses: が1つも無いワークフローも含む）の実行と、自分のリポジトリで載っていない再利用可能なワークフローを呼ぶワークフローの実行を止めます。

見分け方

失敗したジョブを IntelliJ IDEA から見るなら

Pipeline Inbox for GitHub Actions Workflows は、Lesstep が作っている JetBrains IDE（2024.1 以降）のプラグインです。すべてのリポジトリの実行を、ジョブ・ステップと一緒に IDE のツールウィンドウに並べるので、Set up job で止まった実行がすぐ分かり、いまのブランチの実行はステータスバーに出ます。読むのは無料、失敗したジョブの再実行・キャンセル・ワークフローの実行・デプロイのレビューは Pro（月 US$1.50・30日の無料試用つき）です。

JetBrains Marketplace で入れる

GitHub と GitHub Actions は GitHub, Inc. の商標、IntelliJ IDEA は JetBrains s.r.o. の商標です。このページは GitHub, Inc.・JetBrains のいずれとも提携しておらず、承認も受けていません。

ほかに：「Unable to resolve action」 · 「Invalid workflow file」 · free-disk-space の引っ越し · IntelliJ IDEA で使える GitHub Actions のプラグインの比較 · English