App Storeメタデータ拒否の対処法:2.3.x、2.3.7、4.3、5.2.1を修正する
メールが届きます。ステータスはMetadata Rejectedに変わり、Resolution Centerのメモにはわざわざ調べないとわからないガイドライン番号が書かれています。良い知らせは、メタデータ拒否は比較的早く解決できるということです。ビルドを再アップロードするのではなく、バージョン情報を編集して再提出するだけで済みます。
まず確認すべきはResolution Centerメッセージ内のガイドライン番号です。それによってどのフィールドを直すべきかが正確にわかります。この記事では、リスティング拒否で最もよく見る4つのガイドラインを取り上げます。ガイドライン番号は時間とともに振り直されることがあるため、ここで扱う内容は現行のApp Store Review Guidelinesに基づいています。
まず仕組みから:「Metadata Rejected」とは実際どういう意味か
Metadata Rejectedというステータスは、コンパイル済みのアプリではなく、ストアリスティング（アプリ名、サブタイトル、キーワード、説明文、スクリーンショット、プレビュー、URLなど）を指しています。フラグが立っているのはメタデータなので、新しいビルドは不要です。App Store Connectで指摘されたフィールドを編集し、既存のビルドをそのバージョンに紐づけたまま再提出すればいいだけです。
はっきり言っておくべき注意点が2つあります。まず、再提出しても審査キューには再び戻ることになります。つまりビルドは不要でも、審査は不要ではありません。人間または自動のチェックが再び行われます。次に、Appleが指摘した1つのフィールドを直しただけでは、リスティングの他の部分が免罪されるわけではありません。次のパスでは別のガイドラインが引っかかることもあります。指摘された一文だけでなく、リスティング全体をこの機会にきれいにしておきましょう。
ガイドライン2.3.3:スクリーンショットはアプリの使用中の様子を示すこと
発生する原因。スクリーンショットがアプリの実際の動作を示していない場合に起こります。典型的なのは、1枚目がスプラッシュ画面やログイン画面、あるいはキャッチコピーだけでUIがまったく写っていないタイトルアートになっているケースです。また、アプリに存在しない機能を写している場合や、別プラットフォームのデバイスやインターフェースを参照している場合にも発生します。
修正前:1枚目がグラデーションの背景にロゴを中央配置し、「週の計画を最も賢く立てる方法」という言葉だけで、アプリのUIがどこにも写っていません。
修正後:1枚目はコアフローの実際の画面（実データが入力された週表示ビュー）で、デバイスの上に短いキャプションでメリットを示しています。レビュアー(そしてユーザー)がサムネイルからアプリの機能を理解できるようにします。マーケティング用キャプションやデバイスフレームは残してよいですが、その下に写るアプリUIは本物で最新のものにしてください。
これはメタデータの変更です。バージョン情報内の画像を差し替え、再提出すればよく、新しいビルドは不要です。
ガイドライン2.3.7:キーワードはアプリの内容を説明するもので、ゲーム検索狙いではない
発生する原因。これはキーワード濫用に関するガイドラインです。アプリの内容を説明しない語句、たとえば自分が権利を持たない商標、より大きく人気のあるアプリの名前、間違ったフィールドに書かれた価格表現、リーチ目的で入れられた著名人や公人の名前、検索を釣るために詰め込まれた一般語句などでメタデータが水増しされていると発生します。100文字のキーワードフィールドがよくある原因ですが、サブタイトルや名前もフラグの対象になります。アプリ名は30文字までで、価格やプロモーション表現は名前・サブタイトル・スクリーンショットに含めてはいけません。
修正前(キーワードフィールド):自分のカテゴリでより大きな3つのアプリの名前、有名なクリエイターの名前、いくつかの無関係なトレンドワードが並び、どれも自分が実装した機能を説明していません。
修正後:ユーザーが実際にその機能を探すときに検索するであろう語句、つまりアプリが実行するタスク、解決する問題、自分の画面から出てくる名詞にマッピングされたキーワードです。すべての語句が、アプリが実際に行っていることを指すようにします。
修正前(サブタイトル):名指しした競合アプリと自分を比較する一文。
修正後:他ブランドの名前を一切出さず、自分のアプリがもたらす成果を平易な言葉で述べたサブタイトルです。サブタイトルは自分のアプリの文脈を伝える場所であって、他人のトラフィックを借りる場所ではありません。
ガイドライン4.3:スパムおよびほぼ重複したアプリ
発生する原因。4.3は「同一性」に関するものです。都市ごと、チームごと、クライアントごとに別々のバンドルIDでほぼ同一のアプリを複数リリースしている場合(本来は1つのアプリの中でそうしたバリエーションを扱うべきところ)、あるいは提出物がすでに広く流通している何かと見分けがつきにくい場合に発生します。多くはコンセプト自体の問題ですが、重複を可視化させているのはリスティングです。自分のアプリ同士で説明文やスクリーンショットが同一なのは強い兆候になります。
修正前:同じレイアウト、同じ機能リストで、都市名やチーム名を入れ替えただけの文言のアプリが、自分のアカウントに5本並んでいます。
修正後:そうしたバリエーションをアプリ内オプションや購入として持つ1本のアプリにまとめ、それが実際に行う本質的に異なることを説明するリスティングにします。もし本当に別々の製品であるなら、固有名詞の置換だけでなく、スクリーンショットと説明文で実際に何が違うのかをそれぞれのリスティングで示してください。
根本のアプリが本当に薄いリスキンである場合、4.3はメタデータの修正だけでは済まないこともあります。しかし問題がリスティング同士が互いの複製のように見えることであれば、文言とスクリーンショットを差別化することはメタデータの修正で対応できます。
ガイドライン5.2.1:他者の知的財産がメタデータに含まれている
発生する原因。権利を持たない保護された第三者の素材（商標、著作物、模倣した名前など）を、バンドル、デベロッパー名、メタデータのどこかに使用している場合に発生します。よくあるパターンは、リスティング上のアプリやブランドと、実際に提出した組織との間に不一致がある場合で、これによりAppleはその名前を誰が所有しているのかを問うことになります。
修正前:自分が所有していないブランド名やプラットフォーム名を、その検索トラフィックを狙ってアプリのタイトル、サブタイトル、キーワードフィールドに入れています。
修正後:タイトル、サブタイトル、キーワードには自分自身の製品名を使います。第三者のプラットフォームと本当に連携していてそれを伝える必要がある場合は、事実に基づく互換性の記載を許可されている範囲で説明文に留め、名前やサブタイトルには含めません。商標を所有するクライアントのためにアプリを作った場合は、その商標を所有する組織のアカウントから提出するか、そのチームに加えてもらい、販売者名とブランドを一致させてください。
「ビルド不要」の部分をあらためて整理する
これら4項目すべてにおいて、修正がバージョン情報、つまりテキストと画像の範囲に収まるのであれば、App Store Connectで修正し、同じバイナリを再提出すればよいだけです。ビルド番号を上げる必要も、処理を待つ必要もありません。それがメタデータ拒否がもたらす近道です。ただし、再び審査を通ることになるので、拒否を1つずつ潰していくのではなく、再提出する前にこの4項目に照らしてリスティング全体を読み直す価値があります。
Mokbiが役立つところ(そして役立たないところ)
2.3.7のトラブルの多くは、キーワードフィールドやサブタイトルがリーチ狙いで水増しされる執筆段階から始まります。MokbiのAIは、アプリが実際に行っていることをもとにリスティング文言(名前、サブタイトル、キーワード、説明文)を作成します。これにより、そもそもキーワード拒否を招く水増しや他ブランドの流用といった習慣を避けられます。さらにそのコピーを50言語にローカライズするので、市場ごとにキーワードフィールドを手書きし直して同じ罠を繰り返すこともありません。
限界についてもはっきりさせておきます。これは文言に関する2.3.xや5.2.1のフラグの確率を下げるものであり、承認を約束するものではありませんし、ビルドの中身を決めるものでもありません。審査を判断するのはAppleです。規約に沿ったアプリに忠実なコピーが取り除くのは、自ら招く形での不採用の理由にすぎません。Mokbiはリスティングへの自動公開は行いません。コピーとスクリーンショットを生成するので、内容を確認したうえで提出します。