2026年独占リモート Mac iOS/macOS CI：SwiftPM の Package.resolved はコミットすべき？——再現可能ビルド、キャッシュ予熱、CI のロック漂移と SSH パイプライン意思決定マトリクス＋FAQ
SSH で駆動する独占リモート Macでは、リゾルバが動く壁時計の 1 分 1 分がそのままコストと感覚に乗ります。そこへ、トランジティブな Swift パッケージの予期せぬ更新が重なると、アプリ差分ゼロでも main が赤くなることがあります。Package.resolved は SwiftPM のピンファイルで、解決済みバージョンとチェックサムを記録します。本稿では、再現可能な iOS／macOS CIのためにいつコミットがデフォルト勝ちか、公開ライブラリで省略する典型、キャッシュ予熱との関係、Xcode／Swift更新によるロック漂移の自動化の置き方を整理します。ピーク時の台数設計の補助線として
2026年iOS CIピーク対策：Mac miniレンタルがビルド自動化に最適な理由、Webhook と共有シークレット境界の整理には
2026年 OpenClaw Webhooks の受信と GitHub／GitLab CI：共有シークレット、ゲートウェイルーティングとレート制限、専用リモート Mac の SSH における再現可能なデプロイ、401／413／タイムアウト FAQ
も参照してください。
1. TL;DR — 2026 年のコードレビューで通るデフォルト
- アプリ・社内向けツール（Xcode ワークスペース＋ SPM）：意図的な「常に最新追従チャネル」が無い限り、
Package.resolvedをコミットする。再現可能なアーカイブ、CI とローカルの一致、二分探索可能な履歴への最安ガードレールになる。 - 配布する Swift ライブラリ（パッケージとして提供）：典型はコミットしない。利用側が解決し、CI はサポートする Swift ツールチェーンでマトリクス解決する。
- モノレポで複数パッケージ：ワークスペース／パッケージごとに resolved が付くことがある。独立扱いにし、どのジョブがロック再生成のオーナーかを文書化する。
- 独占リモート Mac CI：ピン＋温かい SPM／DerivedData キャッシュは、毎回ゼロからの resolve に勝つ。ピンが無いとキャッシュキーも曖昧になる。
- SSH パイプライン：SSH 上でロックを再生成してもよいが、CI が自動コミットするのはボット身份とブランチ保護が揃っているときだけ。それ以外は開発者に
swift package resolveをローカルで回してもらう運用が安全。
2. Package.resolved が実際に留めるもの
SwiftPM は Package.swift や Xcode のパッケージ依存からセマンティックバージョン要件を読み、具体的なgit リビジョン（およびレジストリ利用時はその識別子）へ解決する。解決結果が Xcode が使うワークスペース／パッケージルートの Package.resolved に書き出される。このファイルが「semver 上 ~> 2.1 は合法」と「今日はコミット abc123 でビルドした」の橋になる。
ロックをコミットしないと、同一コミット上の 2 つの CI ジョブが、下流タグの移動だけで別の依存グラフをコンパイルしうる。フレークしたテストの二分が不可能になる典型失敗モードである。
3. 再現可能ビルドと依存の鮮度
再現性は監査、App Store インシデント対応、顧客クラッシュのシンボリケーションに効く。鮮度はセキュリティパッチと API 追随に効く。一度きりの二者択一ではなく、自動化の設計である。
- ピン＋定期バンプ：Dependabot／Renovate／社内週次ジョブが
Package.resolvedを再生成し、テスト後に PR。アプリでは業界デフォルトに近い。 - ピン無し：毎 CI でフローティングヘッドを受け入れ、キャッシュと非決定性のコストを払う。リリースブランチでは稀に許容される。
4. 専用 Mac Runner 上のキャッシュ予熱
SPM の clone とビルド成果はユーザーの SourcePackages 周辺と Xcode の DerivedData に溜まる。短命ホスト Runner は毎回コールドになりがちだが、専用機では CI ユーザー単位で温かいキャッシュを維持できる。ただしジョブ同士がチェックアウトを振り回すと効果が潰れる。
- キー付きキャッシュ：
Package.resolvedのハッシュに加え、Xcode バージョンと macOS マイナーをキャッシュキーに含め、リストアの誠実さを保つ。 - コールド resolve：ロックを外すと「最新互換」は速いが、毎回リゾルバのネットワーク I/O が発生し、GitHub レート制限や不安定さの下で SSH 運用の Mac 農場には高くつく。
- 並列ワークスペース：1 台に複数エージェントを載せるなら、ユーザ分離または DerivedData ルートの分離で SPM のファイルロック競合を避ける。
5. Xcode や Swift が変わったときの CI ロック漂移
Apple は Xcode 内の Swift ツールチェーンを頻繁に更新する。Xcode A で生成した resolved を Xcode B で開くと、パッケージが変わっていなくてもリゾルバグラフや成果物レイアウトの差で書き換わることがある。「Xcode アップグレード」はマイグレーションタスクとして扱う。
- ブランチファミリー（release と main 等）ごとに
xcode-selectパスを CI で固定する。 swift package resolve（または Xcode の Resolve）を、ロックだけを更新する制御された PR で一度に回す。- マージ後にキャッシュを再予熱し、マイグレーション前後のアーティファクトが混ざらないようにする。
6. 意思決定マトリクス（コミットするか／しないか）
| シナリオ | Package.resolved をコミット？ |
メモ |
|---|---|---|
| Git 管理の iOS／macOS アプリ | はい（ワークスペース単位） | CI、TestFlight、クラッシュログを揃える。バンプボットとセット。 |
| 配布するライブラリパッケージ | いいえ（典型） | アプリ側がピン留め。CI は SwiftPM 互換のマトリクス解決。 |
| 社内マルチアプリモノレポ | はい（アプリごとのワークスペース） | 共有パッケージは未ピン、アプリはピン、の切り分けも可。 |
| バイナリ／XCFramework中心のグラフ | はい | チェックサム安定がアーティファクトキャッシュに直撃する。 |
| 実験ブランチ「常に最新」 | 任意 | ロック削除は意図的に。CI は騒がしく、リリースには載せない。 |
7. SSH ファーストパイプラインでの含意
オペレータがトリアージで SSH するとき、Runner と同じファイルシステムが見える。実務上の良い習慣は次のとおり。
- resolved JSON を手編集しない。チェックサム整合のため SwiftPM コマンドで回す。
- 対話シェル用ユーザーと自動化ユーザーを分け、個人実験が CI キャッシュを汚さないようにする。
- 「CI とノートPCが違う」調査では、ビルドログに
Package.resolvedの先頭行を出し、誤った作業ディレクトリを早期に潰す。
8. FAQ
Q1: Xcode の「Reset Package Caches」を CI で回してよい？
最後の手段として扱う。温かいキャッシュを無効化し再ダウンロードする。破損疑いには有効だが、リモート Mac 群では高コスト。特定パッケージ成果物のピンポイント削除を先に試す。
Q2: CocoaPods と SPM の両方を使う。真実はどちら？
共存する。SPM のピンは Package.resolved、Pods は Podfile.lock。アプリでは両方コミット。リリースブランチではどちらかのロック欠落を CI で失敗させるのが無難。
Q3: ボットがロック更新を自動コミットすべき？
ブランチ保護、必要なら署名付きコミット、権限の狭いトークンが揃うときだけ。それ以外は人間がロック専用 PR を押す運用でも、専用ハード上でテスト並列化できていれば十分速い。
Q4: レジストリ依存と git 依存でピン留めは違う？
解決済み識別子はどちらも記録される。キャッシュ戦略（レジストリメタデータ対 git オブジェクト）は違っても、ロックをコミットする価値は残る。
Q5: 毎回 xcodebuild -resolvePackageDependencies を回している。それでもコミット？
はい。グラフがロックと一致していれば resolvePackageDependencies は実質 no-opになり速く、意図しない依存漂移も検知できる。
SwiftPM CI にも、Apple Silicon の専用 Mac が効く理由
リゾルバとコンパイルのスループットはディスク I/O、ユニファイドメモリ帯域、安定した Xcode 設置に敏感で、Apple Silicon Mac mini 級は同価格帯の汎用 VM よりここで有利になりやすい。macOS は長期無人運用でもドライバスタックが静かで、Gatekeeper と SIP により無人 Runner の改ざんリスク説明もしやすい。待機電力が低いので、SPM を温かく保つ 24 時間運用の経済性も現実的になる。Package.resolved でグラフを固定したなら、ジョブ間で同一の再生機を揃えたいが、シングルテナントのリモート Mac の方がノイジーな共有ハイパーバイザよりやりやすい。
iOS／macOS パイプラインの SwiftPM 方針を締めるなら、コミット済みロックと相性のよい静音・低消費電力の Mac mini M4は、2026 年時点でもコストパフォーマンスの錨になりやすい。ハードの当たりを付けるには SSHMac のトップページで構成を確認し、CI イメージ凍結の前にラインアップしておくとよい。