GitHub Actions Xcode 27 RunnerでSimulatorデバイスが見つからない？2026修復ガイド

xcodebuildがdestinationを見つけられず、Simulatorテストを開始できない。
最初に実際のRunnerイメージと活動中のXcodeを確認し、次にRuntime、デバイス一覧、schemeのdestinationを照合してください。Xcodeの再インストールやプロジェクト変更は、その後です。

この記事は、GitHub ActionsのXcode 27 Runnerへ切り替えたCIエンジニア、iOS Simulatorの起動前にエラーが出る開発者、テスト環境をリモートMacへ移すべきか判断するDevOps担当者向けです。

最終更新：2026年10月17日。Runnerの提供状況はGitHubのXcode 27 Runner公式発表、現在のイメージ内容はRunnerイメージのREADME、ツール設定とコンポーネントの確認方法はAppleの開発者向け資料を基に確認しています。

Runnerのログから失敗した層を特定する

まず、失敗を「ビルド失敗」「テスト開始前のdestination解決失敗」「Simulator起動後のテスト失敗」に分けます。エラーが似ていても、直す場所は異なります。

GitHubは2026年10月15日にXcode 27 Runnerイメージの一般提供を発表しました。発表ではmacOS 27上で動作し、xcode-27とxcode-27-xlargeのラベルを提供すること、Apple Silicon Runnerのみであることが示されています。ラベルが一致しても、個々のジョブで実際に選ばれた環境やインストール済みRuntimeまで保証されるわけではありません。公式発表の提供条件を確認し、当該実行のログも見てください。

GitHub Actionsのログで、実際のRunnerラベル、ジョブ開始時の情報、失敗ステップを確認します。ワークフロー実行ログの確認方法に沿って、問題が起きた実行のログを保存してください。workflowファイルに書かれたラベルだけから、実際のイメージ内容を決めつけないことが重要です。

たとえば、同じworkflowでも、ビルドは通るのにテスト用destinationの解決で止まるなら、最初に調べるのはコンパイラーではなく、Runtimeとテスト対象の組み合わせです。対してSimulatorが起動してからテストが失敗する場合は、destinationが見つからない問題とは分けて記録します。

schemeとdestinationの不一致を切り分ける

xcodebuildが一致するdestinationを返さないときは、要求した条件と、そのschemeが実際にテストするtargetの両方を照合します。デバイス名だけを変更して試す前に、エラーがdestinationの解決段階で起きたか確認してください。

xcodebuild -showdestinations -scheme "アプリのscheme名"

出力にある利用可能なdestinationと、workflowやテストツールに渡したデバイス名・OSバージョンを比較します。schemeのテストtargetが想定したAppleプラットフォームを対象にしているかも確認してください。スペル違い、イメージにないOSバージョンの指定、テストtargetとプラットフォームの不一致は、個別に検証します。

Appleの自動テストに関する資料も参照し、schemeとテスト対象の設定を確認します。xcodebuildの出力とプロジェクト設定が食い違うときは、まずCIで選ばれたschemeとテストtargetを明示して、同じ条件で再実行してください。

Runtimeとデバイス一覧を実環境で照合する

Runtimeがないというメッセージが出たら、Runner上で実際に選ばれているXcodeとSimulator Runtimeを調べます。RunnerイメージのREADMEは有用ですが、更新されるため、過去に確認した一覧を今回の実行環境の保証として扱わないでください。Xcode 27 RunnerのREADMEと、ジョブの実出力を突き合わせます。

ジョブに次のコマンドを追加し、結果をログに残してください。

xcrun simctl list runtimes
xcrun simctl list devices available
xcodebuild -showdestinations -scheme "アプリのscheme名"

Runtimeがないのか、必要なデバイス種類がないのか、destinationの指定が実在する組み合わせと異なるのかを判別できます。Runtimeの導入が必要な場合は、独自のダウンロード手順を試す前にAppleの追加Xcodeコンポーネントの入手・インストール手順に従ってください。一時的なRunnerでインストールを毎回行う方式が妥当かどうかは、待ち時間、再現性、保守方法も含めて判断します。

注意：Runnerイメージに含まれるRuntimeやデバイス一覧は更新され得ます。ある日のREADMEや別ジョブの出力を、今回の実行にそのまま当てはめないでください。

活動中のXcodeと実行パスを確認する

複数のXcodeがある場合、Runnerのラベルとコマンドが使用するXcodeが一致しているとは限りません。次の出力を同じジョブログに残し、活動中の開発ディレクトリと実行バージョンを照合します。

xcode-select -p
xcodebuild -version

xcode-select -pが示すパスと、xcodebuild -versionの情報を確認してください。期待したXcodeと異なる場合は、選択中の開発ディレクトリを調整し、同じ確認を再実行します。Appleのコマンドラインツール設定では、利用するXcodeの設定方法を確認できます。

ここでは、原因を混同しないことがポイントです。イメージに複数のXcodeが存在する状態、活動中の開発ディレクトリの選択誤り、選んだXcodeに必要なプラットフォームコンポーネントがない状態は、それぞれ別の証拠で判断します。Runnerのラベルだけを変更して解決したと判断せず、実行パスとRuntimeの両方を再確認してください。

デバイス名と起動後の失敗を分離する

Runtimeが確認できたら、simctlのデバイス一覧とworkflowが指定するデバイス名・OSバージョンを照合します。名称が一致しても、テスト開始前のdestination解決を通過したとは限りません。

デバイス一覧に対象があり、destinationも解決できた後でSimulatorの起動やテストが失敗する場合は、別の障害として扱います。起動前のエラーと起動後の失敗を一つの問題として修正しようとすると、変更の効果を検証できなくなります。ジョブログとテスト結果を保存し、同じ条件で再現できる状態にしてください。

修復後の再実行を受け入れチェックにする

修正のたびに複数箇所を同時に変更せず、同一コミット、同一scheme、記録したRunnerイメージで再実行します。次の項目を満たせない場合は、まだ原因を切り分けられていません。

• [ ] ジョブのログから、実際のRunnerラベルと失敗したステップを確認した。
• [ ] xcode-select -pとxcodebuild -versionで、活動中のXcodeを記録した。
• [ ] simctlでRuntimeと利用可能なデバイスを出力し、対象の有無を照合した。
• [ ] -showdestinationsの出力とscheme、テストtarget、workflowの指定を比較した。
• [ ] 同じコミットとschemeで再実行し、ビルド、destination解決、Simulator起動、テスト結果を別々に確認した。
• [ ] Simulatorの検証結果を、実機での受け入れ試験と混同していない。

運用上の注意：Simulatorテストが成功しても、実機固有の動作や実機での受け入れ確認を置き換えたことにはなりません。必要な実機検証は別の工程として残してください。

リモートMacへ切り替える条件を決める

Runnerイメージの変動、Runtimeの導入制約、ホスト環境を十分に制御できないことは、托管Runnerで再現性を保つうえでの制約です。一方、特定のRunner条件だけが原因だと確認できていない段階で、テスト全体を移すと問題の所在が見えにくくなります。

まず同じコミットとschemeで専用Mac上の再現を試し、活動中のXcode、Runtime、destination、テスト結果を記録してください。そこで動作し、必要なツールチェーンやホスト条件を托管Runnerで満たせないと確認できたら、そのテストジョブだけを移す判断ができます。専用環境でも失敗するなら、Runnerの変更ではなく、schemeやテスト自体に原因が残っている可能性があります。

一時的な再現環境やApple向けCIの実行先を検討する場合は、MACCOMEのリモートMac環境を候補に加えられます。SSHやVNCなどで接続して作業する方法と、手元に実機を用意する方法では、環境の管理範囲や運用負担が異なります。物理接続が必須、または常時固定の実機を長期運用したい場合は、Mac miniを用意する方法も比較対象です。

よくある質問

GitHub ActionsのXcode 27 RunnerでiOS Simulatorが見つからない場合、何から調べればよいですか？

ジョブログで実際のRunnerと失敗ステップを特定し、活動中のXcodeを確認します。その後、Runtimeとデバイス一覧を調べ、schemeのdestination指定と比較してください。workflowに書いたラベルだけでは、その実行環境に目的のRuntimeがあるとは判断できません。

xcode-27 Runnerに入っているSimulator Runtimeを確認する方法は？

ジョブ内でxcrun simctl list runtimesを実行し、Runtimeの一覧をログに出します。併せてxcrun simctl list devices availableを記録すると、利用可能なデバイスも確認できます。Runnerイメージは更新されるため、確認した出力には対象の実行ログとイメージ情報を紐付けてください。

xcodebuildで一致するdestinationがないと表示されたとき、最初に確認する点は何ですか？

-showdestinationsの出力を確認し、指定したデバイス名とOSバージョンが利用可能かを調べます。次にschemeのテストtargetと対象プラットフォームを照合します。Runtimeがない場合とtargetが別プラットフォーム向けの場合では、修正箇所が異なります。

Xcode 27のSimulatorテストをリモートMacに移すべきなのはどんな場合ですか？

Runnerと活動中のXcodeを確認しても必要なRuntimeやホスト条件を満たせない場合に、同じコミットとschemeで専用Mac上の再現を試します。専用環境では安定して動作し、托管Runner側の制約が原因だと確認できたら、そのテストを移すことを検討してください。Simulatorの結果だけで実機検証を省略しないでください。

Runnerイメージ、活動中のXcode、Runtime、destinationの順に記録すれば、修正対象をプロジェクト設定にするか実行環境にするか判断できます。托管Runnerは手軽ですが、イメージの変化やRuntimeの可用性を自分で固定しにくい面があります。再現性のある専用環境が必要なら、MACCOMEのリモートMacで対象テストを試し、移行後もSimulatorと実機の受け入れを分けて運用してください。