想定読者：APAC と米国など複数リージョンでリモート Mac 上の CI を回しており、すでにGit と Docker レジストリの再試行 Runbookを適用したあとも、コンパイル開始前にオブジェクトデータベースの転送とフルモノレポのマトリクスで分を消費しているチームです。成果：リンク調整は再試行 Runbook に残しつつ、部分クローン（blobless／treeless）、スパースチェックアウト、変更検知で作業ツリーとビルドグラフを縮め、M4／M4 Pro の分をコンパイラ側へ寄せます。構成：典型的な誤読六つ、戦略マトリクス、コマンド断片、六段階 Runbook、ダッシュボード向けの硬い指標三つ、締めの運用指針です。
Apple Silicon は計算の天井を押し上げますが、モノレポではしばしばオブジェクトの実体化とワークスペースのインデックス化がボトルネックになります。単一ジョブが巨大なコミットグラフを取得し、数千ディレクトリを展開したうえで、既定では全体を走査するビルドツールへ渡る、という流れです。地域間のリンク調整は転送の尾部を短くしますが、そもそも不要だったオブジェクトの無駄までは消せません。本節では本番トリアージで繰り返し見る誤読を六つに整理します。
--depth=1 を万能視する：浅い履歴は助けになりますが、既定パスではツリーと巨大 blobが作業ツリーに入り得ます。ビルドの入口がリポジトリ全体を歩くなら、無関係な設定解析で CPU が遊びます。--filter=blob:none（blobless）と--filter=tree:0（treeless）は、チェックアウト、スパースのコーン、Git LFS との相互作用が異なります。オンデマンド取得の挙動を文書化せずに混在させると、リモートビルダーに隠れたオンデマンド取得のスパイクが出ます。.git を見ない：1TB／2TB 級のホストでも、.git の肥大化と層状のキャッシュで、コンパイル前にディスクが尽きます。閾値はマルチリージョンのレンタルガイドと同じストレージレビューに結び付けてください。これらの制御はセルフホストランナーのガイドと組み合わせます。ランナーはどのマシンがジョブを受けるかを決め、再試行 Runbook は pull を安定させ、本稿はどれだけ取得し何をコンパイルするかを決めます。三つを同一レビューパケットで出荷してください。
リポジトリの形、オンデマンド取得への耐性、オフライン再現性の要件から、パイプライン設計レビューでコマンドを選びます。個人の慣れではなく、これらの制約を優先してください。
| 戦略 | 向いているケース | 主な利点 | リスク／コスト |
|---|---|---|---|
| フルクローン＋フルツリー | 小さめのリポジトリ、厳格なオフライン再現、初回監査 | 挙動が最も単純で、トリアージ経路が短い | 巨大モノレポではオブジェクト転送とワークスペース IO が地域横断で重い |
Blobless（--filter=blob:none） | 深い履歴が要るが CI は現在のツリー中心 | 初期 blob ダウンロードを大きく削減し、浅いクローンと相性が良い | チェックアウト／ビルド中のオンデマンド blob 取得。取得率を監視する |
Treeless（--filter=tree:0） | 極端に大きいツリー、単一コミット視点 | ツリー実体化を先送りできる | ツールチェーン互換の検証が要る。トリアージの複雑さが上がる |
| スパースチェックアウト（コーン） | サブツリーの境界が明確なマルチアプリリポジトリ | ワークスペース IO とインデックス負荷を下げ、コーン違いの並列ジョブが可能 | コーン誤設定はファイル欠落を静かに招く。コーンをバージョンしレビューする |
| 変更検知＋最小マトリクス | npm／yarn／pnpm、Gradle、Bazel 風のグラフ | 影響閉包にコンパイルグラフを限定できる | パスマップとベースライン規則の維持。取りこぼしはカナリアビルドで捕捉する |
パスは自社のモノレポのルートに置き換えてください。treeless は単一ジョブでカナリアしてからフリートへ展開します。オンデマンド取得の尾部を抑えるため、地域横断 Runbook の GIT_HTTP_LOW_SPEED_* は維持してください。
# 1) Blobless + shallow + single branch (common CI baseline)
git clone --filter=blob:none --depth=1 --single-branch \
--branch "${BRANCH}" "https://example.com/org/monorepo.git" repo
cd repo
# 2) Sparse cone: store the list in git and require CODEOWNERS review
git sparse-checkout init --cone
git sparse-checkout set apps/ios libs/shared-contracts
# 3) Change detection sketch (implement via git diff, path prefixes, or tooling)
# BASE_SHA=$(git merge-base origin/main HEAD)
# git diff --name-only "$BASE_SHA"..HEAD | awk -F/ '{print $1"/"$2}' | sort -u
# 4) Avoid: enabling treeless globally without Xcode/SwiftPM canary jobs
注意：部分クローンとスパースのコーンを併用したあと、LFS ポインタや大きなバイナリがコーン外に残ることがあります。リソースパスをコーンに足すか成果物キャッシュを使わないと、後段で「ファイル欠落」に見える不安定な失敗が出ます。
シークレットとランナーラベルはすでに分離されている前提です。キャッシュボリュームと .git の権限が分かれていない場合は、先にランナーガイドと再現ビルドのガイドで整えてください。
~/.gitconfig にだけ魔法の引数を置くことを禁止します。.git、ビルドキャッシュ、DerivedData を別々にアラートし、コーンが異なる複数ジョブが同一ワークスペースを共有しないようにします。再試行 Runbook のリンク KPI の横に置き、取得の安定性とワークスペース肥大を切り分けられます。
現場メモ（オーダー・オブ・マグニチュードでありベンチマークではありません）：2025〜2026 年、パスが数万規模のモノレポでは、コンパイル前にワークスペース展開だけで十分単位を要することがあります。レビュー済みのスパースコーンと影響マトリクスを揃えると、同一ハードウェアでも壁時計のうちコンパイラが占める割合が上がりやすいです。したがってレンタルの経済性は CPU 層だけでなくチェックアウト方針も含めて評価してください。
ビルダーを Git のホームリージョンから恒久的に遠ざけるチームは、帯域だけでは構造的な無駄を解消しにくいです。リンク調整とコーン／検知の方針を揃えることは、主要リポジトリに macOS CI を寄せる組織の動きと一致します。夜間の「ランナーを再起動」ループを避けるため、運用マニュアルの同じ章に両方の軌道を書いてください。
レビューのたびに「とりあえずフルビルドで様子を見る」に戻ると、スパースと検知の投資が帳簿に現れません。ダッシュボードの三指標を四半期目標に結び、コーン変更と検知ルール変更を同一変更管理に載せると、リージョン移動やディスク拡張の判断が静かになります。オンデマンド取得が許容範囲を超えたら、まずコーンとスクリプトの走査範囲を疑い、帯域やマシン台数は二次です。
個人用スクリプトと単発ホストには、コーン変更の監査、キャッシュ契約、マルチリージョンでの一貫性がありません。エンジニア A のスパース設定はローカルでは通る一方、エンジニア B のクリーン CI は失敗します。リージョンを動かすと取得経路とディスク閾値が無効化されます。本番級の Apple Silicon CI には、専用ベアメタル、グローバルなリージョン選択、ベースとバーストのレンタル組み合わせが必要で、Git 方針、チェックアウト方針、コストを一枚に載せるべきです。
エグレスとディスクのヘッドルームが読めない断片化ベンダーは、チームを「フルビルドにマシンを足す」方向へ押しやすいです。再現可能なディレクトリ境界、リージョン横の水平拡張、本番に近い CI のシークレットモデルが要るチームは、短期ホストのローテーションよりプロフェッショナルな Mac クラウドに落ち着きやすいです。MACCOMEはシンガポール、日本、韓国、香港、米国東部、米国西部でMac mini M4／M4 Proのベアメタルノードを柔軟な条件で提供し、ビルダーを主要リポジトリとコーン戦略に沿わせられます。公開のレンタル料金から始め、各地域ページで確定してください。
パイロット案：主要リポジトリのリージョンに揃えたビルダーを短期レンタルし、本 Runbook を二周レビューしてから月次／四半期や 2TB 移行を決めます。「安いリージョン＋フルモノレポチェックアウト」による長期請求を避けてください。
FAQ
Git／レジストリの再試行 Runbook との境界は？
再試行 Runbook はリンクパラメータを、本稿はオブジェクト量とワークスペースの範囲を担当します。取得は安定しているのに遅いなら、まず本マトリクスを開いてください。発注前にレンタル料金を確認し、必要ならヘルプセンターで運用フローをたどってください。
スパースチェックアウトと変更検知、どちらを先にしますか？
多くの場合は両方です。スパースはマシンあたりの負荷を下げ、検知はマトリクスを縮めます。コーンがまだバージョン管理されていないなら、まず影響ビルドを締め、欠落パスによる静かな失敗を避けます。詳細はヘルプセンターも参照してください。
treeless は本番に載せられますか？
非リリースブランチでカナリアし、オンデマンド取得の挙動をログに残し、Xcode／SwiftPM の検証と組み合わせてからフリートへ展開してください。条件整理はレンタル料金ページと併せて確認すると、ディスクと期間の見積りが揃いやすいです。