2026 ヘッドレスレンタルクラウド Mac CI における Xcode 自動と手動のコード署名

香港・日本・韓国・シンガポール・米国でApple Silicon のクラウド Macにアーカイブを移した iOS チームでも、コード署名だけで何時間も失うことがあります。Xcode が「壊れている」のではなく、ノート PC では問題にならなかった CODE_SIGN_STYLE の選択が、ヘッドレス SSH・共有キーチェーン・「常に許可」をクリックできない CI と衝突しているのです。本稿（2026年版）はリモートビルダー向けに自動署名と手動署名を比較し、意思決定マトリクスとキーチェーン＋xcodebuild の実務チェックリストを示します。リリースラインの次工程として リモート Archive、署名まわりの最適化、IPA 書き出しと App Store Connect API も合わせて参照してください。

ヘッドレス環境のクラウド Mac でだけ署名が爆発する理由（ローカルでは「動く」のに）

多くのエンジニアが「自動署名」を「設定ゼロ」と混同します。レンタル Mac に ssh だけで入ると、次の制約がすぐ効きます。

• GUI の信頼プロンプトがない — 秘密鍵や配布用証明書への初回アクセスは事前に許可が必要です。さもなければ xcodebuild は永遠に現れないダイアログを待ち続けます。
• 共有ログインキーチェーン — 5 本の並列パイプラインが同じキーチェーンを解除すると、断続的な errSecInternalError やアイデンティティの食い違いとしてレースが表面化します。
• プロファイルの更新周期 — 配布プロファイルはおおよそ 12 か月 でローテーションします。更新を忘れた自動パイプラインは、壊れるまで「緑」に見えます。
• 拡張ターゲット — App Clip や Share Extension の bundle id を手動マップから漏らすと、codesign の終盤で失敗し、18〜40 分のコンパイル時間を無駄にします。

自動 vs 手動：CI において Xcode が実際に意味すること

自動は許可されている場合、プロファイル選択を Xcode と Apple の開発者向け API に委ねます。手動はターゲットごとにプロビジョニングプロファイルの UUID を固定します。いずれもキーチェーンに有効な証明書が必要であり、ビルド中に誰がプロビジョニング入力を変更できるかが違います。

観点	自動	手動
プロファイルのドリフト	資格情報があれば -allowProvisioningUpdates で更新可能	CI が新しい .mobileprovision を投入するか、早期に失敗させる
コンプライアンス／変更管理	監査ログでプロファイルのバイト列を証明しにくい	git やオブジェクトストレージで版管理された成果物として扱いやすい
マルチターゲット	チーム設定がきれいなら Xcode が bundle id を同期	埋め込みターゲットごとに明示的なマップが必要
ヘッドレスとの相性	ASC API とキーチェーン解除が自動化されていれば強い	実行時のプロファイル変更を禁止するセキュリティ方針なら強い

意思決定マトリクス：次の Mac を借りる前にレーンを決める

シナリオ	推奨スタイル	メモ
スピード重視のスタートアップ、単一アプリ、小規模チーム	自動 + ASC API	ブランチごとのキーチェーンや使い捨て macOS ユーザーと組み合わせる。
銀行／規制産業	手動 + 署名済みプロファイルをアーティファクトストアへ	CI では -allowProvisioningUpdates を無効化し、プロファイルを秘密と同列に扱う。
多数の bundle id を持つホワイトラベル	手動	CI メタデータから plist マップを生成し、Xcode だけでの手編集に頼らない。
24 GB RAM の共有ベアメタル Mac mini M4	どちらでも可	プロダクト間でスタイルが混在するなら macOS ユーザーを分離する。

キーチェーン規律：真のコントロールプレーン

自動でも手動でも、キーチェーンは共通のボトルネックです。次を標準化します。

1. CI ロールごとに署名アイデンティティは 1 つ — 全エンジニアの Apple Development 証明書をビルダーへ入れない。
2. キーチェーンファイルで分割 — 例：~/Library/Keychains/ci-signing.keychain-db をジョブの KEYCHAIN_PATH で参照。
3. 非対話のアンロック — セキュリティが承認した security unlock-keychain の呼び出しを Runbook に明記し、API キーと同じ周期でパスワードをローテーション。
4. ジョブ後のロック — マルチテナントでは任意だが、露出時間を短くできる。

security set-key-partition-list -S apple-tool:,apple: -s -k "" -D "iPhone Distribution: Your Team" ~/Library/Keychains/login.keychain-db

効き目の大きい xcodebuild フラグと設定

CODE_SIGN_STYLE 以外で、ローカルの MacBook と SSH ビルダーで最も食い違いやすい設定です。

• CODE_SIGN_IDENTITY — Release では iPhone Distribution と Apple Development を明示的に固定。
• DEVELOPMENT_TEAM — プロビジョニングプロファイルのチーム ID と一致必須。タイポは「プロファイルがない」に見える。
• PROVISIONING_PROFILE_SPECIFIER — 手動では月次ローテーション時に raw UUID より specifier を推奨。
• -allowProvisioningUpdates — 自動では強力だが企業では禁止も。パイプラインの lint で方針をコード化する。

リモートチーム特有の共有クラウド Mac の落とし穴

ビルダーがシンガポールにあり開発者が欧州にいても、レイテンシが署名を壊すことは稀です。一方時刻のズレは効きます。ntp を健全に保ち、およそ 120 秒を超えると Apple への TLS が不可解に失敗することがあります。また、ASC API のスロットリングがアジア朝のマージピークと重ならないよう、プロファイル更新ジョブをオフピークに回してください。

配布証明書の更新インポートなど、初回だけ対話が要る作業は Runbook に従い VNC を使い、その後は再現性のある純 SSH CI に戻します。

FAQ：レンタル Mac 上の自動 vs 手動署名

質問	回答
ターゲットごとにスタイルを混在させてよいか	技術的には可能だが実務では避ける — ハイブリッドはサポートが追いにくい。
アーカイブ後の export 署名はどこで検証するか	IPA 書き出し + ASC API で ExportOptions のマップと署名判断を揃える。
ASC に近い MacXCode リージョンはどれか	テスターと法的居住地に合わせる。料金でノードを比較し、SSH の基準は ヘルプ を参照。

署名スループットにおいて Mac mini M4 ベアメタルがまだ重要な理由

Swift が大きなバイナリを吐き、codesign がネストしたフレームワークを再シールするとき、署名は意外と CPU 拘束になります。Mac mini M4 のユニファイドメモリはリンカ出力を常駐させ、オーバーサブスクライブされた VM で起きがちなリモートディスクへのスワップを避けます。MacXCode の HK / JP / KR / SG / US で TestFlight 検証チームの近くに署名ホストを置きつつ、リージョン横断で同じ SSH 自動化を維持できます。

まとめ：資格情報の更新を安全に自動化できるなら自動、コンプライアンスでプロファイルのバイト列を凍結するなら手動。いずれにせよ Xcode を責める前にキーチェーンの物語を握ること。容量計画は 料金、接続チェックリストは ヘルプ を続けて参照してください。