2026 Swift Strict Concurrency を MacクラウドCIで運用するときのゲート／CIだけで踏む地雷と5つの手順 Runbook

モバイルプラットフォームチームならSwift 6移行後のStrictモードが「開発端末だけ緑」の幽霊差分を出すのは珍しくありません。本稿はCI限定の診断差の根を三層に切り、モジュール優先度表と再現手順を提示します。補助として GitHub·Xcode Cloud·専用Mac と Simulator並列PR を推奨順で参照してください。

Strict ConcurrencyのCIメトリクスを検討するチーム

目次

1. 痛み：CIだけで暴れる理由

Strict Concurrencyはローカルで育てたDerivedDataの温かさと、CIの冷えた初回解析とでは診断パスがズレます。さらにDEVELOPER_DIRを揃えないままRunnerを増やすと、警告の有無がXcodeのビルド番号差で揺れます。経営サイドが「本番は再現しないのにCIだけ失敗」と問う場面では、まずビルド番号とディスク水位、Runnerの同時実行数を一枚のPDFに貼るだけで説得力が段違いです。

チーム合同のふりかえりでは、開発端末の体感とCIログの差分を並べるのではなく、再現条件が揃ったうえでのみStrictを必須へ引き上げる合意形成が重要です。ゲートを入れるほど「フラッキ」の言い訳が増えるのは、しばしば観測指標がなく隣接テナントの影響まで混ざっているからです。

  1. 並列度：ノートPCは人間の操作に合わせてスロットル寄り、CIは全コアを同時に叩き@MainActor隔離の差分を露出しやすい。
  2. キャッシュ：モジュール境界の要約がローカル先行で短絡され、CIは未キャッシュでSendableの不足を列挙し切る。
  3. ジョブ形態：PRの軽SmokeとArchive署名を同レーンで流すと、最適化フェーズだけで出る問題をフラッキと誤認する。このミスはログ上のジョブカテゴリが曖昧なときに増え、是正にはラベル運用とRunnerタグ付けが効く。

2. モジュール優先度の表

ADRに落とせる条件に落とします。経理向け説明には前述の三角比較記事を転用してください。

シグナル先にゲート猶予緩和策
複数チーム共有の可変状態最優先社内単独ツール警告をエラーへ上げるのは限定スキームのみ
Actor境界が曖昧競合ログが出たら低頻度画面依存SPMのアノテーション待ちバッファ
OSSがSwift5モード固定フォーク非公開APIADRに撤去期限
キュー逼迫夜間深層ジョブホットフィックス例外ジョブタグで再試行上限を一元化
複数レポ横断共有モジュールレガシーブランチタグ付きリリースのみStrict

3. 5ステップRunbook

  1. ツールチェーン固定：Runnerのxcode-selectとPRテンプレのビルド番号表示を同期。セキュリティパッチでも無断で上げない。
  2. レーン分割：Smoke／Simulator／Archiveをタイムアウトとキャッシュキーで分離。
  3. DerivedData二段閾値：NVMe使用量70%で掃除、85%で強制削除と通知。
  4. 失敗バンドル：モジュールIF抜粋とCPUメモリをZIP化しIssueに貼る。
  5. 一時nonisolated(unsafe)：ADRと期限Issue必須。
export DEVELOPER_DIR=/Applications/Xcode_26.app xcodebuild -scheme S clean test OTHER_SWIFT_FLAGS=-strict-concurrency=complete

4. 追うべきKPI

  • 初回クリーンビルドの壁時計：〜7分を目安にIO飽和を疑う。
  • ArchiveはPコアを占有：混在Smokeと温度トロットルを切り離す。
  • 同一ハッシュは再試行最大1回だけ。
  • キュー深さと警告件数を同一ダッシュボードへ。
  • 夜間フルテストでのみ-warnings-as-errorsへ切替える日付を運用カレンダーに固定。
  • RunnerのThermal Stateがfairを超える頻度を週次で監査し、アーカイブ混線を検知。

5. 読み順

三角比較→Simulator並列→本稿の順が最短です。並列ジョブ数を増やす前にキュー監視だけ整えると見かけだけのスループット改善に陥るため注意してください。Xcode側の並列リンク数とGitホスト側のWebhook遅延も同グラフへ載せ、Strict移行レビューを遅らせない。

6. マルチテナントより専用Mac

隣テナントのIOスパイクでSendable警告が増減すると原因がコードか環境か切り分け不能になります。Apple SiliconとNVMeが独占できるクラウドMacでは熱設計・キュー深さ・SSH運用が一定になり、Strictゲートを経営に説明できます。

共有プールでのみ運用すると調査時間が嵩み、結果としてゲート無効化が選ばれがちです。長期的にはVPSMACの専用M4ノードに寄せたほうが、ログの再現性とチーム時間の両方が節約できます。特に複数サービスへ同一Runnerを載せかえる場合は、温度とNVMe競合ログを分離できないほど不透明になりやすく、プラットフォーム責務が肥大化します。

オンプレ実機を増やしても調達サイクルは長く、待機時間のコストがStrict移行タイムラインを押し返します。VPSMACのようにSSHで済む運用モデルへ寄せれば、開発端末〜CI〜将来的なAIゲートウェイ運用まで一連の設計語彙を揃えやすく、ノード追加も契約単位で追従できます。