GitHub Actions cache-modeの設定方法：2026年企業Mac CIのキャッシュ汚染対策ガイド

2026年9月10日、GitHubはGitHub Actionsのキャッシュアクセスを制御するcache-modeを発表しました。公式発表

症状 → 最短の対処
信頼できないPRが信頼済みキャッシュに触れる懸念がある → まずreadかnoneに制限し、キャッシュの更新は信頼できるワークフローに分けてください。
キャッシュ権限だけではMac Runnerの作業領域や認証情報は隔離されません。Runnerの清掃と資格情報の分離も、別の統制として設計してください。

このガイドは、企業のGitHub Actions方針を決めるIT・プラットフォームエンジニア向けです。
iOS/macOS CIの担当者は、キャッシュからビルド工程に渡るリスクを確認できます。
セキュリティ担当者は、非信頼コードと署名資格情報の境界を点検できます。

最終更新：2026年9月24日。 GitHubのcache-mode発表、ワークフロー構文、キャッシュのセキュリティ説明、self-hosted Runnerの安全な利用指針をもとに確認しています。実装時は、利用中の構文と対応範囲を最新の公式資料で再確認してください。

権限モードの違い：復元まで許すか、保存だけ許すか

cache-modeはキャッシュに対する読み取り・書き込みを制御します。GitHubが示す4つのモードの使い分けは、次のとおりです。

この表はキャッシュへのアクセス許可を整理したものです。ジョブ内で実行されるコードの安全性や、Runnerに残るファイルまで保証するものではありません。writeとwrite-onlyを選ぶ場合は、保存データが後続ジョブに与える影響も確認してください。

GitHub Actionsの企業設定では、モード名だけでなく、各トリガーで実際に適用される設定とログを照合します。既定値を思い込みで補わず、公式のワークフロー構文で設定可能な位置と適用範囲を確かめてください。

トリガーの信頼度：PRと保護済みブランチを同じ扱いにしない

pull_requestのジョブは、どのキャッシュ権限にするか

外部からの変更を含み得るpull_requestジョブは、まずreadまたはnoneを候補にします。ビルドにキャッシュが不要ならnone、依存関係の取得時間を抑えつつキャッシュを書き換えさせたくないならreadを検討します。

フォークからのPRについては、GitHubのイベント説明で、イベントごとの実行条件やアクセス範囲を確認してください。キャッシュを読み取れることは、その内容を信頼できることを意味しません。復元した依存物や生成物も、ジョブに渡す入力として扱います。

pull_request_targetやworkflow_runを混同しない

pull_request_targetは、イベント元と実行コンテキストの組み合わせに注意が必要です。非信頼なPRのコードを安易にチェックアウトして実行すると、トークンやシークレットに影響するおそれがあります。GitHubの安全利用上の注意に沿って、権限の強いワークフローでPRコードを実行しないよう設計してください。

workflow_runで後続処理を行う場合も、先行ジョブが生成した成果物をそのまま信頼してはいけません。受け取る成果物の検証と、後続ワークフローの権限を分けて考えます。キャッシュへの書き込みが必要なら、ブランチ保護やレビューなどで入力元を確認できる信頼済みワークフローに限定します。

注意：キャッシュの読み取り制御は、PRコードの実行隔離ではありません。キャッシュ復元後に実行するスクリプト、依存物、生成物の検証は別途必要です。

表の評価は権限設計の出発点です。実際のイベント条件や設定の適用範囲は、使用しているワークフローと公式仕様で確認してください。

キャッシュの影響範囲：キーと復元先を検査する

キャッシュのキーや復元キーが広すぎると、想定と異なるブランチやジョブの内容を復元する可能性があります。キーには依存関係のロックファイルや対象環境を反映し、復元範囲を必要以上に広げないようにします。ブランチ間のキャッシュ共有範囲も、GitHubの依存関係キャッシュの仕様で確認してください。

キャッシュにはシークレット、署名用資格情報、その他の機密データを保存しないでください。保存対象が実行可能なビルド成果物なら、復元しただけで信頼せず、信頼済み入力から作られたことを検証してから後続工程で使います。キャッシュのセキュリティ参考資料もあわせて確認します。

永続化するMac Runner：キャッシュ権限とホスト隔離を分ける

GitHub Actionsのキャッシュ権限は、self-hosted Mac Runner上の作業ディレクトリ、インストール済みツール、ログイン状態、残存資格情報を消去しません。ジョブ終了後も環境を使い続ける構成では、非信頼タスクの実行後に何が残るかを別途調べる必要があります。

GitHubは、self-hosted Runnerで信頼できないワークフローを実行する場合のリスクを説明しています。安全な利用指針を基準に、Runnerグループの分離、クリーンな環境の利用、ジョブ後の再構築が必要かを判断します。実行権限の強い署名処理は、非信頼タスクと同じホストや資格情報に依存させないでください。

物理ホストと仮想化環境の違いを検討するときは、隔離方式そのものを比較対象にしてください。Macのベアメタルと仮想化の違いはホスト構成の検討材料になりますが、どの方式でもジョブ後の清掃や資格情報の管理が不要になるわけではありません。

最小権限の検証：設定値だけでなくログと失敗時の挙動を見る

導入前には、次の項目をチェックしてください。非信頼タスクと信頼済みタスクを分けて実行し、設定、ログ、ホスト状態を証拠として残します。

• [ ] トリガーごとに、コードの信頼度と許可するキャッシュ操作を記録する。
• [ ] read、write、write-only、noneのどれが適用されるかをワークフロー設定で確認する。
• [ ] 実行ログでキャッシュの復元・保存が許可どおりに行われたかを確認する。
• [ ] ワークフロー権限とシークレットの公開範囲が、キャッシュ権限と別に制限されていることを確認する。
• [ ] 保存に失敗した場合やキャッシュが存在しない場合に、処理がどう続行・停止するかを確認する。
• [ ] 永続化するMac Runnerでは、ジョブ後に作業領域、ツール状態、資格情報が残っていないか確認する。
• [ ] 非信頼タスクと信頼済みタスクの検証結果を分けて記録し、承認者が確認できる状態にする。

判定は、権限、ホスト、資格情報の3つを分けて行います。キャッシュの読み書きが意図どおりでも、Runnerの清掃や資格情報分離を確認できなければ、非信頼コードを扱うタスクの拡大は保留してください。

チームで合意する運用方針

プラットフォーム、セキュリティ、開発の各担当者で、次の方針を確認してから対象を広げます。

• 非信頼入力はreadまたはnoneを基本にし、キャッシュへの書き込みは許可しません。
• 信頼済みワークフローがキャッシュを管理し、復元した内容も検証対象にします。
• 本番署名用の資格情報を、低信頼のPR処理や共有Runnerから分離します。
• 試行、修正、適用拡大の判断には、権限ログ、Runner清掃、資格情報分離の証拠を求めます。

自社運用の永続化Macは、作業領域やツール状態の管理を自分たちで担う一方、汎用的なクラウド実行環境は、macOS固有のビルド条件やホスト状態を事前に確認する必要があります。どちらも非信頼PRと署名タスクの境界を自動で解決するものではありません。

一時的なXcode CIやMac Runnerの検証環境が必要なら、MacDateのレンタルMacも比較対象になります。実際の分離方式、清掃手順、資格情報の扱いは契約前に確認し、要件を満たさない場合は自社管理の専用環境を選んでください。MacDateの案内から、チームの運用条件に合うかを確認できます。