App Store Connect Missing Compliance：2026年の暗号化輸出申告はどう記入する？

結論：App Store Connect Missing Complianceが表示されたら、まずアプリ全体の暗号化の出所を棚卸しし、AppleのOS機能だけなら通常は追加書類を避け、システム外の暗号化があれば質問票と必要資料を確認してください。
そのうえで、免除対象外の暗号化を使わないと確認できた場合だけ、最終構築物のInfo.plistにITSAppUsesNonExemptEncryptionを適切に反映させます。

この案内は、TestFlightへアップロードした後にMissing Complianceで止まった独立開発者、HTTPSやKeychain、ログインSDK、決済SDKの扱いに迷う開発者、遠隔のMacやCIから繰り返し配布している小規模チーム向けです。暗号化の法的判断そのものを代行するものではなく、申告漏れを避けるためのリリース確認手順として読んでください。

SECTION 01App Store Connect Missing Complianceは何を意味するのか

Missing Complianceは、アップロードした構築物に輸出コンプライアンス情報が不足している状態です。Invalid Binary、署名失敗、処理中の構築物とは別の問題であり、まずAppleが説明する構築物の状態一覧で現在の状態を確認します。

ここで重要なのは、申告対象が業務ロジックのソースコードだけではないことです。最終的に配布する構築物には、次のような要素が含まれます。

• 自社で実装した暗号化処理や独自プロトコル
• Appleのネットワーク、KeychainなどのシステムAPI
• 静的または動的にリンクしたライブラリ
• ログイン、決済、分析、通信保護などの第三者SDK
• SDKが内部で利用する標準暗号アルゴリズム

そのため「自分のコードでAESを呼び出していない」という確認だけでは不十分です。アプリの依存関係、組み込みバイナリ、SDKの公式資料まで見て、アップロードした完全な構築物を対象に判断します。

症状から最初の分岐を決める

判断は、次の三つのルートに分けると作業が止まりにくくなります。

これは「HTTPSなら必ず書類が必要」「HTTPSなら必ず不使用と答える」という単純な分類ではありません。Appleの輸出コンプライアンス概要と、実装・配布地域を照合してください。

SECTION 02第一の場面：Appleのシステム暗号化だけを利用する場合

HTTPS通信をAppleのネットワークフレームワークで行い、認証情報をKeychainに保存する一般的なツールアプリでは、AppleのOSが提供する暗号化機能だけを使っていることがあります。この場合、通常はアプリ独自の暗号アルゴリズムを実装したケースとは異なります。

ただし、次の確認を省略してはいけません。

1. Package.resolved、依存管理ツール、組み込みFrameworkの一覧を保存する。
2. SDKの公式文書で、暗号化処理をSDK自身が実装していないか確認する。
3. Archiveに含まれるFrameworkやバイナリを確認する。
4. アプリの通信、保存、認証機能を簡単に説明できる状態にする。
5. App Store Connectの質問票への回答と、確認資料のスクリーンショットを社内に残す。

特にログインSDKや決済SDKは、アプリ側が暗号化APIを直接呼び出していなくても、内部の通信ライブラリが暗号化処理を含むことがあります。SDK名だけで「Appleのシステム機能だけ」と結論づけないでください。

Appleの暗号化輸出規制への対応文書も確認し、質問票の回答を法的な全面保証と解釈しないことが大切です。

SECTION 03第二の場面：第三者SDKが標準暗号を含む場合

第三者SDKが標準的な暗号アルゴリズムを内包している場合、業務コードでアルゴリズムを呼び出していなくても、直ちに免除扱いにはできません。確認すべきなのは、SDKの名称ではなく、実際に配布するバイナリと有効化された機能です。

調査では、次の順番が有効です。

• SDK公式文書で暗号化機能と輸出に関する説明を読む。
• 静的リンクか動的リンクか、どのバイナリがArchiveへ入るかを確認する。
• 暗号化通信、暗号化保存、鍵交換など、実際に有効な機能を記録する。
• 無料版、地域別版、企業向け機能などで実装が変わらないか確認する。
• App Store Connectの質問票で、免除対象か追加資料が必要かを判定する。

米国の分類や暗号化規制に関係する場合は、BISの暗号化FAQを参照してください。フランスへ配布する場合は、フランスの主管機関が公開する暗号技術に関する規制説明も確認が必要です。

国、機能、事業形態によって扱いが変わるため、SDKを使っているという一事だけで「必ず提出不要」または「必ずCCATSが必要」と断定しないでください。

SECTION 04第三の場面：独自暗号や安全機能がアプリの中心にある場合

自社で設計した暗号プロトコル、公認標準に基づかない暗号方式、または安全な通信・暗号化保存そのものが主要機能であるアプリは、先に正式な分類や申告の必要性を確認するべきです。

この場面で避けたいのは、Info.plistを変更して質問を消すことです。設定キーは構築物の情報を正しく伝えるためのものであり、実際の暗号化機能を別の扱いに変える回避策ではありません。

資料を準備するときは、少なくとも次を分離して説明します。

• 暗号化方式の概要と、標準方式か独自方式か
• アプリ内で暗号化を使う機能
• 組み込みSDKやライブラリの役割
• 配布地域と対象ユーザー
• Appleでの申告に使う情報
• 米国の分類やフランスの申告など、各管轄で必要になり得る情報

CCATS、フランスの暗号化申告、AppleのApp Review向けコード確認は、同じ手続きではありません。目的と提出先が異なるため、疑義が残る場合は輸出管理の経験を持つ専門家へ相談してください。

SECTION 05TestFlightでの申告とInfo.plistの確認手順

1. 構築物の詳細画面で状態を確認する

App Store Connectで対象の構築物を開き、Missing Complianceが表示されていることを確認します。署名失敗やバイナリ不正と混同すると、証明書を作り直しても解決しません。

2. 暗号化の出所を一覧化する

自社コード、Apple API、リンク済みライブラリ、第三者SDKを一覧にします。依存関係の更新で暗号化実装が変わる場合もあるため、今回アップロードしたArchiveを基準に記録します。

3. TestFlightの輸出コンプライアンス情報を回答する

AppleのTestFlight向け輸出コンプライアンス情報の手順に従い、質問票へ回答します。すでに承認済みの資料を関連付けられる場合は、その情報を指定します。

4. Info.plistの設定を判断する

ITSAppUsesNonExemptEncryptionは、免除対象外の暗号化を使うかどうかを示すキーです。免除対象外の暗号化を使わないと確認できる場合はNO、該当する暗号化を含む場合はYESを検討します。キーを未設定にした場合は、App Store Connect側で追加確認が必要になることがあります。

AppleのITSAppUsesNonExemptEncryptionキーの説明を確認し、質問を消すためだけにNOを入れないでください。承認コードが発行されているケースでは、ITSEncryptionExportComplianceCodeの利用可否も確認します。

5. Archiveの最終成果物を検査する

Xcodeの設定画面やソース上のInfo.plistだけを根拠にせず、実際にアップロードするArchive内の最終Info.plistを確認します。設定を直した後は既存構築物を再利用せず、新しいArchiveを作成してアップロードします。

6. TestFlightで配布可能状態を再確認する

アップロード後、処理が完了した構築物で輸出コンプライアンス情報が解決されているか確認します。内部テスターへ配布できるかは、構築物の状態と処理結果に依存するため、Missing Complianceの表示が残ったまま配布作業を進めないでください。

注意：遠隔のMacで作業する場合、ログや画面キャプチャにAppleアカウント、Bundle ID、API Key、承認コード、SDKの非公開名称を残さないでください。共有用の記録では値をマスキングし、原本はアクセス権を制限して保管します。

SECTION 06FAQ：よくある分岐を先に確認する

TestFlightでMissing Complianceが表示された後も内部テスターへ配布できますか？

表示があるだけで、すべてのケースを同じように扱うことはできません。構築物の詳細画面から輸出コンプライアンス情報を回答し、処理後の状態が配布可能になったかを確認します。インストールできない場合は、署名やバイナリの問題と決めつけず、構築物の状態も確認してください。

HTTPSとKeychainだけなら、暗号化輸出の質問票はどう回答しますか？

AppleのシステムAPIだけを使い、システム外の暗号化ライブラリやSDK機能を含まないことを確認できるなら、追加書類が必要な暗号化を使うケースとは分けて考えます。ただし、通信SDKや認証SDKが独自実装を持つ場合があるため、依存関係とArchiveの内容を確認してから回答します。

ITSAppUsesNonExemptEncryptionはYESとNOのどちらですか？

免除対象外の暗号化を使わないと確認できる場合はNOを検討し、該当する暗号化を使う場合はYESを検討します。これは質問票を回避するための固定値ではありません。実際の構築物、SDKの仕様、Appleの質問票を一致させることが優先です。

第三者のログインSDKや決済SDKが暗号化を使う場合、何を提出しますか？

まずSDKの公式文書、バイナリ構成、実際に有効な機能、配布地域を確認します。その結果に応じて、App Store Connectの質問票で免除条件を確認し、必要なら暗号化方式や分類に関する資料を準備します。SDK名だけから提出不要とは判断できません。

Info.plistを変更したのに、新しい構築物でも再び聞かれるのはなぜですか？

変更がArchiveへ反映されていない、古い構築物を再アップロードしている、またはSDKの内容が想定と異なる可能性があります。ソースではなく最終ArchiveのInfo.plistを確認し、変更後に新しい構築物を作成してアップロードしてください。

SECTION 07リリース前に使える判定表

次の表は、申告の方向を決めるための作業用です。法的な分類を置き換えるものではなく、調査漏れを見つけるために使います。

SECTION 08遠隔Macの公開作業へ組み込む最終確認

遠隔MacやCIから配布する場合は、単にアップロードが成功したかではなく、合規情報が再現可能な形で反映されたかを確認します。Appleの構築物アップロード手順と、チーム内の公開手順を照合してください。

最終的な結論は、次の三つのいずれかに記録します。質問票への回答だけで処理できた、Info.plistの設定によって同じ確認の繰り返しを減らせる状態になった、または資料の審査が終わるまで配布を保留する状態です。

暗号化情報を含むiOS配布を継続的に行うなら、MACNOXのMac利用プランを使って、同じ環境でArchiveとアップロードの確認を分離する方法もあります。運用を始める前に、アカウント権限、署名資産、ログの保存範囲を決めておくと、合規確認と秘密情報管理を同じ作業に混在させずに済みます。

現在の手元環境だけで公開する方法は、作業者のMacがスリープする、依存SDKやInfo.plistの確認記録が残りにくい、アップロード後のTestFlight状態を担当者が都度確認しなければならない、という欠点があります。特に小規模チームで複数回Archiveを作る場合は、環境の再現性が崩れるとMissing Complianceの再発原因を切り分けにくくなります。

一方、MACNOXのMacをレンタルすれば、必要な期間だけ実際のmacOS環境を使い、Archive、最終Info.plist、アップロード状態を一つの公開作業として確認できます。長期にわたる固定負荷や物理デバイス接続が必要なら自分でMacを所有する方が適する場合もありますが、臨時のiOS配布、検証環境、公開前の再現確認が目的なら、MACNOXの利用手続きを確認してから作業環境を選ぶのが現実的です。

SECTION 09関連記事

• 自動化環境で本番申請前のiOSビルドを確認するチェックリスト
• 継続的インテグレーションでiOSビルドをリモートMacへ移行する手順
• コマンドラインからリモートMacへアプリをデプロイする方法