ビルドが終わっても、次のJobに前のファイルや認証情報が残っていないか不安です。

最短の判断は、信頼できる私有リポジトリの限定タスクなら管理された常駐Mac、不審な外部コードや高権限の署名処理なら隔離した一時実行環境です。作業ディレクトリを空にするだけでは隔離にならず、MacをレンタルしてもRunnerの隔離は自動で実現しません。

独立開発者：GitHub ActionsでiOS Appを構築し、Runnerの再利用と管理負担のどちらを優先するか迷っている人向けです。
小規模チーム：日常ビルドと署名・公開を分け、ワークフローごとの権限を制御したい人向けです。
リリース担当者：常駐Runnerに証明書やAPI認証情報を置くリスクを見直したい人向けです。

01

GitHub Actions macOS Runnerの常駐機・一時機を分ける基準

GitHub Actions 自托管 Runner、つまり自分で管理するRunnerは、繰り返しJobを実行するために常時稼働させられます。ただし、Runnerプロセスがオンラインであることと、前回のJobの状態が残っていることは別問題です。GitHubの自ホストRunnerの仕様を確認し、作業ディレクトリの状態、Runnerログ、リポジトリへのアクセス範囲をそれぞれ点検してください。

運用シナリオ 常駐Mac 一時実行環境 判断の要点
信頼できる私有リポジトリの日常ビルド 適しています。アクセス範囲と後処理を管理します 利用できますが、実行環境の準備が必要です 再利用による運用の簡便さを優先するか
同じリポジトリへの信頼できるPR 条件付きで利用できます 隔離を強めたい場合に適しています イベント、Runnerグループ、Secretsの権限を確認します
外部からのPRや不審なコード 原則として避けます ホストを確実に初期化できる構成を検討します 共有状態や秘密情報に触れられないことが重要です
署名・アップロードを伴う公開 発行専用に限定し、厳格な制御が必要です 使い捨て実行環境と権限分離を検討します 証明書、Keychain、API認証情報を分離します

ここでいう一時実行環境は、Job終了後にRunnerの登録を解除するだけでなく、ホスト上の残存状態も含めて管理できる構成を指します。Runnerの登録解除だけで、ディスクやKeychainまで初期状態に戻ると決めつけないでください。

自托管Runnerは複数のJobを繰り返し実行できますか？

できます。常駐RunnerはJobを受け取れる状態を保てますが、そのことはJob間の完全な状態分離を意味しません。作業領域だけを削除しても、ユーザー領域の設定、Keychain、キャッシュ、バックグラウンドプロセスなどが残る可能性があります。

まず、Runnerログで実行されたJobと終了状態を照合します。次に、ワークスペースの後処理が成功したか確認し、認証情報が作業領域の外に保存されていないか点検します。GitHubも自ホストRunnerのリスクと運用上の注意を安全な利用に関する説明で案内しています。

02

外部コードが入る経路と実行権限

同じリポジトリ名でも、コードの出所によって信頼度は異なります。ブランチ保護やレビューの有無だけで安全と判断せず、イベントの種類と、対象Jobが使えるRunner・トークン・Secretsを確認します。

外部Pull Requestを自ホストMac Runnerで実行できますか？

外部コードを常駐Runnerに渡す運用は避けるのが基本です。PRのコードがRunner上で実行されると、作業ファイルだけでなく、Runnerの環境やアクセス可能な情報に影響するおそれがあります。イベントごとの動作はワークフローを起動するイベントの説明で確認し、フォークからのPRを自ホスト環境に流す設定になっていないか見直してください。

特にpull_request_targetは、ベースブランチ側の権限で動作する用途があり、使い方を誤ると危険です。信頼されていないPRのコードをチェックアウトして実行しないでください。pull_request_targetの安全な利用方法と、Runnerグループのリポジトリ別アクセス管理を照合し、実行経路を閉じます。

ワークフロー設定では、Runnerラベルだけでアクセスを制御したつもりにならないことも重要です。Runnerグループのアクセス範囲と、ワークフローのpermissionsを別々に点検してください。権限は必要なものに限定し、設定構文はワークフローの権限指定で確認できます。

03

署名・公開ジョブと認証情報の境界

通常のビルドと署名・アップロードは、同じRunnerを使う場合でも権限を分けて設計します。証明書の秘密鍵、Keychain、App Store ConnectのAPI認証情報を、すべてのJobから読み取れる状態にしないでください。

iOSの署名鍵を常駐Runnerに置いてよいですか？

無条件に置くべきではありません。署名処理が必要なリリースJobだけに認証情報を渡し、外部PRや通常の検証Jobからは利用できないようにします。署名鍵を常駐機に保存する場合は、リポジトリと公開イベントを限定し、Job終了後の削除・Keychainの扱いを記録してください。

作業前に、各Jobが参照できるSecretsとトークン権限を一覧にします。次に、署名・公開を行うワークフローの起動条件を限定し、Runnerグループも対象リポジトリに絞ります。最後に、秘密値を含まない設定記録と認可履歴で、意図したJobだけが権限を持つことを確認します。

04

Job終了後の清掃と障害対応

Jobごとに何を削除・確認しますか？

作業ディレクトリだけでなく、認証情報、Keychain、生成物、一時ファイル、プロセス、キャッシュの保存場所を洗い出します。どれを削除するかは、次のJobで再利用する必要があるか、機密情報を含むかで決めます。キャッシュを残す場合も、信頼されていないコードと共有しない設計が必要です。

実務では、次の順番で状態を検証します。

  1. ワークフローのon設定を確認し、外部PRが自ホストRunnerに到達しないことを確かめます。
  2. Runnerグループの対象リポジトリと、ラベルを指定するJobを照合します。
  3. 各JobのpermissionsとSecrets参照を点検し、ビルド用と署名用を分けます。
  4. テスト用の代表的なビルドを実行し、Runnerログ、Job結果、作業領域の後処理を照合します。
  5. 秘密値を表示せずに、Keychainや認証情報の削除・無効化が行われた記録を残します。
  6. 一時Runnerでは、Job後の登録解除だけでなく、ホストや実行環境の初期化方法も確認します。

一時Runnerにしても、診断情報が自動で保存されるわけではありません。障害を追えるよう、秘密値を除いたRunnerログ、Jobの結果、後処理の成否を外部に保管します。GitHubの監視とトラブルシューティングの資料およびRunnerの削除手順を参照し、登録解除と環境初期化を混同しない運用にします。

05

常駐Macを選ぶ前の最終確認

常駐Macは、信頼できるコードだけを処理し、Runnerへのアクセスを限定できる場合に有効です。長所は環境を再利用しやすいことです。短所は、ワークスペース以外の残存状態も継続して管理する必要があることです。

一時実行環境は、Jobごとの状態を分離しやすくできますが、診断ログの保存やホストの初期化を別途設計しなければなりません。外部コードを動かす必要があるなら、ホストのリセットまで確認できる隔離環境を使うか、そのコードを自ホストRunnerで実行しない選択をしてください。方式だけを変えて、隔離が保証されたと見なすのは避けます。

すでに手元のMacを使っている場合、常時稼働させる保守負担や、開発作業とCIの環境が重なる点が弱点になります。Macを持たずに汎用クラウド実行環境だけで済ませる場合は、macOS専用ツールを使うビルド要件を満たせるか確認が必要です。専用のmacOS環境を必要な期間だけ使いたいなら、リモートMacの利用案内で利用方法を確認し、構成や接続条件が自分のワークフローに合うか照合してください。

VpsMeshのMacをレンタルする選択肢は、専用のMacを購入して保守する負担を避けたい場合に検討できます。Macの利用可能な環境を確認したうえで、Runnerの登録、アクセス制御、署名情報の保管とJob後の処理は自分の構成で検証してください。レンタルはmacOS環境を用意する方法であり、Runnerの隔離を自動で提供するものではありません。