TestFlightへ.ipaアップロード時に「Asset validation failed (90046) / Invalid Code Signing Entitlements」で失敗する原因と対処を解説します。aps-environmentがdevelopmentのまま提出されているケースをproductionへ修正し、Releaseで再ArchiveしてTransporterで通す手順とチェックポイントをまとめます。
起きている現象（90046 / Invalid Code Signing Entitlements）
Xcodeを更新した後や、Windows側で生成した.ipaをmacOSのTransporterへコピーしてアップロードする運用に切り替えた後に、次のようなエラーで止まることがあります。
- Asset validation failed (90046)
- Invalid Code Signing Entitlements
- 詳細ログに
aps-environmentがdevelopmentになっている、iOSではサポートされない／App Store側で拒否される、などの文言が出る
この手のエラーは「Transporterが悪い」「コピーした.ipaが壊れた」ではなく、ほとんどが提出用ビルドの署名・Entitlementsが“開発用”になっていることが原因です。
結論：App Store Connect提出用は“配布用署名”＋“production Entitlements”が必須
TestFlight（App Store Connect）にアップロードするビルドは、内部テストの印象が強いものの、扱いはあくまで配布用（Release/Distribution）です。Push通知（APNs）のEntitlementsもproduction（本番）である必要があります。
問題のポイントはここです。
| 項目 | 開発用（NGになりやすい） | 提出用（OK） |
|---|---|---|
| ビルド構成 | Debug / 開発向け設定 | Release / 配布向け設定 |
| 署名 | Development証明書・開発用プロビジョニング | Distribution（App Store）証明書・App Store用プロビジョニング |
| APNs Entitlements | aps-environment=development | aps-environment=production |
具体的には、Entitlements.plist（または署名時に使われるEntitlements定義）で、次の値を修正します。
<key>aps-environment</key>
<string>development</string>
↓ これに変更
<key>aps-environment</key>
<string>production</string>
そして、修正後は必ずRelease（配布用）で再Archive/再発行して、新しい.ipaを作り直す必要があります（.ipaの中身だけを編集すると署名が壊れるためです）。
なぜ「aps-environment=development」だと弾かれるのか
aps-environmentは、Push通知（APNs）を使うアプリに付与されるEntitlementsの1つで、APNsの接続先（開発サンドボックスか本番か）を示します。
- development：開発・デバッグ用（サンドボックス）
- production：配布・運用用（本番）
TestFlightやApp Storeに提出されるビルドは、Apple側のバリデーションで「配布用ビルドとして妥当なEntitlementsか」を検査されます。配布ビルドに開発用Entitlementsが混ざると、“提出物として不正”と判断され、90046のようなエラーで拒否されます。
まずやるべき診断：.ipa内のEntitlementsを確認する
「本当に.ipaのEntitlementsがdevelopmentなのか？」を確認すると、原因が一気に絞れます。macOSで次の手順を試してください（Transporterで落ちた直後の.ipaが対象です）。
.ipaを展開してアプリ本体の署名情報を見る
- .ipaを作業用フォルダへコピー
- .ipaをzipとして展開（中に
Payloadフォルダが出ます） .appに対してcodesignでEntitlementsを表示
mkdir -p /tmp/ipa_check
cd /tmp/ipa_check
# .ipaを展開（例：YourApp.ipa）
unzip -q /path/to/YourApp.ipa
# .appのパスを確認
ls Payload
# Entitlementsを表示（XMLが出ます）
codesign -d --entitlements :- "Payload/YourApp.app" 2>/dev/null
出力の中に次のような行があれば、今回の症状に一致します。
<key>aps-environment</key>
<string>development</string>
ここでdevelopmentになっているのに提出しようとしている場合、アップロード側（Transporter）ではなく、ビルド／署名の作り方を直すのが最短です。
解決手順：EntitlementsをproductionにしてReleaseで.ipaを作り直す
ここからが本題です。Visual Studio（Xamarin.iOS / .NET MAUIなど）でiOSアプリを作っている場合でも、やることはシンプルで、次の2点を揃えます。
- Entitlementsを提出向け（production）にする
- Release（配布用）として署名・Archiveし直す
Entitlements.plistの「aps-environment」をproductionへ変更
プロジェクト内の Entitlements.plist（名前はプロジェクトによって異なります）を開き、該当キーを修正します。
- 修正前：
development - 修正後：
production
差分のイメージです。
- <string>development</string>
+ <string>production</string>
もしEntitlementsファイルが複数ある場合は、Release構成で参照されるEntitlementsを修正してください（Debug用Entitlementsだけ直しても提出用は変わりません）。
Release構成の署名設定（Distribution / App Store）を見直す
aps-environmentがdevelopmentになってしまう背景には、開発用プロビジョニングで署名されている、またはReleaseなのにDebug向け設定を参照している、という構成ミスがよくあります。次の表をチェックして、提出用に揃えましょう。
| チェック項目 | 目安 | 見落としポイント |
|---|---|---|
| 構成 | Release | ビルドはReleaseでも、署名設定がDebugのまま残っていることがある |
| 署名Identity | Apple Distribution / iPhone Distribution | “Development”が混ざるとEntitlementsも開発寄りになりやすい |
| Provisioning Profile | App Store用（Distribution） | Ad HocやDevelopmentを選ぶと提出用として不整合になりやすい |
| Entitlements適用 | ReleaseでproductionのEntitlementsを参照 | Debug/Releaseで別ファイルを使う場合、参照先の切り替え漏れが多い |
Visual Studioの画面上では、iOSプロジェクトの設定で「Bundle Signing」や「Signing Identity」「Provisioning profile」を構成（Debug/Release）ごとに確認できることが多いです。Release側が提出用（Distribution/App Store）を指しているかを最優先で確認してください。
修正後は必ず再Archive/再発行して新しい.ipaを作る
Entitlementsはコード署名の一部です。すでに作成済みの.ipaを後から編集しても、署名が一致しなくなります。その結果、別のエラー（署名不正）に変わるだけで、根本解決にはなりません。
そのため、次を徹底します。
- Entitlements修正
- Release構成でArchive/Publish（配布用）を実行
- 新しく生成された.ipaをアップロードに使う
作り直した.ipaについて、前述のcodesign確認をもう一度行い、aps-environmentがproductionになっていることを確認すると安心です。
Transporterでアップロードする
新しい.ipaをmacOSへコピーし、Transporterでアップロードします。ここでポイントは、アップロード前に.ipaを“作り直していること”です。同じファイルを何度投げても通りません。
- Transporterを起動
- .ipaをドラッグ＆ドロップ
- 配信（Deliver）を実行
修正が正しければ、90046は解消し、App Store Connect側で処理が進むはずです。
補足：Push通知を使わないなら「aps-environment自体を外す」選択肢もある
Push通知を使わないアプリであれば、そもそもaps-environmentが不要です。不要なEntitlementが入っていると、提出時の検査ポイントが増えて事故りやすくなります。
| アプリの状況 | 推奨 | 理由 |
|---|---|---|
| Push通知を使う | aps-environment=productionで提出 | TestFlight/App Storeは配布扱いのため |
| Push通知を使わない | aps-environmentをEntitlementsから削除 | 不要な権限を減らし、審査・バリデーションのリスクを下げる |
ただし、過去にPushを使っていた名残がある場合は、Apple Developer側のApp ID設定（Capabilities）や、プロジェクトの設定にもPushが残っていることがあります。提出時に余計なEntitlementsが付与されないよう、設定も合わせて整理すると安全です。
よくあるハマりどころ（再発しやすいポイント）
- Debug用のEntitlementsだけ直していた：Releaseで別ファイルを参照していると、提出用は変わりません。
- Releaseなのに開発用プロビジョニングで署名していた：結果として
aps-environment=developmentが入りやすくなります。 - “TestFlight=テストだからdevelopmentでOK”と思い込んでいた：TestFlightは配布フローの一部で、提出用の整合性が求められます。
- .ipaを後から編集して直そうとした：Entitlementsは署名に含まれるため、基本は再ビルドが必要です（編集するなら再署名まで必要）。
- Windows→Macへのコピーが原因だと思い込んだ：通常のファイルコピーで署名が壊れることはありません。中身の設定（署名/Entitlements）が本丸です。
提出前チェックリスト（この順番で見ると早い）
次のチェックを通してからTransporterへ渡すと、90046系の事故をかなり防げます。
| チェック | 確認方法 | OKの目安 |
|---|---|---|
| Releaseでビルドしたか | Visual Studioの構成を確認 | Release |
| Distribution（App Store）で署名されているか | Signing Identity / Provisioning profile | Apple Distribution + App Store用プロビジョニング |
| Entitlementsにdevelopmentが残っていないか | codesign -d --entitlements :- | aps-environment=production（Push使用時） |
| 不要なEntitlementが入っていないか | Entitlements.plistを棚卸し | 使う機能だけが最小限で入っている |
よくある質問
productionに変えると、開発中のPush通知テストに影響しますか？
影響します。開発中はサンドボックス（development）でテストし、提出用はproductionにするのが基本です。実運用では、Debug用とRelease用でEntitlementsを分ける（例：Debugはdevelopment、Releaseはproduction）と、開発と提出を両立できます。
TestFlightなのに“本番”扱いなのはなぜ？
TestFlightは「配布前のテスト」ですが、配布の仕組み自体はApp Store Connectを通ります。Apple側が配布ビルドとして整合性を検証するため、開発用Entitlementsが混ざると弾かれます。
TransporterではなくXcode Organizerから上げれば回避できますか？
アップロード手段を変えても、提出物（.ipa/.xcarchive）の署名・Entitlementsが不正なら同じく失敗します。まずはビルド成果物を正しく作ることが最優先です。
まとめ
「Asset validation failed (90046) / Invalid Code Signing Entitlements」は、提出用ビルドに開発用Entitlementsが混ざっているときに起きやすいエラーです。特にaps-environmentがdevelopmentになっている場合は、Entitlementsをproductionへ修正し、Release（配布用）として再Archive/再発行してからアップロードすれば解決できます。
コメント