信頼できる定常ジョブは、権限とホスト清掃を管理できる場合に常駐Runnerを検討できます。不可信なコードや高権限ジョブは一時Runnerを優先し、実行後にホストを消去または再構築してください。一時登録の解除だけでは、Macが清潔な状態に戻った証拠にはなりません。
自托管Mac Runner群を運用し、ジョブごとの再利用方法を決めるIT担当者向けです。
iOS/macOS CIの実行境界を設計するプラットフォームエンジニアや、構築基盤の責任範囲を整理する技術責任者にも役立ちます。
今週の推奨アクション： ワークフローを信頼度と必要権限で分類し、Runner登録、ホスト清掃、資格情報の処理、ログ保管をそれぞれ別の検収項目にしてください。
信頼境界はRunnerの所属先ではなく実行コードで決める
同じリポジトリや組織に登録されたRunnerでも、実行するコードがすべて信頼できるとは限りません。外部コントリビューターの変更を扱うジョブ、保護されていないブランチの処理、署名や公開に関わる処理は、ワークフローの起動条件と権限設定を確認してから分類します。
GitHubは、自托管Runner上で信頼できないワークフローを実行すると、Runner環境やそこからアクセス可能な情報にリスクが及ぶ可能性を説明しています。自托管Runnerの安全な利用に関するガイドを基に、少なくとも次の境界を点検します。
- 信頼された変更：レビュー済みブランチからのビルドなど、コードと実行権限の管理状態を確認できる処理です。
- 外部コードを含む変更：フォークからのプルリクエストなど、実行コードを事前に信頼できない処理です。
pull_request_targetは特別な権限上の注意が必要であり、外部の変更をチェックアウトして実行する構成を避けます。pull_request_targetの安全な使い方も確認してください。 - 保護された署名・公開処理：署名鍵や配布権限を使う処理です。通常のビルドとは分け、環境保護ルールや承認条件を含めて管理します。環境とデプロイ保護の仕組みは実行の承認や保護に使えますが、Macホストの隔離を代替するものではありません。
タスク間の隔離は登録解除とホスト清掃を分けて検収する
一時Runnerと常駐Runnerの重要な違いは、ジョブ終了後に同じホストを次のジョブへ渡す前提があるかどうかです。GitHubのRunner資料では、一時Runnerを1つのジョブだけ処理する用途で構成でき、ジョブ終了後にRunner登録が自動解除されます。ただし、これはMacのディスクやユーザー環境を消去する機能の保証ではありません。自托管Runnerの構成と一時Runnerの説明を、ホスト側の清掃手順と区別して読みます。
- 常駐Runnerは、Xcodeや依存関係を維持し、キャッシュを再利用しやすい一方、作業領域、テンポラリファイル、シミュレーター状態などが次のジョブに残らない仕組みが必要です。
- 一時Runnerは、Runner登録をジョブ単位にできますが、同じMacを再利用するならホスト上の残留物を別途処理します。再構築の仕組みがない場合、登録解除だけを隔離完了の証拠にしてはいけません。
- 干渉を受けにくい再構築環境は、ジョブ後に既知の状態へ戻す設計が可能です。ただし、実際に消去される範囲と再構築の検証記録が必要です。
検収では、「ジョブ終了」「GitHub上のRunner登録解除」「Mac上の清掃」「クリーンな状態からの再構築」を別々の状態として記録してください。運用ログに登録解除の記録しかなければ、ホスト上のデータが消去されたとは判断できません。
資格情報はジョブ単位で渡し、ホストに残らないことを確かめる
Mac CI環境の隔離では、ワークフローから参照できるSecretsやトークンだけでなく、署名用Keychain、ログインユーザーの権限、社内ネットワークへの経路も対象になります。ジョブ終了後に次のタスクが同じユーザー環境を使うなら、認証情報が残存・再利用される可能性を検討してください。
GitHubのGITHUB_TOKENはジョブ終了時に失効し、ジョブが長時間続く場合も有効期間には上限があります（最大24時間）。これはトークンの性質であり、ホスト上に保存した別の資格情報やKeychainを消去するものではありません。GITHUB_TOKENの権限と有効期間を確認し、ワークフローが要求する最小限の権限に設定します。
フォーク由来のプルリクエストでは、既定でSecretsが渡されず、GITHUB_TOKENも読み取り専用に制限されます。ただし、リポジトリや組織の設定、ワークフロー構成によって条件が変わり得るため、「フォークだから安全」と決めつけず、実際の設定を確認します。Secretsの利用範囲と安全なワークフロー運用の注意事項を根拠に、次の項目を点検してください。
- ジョブが参照できるSecretsとトークンの権限
- 署名用Keychainを使う処理と、通常のビルド処理の分離
- ジョブ終了後のKeychain、作業領域、テンポラリファイルの扱い
- ホストから接続可能な社内サービスと、そのアクセス制御
- 削除・失効の実行記録と、次のジョブから再利用できないことの確認
Runnerグループや環境の承認ルールは、ジョブの割り当てや実行条件を制御します。これらをMacホストの隔離や資格情報の消去と同一視せず、ネットワーク境界、macOSユーザー、ホスト清掃の証拠も別に確認します。
注意： 一時Runnerの登録を解除しても、ホストを再利用する設計なら清掃の責任は残ります。清掃完了を示す記録が取れない場合は、次の信頼境界の異なるジョブへ同じ環境を渡さない運用にしてください。
ツールチェーンの再利用と基準状態の検証を比較する
常駐Macでは、Xcode、依存関係、キャッシュを維持しやすく、環境の更新手順も単一ホストに集約できます。一方、ツールチェーンの更新差分やワークスペースの残留が次のジョブに影響しないか、継続して確認する必要があります。
一時Runnerでは、環境を再構築する手順と基準イメージを管理することで、状態を説明しやすくできます。ただし、Xcodeの版、依存関係の取得元、シミュレーター状態、キャッシュの扱いが同じかどうかは実測が必要です。測定していない限り、再構築でビルドが速くなる・遅くなるとは判断できません。
導入時は、代表的なワークフローを両方の方式で実行し、次を記録します。Xcodeの版と選択されたパス、依存関係の解決状態、作業領域の残留、Simulatorの状態、キャッシュを消した場合の再現性です。確認結果を更新前後で比べれば、常駐環境の保守性と再構築環境の再現性を、推測ではなくチームの実態に基づいて評価できます。
監査証跡と故障診断はRunner削除後も残す
一時Runnerを削除すると、ホスト上にだけ存在する診断情報も失われることがあります。Runnerの登録記録、ジョブログ、清掃結果、環境の基準情報を、ホスト削除後も調査できる形で保管してください。GitHubの監視・トラブルシューティング資料はRunnerのログ確認を案内しているため、運用設計ではログを外部へ転送し、削除後に参照できることまで検収します。Runnerの監視とトラブルシューティング
手順としては、ジョブ開始時にRunner識別情報と環境の基準情報を記録し、終了後にジョブ結果と清掃処理の結果を同じ識別子で関連付けます。診断ログにはトークンや署名情報を含めないよう、出力内容のマスキングも確認してください。
GitHub上のRunner登録を削除する操作と、Mac上のデータを消去する操作は別です。Runner登録の削除手順を実施した後も、ホスト側の再利用可否を判定し、ログ転送と調査手順が機能するか確認します。
環境確認用の記録例です。実行環境に合わせて、機密値を出力しないよう項目を選びます。
date -u '+%Y-%m-%dT%H:%M:%SZ'
sw_vers
xcodebuild -version
git -C "$GITHUB_WORKSPACE" status --short
ログを外部へ転送する前に、ワークスペースのパス、ユーザー名、署名関連情報などが運用上の取り扱い基準に合っているか確認します。ログが残ることと、ログから必要な事象を調査できることは別の検収項目です。
運用条件を決定表に当てはめる
選択は「一時か常駐か」だけで決まりません。ジョブの信頼度、ホストを清潔な状態に戻せるか、ツールチェーンの安定性、証跡の保存先、復旧の担当者を合わせて判断します。
| 判断軸 | 常駐Runnerを評価する条件 | 一時Runnerを評価する条件 |
|---|---|---|
| ジョブの信頼度 | 信頼できるコードに処理を限定できる | 外部コードや信頼度の異なる処理を扱う |
| ホスト清掃 | 再利用前の清掃と検証記録がある | ジョブ後に登録解除し、ホスト消去または再構築も行える |
| 資格情報 | 必要なジョブだけに権限を限定できる | 高権限の処理後に資格情報と実行環境を破棄できる |
| ツールチェーン | 固定された環境の維持を優先する | 基準状態からの再構築と検証が可能 |
| 監査・復旧 | Runnerとホストのログを継続して保管できる | ホスト削除後もログを参照でき、復旧担当が明確 |
実装の検収は、次の順で進めます。
- ワークフローの起動条件を一覧化し、信頼された変更、外部コード、署名・公開処理を分類します。
- 各ジョブのSecrets、
GITHUB_TOKEN権限、Keychain利用、社内ネットワークへの接続先を記録します。 - 常駐か一時かを選び、一時Runnerの場合は登録解除とホスト清掃・再構築を別の処理として設計します。
- Xcode、依存関係、ワークスペース、Simulatorの状態を記録し、想定した基準状態へ戻るか確認します。
- Runnerログと清掃結果を外部に保管し、ホスト削除後も失敗原因を調査できることを試します。
- 清掃に失敗した場合の隔離、再構築、ジョブ再実行の責任者を定め、手順を記録します。
一時Runnerを導入しても、ホストの清掃やログ保管の担当が決まっていなければ、隔離は完了していません。信頼できる定常ジョブに限り、権限と清掃記録を維持できることを条件として常駐方式を評価します。
よくある質問
一時Runnerと常駐Runnerは、運用上どこが違いますか？
一時Runnerはジョブ後にRunner登録を解除する構成にできます。常駐Runnerは同じホスト環境を次のジョブに使います。どちらを選んでも、ホスト上の作業領域や資格情報をどう扱うかは別途決める必要があります。
一時Mac Runnerのジョブ終了後、ホストの清掃も必要ですか？
ホストを再利用するなら、作業領域、テンポラリファイル、Keychain、キャッシュなどの残留を確認してください。登録解除の記録だけでは清掃の証拠になりません。清潔な状態に戻ったと検証できない場合は、再利用を止めて消去または再構築します。
自托管Mac Runnerでジョブ間の資格情報リスクを抑えるには？
各ジョブが参照できるSecretsとトークンの権限を確認し、署名用Keychainや社内ネットワークへのアクセスを必要な処理に限定します。終了後の失効・消去を記録し、後続ジョブが前の資格情報を参照できないことを確かめます。Runnerグループだけでホスト隔離が成立したとは判断しません。
企業のiOS CIでは、どの処理を一時Runnerに向けるべきですか？
外部コードを扱うジョブや、権限の大きい処理は一時Runnerを優先候補にします。署名・公開処理は保護ルールと限定した資格情報を組み合わせ、通常のビルドから分離してください。ホスト清掃とログ保管が実証できることも採用条件です。
Mac CIの運用責任を確認してから基盤を選ぶ
自社でMacを保有する方式は、ホスト構成を直接管理しやすい一方、調達、更新、監視、故障時の復旧を継続して担います。常駐Runnerとして使う場合は、さらに環境残留と資格情報の持ち越しを管理しなければなりません。
一時的な検証環境や必要台数が変動するチームでは、Macを購入して固定資産として運用する以外に、Macのレンタルも比較対象になります。ただし、レンタルでもジョブ間隔離やホスト清掃が自動的に保証されるわけではありません。利用前に、実機の引き渡し条件、アクセス方式、環境の清掃責任、ログ保管、障害時の担当範囲を確認してください。
Mac CIの実行環境を比較する際は、NodeMiniの案内とMac miniの注文案内で提供条件を確認し、必要な隔離・再構築要件を満たす場合に限って評価を進めます。信頼できる定常負荷を長期にわたって同じ構成で運用し、物理的な接続や専用設備が必要な場合は、自社保有のMacが適することもあります。