Xcode 27 並列テストログ遅延：2026 xcodebuild どう調査する？
Xcode 27 Beta 6では、複数プロセスがstdoutとstderrを同時に送信すると、出力が大幅に遅れる既知の問題があります。この記事では、ログ停止をテスト停止と誤認しないために、責任者ごとの証拠確認、単一ワーカー比較、CIの停止条件、遠隔Mac環境の復旧確認まで整理します。
目次
Xcode 27 並列テストログ遅延では、コンソールの無出力だけでテストを停止扱いにせず、まずテストプロセス、シミュレーター、xcresultを確認してください。Xcode 27 Beta 6では、複数プロセスがstdoutとstderrを同時に送信すると結果表示が大幅に遅れる既知の問題があるため、2026年9月5日時点では、正式ツールチェーンを本番用に残し、Betaは互換性確認または二重運用に分ける判断が安全です。詳細は Xcode 27 Beta 6のリリースノート で確認できます。
このページは、xcodebuildでXCTestまたはSwift Testingを実行し、Xcode 27への更新後にログが長時間止まって見える独立開発者向けです。
XCUITestの並列実行を保守する担当者、遠隔Macや自ホストRunnerでCIを管理する担当者にも、停止判定と回退条件を使える形で整理しています。
最終更新：2026年9月5日。Xcode 27 Beta 6の既知の問題番号165098287、テスト結果の解釈、App Store ConnectのBeta対応範囲をApple公式資料で再確認しています。後続Beta、RC、正式版で挙動が変わる可能性があります。
最初に固定する判定基準
脱臭した事例では、ターミナルのstdoutがしばらく更新されない一方、テストプロセスは存続し、終了後にxcresultが生成されました。この状態は「表示の遅延」であり、コンソールだけから「テストが固まった」とは判定できません。
一方、プロセスが消失している、シミュレーターが応答しない、結果パッケージが生成されない、CIの外側でタイムアウトが発生している場合は、既知のログ問題だけで説明してはいけません。最初にコマンド、開始時刻、Scheme、Test Plan、終了コード、結果パスを保存してください。ホストの再起動は第一手段にしないでください。
Xcode 27 Beta 6の既知の問題は、複数プロセスからのstdoutとstderrの転送が遅延する可能性を示すものです。すべての無出力状態が安全だと保証するものではありません。Appleのテスト実行と結果解釈の資料も参照し、表示、実行、結果保存を別々の証拠として扱います。
責任者別の証拠入口
| 担当者 | 最初に見る証拠 | 一時対応 | 中止・エスカレーション条件 |
|---|---|---|---|
| コマンドライン開発者 | xcodebuild、テストプロセス、終了コード、xcresult | 同一条件で単一ワーカーを比較 | 単一ワーカーでも完了せず、結果も残らない |
| XCUITest保守担当 | シミュレータークローン、App起動、添付ファイル、時系列 | ワーカー数を抑えて診断 | UI待機が期限を超え、画面状態も変化しない |
| CI担当者 | xcresultの保存、外部タイムアウト、システムログ | 結果保存後に回退ジョブを実行 | 外部監視だけでジョブを終了している |
| 遠隔Mac管理者 | SSHや画面接続の状態、CPU、メモリ、ディスク、残留プロセス | 切断後の継続と再接続を検証 | 資源枯渇、ディスク不足、再接続後の復旧失敗 |
Appleの自動テスト資料では、コマンドラインからテストを自動化する方法と結果の扱いが説明されています。CIでは標準出力の見た目を監視するだけでなく、自動テストの公式ガイドに沿って成果物を保存する設計にしてください。
Test Planを複数の実行層に分ける場合は、対象テスト、診断用設定、並列実行の条件が混ざらないように管理します。テストを整理してフィードバックを改善するAppleの資料も確認し、プルリクエスト用と完全回帰用で同じ停止条件をそのまま使わないでください。
ローカルのxcodebuild実行
まず現在のコマンドを変更せず、実行開始時刻と終了状態を記録します。次に、同じコミット、Scheme、Test Plan、シミュレーターの種類を使い、並列設定だけを抑えたテストを実行します。プロジェクト名、ユーザー名、端末識別子、作業パスは共有ログから脱臭してください。
比較対象は、ターミナルが何行表示したかではありません。テストが完了したか、終了コードがどうなったか、Xcodeのテストレポートとxcresultに失敗テストや添付ファイルが残ったかを見ます。ビルド段階から無出力なのか、テスト実行中だけ無出力なのかも分けて記録します。
XCUITestのシミュレーター確認
並列実行では、各ワーカーに対応するシミュレータークローンを確認します。被テストAppが起動していないのか、起動後にUI条件を待っているのか、テストプロセスそのものが応答しないのかで対応が変わります。
失敗スクリーンショット、アクティビティ記録、xcresultのテスト時系列を組み合わせると、停止位置を特定しやすくなります。アプリ内の待機、XCTestやXCUITestの制限時間、CI外側のジョブタイムアウトは別の時計として管理してください。
CI運用の保存設計
CIのジョブは、少なくともxcresult、終了コード、テスト開始・終了時刻、主要なシステムログを保存する設計にします。コンソールに新しい文字が出ない時間だけを失敗条件にすると、ログ遅延を本当の停止と誤認して不要な再試行を起こします。
プルリクエスト向けの短い確認、完全回帰、夜間の並列テストでは、停止条件を同じにしない方が安全です。並列ジョブが判定不能になった場合に、単一ワーカーの回退ジョブを起動して結果を残す仕組みを用意してください。
App Store Connectは、Xcode 27 Beta 6で構築したバージョンのTestFlight内部・外部テスト対応を案内しています。ただし、これは本番CI全体をBetaへ移行すべきという意味ではありません。対応範囲はApp Store Connectのリリースノートで、最新BetaやRCの記載を再確認してください。
並列実行と単一実行の比較
| 比較項目 | 現在の並列設定 | 単一ワーカーの対照 |
|---|---|---|
| 目的 | 実際のCI運用で現象を再現する | ログ遅延とテスト故障を切り分ける |
| 固定する条件 | コミット、Scheme、Test Plan、端末 | 左記を完全に一致させる |
| 見るべき結果 | プロセス、クローン、xcresult、終了コード | 完了状態、失敗時刻、添付ファイル |
| 位置づけ | 通常運用または再現確認 | 診断および一時的な回避 |
| 採用判断 | 結果保存と停止判定が安定している場合 | 並列時の判定不能を避けたい場合 |
ワーカー数を減らすことは、Appleが問題番号165098287に対して示した恒久修正ではありません。原因確認のための対照実験、またはBeta期間中の一時的な運用策として扱ってください。
遠隔Macでの切断と資源確認
遠隔Macでは、SSHやグラフィカルな接続が切れたことと、テストジョブが停止したことを混同しやすくなります。接続を切る前後で、テストプロセス、シミュレーター、xcresultの保存先が継続して動くかを確認してください。画面が見えなくても、プロセスと成果物が更新されていれば、表示経路の問題である可能性があります。
次の手順で環境を検証します。
- 実行コマンド、コミット、Scheme、Test Plan、端末条件、開始時刻を保存します。
- xcodebuildと子プロセス、シミュレーターの状態を確認し、ターミナルの無出力だけでは停止扱いにしません。
- xcresultの保存先、生成状態、テスト時系列、添付ファイルを確認します。
- 同じ条件で並列実行と単一ワーカー実行を行い、最終結果と終了コードを比較します。
- XCUITestではApp起動、UI待機、スクリーンショット、シミュレータークローンを確認します。
- SSHや画面接続を切断し、再接続後もプロセス、結果保存、ログ収集が継続しているかを確認します。
- CPU、メモリ、ディスク容量、シミュレーターの起動履歴、残留プロセスを確認します。
- Betaの互換性検証と正式ツールチェーンのリリース処理を分離し、単一ワーカーの回退入口を残します。
常駐のiOSテスト環境を作る場合は、先にMacレンタルの利用環境で、接続方式、結果の保存場所、再接続手順を確認してください。遠隔環境の選択では、開発者との距離だけでなく、テスト中の接続切断、ディスク消費、シミュレーターの復旧方法まで受け入れ条件に含める必要があります。候補地域を比較する場合は、M4 Macノードの一覧を起点にしてください。
Beta継続と正式運用の分離
判断は次の3通りに分けると、問題の影響範囲を抑えられます。
- iOS 27互換性の確認が主目的で、プロセス、xcresult、終了コードを完全に保存できる場合は、Xcode 27 Betaの専用検証環境を継続します。
- 安定したログ、厳密なタイムアウト、署名付きリリースが必要な場合は、正式ツールチェーンを本番に残し、Betaを別の検証経路で動かします。
- 単一ワーカーでも完了しない、xcresultが有効に生成されない、シミュレーターが継続して無応答になる場合は、ログ遅延ではなく実際のテスト障害として扱います。
テスト担当者は、1回の完全なジョブの最後に、Xcodeとxcodebuildのバージョン、並列設定、Scheme、Test Plan、結果保存先、終了コード、回退入口を記録してください。Xcode 27の新しいBeta、RC、正式版が公開された時点、または問題番号165098287がResolved Issuesへ移動した時点で、同じ対照テストを再実行します。
現在の共有Runnerや一時的な遠隔作業環境を使い続ける方法は、初期確認には向いていても、結果パッケージの保存漏れ、接続断、資源競合、正式版とBetaの混在という弱点が残ります。長時間の並列テストや回退ジョブを安定して運用するなら、VPSMACのMacレンタルで検証環境を分離する方が、ログ遅延と本当の障害を切り分けやすくなります。ただし、物理デバイス接続が必須の試験や、長期にわたる固定負荷を自社で管理したい場合は、専用の実機環境や自社保有Macの方が適しています。
よくある確認
Xcode 27の並列テストでログが止まったら、すぐ失敗扱いにしますか？
いいえ。まずテストプロセス、シミュレーター、xcresult、CI外部タイムアウトを確認します。Beta 6では複数プロセスのstdoutとstderrが遅延する既知の問題があるため、コンソールの表示だけを停止条件にしないでください。
xcodebuild testが出力し続けない場合の最初の操作は何ですか？
コマンドと開始時刻を保存し、xcodebuildとテスト子プロセスが存続しているかを確認します。続いてxcresultの生成状態を調べ、同一コミット、Scheme、Test Plan、端末条件で単一ワーカーを実行します。
xcresultで実行中かどうかを判定できますか？
xcresultは完了結果、失敗テスト、添付ファイル、テスト時系列の確認に使えます。ただし、生成途中の状態だけで実行中と断定しないでください。プロセス、シミュレーター、終了コードと組み合わせて判定します。
XCUITestのワーカーは無効にするべきですか？
恒久的に無効化するのではなく、単一ワーカーを対照として使います。並列時だけ結果保存やUI待機が不安定になるなら、一時的な回避策としてワーカー数を抑えますが、公式修正とは扱いません。
遠隔Macのタイムアウトはどう分けますか？
アプリ内待機、テストフレームワーク、CIジョブ、外側の監視を別々に管理します。ログが止まった直後に終了させず、プロセスとシミュレーター、xcresult、資源状態を確認できる猶予を設けてください。需要が一時的な検証やBetaとの二重運用に限られるなら、VPSMACのMac環境を回退用に使う構成も検討できます。