2026 リース型クラウド Mac CI における iOS IPA エクスポート、ExportOptions.plist、App Store Connect API

すでに SSH で Apple Silicon のクラウド Mac に入り、xcodebuild archive を回せるチームでも、次の関門である IPA エクスポートと App Store への配送でパイプラインが静かに劣化します。ExportOptions.plist の method 誤り、Xcode の署名設定とズレた手動プロビジョニングマップ、あるいは非推奨の altool 前提のまま残ったアップロード手順が典型です。本稿は 2026 年時点で MacXCode が香港・日本・韓国・シンガポール・米国東海岸の顧客から受ける問い合わせを整理し、誰が（分散 iOS チーム）、何を（再現可能なエクスポート＋ API アップロード列）、どう（比較表・7 ステップ・FAQ）を一気通貫で示します。併読として リモート Archive 自動化、リモート署名の最適化、macOS 成果物も出す場合は notarytool パターン を参照してください。

本番 CI で -exportArchive が壊れる理由（「手元の Mac では通る」では済まない）

エクスポートは見かけ上たった 1 つの plist と 1 コマンドですが、運用では次の失敗クラスが支配的です。いずれもログの一行だけでは原因が分かりにくく、再現に時間がかかります。

• プロビジョニングのドリフト — 配布系プロファイルは多くの場合 12 か月 で期限切れになります。半年前にキャッシュしたパスを CI が参照し続けると、アーカイブは成功しても error: exportArchive で終わります。
• method の取り違え — エンタープライズ MDM 向けに ad-hoc が必要なのに app-store を選ぶ、あるいはその逆。アップロードは成功してもテスター端末に入らず、夜間リリースが宙に浮きます。
• 単一ホスト上の並列ジョブ — 2 つのエクスポートが同じ ~/exports/release に書き込むとレースが発生します。24 GB ユニファイドメモリの Mac mini M4 では、パスをジョブ UUID で分離しない限り、同時 3 レーン程度が実務的な上限になりがちです。
• アップロード遅延 — 約 220 MB の IPA を 12 Mbps の上りで送ると、App Store Connect にビルドが現れるまで 24 分以上 かかることも珍しくありません。シンガポールのビルダーから米東寄りのエンドポイントへ上げる構成では体感がさらに悪化します。

加えて、Xcode のマイナーアップデート後にエクスポート時の警告閾値が変わり、従来は通っていた設定が突然ブロックされるケースも報告されています。そのため「成功した最後のビルド」のメタデータとしてツールチェーン文字列を必ず残す運用が有効です。

ExportOptions.plist で実際に選ぶ配布 method

method はラベルではなく、エンタイトルメントの扱いやシンボル送信の既定、レガシー bitcode の期待値まで波及します。TestFlight と社内配布、ストア公開を議論する際の共通言語として使ってください。

method	主な利用者	アップロード先	運用上のメモ
app-store	公開 App Store と TestFlight	App Store Connect の処理キュー	App Store 配布プロファイルが必要。多くのテンプレでシンボル送信が有効。
ad-hoc	登録端末／QA	MDM や手動インストールが多い	UDID リストの鮮度が命。リース端末でのプッシュ検証に向く。
enterprise	社内のみ	社内 CDN／MDM	エンタープライズプログラムが前提。キーチェーンはクラウド Mac でも分離推奨。
development	エンジニアのデバッグ	直接インストール	反復が最速。初回信頼には ヘルプ の VNC 手順も参照。

マルチターゲットアプリでは extension ごとにプロファイル要件が異なるため、provisioningProfiles の辞書をレビュー対象に含めることを推奨します。Pull Request の差分に plist が紛れ込むより、CI テンプレートから生成する方がドリフトしにくいです。

method 以外の高シグナル鍵

Fastlane が常設されていないリースビルダーでは、以下のキー設定ミスがサポート工数を押し上げます。コピペ肥大化した plist は削ぎ落として最小構成に寄せてください。

キー	設定する場面	誤設定のリスク
signingStyle	自動／手動の切り替え	manual で provisioningProfiles が無いと即死。automatic は複数チームがあると誤選択しうる。
provisioningProfiles	手動マルチターゲット	拡張の欠落は部分エクスポートや実行時クラッシュに直結。
teamID	複数 Apple チームを同一ホストに取り込む場合	誤った teamID では「証明書が無い」ように見える。
uploadSymbols	TestFlight のクラッシュ解析	オフにするとアップロードは速いがスタックが読めなくなる。
compileBitcode	レガシー管線のみ	現行 iOS では無視されがちだが、古い Watch ターゲットで驚きがある。

7 ステップ：.xcarchive から ASC に見えるビルドへ

1. ツールチェーンを固定記録 — xcodebuild -version、xcode-select -p、sw_vers を必ずログ化。
2. アーカイブ整合性 — Products/Applications/YourApp.app の存在と codesign --verify --deep --strict。
3. レーンごとに plist をレンダリング — EXPORT_METHOD と TEAM_ID を CI 変数から。API の issuer id は署名証明書と別保管。
4. UUID ディレクトリへエクスポート — 例 exports/${BUILD_UUID}/ で衝突回避。
5. export 実行 — キーチェーン方針が許す場合のみ -allowProvisioningUpdates を付与。
6. チェックサムと保持 — IPA の SHA-256 をメタデータ化。dSYM は少なくとも 90 日 保持が一般的目安。
7. ASC API でアップロード — JWT ベースのツールを標準化し、Apple の相関 ID をログに残す。

xcodebuild -exportArchive -archivePath ./build/YourApp.xcarchive -exportPath ./out -exportOptionsPlist ExportOptions.plist

運用が成熟すると、エクスポート時間そのものより「アップロード待ち行列に入るまでの壁時計時間」がボトルネックになります。地域別にビルダーを置き、上り経路を短くする投資が効いてきます。料金とリージョンは pricing で比較できます。

App Store Connect API と対話型 Transporter

Transporter.app は単発検証に便利ですが、CI ではロールを絞った API キーへ寄せるべきです。GUI 前提の Finder ステージングを挟まないぶん、API 経路は往々にして速く、シンボルの gzip と IPA 送信をパイプライン化しやすいです。シンガポールのビルダーからグローバルな ASC 処理へ流す場合でも、JSON エラーレスポンスをそのままジョブ成果物に保存するとエスカレーションが早いです。

社内のオンコール手順に MacXCode ヘルプ の接続要件をリンクしておくと、深夜にポート開放を疑う往復が減ります。

共有クラウド Mac の落とし穴と回避策

スカッドごとに裸機の Mac mini M4 をリースする方が、オフィスの「ペット」1 台を奪い合うより安定しやすいのは、キーチェーンとストレージの隔離が明確だからです。それでもマルチテナントにするなら：

• macOS ユーザーを分けるか、製品線ごとにキーチェーンファイルを分離。
• ~/Library/Developer/Xcode/Archives を週次で 21 日 超を削除。アーカイブ肥大はエクスポート後も続く。
• launchd や Actions のサービス定義で DEVELOPER_DIR を明示し、GUI ログインによる Xcode 切替を防ぐ。

ディスクは IPA 本体よりも古いシミュレータデータや複数 Xcode の残滓が圧迫することがあり、空き容量が 15% を切ると I/O レイテンシが非線形に悪化する点に注意してください。

FAQ：ヘッドレスビルダーでのエクスポートとアップロード

質問	実務回答
全ブランチで同一 plist を使い回してよいか	method と署名スタイルが不変なら可。bundle id が変わる feature ブランチでは CI で plist 断片を生成し、古い provisioningProfiles を避ける。
フル Xcode.app はまだ必要か	多くの iOS エクスポート経路では必要。CLT のみのホストは IDE 管理資産が欠ける。ブログ索引の CLT 比較記事を参照。
リージョン別 M4 エクスポーターをどこで借りるか	pricing で HK／JP／KR／SG／US を比較し、テスター所在地とデータレジデンシーを同時に満たす。

なぜ Mac mini M4 裸機はエクスポート時間を予測しやすいか

エクスポートは CPU・ディスク・署名の三重制約です。ユニファイドメモリは .xcarchive をホットに保ち、バンドル再密封時の I/O を支えます。Apple Silicon の AES 性能は内部ミラーへ暗号化アップロードする管線でも効きます。サポート外の仮想化スタックに無理やり macOS を載せるより、実機の Mac mini M4 は Xcode リリースノートに近い挙動を返し、オーケストレータから SSH／VNC で操作するだけで本番相当の再現性が得られます。MacXCode の香港・日本・韓国・シンガポール・米国プールは、TestFlight 検証チームの近くにワーカーを置きつつホスト単位で署名素材を隔離する設計に向きます。

まとめ：ExportOptions.plist をコードと同列に扱い、レビューとバージョン管理、そして本番と同クラスのマシンでの検証を徹底してください。レーンを増やすときは単一 Mac に過負荷をかける前にノードを追加し、pricing と help で接続と容量を確認しましょう。