ビルド時間が安定せず、Macノードを増やすか共有キャッシュを作るかで判断が止まっている。
最短解は、Bazel 9のリモートキャッシュを全社で有効化せず、固定したMac基準プールと読み取り専用キャッシュで同一コミットを比較することです。アクションが再現可能で、複数ノードで同じ処理が繰り返され、転送失敗も管理できる場合だけ本番導入へ進みます。
読者が先に見る判断表
この判断は、単一のビルド時間ではなく、アクションの再利用性、待ち行列、ネットワーク、セキュリティを合わせて行います。リモートキャッシュはBazelのアクション出力を共有する仕組みであり、Xcode、シミュレーター、署名処理をMac以外のノードで実行する機能ではありません。詳しい対象と保存単位はBazel公式のリモートキャッシュ仕様で確認できます。
| 観測された状態 | 先に選ぶ案 | 判断の理由 |
|---|---|---|
| 同じアクションが複数のMacで繰り返され、環境差も管理できている | 読み取り専用キャッシュの試験 | 既存成果物の再利用を安全に確認できます |
| キャッシュ取得よりも待ち行列や署名処理が支配的 | Macビルドノードの拡張 | キャッシュでは実行待ちやApple固有処理を消せません |
| 絶対パス、環境変数、外部ツールの差が大きい | 導入を延期し、再現性を修正 | 誤った再利用や恒常的なミスを避ける必要があります |
| 転送失敗、認証エラー、保存領域の増加を監査できない | 本番導入を見送る | 速度よりも復旧性と供給網の管理が優先されます |
| 読み取り試験で効果があり、書き込み対象を限定できる | 制御付き書き込みへ進む | 書き込み元を絞って汚染範囲を管理できます |
誰がこの判断を使うべきか
大型iOSプロジェクトをBazelで構築し、重複コンパイルを減らしたい開発生産性の責任者向けです。Bazel 9のリモートキャッシュ導入を、単なる高速化ではなく基盤投資として評価したいIT・FinOps責任者にも適しています。
キャッシュへの書き込み権限、成果物の分離、異常時の隔離を設計するセキュリティ担当者やプラットフォーム担当者も対象です。
指標の収集と再現性
先に集める運用指標
試験前に、代表的な同一コミットを使って次の記録を取ります。
- キャッシュなし、読み取り専用、書き込み可能の各条件でのアクション数
- リモートヒット、ローカルヒット、ミスの内訳
- キャッシュ成果物の取得時間と送信時間
- 転送失敗、認証失敗、再試行、タイムアウトの記録
- 待ち行列の長さ、クリーンビルドの頻度、Macノード間で重なるタスク
- キャッシュオブジェクトの増加、削除、再構築に要した作業
rules_appleで起きる互換性のずれ
rules_appleやrules_swiftの組み合わせが同じでも、実際に本番で使えるとは限りません。Bazel 9、各ルールセット、Xcode、SDK、macOS、Swiftツールチェーンの組み合わせを固定し、公式リポジトリの[サポート情報](https://github.com/bazelbuild/rules_apple)と[rules_swiftのツールチェーン情報](https://github.com/bazelbuild/rules_swift)を確認します。
Bazel 9.1.0の変更点は、公式リリースノートで個別に確認してください。リリースノートに記載があることは、あなたの全ターゲット、署名方式、プラグイン構成が本番で安定することを意味しません。
| 組み合わせの状態 | 扱い | 本番承認に必要な証拠 |
|---|---|---|
| 公式リリースとサポート情報で対象範囲が確認できる | 公式確認済み | 同一コミットの再現ビルドと成果物比較 |
| 公式範囲内だが、社内の依存関係をまだ検証していない | チーム検証中 | CIログ、失敗再現、複数Macでの一致 |
| 開発ブランチ、未マージ修正、プレビュー版に依存する | 隔離試験 | 期限付きの検証計画と明確な撤回手順 |
| XcodeやSDKがノードごとに異なる | キャッシュ利用を停止 | イメージ、パス、署名環境の統一 |
Apple側のXcodeとOS要件も、Apple公式のシステム要件で確認します。キャッシュ設定だけを先に変更し、XcodeやSDKの差分を後から追いかける運用は避けてください。
キャッシュ効果とMac容量
iOSビルドをどこまで速くできるか
Bazel 9のリモートキャッシュで得られる効果は、プロジェクト全体に一律に適用されるものではありません。再利用できるコンパイルや生成アクションが多いほど有利ですが、クリーンビルド、署名、アーカイブ、シミュレーター実行、機密ターゲットは別の容量として残ります。
そのため、企業iOS CIでは「キャッシュ導入後の総時間」ではなく、次の差分を見ます。
- 再利用できたアクションの割合
- 取得時間を含めた実効時間
- キャッシュが使えない場合の実行時間
- Macノードの待ち時間が減ったか
- 署名、アーカイブ、テストの処理が詰まっていないか
キャッシュとMac追加の費用項目
TCOは、キャッシュの保存領域だけで計算できません。次の変数を分けて、社内の単価を入れます。
- キャッシュ基盤の構築・監視・保存・削除費用
- Macノードのレンタルまたは購入費、保守、交換、設置
- XcodeやSDKの更新、証明書更新、障害対応に要する工数
- 転送量、バックアップ、ログ保管、監査の費用
- キュー待ちによる開発遅延とリリース機会損失
権限と成果物の安全境界
ノード種別ごとのアクセス方針
全開発機に共有キャッシュへの書き込みを許可する設計は避けます。開発者端末の依存関係や未承認ツールが成果物へ影響し、異常が起きた際に、どのノードが書き込んだか追跡できなくなるためです。
| ノード種別 | 主な処理 | キャッシュ権限 | 監査と異常時の対応 |
|---|---|---|---|
| 固定Macの検証ノード | 再現ビルド、依存関係確認 | 読み取り中心、承認後のみ書き込み | コミット、ツールチェーン、実行者を記録 |
| 本番CIのビルドノード | 通常ビルド、テスト | 制御付き読み書き | 署名付きログを保存し、異常時は資格情報を無効化 |
| 開発者のMac | 個別開発、試行的変更 | 原則読み取りのみ | 未検証成果物を本番ターゲットへ使わない |
| 署名専用ノード | アーカイブ、署名、公開準備 | キャッシュ対象外または限定読み取り | 証明書、秘密鍵、成果物経路を分離 |
| 障害調査用ノード | 再現、隔離、復旧 | 一時的な読み取り | 調査終了後にアクセスを削除し、再利用を停止 |
リモートキャッシュの汚染を疑った場合は、原因調査を優先して成果物を使い続けるのではなく、該当キーの利用停止、書き込み元の隔離、クリーン環境での再生成、無キャッシュとの比較を順に実施してください。
生成物の汚染を検証する方法
同一コミット、同じMac構成、同じXcodeとSDKを使い、キャッシュなしの成果物とキャッシュ利用後の成果物を比較します。比較対象はビルド成功だけではなく、アーカイブ、署名、テスト結果、依存バイナリ、生成されたメタデータです。
書き込みノードを一時的に限定し、読み取り専用のジョブが同じ成果物を取得できるか確認します。差分が出た場合は、キャッシュを全消去する前に、キー、アクション入力、書き込み元、ツールチェーン、ログの相関を保存してください。
A/B試験と本番承認
3条件を同一コミットで比較する
試験は同じ提出物と同じMac構成で実施します。無キャッシュ、読み取り専用キャッシュ、制御付き読み書きキャッシュを分け、ジョブの並列度や依存関係を変えないことが重要です。
記録には、アクション数、ヒットとミス、取得・送信時間、転送失敗、キュー待ち、成果物差分、復旧時間を含めます。単発の成功例ではなく、クリーンビルドと反復ビルド、通常時とキャッシュ障害時の両方を比較します。
条件分岐で投資先を決める
- 再現性が確認でき、反復アクションのヒットが安定し、取得時間と障害対応も許容範囲なら、対象ターゲットを限定して本番化します。
- ヒットは得られるものの、特定のXcode、SDK、外部ツールでミスが続くなら、環境固定とルールセットの検証後に再試験します。
- キャッシュを使っても署名、シミュレーター、アーカイブ、キュー待ちが支配的なら、キャッシュへの追加投資を止めてMac容量を増やします。
- 書き込み元を特定できず、汚染時の隔離や再構築を実演できないなら、読み取り専用に戻します。
- 障害時にキャッシュなしで継続できず、復旧手順も検証できないなら、全量導入を承認しません。
現行構成と遠隔Macの使い分け
すでに手元のMacだけで運用している場合、ピーク時のキュー、ノードごとの環境差、保守・交換の負担が見えにくくなります。そこへキャッシュを足しても、署名専用処理やシミュレーターの実行枠、隔離試験用の余力までは増えません。
A/B試験後に、キャッシュ未適用タスク、署名処理、ピークキューを実測して必要なMac容量へ換算してください。既存ノードだけでは隔離試験や短期のピーク対応が難しい場合は、MACGPUの遠隔Macを基準ノードまたは一時的なビルドプールとして比較する価値があります。長期にわたり同じ高負荷を処理し、物理接続や固定設備が必要なら自社保有が適しますが、試験環境や期間限定の増強では、周期契約のほうが判断を戻しやすい場合があります。