asc-submission-health

App Store 提出の健全性

このスキルを使用して、リリースを進められない理由を説明し、既存の審査提出を管理します。問題のないリリース実行は asc-release-flow に引き継ぎます。

担当範囲

このスキルの担当範囲は次のとおりです。

• 準備状況の検証とブロッカーの診断；
• パブリック API、Web セッション、手動修復への振り分け；
• 審査状況と履歴；
• キャンセルと再試行の判断。

ステージング、アップロード、公開、提出には asc-release-flow を使用します。スキルを切り替えても、解決済みの対象、認可、検証済みの進捗を引き継いで現在のタスクを続行します。ユーザーがワークフローを最初からやり直す必要はありません。認可済みの修復を続行し、問題が解消したらリリース実行に戻ります。修復が権限の範囲を超える場合にのみ、新たな許可を求めます。

回答の順序

1. バージョンの準備状況が、準備完了、ブロック中、または審査中のいずれかを伝えます。
2. 各ブロッカーと、それを裏付ける証拠を示します。
3. パブリック API での修復と、Web セッションおよび手動での作業を分けます。
4. 診断を確定するために必要な読み取り専用チェックを実行します。診断のみを求められた場合は、証拠と修復コマンドの案を 1 つ報告し、その修復は実行しません。実行が許可されている場合は、修復キューを続行し、完了した作業と残りのブロッカーを報告します。

対象の特定

• APP_ID、バージョン文字列または VERSION_ID、BUILD_ID、プラットフォーム、および判明している SUBMISSION_ID を解決します。
• asc auth login または ASC_* 環境変数で認証を設定します。
• ASC_BYPASS_KEYCHAIN=1 は、リポジトリのテストと分離された検証にのみ使用し、通常のユーザーセッションでは使用しません。
• 対象が特定できたら ID を優先します。アプリ、バージョン、または製品の特定が曖昧な場合は停止します。

準備状況の診断

まず、標準の準備状況レポートを実行します。

asc validate --app "APP_ID" --version "1.2.3" --platform IOS --output table

バージョンが判明している場合は --version-id "VERSION_ID" を使用します。警告を自動化の失敗として扱う必要がある場合は --strict を追加します。

審査専用の診断ツールを使用して、優先順位付きの説明を確認します。

asc review doctor --app "APP_ID" --version "1.2.3" --platform IOS --output table

レポートでビルドまたはバージョンが指摘された場合は、直接証拠を収集します。

asc builds info --build-id "BUILD_ID" --output table
# The attached build and submission are in .data.relationships and .included
asc versions view --version-id "VERSION_ID" --include build,appStoreVersionSubmission --output json

デジタル商品については、関連する製品バリデーターのみを実行します。

asc validate iap --app "APP_ID" --output table
asc validate subscriptions --app "APP_ID" --output table

asc validate が提示する優先順位付きの修正計画を修復キューとして扱います。次の種類のブロッカーに移る前に、現在の種類のブロッカーを修正して検証します。

修復の振り分け

ビルド処理、メタデータ、スクリーンショット、審査の詳細、暗号化、コンテンツ権利、年齢レーティング、提供状況、またはバージョン単位の製品メタデータがブロッカーの場合は、パブリック API コマンドを使用します。

診断でよくあるブロッカーのいずれか、または初回リリースの提供状況の不足が特定された場合は、references/readiness-repairs.md を読みます。

IAP またはサブスクリプションの検証に失敗した場合、Apple が初回審査への添付を求めている場合、またはバージョン管理された製品を既存の審査提出に含める必要がある場合にのみ、references/digital-goods.md を読みます。

検証で App Privacy に関する注意が報告された場合、またはパブリック API で公開状態を確認できない場合にのみ、references/app-privacy.md を読みます。

検証で Game Center のコンポーネントまたはバージョンのブロッカーが報告された場合は、asc-release-flow に引き継ぎ、複数項目に関するリファレンスの Prepare every item セクションを参照するよう依頼します。Game Center を一般的な準備状況の修復やデジタル商品の修復に振り分けてはいけません。

パブリック API では対応できない不足に対してのみ、Web セッションのコマンドを使用し、認証済みの Apple Web セッションが必要であることを伝えます。ユーザーが Web セッションによる自動化を断った場合に備えて、手動で App Store Connect を操作する代替手段も提示します。

バージョンが健全か判断する

次の条件を満たしたバージョンは、asc-release-flow に戻せる状態です。

• asc validate にブロッキング要因がない；
• 添付ビルドが VALID である；
• メタデータ、スクリーンショット、アプリ情報、審査の詳細、コンテンツの権利、暗号化、年齢制限、価格、配信状況が解決済みである；
• 該当する asc validate iap および／または asc validate subscriptions のチェックにブロッキング要因がなく、必要なデジタル商品のバージョンが準備されている；
• Game Center のバージョン項目がある場合は、asc-release-flow の複数項目提出リファレンスを使って確認されている；
• App Privacy が確認済み、または公開済みである。

1つのバリデーターが正常終了しただけで、バージョンが準備完了だと判断しないでください。ウェブセッションまたは手動での確認がまだ必要な警告があれば報告してください。

審査を監視する

提出 ID が不明な場合は、アプリ単位のステータスを使用します。

asc review status --app "APP_ID" --version "1.2.3" --platform IOS --output table

利用可能な場合は、正確な提出 ID またはバージョン ID を使用します。

asc submit status --id "SUBMISSION_ID" --output table
asc submit status --version-id "VERSION_ID" --output table

ビルドおよび審査の周辺状況を確認するには、リリースダッシュボードを使用します。

asc status --app "APP_ID" --include builds,appstore,submission,review --output table

審査結果を待つには、結果が確定するまでポーリングします。承認時はコマンドが 0、却下時は 1、タイムアウト時点で保留中の場合は 7 で終了します。

asc status --app "APP_ID" --until review-done --timeout 2h --output json

ステータス JSON の summary.nextCommands には、App Store Connect を変更するかどうかが示された、推奨される次の手順が一覧表示されます。変更を伴う提案は、ユーザーの承認が必要な提案として扱ってください。

履歴を使って、現在の停滞状態と、以前に却下または完了した提出を区別します。

asc review history --app "APP_ID" --version "1.2.3" --paginate --output table

健全でない提出をキャンセルする

キャンセルする前に、該当するアクティブな提出を正確に特定してください。まずステータスをプレビューし、その後で確認を求めます。

asc submit status --id "SUBMISSION_ID" --output table
asc submit cancel --id "SUBMISSION_ID" --confirm

バージョンから特定する場合、最新の審査提出ルックアップではアプリを指定してください。

asc submit status --version-id "VERSION_ID" --output table
asc submit cancel --version-id "VERSION_ID" --app "APP_ID" --confirm

該当する審査提出がすでに特定できている場合は、低レベルの同等コマンドが有効です。

asc review submissions-cancel --id "SUBMISSION_ID" --confirm

審査に予想以上の時間がかかっているという理由だけで、提出をキャンセルしないでください。まず状態とユーザーの意図を確認してください。

再試行のタイミングを判断する

専用の再試行コマンドはありません。次の手順を使用してください。

1. アクティブな提出を取り下げる必要がある場合にのみキャンセルします。
2. 確認済みのブロッキング要因を修正します。
3. asc validate と関連する製品バリデーターを再実行します。
4. 該当バージョンまたは審査項目をすでに所有しているアクティブな提出がないことを確認します。
5. 健全なバージョンと、保持されている SUBMISSION_ID があればそれも添えて、提出の実行を asc-release-flow に引き継ぎます。確認済みの READY_FOR_REVIEW の下書きを再利用し、該当する下書きまたはアクティブな提出がない場合にのみ提出を作成します。

よくある失敗の対処先

症状	最初に確認する情報	修正方法
バージョンの状態が無効	asc validate、asc review doctor	順番に実施する準備作業
輸出コンプライアンスの承認が必要	ビルド情報と暗号化の申告	準備作業
複数のアプリ情報が見つかった	asc apps info list --app "APP_ID"	正確なアプリ情報 ID を特定
IAP またはサブスクリプションの準備ができていない	製品バリデーター	デジタル商品リファレンス
Game Center のコンポーネントまたはバージョンの準備ができていない	asc validate の診断	asc-release-flow の複数項目の準備セクション
App Privacy の公開状態が不明	検証時の注意事項	App Privacy リファレンス
審査が停滞しているように見える	審査ステータスと履歴	監視する。証拠と承認がある場合にのみキャンセルする

ガードレール

• 削除済みの submit-preflight または submit-create ショートカットを使用しないでください。
• このスキルから提出しないでください。健全なバージョンの実行を asc-release-flow に戻してください。
• ウェブセッションの自動化を、公開されている App Store Connect API のカバレッジとして扱わないでください。
• 以前の提出状態とブロッキング要因の修正を確認するまで、再試行しないでください。
• 人による診断には --output table を、自動化には JSON を使用してください。
• macOS の場合は、同じ健全性のライフサイクルを維持しつつ --platform MAC_OS を使用してください。