【ITニュース解説】How to write App Review notes that stop the "Information Needed" rejection (Guideline 2.1)

システムエンジニアを目指す皆さんにとって、いつか自分の作ったアプリを多くの人に使ってもらうことは大きな目標の一つだろう。しかし、アプリを公開するには、App Storeなどのプラットフォームが行う「アプリ審査」を通過しなければならない。この審査で、もし「Information Needed」（情報不足）という理由でアプリが拒否されたら、どうすれば良いのだろうか。これは、特にシステムエンジニア初心者が直面しやすい問題であり、適切な知識があれば簡単に解決できる。

「Information Needed」という拒否は、実はアプリに重大なバグがあるわけではないことが多い。これは「審査員があなたのアプリを評価するのに必要な情報が足りない」という、審査員からの質問だと捉えることができる。最も一般的な原因は、審査員がアプリを開いた際に、ログイン画面で行き詰まってしまい、アプリの主要な機能にアクセスできないことだ。開発者自身はいつもログイン済みの状態でアプリをテストするため、この点をうっかり見落としがちだ。特に最近増えているAIを活用したアプリや、ノーコード・ローコードツールで開発されたアプリでは、このようなケースが頻繁に発生すると言われている。開発者が自身のデバイスでテストする際には、既にログイン済みでデータも入っている状態だが、審査員は全くの新規ユーザーとして、使ったことのないデバイスからまっさらな状態でアプリを試す。このギャップが、「Information Needed」という拒否の主な原因となるのだ。

では、審査員は何を求めているのだろうか。彼らがスムーズにアプリを評価するために必要な情報は、主に以下の五つだ。

まず一つ目は、動作するデモアカウントである。これは非常に重要で、審査員がすぐにログインしてアプリの機能を確認できるアカウントを提供しなければならない。数週間前に作成したきりの古いアカウントや、メールやSMSで認証コードを受け取る必要があるアカウントは避けるべきだ。審査員は個人のデバイスで認証コードを確認できないため、認証が必要なアカウントは実質的にログインできないのと同じだ。常に最新で、認証不要なデモアカウントを用意することが不可欠だ。

二つ目は、有料機能の場所だ。もしあなたのアプリにサブスクリプションやアプリ内課金などの有料機能がある場合、審査員にその場所と、どのようにアクセスすれば良いかを明確に伝える必要がある。審査員が有料機能を探してアプリ内をさまようことがないよう、具体的なパス（例：「設定」メニューから「アップグレード」をタップ）を指示しよう。

三つ目は、アカウント削除機能の場所だ。これはガイドライン5.1.1(v)という別の項目に関連するが、審査員はよくこの機能の有無も同時に確認する。デモアカウントでログインした場合に、アカウント削除オプションがどこにあるのかを明確に伝えることが、二重の拒否を防ぐことにつながる。

四つ目は、特定のハードウェアを必要とする機能の説明とテスト方法だ。もしあなたのアプリがバーコードスキャナーやBluetoothデバイス、特定のカメラ機能など、物理的な機器と連携して動作する場合、審査員はその機器を持っていない可能性が高い。この場合、その機能が何をするのか、そして可能であればハードウェアなしでその結果を確認する方法（デモモード、サンプルデータ表示など）を説明する必要がある。動画は代わりにはならないが、具体的なテキストでの説明は、何も情報がないよりははるかに良い。

最後に五つ目は、サンドボックス購入パスの正常な完了だ。もしアプリ内課金機能がある場合、審査員はテスト環境（サンドボックス）で実際に購入を試みることがある。この際、提供されているテスト用の商品IDがApp Store Connectの設定と一致しているか、そして購入プロセスが最後までエラーなく完了するかを事前に確認しておく必要がある。購入が途中で失敗したり、無限に処理中になったりすると、別の拒否理由（2.1(b)）につながってしまう。

これらの情報は、App Store Connectの「App Review Information」というセクションに記入する。このセクションは、提出を急ぐあまりに記入が不十分になりがちだが、非常に重要だ。記事には、具体的な記入例のテンプレートも示されている。デモアカウントのユーザー名とパスワード、主要機能へのアクセス方法、有料機能やアカウント削除機能の場所、そしてハードウェア機能に関する説明などを簡潔に記入する。文章の壁のように長々と書くのではなく、三行から五行程度にまとめ、必要な情報がすぐに目に留まるようにすることが大切だ。

アプリを提出する前に、一つ重要なテストをしてほしい。それは、しばらく触っていないデバイスや、完全にログアウトした状態のWebブラウザで、まさに審査員が使うであろうデモアカウントを使ってログインし、アプリを操作してみることだ。もし提供した情報に古くなった部分があれば、審査員が見つける前に自分で発見し、修正することができる。

また、アプリ審査ノートを適切に記入したつもりでも、「Information Needed」の拒否を受けてしまうケースがいくつかある。よくある間違いは以下の四つだ。

一つ目は、デモアカウントのパスワードが期限切れになっているケースだ。多くのデモアカウントは一度作るとそのまま放置されがちだが、バックエンドシステムによってはパスワードやセッションが一定期間で期限切れになったり、テストユーザーの整理スクリプトに巻き込まれて無効になったりすることがある。提出前に必ずデモアカウントが有効であることを確認しよう。

二つ目は、デモアカウントに二段階認証が設定されているケースだ。認証プロバイダのデフォルト設定で新規アカウントに二段階認証が適用されることがあるが、審査員は認証コードを受け取れない。審査用のアカウントだけは二段階認証をオフにするか、これをバイパスする特別な役割を持つアカウントを用意する必要がある。

三つ目は、審査ノートに書かれたUIのパスが、アプリの更新によって古くなっているケースだ。バージョン1.0のために書いたノートが、UIデザインが変更されたバージョン1.3ではもはや正しくない、という状況だ。「画面下の三番目のアイコンをタップ」といった指示は、UIの変更によって簡単に古くなってしまう。頻繁にアプリを更新するならば、提出ごとに三十秒程度の確認を行うべきだ。

四つ目は、審査ノート欄にマーケティング用の宣伝文句を書いてしまうケースだ。この欄はアプリの魅力をアピールする場所ではなく、審査員がアプリを操作するための「道案内」だ。「革新的なAI搭載の生産性向上アプリ！」のような宣伝文句では、審査員はどこをクリックすれば良いか分からず、結局「Information Needed」の拒否につながってしまう。見知らぬ人に道順を教えるように、簡潔で分かりやすい操作手順を記述することが求められる。

最後に、もし「Information Needed」で拒否されても、慌てる必要はない。ほとんどの場合、この種の拒否は新しいアプリのビルド（プログラム自体）を再提出する必要はない。App Store Connectの「Resolution Center」で、必要な情報（デモアカウントや審査ノートの内容）を修正し、返信するだけで審査を再開できることが多い。実際のバグ修正のために新しいビルドサイクルを回すのではなく、情報不足は書類上の修正で対応できることを知っておこう。この知識は、審査プロセスをスムーズに進める上で非常に役立つはずだ。