2026 GitHub ActionsのMac Runnerで外部PRをどう隔離する？

外部PRを自管理のMac Runnerで実行する際、どこまで許可し、何を隔離すべきかを判断する記事です。実行元、アクセス範囲、署名情報、ジョブ後の清掃を比較表と合否条件で確認し、問題発生時の切り替え手順も紹介します。

外部PRのビルド後もMac Runnerにファイルやプロセスが残り、次のジョブへの影響が心配です。 結論：信頼できない外部PRを、機密情報や残留状態を持つ長期稼働の自管理Mac Runnerへ直接流さないでください。 Runnerグループとリポジトリのアクセスを絞り、テストと署名・リリースを分離したうえで、実行後の清掃とノード復旧を実ジョブで確認します。

開発者向け：外部貢献者のPRを自管理Runnerで実行するか判断したい開発者向けです。 iOSチーム向け：テストビルドと署名・リリースを切り分けたいセキュリティ担当者向けです。 基盤担当者向け：Runnerグループ、ノード清掃、監査の運用を担う方にも役立ちます。

GitHub ActionsのMac Runnerで外部PRを隔離する境界

最初に見るのは、ジョブの起動元と、実際に実行されるワークフローの内容です。PRの差分だけで安全性を判断してはいけません。セルフホストRunnerでは、ワークフローが動くノードのファイル、環境、利用可能な権限もリスクの対象になります。GitHubも、自管理Runnerで信頼できないコードを実行する危険を説明しています。自管理Runnerの安全な利用に関する公式説明

GitHub Actionsのイベントごとに、参照されるワークフローや実行コンテキストは異なります。イベント名だけで安全と決めず、ワークフローを起動するイベントの仕様を照合してください。

外部PRをセルフホストRunnerで動かせるか。 技術的に実行できることと、安全に実行できることは別です。Runnerが署名情報、社内ファイル、別ジョブの残留データへ触れられるなら、外部コードをそのRunnerで動かす設計は不合格です。

Runnerグループとリポジトリの許可範囲

Runnerグループは、利用を許可するリポジトリやワークフローを管理するための境界として確認します。組織内のどのリポジトリが対象か、ワークフロー側の利用条件がどう設定されているかを、Runnerグループのアクセス管理手順とグループの仕組みで確認します。

どのリポジトリに自管理Runnerを使わせるか。 Runnerグループの許可対象を必要最小限にし、対象外のリポジトリからジョブが実行できないことを確かめます。ラベルが合っていることだけでは合格にしません。ラベルでRunnerを選べても、利用権限が適切とは限らないためです。

注意： runs-onに意図したラベルを指定していても、それだけでリポジトリやワークフローのアクセスが制限されたことにはなりません。許可範囲はRunnerグループ側で確認します。

macOS CIの署名情報と権限

テスト用ジョブが署名証明書、プロビジョニング情報、リリース用トークンに触れられる設計なら、外部PRを受け入れる前に分離します。GitHubの説明では、フォークからのpull_requestワークフローでは通常、秘密情報は渡されず、GITHUB_TOKENの権限も読み取り専用に制限されます。ただし、設定変更や別イベントの利用まで含めて確認する必要があります。秘密情報の利用条件

pull_request_targetは、フォークからのPRでもベースリポジトリ側の権限や秘密情報にアクセスできるため、PRのコードをそのままチェックアウトして実行する使い方は避けます。GitHubのこのイベントを安全に使うための注意事項に沿って設計を確認してください。

Mac Runner上の署名情報をPRテストからどう切り離すか。 テストジョブに署名・公開用の秘密情報を渡さず、公開処理を信頼済みの変更と承認に限定します。ログに秘密情報が見えないことは、ジョブやプロセスから読み取れない証明にはなりません。ワークフロー権限、環境変数、キーチェーン、ファイル配置まで確認してください。

実ジョブで確認する清掃と復旧

長期稼働のMac Runnerでは、ジョブの作業ディレクトリだけでなく、キャッシュ、一時ファイル、バックグラウンドプロセス、キーチェーンへの変更も確認対象です。設定ファイルに清掃処理が書かれているだけでは不十分です。GitHubはセルフホストRunnerでジョブ前後にスクリプトを実行する方法を案内していますが、清掃の成否は実環境で検証します。Runnerの前後処理スクリプト

外部コード実行後に何を確認するか。 まず非機密のテストワークフローを実行し、ファイル、キャッシュ、プロセス、権限状態を記録します。清掃後の確認に失敗したら、そのノードを隔離して調査・復旧し、結果と再確認の担当者を記録します。

運用上の注意： 一度のテストで清掃できたことは、以後のジョブでも継続して安全だという保証にはなりません。ワークフローやRunner設定を変更した後も、同じ観点で再確認します。

合否条件と切り替え手順

迷った場合は、次の条件で運用を分岐します。ここでの合格は、記載した設定とテスト結果の範囲内での判断です。法令やセキュリティ認証への適合を示すものではありません。

• Runnerグループが対象リポジトリを限定し、対象外から実行できないことを確認できる場合： その範囲で利用を継続します。ラベルだけを根拠にした許可は不可です。
• 外部PRのジョブから署名・公開用情報へ到達できない場合： テストを分離した状態で実ジョブを検証します。到達可否が不明なら、不合格として機密情報を扱うRunnerから外します。
• ジョブ後に作業領域と不要なプロセスが消え、再利用前の確認を記録できる場合： 検証した条件でのみ再利用します。
• アクセス範囲が広い、秘密情報が見える、または清掃に失敗した場合： 外部PRをその自管理Runnerへ流さず、隔離した実行環境へ切り替えます。ノードを停止・復旧し、ログと再確認の責任者を記録します。

実施手順は、まず許可されるリポジトリとワークフローを一覧化し、Runnerグループの設定と突き合わせます。次に、外部PR用ジョブが持つ権限と参照可能な秘密情報を調べ、公開処理と分離します。続いて非機密のテストを実行し、ジョブ後の状態を検査します。不合格ならRunnerへの割り当てを止め、復旧後に再テストします。セルフホストRunnerの安全性は、YAMLの確認だけでなく、この一連の結果と運用記録で判断します。

現在の長期Runnerを使い続ける構成では、状態の残留確認、秘密情報の分離、アクセス制御の維持を運用側で担い続ける必要があります。短期間のMacビルド環境が必要なら、まずクラウドMacレンタルの利用条件を読み、ノードの引き渡し方法や清掃、権限境界を確認してください。必要に応じて日本向けMacレンタルの案内も比較できます。ZekVPSの利用を検討する場合も、外部PRの隔離や自動清掃が提供されると決めつけず、実際の条件を確認したうえで、短期の検証環境として適するか判断してください。恒常的な高負荷運用や物理インターフェースが必要なら、自社管理のMacを含めて比較するのが適切です。