ガイドライン5.6.3：アプリがリジェクトされるレビュー依頼

Appleは、評価を早すぎるタイミングで求めるアプリをリジェクトします。レビュー依頼が初回起動時やオンボーディング中に表示されると、ガイドライン5.6.3でリジェクトされるおそれがあります。 依頼はユーザーがアプリを実際に使った後に、システム標準のウインドウで出す必要があります。

僕はミニゲーム付き目覚ましアプリのSolysで、このリジェクトを受けました。ルールの内容、Appleの推奨、そして僕がどう修正したかを紹介します。

ガイドライン5.6.3には何が書かれているのか？

ガイドライン5.6.3は「Developer Code of Conduct」、つまりApp Review Guidelinesのセクション5.6の一部です。条文では、ランキング、検索、レビュー、アプリへの誘導など、App Storeの利用者が目にするものを操作することを禁じています。オンボーディングについては何も書かれていません。

それでも、僕の評価依頼に対してAppleが挙げたのはこのルールでした。根拠はAppleのデザインガイドラインにあります。初回起動時やオンボーディング中は、ユーザーがまだ意見を持てるほど使っていない、という考え方です。

同じセクションの5.6.1では、認められた方法が示されています。レビューを依頼するにはAppleが提供するAPIを使うこと。自作の評価ウインドウは認められず、ガイドライン3.2.2では評価と引き換えに機能をロックすることも禁止されています。

レビューを依頼するタイミング

評価とレビューに関するAppleのデザインガイドラインは明快です。評価を求めるのは、ユーザーがアプリを本当に使った後だけです。

依頼のタイミング	Appleの立場	理由
初回起動時	避ける	まだ意見がない
オンボーディング中	避ける	アプリをまだ使っていない
タスクの途中	避ける	操作を中断させる
タスクの完了後	推奨	すでにアプリを知っている
「アプリを評価」ボタン	可（リンクで）	ウインドウが出ないことがある
何度も続けて	避ける	繰り返しはうんざりされる

僕がリジェクトされたのは最初の2行だけです。残りはAppleのアドバイスに基づくものです。目安を2つ挙げます。Appleは依頼の間隔を少なくとも1〜2週間空けることを勧めています。また、システム自体が同じアプリについてウインドウの表示を365日間で3回までに制限しています。つまり、表示を強制することはできません。

Solysで受けた5.6.3のリジェクト

2026年8月30日、Solysのアップデートがリジェクトされました。Appleのメッセージは5.6.3を挙げ、アプリが初回起動時またはオンボーディング中に評価を求めていると指摘していました。審査はiPad Airで行われていました。

原因は単純です。ウェルカムフローの中で、「レビューを書く」画面がミニゲームのデモの直後、2番目に表示されていました。ユーザーはデモしか見ていない状態でした。

修正内容：依頼をフローのもっと後ろに移し、ユーザーがデモをクリアした直後にだけ表示するようにしました。デモをスキップした人や負けた人には、依頼は一切表示されません。修正版はその後承認されました。

これは僕にとって賭けでした。Appleのメッセージは「オンボーディング中はダメ」と、例外なしに言っていたからです。

教訓：安全なのは、依頼をオンボーディングから外すことです。評価も権限リクエストと同じで、アプリが何をしてくれるかをユーザーが見た後に求めるものです。

システム標準のウインドウでレビューを依頼する

Expoアプリでは、システム標準のウインドウはexpo-store-reviewライブラリで呼び出します。

import * as StoreReview from "expo-store-review";

export async function demanderUnAvis() {
  if (await StoreReview.isAvailableAsync()) {
    await StoreReview.requestReview();
  }
}

レビュー依頼に関するAppleのドキュメントから、知っておくべきことを3つ挙げます。

• ウインドウを表示するかどうかはシステムが決めます。 呼び出しても何も表示されないことがあります。表示を前提にした画面は作らないでください。
• ボタンなど、ユーザーの操作から呼び出すのは避けましょう。 ウインドウが表示されないことがあります。「アプリを評価」ボタンには、アドレスの末尾に?action=write-reviewを付けて、アプリのApp Storeページを開くようにしましょう。
• 成功のタイミングを選びましょう。 アプリを開いたときではなく、ユーザーが一連の操作を終えたときです。

Appleのサンプルコードは呼び出しを遅らせてもいます。ユーザーが操作を何度か完了するまで待ち、同じバージョンのアプリでは2回依頼しません。回数は自由に決められます。

提出前のチェックリスト

• 初回起動時に評価を依頼していない。
• オンボーディング内で評価を依頼していない。
• 星付きの自作画面ではなく、システム標準のウインドウで依頼している。
• 設定画面の「アプリを評価」ボタンはApp Storeページを開き、システムのウインドウを呼び出していない。
• 依頼は実際に使った後に出ている。タスクの完了、レベルのクリア、何回かの起動など。
• ウェルカムフローをiPadでもテストした。僕のリジェクトのいくつかは、iPhoneアプリなのにiPadで指摘されたものです。

次の提出前に5.6.3のリジェクトを防ぐ

Apple Review Kitには、提出前のチェックリスト、僕が修正したAppleのリジェクト事例、そしてプロジェクトをチェックするClaude Codeのスキルをまとめています。アプリがリジェクトされたばかりで人の目で見てほしい場合は、僕と1時間のセッションを予約してください。ビデオ通話で、あなたの画面を見ながらウェルカムフローを一緒に見直します。全体の進め方はAppleにリジェクトされたアプリのページに、その他のよくある理由はAppleがアプリをリジェクトする理由にまとめています。

初めてのリリースを準備中なら、無料の診断を受けてください。手順を正しい順番に整理し、Appleのリジェクト対策チェックリストをお送りします。

よくある質問

オンボーディング中に評価を依頼してもいいですか？

Appleはデザインガイドラインで非推奨としていて、僕はそれが原因でガイドライン5.6.3のリジェクトを受けました。ユーザーはまだアプリを使っていないので、意見を持てません。依頼は実際に使った後に置きましょう。

レビュー依頼は何回まで表示できますか？

システムは同じアプリについて、ウインドウの表示を365日間で3回までに制限しています。Appleは依頼の間隔を少なくとも1〜2週間空けることも勧めており、サンプルコードでは同じバージョンのアプリで2回依頼しません。

独自の評価ウインドウを作ってもいいですか？

いいえ。ガイドライン5.6.1はAppleが提供するAPIを使うよう求めていて、自作の評価ウインドウは認めていません。ただし、アプリのApp Storeページを開く「アプリを評価」ボタンを用意するのは問題ありません。

5.6.3でリジェクトされたら新しいビルドが必要ですか？

依頼がビルドのコードに含まれているなら必要です。ほとんどの場合そうです。審査担当者は初回起動時に組み込まれたコードを見るので、リモートアップデートでは足りません。依頼の位置を移し、ビルドし直して再提出しましょう。

レビューを依頼するのに最適なタイミングはいつですか？

成功の直後です。タスクの完了、レベルのクリア、目標の達成などです。Appleは、ユーザーがすでにアプリを知っていて、何も中断しないタイミングを推奨しています。アプリを開いたときや操作の途中は避けましょう。