AppleのBuild Runs APIでは、ビルド実行の記録を確認でき、完了状態はcompletionStatusという項目で扱われます。ビルド記録のAPIと完了状態の説明を基準に、まずビルドが作成されたのか、実行待ちなのか、完了後の処理なのかを分けてください。Xcode Cloudのビルドキュー待ちは、状態、ワークフローのトリガー、チーム用量を照合してからAppleのシステム状況を確認し、根拠なく取消・再実行しないのが今週の推奨アクションです。
企業IT・プラットフォーム担当者：Xcode Cloudの状態、設定、用量のどこに原因があるかを切り分け、重要なタスクの代替経路を計画できます。
iOSリリース担当者：ビルドが始まらないとき、待機・再試行・別CIへの切り替えを判断する材料を得られます。
開発効率・FinOps担当者：個別の印象ではなく、チームのビルド記録から影響を評価できます。
SECTION 01 「Queued」の位置を特定し、ビルドの段階を分ける
最初に、XcodeまたはApp Store Connectで対象ビルドの記録を開き、作成日時、対象ブランチ、ワークフロー、現在の状態を確認します。ビルドが作成されていない状態は、実行待ちとは別です。また、ビルドが完了した後にApp Store Connect側で処理されている状態も、Xcode Cloud内での実行待ちと混同しないでください。
App Store Connect APIのビルド記録とアクション情報を照合すると、ビルドの状態だけでなく、実行に関連する記録も確認できます。ビルドアクションの情報も参照し、記録上どの段階まで進んだかを把握します。アップロード後の処理については、Appleのビルドアップロードに関する案内を別に確認してください。
| 見えている状況 | まず確認する記録 | 判断の目安 |
|---|---|---|
| ビルドが見当たらない | トリガー履歴、対象ブランチ、ワークフロー設定 | 作成されていない可能性があり、再実行より設定確認を優先します |
ビルドがQueuedのまま |
ビルド記録、ワークフロー、同時期の他ビルド | 実行待ちか、複数タスクが重なっているかを確認します |
| ビルドが実行され、失敗した | ビルド詳細とアクションの記録 | キュー待ちではなく、失敗した工程のログを調べます |
| ビルド完了後に利用できない | App Store Connectの処理状況 | ビルド実行とアップロード後の処理を分けて追います |
Xcode CloudのビルドがQueuedのままの場合、何から確認しますか？
まず対象ビルドが記録に作成されているかを確認し、作成済みならワークフローと同時期のほかのビルドを照合します。記録がないのに再実行を繰り返すと、トリガー設定の問題を見逃したまま不要な処理を増やすおそれがあります。
SECTION 02 トリガー設定とチーム用量を照合する
ワークフローが有効か、対象ブランチやイベントが条件に合っているかを確認します。意図した変更が条件から外れていれば、ビルドは作成されません。AppleのXcode Cloudワークフローリファレンスに沿って条件を確認し、初回ワークフローの設定案内も参照しながら、設定と実際のイベントを突き合わせてください。
サービス障害とワークフロー設定の問題は、どう見分けますか？
まずビルド記録が作成されたかを確認します。記録がなければトリガー条件やブランチを優先して調べ、記録がある場合はビルド状態、関連アクション、同時期の別ビルドを比較します。設定に問題がないと確認できた後で、Appleのシステム状況と照合してください。
変更を加える場合は、対象ブランチとイベントを記録したうえで、受け入れ可能なテスト変更を使って一度だけ制御された検証を行います。元のワークフロー記録と結果を比較すれば、条件変更がビルド作成に影響したかを追いやすくなります。確認が済む前に設定を複数変更したり、連続して再実行したりするのは避けてください。
次に、Appleが提供するXcode Cloudの用量データ確認方法を見ます。予算やプランの情報だけで利用上限に達したと決めつけず、実際の用量表示と対象ビルドの記録を同じ期間で照合することが重要です。
チーム用量がビルドのキュー待ちにつながっているかは、どう確認しますか？
用量情報とビルド詳細の両方を確認し、待ちが発生した期間やワークフローと一致するかを調べます。単一の失敗や、計画上の予算だけから原因を断定せず、チームの記録に基づいて判断してください。
SECTION 03 Appleのシステム状況を見て、待機か再試行かを決める
対象ビルドの時刻、プロジェクト、ワークフローを記録したうえで、Apple Developerのシステム状況を確認します。関連サービスに表示がある場合は、影響する時間帯や機能と手元の記録を照らし合わせてください。一方、ステータスページが正常でも、すべてのサービス側要因が否定されたとは限りません。
ステータスページの表示だけで結論を出さず、対象ビルドの記録、ワークフロー条件、用量情報と一緒に判断してください。
判断の順序は、トリガーと設定に誤りがないか、用量表示に関連する情報があるか、システム状況と発生時刻が重なるか、です。確認後も解消せず、リリース期限への影響が大きい場合は、記録を保存して一度だけ制御された再試行を検討するか、診断情報を添えてAppleのサポート窓口へ相談します。キャンセルと再実行を繰り返すのではなく、各試行の結果を比較できる形で残してください。
SECTION 04 重要タスクを切り分け、代替CIの受け入れ条件を決める
キュー待ちが一時的か継続的かは、チームのビルド記録で評価します。重複したコミット、複数ワークフローの集中、テストが完了していない状態などが同時期にないかを調べ、単発の事例をチーム全体の容量不足とみなさないでください。
どのiOSビルドタスクをMac CIへ分けるべきですか？
プロジェクトのソース取得、コンパイル、テストなど、実際のワークフローで再現できる工程から適性を確認します。Apple側で行われるアップロード後処理など、依存先がAppleのサービスである工程は、Mac CIへ移しても同じ原因を解消できるとは限りません。署名権限や証明書の保管範囲を確認し、切り替え条件、結果の返却方法、二重実行の検知も事前に決めます。
次の項目を、実際のプロジェクトと担当者で確認してください。
- [ ] ビルド記録から、作成、実行待ち、実行、完了後の処理を区別できる
- [ ] ブランチ、イベント、ワークフローの有効状態を記録と照合した
- [ ] チーム用量の表示を対象期間のビルド記録と比較した
- [ ] Appleのシステム状況を対象ビルドの発生時刻と照合した
- [ ] 再試行は原因確認後に制御して行い、結果を元の記録と比較できる
- [ ] Mac CIへ分ける場合、署名権限、重複実行、結果の返却を検証した
| 選択肢 | 適する条件 | 注意点 |
|---|---|---|
| Xcode Cloudで待機 | 設定と記録に明確な誤りがなく、リリースへの影響を許容できる | 状況を記録し、状態の変化を追います |
| 制御された再試行 | トリガーや設定を確認済みで、再実行の結果を比較できる | 原因不明のまま取消・再実行を重ねないでください |
| 独立したMac CIへ分流 | 対象工程を再現でき、権限や結果連携も検証できる | Apple側の処理待ちそのものを解決する手段ではありません |
遠隔のMac CIを検討する場合は、まず自分たちのワークフロー、署名の扱い、ネットワーク要件で受け入れ試験を行い、切り替え後のログと成果物が追跡できることを確認します。提供条件は構成や契約によって異なるため、利用前にVPSNIXの料金・期間情報とヘルプセンターの案内で、確認できる内容を照合してください。ここに記載のない性能、納期、稼働保証を前提に設計しないことが大切です。
チームのローカルMacだけで運用する方法は、手元の管理が容易な一方、担当者の稼働状況や端末の保守がボトルネックになりやすく、台数を増やせば購入・管理負担も増えます。Xcode Cloudだけに集約する場合は、Apple側の実行や後続処理に依存するため、Mac CIを追加してもサービス側の障害を即時に直せるわけではありません。重要リリースで待ちが繰り返されるなら、タスク分流用のMacを実際の工程で検証し、必要な期間だけ利用する選択肢もあります。VPSNIXのMacレンタルは、まず自社のワークフローと署名境界に合うかを確認したうえで、予備の実行環境が必要な場合に比較してください。