GitHubのセルフホストRunner APIは、Runnerのstatusとbusyを別々の項目として返します（Runner APIの項目）。つまり、Mac CIはホストがオンライン、またはRunnerがアイドルという表示だけで本番稼働可とは判断できません。Runner接続、タスク状態、ビルド結果と段階ログ、ホスト資源、アラート後の診断を同じノード・同じタスクに結び付けて受け入れてください。
企業IT担当者やプラットフォームエンジニアが、Macビルド機の本番監視と障害対応の基準を決めるための記事です。
Mac CIの可観測性を整え、監視の抜けを実際のパイプラインで確かめたい方に向けています。
01 監視対象と本番受け入れの境界
Macホストの稼働、Runnerの接続、タスクの成功、アプリの公開完了は別の状態です。監視画面が緑でも、Xcodeのテストが失敗していたり、成果物が欠けていたりすれば、リリース可能とは限りません。
まず、チームの実際のiOSパイプラインを受け入れ対象にします。コミットからビルド、テスト、署名、成果物の確認までを通し、各記録にノード名、Runner名、タスクID、実行時刻、コミットを残します。これらを照合できなければ、障害の影響範囲を追えません。
| 観測対象 | 確認する信号 | その信号だけでは分からないこと |
|---|---|---|
| Macホスト | 到達性、CPU、メモリ、空きディスク | Runnerがタスクを受け取れるか |
| Runner | オンライン状態、実行中かどうか、ラベル | ビルドやテストが成功したか |
| パイプライン | 待機、開始、成功、失敗、キャンセル | 失敗した工程の原因や成果物の内容 |
| 診断情報 | Runnerログ、タスクログ、Xcodeの結果 | 記録が対象ノード・タスクに正しく結び付くか |
02 Runner状態とタスクの振り分け
Runnerがオンラインなのにタスクが始まらない場合
オンライン表示だけでなく、実行中かどうか、Runnerに付いたラベル、ワークフローが要求するラベル、実際の割り当て先を照合します。GitHubの説明でもRunnerの接続状態とタスクの実行状態は区別されています（Runnerの状態とトラブルシューティング）。オンラインでも、要求ラベルとの不一致や割り当て経路の問題は別途確認が必要です。
| 表示・記録 | 調べる項目 | 次の確認 |
|---|---|---|
| オンライン、待機中 | ラベル、対象ワークフロー、割り当て先 | タスクが要求する実行環境との一致 |
| オンライン、実行中 | 対応するジョブとログ | 想定したノードで実行されているか |
| オフライン | Runnerの診断記録、ホスト到達性 | 再接続後にタスクを受け取れるか |
ワークフロー実行APIでは実行記録を確認でき、ジョブAPIでは個々のジョブの状態を追えます（ワークフロー実行API、ジョブAPI）。GitHub Actions self-hosted runnerの監視では、APIや画面の状態を、実行されたジョブの記録と突き合わせてください。
Runnerの状態は「実行環境が接続しているか」を示す信号です。ビルド成功や公開完了の証明として扱わないでください。
03 タスク結果と工程ログの追跡
企業のMacビルド機で確認するパイプライン状態
待機時間、開始、成功、失敗、キャンセルを、ビルドやテストなどの工程ログと同じ実行記録にまとめます。失敗率や所要時間に一律の閾値を当てず、チームの通常時の推移と、遅延や失敗が業務に与える影響から通知条件を決めます。
受け入れでは成功した実行と失敗した実行の記録を用意します。どちらも担当者が該当ジョブ、工程ログ、コミット、成果物またはテスト結果へたどれるかを確認してください。GitHubのワークフローログは実行の調査に利用できます（ワークフロー実行ログの確認方法）。
04 ホスト資源とXcode環境の観測
CPU、メモリ、ディスク空き容量、ネットワーク到達性に加え、Xcodeやビルドに必要な環境の状態を監視します。メトリクスを増やすだけでは障害を判断できません。実際のビルド失敗や遅延と照合し、原因の切り分けに役立った項目から通知条件を設定します。
| 指標 | 監視の目的 | 閾値の決め方 |
|---|---|---|
| CPU | 高負荷と処理停滞の把握 | 通常のビルド時の推移と実行時間を照合 |
| メモリ | メモリ圧迫の把握 | 使用量だけでなくメモリプレッシャーも確認 |
| ディスク | ログ、キャッシュ、成果物の保存余地 | ビルド後の増加量とクリーンアップ後の状態を記録 |
| ネットワーク | 制御面や必要な取得先への到達性 | 実行中の接続失敗と照合 |
| Xcode環境 | 想定するビルド・テスト環境の確認 | 実際のパイプラインで実行結果を検証 |
Appleのアクティビティモニタは、メモリ使用状況の確認方法とメモリプレッシャーを説明しています（メモリ使用状況の表示）。汎用の固定値を本番閾値にせず、チームの履歴や継続的なビルド記録で調整してください。
05 診断証拠とアラートの閉じ方
Xcodeビルド失敗と結果ログをひも付ける方法
Runnerの診断ログ、ジョブログ、Xcodeのテスト結果を、同じ実行IDやジョブIDから検索できるようにします。ログを保存していても、どのノードのどのタスクに属するか分からなければ、当番が復旧判断に使えません。GitHubはRunnerやジョブの診断情報を案内しており、Appleはxcodebuildのテスト結果を結果バンドルとして扱う方法を説明しています（Runnerの診断とトラブルシューティング、テストの実行と結果の解釈、Xcodeコマンドラインツール）。
受け入れ時は、記録に次の情報がそろうか確認します。
- [ ] ノード名、Runner名、タスクとジョブの識別情報が記録されている
- [ ] ビルド工程とテスト工程のログを、実行記録から開ける
- [ ] テスト結果バンドルを対象ジョブに対応付けられる
- [ ] ログの保存先と検索手順を、当番担当者が説明できる
アラートから復旧確認までの試験
監視を本番投入する前に、Runnerオフライン、タスク失敗、ディスク不足の警告、テスト結果の欠落を想定した確認を行います。各ケースで、通知先、最初に見る記録、担当者の切り分け手順、復旧後に確かめる証拠を定めてください。
| 判定 | 受け入れ条件 | 対応 |
|---|---|---|
| 合格 | 信号からノードとタスクを特定でき、ログと復旧確認まで追える | 本番運用へ進む |
| 条件付き | 追跡はできるが、通知先や記録の一部に不足がある | 不足箇所と修正期限を決めて再確認 |
| 保留 | アラートが届かない、またはタスクや診断情報を特定できない | 本番への拡大を止め、監視経路を修正 |
アラートが機能しても、バックアップ、障害復旧、公開承認の代わりにはなりません。それぞれの運用手順と責任者を別に定めてください。
06 受け入れ後のノード計画
既存のMacを社内で購入・運用する方法は、物理的な管理や周辺機器の接続が必要なチームに向いています。一方、購入費用が先に発生し、保守や交換、固定容量の管理も自社で担います。リモートMacのレンタルを比較するなら、監視要件に加え、利用期間や費用をチームの計画と照合してください。CALMVPSの料金情報を確認し、必要な期間やノード条件が合うかを検討できます。
増設を考えているなら、まず実際のパイプラインで監視の欠落を洗い出し、上記の受け入れ条件を満たすか確かめてください。試験用のMac CI環境を一時的に追加する選択肢として、CALMVPSの利用手続きも比較対象にできます。物理接続や長期の安定した重負荷が必須なら、自社保有との運用差を含めて判断してください。