Jenkins公式は、ビルドノードのexecutorについて「1ノードにつき1つ」が最も安全な構成だと説明しています。これは初期値を決める材料にはなりますが、実際のiOSビルド容量を保証する数字ではありません。したがって、Jenkins Macビルドノード受入検査では、Agentが接続できて単発ビルドが成功しただけでは本番投入を承認しないことが重要です。接続とスケジューリング、ツールチェーン、署名資産の分離、並行実行、再起動復旧、実負荷容量の6領域を、実プロジェクトのログで確認してください。(jenkins.io)
判定：本番リリース用途に適しています。 ただし、単なる「オンライン表示」ではなく、失敗時の証跡と復旧手順まで確認できる場合に限ります。
対象となる担当者
Jenkinsで新しいApple Siliconノードを追加し、本番准入の基準を作るプラットフォームエンジニア向けです。
遠隔Macの権限、安全性、オンライン状態、再起動後の復旧を確認する企業IT担当者にも適しています。
また、現在のノード数でチームのビルド並行数とリリース時間帯を支えられるか判断する開発生産性責任者にも役立ちます。
001. 「オンライン」を本番利用可能と誤認しない
受入検査の最初に、判定を3段階へ分けます。
- 接続成功：Jenkins ControllerからAgentへ接続でき、ノードがオンラインになる。
- 検証ビルド成功：実際のリポジトリを取得し、対象のXcodeと依存関係でビルドできる。
- 本番利用可能：署名、並行実行、容量、再起動後の復旧まで、定めたサービス目標を満たす。
特に危険なのは、ノード画面がオンラインでも、正式なリリース用ジョブだけが失敗する状態です。原因は、誤ったラベル、異なるCPUアーキテクチャ、未設定の証明書、キャッシュの汚染、ログイン後にしか利用できないキーチェーンなど、接続状態からは見えない領域にあります。
受入記録には、次の項目を必ず残します。
| 記録項目 | 残す内容 |
|---|---|
| 対象 | ノード名、ラベル、Agent接続方式、担当者 |
| 実行動作 | 実行したPipeline、ブランチ、署名方式、並行数 |
| 合格条件 | チームのSLO、許容待ち時間、許容失敗条件 |
| 原始証跡 | Jenkinsログ、xcodebuildログ、設定エクスポート、監視記録 |
| 失敗処置 | 即時停止、限流、設定修正、再検査、代替ノードへの切替 |
サンプルプロジェクトだけで合格にしてはいけません。実際の依存ライブラリ、証明書、テスト対象、成果物転送を含むチームのPipelineを使う必要があります。
012. Agent、ラベル、調度規則を検査する
Jenkins Agent上でiOSジョブを実行するには、ノードに能力を示すラベルを付け、Pipeline側で対象を明示します。Declarative Pipelineでは、agent { label 'mac-apple-silicon' }のようにラベル条件を指定できます。ラベルはOSやハードウェアなどの条件でジョブを振り分けるための仕組みです。(jenkins.io)
JenkinsでiOSジョブをMacノードへ固定する検査ポイントは、設定画面だけでなく、実行ログで確認します。
- [ ] Mac Agentに、CPUアーキテクチャ、macOS、Xcode系統を示すラベルが付いている
- [ ] iOSのビルドStageに、対象Macラベルを明示している
- [ ] ラベルに一致しないLinuxや別アーキテクチャのノードへジョブが流れない
- [ ] ラベル設定をエクスポートし、レビュー可能な形で保管している
- [ ] Agent切断後に再接続する仕組みと、再接続失敗時の通知を確認している
- [ ] ノードの空きディスク、テンポラリ領域、時刻同期、応答状態を監視している
- [ ] Jenkins Controller自身のexecutorを無効化し、正式なビルドを担当させていない
Jenkins公式は、Controllerを管理と調整に集中させ、ビルドはAgentで実行する構成を推奨しています。Controllerのexecutorを0にすることで、ビルド処理による資源競合を避けやすくなります。(jenkins.io)
023. Xcodeと依存環境の漂移を実ビルドで確認する
xcodebuild -versionが想定どおりでも、受入検査が完了したとはいえません。Xcodeの選択状態、Command Line Tools、SDK、Swift Package、外部依存、ビルドスクリプト、環境変数を、実際のプロジェクトで検証します。
最低でも、次の3条件を比較してください。
- クリーンな作業領域での初回ビルド。
- キャッシュを利用した通常ビルド。
- DerivedDataや依存キャッシュを消去した後の再ビルド。
3条件の差が大きい場合、ノード固有のキャッシュや作業領域へ依存している可能性があります。ログには、使用したXcodeの選択結果、依存関係のロックファイル、署名方式、成果物の保存先を含めます。
ツールチェーンの更新手順も受入対象です。誰がXcode更新を承認するのか、旧環境をどの期間並行保持するのか、更新後に失敗した場合どのAgentへ戻すのかを文書化します。Appleの証明書とProvisioning Profileは、アプリの開発、配布、App Store提出などで用途が異なるため、単にファイルが存在するだけでは十分ではありません。(developer.apple.com)
Xcodeのバージョン文字列だけを証跡にすると、SDK選択、依存解決、署名、アーカイブ作成のどこで差異が出たのか追跡できません。受入時には、成功した成果物と完全な
xcodebuildログを同じ検査記録へ紐付けます。
034. 署名資産とリポジトリ資格情報を分離する
iOS CI/CDでは、コード取得用のSSH鍵、Apple証明書、Provisioning Profile、App Store Connect関連の秘密情報を同じ権限範囲で扱わないことが重要です。JenkinsのCredentialsは、Controller上で暗号化して保管され、Pipelineでは識別子を通じて利用できますが、設定範囲が広すぎれば不要なジョブから参照される危険があります。(jenkins.io)
受入時には、意図的に低権限のテストジョブを用意します。
- [ ] 一般的なプルリクエスト検証ジョブが配布用証明書を取得できない
- [ ] プロジェクトAのジョブがプロジェクトBの資格情報を参照できない
- [ ] 秘密情報がコンソールログ、失敗ログ、アーカイブへ出力されない
- [ ] 一時的に作成したキーチェーンがジョブ終了後に削除される
- [ ] キーチェーンのロック解除が、必要なStageとユーザーだけに限定されている
- [ ] ビルド用Agentと本番配布用Agentの利用範囲を分けている
- [ ] 証明書の失効、更新、漏えい時の交換手順がある
Appleは、配布証明書や認証情報を組織外へ共有しないよう案内しています。複数のプロジェクトや委託先が同じMacを利用し、適切な隔離を実現できない場合は、Agentを分けるだけでなく、独立したMacホストへ分離する判断が必要です。(developer.apple.com)
045. 複数のiOS Pipelineを同じAgentで動かせるか確認する
複数のiOS Pipelineで1台のJenkins Mac Agentを共有することは可能ですが、executorを増やせば比例して処理能力が増えるわけではありません。Jenkins公式も、executor数はCPU、メモリ、I/O、ネットワークなどの実負荷を見て決めるべきで、1ノード1executorを安全な出発点としています。(jenkins.io)
受入検査では、チームの高負荷時間帯を再現します。
- [ ] 実際のプルリクエスト、テスト、アーカイブ、配布用ジョブを混在させる
- [ ] executor数、待ち時間、CPU、メモリ、ディスクI/Oを記録する
- [ ] DerivedData、Swift Packageキャッシュ、Simulator状態が衝突しない
- [ ] 同一キーチェーンを複数ジョブが同時変更しない
- [ ] 作業領域をジョブ単位で分離し、前回の成果物が残らない
- [ ] キュー待ち時間と失敗率がチームの許容範囲に収まる
- [ ] 容量不足時に追加ノードまたは固定ノードへ切り替えられる
executor数はチップ名だけで決めず、許容待ち時間から逆算します。待ち時間を短くするためにexecutorを増やし、署名やディスク競合で失敗率が上がるなら、executorを戻すか、ノードを分割します。
056. Agentの再起動と無人復旧を検査する
「SSHで接続できる」ことと、「夜間に無人でJenkinsへ復帰できる」ことは別の能力です。計画再起動、Agentプロセスの異常終了、短時間の通信断、ディスク容量警告を個別に再現し、復旧に必要な権限と人手を記録します。
遠隔Mac再起動後にJenkins Agentを自動復帰させるための検査項目は、次のとおりです。
- [ ] SSHのRemote Loginが有効で、許可ユーザーが限定されている
- [ ] macOS起動後にAgentプロセスが自動開始する
- [ ] Agent切断をJenkinsが検知し、再接続または通知できる
- [ ] FileVault有効時の再起動後に、必要な解除条件を確認している
- [ ] 再起動後もXcode、キーチェーン、作業領域、監視が利用できる
- [ ] 途中で停止したPipelineを再実行する基準が決まっている
- [ ] 夜間の復旧に人手が必要な場合、その担当者と連絡経路が明記されている
Appleの案内では、Apple Silicon搭載MacでmacOS 26以降を使用し、Remote Loginとネットワーク接続が有効な場合、再起動後にSSH経由でFileVaultを解除できる条件が示されています。ただし、これは完全な災害復旧を意味しません。電源、ネットワーク、認証、Jenkins再接続、署名資産の利用まで、実環境で確認する必要があります。(support.apple.com)
067. 受入結果を4種類に分類する
検査結果は「合格・不合格」の二択にせず、運用上の制約を含めて決定します。
| 判定 | 適用条件 | 次の処置 |
|---|---|---|
| 本番投入可 | 6領域の証跡が揃い、サービス目標を満たす | 担当責任者が承認し、監視を継続 |
| 限流試運用 | 単独ビルドは安定するが、並行負荷または復旧が未確認 | 本番配布を制限し、実負荷記録を追加 |
| 改修後に再検査 | 権限、ラベル、Xcode、署名、作業領域に明確な不備がある | 修正担当と期限を決めて再検査 |
| 本番投入拒否 | 秘密情報の越権、復旧不能、実プロジェクト失敗がある | AgentまたはMacを分離し、設計を見直す |
担当者を曖昧にすると、問題が「Jenkins設定」「Mac管理」「Apple Developerアカウント」の間を行き来します。各判定には、承認者、修正担当、再検査条件、代替ノードの有無を記録してください。
受入前の最終チェック
- [ ] 接続方式と再接続方式のログがある
- [ ] Jenkinsfileのラベル指定と実行ノードが一致している
- [ ] Controllerが正式ビルドを実行していない
- [ ] Apple Silicon、macOS、Xcode、SDK、依存関係を実プロジェクトで確認した
- [ ] クリーン、キャッシュ利用、キャッシュ消去後の3条件を比較した
- [ ] 開発用と配布用の署名資産を分離した
- [ ] 低権限ジョブで越権アクセスを試した
- [ ] 実際の高峰負荷でexecutorと待ち時間を確認した
- [ ] DerivedData、Simulator、キーチェーンの競合を確認した
- [ ] 再起動、Agent異常終了、通信断、容量警告を再現した
- [ ] 合格条件、失敗処置、責任者、再検査日を記録した
07容量と運用方式を比較して長期構成を決める
受入後の構成は、固定ノードだけ、弾力的に追加するノードだけ、という二択にする必要はありません。通常負荷を固定容量で処理し、リリース期間だけ追加のMac Agentを使う構成も候補になります。判断軸は、チップの名称ではなく、チームが許容する待ち時間、同時実行数、署名分離、復旧要件です。
| 構成 | 適する条件 | 注意点 |
|---|---|---|
| 共有Mac Agent 1台 | Pipeline数が少なく、ジョブ間の分離要件が低い | executor増加による競合を実測する |
| 用途別の複数Agent | 開発検証と本番配布を分けたい | 証明書、ラベル、保守手順が増える |
| 固定ノード＋追加ノード | 通常負荷とリリースピークに差がある | 追加ノードのラベルと秘密情報を事前確認する |
| 独立Macホスト | 強いプロジェクト分離、物理アクセス、専用キーチェーンが必要 | 機器調達、保守、遊休時間を負担する |
| 周期利用の遠隔Mac | 受入試験、短期増強、予備ノードが必要 | 実Pipelineで復旧と容量を先に確認する |
Jenkinsのノード管理では、空きディスク、テンポラリ領域、時刻同期、応答時間なども監視対象になります。これらを確認せず、Apple Siliconの性能だけで必要台数を決めると、ビルドの失敗要因を見落とします。(jenkins.io)
常設Macを購入する場合は、資産管理、故障対応、保管場所、OSとXcodeの更新、余剰容量の負担が発生します。一方、NUKCLOUDのような周期利用の遠隔Macは、実際のJenkins Pipelineを受入ノードへ投入し、並行実行と再起動復旧の証跡を集めてから、固定容量や追加ノードの必要性を判断できます。利用条件を確認する場合は、NUKCLOUDの日本語サービス案内を参照してください。
ただし、長期間にわたり安定した高負荷を常時処理する場合、特定の物理機器やUSB接続を必要とする場合、社内規定で専有設備が必須の場合は、周期レンタルが最適とは限りません。現在の方式に、購入後の遊休時間、保守担当者の確保、復旧用の予備機、Xcode更新時の検証負担があるなら、まずは実Pipelineを遠隔Macで試運用し、記録した容量と復旧結果を基に長期構成を決めるのが合理的です。
受入検査で不足しているのが「接続確認」ではなく、実負荷、署名分離、再起動後の復旧証跡であるなら、NUKCLOUDの日本向け申込み案内から検証用のMac環境を準備し、期間を限定して評価する方法が現実的です。まず本番と同じJenkinsfileを動かし、証跡が揃った時点で、購入、固定レンタル、ピーク時の追加利用のどれを採用するか判断してください。