2026-05-12 レンタル Apple Silicon クラウド Mac（HK / JP / KR / SG / US）で Xcode スキーム・ビルド構成・xcconfig 階層により マルチブランチ CI を隔離する

main、release/x.y、多数の feature/* が同一のレンタル Mac mini M4 に流れ込むとき、典型失敗は「Xcode がコンパイルできない」ではなく設定の静かな漂移です。昨日のジョブは本番プロビジョニング付き Release スキームで通り、今日のトピックブランチは Debug 権限だと思い込んでいる——あるいはラッパーがジョブ単位のプレフィックスを落とし、二つの並列 xcodebuild が同じ CONFIGURATION_BUILD_DIR を踏む。この 2026-05-12 のプレイブックは インデックスストアのレーン分離、並列 xcodebuild のキュー設計、GitHub Actions セルフホスト Runner を一本化し、明示的なスキーム対応表と Git 管理される xcconfig スタック、そして解決済みビルド設定をインフラコードとして検証する CI を結びます。

共有レンタルホストでは「スキーム」がローカルより重要になる理由

ローカルでは UI でスキームを切り替え、身体感覚が誤りを拾います。ヘッドレス xcodebuild には触覚がなく、オーケストレータが渡した文字列だけが真実です。ワークフロー YAML の古いデフォルト名は、誤った DEVELOPMENT_TEAM や PRODUCT_BUNDLE_IDENTIFIER を引きずるクロステナント署名インシデントに化けます。本番相当のレンタル CI では、ブランチパターンからスキーム＋構成への正のマッピングを .xcconfig と共に Git 化し、ビルダー上の xcodebuild -list と突き合わせて漂移があればマージを止めるべきです。

ブランチ分類 → スキーム対応（スキーム爆発を避ける）

成熟チームはスキーム面を小さく保ちます：コンシューマ向けアプリ 1 つ、拡張バンドル、必要ならウィジェット、App Store エクスポート設定が大きく異なるときだけ専用アーカイブスキーム。main は App-CI + Debug でユニット、release/* は App-Store + Release のようにポリシーで選択します。正規表現（例 ^release/）をワークフローと同じディレクトリの Markdown に置き、レビューが Git 条件とスキーム文字列を同一 diff で見られるようにします。同一ホストに OpenClaw 等の自動化がある場合、誤起動でも本番署名に届かないスキーム集合を別途用意します。

• トランク向けスキーム — 高速フィードバック、デバッグシンボル、やや寛容な警告。
• リリーストレイン — 警告を締め、dSYM や ASC アップロード設定に整合。
• ホットフィックス — 期限付きエントリを CI チケットで自動失効。

xcconfig 積層：ベース、環境、レーン、シークレット

.xcconfig は合成ポリシーとして扱います。Base.xcconfig で Swift 言語モードと警告プロファイルを固定し、Staging.xcconfig で PRODUCT_BUNDLE_IDENTIFIER にサフィックス、LaneJob.xcconfig（ジョブ生成・非コミット）で CONFIGURATION_BUILD_DIR と OBJROOT を DerivedData 方針に揃えます。include は深さ優先で順序が効くため揮発ファイルは最後に。秘密はシークレットマネージャのテンプレで生成しリポジトリ外へ。include チェーンに code owner を置き、ATS 例外や署名素材の層移動にモバイル基盤とセキュリティの双方承認を要請します。

スキーム決定とセットで渡すべき xcodebuild 引数

-scheme と -configuration に加え、レンタル運用では -derivedDataPath、-resultBundlePath、SwiftPM なら -clonedSourcePackagesDirPath が定番です。これらはインデックス／モジュールキャッシュのレーン記事と整合させ、APFS の振動を抑えます。xcodebuild archive ではテストとアーカイブで同一スキーム対応を共有しないと「テスト緑・アーカイブ赤」に分岐します。ジョブごとに xcodebuild -showBuildSettings -json を成果物として残し、単一コミットに bisect できない回帰でも差分取证が可能になります。

xcodebuild -scheme "App-CI" -configuration Debug -destination 'platform=iOS Simulator,name=iPhone 16' -derivedDataPath "$DD" -resultBundlePath "$RESULT" build

マージキュー、積み PR、「スキーム安定契約」

マージキューはブランチ先端相対でコミット順を入れ替えます。マッピングがブランチ名のみなら大抵安全ですが、合成ブランチ名に依存するなら明示的フォールバックを。積み diff ツールが履歴を書き換えるたびにスキーム検出を再実行し、CI 前置ステップに昇格させます。安定契約としてスキーム改名は二段階（別名スキーム追加→ワークフロー移行→旧削除）を文書化し、Runner の YAML が半端なまま開発者がローカルで legacy を消す事故を防ぎます。

自動署名と手動：xcconfig が助ける所／阻む所

CODE_SIGN_STYLE = Automatic はノート PC では楽ですが共有ホストでは DEVELOPMENT_TEAM の決定性とログ上のプロファイル UUID が依然重要です。手動スタイルはディスク／キーチェーン上のプロファイルを要します——Runbook と整合し、feature ブランチの include がスタイルをひっくり返さないようにします。-showBuildSettings に対する grep ゲートで危険ペア（例 Debug + App Store 配布プロファイル）を禁止。モノレポ多アプリではターゲットごとに xcconfig を名前空間分割します。

意思決定表：ポリシーをどこに置くか

ポリシー	最適な置き場所	理由
コンパイラ警告レベル	追跡 xcconfig	差分可能でアプリコードと同じレビュー
ジョブ別ビルドディレクトリ接頭辞	CI 生成 xcconfig または環境変数	Git に載せずジョブ ID に紐付ける
ブランチ別テスト実行	ワークフロー YAML + テストプラン	オーケストレーションに近い
アーカイブのエクスポート方式	ExportOptions.plist + 専用スキーム	既存 ASC アップロード手順と一致

8 ステップ：スキーム認識マルチブランチ CI の展開

1. 各リージョンイメージで xcodebuild -list -json を実行し JSON をインフラ repo に保管。
2. ブランチ正規表現 → スキーム／構成表を作成し PR テンプレのチェックリストにリンク。
3. xcconfig を積層化し、ターゲットを一つずつ移行して常にグリーン。
4. Release 系構成向けに解決済みビルド設定 JSON を吐く CI ステップを追加。
5. DERIVED_DATA_PATH とビルドディレクトリのエクスポートを並列レーン慣例に揃える。
6. 合成マージブランチ名があるならマージキュー用の命名フォールバックを補う。
7. リリースオンコールへホットフィックス用スキームと期限付き失効を教育。
8. 四半期ごとにリージョン間のスキーム一覧 diff を取りテンプレ漂移を解消。

設定ガバナンスの SLO シグナル

シグナル	しきい値	対応
明示 -scheme 欠落ジョブ	0 容認	ビルド失敗、ワークフローテンプレ再配布
解決済み DEVELOPMENT_TEAM が許容リストと不一致	いかなる 不一致も	成果物昇格停止、署名オーナーへページ
二重書き期間なしのスキーム改名	いかなる 未申告改名も	リリースブランチマージ凍結、マップ更新まで

FAQ

質問	実務回答（2026-05-12）
Debug と Release を別スキームにすべき？	通常は不要。同一スキームに両構成があれば -configuration で選ぶ。
レーンごとに別リポジトリが必要？	不要。ディレクトリ接頭辞と xcconfig サフィックスで一貫運用すれば隔離できる。

高負荷下でスキーム方針を反復しやすい Mac mini M4 レンタルの理由

高速 NVMe と豊富なユニファイド メモリにより、-showBuildSettings プローブ、シミュレータのコールドビルド、アーカイブのドライランを連続実行しつつ APFS 割当を監視できます——リリースフリーズ前に xcconfig スタックを締めるときのフィードバックループが短くなります。地域キャパは 料金 で比較し、スキーム面を広げる前に迷うエンジニアを SSH/VNC ガイドへ誘導してください。