結論：GitHub Actions workflow lockfileはActionなどのワークフロー依存を固定しますが、Mac Runner、macOS、Xcodeは固定しません。依存の再現性を高める用途で導入し、Runnerとツールチェーンの管理は別の仕組みで行ってください。
現時点： GitHubはworkflow dependency lockfileを公開プレビューとして案内しています。GitHubのプレビュー告知と公式ドキュメントで、状態と適用範囲を確認できます。
今週の推奨アクション： 既存のmacOS CIから対象ワークフローを1つ選び、依存ロックとRunner環境の責任範囲を分けてレビューします。
この記事は、Actionのタグやブランチが後から別のコミットを指すことを懸念するCIエンジニア向けです。
プレビュー機能の導入を検討するDevOps担当者や、依存審査・Runner運用の方針を整える開発プラットフォーム担当者にも役立ちます。
GitHub Actions workflow lockfileが記録する範囲
workflow dependency lockfileは、ワークフロー内で参照するActionなどの依存について、解決されたコミットを記録する仕組みです。タグやブランチのように移動し得る参照を使っていても、ロックファイルに記録されたコミットをレビューし、接続済みワークフローの依存を追跡できます。公式説明では、対象に推移依存や再利用可能なワークフローの依存も含まれます。
| 対象 | ロックファイルで扱うもの | 別途管理するもの |
|---|---|---|
uses:で参照するAction |
解決された依存コミット。タグやブランチが指す先の変化をレビューできます。 | そのコミットのコードが安全かどうかの評価 |
| Actionの推移依存 | 接続済みワークフローに含まれる依存関係の記録。 | トップレベルの参照だけを見て済ませず、差分の内容も審査します。 |
| 再利用可能なワークフロー | 呼び出し先のワークフロー依存に関する記録。 | 定義元リポジトリ側の変更・更新管理 |
| macOS RunnerとXcode | 対象外です。 | Runnerラベル、イメージ、OS、Xcode、SDKの管理 |
GitHubは2026年10月14日の告知で、この機能を公開プレビューとして発表しています。プレビュー中は仕様や利用条件が変わる可能性があるため、全リポジトリへの一括適用を前提にせず、公式の接続・保守手順を確認してから試験導入してください。
タグ参照と推移依存を一緒にレビューする
たとえば、ワークフローがActionをタグで参照している場合、タグの参照先は後から変わる可能性があります。ロックファイルを導入すると、接続済みワークフローが解決した依存コミットを記録し、更新差分をレビュー対象にできます。これは参照の追跡を助けるものであり、参照先のコードを安全と認定するものではありません。
Actionが別のActionを呼び出す場合は、トップレベルのuses:だけでは依存全体を把握できません。ロックファイルの変更を確認するときは、直接依存の追加・更新だけでなく、推移依存の差分も確認します。依存が増えた理由、変更されたコード、実行時に必要な権限を審査から外さないでください。
依存の変更とRunner環境の変更を切り分ける
Runnerラベルはワークフロー構文上の選択であり、ホストされたRunnerの実体や更新状況はRunner環境側の管理事項です。Runner選択の構文とホストされたRunnerの説明を分けて参照してください。
| 変更例 | 主な確認対象 | lockfileだけで再現できるか |
|---|---|---|
| Actionのタグが別コミットを指す | Actions依存とロックファイル差分 | 依存コミットを追跡する範囲で対応します。 |
| Actionが呼び出す別Actionが変わる | 推移依存と、その変更を含むレビュー | 差分の審査は別途必要です。 |
runs-onのRunnerラベルが変わる |
ワークフロー構文とRunnerの選択 | できません。 |
| macOSイメージやXcode・SDKが変わる | 実行ノードのOS・ツールチェーン管理 | できません。 |
つまり、macOS CIの再現性は依存ロックだけでは完成しません。ビルド結果に影響するRunner環境とツールチェーンを、ロックファイルとは別に把握できる状態にしておく必要があります。自前の実行ノードを運用する場合も、自ホストRunnerの管理要件は依存ロックとは別の確認事項です。
注意： ロックファイルにコミットが記録されていることは、依存が安全であることの証明ではありません。依存を固定することと、その依存自体の安全性を検証することは別の作業です。
再利用可能なワークフローは定義元で追う
ワークフローが別リポジトリの再利用可能なワークフローを呼び出す場合、呼び出し元のロックファイルだけを見て、定義元の内部依存まで管理できたと判断しないでください。呼び出し元は自分のワークフローから見える参照を管理し、再利用可能なワークフローの内部依存は、原則としてその定義元リポジトリのメンテナーが管理・更新します。
運用上は、呼び出し元と定義元の両方に変更レビューの責任者を置きます。呼び出し元のチームは、どのワークフローを利用しているかを確認し、定義元のチームは内部Actionを含む依存差分とリリース判断を管理します。リポジトリが異なる場合、更新をどちらが提案し、どちらが承認するかをあらかじめ決めておくと、片側だけ更新された状態を見落としにくくなります。
actions.lockを段階的に導入する手順
次の手順は、依存固定をmacOS環境の固定と混同せずに試すための流れです。実際の生成・更新・検証方法は、プレビュー中に更新され得るため、作業時点の公式ガイドに合わせてください。
- 対象を選ぶ： macOSとXcodeを使うワークフローから、依存関係と責任者を特定できるものを選びます。
- 参照を棚卸しする：
.github/workflows/actions.lockを含む対象ファイルと、各ワークフローのuses:参照を確認します。再利用可能なワークフローの定義元が別リポジトリなら、その所有者も特定します。 - 試験用変更を作る： 公式手順に沿ってロックファイルを生成または更新し、通常のコードレビューに提出します。
- 依存差分を調べる： 追加・削除・更新されたAction、解決されたコミット、推移依存を確認します。トップレベルの宣言だけでレビューを終えないようにします。
- Runner側を別に確認する：
runs-onの指定、実行環境、macOS、Xcode、SDKを、ロックファイルとは別の項目として記録します。 - 検証結果を確認する： GitHubが案内するロックファイルの検証方法で、古くなった参照や更新漏れを確認します。単なる差分表示だけを検証済みの根拠にしないでください。
- 範囲を広げるか判断する： 試験対象のレビューと実行結果が安定してから、対象ワークフローやリポジトリを増やします。
たとえば、レビューでは次のようにロックファイルの差分を確認できます。このコマンドは変更表示用であり、GitHubが提供するロックファイル検証の代替ではありません。
git status --short
git diff -- .github/workflows/actions.lock
出力例は次のとおりです。実際の表示内容は作業ツリーの状態によって異なります。
M .github/workflows/actions.lock
更新と組織ポリシーはレビューと組み合わせる
Actionの参照を更新したときは、対応するロックファイルも同じ変更単位で更新し、検証結果と差分をレビューに含めます。ロックファイルだけを更新してAction側の意図が分からない状態や、Action側だけを変更してロックファイルを古いまま残す状態を避けます。
GitHubはDependabotによる、接続済みワークフローの依存更新について説明しています。Dependabotの更新範囲に関する公式資料を確認し、自動提案を自動承認と取り違えないでください。更新提案を受け取っても、依存の差分、必要な権限、ビルドへの影響を人が確認する運用が必要です。
組織で必須化する場合は、単一リポジトリ・単一ワークフローで運用を確かめ、レビューの担当者や更新の流れに無理がないことを確認してから範囲を拡大します。実行ポリシーで対象ワークフローを管理する場合も、ワークフロー実行の制御に関する説明で適用範囲を確認してください。プレビューの状態やポリシーの適用先を、組織全体で一律に同じだと仮定しないことが重要です。
よくある疑問への判断
RunnerイメージやXcodeも固定されますか
固定されません。actions.lockが扱うのはワークフロー依存であり、Runnerラベルはワークフローの実行対象、macOSイメージとXcodeは実行環境の要素です。したがって、XcodeやSDKのバージョンを一定に保つ必要があるなら、その管理方法を別に決めます。
再利用可能なワークフローの依存はどこで管理しますか
そのワークフローを定義するリポジトリで、内部依存の管理と更新を行います。呼び出し側は利用しているワークフローと参照先を確認し、定義元の変更を追える連絡・レビュー経路を整えます。複数リポジトリをまたぐ依存管理を、呼び出し側だけで完結させないでください。
lockfileだけで悪意のあるActionを防げますか
防げません。ロックファイルは依存先の変更を追跡し、レビューを助けるもので、コードの安全性を保証しません。提供元や変更内容、Actionに渡す権限を確認し、GitHubのActions安全利用ガイドも参照して審査基準を設けます。
条件に応じて導入範囲を決める
- Action参照の変化をレビュー可能にしたい場合： まず1つのワークフローでlockfileを試し、直接依存と推移依存の差分を確認します。
- 再利用可能なワークフローを複数リポジトリで使う場合： 呼び出し元だけで完結させず、定義元の責任者と更新フローを決めてから対象を増やします。
- 目的がmacOS・Xcode環境の再現である場合： lockfileだけで解決しようとせず、Runnerとツールチェーンの管理を別に設計します。
- 組織全体で必須化したい場合： プレビューの制約、検証結果、例外時の扱いを試験リポジトリで確認できてから、組織ポリシーへの適用を検討します。
現在の方式とMacの実行環境を比べる
workflow lockfileを追加しても、Runner環境の変動、Xcodeの管理、実行ノードの保守は残ります。共有の実行環境だけで運用している場合、必要なツールチェーンを個別に統制しづらいことがあり、自社でMacを保有する場合は更新・障害対応・空き容量などの保守負担が発生します。
依存ロックはあくまでワークフロー依存の管理です。Mac上での独立したビルド実行も必要なら、ロックファイルとは別の選択肢として、NodeMiniのMac mini利用案内で遠隔利用の形を確認できます。短期の検証や専用実行環境が必要な場合は、NodeMiniのサービス案内も選択肢になります。一方、物理接続が必要な作業や、長期にわたる安定した高負荷運用では、自社保有などの構成も含めて比較してください。
最終更新：2026年10月24日。プレビュー状態などは、本文中に示したGitHubの公式告知と公式ドキュメントを基に確認しました。