リモートMac CIのxcresultをどう書き出す？2026年ガイド

今週は、xcodebuild testに専用の結果パッケージ保存先を指定し、テストが失敗しても生成済みの.xcresultをワークフロー成果物としてアップロードしてください。CIの終了ステータスだけで判断せず、成果物をダウンロードしてXcodeまたはxcresulttoolで開けるところまで確認する方法が、調査に必要な情報を残す確実な手順です。

リモートMac CIの担当者は、テスト終了後に結果を回収できるか確認したいはずです。
テスト担当者は、失敗の詳細やログ、プロジェクトで必要なカバレッジ情報を調べたいはずです。
リリース・プラットフォーム担当者は、結果の命名、保管期間、アクセス範囲を決める必要があります。

CI保守担当者は、テスト結果が生成される工程を特定します

.xcresultは通常のビルドログや配布用アーカイブと同じものではありません。AppleはXcodeのテスト結果パッケージについて、テスト結果などを含む形式として案内しており、結果の閲覧にはXcodeやxcresulttoolを利用できます。Appleのテスト実行と結果の解釈に関する説明と、Xcode 11のリリースノートで、結果パッケージの位置づけを確認できます。

最初に、該当ジョブがテストを実行しているかを確認してください。ビルドのみを行うxcodebuildの呼び出しと、xcodebuild testによるテスト実行は区別が必要です。テスト工程がなければ、アップロード設定を追加しても期待したテスト結果パッケージは生成されません。

ビルドログがあるのにXcodeテスト結果パッケージが見当たらない場合は？
まず実行コマンドとジョブの順序を確認します。ログにビルド処理しか記録されていないなら、テスト未実行の可能性があります。テストが実行されている場合は、指定した保存先とアップロード対象のパスが一致しているかを調べます。

プラットフォーム担当者は、命名とアクセス境界を先に定めます

結果ファイルの名前から、どのワークフロー実行、コミット、テスト対象に対応するのかを特定できるようにしてください。保存先をジョブごとに分け、既存ファイルと衝突しない一意のパスを使うと、並列実行で結果が上書きされる事態を避けやすくなります。

保管期間はCIプラットフォームの設定とプロジェクトの運用要件に合わせて決めます。ここでは一律の既定日数を前提にしません。また、テストログや結果パッケージには、テスト名、失敗箇所、添付情報などプロジェクト内部の情報が含まれる場合があります。閲覧できる担当者と、外部共有の可否を成果物の運用ルールに含めてください。

注意：.xcresultをリポジトリのソース領域や、並行する別テストの共有ディレクトリへ出力すると、差分の混入や結果の取り違えにつながります。CIごとに独立した一時領域を使い、成果物の名前にも実行を識別できる情報を含めてください。

ワークフロー担当者は、テスト失敗後もアップロードを実行します

GitHub Actionsのワークフロー成果物は、ビルドやテストの出力を保存し、後からダウンロードするための仕組みです。公式ガイドでは、ファイルやディレクトリをアップロード対象として指定する方法が案内されています。ワークフロー成果物の保存方法を参照し、実際の指定方法は使っているアクションとワークフロー設定に合わせてください。

テストコマンドが失敗すると、通常の成功時条件のままでは後続のアップロード処理が実行されない構成になりえます。失敗時にも成果物を残すには、テスト工程とアップロード工程の条件を確認し、キャンセル時の扱いも含めて設定してください。GitHubのワークフロー式とステータス確認関数の説明では、条件式の評価に関する注意が示されています。

テストが失敗したときに結果パッケージがアップロードされない場合は？
テスト後のステップが失敗時にも実行される条件か、アップロード対象のパスが実際の出力先と一致しているかを確認します。ログだけを保存する設定になっていないかも見直してください。キャッシュは依存データなどの再利用を目的とする仕組みで、調査に使うテスト結果の保管を代替するものではありません。成果物とキャッシュの違いは、GitHub Actionsの成果物に関する概念説明で確認できます。

ビルド担当者は、テストごとに独立した保存先を指定します

xcodebuildの結果パッケージ保存先には、-resultBundlePathを指定します。AppleのXcodeコマンドラインツールのリファレンスで、利用中のXcodeに対応するオプションを確認してください。

xcodebuild test \
  -scheme "<scheme>" \
  -destination "<destination>" \
  -resultBundlePath "$RUNNER_TEMP/<run-id>-<test-task>.xcresult"

<scheme>、<destination>、<run-id>、<test-task>は、実際のプロジェクトやワークフローに合わせて置き換えます。並列テストを実行する場合は、各テストタスクの出力先を分けてください。パスを固定したまま同じ場所を再利用せず、ジョブ開始時に既存の同名ファイルが残っていないことも確認します。

保存先をどのように指定すればよいですか？
テストを実行するコマンドに-resultBundlePathを加え、リポジトリ外の専用パスを指定します。並列処理があるなら、実行識別子やタスク名をパスに含め、別ジョブが同じ結果パッケージを扱わないようにします。

テスト担当者は、ダウンロードしたパッケージを実際に開きます

ワークフロー実行記録から成果物を取得し、macOS上でXcodeまたはxcresulttoolを使って中身を確認します。GitHubのワークフロー実行から成果物をダウンロードする手順に沿って対象の実行を選び、ダウンロード後にファイルが.xcresultとして存在することを確かめてください。

Xcodeの結果ビューでは、テストの概要、失敗したテスト、診断に必要なログを確認します。カバレッジや添付情報は、テスト設定と実際に収集された内容によって有無が異なります。プロジェクトで必要なデータが含まれているかは、成功・失敗の表示だけで済ませず、結果パッケージの中で個別に確かめます。xcresulttoolのサブコマンドや表示項目はXcodeのバージョンに応じて確認し、使用環境のヘルプとAppleの公式リファレンスを照合してください。

リリース担当者は、成功と失敗の両方で受け渡しを検証します

GitHub Actionsの成果物をダウンロードして開けない場合は？
まず成果物の中身とパスを確認し、ディレクトリそのものがアップロードされたのか、対象ファイルだけが選ばれたのかを切り分けます。次に、ダウンロードしたファイルが完全か、手元のXcodeで開けるかを確認します。アップロード工程が実行されていないのか、パスの選択範囲が合わないのか、成果物がすでに削除されたのかを区別すると、原因を絞り込めます。

結果パッケージをアップロード対象に含めるのに、テスト失敗で消えてしまう場合は？
テスト工程の戻り値だけでワークフロー全体を終了させず、失敗後にもアップロード工程へ進む条件にします。テストを意図的に失敗させた実行を用意し、成果物が残ることまで確かめてください。

判断に迷った場合は、次の条件で方式を選びます。

• 各テストタスクに専用パスを用意できるなら、そのパスを-resultBundlePathに指定します。用意できない場合は、まず並列実行を分離するか、一意な出力先を作る設計へ戻します。
• 失敗後にも成果物アップロードを実行できるなら、失敗時の結果を保存する設定にします。実行条件が確認できない場合は、成功時だけのワークフローを本番診断に使わず、失敗ケースで条件を検証します。
• ダウンロードした.xcresultをXcodeまたはxcresulttoolで開けるなら、受け渡し経路を合格とします。開けない場合は、生成、アップロード、ダウンロードのどこで欠けたかをログとパスで特定します。

運用上の確認では、テスト成功時だけでなく、意図した失敗時にも成果物が取得できることを受け入れ条件にしてください。画面上のワークフロー状態が「失敗」でも、結果パッケージが残り、内容を読めれば診断に使えます。

結果の保存と持ち帰りが確認できたら、次はMac実行環境の維持方法を検討します。手元のMacをCIに使う方式はハードウェアの初期負担があり、稼働状況やネットワークを自分で保つ必要があります。また、共有実行環境ではOSやツールの状態を細かく管理しにくい場合があります。長期の安定負荷や物理インターフェースが必須なら自前のMacが適する一方、期間限定の検証や必要な時期だけMac CIを動かしたいなら、VPSMACのリモートMacレンタルも比較対象になります。サービスの利用形態を検討する際は、VPSMACのリモートMac案内とリモートMacのノード一覧を確認し、プロジェクトの実行頻度と保守担当者に合う方法を選んでください。