App Store ConnectでPrivacyInfo.xcprivacyが無効と表示された場合の対処法（2026）

Appleは、無効なプライバシーマニフェストを含む提出について、通知にファイル名とアーカイブ内のパスを示すと説明しています。TN3181の案内を手掛かりに、そのパスから対象を特定してください。App本体、Swift Package、第三者SDKのどれに属するかを切り分け、該当するファイルの出所で直してから、Xcode Archiveを作り直して検証します。出所を確かめずに清單を削除したり、別の清單で上書きしたりしないでください。

今週の作業: まず通知のファイル名とパスを照合し、修正後は新しいアーカイブを検証してください。

この記事は、App Store Connectからプライバシーマニフェストの無効通知を受け、対象ファイルを特定したい独立開発者向けです。
第三者SDKを導入・更新した小規模チームや、Xcode Archiveを確認して提出を完了したい開発者にも役立ちます。
リリース前の確認項目を決め、修正の根拠を残したい場合にも使える手順です。

通知に記載されたパスから、どの清單かを特定する

App Store Connectが示すファイルをどう見つけますか？ 通知にあるファイル名とアーカイブ内パスを確認し、Xcode Organizerで該当するArchiveを開いて、記載された場所と照合します。手元のソースツリーにある同名ファイルだけを見て判断せず、実際に提出したアーカイブを確認してください。

Appleのプライバシーマニフェストの配置説明では、アプリやSDKの構成に応じたマニフェストの扱いが示されています。通知のパスがApp本体、組み込まれたパッケージ、またはフレームワークのどこを指すかを見れば、修正すべき責任範囲を絞れます。

App本体とSDKの清單は、役割が同じとは限りません。アプリ自身が使用するAPIやデータ利用の説明を、依存ライブラリの申告と混同しないでください。Appleは、アプリや第三者SDKにプライバシーマニフェストを追加する方法を公式資料で案内しています。

App Store Connectのプライバシーラベルと同じものですか？ いいえ。PrivacyInfo.xcprivacyはアプリやSDKのプライバシー情報を記述するファイルです。App Store Connect上のプライバシーラベルと混同せず、まず通知が指しているファイルそのものを確認してください。データ利用の記述方法は、Appleのマニフェストでのデータ利用説明を参照できます。

App本体とSwift Packageでは、清單の入り方を分けて確認する

Appの主ターゲットに清單を追加したつもりでも、実際にビルドされるターゲットに含まれているとは限りません。Xcodeのターゲット設定と、生成されたアプリバンドル内のファイルを見比べてください。ソースにファイルがあるかだけでなく、Archiveに含まれていることが確認の基準です。

Swift Packageの清單がアーカイブに見当たらない場合は？ Packageのソースディレクトリにファイルを置いただけでは、リソースとして組み込まれていない可能性があります。対象のPackageターゲットでリソースが宣言されているかを確認し、ビルド後の依存パッケージ側に清單が含まれるか調べます。AppleのSwift Packageリソース設定に沿って、Packageの設定とArchiveの中身を照合してください。

Xcodeプロジェクトで見る場所と、Swift Packageで見る場所は異なります。ファイルが存在しているのに提出物から抜ける場合は、追加先のターゲットやリソース設定を疑います。原因を確かめずにApp本体の清單をコピーして補うと、実際の所有元と記述内容が一致しなくなるおそれがあります。

第三者SDKの清單なら、まず依存元に戻る

第三者SDKのPrivacyInfo.xcprivacyが無効な場合、App側を直すべきですか？ 通知のパスがSDKのフレームワークやXCFramework内を指しているなら、まず対象SDKとそのバージョンを特定します。SDK提供元の配布物や公式情報にある清單を確認し、SDK側のファイルが原因なら提供元に修正版の有無を確認してください。App本体の清單を書き換えても、SDK内の無効ファイルが直るとは限りません。

依存関係の記録と通知のパスを照合すると、どのSDKに由来するかを追いやすくなります。更新前のArchiveと修正後のArchiveを混同しないよう、検証対象の構成も記録してください。AppleのTN3181では、無効なマニフェストを調査する際の確認方法が説明されています。

清單が存在するのに無効なら、キーと値を個別に点検する

ファイルがArchiveに入っていても、内容の構造や値が認められない場合は無効になります。Appleの案内に照らして、未知のキー、想定外の値、配列や辞書の形を一項目ずつ確認してください。ファイル全体を書き換える前に、通知と検証結果が示す問題を限定します。

Required reason APIの理由はどう選びますか？ プロジェクトやSDKが実際に使っているAPIを確認し、その利用内容に合うAppleの許可理由だけを記述してください。推測で理由を追加したり、実際には使っていないAPIの理由を並べたりしないでください。対象APIと理由の対応は、AppleのRequired Reason APIの説明で照合できます。

データ収集に関する記述とRequired Reason APIの申告も別の項目です。片方を直せばもう片方も解決する、と決めつけないでください。清單の該当部分、Appleの現行ルール、再現した検証結果を並べて、変更理由を説明できる状態にします。

修正後は新しいXcode Archiveを作り、提出対象を検証する

ソースや依存関係を修正したら、修正前のArchiveを提出に使わず、新しいArchiveを作成します。Organizerで対象を開き、通知にあったパスと修正後のファイルを確認したうえで、Xcodeの提出前検証を実行してください。AppleのXcodeでの配布とアーカイブの手順を確認し、検証対象が今回のビルドであることを確かめます。

Archive内のファイルを直接編集したり、問題に見えるファイルを削除したりする方法は避けてください。アーカイブの変更は署名に影響する可能性があります。署名を伴う変更が必要な例外ケースでは、Appleのコード署名に関する技術資料に従い、変更後の署名状態も確認してください。

修正後の作業は、次の順に進めると原因と結果を追いやすくなります。

• [ ] 通知からファイル名とアーカイブ内パスを記録する。
• [ ] Organizerで通知が指すArchiveを開き、対象ファイルの場所を照合する。
• [ ] ファイルの所有元がApp本体、Swift Package、第三者SDKのどれかを確認する。
• [ ] Appleの現行資料に照らして、清單の構造、キー、値、APIの理由を点検する。
• [ ] 所有元の設定や配布元で修正し、修正内容と依存関係の情報を記録する。
• [ ] 新しいArchiveを作成し、提出前検証で結果を確認する。
• [ ] 検証結果と使用したArchiveをひも付け、次の提出時にも追えるようにする。

修正後、提出ファイルをどう確かめますか？ 新しいArchiveを開き、通知にあったパスのファイルが修正されていることを見てから、Xcodeで提出前検証を行います。検証に通った場合も、提出するArchiveがその検証対象と同一であることを確認してください。リモートMacを使う場合も、この確認記録を残せる手順を組み立てることが重要です。Xcodeの利用環境については、Macでの開発・操作ガイドも参考になります。

App Store Connectの無効通知は、プライバシーラベル全体を見直す合図ではなく、まずArchive内の対象ファイルを見つける手掛かりです。App本体、Swift Package、第三者SDKを分けて修正し、新しいArchiveで検証してください。

手元のMacを使う方法は環境をすぐ確認できる一方、専用のMacを購入すれば初期費用や保守が発生し、共有機ではビルド時間の確保が難しくなることがあります。提出前の短期検証や一時的なビルド環境が必要で、利用期間に合わせてMacを確保したい場合は、Macの選択肢を比較したうえで、日本向けのリモートMac環境を検討できます。継続的に重いビルドを行う場合や物理接続が必要な場合は、手元のMacを維持するほうが適しています。