2026-04-22 ヘッドレスのレンタルクラウド Mac における iOS キーチェーンとプロビジョニング衛生(CI 署名)
リリースマネージャーとiOS CI オーナーが SSH で Apple Silicon Mac をレンタルすると、同じ壁にぶつかる:ローカルでは Archive が成功するのに、リモートビルダーでは errSecInternalComponent、「署名証明書なし」、古いプロビジョニング UUID などで失敗する。本2026-04-22ガイドでは、HK / JP / KR / SG / US で無人ジョブを回す際に、ログインキーチェーン、プロビジョニングプロファイル、codesign アイデンティティを揃える方法を説明する。比較表 2 つ、強化された SSH ワークフロー、NVMe の数値予算、そして 自動と手動署名、エクスポートと ASC API、並列 xcodebuild へのリンクを提供する。
ヘッドレスビルダー上の失敗面
UI プロンプトのあるノート PC と違い、レンタルのクラウド Mac は非対話シェルで xcodebuild を動かすことが多い。最も一般的な断裂は 3 層にきれいに写る:キーチェーン状態、プロファイルの鮮度、アイデンティティの不一致。
| 症状 | 典型的な原因 | 最初の計測 |
|---|---|---|
codesign 中の errSecInternalComponent |
ログインキーチェーンがロック、または秘密鍵利用が拒否 | security list-keychains + CI ユーザーのアンロック監査 |
| プロファイルが「署名証明書を含まない」 | ディスク上の UUID ≠ ターゲットに埋め込まれたプロファイル | ~/Library/MobileDevice/Provisioning Profiles と Xcode レポートを比較 |
| ブランチ A は成功、B は失敗 | 同一 CN の複数アイデンティティ、誤選択 | security find-identity -v -p codesigning と明示的 CODE_SIGN_IDENTITY |
xcodebuild archive ごとに 120〜320 GB の高速 NVMe を見込む——dSYM 保持のクラッシュ管線も参照。
署名モード:意思決定マトリクス
キーチェーンに触れる前に、ビルダーが 自動署名(Xcode 管理プロファイル)に依存するか、手動署名(コミット済みプロファイル)にするかを決める。証明書のローテ頻度と、1 台のホストを複数アプリが共有するかで答えが変わる。
| モード | 最適な場面 | 運用コスト | SSH のみ Mac のリスク |
|---|---|---|---|
| 自動 + Xcode 管理 | 高速イテレーション、bundle ID が少ない | プロファイルの世話が低い | 中程度—Apple ID セッションの健全性に依存 |
| 手動 + コミット済み | エンタープライズ管線、再現可能なアーカイブ | ローテの規律が高い | 低い—UUID とアイデンティティが明示 |
| ジョブごとの一時キーチェーン | マルチテナントホスト | 自動化の工数が最大 | 正しく実装すればチーム間漏えいは最小 |
SSH セッションのキーチェーン規律
クラウド Mac の CI ユーザーは login.keychain-db をライブ DB のように扱う:インポートを所有する自動化主体は 1 つだけにし、アンロックは明示的に行う。
- プリフライト — キーチェーン一覧とデフォルトを確認。
- アンロック — 組織承認の非対話アンロック(パスワードは秘密管理から)。
- リストの分割 —
codesignとproductbuildに必要な範囲だけ秘密鍵へ。 - ポストジョブ — 一時証明書を削除し孤児アイデンティティを軽く掃除。
security unlock-keychain -p "$KEYCHAIN_PASSWORD" ~/Library/Keychains/login.keychain-db
プロビジョニングプロファイルのライフサイクル
ディスク上のプロファイルは、アーカイブ時に Xcode が解決する内容と一致させる。次の不変条件を守る:
- ファイル名は UUID:
<UUID>.mobileprovision。マーケのリネームは静かに壊す。 - 配布プロファイルは T-30 / T-14 / T-7 で期限アラート。ASC API でポーリングも可。
- 更新後は旧 UUID を削除し、同一 bundle ID に複数マッチする「ほぼ正しい」選択を防ぐ。
本節は エクスポートオプションと ASC API とセットで読み、緑のアーカイブと期限切れ配布プロファイルのキャッシュが共存する状態を避ける。
アイデンティティ、embedded.mobileprovision、エクスポート
security find-identity -v -p codesigning で列挙し、CI マトリクスで CODE_SIGN_IDENTITY を明示固定する。IPA エクスポートでは埋め込みがチャネル(TestFlight と Ad Hoc)と一致するか確認。クラッシュのシンボリケーションがあるなら dSYM バンドルと UUID を端到端で揃える。
秘密情報レイアウトと NVMe 予算
シンガポールと米国東海岸の多プロジェクトではアーカイブが重なる。分離する:
- 署名ルート — チームごとに制御された
/var/lib/ci風プレフィックス。 - DerivedData — 分離記事のとおりジョブごとの tmp ルート。
- 成果物保持 — 直近 3 つの
.xcarchiveをロールバック用に保持し、古いスライスを刈る。
並列ジョブを広げるときは 並列 xcodebuild に従い、CPU 圧が署名リトライを増幅してキーチェーンエラーを隠すのを避ける。
MacXCode の関連ガイド
戦略は 自動と手動署名、アカウント基礎は ヘルプ、地域ごとの専用署名ホストは 料金。
FAQ:キーチェーンとプロファイル
| 質問 | 実務的な答え |
|---|---|
| 1 つの Apple ID を複数 CI ユーザーで共有すべき? | 避ける——アプリ家族ごとにサービスアカウントを分け、四半期にログインを監査。 |
| VNC は必要? | 初回の信頼プロンプトなど限定的。定常は SSH + ログ。VNC ガイド。 |
| 署名が壊れたとき最速のロールバックは? | 昨日のプロファイル集合を VCS から戻し、オフラインのバックアップからアイデンティティを再インポート——一度だけ再ビルド。 |
なぜ Mac mini M4 ベアメタルが署名スループットで勝つのか
Apple Silicon Mac mini M4 は暗号処理と I/O がローカル NVMe に乗り、ハイパーバイザが割り込み予算を奪わないため codesign レイテンシが予測しやすい。アーカイブ → エクスポート → アップロードを SLA でつなぐときに重要。MacXCode の HK / JP / KR / SG / US 展開でテスター近くに署名ホストを置きつつ同一 SSH ワークフローを維持し、週次リリース向けに 1〜2 TB ストレージも選べる。キーよりアプリが増えるなら 料金からビルダーを追加し、1 つのキーチェーンに過負荷をかけない。