2026年8月の注記： この記事は以前のリリースのもので、当時のプラン構成について書かれています。AlcoLogはv1.2.0でProプランをPremiumに統合したため、現在の有料プランはひとつだけです。統合によって失われた機能はなく、Proを利用していた方は追加料金なしでPremiumに移行しました。
サブスクリプション、App内課金、Watchのコンパニオンアプリ、ウィジェット、あるいは健康に関わる位置づけを持つv1.0のiOSアプリをこれからリリースしようとしているなら、App Reviewの審査はドキュメントから想像するより厳しいものになるでしょう。この記事は、あるリリースのサイクル（5日間で4回のリジェクト、5人の審査担当者、ひとつのバイナリ）と、そのサイクルを乗り切るうえで役立ったパターンをまとめたものです。これを共有するのは、この経験が本格的な個人開発アプリをリリースするうえで最も記録の少ない部分のひとつであり、記録されている姿（WWDCのセッション、App Reviewガイドラインのページ、開発者フォーラム）が日々の現実と一致していないからです。
サイクルの真っ最中で、すぐに使える対策を探しているなら、「申請前に直しておくべきこと」と「理解しておきたいパターン」に進んでください。背景を知りたい方のために、個人的な経緯は後半にまとめています。
# 申請前に直しておくべきこと
ここに挙げるのは、4回のリジェクトを通じて指摘された項目です。最初からこれらを直しておけば、サブスクリプションのあるセンシティブなカテゴリーのv1.0で、リジェクトされうる範囲の大部分をなくせます。
# サブスクリプションの購入画面での価格表示の優先順位
サブスクリプションに関するAppleのヒューマンインターフェイスガイドラインは、価格の見せ方についてはっきりしています。請求される金額が、価格に関する要素の中で最も目立たなければなりません。マーケティングの感覚（割引をお得に感じさせる）は、ここでは間違った感覚です。規約を守る感覚（請求額を文字の主役にする）が正しいのです。
実際には、通常価格を最も大きく、最も太い要素にするということです。初回価格や割引価格はそれより小さくし、「初回期間：」とはっきり表示します。小さな目印にパーセントのバッジを使うのは避けてください（「25% OFF」ではなく「LAUNCH OFFER」を使う）。この点に関する3.1.2©「支払いとサブスクリプション」の運用は、審査担当者が変わっても一貫しています。
# はっきりとしたデータ削除の手段
「アカウント」がオプトインの匿名IDにすぎない場合でも、Appleの5.1.1(v)では、ラベルの付いた、目に見える、すぐに実行できる削除の手段が求められます。スイッチをオフにすることで暗黙的に削除する方法は、開発者の側からは規約に沿っているように見えますが、現在の運用基準は満たしません。
最初のビルドから、プライバシーや設定の画面にはっきりとした「データを削除」ボタンを組み込んでください。確認のアラートも追加します。そして、周りの説明文が、後で直すつもりの仮のスケジュールではなく、実際の削除の動作を説明していることを確認してください。
# Info.plistに残った不要な宣言を点検する
バックグラウンドモード、バックグラウンドフェッチ、位置情報のエンタイトルメント、HealthKitの宣言などのInfo.plistの項目は、コードベースの改良が進むあいだ、何か月も使われないまま残っていることがあります。実際の機能と一致していないと、それが指摘されます。この点に関する2.5.4「ソフトウェア要件」の運用は機械的で、あいまいさがありません。
具体的には、UIBackgroundModesの項目はすべて、実際にそれを使っている機能に対応している必要があります。アプリがバックグラウンドモードとして「location」を宣言しているのに、バックグラウンドでの継続的な位置情報を一度も使わず、allowsBackgroundLocationUpdates = falseになっているなら、その宣言は削除してください。領域のモニタリングには必要ありません。点検は10分で終わり、リジェクトのサイクルを1回防げます。
# App Storeのメタデータに、機能する利用規約のリンクを
App Store Connectのプライバシーポリシーの欄はよく知られています。利用規約の要件は、それほど知られていません。Appleの標準EULAを使っている場合は、Appの説明に利用規約へのリンクを入れてください。独自のEULAを使っている場合は、App Store Connectの独自EULAの欄に追加します。
利用規約のページ自体には、すべての有料商品について、サブスクリプションの期間、価格、更新のしくみを明記しておく必要があります。多くのチームでは、これらの要素が別々のページに散らばっていたり、プライバシーポリシーの奥に埋もれていたりします。審査担当者が2分で読めるよう、ひとつの利用規約のページにまとめてください。
# App Previewの動画：画面をそのまま録画したものを使う
3Dのスマートフォンのモックアップ、デバイスのフレーム、演出を加えたマーケティング用の構成は、2.3.4「正確なメタデータ」のもとで、審査担当者の裁量に委ねられる判断になります。公開されているガイダンスのページでは、デバイスのフレームがはっきり禁止されているわけではありませんが、審査担当者が従っている内部の研修資料では禁止されているようです。ネイティブ解像度で画面をそのまま録画したものなら、間違いなく安全です。
マーケティング向けの装飾は、自分のウェブサイト、ソーシャルメディア、Redditのためにとっておきましょう。App Previewの枠には画面の録画を入れてください。「作り込んだモックアップのプレビュー」と「画面をそのまま録画したプレビュー」とで、コンバージョンの差は小さいものです。リスクの低減は大きいのです。
# App Reviewに関する情報に、App内課金への道順をはっきり書く
審査担当者は、1つのアプリにつき5〜15分という時間の枠の中で作業しています。そのバージョンに付いているApp内課金を、いつもすべて見つけられるとはかぎりません。App内課金にアプリの中の異なる経路からたどり着く場合（別々の購入画面、別々のカード、より深い階層）は、App Reviewに関する情報の欄に、すべてのApp内課金について、タップの順番がわかる道順を書いてください。
うまくいった書き方は次のとおりです。
Premium subscriptions and Lifetime IAP: Settings tab > Premium card > Get Premium button > Premium upgrade sheet Pro subscriptions and Lifetime IAP: Settings tab > Pro card > Get Pro button Consumable Tip Jar items: Settings tab > scroll past tier cards > Tip Jar card > Show Tip Options
やりすぎに聞こえるかもしれません。でもこれで、そうしなければ1日を失う、特定のリジェクトのサイクル（ガイドライン2.1(b)「情報の追加が必要」）をひとつ防げます。
# 申請日と約束したリリース日のあいだに、カレンダーの余裕を
センシティブなカテゴリーで、サブスクリプションのあるv1.0を申請する場合、最初の申請から、外部に約束したリリース日までのあいだに、少なくとも7日間の余裕をみておいてください。すぐに対応すれば、リジェクトのサイクルは1回あたりおよそ24時間です。センシティブなカテゴリーのv1.0の申請では、4回のリジェクトのサイクルは現実的な最悪のケースです。
リリース日を外部に約束している場合（予約注文を設定済み、App内イベントを予定済み、マーケティングの集中施策を手配済み、記者に売り込み済み）、7日間の余裕が最低限です。10日あれば、もっと安心です。7日未満だと、手続き上のリジェクト1回で日程を逃すおそれがあります。
# 理解しておきたいパターン
サイクルの内側から見えた、ドキュメントからはわからないことをいくつか紹介します。
# リジェクトのたびに、指摘される内容が違う
4回のリジェクトでは、重なりのない項目が指摘されました。どの審査担当者も、前の担当者が問題なしとした画面をすべて見ることができました。最初の担当者はメタデータのEULAのリンクを指摘しました。2人目は同じバイナリで別の3つの項目（バックグラウンドモード、価格表示、削除ボタン）を指摘しました。3人目はマーケティング用の素材を指摘しました。4人目は操作の道順について質問しました。
これは不具合ではありません。App Reviewの構造そのものの特徴です。審査は、アプリ単位ではなく問題単位で行われているようです。審査担当者は、時間の枠の中で最初に見つけた大きな問題で止まります。すべてを網羅的に点検することは求められておらず、前の担当者が受け入れた部分に「問題なしとされた」という扱いが与えられるしくみもありません。この構造は、開発者の体験よりも、組織としての処理量を優先しています。
つまり、どの1回の審査からも、網羅的な点検の結果は得られないということです。得られるのは、その時の担当者が時間の枠の中で見つけたものだけです。そして、次の担当者は次の審査で、それとは無関係にほかの何でも指摘しうる、ということを受け入れるしかありません。
# リジェクトのたびに、指摘の範囲は前回より小さくなりがち
保証ではなく、ゆるやかな傾向です。最初のリジェクトは、しばしば本質的な内容です（欠けている要件、構造上の問題）。2回目もまだ本質的ですが、よりチェックリスト的になります。3回目は周辺的なメタデータに寄っていきます。4回目は、リジェクトですらなく、手続き上の質問であることもあります。
その理由は、アプリが審査のたびに「良くなっている」からではありません。指摘された項目が直され、問題なしとされた項目が対象から外れていくにつれて、バイナリとメタデータの中で審査できる範囲が回を追うごとに小さくなるからです。審査担当者がそれぞれ独立に、チェックリストで確認できる範囲を使い切っていくので、後の審査ほど見つけるものが少なくなるのです。
このパターンは、サイクルの最中には心の支えになりますが、当てにしすぎないでください。サイクルの終盤の担当者でも、前の担当者が見落とした本質的な項目を指摘することはあります。
# 審査担当者の徹底ぶりは大きく異なる
同じバイナリの4回の審査で、各担当者が見つけたものには大きなばらつきがありました。ある担当者は3つの項目を見つけました。別の担当者は周辺的な項目を1つだけ見つけました。3人目は、アプリの2つ目のタブにあるカードをタップすれば答えがわかる質問をしてきました。
どの回の申請をどの担当者が受け持つかに、あなたは影響を与えられません。ばらつきを前提に計画してください。次の審査が前回より徹底的になる、あるいは前回より甘くなるとは考えないでください。それぞれが、幅の広い分布から独立に取り出されたサンプルなのです。
# ベータ版App Reviewの承認は、本番のApp Reviewの承認を予測しない
2つの審査は、担当するチームも基準も異なります。本番の審査で指摘される機能を含んだビルドがベータ版の審査を通過しても、矛盾ではありません。2つの別々の審査プロセスなのです。
本番に向けて審査の準備ができているかを確かめるためにTestFlightを使っているなら、間違ったシグナルを見ていることになります。TestFlightで見つかるのは、ビルドの有効性と基本的な規約違反の問題です。本番のApp Reviewでは、運用の範囲全体が確認されます。この2つは置き換えられるものではありません。
# センシティブなカテゴリーでは、審査が厳しくなる要因が積み重なる
サブスクリプションは、特に初回価格やトライアルの特典があると、自動的に3.1.2の運用の対象になります。健康に関わるカテゴリー（アルコール、フィットネス、メンタルヘルス、睡眠）では、審査担当者が1.4.1の医療的な主張に関する懸念に注意を向けます。プライバシーに関わる機能（位置情報、HealthKit、匿名ID）では、5.1.1による精査が入ります。最初のバージョンであるv1.0の申請では、包括的な審査が行われます。リリース日に結びついたApp内イベントがあると、メタデータが精査されます。
それぞれの要因は、ひとつずつなら対処できます。ただ、それらは掛け算で積み重なります。サブスクリプション、複数のプラットフォーム、App内イベントのある、センシティブなカテゴリーの本格的なリリースでは、すべての要因が同時に働きます。App内課金のない、無料で1画面だけのユーティリティなら、2分で審査が終わります。審査がどれだけ大変になるかは、アプリの質ではなく、リリースの本格さと広さに比例するのです。
# ドキュメントと運用は、いつも完全に一致するとはかぎらない
リジェクトの理由として、リンク先の公開ページにははっきり書かれていないガイダンスが挙げられることがあります。審査担当者は、公開されているApp Reviewガイドラインと重なる部分はあるものの同一ではない、内部の研修資料に従って作業しています。公開ドキュメントと合わないリジェクトに出会ったら、ていねいに反論することもできます。それで覆ることもあれば、覆らないこともあります。
反論するときは、Resolution Centerで文書にして、公開されているガイダンスを引用し、適用されている具体的な条項を尋ねる、構成の整った段落で行ってください。いら立ちを言葉に出すのは避けましょう。審査担当者は限られた時間の中で返信を読んでいます。ていねいに読まれるのは、そのことを尊重した返信です。
# リジェクトに建設的に対応するには
Resolution Centerでのやりとりについて、実践的なメモをいくつか紹介します。
# できれば当日中に返信する
サイクルから抜け出す最も速い方法は、サイクルを止めないことです。リジェクトのサイクルの時計は、あなたが返信した時点でリセットされます。当日中に返信すれば、その週のうちに解決します。返信に何日もかかれば、その分だけサイクルが長引きます。
そのためには、修正をすばやく出せる体制がチームに必要です。個人開発者の場合、多くは申請後の数日間の予定を空けておくことを意味します。申請期間を、片手間の作業として扱うことはできません。
# 修正はまとめて1回の再申請に
リジェクトで3つの項目が指摘されたら、3つすべてを直してから再申請してください。「3つのうち2つを直しました、3つ目は対応中です」という返信は送らないでください。次の担当者はまったく別の項目を指摘してくるので、一部だけ直した返信は、キューにサイクルをもう1回増やすだけです。
# 修正を確認できる画面の録画を添付する
簡単ではない修正には、修正後の動作を見せる30秒の画面の録画を添付してください。削除の流れ、直した価格表示、新しい操作の道順などです。担当者が自分でそこまで操作しなくても修正を確認できれば、次の審査で問題なしとされる可能性が高まります。
# 返信の中で、包括的な審査をお願いする
残っている懸念があれば、次のサイクルに分けずに今回の審査でまとめて指摘してほしい、とていねいにお願いするのは妥当なことです。いつもうまくいくわけではありませんが、ときどきはうまくいきます。言い回しが大切です。英語で送った文面の意味は、おおよそ次のとおりです。「これまでに指摘されたすべての問題に、速やかに、誠意をもって対応してきました。これ以上のサイクルを最小限にするため、今回の審査で、該当するすべてのガイドラインに照らした包括的な審査をお願いできれば幸いです。」
こうすると、担当者の次の返信は、アプリを承認するか、残っている懸念をすべて指摘するか、のどちらかになります。どちらの結果も、単一の問題による次のリジェクトよりはましです。
# 審査は毎回独立したものとして扱う
次の担当者が前の担当者のメモを読んでいる、と考えたくなるものです。おそらく読んでいません。Resolution Centerでの返信は毎回、それだけで完結させ、これまでのやりとりを見ていない人に向けて申請の現状をまとめてください。
つまり、サイクルのあいだで、ある程度のくり返しは必要だということです。最初の担当者に効果があった、詳しいApp Reviewに関する情報は、3人目の担当者のためにもう一度添付するか、あらためて書いてください。組織としての記憶があるとは考えないでください。
# 個人的な経緯
背景として、実際の5日間がどうだったかを紹介します。
土曜日の午後に、ビルド22を申請しました。申請には、4つの自動更新サブスクリプション、2つの非消耗型の買い切りのApp内課金、5つの消耗型のチップ用アイテム、Appの説明、スクリーンショット、App Previewの動画、公開初週に合わせたApp内イベント、そして175の国と地域でリリース日に合わせて設定した予約注文が含まれていました。
私はそれまでの6週間、予想できる問題をひとつずつ、系統立ててつぶしてきました。App Reviewに関する情報には、アプリの中でも特に精査されそうな部分について、審査担当者にわかりやすい説明を書いておきました。DSAの取引業者情報は1週間前に承認されていました。Appのプライバシーに関する栄養ラベルも公開済みでした。ベータ版App Reviewは複数のビルドを通過していました。準備はできていると感じていました。
2日目、午前5時15分： 1回目のリジェクト。ガイドライン3.1.2©。App Storeのメタデータに、機能する利用規約のリンクがないというものでした。当日中に修正を出しました（アプリ内のアップグレードのシートに利用規約のリンクを追加し、利用規約のページを広げてすべての有料商品を明記し、Appの説明を更新）。サイクルは1日でした。
4日目、午後4時3分： 2回目のリジェクト。1通のメッセージに3つの項目がありました。ガイドライン2.5.4（本来あるべきでなかった、UIBackgroundModesの不要な「location」の項目）。ガイドライン3.1.2©（初回価格が請求額より目立つように表示されていた）。ガイドライン5.1.1(v)（匿名IDのスイッチをオフにするだけでなく、ラベルの付いたはっきりとした削除ボタンが必要）。当日中に修正を出しました（Info.plistの項目を削除し、価格表示の優先順位を逆にし、確認のアラート付きの「匿名データを削除」ボタンを追加）。サイクルは1日でした。
5日目、午後5時5分： 3回目のリジェクト。ガイドライン2.3.4「正確なメタデータ」。App Previewの動画で、アプリの画面を見せるのに3Dのスマートフォンのモックアップを使っていました。審査担当者のメモでは、「アプリが使われている様子を十分に示していない」内容が理由として挙げられ、デバイスのフレームが名指しで指摘されていました。
難しかったのは、developer.apple.com/app-store/app-previews/ の公開ガイダンスのページでは、デバイスのフレームがはっきり禁止されていないことでした。いちばん近い記載は「アプリの中にとどまる」というルールで、肩越しに撮った映像や、デバイスに物理的に触れる様子についての例が挙げられていました。どちらも当てはまりませんでした。
リリースまで4日、すでに合計4日の遅れが出ていたので、私は取引を選びました。再申請を進めるためにApp Previewの動画を削除しました。見落としている具体的なガイドラインの条項があるなら、再検討してほしいとていねいにお願いしました。残っている懸念があれば今回の審査でまとめて指摘してほしいと、ていねいで構成の整った段落で伝えました。App Previewの削除はそのまま確定しました。再検討のお願いに、直接の返事はありませんでした。
6日目、午後7時23分： 4通目のメッセージ。ガイドライン2.1(b)「情報の追加が必要」。厳密にはリジェクトではありません。質問をするための審査の一時停止です。担当者は、そのバージョンに付いていたApp内課金のうち2つを見つけられず、どこにあるのかを尋ねてきました。
添付されていたスクリーンショットには、1つ目の購入画面が正しく写っていました。2つ目の購入画面は同じ設定の画面にあり、担当者がたどり着けた最初のカードのすぐ下にあるカードをタップすれば開けるものでした。私は11のApp内課金すべてについて、ステップごとのはっきりとした道順を書いて、1時間以内に返信しました。
7日目、午後8時30分： 承認。ビルドが通過しました。予約注文が有効になりました。公開初週は5月11日に決まりました。
この5日間は緊張の連続でした。振り返れば、どの日も存続に関わるほどのものではありませんでしたが、サイクルの最中にはそうは感じられませんでした。積み重なった遅れで、リリース日をあやうく逃すところでしたが、逃さずにすみました。実際にリリースした製品は、申請前に作ったものとまったく同じです。審査を通すために削ったり、変えたり、先送りしたりしたものは何もありません。
# サイクルで指摘されないことにも意味がある
4回の審査を通じて、私が最も心配していた部分は、一度も指摘されませんでした。
習慣のスコアの機能（6つの重み付けされた柱にわたって、スコアを上げる要因と下げる要因を示す0〜100のスコア）。薬の記録の機能（記録のみで、助言は一切出さない）。プライバシーのモデル（アカウントなし、データはデバイス内、はっきりした削除の手段がある匿名のオプトイン共有）。HealthKitへの書き込み。健康に関する主張やプライバシーの懸念を最も招きやすいこれらの部分は、4回の審査のどれでも指摘されませんでした。4人の独立した担当者がそろって確認し、そろって指摘しないことを選んだのです。
センシティブなカテゴリーでアプリを作る人にとっての教訓は、先回りして情報を開示する作業には意味がある、ということです。手法を説明するApp Reviewに関する情報、アプリ内の免責事項、慎重に選んだ名前、Appの説明での控えめな表現。どれも華やかなものではありません。でも、そのすべてが、4人の担当者が続けて、最も議論になりそうな部分を指摘しないことを選んだ理由になりました。18歳以上の年齢制限、初回起動時の免責事項のシート、関係する部分での「医療上のアドバイスは提供しません」という明確な文言。そのすべてが効きました。
代わりに指摘されたのは、手続き的で機械的な部分でした。価格表示の優先順位。バックグラウンドモードの宣言。メタデータのリンクの有無。マーケティング用素材の構成。App内課金の見つけやすさ。アプリの本質的な部分は、どの審査も通過しました。
# 個人開発者への最後のメモ
ここまでにうまく収まらなかった考えを、いくつか書いておきます。
App Storeで見かける安っぽいアプリが、甘い扱いを受けているわけではありません。 それらは基準がもっと低かった何年も前に承認されたか、あなたの本格的なリリースが招くような精査の要因に引っかからないのです。このしくみは、手間もリスクも小さいアプリには小さな精査で報います。審査が厳しくなるのは、あなたがかけた手間と配慮のせいでもあります。アプリの質を評価しているわけではありません。
このしくみは、あなたが望むような体験を提供できる人員配置にはなっていません。 App Reviewは契約スタッフの集まりです。審査担当者は1日に何十ものアプリを、1つあたり数分で扱います。彼らはApp Reviewガイドラインをチェックリストとして学んでいるのであって、個々のアプリの具体的なUXについて学んでいるわけではありません。共感の欠如は構造的なもので、個人的なものではありません。
個人開発者の経験を記録することは、いずれ物事を動かします。 Appleはこの10年で、App Reviewを大きく改善してきました。その改善の一部は、個人開発者が自分たちの経験を一貫して記録し、それが全体としての圧力になったことにさかのぼります。あなた個人のリジェクトによって、特定の担当者が再研修を受けることはないでしょう。それでも、個人開発者の経験が構造的に積み重なれば、いずれ組織の側も動きます。
あなたはおそらく、自分が作った製品をそのままリリースできます。 削られるかもしれないと心配していた機能は、すべてそのままリリースされました。4回のリジェクトのサイクルは、その最中には存続に関わるものに感じられました。それでも、私がはっきりと返信を続け、リリースの締め切りに余裕を残しておくかぎり、実際の結果は承認へと向かっていきました。
今まさにサイクルの最中で、Resolution Centerを前に徹夜を続けているなら。リリースの日は来ます。返信を続けてください。このしくみは個人的なものではありません。製品は、あなたのものです。
この記事は、iOSのドリンク記録アプリAlcoLogのリリースを記録したものです。AlcoLogは、上に書いたサイクルを経て、2026年5月11日にApp Storeで公開されます。アプリは無料で、オプションのPremiumプランがあり、現在175の国と地域で予約注文を受け付けています。
App Reviewの経験について情報交換をしたいiOS開発者の方には、r/iOSProgrammingやIndie Hackersの個人iOS開発者のコミュニティが、始めるのによい場所です。私たち一人ひとりが出会ったことを具体的に記録すればするほど、それが集まったものは次の人にとって役に立つものになります。