2026年4月28日以降、App Store Connectへの提出ではXcode 26またはそれ以降のバージョンが最低要件になります。この変更はAppleのXcode 26リリースノートで確認できます。
症状： 管理者のTerminalではビルドできるのに、CIサービスアカウントでは「Xcode 26のライセンス未承諾」が表示される。
最短解法： 実際のXcodeパスを固定し、そのバージョンのxcodebuildヘルプに従ってライセンスとfirst-launch初期化を実施し、同じサービスアカウントで最小ビルドを通します。
この順序を飛ばして再インストールすると、別のXcodeやCommand Line Toolsを呼び出している問題、初回コンポーネント不足、署名用Keychainの問題を隠してしまいます。複数ノードでは、成功した操作を手作業で繰り返すのではなく、証拠を残せる交付基準として灰度展開してください。
SECTION 01この手順を読むべき担当者
企業IT担当者は、社内またはリモートMacへ同じXcode環境を交付する基準を作るために利用できます。プラットフォーム担当者は、Jenkins、GitHub Actions、GitLabなどの非対話シェルで発生する初期化失敗を切り分けられます。
技術責任者や開発者体験の責任者にとっては、既存ノードを止めて修復するか、隔離した予備ノードを先に用意するかを判断するための材料になります。
SECTION 02まず「ライセンス未承諾」と別の失敗を分ける
管理者Terminalで成功したという事実だけでは、CIが同じ環境を使った証拠になりません。シェルのPATH、DEVELOPER_DIR、実行ユーザー、作業ディレクトリが違えば、同じMacでも別のXcodeが選択されます。
| 確認対象 | 残す証拠 | 主な担当 | 次の対応 |
|---|---|---|---|
| Xcodeの実体 | xcode-select -p、xcodebuild -version、アプリパス |
交付担当 | パスを固定する |
| ライセンス | 対象Xcodeでの同意処理と終了状態 | 管理者・監査担当 | 小バージョンのヘルプを再確認する |
| first-launch | 初回セットアップ処理の結果とコンポーネント状態 | Mac交付担当 | 管理者権限で初期化する |
| CI実行文脈 | サービスアカウント、環境変数、作業ディレクトリ | CI担当 | 非対話シェルで再現する |
| 署名処理 | Keychain、証明書、プロファイルのログ | リリース担当 | 初期化問題と分離して修復する |
| プロジェクト固有処理 | 依存解決、コンパイル、テストのログ | 開発チーム | Xcode初期化の完了後に調べる |
Command Line Toolsだけが選択されている場合、完全なXcodeアプリを前提とする処理は期待どおりに動きません。AppleのCommand Line Tools設定資料でも、ツールの導入と選択は別の管理対象として扱われています。
SECTION 03第一歩：呼び出されたXcodeを固定する
交付スクリプトの最初に、対象アプリのパスとバージョンを記録します。全体の既定値を切り替える場合はxcode-select --switchを使い、ジョブ単位で複数バージョンを使い分ける場合はDEVELOPER_DIRで対象を限定します。
xcode-select -p
xcodebuild -version
xcodebuild -help
man xcodebuild
ここで重要なのは、Xcode 26の小バージョンが変わっても、過去のブログにあるオプションの動作をそのまま信頼しないことです。Appleが提供するアプリのビルドと実行に関する資料と、実際にノードへ入っているxcodebuildのヘルプを突き合わせてください。
xcode-selectを全体設定として使うのは、標準のCIノードで既定のXcodeを一つに揃える場合です。一方、複数のXcodeを同居させるノードでは、ジョブごとのDEVELOPER_DIRを優先し、ログにもその値を出します。これを曖昧にすると、ライセンスを処理した後に別のXcodeへ切り替わり、同じエラーが再発します。
SECTION 04runFirstLaunchとライセンス同意は何が違うのか
ライセンス同意は、Xcodeのソフトウェア使用条件に関する確認です。first-launch処理は、選択したXcodeを初めて開発用ツールチェーンとして使うための初期コンポーネントや設定を完了させる処理で、同じものではありません。
そのため、ライセンス処理が終わってもfirst-launchが未完了ならCIは失敗します。反対に初回コンポーネントが整っていても、ライセンス同意が対象のXcodeに反映されていなければ、xcodebuildは停止します。
小バージョンごとのrunFirstLaunchオプション、ライセンス関連のオプション、必要な権限、終了状態は、必ず対象ノードのxcodebuild -helpとman xcodebuildで確認してください。交付スクリプトには、実行したコマンドだけでなく、Xcodeパス、バージョン、終了コード、標準出力、標準エラーも保存します。
注意：ライセンス同意、ローカルツールチェーンの初期化、Apple Developer Programのオンライン契約は別々の確認対象です。一つが成功したことから、残りも有効だと判断しないでください。
SECTION 05CIサービスアカウントで失敗を再現する
「管理者Terminalでは成功、CIでは失敗」という状態では、管理者の成功を修正完了の証拠にしません。CIエージェントと同じmacOSアカウント、非対話シェル、環境変数、作業ディレクトリで、次の順に検証します。
- [ ] CIサービスアカウントで
xcode-select -pを実行し、想定したXcodeアプリのパスを記録する - [ ] 同じアカウントで
xcodebuild -versionを実行し、ジョブの要求バージョンと一致させる - [ ] 対象バージョンの
xcodebuild -helpとman xcodebuildを保存する - [ ] 管理者権限が必要な初期化を、共有パスワードなしで承認済みの手順として実施する
- [ ] 署名なしの最小プロジェクトをビルドし、初期化とコンパイルを分離して確認する
- [ ] 依存解決、テスト、アーカイブ、署名の順に実プロジェクトへ進む
- [ ] Macを再起動し、新しいCIセッションで同じ検証を繰り返す
- [ ] Xcodeパスを切り替えた後も、意図したバージョンが選択されることを確認する
無署名の最小ビルドが失敗するなら、まずXcodeパス、ライセンス、first-launchを戻り先にします。無署名ビルドが成功し、署名段階だけが失敗するなら、Keychainや証明書を調べます。エージェント自体が環境変数を渡していない場合は、Runnerの起動コンテキストが責任範囲です。
署名資格情報は初期化処理へ混ぜないでください。AppleのKeychainで秘密情報を管理する資料を基準に、CIサービスアカウント、証明書、プロファイルの保管とアクセスを別に監査します。
SECTION 06セキュリティ担当とリリース担当の否決条件
セキュリティ担当は、誰が、どのXcodeバージョンを、どのノード群へ、いつ初期化したかを追跡できる状態にします。必要なのは管理者パスワードの共有ではなく、承認者、対象範囲、実行結果、失敗時の復旧先を含む監査記録です。
個人のAppleアカウント、長期保存する署名鍵、開発に不要なシステム権限を初期化スクリプトへ書き込むことは避けます。Appleの配布用署名コードに関する資料も、署名処理はツールチェーン初期化とは異なる工程として確認してください。
リリース担当は、いきなり全ノードへ展開しません。隔離した試点ノードで、コンパイル、テスト、アーカイブ、必要に応じた署名を実行し、再起動後と新しいCIセッションでも再現します。次の条件を満たさない場合は放量を否決します。
- 試点ノードの実プロジェクトが成功していない
- 旧ノードへ戻す手順が確認されていない
- 本番キューを止めずに検証できない
- Xcodeパス変更後のログが残っていない
- ライセンス、初回初期化、署名、Runner障害の責任境界が不明確である
Appleの技術ノートTN2339も、コマンドラインからのビルドを設計する際の補助資料として参照できます。ただし、Xcode 26の小バージョン固有の挙動は、対象ノードに同梱されたマニュアルを優先してください。
SECTION 07修復か、予備ノードかをどう決めるか
既存Macを継続修復する判断は、隔離試験ができ、失敗時に旧ノードへ戻せる場合に限ります。アップグレード中に本番キューを共有し、交付記録も残せないなら、修復作業そのものがリリースリスクになります。
その場合は、安定稼働中の本番プールを維持し、独立したリモートMacでXcode 26の初期化と実際のCIジョブを検証します。MACNOXのリモートMacレンタルのPoCを使う場合も、単なるログイン確認ではなく、サービスアカウント、再起動、Xcodeパス切り替え、実プロジェクトの証拠を受け入れ条件にしてください。
判断材料として、各ノードについて次を記録します。
- 交付からCI受付可能になるまでの作業項目
- 管理者の手作業が残った箇所
- 失敗がライセンス、初期化、署名、Runnerのどこに分類されたか
- 再構築と旧環境への回帰が可能か
- リリース集中時に試験用ノードを確保できるか
固定のMacを長期にわたり高負荷で使い、物理インターフェースや社内ネットワークへの常時接続が必要なら、自社保有の方が適する場合があります。一方、Xcode 26の交付基準を先に検証したい、アップグレード期間だけ容量が必要、既存本番ノードを止められないという条件なら、独立したリモートMacを短期または月単位で使う方が、検証と本番の境界を作りやすくなります。
現在の運用で特に問題になるのは、管理者Terminalに依存する初期化、ノードごとに異なるXcodeパス、再起動後に確認されていないサービスアカウントです。これらを抱えたままMacを買い足すと、台数だけが増えて同じ交付不良が再生産されます。まずMACNOXの料金と利用期間を確認し、隔離したリモートMacで本番CIの最小ジョブを通してから、既存ノードを修復するか予備容量を増やすかを決めるのが安全です。
ライセンス同意を一度実行したことではなく、対象パス、実行アカウント、初期化記録、再起動後の実プロジェクト成功まで揃って、はじめて企業CIの修復完了と判定してください。必要ならMACNOXのMac利用申込みで独立ノードを用意し、既存の本番プールを守りながらXcode 26の交付基準を固めてください。