社内レジストリやAPIにCIから届かず、ビルドが止まっていますか。
GitHub Actions macOS larger runnersで企業内ネットワークへの直接接続や静的IPが必要なら、採用を前提にせず、制約を確認してから自管Macか検証済みの中継方式を選んでください。

この記事は、企業ネットワークの接続方針を決めるIT担当者、iOS/macOS CIを設計するプラットフォームエンジニア、CIの安全性と調達を判断する責任者向けです。

静的IPを必須にするファイアウォール

送信元IPの許可リストが必須なら、まずrunnerのアドレス特性を確認します。GitHubの公式資料では、macOS larger runnersは静的IPとAzure private networkingを提供していません。LinuxやWindows向けに記載されたネットワーク機能を、macOSにもあるものとして設計しないでください。macOS larger runnersのネットワーク制限で、採用するrunnerの条件を照合します。

  • 利点: 管理対象のMacを自社ネットワーク側に置けば、ネットワーク設計を自社の制御範囲で検討できます。
  • 注意点: 自管Macに切り替えても、許可リスト登録、ルーティング、認証は別途必要です。runner登録と社内アクセス権は同じではありません。

ファイアウォールが固定IPを求めているのか、認証済みのAPI経由で代替できるのかも切り分けます。固定IPが変更不可の要件なら、静的IPを使えるという未確認の前提で進めず、自管Macなど別の経路を検証します。

公開依存だけで完結するビルド

社内ネットワークへの接続が不要なら、ホステッドmacOS runnerを候補にできます。ただし、「ホステッドだから自社のすべてのビルドに適する」とは判断できません。ソースコードの取得先、依存パッケージ、ビルドサービスが、runnerから実際に利用可能かを確認します。

次の違いを混同しないでください。

  • 公開URLでも、アカウントやトークンによる認証が必要な場合があります。
  • 組織の権限で閲覧できるリポジトリでも、runnerが必要な資格情報を持たなければ取得できません。
  • ビルド後の成果物アップロード先や署名サービスが社内限定なら、ビルド工程だけ公開ネットワークで動いても全体は完結しません。

依存関係一覧、実際のworkflow設定、成功・失敗時のビルドログを照合してください。公開リソースだけで完結することを確認できたタスクに限り、ホステッドrunnerを優先候補にします。

GitHub Actions macOS larger runnersの企業内ネットワーク接続

私有パッケージレジストリ、社内アーティファクト保管庫、秘密情報サービス、内部APIのどれが必要かを列挙し、CIから接続先までの経路を描きます。入口と出口の向き、認証方式、必要なサービスを分けて書くと、単に「社内ネットワークにつなぐ」という曖昧な要件を避けられます。

大きなrunnerのアクセス制御とネットワーク設定は、larger runnersのアクセス制御資料および管理手順で確認します。macOSに適用される機能かどうかを、記載対象まで読んで判断してください。

注意：管理画面でrunnerを選択できることは、社内サービスへの到達性を示しません。実行ログだけでなく、接続先のアクセスログでも成功と認証主体を確認します。

中継方式を使って接続する構成

直接接続が使えない場合、OIDC認証を使うAPIゲートウェイやネットワークオーバーレイを候補にできます。ただし、選択肢として記載されていることと、対象のmacOS runnerで利用できることは別です。

実装前に、接続先、資格情報の範囲、出口経路、監査ログをセキュリティ担当者と確認します。対象macOS runnerで確認できていない方式は「利用可能」ではなく「要検証」として扱ってください。

自管Macを社内ネットワーク側に置く構成

自管Macは、必要なネットワーク経路を作れるかどうかがホストの設置場所と企業の接続ポリシーに左右されます。GitHubの自管runnerに関する通信要件を確認し、runnerからGitHubへの通信と、社内サービスへの通信を別々に検証します。

ここでいう自管Mac Runnerは、ネットワーク経路を構成できる可能性を意味するだけです。ホストの隔離や、登録したジョブの安全性を保証するものではありません。保守、OS更新、資格情報の保護、不審なworkflowを実行させない仕組みを運用責任に含めます。

Macを購入する場合とレンタルする場合も、ネットワーク接続の要件を先に定義してください。機材の調達先だけでは、社内経路やセキュリティ境界は決まりません。必要な設置場所や保守分担を詰める際は、Macの調達方法と対象地域も確認できます。

タスクを分ける混合構成

公開リソースだけで動くコンパイルやテストと、社内サービスへの接続が必要な工程は、別のrunnerに分ける方法があります。工程を分割する場合は、タスクの受け渡しだけでなく、成果物、実行主体、署名・公開権限の境界を決めます。

受入チェックリスト

  • [ ] workflowから必要な依存先、リポジトリ、サービスへの接続先を列挙した。
  • [ ] 各接続について、認証主体、必要なポート、許可リストの要否を記録した。
  • [ ] macOS runnerに機能が適用されることを公式資料で確認した。未確認の中継方式は要検証として残した。
  • [ ] 実際のworkflowで接続、認証、成果物の受け渡し、署名工程を実行した。
  • [ ] runnerログと接続先ログの両方で結果を確認し、必要な監査記録を保存した。
  • [ ] 自管Macを使う場合、保守担当、資格情報管理、実行するworkflowの信頼条件を決めた。
  • [ ] 満たしていないネットワーク要件と、ホステッド・自管それぞれの運用責任を記録した。

よくある確認事項

macOS larger runnersから社内のプライベートなパッケージレジストリを使えるか

runnerからそのレジストリへの到達経路と認証が必要です。公式資料で対象runnerへの適用を確認し、ワークフローの実行と接続先ログの両方で疎通を立証します。

macOS larger runnersで静的IPの許可リストを使えるか

公式資料上、macOS larger runnersは静的IPに対応していません。固定アドレスが必須なら、自管Macまたは要件を満たす別経路を検討します。

社内依存が必須のiOS CIでは何を選ぶか

必要な経路を構成できる自管Macが候補ですが、設置場所、ネットワーク設定、認証を実ワークフローで検証します。ホステッドrunnerを選ぶのは、公開依存で完結するか、中継方式が対象環境で実証できた場合です。

ゲートウェイやネットワークオーバーレイで接続できるか

方式の一般説明だけでは判断できません。接続先、認証、出口経路、ログを確認し、対象macOS runnerで実行してから採用します。

ホステッドrunnerは、ホストの保守負担を抑えやすい一方、静的IPや社内ネットワークへの直接接続を前提にできません。自管Macは経路を組み立てやすい一方、ホスト保守、認証情報の管理、workflowの安全性を自社で担います。接続要件が満たせない状態で本番CIを載せるより、実際のworkflowとネットワークログで適合性を確かめてください。

必要な経路を持つMac環境を一時的に検証したい場合は、MACCOMEのサービス案内で利用条件を確認し、対象ネットワークへの接続が保証されていると仮定せず、実環境の要件と照合してください。購入・自社運用が適するケースもあるため、保守責任や物理接続の要否を含めて比較してから判断します。