Xcode Cloudの送信元IP変更後、企業ファイアウォールをどう更新する？2026

【判断】Xcode Cloudの送信元IP変更に伴うファイアウォール更新は、Appleが現在公開しているIP範囲を基準に、コード管理側とネットワーク側の許可リストを照合し、実際のワークフローで確認してください。古いルールや出所を確認できないIP一覧を、そのまま使い続けるべきではありません。

この手順が役立つのは、Xcode Cloudから自社のGitリポジトリへの接続をIP制限で管理している場合です。
ネットワーク担当者は通信経路とルールを、安全担当者は変更の根拠と承認を、コード管理者はリポジトリ側の許可設定を確認してください。

最終更新：2026年10月26日。AppleのXcode Cloudリリースノートとプロジェクト設定に関する公式資料を照合しています。Appleの公開資料は更新される可能性があるため、変更作業の時点で最新の内容を再確認してください。

Xcode CloudのIP範囲はどこで確認し、何を根拠にするか

Appleは、Xcode Cloudの送信元IP範囲が2026年2月10日に変更されたことをリリースノートに記載しています。アドレスの根拠には、リリースノートの記載だけでなく、コードリポジトリへのアクセスに関する範囲を示すプロジェクト設定資料も使ってください。この記事ではIPアドレスを転記しません。実際のルールには、作業時点でAppleが公開する値を反映します。

「Xcode Cloud IP ranges」を調べるときは、検索結果や過去の設定ファイルを公式資料の代わりにしないことが重要です。アドレスファミリーごとの記載、適用対象、ページの更新状況を公式ページで確認し、社内に保存している許可リストとの差分を取ります。Appleのソースコード管理接続に関する説明も確認し、実際のリポジトリ接続方式と照らし合わせてください。

まず、影響を受ける通信経路を切り分けます。今回確認するのは、Xcode Cloudからコードリポジトリへの接続です。ビルド後の成果物転送など、別の通信経路まで同じ変更の対象だと決めつけず、各経路の接続先と管理者を個別に特定してください。

ネットワーク担当者：第一段階でルールと変更記録をそろえる

「企業ファイアウォールのallowlist」は、許可する送信元だけでなく、宛先、プロトコル、適用するゲートウェイやルールオブジェクトを組み合わせて確認します。AppleのXcode Cloudセキュリティ資料とプロジェクト設定資料を参照し、リポジトリへの接続に必要な通信だけを対象にしてください。

ルールを変更する前に、現在の設定、変更申請、承認者、変更理由、切り戻し方法を記録します。通信がまだ復旧しない場合に、どのルールを元に戻すか判断できない状態では作業を始めないでください。許可範囲を一時的に任意の送信元へ広げる対応は、原因を切り分けにくくし、意図しない通信まで許可するおそれがあります。

コード管理者：自社Gitへの接続とリポジトリ権限を分けて確認する

自社運用のGitサービスでは、ネットワーク許可が通っても、リポジトリへの認証やユーザー権限が不足していればコードを取得できません。反対に、認証設定が正しくても、IP制限で接続元が拒否されることがあります。Appleのソースコード管理設定に沿って接続構成を確認し、通信許可とリポジトリ認可を別々に検証してください。

企業向けコード管理サービスでIP制限を設定している場合は、サービス側の許可リストも対象です。たとえば、企業向けIP許可リストの管理資料では、許可リストが組織へのネットワークアクセス制御に関わることが説明されています。自社の契約形態や設定に該当する制限があるかを確認し、ファイアウォール側だけを更新して完了としないでください。

セキュリティ担当者：許可範囲を必要な接続に限定する

変更審査では、Appleの公開範囲を根拠として残し、送信元・宛先・通信方式が実際の接続要件に一致するかを確認します。不要な宛先をまとめて許可したり、一時的に広げたルールを期限や責任者なしで残したりしないでください。具体的な通信制御の効果は、組織のネットワーク構成と実地検証で確かめる必要があります。

記録の作り方は、NISTのセキュリティ管理策資料を参考に、変更の根拠、承認、実施結果、監査可能な証跡を結び付けます。これは個々のファイアウォール設定を保証するものではありません。自社の変更管理手順に合わせて、どの記録を保存するか決めてください。

CI担当者：allowlist更新後、実ワークフローで取得を確かめる

設定画面上で許可リストを更新しただけでは、接続が復旧した証明になりません。対象リポジトリを使う代表的なXcode Cloudワークフローを選び、リポジトリ接続、コード取得、ビルドの結果を一連の記録として残します。手順は最初のXcode Cloudワークフローの設定資料とワークフローのアクションに関する説明を参照してください。

作業順序は次のとおりです。

1. Appleの最新資料で、対象プロジェクトに適用される送信元IP範囲を確認します。
2. 現行のファイアウォール、ゲートウェイ、コード管理側の許可リストを保存し、差分を特定します。
3. ネットワーク担当者が必要なルールだけを申請し、セキュリティ担当者の承認を得ます。
4. コード管理者が許可リストとリポジトリの認可設定をそれぞれ確認します。
5. CI担当者が代表的なワークフローを実行し、接続、取得、ビルドの記録を保管します。
6. 失敗が残る場合は、ルールの反映状況、リポジトリ認可、ワークフロー設定を分けて調べ、必要なら承認済みの手順で切り戻します。

社内の変更記録には、次のような項目を残せます。これは記入用のひな形であり、接続成功を示す実行結果ではありません。

根拠資料: Apple公式のXcode Cloud資料
変更対象: ファイアウォール / リポジトリ許可リスト
確認者: ネットワーク / セキュリティ / コード管理
検証対象: 対象ワークフローとリポジトリ
実行結果: チームの実測結果を記録
切り戻し責任者: 担当者名を記録

「Xcode Cloudのリポジトリ取得が成功したか」は、実行記録で確認してください。失敗した場合も、単発のエラーだけでIP範囲が原因だと断定せず、ルールの反映、リポジトリ側の許可と認可、ワークフローの設定を個別に確認します。なお、依存関係の取得はリポジトリ本体とは別の確認事項になる場合があるため、必要に応じて依存関係をXcode Cloudで利用する公式ガイドを参照してください。

判断に迷った場合は、次の条件で作業を分岐できます。

• Appleの現行資料で対象範囲と適用先を確認でき、影響する接続経路も特定できた場合は、承認を得て該当する許可ルールを更新します。
• Appleの資料と社内ルールの対応関係を説明できない場合は、IPを推測で追加せず、ネットワーク担当者とコード管理者が接続方式と対象サービスを再確認します。
• ルール更新後に代表的なワークフローで取得できた場合は、実行記録を証跡として変更を完了します。
• 取得できない場合は、許可範囲を広げず、ルール反映、リポジトリ認可、ワークフロー設定を分けて調査し、結果に応じて変更を修正または切り戻します。

技術責任者：後から再確認できる変更にする

変更を閉じる前に、公式資料への参照、ルールの変更記録、承認、代表ワークフローの結果、切り戻し責任者がそろっているか確認します。次回の見直し担当と、Appleの公開資料に更新があった場合の確認方法も決めてください。社内の許可リストが最新かどうかは、実際の設定を確認し、ワークフローを検証するまで確定できません。

今回の作業はXcode Cloudからリポジトリへのアクセス制御を整えるもので、macOSビルドを実行する環境の調達とは別の判断です。チームに専用Macがなく、ビルド需要が一時的または変動する場合は、購入時の初期費用、保守、空き時間のコストと、必要な期間だけ使うMacレンタルを比較してください。長期にわたり安定した高負荷が続く場合や物理ポートへの接続が必要な場合は、自社保有が適することもあります。選択肢を整理する際はMac環境の比較情報を参照し、利用条件の確認が必要ならOakVMへの問い合わせから相談できます。レンタルを検討する場合も、この記事で扱ったネットワーク許可やリポジトリ権限の確認は別途必要です。