GitHub Actions workflow lockfilesは、適用条件を確認したうえで小規模な試験導入から始めるのが妥当です。依存範囲、参照の一貫性、更新と審査、Runnerや資格情報に残るリスクを指標ごとに比較し、強制ポリシーへ進むための判断材料をまとめます。
GitHub Actions workflow lockfilesは、適用条件を確認したうえで小規模な試験導入から始めるのが妥当です。依存範囲、参照の一貫性、更新と審査、Runnerや資格情報に残るリスクを指標ごとに比較し、強制ポリシーへ進むための判断材料をまとめます。
症状：Actionのタグやブランチが動くと、審査した参照と実行されるコードが一致しないおそれがあります。
最短の対処：GitHub Actions workflow lockfilesは、適用条件を確かめて小規模に試し、検証後に強制範囲を広げます。依存を固定しても安全性の判定やRunnerの隔離は代替できません。
この記事は、GitHub Enterpriseの管理者、Mac CIを運用するプラットフォームエンジニア、サプライチェーンリスクを評価するセキュリティ担当者向けです。
最終更新：2026年10月15日。公開プレビューの状態はGitHubの発表に基づいて確認しています。
GitHub Actions workflow dependency lockfilesは、ワークフローが参照する外部依存関係を追跡し、参照元のリポジトリと解決されたコミットを確認するための仕組みです。これにより、タグやブランチの移動に伴って参照先が意図せず変わるリスクを抑えやすくなります。ただし、CI全体をひとつのロックファイルで固定する仕組みではありません。GitHubの依存ロックファイル仕様で対象と解決方法を確認してください。
外部リポジトリのActionや再利用可能ワークフローと、同一リポジトリ内のローカルActionは区別が必要です。ローカルActionのコードはワークフローと同じリポジトリの管理対象であり、外部参照と同じ形でロックされるとは限りません。依存の定義場所と更新責任は、その依存を公開・管理しているリポジトリにあります。対象範囲を把握する際は、Actionとワークフローの選択・カスタマイズに関する公式説明も照合します。
lockfileが役立つのは、審査時に確認した参照先と実行時の参照先を対応付けやすくする点です。これに対して、Actionを完全なコミットSHAで直接固定する方法は、ワークフローファイル上で参照先を読み取りやすくする一方、各参照の更新を個別に管理する必要があります。lockfileは依存関係をまとめて確認する助けになりますが、どちらの方法もコードレビューや脆弱性評価そのものではありません。依存関係をロックする手順に沿って、リポジトリでの生成・確認方法を検証します。
完全なコミットSHAに固定されていても、そのコードが信頼できるとは限りません。レビュー済みの変更であること、権限が必要最小限であること、更新後に再審査されることは、別々に確認すべき条件です。GitHub Actionsの安全な利用に関する資料も、固定だけで対策が完結しない前提で参照します。
Mac CIのサプライチェーン安全性を評価するときは、参照の固定と実行環境の保護を別の管理項目として扱います。lockfileが改善するのは主に依存参照の確定性です。Runnerが侵害された場合の影響、ワークフローに渡す資格情報の露出、署名権限の悪用は、Runnerの隔離や権限設計で対処します。
| 評価対象 | lockfile | 併用する管理策 | 評価 |
|---|---|---|---|
| Action・再利用可能ワークフローの参照変動 | 解決された参照を記録し、意図しない変更を見つけやすくします | 変更レビューと更新履歴の確認 | ◎ 参照の確定性に有効 |
| 依存コードの信頼性・脆弱性 | 安全性を判定しません | ソース確認、脆弱性対応、承認手順 | △ 単独では不足 |
| Mac Runnerの侵害や横展開 | Runnerを隔離しません | Runnerグループのアクセス制御、使い捨て環境の検討 | × 別の境界で対処 |
| 秘密鍵や公開権限の露出 | 資格情報の利用を制限しません | 最小権限、保管・配布・失効の管理 | × 別の境界で対処 |
評価記号は、公式仕様が示す機能と本記事の運用上の判定を区別するためのものです。Runnerグループのアクセス管理は、自ホストRunnerへのアクセス制御に関する公式文書で実際の組織設定に照らして確認してください。
lockfileを運用に乗せるには、ワークフローの新設・変更時に依存を検出できること、更新差分を審査できること、検証失敗を見逃さないことが必要です。GitHub ActionsのDependabot更新を利用する場合も、lockfileの更新がリポジトリの設定や対象依存にどう反映されるかを公式手順で確認し、レビュー担当と失敗時の戻し方を決めてから運用します。ポリシーを先に強制すると、未対応のワークフローが実行できなくなる可能性があります。
企業では、いきなり全体へ適用するのではなく、対象リポジトリを絞ってポリシーの評価結果を確認し、適用できない参照や未更新の依存を洗い出すのが安全です。Require lockfileポリシーは、2026年10月14日に公開プレビューとして発表されています。正式提供済みとは扱わず、利用資格、対象範囲、設定方法、実際に実行を止める条件は、強制ポリシーの公式ガイドで導入時点の記載を確認してください。
導入前に、次の条件を満たせるかを運用記録で判定します。
評価対象は、依存一覧の網羅性、lockfile更新の閉ループ、変更審査の記録、ポリシー評価、Mac CIでの実行結果です。これらを揃えたうえで、影響を限定した試験から段階的に範囲を広げます。lockfile導入によって改善するのは依存参照の確定性であり、MacホストやRunnerの分離、署名資格情報の保護は別途受け入れ条件として残ります。
Mac CIに必要な構築資源の調達も、ロックファイルの効果とは分けて検討してください。地域や利用形態を含むMac環境の選択肢は、日本向けMac環境の案内とMacクラウドの利用案内で確認できます。
既存のMacを専用Runnerとして運用する方法は、環境を細かく管理できる一方、稼働監視、更新、容量調整を自社で担います。一般的なCI環境だけでは実機Macが必要な工程をまかなえず、開発者用Macの共用は権限や署名資産の分離を難しくする場合があります。試験で一時的なMac容量が必要になったり、Runnerの運用負荷を切り分けて確かめたりする場合は、週・月・四半期単位で利用できるVNCMacのリモートMacも比較対象になります。ただし、長期にわたり常時稼働する専用環境や物理接続が必要な構成では、自社保有を含めて要件と運用責任を比較してください。