GitHub Actions macOS-26かセルフホストMacか？2026 CI選定ガイド

GitHub公式のmacOS-26ランナー情報とイメージ一覧は、ラベル、プロセッサー構成、プリインストールソフトウェアを更新対象として公開しています。公式のランナー仕様とmacOS-26イメージ一覧を毎回確認できないチームは、すべてをホステッドランナーへ移すべきではありません。

結論は明確です。低頻度で標準化しやすく、長期キャッシュを必要としない処理はGitHub Actions macOS-26へ、固定したXcode、社内ネットワーク、接続デバイス、持続キャッシュ、高い並列性が必要な処理はセルフホストMacへ振り分けます。成長中のチームには、通常の検査をホステッドランナー、署名・公開・重いビルドを専用Macで処理する混合CIが最も現実的です。

現在macOS-26ランナーへ移行しているGitHub Actions利用者、ビルド待ち時間や依存関係のダウンロード、署名処理がリリースを遅らせているDevOpsチーム、ホステッドCIと専用Macノードを比較する技術責任者が対象です。
最終更新日：2026年8月24日。ランナー仕様はGitHubの公式ドキュメント、イメージ内容はrunner-imagesのmacOS-26定義を基準に確認しています。

先に判断するための指標

GitHub Actions macOS-26がiOSビルドに使えるかどうかは、ラベル名だけで決まりません。対象ジョブが必要とするXcode、CPUアーキテクチャー、署名方式、依存キャッシュ、接続先を同時に確認する必要があります。

コード解析、静的チェック、短い単体テスト
環境差分が少なく、毎回クリーンな状態でも成立するならホステッドランナーが適しています。マシンの保守を持たずにジョブを増減できるため、実行頻度が低いリポジトリでも管理負担を抑えられます。
固定Xcodeでの再現ビルド
Xcodeの版、追加コンポーネント、SDKの組み合わせを固定したい場合はセルフホストMacが有力です。Xcodeのシステム要件はリリースごとに対応macOSを示すため、ランナーのOS更新と同時に検証します。
署名とストア公開
証明書、秘密鍵、プロビジョニング情報を長期ノードへ置く設計には、アクセス制御と消去手順が不可欠です。署名専用のセルフホストMacへジョブを限定し、通常のテストジョブから秘密情報を見えなくする構成が適しています。
重いビルド、端末関連テスト、社内ネットワーク接続
Derived Dataを継続利用したい、実機や専用周辺機器を使う、社内サービスへ接続する場合は専用ノードの制御性が勝ります。
急な並列実行
実行数が時間帯で大きく変わる場合は、ホステッドランナーの弾力性とセルフホストMacの固定容量を組み合わせます。自前ノードだけでピークに合わせると、平常時に遊休資産が発生します。

macOS-26 runnerのバージョン管理と再現性

ホステッドランナーは、イメージ更新によって新しいソフトウェアや修正を取り込めます。一方で、macOS-26というラベルが同じでも、プリインストール済みのXcodeやツールの組み合わせが将来変わる可能性があります。ラベル、実行時のOS、Xcodeの実体をログへ保存し、変更を検出できるようにします。

GitHub ActionsでXcodeの版を固定する場合、ワークフロー上のラベル指定だけでは不十分です。イメージ一覧を確認したうえで、ジョブ開始時にxcodebuild -versionとsw_versを出力し、期待する値と異なれば早期失敗させます。必要な追加コンポーネントは、Xcode追加コンポーネントの導入手順に沿って明示的に準備します。

セルフホストMacでは、Xcodeのインストール先、選択中のDeveloper Directory、macOS更新タイミングを管理側で決められます。ただし、自由度が高いことは自動的な再現性を意味しません。OS更新、証明書更新、Homebrewなどの依存ツール更新を記録し、同じ構成を再構築できる手順書を用意する必要があります。

冷起動よりキャッシュの実測値を優先する

ビルド時間をCPUコア数だけで推測するのは危険です。依存関係の取得、Swift Package ManagerやCocoaPodsの解決、Derived Dataの再生成、アーカイブ保存、署名処理が連続するため、単純なマシン比較ではボトルネックを見誤ります。

ホステッドランナーではジョブごとに初期化されるため、キャッシュが使えない場合は依存関係のダウンロードが毎回発生します。GitHub公式の依存キャッシュ機能を利用する場合も、OS、Xcode、ロックファイル、アーキテクチャーをキャッシュキーへ反映しなければ、古い成果物や互換性のない依存物を再利用する危険があります。

セルフホストMacは、依存キャッシュやDerived Dataを保持しやすい点が利点です。しかし、複数ブランチが同じキャッシュを同時に書き換えると、再現性が崩れます。読み取り専用の共有キャッシュ、ジョブ単位の作業ディレクトリ、定期的な全消去を分けて設計します。

性能を比較する際は、同じコミットで次の値を記録します。

ランナー割り当てから処理開始までの待機時間
依存関係の取得時間とキャッシュヒットの有無
コンパイル、テスト、アーカイブ、署名それぞれの経過時間
キャッシュ容量、保存時間、復元失敗の回数
同時実行時のキュー長と失敗後の再試行結果

これらは環境ごとの実測値であり、公開仕様のコア数から算出してはいけません。比較用ワークフローを固定し、同一コミットを複数回流して分布を確認してから移行判断を行います。

署名、秘密鍵、社内ネットワーク接続は別のリスクとして扱う

ホステッドランナーは使い捨てに近い運用がしやすく、長期的な秘密情報をマシンへ残さずに済みます。その一方で、署名ジョブが外部実行環境へ秘密情報を渡す設計になる場合、ログ出力、プルリクエスト権限、サードパーティーアクションの扱いを厳しく制限しなければなりません。

セルフホストMacなら秘密鍵を専用ノードに限定できますが、ノードが常時稼働するほど攻撃対象の期間も長くなります。自ホストであること自体は安全性の証明になりません。GitHubの安全な利用指針に沿って、信頼できるブランチだけが署名ジョブを呼び出せる権限設計にします。

また、セルフホストランナーを公開リポジトリの無制限なジョブから受け入れる構成は避けます。セルフホストランナーのアクセス管理を確認し、ランナーグループ、リポジトリ範囲、ラベル、ジョブ終了後の作業領域消去、監査ログを設定します。

macOS托管ランナーと自ホストMacの安定性を分けて評価する

「安定している」の意味を、ジョブの成功率だけに限定しないことが重要です。ホステッドランナーはハードウェア障害やOSパッチの対応を自社で抱えにくい反面、イメージ変更による予期しない差分が発生します。セルフホストMacは環境を凍結できますが、ディスク容量不足、証明書期限切れ、OS更新失敗、単一ノード障害を自社で復旧しなければなりません。

したがって、次のように評価します。

再現性は、XcodeとSDKを固定できるかで判定します。
可用性は、ノード障害時に代替ランナーへ切り替えられるかで判定します。
安全性は、秘密情報と通常テストを分離できるかで判定します。
拡張性は、ピーク時の同時ジョブを増やせるかで判定します。
運用費は、ランナー利用料だけでなく、監視、パッチ、待機ノード、障害対応時間まで含めて算出します。

費用は、ホステッド側では実行時間、ランナー種別、ストレージやキャッシュ関連の利用量、自ホスト側ではMacのレンタルまたは購入費、稼働時間、保守、バックアップ、予備機の費用を変数にした式で比較します。リアルタイム価格を確認できない状態で、月額や分単価を断定するべきではありません。専用ノードの料金条件を比較する場合は、Mac VPSの料金案内で契約期間や利用形態を確認し、GitHub Actionsの実行時間だけでは見えない監視・保守費も加えて評価します。

混合CIへ移すための実行手順

第一歩：ジョブを役割で分類する

ワークフローを、コード検査、通常の単体テスト、重いビルド、署名、公開、実機テストに分けます。処理時間ではなく、固定環境、秘密情報、社内ネットワーク接続、デバイス接続の有無を分類軸にします。

第二歩：ランナーの実体をログへ残す

macOSの版、プロセッサーアーキテクチャー、Xcodeの版、SDK、主要依存ツールをジョブ冒頭で出力します。macOS-26 runnerのラベルと実際の環境が一致しているか、イメージ更新後も確認できる状態にします。

第三歩：ホステッドランナーで基準結果を作る

同一コミットを使い、キャッシュなしとキャッシュありの両方を記録します。単発の最短値ではなく、キュー待機、依存取得、コンパイル、テスト、アーカイブを分けて保存すると、自ホスト化すべき工程が見えます。

第四歩：専用Macの境界を狭く設定する

最初から全ジョブを移さず、署名、実機関連、社内ネットワーク接続、重いアーカイブだけに専用ラベルを付けます。証明書を置くノードと、秘密情報を扱わないビルドノードを分けられるなら、さらに権限範囲を縮小できます。

第五歩：同じコミットで成果物を照合する

ホステッドと自ホストで同じコミットを実行し、テスト結果、警告、アーカイブ、署名状態、生成されたメタデータを比較します。バイナリが完全一致しない場合は、Xcode、SDK、依存物、ビルド時刻、署名設定の差分を調査します。

第六歩：障害時の回退を検証する

専用Macを停止した状態で、署名を伴わない通常テストがホステッドランナーへ戻るか確認します。逆に、macOS-26のイメージ更新でテストが失敗した場合、固定済みの自ホスト環境で原因切り分けできるようにします。

第七歩：容量と更新の責任者を決める

キュー長、失敗率、キャッシュ復元率、ディスク使用量、証明書の有効期限を監視対象にします。ノード追加の条件と、Xcode・macOS更新を本番へ反映する承認手順を先に定義します。

移行前に実行する検収チェック

[ ] macOS-26ラベル、実OS、アーキテクチャーをログで照合した
[ ] Xcodeの版と追加コンポーネントを固定し、要件ページと照合した
[ ] 同一コミットでホステッドと自ホストの工程別時間を取得した
[ ] キャッシュキーへロックファイル、OS、Xcode、アーキテクチャーを反映した
[ ] 署名ジョブを信頼済みブランチと専用ランナーへ限定した
[ ] ジョブ終了後に作業領域、ログ、署名関連の一時ファイルを消去した
[ ] セルフホストMac停止時の回退先と担当者を決めた
[ ] XcodeまたはmacOS更新後に同じ検収を再実施する日程を登録した

このチェックで失敗する項目が残るなら、移行範囲を広げる時期ではありません。まず通常テストだけをGitHub Actions macOS-26へ置き、署名と重いビルドは制御可能なノードに残す方が、原因の切り分けと回復を行いやすくなります。

Macノードの必要台数やキュー設計を詰める段階では、iOS CI向けのMacレンタル環境を候補に含め、購入、クラウド実行、専用レンタルの保守範囲を分けて比較します。Xcodeの版を固定する運用や、セルフホスト環境の権限分離については、既存の手順書へ反映できる粒度で整理する必要があります。

ホステッドランナーだけで運用すると、イメージ更新、長い依存ダウンロード、署名や社内ネットワーク接続の制約が残ります。自社購入のMacだけに寄せると、ピーク時の待機ノード、障害時の単一障害点、パッチと証明書管理が重くなります。部分的に固定環境が必要なチームなら、ZilmacのMac環境を専用ノード候補として検証し、普通の検査はホステッドへ残す構成の方が、全面移行よりも失敗時の影響を抑えやすいです。