GitHub Actions arm64 Runnerに固定UDIDがない？2026年のiOS CIはどうする

GitHub公式文書は、macOSのlarger runnerをarm64とIntelに分けて説明し、arm64 Runnerには静的なUUID／UDIDがないとしています。Runnerのアーキテクチャ別UDID条件が問題になるのは、固定されたMacホスト識別子を前提にした工程です。一般的なiOSビルド、シミュレーター検証、App Store向け配信まで一律に止まるわけではありません。まず必要なのがMacの識別子か、実際に使うiPhoneの登録かを切り分けてください。

対象読者は、GitHub ActionsとmacOS Runnerの選定を担うIT担当者、プラットフォームエンジニア、技術責任者です。
既存パイプラインの失敗がRunnerの制限によるものか、署名設定や実機接続によるものかを見極めたい方に向けています。

最終更新：2026年10月4日。 GitHubのRunner仕様と、Appleのデバイス登録・プロビジョニング資料を照合しています。Runnerのラベルや提供状態は変更される可能性があるため、導入時にも公式記録を再確認してください。

「UDIDがない」というエラーだけでRunnerを移行すると、原因を取り違えることがあります。ビルド、署名、端末へのインストール、ストア提出は別々の工程です。失敗ログと署名方式を照らし合わせ、どの条件で止まったかを特定します。

GitHub-hosted macOS Runnerで固定UDIDがないと、iOS開発署名も失敗しますか。
必ずしも失敗しません。開発用プロビジョニングプロファイルに関係するのは、通常、インストール対象となる登録済みiPhoneなどのデバイスです。ビルドMacの固定識別子が必要だと明示する処理がある場合に限り、その依存を別途調べてください。

RunnerのUDIDは、ビルドを実行するMacホストの識別子です。一方、iOS開発署名やAd Hoc配布で問題になるデバイス登録は、アプリをインストールするiPhoneなどが対象です。片方の識別子を、もう片方の代わりとして登録することはできません。

Appleの手順では、開発用プロビジョニングプロファイルを作る際に、開発に使う登録済みデバイスを指定します。開発用プロファイルの作成要件を確認し、テスト端末が対象に含まれているか照合してください。Ad Hoc配布も登録済みデバイスを前提とするため、Ad Hocプロファイルの対象デバイスと実際の端末一覧を一致させます。

Runner MacのUDIDと、iPhoneのテスト用UDIDは何が違うのでしょうか。
MacのUDIDは実行ホストを識別し、iPhoneのUDIDはアプリを入れるテスト端末を識別します。Apple Developerで端末登録が必要な署名フローでは、実際に使うiPhoneの識別子を登録してください。MacのUDIDが固定されないことだけを理由に、iPhoneの登録をやり直す必要はありません。

エラーに「device」や「UDID」とあっても、メッセージが指す対象を決めつけないでください。署名ログ、プロファイルの端末一覧、Runner側の識別情報を個別に確認します。

シミュレーターだけで完結する検証では、物理iPhoneを接続してアプリを入れる工程はありません。したがって、実機向けプロファイルの端末登録要件を、そのままシミュレーター検証に当てはめないでください。失敗時は、シミュレーターのランタイムや署名設定など、該当工程のログを確認します。

App Store向けの提出も、Ad Hoc配布や開発端末へのインストールとは目的が異なります。提出に必要なビルドと署名を確認し、App Store Connectへのビルドアップロード手順に沿って、アップロード後の処理状況と成果物を検証してください。登録端末を含む開発・Ad Hoc用プロファイルの条件を、すべてのストア配信に拡張して判断しないことが重要です。

iOS CIで実機テストを行う場合、GitHub-hosted Runnerに端末を直接つなげられますか。
テストするiPhoneがRunnerに接続され、ジョブから利用できる状態でなければ、USB接続を前提とする実機テストは成立しません。端末が接続可能な専用環境やテスト設備を用意し、デバイス登録、プロファイル、接続確認までを一連の受け入れ条件にしてください。

GitHubの現行資料では、arm64 macOS Runnerに静的UDIDがないことと、Intel macOS Runnerに固定UDIDの選択肢があることが案内されています。GitHubのlarger runner仕様で、対象Runnerのアーキテクチャと現在の提供条件を確認してください。固定UDIDが必要な処理があるからといって、Intel RunnerがすべてのApple向けタスクを解決するわけではありません。実機接続やMac上の専用設定が要件なら、その環境が必要な接続・運用条件を満たすかも検証します。

固定されたMac識別子が必要なGitHub Actionsの処理には、どんなものがありますか。
Runnerのホスト識別子を署名や検証の前提にしている処理がある場合は、固定UDIDの有無が影響し得ます。ただし、要件はワークフローと利用する署名経路に依存します。失敗ログや設定で必要性を確かめてから、Runnerを変更してください。

選択肢は、既存のGitHub-hosted Runnerを使い続ける、固定UDIDの条件を満たすホストを使う、自社管理のMacを自托Runnerとして用意する、専用のリモートMacを検証する、のいずれかです。自托Runnerはホストや認証情報を管理できる一方、パッチ適用、アクセス制御、ジョブ後のクリーンアップも自分たちの責任になります。自托Runnerの運用上の注意を確認してください。特に未信頼のコードを扱うワークフローでは、pull_request_targetと自托Runnerに関するセキュリティ上の警告を踏まえて実行権限を分離します。

ノードへログインできることは、本番CIとして安全である証明にはなりません。証明書やプロビジョニングプロファイルをどのジョブが使えるか、Keychainをどう扱うか、共有端末やワークスペースに前のジョブの情報が残らないかを、それぞれ確認します。Appleのプロファイル管理手順も参照し、使用中のプロファイルと登録デバイスの対応を明らかにしてください。

次の項目を、対象ワークフローで一つずつ確認してください。

• [ ] 失敗ログから、ビルド・署名・インストール・提出のどの工程で止まるかを特定した。
• [ ] エラーが指す識別子がRunner Macか、実際のiPhoneかを確認した。
• [ ] 開発用またはAd Hoc用プロファイルに、対象のテスト端末が登録されている。
• [ ] 実機テストでは、ジョブから端末へ接続し、インストールと起動まで実行できた。
• [ ] 証明書、Keychain、プロファイル、Runnerワークスペースへのアクセス権を確認した。
• [ ] ビルド成功、署名検証、端末へのインストール、提出後の成果物確認を別々に記録した。
• [ ] 自托Runnerでは、未信頼のプルリクエストから署名情報や永続的なホストへアクセスできないことを検証した。

まずはエラーの種類、必要な端末、署名方式、ホスト識別子への依存、実行後に残る証跡を記録します。ビルドとシミュレーター検証だけなら、現在のホストで要件を満たせるかを先に確認します。実機接続が必要なら、端末を利用できる環境でインストールまで試し、固定Mac UDIDが必要なら、その要件を満たすRunnerだけを対象に比較してください。

一時的な検証や特定ワークフローの実機接続が必要な場合、CALMVPSのリモートMacを候補に含める前に、必要な接続方式、署名情報の隔離、利用者権限を確認してください。固定UDIDや実機接続が解決するかは、申込み前に実際のタスク条件と照合する必要があります。長期にわたる高負荷の専用運用や、物理ポートへの直接アクセスが欠かせない場合は、自社保有Macの方が適することもあります。条件が合うかを確かめたい場合は、CALMVPSの料金案内を確認し、必要な環境を具体化したうえで利用方法を相談してください。