「別のMacではビルドできるのに、キャッシュが使われた証拠がない」場合は、まずツールチェーンとビルド条件を照合してください。
結論：先にリモートMacでiOSビルドを再現可能にし、その後でBazelのリモートキャッシュを接続して、別のMacからのヒットを検証します。 キャッシュは条件の合う成果物を再利用する機能であり、リモート実行や署名検証の代わりにはなりません。
iOS向けBazelルールを保守する開発者には、ローカルの基準ビルドからリモートMac、CIへ進む順序を示します。
キャッシュの接続先を探す前に、再現性と読み書き権限を確認したいビルドエンジニア、DevOpsエンジニアにも役立ちます。
00基準ビルドの記録
まず対象プロジェクトを、開発者が普段使う環境でビルドします。ビルド、テスト、成果物の生成が同じ手順で繰り返せるかを確認し、失敗時のログも残します。最初からキャッシュを有効にすると、ビルド設定の問題とキャッシュ接続の問題を切り分けにくくなります。
Bazel本体だけでなく、rules_apple、rules_swift、選択されたXcodeとSDK、ビルド対象、コマンドライン引数を記録します。各バージョンの互換性はプロジェクトのロックファイルと採用ルールの公式資料で確認してください。rules_appleの公式リポジトリには、Appleプラットフォーム向けルールの情報がありますが、記載内容が手元のプロジェクト構成と一致するかは別途照合が必要です。
| 記録項目 | 基準ビルドで残すもの | 比較で見る点 |
|---|---|---|
| Bazelとルール | Bazel、rules_apple、rules_swiftのバージョンと固定方法 |
ローカル、リモートMac、CIで設定が揃っているか |
| Appleツールチェーン | 選択中のXcode、SDK、コマンドラインツール | 参照先や選択状態が環境間で異ならないか |
| ビルド条件 | ターゲット、設定ファイル、引数、環境変数 | キャッシュキーに関わる入力が一致しているか |
| 成果物 | ビルドログ、テスト結果、成果物の識別情報 | 後で同じターゲットを比較できるか |
設定の分岐：
- 基準ビルドが同じ条件で再現できるなら、記録した構成をリモートMacに移し、ツールチェーンの照合へ進みます。
- ビルドやテストが再現できないなら、キャッシュ設定には進まず、ルール、依存関係、ターゲット、ビルド引数の差を先に解消します。
- 失敗の原因をログで説明できないなら、キャッシュ未命中を主原因と決めつけず、基準ビルドの再調査へ戻ります。
01リモートMacのツールチェーン照合
リモートMacでは、想定したXcodeが実際に選択されているかを調べます。次のコマンドで参照先やバージョン情報を確認し、その出力を基準ビルドの記録と並べます。
xcode-select -p
xcodebuild -version
xcrun --sdk iphoneos --show-sdk-version
コマンドの役割はAppleのXcodeコマンドラインツールリファレンスで確認できます。コマンドラインツールの導入や選択状態に疑いがある場合は、Appleのインストール手順も参照してください。インストール済みであることだけで判断せず、実際の選択結果を記録します。
| 比較対象 | ローカルとリモートMacで照合する内容 | 不一致があった場合 |
|---|---|---|
| XcodeとSDK | 選択先、SDKの種類、プロジェクトの指定 | Xcodeの選択状態とプロジェクト設定を揃えて再ビルド |
| Bazelルール | 固定された依存関係と読み込まれる設定 | ロックファイル、モジュール、ワークスペース設定を確認 |
| ビルド入力 | ターゲット、フラグ、環境変数 | 実行コマンドとCI設定の差分を特定 |
| 実行結果 | ログ、テスト、成果物 | キャッシュを無効にした条件でも基準が再現するか確認 |
リモートMac単体で、先ほどと同じターゲットをビルドします。ここで失敗する場合は、キャッシュを調べる前にログを読み、Appleツールチェーンやプロジェクトの構成を修正してください。NUKCLOUDを含め、リモートMacを実行環境として検討する場合は、NUKCLOUDのサービス概要を確認し、必要なXcode環境やアクセス方法が要件に合うかを個別に確かめます。
02Bazelのキャッシュ接続と権限設定
リモートMac単体で基準ビルドが通ったら、キャッシュの接続先、認証方法、Bazel設定の適用箇所を決めます。Bazelのリモートキャッシュ公式ガイドを参照し、採用するバックエンドに必要な接続情報を設定します。たとえば設定ファイルまたは実行時のフラグでキャッシュ先を指定できますが、実際の値は利用する環境に合わせてください。
bazel build //path/to:ios_target --remote_cache=<cache-endpoint>
この例は接続設定の形を示すもので、<cache-endpoint>は実際のエンドポイントに置き換えます。読み取り、書き込みの可否は、キャッシュ側の認証設定とCIジョブの権限を合わせて確認してください。認証情報をリポジトリへ直接保存せず、ログに出力されないことも設定レビューと実行ログで検証します。
| 実行主体 | 読み取り | 書き込み | 運用上の確認 |
|---|---|---|---|
| 開発者のMac | 開発方針に応じて許可 | チームの方針に応じて制限 | 個人の認証情報と共有領域の扱い |
| CIの検証ジョブ | 必要な対象に許可 | 原則はジョブの役割に応じて設定 | 読み書き権限が意図したジョブに限られるか |
| リリースジョブ | 必要性を個別判断 | 成果物の責任範囲に応じて判断 | 署名用の秘密情報がログへ漏れないか |
キャッシュ対象にすべきでない処理や、書き込みを許可しないジョブは、プロジェクトのルールとセキュリティ方針に従って明示します。設定ファイルを開発者とCIで共有する場合も、秘密情報を含む接続情報は別に管理し、誰が読み書きできるのかをレビュー可能な形で残します。
03別のMacでのキャッシュヒット検証
最初のMacで対象をビルドしてキャッシュへ書き込み、別のMacから同じコード、ツールチェーン、引数で同じターゲットを実行します。ビルドが成功しただけでは、キャッシュが読み込まれた証拠になりません。Bazelの実行ログでリモートキャッシュの読み取りやヒットを確認し、結果を保存してください。
ヒットしない場合は、両方のMacについて、選択中のXcodeとSDK、Bazel設定、ルール、ビルド引数、環境変数を比較します。続いて認証、ネットワーク接続、キャッシュの接続先を確認し、修正した項目を記録して同じ手順を再実行します。Bazelのキャッシュヒット調査資料も参照できます。結果を確認できないまま、キャッシュの効果や性能改善を主張するのは避けてください。
- [ ] 最初のMacで、記録済みのターゲットをビルドした。
- [ ] ログでキャッシュへの書き込みを確認した。
- [ ] 別のMacで同一のコードとビルド条件を使った。
- [ ] 別のMacのログでキャッシュ読み取りまたはヒットを確認した。
- [ ] ヒットしない場合、差分と修正後の再実行結果を保存した。
04キャッシュ、リモート実行、署名の切り分け
リモートキャッシュは、条件が一致した構築結果を再利用します。一方、リモート実行はビルド処理を遠隔の実行環境で動かす仕組みです。Bazelもこれらを別の機能として説明しており、リモート実行の概要では実行基盤側の構成や前提を扱っています。キャッシュヒットはリモート実行の証拠ではなく、ローカル実行がキャッシュ結果を利用する場合もあります。
Appleツールチェーンを伴う処理をリモート実行する場合は、利用するBazelの構成とrules_appleが示す要件を確認し、実際のプロジェクトで対象アクションを検証します。リモートキャッシュを使えることだけから、すべてのApple関連アクションが遠隔実行できるとは判断できません。
署名と最終パッケージングは、キャッシュの読み書きや遠隔アクションの成功とは別のリリース判定にします。プロジェクトで使用する証明書、プロビジョニング設定、Keychain、生成物を実際の配布条件で確認してください。Appleの署名資料を参照する際は、配布用に署名されたMacコードの作成手順がMac向けの説明である点に留意し、iOSアプリの署名手順そのものとして流用しないでください。
05CIへの段階導入と運用判断
開発者のMacとCIで、同じBazel設定とツールチェーンを参照できる状態にします。CIの実行主体ごとに、キャッシュの読み取り・書き込み権限とログへの秘密情報の露出を確認します。そのうえで実際のiOSプロジェクトについてビルド、テスト、最終成果物を再検証してください。
導入範囲は、次の条件で判断できます。
- キャッシュヒットをログで確認でき、別のMacでも成果物とテスト結果が一致するなら、限定したジョブで試行を続けます。
- 開発者のMacでは読める一方、CIでは認証エラーになるなら、実行主体の権限と資格情報の管理を修正してから再判定します。
- キャッシュが利用できなくても、ビルドが安全に失敗または回復し、手順をログで追えるなら、運用上の回退経路を定めます。
- 署名や最終成果物を検証できない場合は、キャッシュの成否にかかわらずリリース判定を保留します。
BazelとAppleルールの公式資料をプロジェクトの固定バージョンに照らし、構成変更があれば再確認します。長期運用を見据えてAppleツールチェーン用の実行環境を比較する場合は、NUKCLOUDのリモートMac環境も候補の一つとして要件を照合できます。
06よくある疑問
BazelのiOSプロジェクトにリモートキャッシュをつなぐ順番は？
基準となるビルドを記録し、リモートMacで同じ条件を再現してから接続します。その後、書き込みを確認したMacとは別のMacから読み取りを試し、ログにヒットが出ることを確かめます。
キャッシュとリモート実行は同じ機能ですか？
異なります。キャッシュは適合する結果の再利用、リモート実行はビルド処理の実行場所を遠隔にする機能です。ログと実際の実行環境を個別に確認してください。
Macごとにキャッシュ結果が変わるときの確認箇所は？
Xcode、SDK、ルール、ターゲット、引数、環境変数を比較してから、認証、通信経路、キャッシュ先を調べます。修正後は条件を揃えた同じターゲットで再検証します。
署名やアプリの最終パッケージングも遠隔実行に含めるべきですか？
自動的に含める前提にはしません。採用する実行環境で必要なAppleツールチェーンと秘密情報の扱いを確認し、署名と最終成果物は独立した受け入れ条件で検証します。
現在のビルド環境が、ツールチェーンの差、CI認証の管理、キャッシュ障害時の回復で運用負荷を抱えているなら、Macを都度購入して固定する方法だけでなく、遠隔Macを使う選択肢も比較できます。一方、継続的な高負荷や物理インターフェースへの接続が欠かせない環境では、自社保有のMacが適する場合もあります。まず実プロジェクトで要件を確かめ、継続稼働するAppleツールチェーン用ノードが必要なら、NUKCLOUDのリモートMac環境を候補として検討してください。