同じタグで、同じコードが動くか

ある開発チームが、外部アクションを uses: example/deploy@v3 と指定して公開処理を動かすとします。これは架空の運用例です。GitHub Actionsはワークフローに書いた処理を実行し、uses はアクションや再利用ワークフロー（別のワークフローから呼び出して使うワークフロー）を呼び出します。

レビュー時に確認した v3 が後から別のコミットを指すと、利用側のファイルが変わっていなくても実行コードが変わり得ます。コミットはGitに記録した変更の単位です。GitHubは、この可変参照を依存先の侵害が利用側へ波及する経路として説明しています [2]。

2026年10月14日のGitHub公式発表は、ワークフロー依存関係ロックファイルの公開プレビューを案内しました [1]。GitHub Enterprise Cloud（企業向けクラウド版）での公開プレビューです。データ保存地域の要件に対応するデータレジデンシー版も含まれます [1]。

ロックファイルは、参照名と実行対象のコミットを対応付けて記録します。Enterprise Cloudの公式手順では、ワークフロー依存の固定、検査、更新を扱います。プレビューの仕様は変更され得ます。

直接SHA指定と、依存の記録を比較する

SHAはコミットを識別するハッシュ値です。ワークフローに完全なコミットSHAを直接書くと、そのアクションの実行対象を固定できます。ただし、その一行だけではアクション内部から呼ぶ別のアクションまで固定できません [3]。

方法実行対象更新時に見るもの
タグ・ブランチ指定実行時の参照先。移動するとコードも変わり得る [2]上流の変更と参照先
完全なSHAの直接指定指定したアクションのコミット [3]ワークフローのSHA差分とコード
ロックファイル記録したコミットと対象の推移的なアクション依存 [5]参照・lockfileの差分とコード

推移的依存は、直接呼ぶアクションがさらに呼ぶアクションです。.github/workflows/actions.lock は、導入したワークフローと依存の対応を記録します。依存ごとの ref は参照名、commit は実行コミット、owner_id と repo_id は提供元の数値識別子です [4]。

呼び出し先が再利用ワークフローの場合は、管理する場所を分けます。本体への呼び出し参照は呼び出し側で固定できますが、その内部依存は定義元リポジトリのlockfileが管理します。利用側は呼び出し参照を、定義元リポジトリは内部依存を管理します [5]。

固定が確かめるのは、実行対象の同一性です。依存コード自体の安全性は別に審査します。固定したコミットの内容も、導入時と更新時のレビュー対象です [6]。

後輩直接のSHA指定と、ロックファイルでは何を見る範囲が違いますか？

先輩直接呼ぶコードに加え、対象の推移的依存と提供元の記録を管理できる。ただし、共通ワークフロー内部は定義元の管理も必要だよ。

検査の成功と、固定記録の確認完了を分ける

CLI（コマンドラインインタフェース）は、文字でコマンドを入力してソフトウェアを操作する仕組みです。ここでは公式リポジトリの固定コミット d5dca22a06ff8590d50b41612038996800cfb336 のソースとテストを扱います [25, 29, 30]。公開配布CLIがこのソースと一致するか、本番runner（ジョブを実行する環境）がどう動くかは、本稿では検証していません。

固定記録（pin）は、特定のコミットへ固定した記録です。

操作主な目的読み取る範囲
gh actions-lock導入・依存記録の更新既存の固定記録（pin）は通常維持し、新しい依存などを反映する [10, 11]
gh actions-lock --verifyworkflowとlockfileを変えず上流も参照して検査参照との整合を調べ、警告・検出結果も確認する [9]
gh actions-lock --verify-localオフラインの静的検査依存とlockfileの静的な対応や、古い項目などの構造上の不整合。上流pinは再検証しない [9]
gh actions-lock --relock意図した上流更新の取込み参照を再解決し、変更コミットをレビューする [12]

--verify では、完全なバージョンタグが固定コミットを指すかを検査します。ブランチや部分バージョン参照では、固定コミットが参照の履歴に残るかを調べます [8]。通常生成では、上流が進んだだけでは既存pinを更新しません [10]。

固定ソースの検証テストには、通常のCLI実行を扱う例があります。この例では、Dependabot向けに通信を仲介する仕組み（proxy）を使いません [25]。

このテスト例では、既存pinのオンライン検証が判定不能でも、警告を出して成功終了します [25]。Dependabot proxy経由では、同じ判定不能をエラーとして扱います [26]。

終了コード0だけでは、全pinの検証が完了したかを判断できません。運用では警告や検出結果も確認します。

同じテストでは、repo_idを維持する移転を警告付きで許容する例があります [27]。同名でもrepo_idが異なる差替えは拒否する例です [28]。この違いは、固定ソースのCLIに関するテストで確認したものです。

ローカル参照は、置かれた場所で扱いが違う

同一リポジトリ内の実在するアクションを指す ./... は、通常の修正実行で $/... へ移行できます。この形式は、そのリポジトリの実行中コミットを使うため個別の依存記録（lock entry）を要しません。--verify と --verify-local は、この移行を行いません [7]。

固定ソースの移行テストは、ワークフローに加え、同一リポジトリ内のcomposite action（複数の処理をまとめたアクション）の定義も対象にします [29]。解決できない ./... は、そのまま対応済みにはなりません。

取得した外部composite内の ./... には制限が残ります。解決処理と対応テストでは解決不能エラーにし、外部composite内の $/... は、そのcomposite自身の固定コミットからたどります [30]。参照の対応範囲は、配置場所と形式によって異なります。

更新PRと段階導入を、運用例で考える

冒頭の架空チームなら、共有ワークフローの定義元リポジトリから導入し、次に利用側を導入する順序を検討できます。内部依存の管理境界は公式導入手順で確認できます。ワークフロー単位でも一括でも導入できます [24]。

初回生成はlockfileだけでなく、ワークフローの参照表記も変更します。部分バージョンが具体的なバージョンになっても、解決コミット自体は変わりません [17]。レビューではworkflow、同一repo内のaction定義、lockfileの全差分を確認します。

DependabotのGitHub Actions version updatesは、導入済みワークフローのアクション更新を扱います。更新時には、参照とロックファイル内の依存記録を同じプルリクエスト（PR）で変更します。未導入ワークフローの初回導入は代行しません [14]。PRは変更の提案です。コードの安全性を審査する手順は残ります。

手動更新では、参照が移動した理由を上流の履歴で調べてから --relock を使います。固定コミットが到達不能なら、これだけではエラーになります。移動を受け入れる --relock --accept-moved は、理由と新しいコードを確認したうえで選ぶ操作です [13]。

更新中に自己修復できないエラーがあると、通常生成はワークフローとlockfileの変更を書き込みません [18]。削除済みワークフローの記録整理は、全体を対象とした引数なし実行で行われ、対象を指定した実行では対象外を整理しません [19]。

管理側がRequire lockfileポリシーを設定すると、対象にした、アクション依存を持つ未導入ワークフローの実行を遮断できます。対象はEnterprise Cloud（GitHubの企業向けクラウド版）です。設定できるのは、リポジトリ管理者、Organization owner、Enterprise ownerです [15]。Evaluate mode（影響を確認する評価モード）で状況を見ます。更新を維持できる体制を整えてから、Active（実行を制限する適用状態）へ進めます [16]。

許可するアクションの一覧であるallowlistの確認も必要です。導入後のallowlistは、lockfileに記録されたコミットSHAを基準に評価されます [31]。そのため、タグで指定した一覧は一致しなくなります。公式導入手順は、ワイルドカードまたは完全なコミットSHAで許可する方法を案内しています [31]。許可範囲を広げる案と、特定SHAを許す案を区別して検討します。

後輩ファイルを作ってポリシーを有効にすれば、日々の管理は終わりますか？

先輩新しい依存の記録、更新PRのレビュー、検査の警告確認を続ける運用が必要だよ。まず対象を絞って、更新を維持できるかを見るとよいね。

依存の固定と、CI全体の安全性を分ける

CIは、コード変更のビルドやテストを継続的に自動実行する仕組みです。

ワークフローの run: スクリプトもlockfileの固定対象外です。未信頼のイベント値をシェルへ直接埋め込む問題は、別に対策します [20]。GITHUB_TOKEN はワークフローの認証用トークンです。環境secretは環境単位で登録する機密値です。トークンの権限や機密値のレビュー設定も、実行コードへ渡す権限・情報の範囲として管理します [21]。

runner環境の分離や、自ら管理するrunner（self-hosted runner）を未信頼コードから守る設計まで、lockfileが保証するわけではありません [22]。GHES（GitHub Enterprise Server）は公式CLIリポジトリで非対応とされています [23]。

この機能を評価する際は、実行コミットの固定、検査で確認できた範囲、更新PRの審査、別リポジトリ側の管理を一緒に見ます。本稿は公開資料と固定ソースに基づく整理で、実際のリポジトリへの導入や本番runnerの動作検証は行っていません。