2026年 越境チーム CI の Git チェックアウトはどう選ぶ？partial clone・blobless・フルクローン：マルチリージョン物理 Mac における checkout 尾部遅延と一貫性リスクの意思決定マトリクス（コピペ git＋FAQ）
複数国に物理 Mac プールを置くプラットフォーム／モバイルリリースチームは、ディスク節約で blobless や partial を使いがちですが、コンパイル途中に blob が届いてジョブが不安定になるケースもあります。本稿では クローンモードの意思決定マトリクス、七ステップ Runbook、コピペ可能な git 断片、引用しやすい閾値、FAQ をまとめます。Runner プール設計は GitHub Actions セルフホスト macOS Runner と短命 CI／CD（2026）、成果物の扱いは XCTest 分片とマルチリージョン物理 Mac の Artifact／Runner 閾値 と併せて読むと通しで設計しやすくなります。
1. はじめに
セルフホスト macOS Runner において「clone」は単一コストではなく、fetch 時間、checkout の I/O、サブモジュール再帰、LFS の smudge、そして partial／blobless 時の promisor 経由のオンデマンド取得の合算です。越境チームは RTT、ピアリング差、オブジェクト保管とビルド実行の コンプライアンス境界が加わります。
本稿は フルクローン、blobless（--filter=blob:none）、ツリー単位 partial（--filter=tree:0）、浅い履歴、sparse checkout を、checkout の尾部遅延（p95／p99）と一貫性リスク（blob 取得失敗・LFS のずれ・サブモジュールのドリフト）の二軸で比較します。
2. 痛みの分解
- 制約：ディスク予算と実作業ツリー。短命 CI は小さいディスクを好みますが、iOS／macOS モノレポは巨大な履歴を要求します。blobless や sparse は初期バイトを減らす代わりに後工程へ負荷を送り、尾部遅延を悪化させがちです。
- 隠れコスト：オンデマンドの blob／tree 取得。冷えた
xcodebuildやコード生成が大量パスに触れると、blob:noneやtree:0ではビルド中にリモートへ再度問い合わせることがあります。事前フェッチで潰すのが定石です。 - 安定性と一貫性：LFS・サブモジュール・浅い履歴。
GIT_LFS_SKIP_SMUDGE=1は clone を速くしますが、コンパイルが実体ファイルを前提としていると地雷になります。浅い clone はdescribeや merge-base 系スクリプトを壊し得ます。マルチリージョンでは同じレシピを全ノードに適用することが重要です。
3. クローンモード意思決定マトリクス
地理とは独立に戦略を比較し、次節でリージョン上乗せを足します。
| モード | 初期 fetch | checkout／ビルド尾部 | 一貫性メモ |
|---|---|---|---|
| フルクローン | ディスク・帯域最大 | 驚きは少ない—多くの blob がローカル | エアギャップ、全ツールチェーン、長寿命ウォーム Runner に向く |
Blobless blob:none |
初期 pack が小さい | 欠損 blob の取得が負荷下で刺さる尾部リスク | コミット同一性は不変。運用リスクのみ |
Partial tree:0 |
メタ取得が最小 | 作業セットが広いとオンデマンド tree／blob が増える | sparse や積極的 prefetch とセットが無難 |
浅い --depth |
線形履歴では速い | 一部のマージ／バージョンスクリプトを壊す | 全グラフや深いタグが要る場合は避ける |
| Sparse ＋ blobless | 巨大リポでツリーが小さい | cone パスがビルドと一致すればバイト最小 | ジョブ種別ごとのパス一覧のメンテが主リスク |
4. マルチリージョン物理 Mac の上乗せ
米／欧／アジアなどに置いた物理 Mac プールは uplink が揃いません。オブジェクト取得を遅延させる戦略ほど、越境 RTT と パケットロス が増幅器になります。
| シグナル | 向く構成 | 注意 |
|---|---|---|
| オリジンへの RTT が高い | 地域別ベア Git ミラー、長寿命ウォームクローン、ローカル SSD へのフルクローン | ミラーなしの raw tree:0—promisor 遅延が最悪リンクに引きずられる |
| ジョブごとに短命 Runner | blobless ＋明示 prefetch、または浅い作業ツリーの tarball キャッシュ | コンパイルが欠損 blob に触れないと仮定すること |
| 厳格な変更監査 | 不変成果物＋リージョン横断で同一 SHA（XCTest 記事の成果物戦略参照） | リージョンごとに git fetch の深さだけが違う運用 |
5. コピペ git 断片
5.1 Blobless（promisor）
git -C "$WORK" checkout --force "$SHA"
5.2 tree:0 ＋ cone sparse（モノレポ）
git -C "$WORK" sparse-checkout init --cone
git -C "$WORK" sparse-checkout set apps/ios Tools/Scripts
git -C "$WORK" checkout "$SHA"
5.3 長寿命 Runner：clone 後の prefetch
git -C "$WORK" lfs install --local
GIT_LFS_SKIP_SMUDGE=0 git -C "$WORK" lfs pull --include="*.png,*.a,*.zip"
include は資産クラスに合わせて調整してください。メタデータのみの clone では GIT_LFS_SKIP_SMUDGE=1 とし、後段で対象 git lfs pull を当てます。
6. 七ステップ Runbook（物理 Mac CI）
- 負荷を分類。モノレポパス、LFS 量、サブモジュール深さ、履歴全体が要るかをパイプライン単位にマッピングします。
- 第 3 節でモードを選ぶ。多くの iOS チームの既定は巨大リポなら blobless＋sparse、小リポや署名ホストは フル。
- ミラーを配置。各 Mac プール近傍に読み取り専用 org ミラーを立て、CI の
url.*.insteadOfで最寄りに寄せます。 - fetch とコンパイルを分離。計時した「マテリアライズ」段で
git fetch、submodule update --init、lfs pullを実行し、Xcode 前に失敗させます。 - 尾部を計測。clone＋checkout 秒、LFS バイト、promisor 取得回数を
region=ラベル付きで出します。 - ディスク保守。週次で
git maintenance run --autoや時間枠 gc。APFS 空き容量が逼迫すると失敗率が跳ねます。 - フォールバックを文書化。promisor や LFS が劣化したときにフルミラーへ昇格するワンコマンドを残します。
7. 引用用閾値
SLO に合わせて調整する出発点です。
- マテリアライズ SLO：長寿命 Runner では clone＋checkout＋当該ジョブの LFS を含む p95 が 120 秒未満。短命かつローカルミラーがある冷起動は 300 秒未満を目安に。
- 尾部アラート：あるリージョンで p99 checkout が p95 の 2 倍超が 2 日連続ならミラー健全性か promisor 嵐を疑う。
- ディスク：CI ボリュームは空き 15% 超を維持。blobless でもメンテ前は loose object で膨らみます。
8. FAQ
blobless と partial clone の違いは？
blob:none はファイル blob を遅延取得します。tree:0 はツリーも遅延し初期 fetch は最小ですが、作業セットが広いと遅延トラフィックが最大になります。
blob:none は CI の再現性を壊す？
コミット SHA は変わりません。欠損 blob 取得がビルド中に失敗するのが運用リスクです。prefetch、ミラー、ゴールドマスター用はフルクローンへ。
Git LFS は blobless とどう組み合わせる？
第二のマテリアライズ段階として扱います。clone で smudge を飛ばし、コンパイル前に明示的 git lfs pull すれば、越境 RTT を一度にまとめられます。
フルクローンが正解なのはどんなとき？
エアギャップ Runner、ツリー全体を走査するジョブ、厳格オフライン方針の署名／リリース機、promisor を信頼できない場合などです。
9. 無人 CI に Mac mini を選ぶ理由
高速 SSD、安定した APFS、ネイティブの Git／Xcode ツールチェーン、そして低い待機電力—これらは Apple Silicon Mac mini がマルチリージョンプールで採られやすい理由です。ノート再利用機より、デスクトップ Mac mini は長時間の git とコンパイルに熱余裕があり、調整すれば待機電力は数 W 程度に抑えやすく、macOS のパッチ計画も Xcode と揃えやすいです。
セキュリティ：Gatekeeper・SIP・FileVault により、安易な PC Runner より改ざんリスクを下げられます。TCO：小型筐体はコロケーションや拠点常設の輸送コストも抑えやすいです。
checkout 尾部を予測可能に保ちたいなら、Mac mini M4 は実務的な土台になります。本稿のマトリクスとミラー設計を組み合わせ、リージョンごとに同一レシピでプールを増やせます。
物理 Mac CI をグローバルに標準化する準備ができたら、ZoneMac の Mac mini ラインアップで構成を確認し、この checkout 戦略をすぐ載せ替えられます。
マルチリージョン Mac CI を安定運用
Git・Xcode・自動化向けにサイズした物理 Mac mini を、単一契約で利用できます。