GitHub Actions セルフホスト型 Mac Runner のデプロイ方法？2026

症状：ワークフローにmacOSが必要なのに、出先から使えるMac環境がありません。
最短の解決策：Macを継続してオンラインにできるなら、管理できるリポジトリでGitHub Actionsのセルフホスト型Mac Runnerを登録し、サービス起動とジョブ完了まで検証します。

この方法は、XcodeなどMac上のツールやmacOS固有の処理がワークフローに必要な場合に適しています。自托管Runnerはジョブを実行するホストの管理も利用者が担うため、外部の未信頼コードを処理する用途にはそのまま使わないでください。

独立系iOS／macOS開発者には、Macが必要なビルドを実行する方法を示します。
顧客案件を扱うフリーランスには、継続利用できるビルド環境の準備と検証手順が役立ちます。
小規模なリモートチームには、Runnerの保守責任とリポジトリの権限境界を判断する材料になります。

まずmacOSが本当に必要か判断します

すべてのGitHub ActionsジョブにMac Runnerが必要なわけではありません。OSに依存しない処理までMacに集約すると、稼働状態やソフトウェア更新を管理する負担が増えます。macOS CIビルドやMac固有のツールを使うジョブだけを切り分けましょう。

選択肢	向いているジョブ	管理する範囲	判断の目安
GitHubホストRunner	OSに依存しない処理や、GitHubが用意する実行環境で足りる処理	自分で用意するMacの稼働管理は不要	macOS固有の環境やツールが必須でなければ、まずこちらを検討
自托管Mac Runner	macOS上のツール、独自の依存関係、管理対象のMac環境が必要な処理	Mac本体、Runnerアプリ、OSやツールの保守	Macを継続稼働させ、ジョブを実行する利用者を管理できる場合

GitHubは自托管Runnerを利用者が管理する実行環境として説明し、ホストやソフトウェアの管理も利用者側の責任としています。管理責任の境界は、GitHubの自托管Runnerに関する説明で確認できます。

登録範囲	適するケース	登録前に確認すること
リポジトリ単位	特定のプロジェクトでのみ利用したい	そのリポジトリでRunnerを登録できる権限があるか
組織単位	組織内の複数リポジトリから使いたい	どのリポジトリにRunnerを利用させるか

登録可能な範囲や設定画面は、利用者の権限とGitHub側の構成によって異なります。GitHubのRunner追加手順で対象範囲を選び、その画面が示す登録指示に進みます。

登録前にMacと権限を整えます

Runnerを追加してから作業環境の不足に気づくと、登録し直しや依存関係の入れ直しが発生します。先にMacへログインできること、プロジェクトの配置場所、必要な開発ツールを確認してください。

確認項目	事前に行うこと	確認できない場合
GitHubの権限	リポジトリまたは組織のRunner設定を管理できるか確認	管理者に登録範囲と操作権限を確認
macOSとCPUアーキテクチャ	GitHubの画面で表示される対応OS・アーキテクチャをMacと照合	画面の条件に合うホストを用意するまで登録を保留
プロジェクト環境	作業ディレクトリ、依存関係、署名など必要なツールを洗い出す	まずローカルで再現手順を整理
ネットワークと電源	RunnerがGitHubへ接続し続けられる運用か確認	接続が途切れる場所やスリープ設定を見直す
ワークフローの利用者	誰がジョブを起動でき、どの秘密情報に触れるか確認	権限を限定するまで秘密情報を登録しない

対応するOSやアーキテクチャは固定の思い込みで決めず、GitHubの自托管Runner要件と登録画面の表示を照合してください。RunnerはGitHubに接続できる必要があります。旅行先のネットワーク切り替え、Macのスリープ、停電などでホストが利用できない場合、ジョブを受け取れない時間が生じます。

GitHub ActionsにMac Runnerを登録します

GitHub Actionsのセルフホスト型Runnerを追加するには、対象リポジトリまたは組織の設定からmacOSと該当アーキテクチャを選び、画面に表示される指示に従います。操作時に生成される登録トークンやコマンドは、その時点の画面を正として扱ってください。

管理権限のあるリポジトリまたは組織を開き、Runnerの設定画面へ進みます。
Runnerの追加を選択し、macOSと実機に合うアーキテクチャを指定します。
画面に表示された手順をMac上で実行し、Runnerアプリをダウンロードして登録します。
一時的に発行される登録用トークンを使います。トークンや登録コマンドを公開リポジトリ、ログ、共有文書へ貼り付けないでください。
登録後、GitHubのRunner一覧で対象ホストが表示され、オンライン状態になっていることを確認します。

セットアップ手順はGitHubの画面から実行時に取得してください。古いコマンドや別の登録範囲向けの指示を流用すると、誤ったRunnerへ登録したり、トークンを露出したりするおそれがあります。

注意：登録用トークンは画面の手順に従って取り扱い、作業後にシェル履歴や共有ログへ残っていないか確認します。トークンをワークフローファイルに保存する運用は避けてください。

ターミナルを閉じてもジョブを受け取れる状態にします

前面で起動したRunnerは、ターミナル終了後も動きますか？

前面で起動したプロセスは、そのプロセスを終了すればジョブを受け取れません。旅行中に毎回ターミナルから手動起動する運用では、ログアウトや端末の再起動で停止しやすくなります。

GitHubはmacOSでRunnerアプリをサービスとして設定する手順を案内しています。GitHubのmacOSでサービスを設定する手順に従い、設定、起動、状態確認を行ってください。サービス設定用のコマンドはRunnerを登録したディレクトリやアプリの状態に応じて異なるため、公式手順にあるコマンドをそのまま確認して実行します。

Macの起動時にRunnerを自動起動させるには？

サービスとして構成したうえで、Macを再起動し、Runnerがオンラインに戻るかを確認します。登録直後にオンラインと表示されたことだけでは、再起動後もジョブを受け取れる証明になりません。

確認手順は次のとおりです。

GitHubの指示に従ってRunnerをサービスとして設定します。
サービスの起動と状態確認を行います。
Macを再起動し、ログイン後に手動でRunnerを起動せずに待ちます。
GitHubのRunner一覧でオンライン状態に戻ったことを確認します。
テスト用ワークフローを実行し、ジョブが完了することを確かめます。

設定後に状態が不明な場合は、GitHubのRunner監視とトラブルシューティングを参照し、サービス状態やRunnerログを確認してください。スリープ設定やネットワークの切断も、サービス起動とは別に調べる必要があります。

ラベルを指定してワークフローを検証します

GitHubの自托管Runnerには、self-hosted、OS、アーキテクチャを示す既定ラベルが付与されます。Runnerごとに実際のラベルを確認し、ワークフローのruns-onに一致する条件を指定してください。ラベルによる割り当ての詳細は、GitHubのラベル設定ガイドで確認できます。

name: macOS runner check

on:
  workflow_dispatch:

jobs:
  verify:
    runs-on: [self-hosted, macOS, ARM64]
    steps:
      - name: Check host
        run: |
          uname -s
          uname -m
          sw_vers

この例では、ARM64のラベルが付いたRunnerを指定しています。実機が別のアーキテクチャなら、登録画面とRunner一覧で確認したラベルに置き換えてください。Runnerの既定ラベルは環境に応じて確認し、例の条件を全ホストにそのまま適用しないことが大切です。

最初は、手元のコードを変更しない低リスクの確認ジョブを実行します。GitHub上でジョブが該当Runnerに割り当てられたこと、ログを確認できること、処理結果を受け取れることを見届けます。その後、実際のプロジェクトで使うツールを呼び出し、依存関係や署名などを含めたエンドツーエンドの確認を行います。

自托管Runnerは一度に1つのジョブを処理する構成として説明されています。並行するジョブが待機するなら、同時実行数を前提にせず、待ち時間が許容できるか、Runnerを追加する必要があるかを見直します。この動作条件はGitHubの自托管Runner要件で確認できます。

公開Pull Requestを扱う前に安全境界を確認します

公開リポジトリの外部Pull Requestを実行できますか？

設定上、公開リポジトリのワークフローを自托管Runnerで動かせる場合でも、外部からの未信頼コードを永続利用するMacで実行するのは避けてください。ジョブのコードがホスト上のファイルや、アクセス可能な秘密情報に影響を及ぼす可能性があります。

GitHubも、自托管Runnerの環境に作業の痕跡が残る可能性や、未信頼ワークフローがホストを危険にさらすリスクを説明しています。GitHubのActions安全利用ガイドを確認し、ワークフローを実行できる利用者、秘密情報へのアクセス、Runnerの再利用方法を決めてください。

とくに、次の条件が整わない場合は、外部コントリビューターのジョブを永続的なMac Runnerへ割り当てないでください。

どの利用者がワークフローを起動できるか把握できていない。
ジョブから参照できる秘密情報を最小限にできていない。
ジョブ終了後に作業ファイルや生成物を確認・削除する手順がない。
Runnerを再起動または再設定して、汚染の疑いがある環境を切り離せない。

初回ジョブが成功しても、すべてのプロジェクトや外部コードに安全・互換であるとは限りません。macOS CI構築に使うツール、必要なアクセス権、ジョブの実行元を個別に検証し、条件が変わったときは再確認します。

今の運用を続けるか、遠隔Macへ移すか決めます

手元のMacをRunnerとして使う方法は、追加のホストを用意せずに始められる一方、持ち歩き中の紛失や故障、スリープ、現地ネットワークの切り替えが稼働に影響します。自宅やオフィスのMacを常時起動する場合も、電源やネットワーク、OS更新、障害時の復旧を自分で管理しなければなりません。

遠隔Macは、移動中に開発用の実機を持ち歩かずに済む選択肢です。ただし、接続経路、利用できるmacOS環境、権限、利用期間が実際のワークフローに合うかは契約前に確認が必要です。Runnerの登録自体が成功しても、必要な開発ツールや秘密情報の運用まで自動的に解決するわけではありません。

遠隔で使うMacを検討する場合は、遠隔Macの利用条件を比較するページで環境と利用条件を確認し、利用可能な拠点も接続先選びの材料にしてください。現在のMacがスリープや移動時の故障、ネットワーク変化で止まりやすく、かつワークフローの検証が済んでいるなら、OnceMacのレンタル環境を候補に加える価値があります。反対に、物理ポートへの接続が必要な場合や、ホストを長期にわたって安定稼働させる要件がある場合は、実機の自前管理が適することもあります。利用条件が判断できない場合は、OnceMacへの問い合わせで確認してから決めてください。