GitHub Actions ワークフロー実行保護の検収方法は？2026年企業向けMac CIガイド
PRの実行が止まる不安と、公開ワークフローからMac Runnerへ処理が流れる不安が同時にあるなら、まず評価モードで影響を洗い出します。
判断：リリースとデプロイのワークフローから段階的に強制してください。 GitHub Actions ワークフロー実行保護は起動者、イベント、対象パスを制御しますが、Mac本体やRunnerの隔離を担う機能ではありません。
対象読者：複数リポジトリのGitHub Actionsポリシーを設計する企業IT・組織管理者。
macOS CIの運用を担うプラットフォーム担当者、公開ワークフローを審査するセキュリティ担当者にも向けています。
最終更新：2026年9月28日。 機能の提供状況と日付はGitHubの正式提供告知およびワークフロー実行ポリシーの公式ガイドで確認しています。適用プランや既定ルールの日程は変更される可能性があるため、強制前に最新の公式記載を再確認してください。
組織管理者とリポジトリ管理者：適用範囲を先に確定
GitHubは2026年9月17日にワークフロー実行保護の一般提供を告知しました。ポリシーは起動者、イベント、ワークフローパスを対象に設定でき、評価モード、インサイト、REST APIによる管理が案内されています。実際の設定場所や利用条件は、公式の設定手順とREST API仕様で対象アカウントを確認してください。
最初に、組織とリポジトリのどちらが各ポリシーを管理するかを一覧化します。上位組織のルールとリポジトリ固有の例外がある場合は、優先関係と承認者も記録します。単に「組織で有効」と記すだけでは、対象外のリポジトリや例外の責任者が見えません。
| 対象 | 管理者が決めること | 検収時に残す証跡 |
|---|---|---|
| リリース・デプロイ | 起動者、許可イベント、対象ワークフローパス | ルール設定の記録と許可・拒否の試験結果 |
| 通常のPR検証 | 開発者や自動化アカウントの扱い | 評価結果と影響を受ける実行の確認記録 |
| 例外ワークフロー | 例外の必要性、承認者、再審査条件 | 業務理由、承認履歴、見直し担当 |
公開リポジトリでは、pull_request_targetに対する既定ルールの適用条件を個別に確かめます。公式案内では、条件を満たす公開リポジトリの既定保護は評価モードで動作し、強制開始日は2026年11月2日とされています。一方、私有・内部リポジトリにはこの既定ルールは適用されません。対象範囲と日付は公式のセキュリティ説明で再確認してください。
macOS CI担当者：ポリシーからRunnerまでを分けて検証
実行保護が許可するのはワークフローの起動です。スケジューリング後にどのRunnerへ割り当てられるか、Mac上でどの権限を使うか、成果物がどこへ渡るかは別の管理対象です。ポリシーの検収記録に、Runner隔離や復旧能力まで「確認済み」とまとめないことが重要です。
境界は次のように分けると、責任の抜けを見つけやすくなります。
起動要求
→ 実行保護ポリシー（起動者・イベント・パス）
→ ワークフローのスケジュール
→ macOS Runnerの割り当てとジョブ実行
→ 成果物の保管・配布
実ファイルで対象パスを確認するには、リポジトリのルートで次のように一覧化できます。これはファイルの所在を確認する補助であり、ポリシーが有効であることの証明ではありません。
find .github/workflows -maxdepth 1 -type f -print
出力例：
.github/workflows/ios-pr.yml
.github/workflows/release.yml
プラットフォーム担当者は、PR検証とリリースを別々に起動し、意図したワークフローパスとRunnerに処理が渡ることを確認します。ジョブの実行記録、使用Runner、成果物の受け渡し、失敗時の復旧手順をひとまとまりで保存してください。macOS CIのノード分離や署名用環境を別途評価する際は、自社ホストRunnerのセキュリティ境界も参照します。
セキュリティ担当者：不可信コードと権限境界を審査
pull_request_targetは、プルリクエストの対象ブランチ側のコンテキストで動作し得るため、ワークフロー内で未検証のコードを取得・実行する設計は特に慎重な審査が必要です。イベント名だけで安全・危険を決めず、チェックアウト対象、実行するスクリプト、秘密情報へのアクセスを確認します。公式の安全な利用ガイドは、同イベントと既定保護の適用範囲を説明しています。
セキュリティ担当者は、該当する処理を止める、許可する起動者を絞る、または業務上必要な例外を承認する、のいずれかを選びます。例外には理由、所有者、再審査条件を付け、公開リポジトリ向けの既定ルールを私有・内部リポジトリにも同じ形で適用されるものとして扱わないでください。
FAQでは、評価モードとMacの権限範囲も切り分けます。ここで扱うのは起動制御であり、Runner上の秘密情報やファイルアクセスの保護ではありません。
よくある確認事項
評価モードは既存の実行を止めますか。
評価モードは、強制した場合の影響を把握するための段階です。対象となる既存実行やインサイトを確認し、例外の必要性を判断してから強制へ進みます。アカウントの条件や画面表示は公式ガイドで確認してください。
Mac Runnerの権限もこのポリシーで制限できますか。
できません。起動者、イベント、ワークフローパスの制御と、Mac上のユーザー権限・プロセス分離・秘密情報の管理は別の統制です。GITHUB_TOKENの権限を最小化する公式手順も確認し、ワークフローごとの権限を見直します。
リリース担当者：評価から強制へ段階移行
リリース担当者は、評価結果を見ながら通常のPR検証、手動リリース、制限対象の起動をそれぞれ確認します。チームや自動化アカウントを許可対象に加える場合も、利用実態と責任者を記録し、便利だからという理由だけで広い例外を残さないようにします。
次のチェック項目をすべて確認してから、対象範囲を広げてください。
- [ ] 組織・リポジトリごとのポリシー所有者と適用範囲を記録した
- [ ] リリース・デプロイの対象パス、許可イベント、起動者を照合した
- [ ] 評価結果から影響を受ける既存ワークフローを特定した
- [ ] 通常のPR、手動リリース、制限対象の起動を個別に試験した
- [ ] 必要な例外に業務理由、承認者、再審査条件を付けた
- [ ] Mac Runnerの権限、秘密情報、失敗後の復旧を別項目で検収した
- [ ] 強制後の監視担当と、問題発生時の回帰手順を決めた
不合格があれば、該当するポリシーは評価段階にとどめ、原因と是正期限を管理します。許可ルールを広げて一時的に通すだけでは、意図しない起動経路が残る可能性があります。
購買・管理責任者：准入判断とMac調達を分離
本番准入の判断材料は、対象ワークフロー、評価記録、例外承認、Runnerの権限境界、回帰時の責任者です。すべて確認できた場合は段階的な強制へ進めます。不足が残る場合は期限付きの是正、または強制の一時保留とし、理由を記録します。
専用Macノードが必要かどうかは、別のインフラ判断です。実行保護を有効にしても、Macの容量、署名資産の保管、ジョブ後の環境復旧が自動で解決するわけではありません。逆に、Macを調達・レンタルしただけでワークフローの起動統制が整うわけでもありません。
既存のMacを使い続ける方法は、調達や保守の担当負荷が残り、利用が集中する時期に容量を柔軟に変えにくい場合があります。継続利用する固定環境は安定した運用に適する一方、短期の検証や一時的な増設には過剰投資になることもあります。必要な期間だけMac環境を試したい場合は、SFTPMACのMacレンタル料金とサービス概要を確認し、ワークフロー保護とは別に、データ隔離・権限・運用責任を照合してください。恒常的な高負荷や物理接続が必要なら、自社保有の専用機を含めて比較するのが適切です。