App Store Connectアップロード失敗：2026年対処法
「Archiveは成功したのにApp Store Connectにビルドが出ない」という症状では、すぐに証明書やビルド番号を変更しないでください。
最も確実な解決策は、アーカイブ検証、アカウント権限、コード署名、転送、Apple側の処理を分離し、元のエラーと同じアーカイブで順番に確認することです。 ローカルでは成功し、SSHや自動化タスクだけ失敗する場合は、同じプロジェクトとアーカイブを保った遠隔Mac環境で対照検証します。
初めてApp Store Connectへ送信する独立開発者、XcodeやTransporterのログ位置が分からない開発者に向いています。TestFlight配布やリリース直前に、アップロード経路だけを復旧したい小規模チームにも適しています。
失敗した段階を先に分ける
App Store Connectへのアップロードは、1つの処理に見えても、実際には複数の段階に分かれます。
- Archive：配布用アーカイブを作成できるか
- Validate App：アーカイブの内容と配布条件を検証できるか
- Upload：Xcode、Transporter、コマンドラインなどで転送できるか
- Processing：App Store Connect側でビルドを処理できるか
Appleは、アップロード後のビルドを処理し、完了後にApp Store Connectへ表示すると説明しています。そのため、転送完了の表示だけではTestFlightで利用できる状態とは限りません。 (developer.apple.com)
最初に次の情報を保存します。
- エラー全文とエラーコード
- 発生日時
- 使用したツール名
- アプリのバージョン番号
- ビルド番号
- 対象のアーカイブファイル
- 実行したMac、ログイン方法、SSHやCIの有無
同じ失敗を何度も再現するために、先にビルド番号を増やす方法は避けます。原因が処理段階にある場合、再ビルドしても新しい変数が増えるだけです。
注意
Appleの公式状態がFailedの場合、詳細画面のエラー、警告、情報を確認してから再送信します。アップロード失敗時は、次の送信で同じビルド番号を再利用できる場合があります。 (developer.apple.com)
Xcodeの成功と送信成功を同じにしない
なぜXcodeでアーカイブに成功しても送信できないのか
通常のBuildが成功しても、配布用アーカイブが正しいとは限りません。シミュレーターで動くことも、App Store Connectへ提出できることの証明にはなりません。
Xcode Organizerで、次の順に確認します。
- 対象スキームが配布対象のアプリになっているか確認します。
Release設定でArchiveを作成します。- Organizerからアーカイブを選択します。
Validate Appを実行します。- 検証ログの最初のエラーを保存します。
- 修正後、同じ条件でArchiveとValidate Appを再実行します。
iOSアプリをTestFlightや顧客配布用にアップロードする場合、Appleが受け付けるXcodeの条件にも注意が必要です。Appleの現行案内では、2026年からApp Store ConnectへのアップロードにXcode 14以降が必要とされています。対象プラットフォームによって、ビルドに必要なXcodeとアップロードに使えるXcodeの条件も異なります。 (developer.apple.com)
リリース設定で確認する項目
- DebugではなくRelease構成になっているか
- iOS、macOS、Mac Catalystなどの対象が一致しているか
- 必須リソースがアーカイブに含まれているか
- 埋め込みフレームワークや拡張機能の署名が揃っているか
- 使用していないターゲットがアーカイブへ混入していないか
- アーカイブ内のBundle IDとApp Store Connectのアプリ記録が一致しているか
ここで失敗する場合、Transporterへ切り替えても直りません。まず配布用アーカイブの内容を修正します。
権限、アプリ記録、コード署名を分けて確認する
アップロード権限が不足している場合
App Store Connectへのビルドアップロードには、Account Holder、Admin、App Manager、Developerなどの権限が関係します。個人登録のアカウントで追加されたユーザーは、Apple Developer Programのチーム権限とApp Store Connect上の権限が同じとは限りません。 (developer.apple.com)
次の順番で確認します。
- Xcodeで選択しているTeamを確認します。
- App Store ConnectのUsers and Accessで対象ユーザーを確認します。
- アプリ単位のアクセス範囲を確認します。
- Account Holderが最新の契約を承認しているか確認します。
- 対象アプリの記録がApp Store Connectに作成済みか確認します。
Appleは、最初のビルドをアップロードする前にアプリ記録を作成する必要があると案内しています。アプリ記録がない状態では、Bundle IDが正しくてもアップロードの関連付けで止まる可能性があります。 (developer.apple.com)
コード署名の不一致を確認する
コード署名では、次の4要素を1つの組み合わせとして確認します。
- Team
- App ID
- Bundle ID
- Distribution CertificateとProvisioning Profile
Provisioning Profileには対応するApp IDと配布証明書が含まれます。App Store用のProfileを作成するときも、開発時に使ったBundle IDと一致するApp IDを選ぶ必要があります。 (developer.apple.com)
自動署名の場合はXcodeが必要なProfileを管理します。手動署名の場合は、プロジェクト設定、ターゲット設定、Profileの内容を個別に照合します。
経験上の注意
秘密鍵をバックアップせずに証明書やProfileをすべて削除するのは危険です。複数のMacやCI環境で共有している署名資産まで失うと、元のエラーとは別の復旧問題が発生します。
バージョン番号とビルド番号の違い
Appleは、アプリバンドル内のBundle IDとバージョン番号をApp Store Connectのアプリおよびバージョン記録との関連付けに使い、ビルド番号でビルドを一意に識別します。値を変更する前に、Archiveに埋め込まれた値を確認してください。 (developer.apple.com)
同じアプリ記録に別のBundle IDで送信している場合、証明書を作り直しても一致しません。先にXcode Organizerのアーカイブ情報とApp Store Connect側のアプリ情報を並べて確認します。
Transporterの転送失敗と処理失敗を分離する
TransporterでiOSアプリのアップロードに失敗した場合
Transporterでは、警告、エラー、配信ログ、過去の配信履歴を確認できます。ログを確認する前に、同じアーカイブをXcode Organizerから送信し、ツール固有の問題か、アーカイブ自体の問題かを分けます。AppleはTransporter、Xcode、コマンドラインツールなど複数のアップロード経路を案内しています。 (developer.apple.com)
確認する順番は次のとおりです。
- 同じアーカイブファイルを使います。
- Transporterの配信ログを保存します。
- Xcode Organizerで同じアーカイブを送信します。
- ログインセッションや認証情報の期限を確認します。
- プロキシ、ファイアウォール、VPNの影響を切り分けます。
- SSH切断後も処理が継続する実行方法になっているか確認します。
- CIやバックグラウンドタスクが終了していないか確認します。
Transporterだけ失敗し、Xcodeでは成功する場合は、アーカイブを作り直す前に認証、セッション、ネットワーク経路、実行ユーザーを確認します。逆に両方で同じ検証エラーが出る場合は、転送ではなくアーカイブまたは署名の問題です。
App Store Connectにビルドが表示されない場合
まずTestFlightのBuild Uploadsと対象アプリのビルド一覧を確認します。Appleの状態表示は、少なくともProcessing、Failed、Completeなどに分かれ、それぞれ対応が異なります。 (developer.apple.com)
- Processing：Apple側で処理中です。24時間を超えて続く場合は、Feedback Assistantまたは開発者サポートへの相談対象です。
- Failed：ビルド処理で問題が発生しています。詳細画面のエラーを修正してから再送信します。
- Complete：処理が完了し、テストに利用できる状態です。
- Invalid Binary：バイナリがアップロード要件を満たしていません。ビルド内容を修正して再送信します。
- Missing Compliance：輸出コンプライアンス情報が不足しています。必要な質問へ回答します。
Processingのまま見えない場合に、同じアーカイブを短時間で連続送信するのは避けます。まずBuild Uploadsの記録、メール通知、バージョン番号、ビルド番号を確認します。Appleは処理完了後に通知し、処理状態をApp Store Connectに表示すると説明しています。 (developer.apple.com)
失敗原因を残さないための確認チェックリスト
以下は、次の送信前にそのまま使える判定用リストです。
- [ ] エラー全文、時刻、ツール、バージョン番号、ビルド番号を保存した
- [ ] Archiveと通常のBuildを別の結果として確認した
- [ ] Xcode OrganizerでValidate Appを実行した
- [ ] App Store Connectに対象アプリ記録がある
- [ ] XcodeのTeamとApp Store Connectの所属チームが一致している
- [ ] Bundle IDとApp IDが一致している
- [ ] Distribution CertificateとProvisioning Profileの組み合わせを確認した
- [ ] 秘密鍵と既存の署名資産をバックアップした
- [ ] 同じアーカイブをXcodeとTransporterで比較した
- [ ] SSHやCIのセッション切断で処理が止まらないことを確認した
- [ ] Build Uploadsの状態が
Failed、Processing、Completeのどれかを確認した - [ ] Missing Complianceなど追加情報の要求を確認した
- [ ] Apple側の処理が長時間続く場合だけサポートへログを提出する準備をした
プロジェクトの署名設定を整理したい場合は、iOSの開発環境に関するヘルプも参照できます。リモート環境でログイン方法や実行履歴を確認する場合は、ProxyMacのコンソールを使い、ローカル実行との差分を残しておくと切り分けやすくなります。
App Store Connectアップロード失敗の多くは、証明書だけを交換すれば解決する問題ではありません。失敗段階を特定し、同じアーカイブを使って修正前後の結果を比較することが、最短の復旧につながります。
特に、現在の環境が一時的なMac、切断されやすいSSHセッション、停止しやすい無人タスクで構成されている場合は、ログを保持できる遠隔Macで同じアーカイブを対照テストする価値があります。手元のMacでは成功するのに自動化環境だけ失敗する場合、環境を毎回作り直す方式は署名状態、認証情報、ログの保存場所が変わりやすいからです。
長期的に大量のビルドを処理する場合や物理デバイス、専用周辺機器が必要な場合は、自前のMacが適しています。一方、リリース直前の復旧、臨時のiOS打包、既存アーカイブの再検証が目的なら、ProxyMacの料金プランを確認し、まず必要な期間だけMac環境を確保する方法が現実的です。
