AppleのXcode 27 Betaリリースノートでは、Xcode 27はBetaとして扱われています。したがって、Buildkite AgentのリモートMacへのデプロイは可能ですが、Xcode 27用ノードはAppleの要求を満たすApple Silicon Macに隔離し、命令行ビルドから順に実タスクで合否判定してください。Agentがオンラインと表示されるだけでは、CIノードの導入完了とはいえません。
最終更新：2026年8月31日。Xcode 27のBeta状態、システム要件、既知の問題をApple公式資料で確認しています。
この記事は、iOSまたはmacOSのビルドを手元のMacからBuildkiteへ移したい開発者向けです。長期間アクセスできるビルドノードを管理するDevOps担当者や、Xcode 27を隔離検証しながら安定版の本番環境を維持したいプラットフォーム責任者にも適しています。
SECTION 01 導入前にリモートMacの役割を固定する
最初に、対象ノードを「命令行ビルド専用」「Simulatorを使うテスト用」「署名・配布用」のどれにするか決めます。すべてを一台へ詰め込むと、DerivedData、Simulatorの状態、ログインセッション、署名資産が互いに影響し、失敗原因を切り分けにくくなります。
Xcode 27を置くMacは、AppleのXcodeシステム要件とXcode 27のBeta資料を照合します。チップ、macOS、SDK、Xcodeの組み合わせが要求を満たさない場合は、Agentの設定を続けず、ノードを再選定してください。
Buildkiteの制御プレーンはジョブを管理し、Agentはジョブを取得してMac上で実行します。公式の自ホストAgentはmacOSで利用できますが、通常はジョブ取得のための出方向接続を使う構成です。自ホストAgentの動作説明を確認し、Agentのためだけに不必要な入方向ポートを開けないでください。
| 確認対象 | Xcode 27隔離ノードで見ること | 停止条件 |
|---|---|---|
| ハードウェア | Apple Siliconを含むApple公式要件との適合 | チップまたはmacOSが不明 |
| ツールチェーン | Xcodeのインストール状態、選択パス、SDK | 要求されたSDKが存在しない |
| 用途 | ビルド、Simulator、署名・配布の範囲 | 本番署名資産とBeta検証を共有 |
| 接続 | Agentの出方向通信、Queue、Cluster | 不要な公開ポートが前提 |
| 復旧 | 再起動後のログイン、Agent、実ジョブ | オンライン表示だけで判断 |
Buildkite AgentはリモートMacにも導入できますか。
できます。ただし、リモート接続方式とCI実行の成立は別問題です。VNCやSSHで管理できても、Agentの実行ユーザー、Xcodeの選択状態、macOSのユーザーセッションがジョブから再現できなければ、導入は未完了です。
SECTION 02 最初の作業時間でアカウントとQueueを分離する
Agent用に、日常利用とは分けたmacOSユーザーを作成します。管理作業に必要な権限と、ビルド実行に必要な権限を同じアカウントへ集約しないことが重要です。特に署名用の秘密鍵を扱うノードでは、Pull Requestの通常ジョブから配布資産へ到達できない構成にします。
macOS版の公式インストール手順に従い、設定ファイル、ログ、作業ディレクトリの実際の場所を確認します。環境によって配置先を決め打ちせず、インストール後にAgentのログと起動定義を照合してください。
登録時は、以下のように値を置き換えます。Token、ホスト名、Queue名、Cluster名を実値で記事や共有ログへ残さないでください。
AGENT_TOKEN=<AGENT_TOKEN_PLACEHOLDER>
AGENT_NAME=<REMOTE_MAC_AGENT_PLACEHOLDER>
CLUSTER=<CLUSTER_PLACEHOLDER>
QUEUE=<QUEUE_PLACEHOLDER>
Queueはジョブの行き先を制御します。Queueの公式仕様を確認し、Xcode 27用には安定版ノードと区別できるタグまたはQueueを割り当てます。
登録直後は、システム情報と開発ツールの場所だけを出力する最小ジョブを送ります。
uname -m
sw_vers
xcode-select -p
このジョブが意図したQueueで実行され、別のMacへ誤配送されていないことをBuildkiteのログで確認します。Tokenを更新した場合は、古いTokenが残っていないかも確認し、認証情報のローテーション手順を記録してください。
SECTION 03 最初のビルドでXcode 27の再現性を確認する
BuildkiteでXcode 27のビルドノードを指定するにはどうしますか。
Xcodeのバージョン名をジョブの期待値にするだけでなく、QueueまたはAgentタグで専用ノードへルーティングし、ジョブ内でXcodeのパスを明示します。インタラクティブなShellで設定した環境変数を、そのままAgentのジョブが継承すると考えてはいけません。
プロジェクトのアクセス権は、Agent用アカウントに必要最小限だけ付与します。Buildkiteのコードアクセスに関する公式手順を基準に、短期間で交換できるマシン用IDや、組織の鍵管理機能を優先します。
作業は次の順に進めます。
- [ ] リポジトリをAgent用アカウントから取得できる
- [ ] 期待するXcode 27のパスをジョブ内で明示できる
- [ ] 依存関係の解決が非対話で完了する
- [ ] コンパイルが完了し、終了コードを記録できる
- [ ] 単体テストが実行され、結果ファイルを保存できる
- [ ] ログと成果物の保存先がジョブごとに追跡できる
- [ ] 失敗時に作業ディレクトリを調査してから安全に清掃できる
たとえば、Xcodeの選択状態を確認したうえで、プロジェクト固有のビルドコマンドを実行します。ここではリポジトリ名、Scheme、パスを固定値にしません。
xcode-select -p
xcodebuild \
-workspace <WORKSPACE_PLACEHOLDER> \
-scheme <SCHEME_PLACEHOLDER> \
-destination '<DESTINATION_PLACEHOLDER>' \
clean build test
実際の合格証拠はAgentがオンラインであることではなく、依存解決、コンパイル、単体テスト、結果ファイル生成が同じジョブから再現できることです。いずれかが対話入力を要求する場合は、署名作業へ進まず、環境変数、キーチェーン、作業ディレクトリの差分を調査します。
| ジョブ段階 | 観測する証拠 | 次へ進める条件 |
|---|---|---|
| 取得 | リポジトリ、ブランチ、認証ログ | 秘密情報をログへ出さず取得できる |
| 依存解決 | 解決結果と終了コード | Agent実行時にも再現する |
| ビルド | Xcodeのパス、コンパイルログ | 指定Queueで完了する |
| テスト | テスト結果ファイル | 成否と成果物を保存できる |
| 清掃 | 作業領域とキャッシュの状態 | 他ジョブのファイルを消さない |
SECTION 04 Simulatorを追加するときはユーザーセッションを検証する
SimulatorやUIテストが不要な命令行ノードなら、グラフィックセッションを無条件に追加しない方が安全です。必要な場合は、Agentが所属するmacOSユーザーセッション、インストール済みランタイム、認識可能なシミュレーターを確認してから最小テストを実行します。
自ホストのMacでiOS Simulatorテストを実行できますか。
実行できますが、Xcodeと対応ランタイムがそのノードにあり、ジョブが適切なユーザーセッションで動作することが条件です。Simulatorの起動成功は、実機テスト、署名、配布まで成功した証拠ではありません。
最小の検証では、シミュレーターの一覧取得、起動、テスト、結果収集、終了後の清掃を一連のジョブにします。GUIから一度起動したから大丈夫と判断せず、Agent経由の非対話ジョブで確認してください。
注意：Simulatorの失敗を「CPU不足」と即断しないでください。ランタイム未導入、ユーザーセッション、デバイス状態、Xcodeの選択パスが原因になることがあるため、ログを保存してから状態を消去します。
SECTION 05 署名・配布は別Queueと別の境界で扱う
通常のPull Requestビルドと署名・配布を同じQueue、同じユーザー、同じキーチェーンへ置くと、検証コードが本番用秘密鍵へ近づきます。コード構築と署名を別Queueに分け、配布ジョブは承認済みブランチや手動承認など、組織のリリース条件を満たした場合だけ実行する設計にします。
確認対象は、キーチェーンのロック解除、秘密鍵へのアクセス、プロビジョニングプロファイルの対応、非対話セッションでの署名動作です。証明書名、Team ID、パスワード、リポジトリ情報はすべてプレースホルダーにします。Appleのコード署名に関する開発者向け資料も参照し、失敗時に秘密情報がログへ出ないことを確認してください。
並列実行については、単一ノードでDerivedData、Simulator、キーチェーンが競合しない証拠を得るまで直列を選びます。Agentプロセスを増やすだけでは分離にならず、同じ作業領域や署名資産を共有してしまう可能性があります。
SECTION 06 再起動後の常駐と回復を受け入れ試験にする
BuildkiteのmacOS Agentを再起動後に自動オンラインへ戻すにはどうしますか。
macOSの起動管理にAgentを登録し、再起動後に対象ユーザーのセッション、Agentプロセス、Queue接続、実ジョブの順に確認します。launchdの仕組みはAppleの公式ドキュメントを参照し、単にプロセスをバックグラウンド起動するだけにしないでください。
受け入れ試験は、次の順で行います。
- [ ] 再起動前にAgentの設定と復旧手順を保管する
- [ ] 影響範囲を確認してから管理対象Macを再起動する
- [ ] SSHまたはVNCで管理アクセスが戻る
- [ ] Agent用ユーザーセッションが期待どおりになる
- [ ] launchdの起動定義とAgentログを確認する
- [ ] Queueがオンラインになり、最小ジョブを受け取る
- [ ] 実際のビルドを実行し、成果物まで確認する
- [ ] ログ輪転、ディスク増加、作業領域の清掃を確認する
復旧できない場合に、サービスの再インストールやキーチェーン変更を先に実行しないでください。設定ファイル、起動定義、ログを保存し、安定版Xcodeを保持した回避ノードへQueueを戻せる状態を確保します。Xcode 27 Betaの問題と、Agentの接続問題を同じ障害として扱わないことが切り分けの要点です。
SECTION 07 本番Queueへ入れる前の判断
命令行ビルドだけが目的で、Xcode 27のBetaリスクを許容できない場合は、専用ノードを検証用途に限定します。Simulatorまで必要ならユーザーセッションとランタイムの復旧を確認し、署名・配布まで行うなら、秘密鍵の境界と承認経路を追加で満たす必要があります。
[ ]の項目をすべて確認できない段階では、本番Queueへ入れず、Xcode 27の隔離検証用として運用してください。反対に、実プロジェクトのビルド、テスト、成果物、再起動後の再実行まで確認できれば、用途を限定したうえで段階的にジョブを移行できます。
すでにLinuxやWindowsのCIサーバーを使っている場合、macOS専用のXcodeツールチェーン、Simulator、キーチェーンを扱えないことが長期的な制約になります。自前のMac mini運用なら初期購入、保守、常時稼働、障害時の現地対応が負担になり、仮想化環境ではAppleの要件やグラフィック、署名の検証範囲が複雑になります。
そのため、Xcode 27を短期検証したい、安定版とBetaを分けたい、常時稼働するApple Silicon Macをまだ用意できていないという条件なら、VPSNIXのMacレンタルを隔離ノードとして比較する価値があります。VPSNIXのMacレンタル料金を確認し、この記事のQueue分離、実ビルド、Simulator、再起動復旧の証拠を取得してから、本番採用を判断してください。接続方法や運用上の確認事項はMacレンタルのヘルプセンターで確認できます。