App Store審査用デモアカウントの設定方法：審査に通るレビュアー用ログインの作り方（2026年）

アプリの一部でもログインの先にあるなら、App Store審査用デモアカウントはAppleが最初に試した時点で確実に動作しなければなりません。AppleのApp Reviewガイドラインは、デモアカウント情報（またはフル機能のデモモード）の提供と、審査期間中にバックエンドを稼働させておくことを求めています。実際には、期限切れにならず、リアルなデータがすでに入っていて、有料機能やロール別機能すべてにアクセスでき、開発者にしか見えないログインコードを必要としない専用アカウントが必要です。このガイドでは、そのアカウントの作り方、添えるメモの書き方、そしてうまくいかなかったときに他の開発者が直面した問題を紹介します。

Appleは審査用デモアカウントに何を求めているのか？

アプリにログインが必要な場合、Appleは有効なデモ用のユーザー名とパスワードをApp Store Connectの「App審査に関する情報」に入力することを求めており、そのアカウントは期限切れになってはいけません。ガイドライン2.1(a)では、審査期間中にバックエンドを稼働させておくことも求められています。

ガイドライン2.1(a)の文言は「アプリにログインが含まれる場合は、デモアカウント情報を記載してください（そしてバックエンドサービスをオンにしておいてください！）」です。App Store Connectのプラットフォームのバージョン情報リファレンスには、さらに「デモアカウントはApp審査のプロセスで使用され、期限切れになってはならない」「追加のアカウントの詳細はメモ欄に記載する」、メモ欄は「最大4000バイトまで入力できる」と書かれています。「サインインが必要」欄は「アプリの使用にログインが必要な場合」に適用されます。

Appleの完全な審査に関するヘルプページはさらに具体的です。「審査開始前に期限切れになったり変更されたりした認証情報は、提出がリジェクトされる原因になる場合があります。」アプリに管理者と一般ユーザーなど複数のアカウント種別がある場合は、それぞれの認証情報をメモ欄に追加します。自動更新サブスクリプションを販売している場合は、「購入フロー全体を審査できるよう、サブスクリプションが期限切れのデモアカウントを提供してください」とされています。

App審査用のデモアカウントはどう設定するのか？

デモアカウントは、本番環境に専用アカウントを作成し、期限切れやクリーンアップの処理から外し、リアルなデータを入れたうえで、提出前に実際のリリースビルドでサインインして確認する、という手順で設定します。

1. appreview@yourdomain.com のような本番環境の専用アカウントを作成します。誰かが変更する可能性のある個人用やQA用のアカウントは使い回さないでください。
2. パスワードのローテーション、非アクティブアカウントの削除、トライアル期限切れ、不正検知ルールなど、あらゆるクリーンアップ処理の対象から外します。
3. 空の画面がなくなるよう、リアルなコンテンツを入れておきます。審査担当者は目に見えるものでアプリの完成度を判断します。
4. サブスクリプションの状態をAppleのガイダンスに合わせます。サブスクリプションを販売している場合は、ペイウォールと購入フローが表示されるよう、期限切れのサブスクリプションを持つアカウントにします。
5. すべての機能が使える地域に設定するか、地域による違いをメモ欄で説明します。
6. まっさらなデバイスで、提出するリリースビルドそのものを使ってサインインし、メモ欄で触れた機能を一つずつ確認します。
7. 審査が終わるまでパスワードには手を付けないでください。

ログインコード、SMSのOTP、マジックリンク、SSOを使っている場合は？

サインインにワンタイムコードが必要な場合は、提出前に審査用アカウント向けの固定コードをメモ欄に記載してください。Appleは、それがないと「審査を続行するために電話が必要になる場合がある」と警告しており、その電話対応は「通常3〜5営業日以内に完了する」とされています。

メールで送るマジックリンクやSMSのワンタイムコードを使う場合は、審査用アカウントが固定のコードまたはパスワードを受け付けるよう設定し、そのコードをメモ欄に書きます。サードパーティのシングルサインオンサービスを使っている場合、App Store Connectは「そのサービスのデモアカウントのログイン情報も記載する」よう求めています。

銀行、ヘルスケア、その他の規制対象アプリによくあるように、法務上・セキュリティ上の理由でデモアカウントを共有できない場合、ガイドライン2.1(a)では「Appleの事前承認を得たうえで、デモアカウントの代わりに組み込みのデモモードを使用する」ことが認められています。そのデモモードは、機能を絞ったツアーではなく、デモ用データを使って「アプリのすべての機能」を示すものでなければなりません。

App審査にはどのアカウントを渡すべきか？

アプリ内のアカウント種別ごとに期限切れにならないログインを1つずつ渡し、さらにコード、ペイウォール、ハードウェア要件を突破するために必要なものを渡します。以下の表は、構成ごとに何をどこに記載するかをまとめたものです。

デモアカウントに添える審査メモには何を書くべきか？

良い審査メモには、アプリのコンセプト、すべてのログイン情報、ログインコード、ペイウォールへのたどり着き方、各機能の場所、地域による違い、テストしたデバイスが含まれます。以下は、メールでログインコードを送り、Proサブスクリプションを提供している架空のチーム向け習慣トラッカーの例です。

CONCEPT: Team habit tracker. Coaches create groups; members log daily habits.
Pro subscription (monthly/annual) unlocks progress reports.

ACCOUNTS (non-expiring, pre-filled with 30 days of data):
- Member: review-member@example.com (in the username/password fields)
- Coach: review-coach@example.com / password: [shared here]
- Deletion test: review-delete@example.com / password: [shared here]

LOGIN CODE: The app emails a 6-digit code. For these review
accounts, enter 246810.

SUBSCRIPTION: The member account's subscription has expired.
Tap Reports > Upgrade to see the full purchase flow.

WHERE TO LOOK: Groups tab (coach) > Create group. Today tab (member)
> Log habit. Settings > Account > Delete account.

REGIONS: All features work the same in every storefront.
TESTED ON: iPhone 15 (iOS 26), iPad Air (iPadOS 26).
SERVICES: Supabase (auth/data), RevenueCat (subscriptions).

短く、実用的にまとめましょう。アップデートについて、Appleのヘルプページは「何が変わったのか、そして審査担当者が重要な新しいコンテンツや機能をどこで見つけられるかを説明する」よう求めています。ガイドライン2.3.1(a)では、新機能は「具体的に説明」しなければならず、「一般的な説明はリジェクトされる」と警告しています。ガイドラインの文言は年に何度も変わるため、提出前に2026年10月のApp Reviewガイドライン変更点のまとめも確認してください。

審査でデモアカウントのログインが失敗するのはなぜ？実際の事例

公開されている報告では、デモログインが失敗する原因はたいてい2つのどちらかです。審査担当者が受け取れない二要素認証か、開発者の環境では動くのにAppleのデバイスではエラーになるアカウントです。Apple Developer Forumsの2つのスレッドが、その両方を示しています。

主要機能でのSMS二要素認証。 Apple Developer Forumsのある開発者は、プロフィール編集に米国の携帯電話番号へのSMSコードが必要だったため、アプリが「何度もリジェクトされている」と投稿しました。その理由として「審査担当者の携帯電話番号がわからないので……審査担当者には認証コードが届かない」と説明しています。スレッド内の他の開発者は解決策を紹介しており、ある人は「テストアカウントには常に同じ2FAコードが発行される」ようバックエンドを変更してメモに記載し、別の人は本番アカウントを仮想電話番号に紐づけてAppleにアクセス権を渡しました。

審査以外ではどこでも動く認証情報。 SupabaseのメールアドレスとパスワードによるAuthを使うReact Native・Expoの開発者が、繰り返しリジェクトされたと報告しています。Appleのスクリーンショットには正しいメールアドレスと「Invalid login credentials」というエラーが表示されていましたが、開発者のデバイス、Postman、Supabaseクライアントからはサインインでき、MFA、レート制限、ジオブロッキングもありませんでした。このスレッドでは原因は確定していません。開発者はデモモードの追加を検討していましたが、ガイドライン2.1(a)のもとではその方法にはAppleの事前承認が必要です。

これらの事例に共通するのは、意味のあるテストは審査担当者の体験だけだということです。メモ欄に固定コードを書けば、二要素認証の問題は解決します。「自分の環境では動く」問題に対しては、リリースビルドで、まっさらなデバイスから、本番環境に対してサインインして確認し、その後はアカウントに一切触れないことが必要です。

デモアカウント付きで提出する前に何を確認すべきか？

提出前に、デモログインがリリースビルドで動作すること、すべてのロールとコードがメモ欄に記載されていること、審査期間中にアカウントが期限切れ・ローテーション・削除されないことを確認してください。

• 直近1時間以内に、まっさらなデバイスでリリースビルドにサインインした
• バックエンド、認証プロバイダ、メールやSMSのサービスがすべて稼働中で、アカウントにレート制限がかかっていない
• アカウントが期限切れ、クリーンアップ、パスワードローテーションの処理から除外されている
• すべてのロールについて、それぞれのログイン情報がメモ欄にある
• サブスクリプションの状態が購入フローを表示できるものになっている
• 削除テスト用の別アカウントが用意されている
• ログインコードまたは回避方法がメモ欄に記載されている
• 連絡先電話番号がプラス記号（+）付きの国際形式で記載されており、誰かが確実に応答できる

AppleのApp Reviewページによると、「未解決の問題の平均40%以上がガイドライン2.1：Appの完成度に関するもの」で、これには不完全な情報も含まれます。壊れたデモログインは、その中でも最も防ぎやすいものの一つです。ビルドのそれ以外の部分を確認するには、2.1リジェクト対策のリリースビルドテスト計画を活用してください。

それでもApp審査でサインインできなかったら？

App審査でサインインできなかった場合は、アカウントを修正し、リリースビルドで再テストし、「App審査に関する情報」を更新したうえで、何を変更したかを正確に記してApp Store Connectで返信します。「App審査に関する情報」は「いつでも編集できます」。

リジェクトのメッセージをよく読んでください。原因は単純な食い違いであることが多く、パスワードが変わっていた、セッションが切れていた、審査担当者がバックエンドでブロックしている地域にいた、といったケースです。返信の書き方は、審査メッセージを修正につなげるガイドで順を追って説明しています。審査の準備を任せたい場合は、当社のApp Store申請サービスが審査の準備を行い、リジェクトのフィードバックへの対応も一緒に進めます。料金は両ストア対応で$599です（デベロッパーアカウントの費用は別途）。