キャッシュ権限はタスクごとに分け、ワークフロー設定とJob設定の両方を確認してください。Job側の指定が優先されるため、低信頼イベントに書き込みを許す前にキャッシュ投毒の可能性を評価し、実行ログで設定の効果を確かめるのが最短です。
Mac CIのキャッシュを管理する開発者向けです。
低信頼イベントの権限を監査するセキュリティ担当者や、複数のAppleプロジェクトへルールを広げる基盤チームにも役立ちます。
最終更新：2026年9月28日。GitHubのcache-mode公開情報とワークフロー構文を照合しています。
cache-modeで分けるキャッシュ権限
GitHubは2026年9月10日の告知でcache-modeを公開し、すべてのプランで利用できると案内しています。設定はワークフロー単位とJob単位で扱え、Job側の指定が優先されます。まずは公式のcache-mode案内とワークフロー構文の定義で、利用中の記述方法と指定値を確認してください。
権限設計では「復元できるか」「保存できるか」「どちらもできないか」を分けます。依存関係を使ってビルドするだけのJobに保存まで必要とは限らず、キャッシュがなくても成立する検査ならアクセス自体を無効にする選択肢があります。具体的な設定値を記憶や他のアクションの書式から推測せず、公式構文に合わせることが重要です。
GitHub Actionsのキャッシュは、単なる高速化の仕組みではありません。公式の依存キャッシュに関するセキュリティ説明も踏まえ、どの実行が内容を書き換え、その内容を後のどの処理が信頼するのかを追ってください。権限を絞っても、認証情報や成果物の扱いを含むワークフロー全体の安全性までは保証されません。
Job単位の優先順位と検証
ワークフロー全体に設定を置くと、複数Jobの初期ルールを揃えやすくなります。一方で、Jobに別の設定があればそちらが優先されるため、ファイル冒頭だけを見ても実効権限は判断できません。キャッシュ権限を確認するときは、各Jobの定義、再利用ワークフローの呼び出し部分、実行ログをひと続きに点検します。
設定を変更したら、キャッシュの復元と保存を別々に見ます。ログに復元の記録があっても、保存も許可されたとは限りません。また、ビルドが速くなったことやキャッシュがヒットしたことは、想定した権限が適用された証明ではありません。GitHubのキャッシュ管理手順を確認し、対象実行で何が起きたかを記録してください。
低信頼イベントと再利用ワークフロー
pull_request_targetを使うワークフローでは、イベントを起こしたコードと実行権限の関係を慎重に確認します。GitHubはこのイベントを安全に使うための注意事項を公開しており、信頼できないコードを扱う処理へ不用意な権限を与えないことが重要です。キャッシュ書き込みが必須でなければ、書き込みを許可しない構成に戻し、変更後のログを確認します。
低信頼イベントに書き込みを許すと、後続のビルドが参照するキャッシュ内容を汚染される可能性があります。キャッシュ投毒を完全に防ぐ設定だと見なすのではなく、書き込みが必要な理由、保存対象、後続処理との信頼関係を個別に評価してください。GitHubの安全な利用に関するガイドも併せて確認できます。
再利用ワークフローでは、呼び出し元と呼び出される側の双方を見ます。GitHubの再利用ワークフローの仕様では、呼び出された側が呼び出し元から与えられた権限を超えられないことを確認できます。ただし、呼び出し元が広い権限を与えていれば、その範囲で処理が実行されます。共通ファイルだけを見て「各リポジトリで制限済み」と判断しないでください。
運用に組み込む確認手順
設定変更は、代表的なリポジトリで段階的に試します。次の順序なら、キャッシュの利便性とアクセス境界を混同せずに記録できます。
- ワークフローとJobを一覧にし、それぞれのトリガー、実行コード、キャッシュの使用目的を記します。
- 各Jobを「復元のみ」「復元と保存」「キャッシュ利用なし」のどれにするか決め、必要性を説明できない書き込み権限は外します。
- ワークフロー単位の設定とJob単位の設定を照合し、優先されるJob側の例外が意図したものか確認します。
pull_request_targetなど低信頼イベントを個別に抽出し、外部コードを実行する処理に不要な保存権限がないか確認します。- 再利用ワークフローの呼び出し元と呼び出し先を照合し、呼び出し元が許可する範囲を超える設定に頼っていないか調べます。
- 代表的な成功・失敗ケースを実行し、キャッシュ復元、保存、Xcodeビルド結果を別々に確認します。期待と異なる場合は、まずJob側の指定とトリガー条件を見直します。
- 権限の理由、確認したログ、ロールバック方法を残してから、チームの基準に沿って他のリポジトリへ展開します。
監査記録には、キャッシュが速くなったかだけでなく、どのイベントがどの権限で実行されたかを残します。Mac CI全体の受け入れ確認では、キャッシュ以外にツールチェーンや成果物の保存も点検対象です。関連するMac環境の利用手順も確認し、実行環境側の準備とリポジトリ設定を分けて管理してください。
権限設計の比較と評価
| 選択肢 | 許可する処理 | 適するJob | 確認する証拠 | 評価 |
|---|---|---|---|---|
| 復元のみ | 既存キャッシュの利用 | 読み込んだ依存関係で検査・ビルドするJob | 復元ログがあり、保存処理を許可していないこと | 低信頼入力を扱う場合の第一候補 |
| 復元と保存 | 既存内容の利用と新しいキャッシュの保存 | 信頼できるコードからキャッシュを更新するJob | 復元と保存のログ、保存対象、実行トリガー | 更新が必要なJobに限定 |
| キャッシュ利用なし | 復元・保存ともに行わない | キャッシュ不要、または信頼境界を分離したいJob | 対象Jobにキャッシュアクセスがないこと | 権限を最小化しやすい |
評価はキャッシュ命中率ではなく、許可した操作と実際のログが一致するかで決めます。運用の観点では、広い共通設定よりも、Jobごとに必要性を説明できる設計のほうが監査しやすくなります。
FAQ
GitHub Actionsのキャッシュ設定はどの粒度で確認しますか
ワークフロー全体の設定だけでなく、Jobごとの指定を確認します。Job側が優先されるため、最終的な権限は実行対象のJobで判断してください。公式構文と実行ログを突き合わせ、復元と保存を別々に検証します。
pull_request_targetにキャッシュ書き込みを許可する基準はありますか
書き込みが処理上必要で、対象イベントが扱うコードや入力を信頼できると説明できる場合に限って検討します。判断できない場合は書き込みを許可せず、イベントの安全な扱いを公式ガイドと照合してください。設定変更後もログで意図した境界を確かめます。
再利用ワークフロー側だけを確認すれば十分ですか
十分ではありません。呼び出し側が許可した権限の範囲が上限になるため、呼び出し元の設定と再利用先のJob設定の両方を確認します。特に複数リポジトリで共通処理を使う場合は、呼び出し元ごとの権限理由も記録してください。
Mac CI環境の選び方と次の確認
手元のMacだけで検証を続けると、開発作業とCI試行が同じ環境を取り合い、設定変更の再現性も保ちにくくなります。共有環境では実行条件や権限境界が見えにくい場合があり、キャッシュ設定の比較が曖昧になりがちです。まず代表リポジトリで手順を固め、継続的なCI運用ではツールチェーンと成果物の扱いまで含めて環境を評価してください。
キャッシュ権限だけを検証する一時的なMac環境が必要なら、手元の作業環境と切り分けられるレンタルMacも選択肢になります。長期の安定した高負荷運用や物理インターフェースが必要な場合は、自社保有環境のほうが適することもあります。試行用の選択肢として、SSHMacのMac miniレンタルプランを確認し、必要な期間と運用条件に合うか比較してください。