Xcode 27.2 UIテストのクラッシュにどうCIゲートを設定する？2026年ガイド

Xcode 27.2のUIテスト崩壊に対するCIゲートは、PR・回帰・リリースのリスクごとに扱いを分け、代表的なテストで実際のCI結果まで検証してから適用してください。リリース判定に使う場合は、Test Planの設定だけで動作を推測せず、チームのMac CIで得た記録を根拠にします。

CIプラットフォームエンジニア：UIテストの結果とパイプライン状態を対応づける担当者向けです。
QA責任者：調査が必要な問題と、リリースを止めるべきクラッシュを整理したい場合に役立ちます。
技術責任者：段階別のゲート、承認者、検証証跡を合意するための判断材料を示します。

CI担当者が確認するTest Planの重大度

AppleはXcode 27のリリースノートで、UIテスト中に発生するアプリクラッシュについて、Test Planで重大度を扱う設定を案内しています。Xcode 27.2固有の選択肢や画面上の表示は、Xcode 27のリリースノートとXcode 27.2のリリースノート、実際に使うXcodeの画面で照合してください。

この設定の役割は、テスト中のクラッシュをTest Plan上でどう扱うか決めることです。Appleの設定項目が、そのままPRのマージ可否やリリース承認を定めるわけではありません。重大度の選択と、CIが成功・失敗を決める条件は分けて確認します。

設定場所は、対象のテスト計画を開き、UIテスト中のアプリクラッシュに関する項目を探す手順になります。具体的な画面名や選択肢は更新される可能性があるため、Test Planの編集方法と現行のXcodeを確認し、選択した設定を記録してください。Xcodeの実行環境がサポート対象かどうかは、AppleのXcodeシステム要件で確認します。

アプリチームが分類するクラッシュの期待値

CIへ渡す前に、既存のXCTest UIテストを「アプリのクラッシュを検証するテスト」「通常の操作を確認するテスト」「テスト実行自体の異常が疑われるケース」に分けます。分類はクラッシュ名や終了コードだけで決めず、テストの目的、期待する状態、実際の結果をプロジェクトの保守担当者が確認します。

たとえばクラッシュを検出することがテストの目的なら、クラッシュしたという事実だけではテスト失敗の根拠にならない場合があります。一方、通常の画面操作を確かめるテストで、期待していないアプリ終了が起きたなら、そのテストの期待値と失敗時の処置を明記してください。具体的な故障原因をログや再現で確認できない段階で、特定の原因に決めつけてはいけません。

テストごとに、対象画面や操作、クラッシュが期待されるか、確認担当者、必要なログを記録します。UI自動化で扱う画面操作や割り込みについては、AppleのXCUIAutomationおよびUI割り込み処理の資料を確認し、テスト対象と期待する動作を照合してください。

QA責任者が決める段階別の処理

PRでは、変更点の確認に必要なテストを選び、調査中の結果をどう通知するか、合併を止める条件は何かを決めます。夜間などの回帰実行では、担当者が確認できる報告先と未解決結果の扱いを定めます。リリースでは、承認に直結するテスト結果と、手動確認を求める条件をあらかじめ明文化します。

ここでの通知・失敗・阻断はチームが設計する運用上の区分であり、Appleが定めた推奨ポリシーではありません。特にリリースでは、テストの重大度とリリース承認の条件を別々にレビューし、例外を誰が承認するかまで記録に含めます。

CIエンジニアが行う検証手順

本番のマージ条件やリリース判定に設定を入れる前に、隔離したジョブでTest PlanとCIの最終状態を突き合わせます。代表的なUIテストは、期待する挙動をチームが事前に説明でき、結果を再確認できるものから選びます。Mac CIの実行環境を用意する際は、候補となるMac mini環境の情報も確認し、必要なテスト条件に合うかを個別に検証してください。

• 対象を選ぶ： アプリクラッシュが期待されるケースと、通常の操作を確認するケースを区別し、テスト所有者が期待結果を記録します。
• 環境を固定する： Xcodeのバージョン、Test Plan名、実行先、必要な実行条件を記録します。OSや利用可能な実行先はAppleのシステム要件と実環境の両方で確認します。
• 隔離ジョブで実行する： PRのマージ条件や公開リリースの承認条件から切り離し、変更の影響が本番のゲートに及ばないようにします。
• 結果を保存する： CIログだけで判断せず、テストレポートや結果バンドルを保存します。実行方法と結果の読み方はテスト実行と結果の解釈に関するApple資料を確認します。
• CIの最終状態と照合する： Test Plan上の表示、テスト結果、ジョブの成功・失敗、後続ジョブの実行条件を並べて確認します。
• 承認後に段階導入する： 期待した状態が再現され、責任者と例外手順が決まった場合に限り、対象範囲を広げます。

実行コマンドや保存先はプロジェクトのスキーム、CIの構成、実行先に合わせて指定します。次は記録すべき項目を示す例であり、特定のチームで得られた実測結果ではありません。

xcodebuild test \
  -scheme "<scheme>" \
  -testPlan "<test-plan>" \
  -destination "<destination>" \
  -resultBundlePath "<result-bundle-path>"

記録例は、Xcode=<実際に使ったバージョン>、Test Plan=<対象名>、結果バンドル=<保存先>、CI状態=<実行結果>のように、実行環境と結果を結びつけます。Xcodeコマンドの引数やサポート状況は、Xcodeのコマンドラインツールリファレンスで確認してください。

発売責任者が整える例外処理と承認

自動阻断の対象は、テストの目的と受け入れ条件が確認され、失敗した際の担当者と対応が決まっている項目に限定します。原因の特定が必要な結果は、レポートを保全してQAまたはテスト所有者へ割り当て、手動確認後に継続・停止を判断する経路を用意してください。

設定変更時は、申請者、レビュー担当、リリース承認者、適用範囲を記録します。テストレポートが取得できない、Test PlanとCI状態が一致しない、再現性を確認できないといった場合の扱いも決めておきます。証跡が不足したまま自動阻断だけを強化すると、失敗の理由を追えず、運用上の判断を検証できません。

注意：Test Planの重大度は品質保証そのものではありません。ゲートを通過した事実だけを、アプリ全体に不具合がない証明として扱わないでください。

技術責任者が確認する受け入れ記録

よくある判断

Xcode 27.2の設定はどこで確認しますか？
対象のTest Planを編集し、アプリクラッシュの重大度に関する設定を確認します。選択肢の名称や適用範囲はAppleのリリースノートと現行画面で照合し、プロジェクトで使う設定を記録します。設定変更後は、CIの結果まで別途検証します。

XCTest UIテストのクラッシュをCI失敗にすべきですか？
テストの期待結果と、その段階で失敗扱いにする根拠がそろっている場合に限って失敗条件にします。クラッシュを検出するテストと、クラッシュを予期しない通常のUIテストは目的が異なるため、同じ扱いに固定せず、テスト所有者とQA責任者が分類します。

PRとリリースで異なるゲートを使えますか？
使えます。PRでは変更確認の条件、回帰では調査と担当割り当て、リリースでは受け入れ条件と例外承認を定義します。ただし、各工程でCIが結果をどう判定するかは、Test Planの設定とは切り分けて実行環境で確認してください。

設定がCIの状態に反映されたことをどう確かめますか？
隔離したジョブで代表的なテストを実行し、Xcodeのバージョン、Test Plan、実行先、結果レポート、CIの最終状態を一組の記録として保存します。設定と結果の対応が再現でき、承認者と例外時の手順が決まるまでは、リリースを自動で止める条件にしないでください。

導入判断では、環境とTest Plan、期待結果、保存した実行記録、CI上の状態、例外時の担当者がそろっているかを確認します。代表的なタスクで期待した状態を再現できない場合は、適用範囲を広げず、設定またはパイプラインの判定条件を見直します。

この記事は2026年11月2日に更新し、AppleのXcode 27リリースノート、Xcode 27.2リリースノート、システム要件を確認しています。チーム固有のMac CI実測値は提供されていないため、実測結果としての比較や性能値は掲載していません。

既存のMacを使う方法は、社内でハードウェアを保有し、保守や環境管理を続ける負担があります。汎用の仮想環境では、実機のMacを使う前提のテストをそのまま検証できるとは限らず、共有CI機では他のジョブとの競合や管理責任も考慮が必要です。検証用環境を一時的に確保したい場合は、購入と保守の負担、必要期間、実機要件を先に比較し、条件に合えばViewMiniのMac環境を候補として確認してください。利用する構成が対象のテストに適合するかは、導入前に個別に検証する必要があります。

よくある質問