Swift Package Manager企業プロキシはどう設定する？2026 Mac CIガイド

AppleのCI向け資料は、Swiftパッケージを使うビルドで依存関係の取得とビルド環境を個別に確認する前提を示しています。AppleのCI向けSwiftパッケージ構成に沿うなら、Swift Package Manager企業プロキシは、RunnerへHTTP_PROXYを1つ設定して終わりにしてはいけません。最初に、ソースリポジトリ、Swift Package Registry、バイナリ成果物、Appleサービスの4系統へ通信を分け、実際のCIサービスアカウントとクリーンな作業領域で受け入れます。

今週の推奨アクション

• 月曜日：依存関係の通信経路と実行アカウントを台帳化します。
• 火曜日：macOS、シェル、Git、SSH、Keychainの設定スコープを分離して確認します。
• 水曜日：HTTPS、SSH、Registry、バイナリ取得を個別に検証します。
• 木曜日：TLS検査とAppleサービスの例外を確認します。
• 金曜日：キャッシュなしの実ビルド、再起動、資格情報更新を含む受入試験を実施します。

この手順は、管理者のターミナルでは成功するのにCIだけが失敗する問題を対象にしています。企業プロキシ、内部CA、Xcode流水線を管理するIT責任者、プラットフォームエンジニア、そして自社MacとリモートMacのどちらを採用するか判断する技術責任者に適しています。

Swift Package Managerの失敗を1つのプロキシ設定で説明すると、原因の境界が崩れます。ソース管理から取得するパッケージ、Registryから取得するメタデータ、バイナリTargetの成果物、Appleの更新・認証関連サービスでは、実行するツール、認証方式、証明書、許可すべき例外が異なるためです。

Swift Package Registryの利用方法は、Swift Package Manager公式のRegistry使用説明で確認できます。Registryを使う構成では、Gitのプロキシ設定だけを変更しても、Registryの認証や取得経路まで自動的に切り替わるとは考えないでください。

まず、各系統について「宛先」「名前解決」「使用プロセス」「実行アカウント」「認証情報の保管場所」を記録します。ポート番号や宛先を推測で許可リストへ追加せず、実際のログと企業ネットワーク担当者の承認を根拠にします。

管理者の対話型ターミナルで成功した結果は、CIの成功を意味しません。CIサービスが起動するユーザー、ログインシェルの有無、LaunchDaemonやRunnerの起動方式、Keychainのロック状態が違えば、同じMacでも見える設定は変わります。

設定は次のように分けて確認します。

GitのHTTPプロキシやTLS関連設定は、Gitの設定リファレンスとGit FAQのネットワーク設定を根拠に確認します。設定をコピーする前に、CIサービスアカウントで次のような読み取り確認を行います。

id
env | grep -E '^(HTTP|HTTPS|NO_PROXY)='
git config --show-origin --get-regexp '(^http\.|url\.)'
ssh -G git.example.invalid

上記は接続を成立させるコマンドではなく、どのアカウントがどの設定を見ているかを確認する最小例です。実際の社内ドメイン、資格情報、証明書の内容はログへ出力しないでください。

注意：個人のプロキシ資格情報、管理者の環境変数、個人Keychainを共有Macへ複製すると、権限管理と監査範囲が不明確になります。CI専用アカウント、専用資格情報、最小限の宛先許可を基本にします。

最初の検証では、いきなりフルビルドを実行せず、依存関係の取得経路を分けます。HTTPS形式のGit、SSH形式のGit、Swift Package Registry、バイナリTargetの順番で、成功した経路と失敗した経路を記録します。

xcodebuildがシステムGitを利用する構成を採用する場合は、Xcodeのソース管理プロバイダー指定と、Git側の設定を一緒に確認します。-scmProvider systemを使う判断は、AppleのCIワークフロー資料にあるXcodeとソース管理の扱いを確認したうえで行います。

ただし、システムGitを指定しても、Swift Package Registryやバイナリ成果物のHTTP通信までGitの設定を利用するとは限りません。したがって、次のように検証結果を分けます。

• HTTPS Git：Gitのプロキシ、CA、資格情報を確認します。
• SSH Git：SSHのHost設定、known_hosts、CIユーザーの鍵を確認します。
• Registry：RegistryのURL、認証、TLS、応答を確認します。
• バイナリTarget：実際の配布URL、証明書、認証、取得後の検証を確認します。

依存関係のバージョンは、リポジトリにあるPackage.resolvedを管理対象にします。CIで自動解決を無制限に許可すると、同じコミットでも取得時点によって解決結果が変わる可能性があります。AppleのCI資料を参照し、解決、ビルド、テストの扱いを流水線のポリシーとして固定します。

企業HTTPS検査で最も危険なのは、失敗を見て証明書検証を無効にすることです。内部Gitや内部Registryへ接続するための企業CAと、Appleサービスが要求するTLS通信は同じ信頼境界として扱わないでください。

Appleの企業環境におけるソフトウェア更新とネットワーク要件を確認し、TLS中間検査が適用できないAppleサービスをネットワーク担当者と特定します。社内サービスについては、企業のCA配布、失効、更新、監査の手順に従って信頼を構成します。

障害時は、次の3層を分けて証拠を集めます。

1. プロキシ転送：プロキシが要求を受け、許可された宛先へ転送したか。
2. TLS検証：証明書チェーン、ホスト名、内部CAの信頼が成立したか。
3. アプリケーション認証：RegistryやGitが資格情報を受け入れたか。

DNS解決が成功しても、TLSやアプリケーション認証が成功したとは限りません。逆に、証明書エラーを内部CAの追加だけで解決しようとして、Appleサービスの例外要件を見落とす場合もあります。

最初の本番相当試験は、キャッシュ済みの作業領域ではなく、クリーンな作業領域から始めます。依存取得がキャッシュに隠れると、プロキシやRegistryの設定が壊れていても成功してしまうためです。

次の順番で、実際のCIサービスアカウントを使って確認します。

• [ ] クリーンな作業領域を作成し、既存の依存キャッシュを参照しないことを確認します。
• [ ] Package.resolvedを取得し、意図した依存バージョンを記録します。
• [ ] HTTPS Git、SSH Git、Registry、バイナリTargetを個別に通過させます。
• [ ] xcodebuildで依存解決、ビルド、テスト、成果物生成を実行します。
• [ ] 各段階の実行ユーザー、宛先、失敗したプロセスを記録します。
• [ ] Macを再起動し、CIサービスと必要なエージェントが自動復旧することを確認します。
• [ ] プロキシ資格情報を更新し、古い資格情報が残っていないことを確認します。
• [ ] プロキシを一時的に利用できない状態にし、失敗が監視と再試行ポリシーへ反映されることを確認します。

AppleのCI資料は、依存関係を取得する工程とビルド工程を含むCIワークフローを扱っています。したがって、単に「パッケージを1回ダウンロードできた」だけでは受入完了にしません。依存解決、再現可能なビルド、再起動後の復旧、資格情報の更新を別々の合格条件にします。

経験則：成功率や所要時間を一般値として置かず、企業の流水線記録から算出します。ネットワーク経路、キャッシュ状態、パッケージ構成が変われば結果も変わるためです。

Swift Package Managerが企業プロキシで依存関係を取得できない理由

RunnerへHTTP_PROXYを設定しても、Git、Registry、バイナリ取得、Appleサービスの全経路へ同じ設定が継承されるとは限りません。実行アカウント、Git設定、SSH設定、内部CA、プロキシ例外を個別に確認し、どの層で失敗したかをログで分けます。

xcodebuildでシステムGitのプロキシ設定を使う場合

xcodebuildのソース管理プロバイダー指定と、CIサービスアカウントが参照するGit設定を確認します。-scmProvider systemはシステムGitを使う構成の検討材料になりますが、RegistryやバイナリTargetの通信を同じ経路にする指定ではありません。

企業HTTPS検査がSwiftパッケージ解析へ与える影響

TLS中間検査によって、証明書チェーンやホスト名の検証が失敗する場合があります。Appleサービスは企業ネットワーク要件に従って例外を判断し、社内GitやRegistryでは企業CAを正式な管理手順で配布します。検証無効化は採用しません。

Mac CIサービスアカウントへのプロキシと証明書の継承

macOSのシステム設定、環境変数、Git、SSH、Keychainはそれぞれ別の作用範囲を持ちます。CIサービスの起動方式と実行ユーザーを先に固定し、必要な設定だけを専用アカウントへ配布します。管理者のログイン環境をそのまま移植しないことが重要です。

リモートMacから企業Gitと内部Registryへ接続する条件

リモートMacの出力経路、DNS、許可宛先、プロキシ認証、企業CA、無人運転時の資格情報を確認します。まず隔離ノードでクリーンな依存解析と再起動後の復旧を実施し、すべて合格してからチーム用ノード池へ拡張します。

最初から全社の本番ジョブを1台へ集約するのではなく、隔離ノードで非本番ジョブを受けます。依存解析の記録、TLSエラー、資格情報更新、再起動後の復旧を確認し、問題がプロキシなのかMacのサービス起動なのかを切り分けます。

社内ネットワークへ接続する必要があるノードと、公開依存だけを扱う弾性ノードは、同じポリシーにしない方が管理しやすくなります。署名やリリース成果物を扱うノードは、さらに独立したKeychainとネットワーク許可を持たせます。

既存のMacで代理設定の安定運用や遠隔復旧が難しい場合は、次の順で判断します。

• 現行Macを改修し、CIサービスアカウントと起動設定を固定する。
• 専用のMacビルドノードを追加し、社内依存を扱うジョブを分離する。
• 自社設備では復旧経路やネットワーク例外を管理できない場合、隔離したリモートMacノードを受入試験へ参加させる。

リモートMacの企業ネットワーク適合性を検討する際は、まず日本向けのJEXCLOUD Mac環境を候補にし、今回の通信地図と受入表をそのまま適用します。地域を固定すること自体が合格条件ではなく、企業Git、内部Registry、Appleサービス、再起動後のCI復旧が確認できることが条件です。運用全体の入口はJEXCLOUDの日本語Macサービス案内で確認できます。

自社Macは物理インターフェース、長期の高負荷、社内設備との密接な連携が必要な場合に適しています。一方で、調達期間、故障時の交換、設置場所、電源、ネットワーク変更、余剰容量が負担になります。既存の共有Macを使い続ける方式も、ユーザー環境の混在、Keychainの境界、再起動後のジョブ復旧、プロキシ設定のドリフトが残りやすい点が弱点です。

依存関係の通信を分離し、サービスアカウントでクリーン環境と再起動を検証した後なら、リモートMacのレンタルは「設定を隠す」ためではなく、同じ受入条件を満たすノードを必要な期間だけ増やす手段になります。まずは隔離ノード1台で企業プロキシ、内部依存、無人運転の復旧を確認し、合格した場合だけチーム用ノード池へ広げるのが安全な進め方です。