Appleは企業ネットワーク向けに、Appleサービスごとに確認すべきホストとポートを案内しています。企業ネットワーク向けの公式要件がサービス単位で整理されていることからも、「*.apple.comをすべて許可する」設計は採用せず、ソースコード、依存関係、Xcodeコンポーネント、署名・公開、通知・管理サービスごとに許可範囲を分けるべきです。2026年9月21日時点では、Xcode 27 CI ネットワーク許可リストを実際のパイプラインで検証し、通常の構築ノードと本番署名ノードを別の出力ポリシーにすることを今週の作業にしてください。
対象読者
企業のネットワーク・セキュリティ担当者は、Mac CIの最小限の外向き通信と変更審査の根拠を作るために読んでください。プラットフォーム担当者は、Xcode 27、Apple Silicon、CI Runnerの接続条件を受け入れる際に利用できます。
調達・インフラ担当者は、レンタルMacや自社管理Macのネットワーク提供能力を、宣伝文句ではなく検証記録で比較したい場合に対象となります。
最終更新：2026年9月21日。 Xcode 27の状態と対応条件はAppleのXcode 27リリースノート、Appleサービスの通信要件はApple公式文書を基準に確認してください。Apple側のエンドポイント、正式版の状態、企業プロキシの方針が変わった場合は、許可リストを再審査します。
SECTION 01 失敗箇所を分ける六つの通信区間
Xcode 27のCIは、単にMacホストでWebサイトを開けるだけでは成立しません。ソース取得、依存関係解決、ツールチェーン取得、署名認証、成果物の公開、結果通知という異なる通信が、別々の実行アカウントと認証情報で発生するためです。
まず、1本のパイプラインを次の区間に分けて記録します。これは許可リストのルール番号、失敗ログ、担当者を結びつけるための基礎になります。
- ソースコード取得：Gitリポジトリ、Git LFS、サブモジュール、社内コードホスティングへの接続。
- 依存関係解決：Swift Package、CocoaPods、私有パッケージレジストリ、Gitベースの依存先への接続。
- ツールチェーン取得：Xcodeコンポーネント、シミュレーターランタイム、追加SDKなどの取得。Xcode追加コンポーネントの公式説明に記載された手順と、実際に使うノードの要求を照合します。
- 署名と認証：Apple Developer関連の認証、証明書、Provisioning Profile、Keychain処理。
- アップロードと公開：App Store Connect、TestFlight、アプリ配布、macOS公証への送信。
- 結果の通知と管理：CIサーバーへの結果返却、ログ保存、Runner管理、監視通知。
ホストは接続できるのにCIだけ失敗する場合
管理者のターミナルで成功しても、CIサービスアカウントでは失敗することがあります。実行ユーザーのホームディレクトリ、SSH鍵、Keychain、プロキシ環境変数、内部CA、DNS設定が異なるためです。
「ホスト名が解決できた」という記録だけでは不十分です。対象サービスごとに、DNS解決、TCP接続、TLSハンドシェイク、認証・認可、業務リクエスト、完全なパイプライン結果を記録してください。pingやブラウザー表示だけで合格にすると、認証後のAPI呼び出しや成果物送信の失敗を見逃します。
SECTION 02 Xcode 27 CI ネットワーク許可リストの設計
Xcode 27構築機に必要な接続先の分け方
Appleのホスト要件をそのまま全ノードへ配布するのではなく、次のように目的別のルールへ分割します。宛先は固定文字列で管理できるもの、Apple公式文書を参照して更新するもの、企業内で管理するものを区別してください。
- ソース用ルール：企業Git、外部Git、Git LFS、サブモジュール。通常のPR構築では読み取り専用を基本にします。
- 依存関係用ルール：Swift Package、CocoaPods、私有制品庫、社内プロキシ。依存ファイルのロックとハッシュを確認し、キャッシュが空の状態でも取得できるか確認します。
- Appleツール用ルール：Xcode 27の追加コンポーネント、シミュレーターランタイム、開発者向けサービス。Xcode 27の対応OSやApple Silicon条件は、公式リリースノートに明記された内容だけを採用します。
- 公開用ルール：App Store Connect、TestFlight、公証など、成果物を外部へ送信する経路。PRノードでは原則として不要にします。
- 管理・通知用ルール：CI管理サーバー、ログ保存先、監視基盤、Runnerの登録・更新経路。
Mac CIの外向き通信を設計するときは、ドメイン名だけでなく、用途、実行アカウント、許可する操作、プロキシ経由の有無、失敗時の証拠場所を1つの変更申請にまとめます。AppleのTCP・UDP要件は、Appleソフトウェア製品の公式ポート資料で確認し、企業独自のGitや制品庫の情報と混在させないでください。
自托管Runnerの経路固定
自社管理のRunnerを使う場合は、ノードのラベル、Runner Group、サブネット、出力ゲートウェイを一緒に管理します。GitHub Actionsの自托管Runner資料が示すように、Runnerは企業側の環境で管理されるため、CIサービスの表示上は同じ種類でも、実際のDNSやプロキシ経路が異なる場合があります。
ラベルは「xcode27」「signing」「private-deps」のように、ツールチェーンと信頼境界を表す属性へ分けます。Runnerラベルの公式説明を参考に、私有依存関係へ到達できないノードへ署名ジョブが誤配分されないようにしてください。
SECTION 03 署名ノードとプロキシの分離
企業の署名・公開ノードに必要な範囲
通常のPR構築、アーカイブ、署名、公開、公証は、同じ許可ポリシーにまとめない方が安全です。PR構築では依存関係の読み取りが必要でも、証明書やApp Store Connectの公開権限は不要です。一方、本番署名ノードは成果物送信と認証状態の確認が必要ですが、不信頼なブランチのコードや任意の依存先を自由に取得させるべきではありません。
App Store ConnectのAPIキーは、AppleのAPIキー作成資料に沿って用途と権限を分けます。公証を自動化する場合は、アップロード成功だけで完了とせず、Notary APIの公式資料を基準に、提出、状態照会、ログ取得、チケットの装着まで確認してください。
企業の署名・公開ノードでは、次の分離が判断材料になります。
- PR用ノード：ソースと依存関係の読み取り、ビルド結果の返却を許可し、公開権限は持たせない。
- アーカイブ用ノード：署名資産を限定的に利用し、ジョブの起動元と成果物の保存先を記録する。
- 本番公開ノード：App Store Connect、公証、配布先への送信を許可し、管理者操作とAPIキーの利用記録を残す。
- 障害対応ノード：通常の開発タスクへ再利用せず、緊急時の証拠採取と復旧作業に限定する。
プロキシ、TLS検査、DNS書き換え
Mac CIのプロキシと企業ファイアウォールを設計する際は、明示的プロキシ、透過プロキシ、TLS復号、内部CA、DNS書き換え、HTTPリダイレクトを別々に確認します。同じURLでも、管理者のシェルとCIサービスアカウントでは、証明書チェーンや認証情報が異なるためです。
Appleのサービス、コードホスティング、パッケージソース、社内制品庫ごとに、次の記録を持たせます。
- DNS応答と確認日時
- TCP接続の成否
- TLS証明書と内部CAの検証結果
- 認証・認可の結果
- APIまたはパッケージ取得の応答
- パイプライン全体の成功・失敗ログ
- ルール変更の責任者、再確認日、ロールバック方法
注意: TLS復号を例外なく適用すると、証明書ピンニング、Appleサービスとの相互運用、署名関連の認証処理に影響する可能性があります。適用可否は一般論で決めず、対象の実リクエストと企業のセキュリティ基準で確認してください。
SECTION 04 本番投入前のネットワーク受け入れ
遠隔Mac構築機の検証手順
遠隔Macの構築機を受け入れる場合は、ホストへログインできることではなく、指定したネットワーク境界で完全なCIが終了することを合格条件にします。次の順番で記録を作ると、調達時の比較にも利用できます。
- ノードを分類する：通常構築、依存関係取得、署名・公開、災害対策の用途を決め、Runnerラベルとネットワーク区域を割り当てます。
- 実行アカウントを固定する：管理者アカウントではなく、実際のCIサービスアカウントで環境変数、Keychain、SSH鍵、プロキシ設定を確認します。
- 許可先を登録する：Apple公式資料の対象、企業Git、私有制品庫、CI管理先を、用途と操作権限付きで登録します。
- 六層の通信確認を行う：DNS、TCP、TLS、認証・認可、業務リクエスト、完全なパイプラインの順番で証拠を保存します。
- キャッシュなしで再実行する：依存関係とXcodeコンポーネントのキャッシュを無効化し、初回取得でも成立するかを確認します。
- 署名と公開を分離検証する：テスト用成果物で署名、アップロード、公証の状態照会、ログ取得、チケット装着まで確認します。
- 障害復旧を確認する：プロキシ遮断、DNS異常、Runner再接続などの失敗を想定し、再接続後にどの証拠が残るかを記録します。
- 審査結果を決める：すべての証拠が揃えば放行、一部に期限付き課題があれば期限付き是正、限定区域でのみ検証できれば隔離試験、署名資産や宛先が管理できなければ本番投入禁止とします。
受け入れチェックリスト
- [ ] Xcode 27の対応OSとApple Silicon条件を公式リリースノートで確認した
- [ ] ソースコード、Git LFS、サブモジュールの接続先を個別に登録した
- [ ] Swift Package、CocoaPods、私有制品庫をAppleサービスのルールと分離した
- [ ] キャッシュを消した状態で依存関係を解決できた
- [ ] Xcodeコンポーネントとシミュレーターランタイムの取得を確認した
- [ ] 管理者ではなくCIサービスアカウントで同じ手順を実行した
- [ ] DNS、TCP、TLS、認証・認可、業務リクエスト、完全なパイプラインの証拠を保存した
- [ ] PRノードと本番署名ノードの外向き通信範囲を分離した
- [ ] App Store ConnectのAPIキー権限と利用ログを確認した
- [ ] 公証の提出、状態照会、ログ取得、チケット装着を確認した
- [ ] Runnerラベル、Runner Group、ネットワーク区域の対応を確認した
- [ ] ルール番号、失敗ログ、承認者、再確認日、ロールバック手順を登録した
- [ ] 通信遮断後の再接続と、失敗時の証拠保存を確認した
このチェックリストで重要なのは、許可した宛先の数ではなく、各ルールが実際のジョブと結びついていることです。企業ファイアウォールの変更審査では、「Appleを許可した」ではなく、「どのジョブが、どの実行アカウントで、どのサービスへ、どの操作を行い、どのログで成功を確認したか」まで提示してください。
現行の社内Macや一般的なクラウド環境では、プロキシ経路、私有依存関係、署名資産、失敗後の再接続が別管理になりやすく、担当部署ごとの設定差分も残りがちです。遠隔Macを長期採用する前に、VPSNIXのヘルプセンターで確認項目を整理し、企業プロキシ、私有制品庫、本番署名、失聯時の復旧を含む小規模な受け入れを先に行う方が、購入後にネットワーク設計をやり直すより判断しやすくなります。
ネットワーク許可リストの証拠がそろい、必要なノードだけを分離して運用できるなら、VPSNIXのMacレンタル料金を、実際のCIジョブと照合してください。価格だけで決めず、あなたの環境で「依存関係取得から公証・結果回収まで」検証できるかを確認してから、短期の試験導入か長期運用かを選ぶのが安全です。