新しい購読を購入できるところまで確認したのに、App Store Connectで商品だけを審査に提出できない。
最短の判断は、その内課金タイプで初めて提出する商品なら新しいアプリバージョンと同時に提出し、同じタイプの商品がすでに承認済みで、アプリにも承認済みバージョンがあるなら、Add for Reviewから後続商品を単独提出できる可能性があるというものです。Appleが案内する2026年8月29日時点の手順に沿って、商品、ビルド、審査提出の状態を分けて確認します。
この手順を読むべき開発者
初めて消耗型、非消耗型のアプリ内課金、または購読を追加する個人開発者が対象です。すでに有料商品を公開していて、新しい価格帯や購読商品を追加したい開発者にも役立ちます。
リモートMacでビルドと署名を行いながら、内課金審査を再現可能なリリース手順に組み込みたい小規模チームにも向いています。
App Store Connectのアプリ内課金提出は、まず「初回商品」かを判定する
ここでいう「初回」は、アプリ全体で初めてという意味ではなく、内課金タイプごとに、そのタイプで最初に提出する商品かどうかという意味です。消耗型、非消耗型、自動更新購読、非更新購読は、それぞれの初回提出条件を分けて判定します。
Appleの内課金を審査に提出する公式手順に基づく判断は次のとおりです。
- 消耗型の最初の商品は、新しいアプリバージョンと一緒に提出します。
- 非消耗型の最初の商品も、新しいアプリバージョンと一緒に提出します。
- 自動更新購読の最初の商品は、購読グループとアプリバージョンを含む提出物として扱います。
- 非更新購読の最初の商品も、そのタイプで承認済みの商品がない状態では、通常、アプリバージョンとの同時提出が必要です。
- 同じ内課金タイプですでに承認済みの商品があり、アプリにも承認済みバージョンがある場合、後続商品は新しいアプリバージョンなしで提出できる場合があります。
たとえば、自動更新購読をすでに1つ承認済みなら、新しい購読期間や価格帯を追加するときは、初回購読と同じ扱いにはなりません。一方、非消耗型商品が承認済みでも、自動更新購読の初回商品を単独提出できるとは限りません。別のタイプの商品が承認済みであることは、対象タイプの初回条件を満たす根拠になりません。
審査資料をそろえてから草稿を作成する
SandboxやTestFlightで購入が成功しても、審査提出に必要な商品情報がそろったことにはなりません。App Store Connectでは、購入処理の動作確認と、審査用メタデータの準備を別々に扱います。
商品詳細ページで、次の項目を確認します。
- [ ] 商品の状態が、審査提出を進められる状態になっている
- [ ] 表示名、説明、スクリーンショットなどのローカライズ情報を確認した
- [ ] 価格と販売地域の設定が意図した内容になっている
- [ ] 審査担当者が購入機能へ到達できるスクリーンショットを登録した
- [ ] Review Notesに、ログイン情報、操作手順、購入画面までの経路を記載した
- [ ] Product ID、Bundle ID、Team ID、アプリ名、ログ、スクリーンショットから不要な個人情報を除去した
Appleの内課金情報と審査資料の編集要件でも、商品情報と審査に必要な説明は別途確認するよう整理されています。
購読の場合は、購読グループと購読商品との関連付けも確認します。商品がグループに入っていない、あるいは審査担当者が購読画面へ進む方法をReview Notesで説明していない状態では、購入テストが成功していても提出後に確認が止まる可能性があります。
Add for Reviewで今回の提出物を組み立てる
App Store ConnectのAdd for Reviewはどこにありますか。
対象アプリの「収益化」領域から「アプリ内課金」または「購読」を開き、提出したい商品を選択すると、既存の審査提出に追加する操作、または新しい提出草稿を作成する操作へ進めます。商品詳細を保存しただけでは審査待ちにはならないため、商品一覧の状態と提出草稿の内容を確認します。
新しい商品を選んだ後は、次のように整理します。
- 初回商品では、対象の商品、新しいアプリバージョン、審査に使うビルドを同じ提出の流れに入れます。
- 初回の自動更新購読では、購読グループと、そのグループ内の商品が提出対象に含まれているか確認します。
- 後続商品では、対象の内課金タイプに承認済み商品があること、アプリに承認済みバージョンがあることを確認してから、商品単独の提出を検討します。
- すでに草稿がある場合は、その草稿へ追加し、別の審査提出に入っている商品と二重に扱わないようにします。
提出審査の全体概要も参照し、Submit for Reviewを押す直前に、対象商品だけでなく関連するアプリバージョンや購読グループも一覧に含まれているか確認します。
内課金とアプリバージョンは、どのように同じ審査提出へ入れますか。
初回商品なら、先にアプリバージョン側へ審査用ビルドを関連付け、そのバージョンと商品を同じ提出草稿へ追加します。商品だけを選んで提出できるように見えても、初回条件を満たさない場合はアプリバージョンの提出が必要です。
新しいビルドが必要な場合はXcode 26の分配経路を確認する
初回商品を提出する場合や、購入画面の実装を変更した場合は、審査に使用するビルドを先にアップロードします。次の順序で確認すると、商品設定とビルド問題を混同しにくくなります。
- Xcode 26でアーカイブを作成します。
- Bundle ID、署名証明書、Provisioning Profileが対象アプリと一致していることを確認します。
- App Store Connectへビルドをアップロードします。
- ビルドのアップロード状態が処理済みになるまで待ちます。
- アプリバージョンの画面で、審査に使う正しいビルドを選択します。
- 実機または審査用の導線で、商品がアプリ内から表示され、購入画面まで到達できることを確認します。
- Add for Reviewで商品とアプリバージョンの組み合わせを確認し、Submit for Reviewへ進みます。
2026年8月29日時点では、Xcode 27 beta 6のビルドがTestFlightの内部テストおよび外部テストに利用できることと、正式なApp Store顧客向け配信に使えることは同じではありません。App Store Connectのリリースノートで正式な対応状況を確認し、ベータ版のテスト対応を本番提出の対応と解釈しないようにします。
リモートMacを使う場合は、さらに次を確認します。
- [ ] SSHまたは画面共有の接続が切れても、アーカイブとアップロードの作業状態を確認できる
- [ ] 署名証明書とProvisioning Profileの保存場所と有効期限を記録した
- [ ] App Store Connectの認証情報を、開発用アカウントと分離した
- [ ] アップロード後に処理中、処理済み、失敗の状態をApp Store Connectで確認した
- [ ] 接続断後に同じビルドを重複して送らない復旧手順を決めた
Appleが説明するアカウントの役割と権限に照らし、商品編集、提出、証明書管理を同じ担当者へ無制限に集約しないことも重要です。
提出後は商品とビルドの状態を分けて追跡する
ビルドが「処理済み」になっただけでは、内課金審査が完了したとは判断できません。少なくとも、アプリバージョン、内課金商品、購読グループ、審査提出それぞれの状態を確認します。
アプリと提出のステータス定義を基準に、どの対象が待機中なのか、どの対象にメッセージがあるのかを切り分けます。複数の商品とアプリバージョンを同時に提出した場合は、提出全体が止まっているのか、特定の商品だけが問題なのかをMessagesで確認します。
内課金を拒否された場合、アプリのビルドを再アップロードする必要がありますか。
商品情報、Review Notes、スクリーンショット、購入導線の説明だけが問題なら、まず該当する商品を修正します。その後、Update ReviewとResubmitを使って再提出し、変更されていないビルドを自動的に再アップロードしないようにします。
ただし、購入画面が存在しない、商品識別子が誤っている、審査用ビルドで購入導線へ到達できないなど、バイナリ側が原因なら新しいビルドが必要です。拒否理由を商品設定の問題と実装の問題に分けてから、再提出方法を決めます。
次回から再現できる内課金リリースにする
一度提出できた後も、商品タイプごとの履歴が残っていないと、次の追加商品で初回条件を再確認することになります。小規模チームでは、次の登録項目を1つの管理記録にまとめると判断が安定します。
- 商品タイプとProduct ID
- 初回商品か後続商品か
- 承認済み商品の有無
- 関連付けたアプリバージョン
- 購読グループ名
- Review Notesとスクリーンショットの保管場所
- 使用したビルド番号とアップロード結果
- 拒否理由、修正内容、再提出結果
次回の実際の内課金リリースでは、最初に「商品設定」、次に「SandboxまたはTestFlightでの購入確認」、その後に「ビルドアップロード」、最後に「審査提出」を行います。購入テストを終えた時点で公開準備が完了したと扱わず、Add for Reviewの提出対象と審査資料まで確認して初めて完了とします。
現在の環境がWindowsやLinuxだけの場合、Xcodeを実行できず、署名、アーカイブ、アップロードのたびに別のMacを借りる必要が生じます。個人所有のMacでは、常時稼働による管理負担、ストレージ不足、接続できない時間帯が問題になりやすく、クラウド上の一般的なビルド環境では画面操作や細かなApp Store Connect確認が制限されることもあります。
そのため、次回の内課金提出で安定したXcode環境を確保したい場合は、RUVCLOUDのリモートMac利用方法を確認し、必要な期間だけMacをレンタルする方法が現実的です。継続的な高負荷処理、物理的な端末接続、長期間の固定運用が必要なら自前のMacが適していますが、審査前のビルド作成や一時的な公開作業が中心なら、RUVCLOUDの日本向け利用プランで署名、アップロード、復旧手順を一度検証しておくと判断しやすくなります。
最後に、AppleのApp提出要件と最新のリリースノートを確認し、Xcode 27が正式配信に対応したか、内課金提出条件が変更されていないかを提出直前に再確認します。今回の対象が初回商品ならアプリバージョンと同時に、後続商品なら条件を満たしたうえでAdd for Reviewから提出する、という分岐を記録しておけば、次のリリースで同じ迷いを繰り返さずに済みます。