APP STORE CONNECTアップロード失敗
Xcode 26確認リスト

症状 → 最短の解決策

App Store Connectのアップロード失敗は、同じアップロード操作を繰り返す前に、失敗した層を特定してください。まず「アーカイブと検証」「転送」「Apple側のProcessing」「コンプライアンスと提出」に分け、2026年4月28日以降の正式提出ではXcode 26以降と対応SDKを使っているかを確認します。(Apple Developerの提出要件)

Organizerで完了と表示されても、TestFlightに表示される前にApple側の処理が必要です。ローカルのMacで通信が不安定、またはmacOSとXcodeの構成が頻繁に変わる場合は、署名とアップロードを常時稼働するリモートMacへ移すと、再現性を確認しやすくなります。

この確認リストが向いている人

Xcode OrganizerやTransporterでアップロードし、検証、認証、転送のどこで止まったのか分からない個人開発者向けです。fastlaneやシェルスクリプトで自動公開している小規模チーム、安定したMac環境を持たないWindows・Linux開発者にも使えます。

最初に状態を分ける

「アップロードできない」という表示だけでは、原因は特定できません。次の表で現在の状態を確認し、見るべきログと次の操作を分けてください。

<

状態・症状	主な確認場所	次に行う操作	判断
Archiveに失敗	XcodeのIssue Navigator、Archiveログ	ビルド設定、依存関係、署名を修正	再アップロード不要
Validateに失敗	OrganizerのValidationログ	Bundle ID、Team、Profile、Entitlementsを確認	Archiveを再検証
転送中断	OrganizerまたはTransporterのDeliveryログ	認証、API Key権限、接続を確認	Archiveが同一なら再転送
Processing	App Store ConnectのBuild Uploads	直ちに再送せず状態を監視	長時間ならAppleへ確認
Failed	Build Uploadsの詳細	表示されたエラーを修正	エラー解消後に再送
Invalid Binary	TestFlightのビルド詳細	要件、署名、埋め込みコンポーネントを再確認	修正版を再ビルド
Missing Compliance	TestFlightのビルド詳細	輸出コンプライアンスを回答	回答後に提出可否を確認

AppleはProcessingを処理中、Failedを処理後に問題が発生した状態、Completeを処理成功かつテスト可能な状態として説明しています。Processingが24時間を超えて続く場合は、Feedback Assistantへの報告またはApple Developer Supportへの連絡が案内されています。([Apple Developerのビルドアップロード状態の定義](https://developer.apple.com/help/app-store-connect/reference/app-uploads/build-upload-statuses?utm_source=openai))

第一段階：Xcode 26とアーカイブを確認する

2026年4月28日以降、App Store Connectへアップロードする対象プラットフォームのアプリは、Xcode 26以降とiOS 26など対応する26版SDKでビルドする必要があります。Xcode 27 Betaの環境や挙動を、正式提出の基準として扱わないでください。(Apple Developerの今後の提出要件)

確認する場所は、Dockに表示されているXcodeではなく、実際にArchiveを作成した環境です。次の情報を記録してから、検証をやり直してください。

Xcode: <XCODE_VERSION>
SDK: <SDK_VERSION>
macOS: <MACOS_VERSION>
Scheme: <SCHEME_NAME>
Configuration: <CONFIGURATION_NAME>
Bundle ID: <BUNDLE_IDENTIFIER>
Team ID: <TEAM_ID>

XcodeのOrganizerで対象Archiveを開き、Validate Appを実行します。ここで失敗する場合、Transporterへ切り替えても解決しません。まず、Deployment Target、対象プラットフォーム、Swift Packageやバイナリ依存関係が、実際のSDKと矛盾していないか確認してください。

第二段階：署名、Bundle ID、バージョン番号を照合する

Invalid BinaryやValidation Failedでは、主アプリだけを確認して終わらせないことが重要です。Share Extension、Notification Extension、Widget、埋め込みフレームワークなども、各Bundle ID、署名証明書、Provisioning Profile、Entitlementsを個別に確認します。

照合順序は次のとおりです。

1. App Store Connectのアプリレコードが、対象のBundle IDに対応しているか確認します。
2. Archiveに含まれる主アプリと各拡張機能のBundle IDを確認します。
3. Team IDがすべて同じチームを指しているか確認します。
4. Distribution用の署名とProvisioning Profileが、現在の構成に適用されているか確認します。
5. VersionとBuildの値を確認し、古いビルドを選択していないか調べます。
6. ArchiveのOrganizer画面で、署名とEntitlementsの警告を再確認します。

Appleはアップロード時にBundle IDとVersionをアプリやバージョンレコードとの関連付けに使い、Build文字列でビルドを識別すると説明しています。アプリレコードを作成する前には、ビルドを正しく関連付けられません。([Apple Developerのビルドアップロード手順](https://developer.apple.com/help/app-store-connect/manage-builds/upload-builds/?utm_source=openai))

第三段階：Transporterと認証を切り分ける

Transporterの途中停止は、必ずしもArchiveの再作成を意味しません。OrganizerでValidateを通過したArchiveが残っており、Deliveryログだけが通信切断や認証失敗を示しているなら、同じArchiveを再送して確認できます。

一方、API Keyの権限不足、無効化されたキー、対象アプリへのアクセス範囲の不足が表示された場合は、再試行より先にApp Store ConnectのUsers and Accessを確認します。チームキーは権限設定を変更するために、必要に応じて失効させて新しいキーを作成する運用になります。秘密鍵は一度しかダウンロードできないため、スクリプトや公開ログへ直接書き込まないでください。(Apple Developerのアカウント権限)

Organizer、Transporter、fastlaneの使い分けは、次のように考えると安全です。

• Organizer：ArchiveとValidateの関係を画面で追いやすく、単発リリースに向いています。
• Transporter：Deliveryログと履歴を確認しやすく、既存Archiveの再送に向いています。
• fastlaneや自動化コマンド：反復処理に向きますが、認証情報、作業ディレクトリ、終了コード、ログ保存を自分で設計する必要があります。

TransporterはmacOSアプリとして、警告、エラー、Deliveryログ、過去の配送履歴を確認できます。App Store Connect APIを使う場合も、バイナリの転送にはTransporterとJWTを組み合わせる構成が案内されています。([Apple Developerのアップロード方法](https://developer.apple.com/help/app-store-connect/manage-builds/upload-builds/?utm_source=openai))

TestFlightに出ない場合の状態別対応

アップロード後にTestFlightへ表示されない

アップロード完了の通知は、TestFlightで利用可能になったことと同義ではありません。Apple側でProcessingが完了し、App Store ConnectのTestFlightタブにビルドが表示されるまで待つ必要があります。(Apple Developerのビルド管理手順)

Processing中は、同じBuild番号で何度も送らず、Build Uploadsの状態とメール通知を確認します。24時間を超えた場合は、ビルド詳細の状態が変わっていないことを記録し、Feedback AssistantまたはApple Developer Supportへ連絡してください。(Apple Developerのビルドアップロード状態の定義)

Invalid Binaryが表示された場合

Invalid Binaryは、Appleがバイナリを受信したものの、アップロード要件を満たしていない状態です。ビルド詳細のエラーを開き、主アプリだけでなく拡張機能、埋め込みフレームワーク、署名、Entitlementsを確認してから修正版を再ビルドします。(Apple Developerのビルド状態の定義)

Missing Complianceが表示された場合

Missing Complianceは、ビルドに輸出コンプライアンス情報が不足している状態です。TestFlightの対象ビルドでManageを開き、暗号化の利用状況に応じた質問へ回答するか、承認済みの書類を提出します。暗号化を使っていないつもりでも、OS標準の暗号化機能や通信ライブラリの扱いを確認してください。(Apple Developerの輸出コンプライアンス案内)

第四段階：提出前に環境を固定する

一度だけ成功させるのではなく、次の手順を同じ環境で実行し、どの段階で止まったかを保存してください。

1. Xcode、SDK、macOS、Scheme、Configurationを記録します。
2. Archiveを作成し、Archive名と作成時刻を保存します。
3. OrganizerでValidateし、警告とエラーを保存します。
4. OrganizerまたはTransporterでアップロードし、Deliveryログを脱敏して保管します。
5. App Store ConnectのBuild UploadsでProcessing、Failed、Completeの変化を確認します。
6. TestFlightにビルドが表示され、選択可能になることを確認します。
7. Missing Compliance、アプリレコード、契約、アカウント権限を確認してから提出します。

ログには、Bundle IDやTeam IDを残しても構いませんが、API Key、秘密鍵、Apple Accountの認証情報、ローカルの絶対パスは置換してください。公開IssueやCIログへそのまま貼ると、アップロード失敗より大きな認証事故につながります。

ローカルMacと常駐リモートMacの判断

次の条件なら、現在のMacを使い続けても問題ありません。

• XcodeとSDKの構成を固定できる。
• Archive、Validate、Transporterのログを毎回保存できる。
• アップロード時にスリープや接続切断が起きない。
• 証明書とAPI Keyを安全に管理できる。

反対に、作業のたびにXcodeの版が変わる、通信が不安定、Macを使える時間が限られる、同じプロジェクトを定期的に自動公開する場合は、常時稼働する環境を検討してください。MACGPUの[Macレンタル環境](https://macgpu.com/ja/index.html)なら、公開専用のmacOS環境を分けて、ログ保存とツールチェーン固定を行えます。M4環境を確認したい場合は、[M4 Macの利用案内](https://macgpu.com/ja/m4-chumon.html)も判断材料になります。

最終判断：再送、修正、環境移行のどれを選ぶか

• Validate成功、Deliveryログだけ失敗：Archiveを作り直さず、Transporterまたは認証を確認して再送します。
• Validate失敗、Invalid Binary：署名、Bundle ID、SDK、拡張機能を修正し、Archiveを作り直します。
• Processing中：同じビルドを連続送信せず、状態を記録して待ちます。
• Missing Compliance：輸出コンプライアンスを回答し、ビルドを再作成する前に解決できるか確認します。
• 毎回原因が変わる：ローカル環境の変更履歴と接続状態を疑い、常駐Macへ移したテストを行います。

現在のMacをそのまま使う方法は、物理デバイス接続や画面操作を必要とする開発では有利です。ただし、スリープ、家庭回線の切断、Xcode更新、ディスク容量不足、秘密情報の分散管理が重なると、公開作業の失敗原因を追いにくくなります。

一方、リモートMacは初期設定とアクセス権限の設計が必要で、物理USB機器を常時使う用途には向きません。それでも、反復するArchiveとアップロードを安定したmacOS環境へ集約したい場合は、MACGPUで一時的な公開環境を借りて検証し、継続運用に移す価値があります。まずは現在の失敗ログを四つの層に分け、ローカル環境の問題か、Apple側の処理待ちかを確定してから選んでください。