GitHub Actions macOS Runnerはホステッドかセルフホステッドか？2026年のセキュリティとコスト比較

GitHubの説明では、ホステッドRunnerの各ジョブは新しい仮想マシンで実行され、ジョブ終了後にその環境は破棄されます。ホステッドRunnerの実行環境を前提にすると、外部コードを実行する可能性があるなら、まずホステッドを候補にしてください。自托管Mac Runnerは、内網への接続や独自ソフトウェアが必要で、隔離・更新・清掃を継続して管理できる場合に絞るのが安全です。

今週は、対象ワークフローを「信頼済みの社内変更」と「外部からの変更」に分け、署名鍵を使うジョブの権限と実行環境を確認してください。費用の比較では、マシン代だけでなく保守とセキュリティ対応も計上します。

iOS・macOS開発チーム：ビルド、テスト、署名に使うRunnerの選定が必要な方。
プラットフォームエンジニア：Mac実行ノードを継続して管理するか判断する方。
セキュリティ担当者：Pull Requestの実行範囲、署名資格情報、Runner権限を評価する方。

信頼境界から候補を絞る

まず、ワークフローが実行するコードを分類します。保護されたブランチからの社内ビルドと、未レビューの外部Pull Requestは同じ信頼度では扱えません。外部コードのテストが必要なら、チェックアウトするコードだけでなく、ワークフロー定義や呼び出すアクションも確認対象にします。

GitHubは、自托管Runnerがワークフローの実行後も環境を保持し得ることや、Runnerにアクセスできる範囲を慎重に管理する必要性を説明しています。自托管Runnerの管理と特性を読み、外部コードが同じマシン上で後続ジョブに影響できない構成かを確かめてください。単にRunnerを社内ネットワーク内に置くことは、隔離の代わりにはなりません。

外部Pull Requestを自托管macOS Runnerで動かすことは、安全性を自動的に保証する選択ではありません。未信頼のコードにRunnerのファイル、キャッシュ、ネットワーク到達範囲、残存資格情報を触られる可能性があります。隔離を説明できない場合は、外部コード用ワークフローをホステッド環境へ分けるか、自托管環境では実行しない設計にします。

指標ごとに方式を比較する

次の評価は、一般的な実行条件を比較するための目安です。高・中・低は性能測定値ではなく、各チームが要件を照合するための評価です。GitHubのイメージ、提供範囲、課金条件は変更されるため、採用時には現行のホステッドRunner仕様を確認してください。

この表から選ぶときは、まず分離と信頼性を優先し、その後にカスタマイズ性を評価します。自托管が必要な理由が「特定のXcode環境」「内網上の依存先」「独自のビルドツール」のどれかを具体化できないなら、管理責任を増やす前にホステッドRunnerで要件を満たせるか試してください。

署名鍵とワークフロー権限を分離する

Appleの署名に使う証明書や秘密鍵は、ソースコードと同じ場所に置かず、対象リポジトリや環境に必要な範囲だけ渡します。GitHubの環境機能では、承認や保護ルールとシークレットの利用条件を設定できます。環境とシークレットの保護機能を使い、署名ジョブを通常のテストジョブから分けてください。

さらに、ワークフローのpermissionsを明示し、必要な権限だけを許可します。ワークフロー構文の権限設定では、権限を読み取り、書き込み、または無効にする形で個別に設定できます。権限を省略したまま広いアクセスが残る構成を避け、トークンが必要な処理と署名鍵を扱う処理を同じジョブに詰め込まないことが重要です。

pull_request_targetは、外部コードを扱うときに特別な注意が必要です。特権を持つ基底ブランチ側のコンテキストで実行されるため、未信頼コードを不用意にチェックアウトして実行すれば、資格情報や書き込み権限を危険にさらします。pull_request_targetの安全な利用方法を確認し、必要性を説明できない場合は別のトリガー方式を選んでください。

ソフトウェア制御と保守責任を見積もる

ホステッドRunnerが適するかは、必要なXcode、macOSイメージ、依存ツールが現在の提供内容に含まれるかで判断します。イメージ名だけで長期利用を決めず、定期的にワークフローを動かし、イメージ更新後にビルドと署名が再現できることを確かめます。利用できるイメージや付属ソフトは変わるため、固定仕様として扱わないでください。

自托管は環境を細かく制御しやすい一方で、OSとRunnerアプリの更新、依存ソフトの脆弱性対応、ジョブ失敗後の復旧、ログ確認、ストレージ消去を自分で引き受けます。内網につなぐ場合は、Runnerが到達できる範囲をビルドに必要な宛先へ限定し、個人端末や本番環境と同じネットワーク権限を与えないでください。

GitHub Actionsの安全な利用に関する公式ガイドは、未信頼の入力、シークレット、サードパーティーアクション、権限設定を含むリスクを扱っています。GitHub Actionsのセキュリティ指針を基準に、Runnerだけでなくワークフロー全体を点検してください。Runnerを自社で管理していても、ワークフローの権限やシークレットの扱いが不適切なら安全性は高まりません。

総コストは運用時間まで含めて算出する

自托管Mac Runnerの費用は、マシンの購入・レンタル費だけでは決まりません。比較には、電力や保管などの設備費、OSとRunnerの更新、監視、障害対応、イメージ再作成、アクセス制御のレビューにかかる工数を含めます。実際の請求書や作業記録がない状態で、金額を推測して結論を出すのは避けてください。

計算式は、次のように置けます。

自托管の総コスト ＝ 実際の設備・利用費 ＋ 更新・監視・障害対応の人件費 ＋ セキュリティ対策費 ＋ 停止時の復旧コスト

ホステッド側も、対象プランの無料枠や課金単位、macOSジョブに適用される料金条件を確認してから比較します。GitHub Actions Runnerの課金説明を参照し、実際の利用量と契約条件を式に当てはめてください。自托管が安いかどうかは、専用ノードの稼働率だけでは判断できません。管理に費やす時間と、障害時にビルドを止める影響も記録します。

導入前に隔離・鍵・清掃を実地確認する

次の項目を満たせない場合は、自托管Runnerを本番ワークフローへ追加せず、設計を見直してください。

• [ ] 外部Pull Requestと信頼済みブランチのジョブを、実行環境または権限で分離した。
• [ ] 外部コードが署名鍵、トークン、内網上の機密リソースにアクセスできないことを確認した。
• [ ] ワークフローのpermissionsを明示し、各ジョブに必要な権限だけを設定した。
• [ ] ジョブ終了後のワークスペース、キャッシュ、一時ファイル、資格情報の処理を実行して確認した。
• [ ] Runner更新、macOS更新、障害復旧の担当者と手順を決めた。
• [ ] ホステッドと自托管の費用に、実際の課金条件と運用工数を反映した。
• [ ] 署名ジョブと通常のテストジョブを分け、シークレットを使う条件を確認した。

清掃の確認では、ジョブの終了後に次のジョブが以前のファイルや資格情報を読み取れないことを試します。運用手順の確認には、自托管Mac Runnerの設置と清掃について相談し、ネットワーク範囲や運用責任を事前に整理する方法もあります。

チームの条件に合わせて方式を決める

小規模なチーム、未信頼コードを実行するプロジェクト、Macノードを継続保守する担当者がいない組織では、まずホステッドRunnerを評価してください。ジョブごとに新しい実行環境を使える点は、前ジョブの残留物を引き継がない設計に役立ちます。ただし、シークレット管理やワークフロー権限の点検は別途必要です。

内網アクセス、独自依存ソフト、固定した実行環境が欠かせず、更新・隔離・清掃を担当できるチームなら、自托管を候補にできます。採用前に上のチェック項目を実機で検証し、未信頼コードからの分離を説明できない場合はホステッドへ戻してください。

「現在の構成」は、Runner基盤を社内で持つ場合、保守要員の確保、OSや依存ソフトの更新、ジョブ後の清掃を継続する負担があります。専用ノードの稼働が一時的なら、設備を保有しても利用しない時間のコストが残ります。反対に、物理デバイス接続や長期の安定した高負荷が欠かせないなら、レンタルが常に適するとは限りません。

一時的なApple開発環境や専用Mac Runnerを評価する段階なら、VPSSparkの日本向けMac利用プランも比較対象に加え、必要期間、ネットワーク要件、運用分担を照らし合わせてください。GitHub Actions macOS Runnerの選定は、最安の実行単価ではなく、信頼境界を守りながらチームが維持できる方式を選ぶことが基準です。