Rork で作ったアプリを App Store に出すと、最初の1〜2回はかなりの確率でリジェクトを食らいます。私自身も Rork で生成したアプリを4本リリースする中で、最初の3本は1回以上リジェクトされました。落ち込みますが、Apple のリジェクトは「直し方」がほぼパターン化されているので、コツを掴めば2回目以降の申請通過率は大きく上がります。
以下は、私が実際に経験したリジェクト理由と、その時に取った対処を Guideline 番号別に整理したものです。再申請前に確認すべきチェックリストも入れています。2026年10月時点の審査傾向を踏まえ、9月から必須になった年齢レーティングの回答と、番号の対応表に載らない「審査メモ」まわりの落とし穴についても項目を設けました。
まず最初に: リジェクトメッセージの読み方
App Store Connect でリジェクトされると、メッセージに Guideline 番号（例: 2.1, 4.0, 5.1.1）が必ず書かれています。最初にすべきは、この番号を Apple のガイドラインページで確認することです。
ガイドラインページ自体は長文ですが、Guideline 番号で検索すれば該当箇所がピンポイントで見つかります。リジェクトメッセージの英語に圧倒されず、まず番号を引くのが最初の一歩です。
私が遭遇したリジェクトを多い順に並べると、次のようになります。番号から「どこを最初に開けばいいか」がすぐ引けるよう、対応表にしました。
| Guideline | 典型的な症状 | 最初に開く場所 | 再申請までの目安 |
|---|---|---|---|
| 2.1 Performance | 起動直後にクラッシュ・白画面で固まる | 指定機種のシミュレータとクラッシュログ | 半日〜2日（原因次第） |
| 4.0 Design | タップ領域が小さい・iOS の慣習から外れる | 指摘された画面のレイアウト定義 | 数時間 |
| 5.1.1 Privacy | 権限の用途説明が汎用的すぎる | Info.plist の Usage Description 群 |
1〜2時間 |
| 2.3.1 Accurate Metadata | スクリーンショットの機能がビルドにない | App Store Connect のメディア管理 | 数時間〜（実装が要る場合は数日） |
| 4.3 Spam | 自分の他アプリと似すぎと判定される | コンセプト・アイコン・配色の設計 | 数日〜（作り直しになりやすい） |
表のいちばん右の列が、実は精神衛生上いちばん大事です。2.1 と 4.3 は「今日直して明日出す」が通用しないことがある、と分かっているだけで、リリース予定日の置き方が変わります。
なお、そもそもビルドが審査に届かず App Store Connect の「処理中」で止まっている場合は、審査以前の問題です。その切り分けはRorkで書き出したアプリがApp Store Connectで「処理中」のまま止まるにまとめています。
Guideline 2.1（Performance）— ビルドが起動しない、クラッシュする
最も多いリジェクト理由です。Apple のレビュー端末（多くは iPhone の旧モデル + 最新 OS）で、起動直後にクラッシュしたり、特定の操作で固まったりすると即リジェクト。
私が経験したケースでは、
「iPhone 12 mini で起動すると、Splash Screen の後で白画面のまま固まる」
というメッセージでした。手元の iPhone 15 では再現せず、最初は「再現できないので問題ない」とリプライしようとしましたが、それは悪手です。Apple は再現環境の詳細を書いてくれているので、その環境を再現して直すのが正解です。
対処法:
- Xcode の Simulator で同じ機種（iPhone 12 mini）と同じ iOS バージョンを選んで起動
- クラッシュログを取得（Window → Devices and Simulators → View Device Logs）
- 原因を特定して修正
- 再申請のメッセージに「指摘いただいた現象を再現し、原因（ライブラリの初期化順序ミス）を特定して修正しました」と具体的に書く
抽象的な「修正しました」より、具体的な原因を書く方が再審査の通過率が上がります。
手元に Xcode がない場合の再現手段
Rork Max のようにクラウド上の Mac でビルドする経路を使っていると、そもそも手元に Xcode がありません。この場合の再現は次の順で試しています。
まず、ブラウザに配信されるシミュレータで機種と OS を指定機種に合わせます。ここで再現できれば話は早いです。再現できなければ、TestFlight で該当機種を持つ人に配布し、フィードバックとクラッシュログを回収します。それも難しければ、App Store Connect の「クラッシュ」タブに集まる分を待つことになりますが、審査中のビルドについては件数が少なく、待つ価値はあまりありません。
起動直後に固まる系は、ウォッチドッグによる強制終了（0x8badf00d）として記録されていることがあります。ログの読み方はiOS の 0x8badf00d ウォッチドッグ強制終了に Rork アプリが落ちるときの対処で扱っています。
Guideline 4.0（Design）— UI が iOS のガイドラインに合っていない
Rork で生成したアプリに多いのが、これです。「ボタンのサイズが小さすぎる」「タップ可能要素の判定がない」「ナビゲーションが iOS の慣習から外れている」など。
実際に受けたメッセージ:
「Buttons in the settings screen are too small to be tapped reliably. Apple Human Interface Guidelines recommend a minimum tappable area of 44 × 44 points.」
対処法:
- Rork のプロンプトに「全てのタップ可能要素は最低 44 × 44 ポイント以上にします」と明示します
- 既存の画面は手動で確認し、小さいボタンを大きくします
- 修正前後のスクリーンショットを App Store Connect のメッセージに添付して再申請します
「指摘されたボタンを 44 × 44pt に拡大しました。同様の問題を全画面で確認・修正しました。」と具体的に書きます。
指摘されるのは1画面でも、生成時のプロンプトが原因なら同じ寸法が全画面に散っています。指摘箇所だけ直して再申請すると、次は別の画面で同じ番号が返ってきます。私はこれを2往復やってから、プロンプト側を直すようになりました。
Guideline 5.1.1（Privacy）— プライバシー情報の説明不足
これも頻出。「カメラ・位置情報・通知の許可を求めるが、なぜ必要かの説明が不十分」というケース。
実際のメッセージ:
「Your app requests camera permission, but the purpose string ("カメラへのアクセスを許可してください") does not explain why the camera is needed.」
対処法:
Info.plistのNSCameraUsageDescriptionなどを、「何のために」「ユーザーにとって何のメリットがあるか」を明記する形に書き換えます- 例: 「プロフィール写真を設定するためにカメラを使用します」
- App Privacy セクション（App Store Connect）の入力内容も、あわせて見直します
私の場合、Rork が生成したデフォルトの説明文が「アクセスを許可してください」のような汎用的なものだったため、すべて手動で書き直しました。これだけで通過したことが何度かあります。
厄介なのは、自分が書いた覚えのない権限やトラッキング宣言が、依存ライブラリ側から入り込んでいるケースです。SDK の連鎖まで遡って洗う手順はRork 生成 Expo アプリの Privacy Manifest を SDK 連鎖まで監査するに分けて書きました。
Guideline 2.3.1（Accurate Metadata）— スクリーンショットと実機が違う
これは Rork のような自動生成系で起こりやすいものです。「スクリーンショットに写っている機能が実機にない」「スクリーンショットのデザインがアプリと一致しない」など。
実際のメッセージ:
「The screenshots show a 'Premium subscription' button, but no such functionality exists in the submitted build.」
対処法:
- スクリーンショットを、実機の画面と一致するものへ差し替えます
- 機能を追加する予定だった場合は、その機能を実装してから再申請します
- 「将来追加予定」のフレーズは、サブタイトルや説明文でも使いません
ここでよくあるミスは、ASO のために魅力的な機能を画像に載せてしまうこと。実装が追いついていないと容赦なくリジェクトされます。キーワードフィールドの方で戦う設計に切り替えたほうが安全です（Rorkで作ったアプリのApp Storeキーワードフィールドを100文字で最大化する設計術）。
2026年9月から必須になった年齢レーティングの回答
メタデータ関連で、いま手元のアプリを確認しておきたい変更があります。App Store Connect の年齢レーティング質問票に、ソーシャル機能に関する設問が加わりました。Apple の告知によれば、回答の入力は7月9日から可能になり、2026年9月以降は、新規アプリの申請・アップデートの申請、および代替マーケットプレイス向けの notarization 申請で、この回答が必須になっています。つまり10月のいま、更新を1回出すだけで必ず通る質問です。
設問が尋ねているのは、ユーザー生成コンテンツ（UGC）をフィードやそれに類する発見の導線で再配布・増幅したり、相互にやり取りさせたりしているかどうかです。該当すると答えると、年齢レーティングは最低でも13+になり、プロダクトページに Social Media のコンテンツディスクリプタが表示されます。カテゴリが何であっても、この下限は変わらないと説明されています。
一方で、13歳未満のユーザーに対して該当機能を無効にし、Declared Age Range API で年齢確認を実装している場合は、Social Media の扱いを避けられるとされています。ただし、その分の実装と審査説明の手間が増えます。
Rork で作ったアプリで見落としやすいのは、「SNS を作ったつもりはない」タイプです。判断の分かれ目になりやすいのは、次のような機能です。
- ユーザーが投稿した画像やテキストを、他のユーザーが一覧で閲覧できます
- コメント欄・レビュー欄など、ユーザー同士が反応を返せる場所があります
- 「みんなの作品」のようなギャラリーやランキングを持っています
生成 AI に「投稿ギャラリーを付けて」と一言頼んだだけの機能でも、実装としては上のどれかに当たることがあります。回答と実際の実装がずれると、Guideline 2.3 系の「実態と異なる情報」として跳ね返ってきます。
私が勧めたいのは、設問に答える前に、アプリの全画面を「他のユーザーの投稿が目に入るか」という一点で見直すことです。13+ になること自体が問題なのではなく、答えと実装が食い違うことのほうがはるかに高くつくのだと思います。要件は変わることがあるため、実際に申請する際は必ず Apple Developer の最新情報で確認いただければ幸いです。
Guideline 4.3（Spam / Duplicate）— 量産系アプリの判定
ASO 対策で複数の似たアプリを出すと、「Spam」として判定されることがあります。Rork の生成スピードを活かして「壁紙アプリを5本出す」のような戦略は、Apple から見ると重複と見なされやすいです。
実際のメッセージ:
「This app appears to be similar to other apps in the App Store. Apple does not allow apps that share the same concept and only differ in minor ways.」
対処法:
- アプリのコンセプトを明確に差別化します（ターゲット層、機能、ジャンル）
- UI・アイコン・カラースキームを大きく変えます
- 同じデベロッパーアカウントで似たアプリを連続で出さないようにします（少なくとも1〜2ヶ月は空けます）
私はこれで1本却下されたあと、「猫の写真が使える壁紙アプリ」と「ミニマルデザインの壁紙アプリ」のように、コンセプトを明確に分けるようにしました。それ以降は通っています。
この番号だけは、直して出し直すというより、企画に戻る類のものです。生成が速いぶん「とりあえず出す」の誘惑が強いのですが、ここで一度立ち止まれたことは、結果的に良かったと思っています。
番号の表に載らない「審査メモ」の落とし穴
ここまでの5つは、メッセージに番号が書かれて返ってくるものでした。もう一つ厄介なのが、コードは正しいのに、審査員が確かめる手段を持てなかったために止まるケースです。Rork のプロンプトからは生まれにくく、提出時に自分で埋めるしかない部分なので、独立して整理しておきます。
| 場面 | 返ってきやすい指摘 | 提出前にやっておくこと |
|---|---|---|
| ログインが必要なアプリ | Guideline 2.1（Information Needed）— 審査用のアカウント情報がない | App Review Information の「サインイン情報」に、実際にログインできる審査専用アカウントを入れる |
| アカウント作成機能がある | Guideline 5.1.1(v) — アプリ内からアカウントを削除できない | 設定画面から削除まで完結する導線を用意し、審査メモにその場所を書く |
| サブスクリプションがある | Guideline 3.1.2 — 価格・期間・解約方法の表示や、利用規約・プライバシーポリシーへのリンクが足りない | 購入画面に価格と更新期間を明示し、メタデータにも両リンクを入れる |
| 外部サービス・ハードウェア連携 | Guideline 2.1 — 審査員が機能を再現できない | 手順つきの説明か、操作を撮った動画を審査メモに添える |
審査用アカウントは、本番のアカウントと分けておくのが安全です。有効期限切れや二段階認証で審査員が入れなくなると、それだけで1往復を失います。私はいつも、提出ボタンを押す直前に「シークレットウィンドウのつもりで、メモに書いた手順だけで自分が最後まで辿れるか」を試すようにしています。
アカウント削除については、「削除したい」という問い合わせを受け付けるだけの画面では足りないと扱われることがあります。生成された設定画面をそのまま出さず、削除の導線があるか一度開いて確かめるだけでも、手戻りは減らせるはずです。
再申請メッセージの書き方
リジェクトを修正して再申請する時、App Store Connect の「Notes」フィールドに何を書くかが重要です。私が使っているテンプレートは次の通り。
We have reviewed your feedback and made the following changes:
1. [Guideline 番号]: [何を直したか1行で]
2. [Guideline 番号]: [何を直したか1行で]
For [指摘された項目1], we [具体的な対処] (see attached screenshot).
For [指摘された項目2], we [具体的な対処].
We have also tested on [指摘された機種・OS] and confirmed the issue is resolved.
Thank you for your review.
具体的な箇条書きと、テスト確認した旨を1段落で書く。これで再審査担当者が直したポイントを素早く把握でき、通過率が上がります。
逆に書かないほうがよいものもあります。事情の説明、スケジュールの都合、前回の審査への異議。読む側が確認したいのは「指摘した箇所がどうなったか」だけです。文章が長いほど確認に時間がかかり、追加の質問が返ってくる確率が上がります。
再申請前の最終チェックリスト
私が毎回確認している基本の6項目です。上から順に潰していきます。
- 実機で起動から主要操作までクラッシュしないことを、複数の機種で確認しました
Info.plistのすべての Privacy Usage Description が、目的を具体的に書いた状態になっています- スクリーンショットに写っている機能が、提出するビルドですべて動作します
- タップ可能要素が 44 × 44pt 以上になっています
- In-App Purchase がある場合、テストアカウントで購入フローが完走します
- アプリ説明文に、過剰な表現や競合他社の名前など、ガイドライン違反になり得る表現が入っていません
これに加えて、9月以降は年齢レーティングの回答が実装と一致しているか、審査用アカウントと審査メモが最新かを、7項目目・8項目目として足しています。
この6項目を満たしてから再申請すると、私の経験ではほとんど跳ね返ってきません。通過したあとの配信をどう刻むかはRork アプリの段階的リリース戦略にまとめています。
リジェクトをポジティブに捉える
最後に、心構えの話を少しだけ。
リジェクトを受けると最初は落ち込みます。私も最初の数回は、自分の作ったものを否定されたように感じていました。でも本質的には、Apple のレビュアーは「ユーザー保護」のために動いています。リジェクトは品質改善の機会であり、通過したアプリは確実にユーザーにとって良いものになります。
それと、リジェクトの理由を直すと「他のアプリでも同じミスをしなくなる」というメタな学びがあります。私は2本目以降、同じ理由でのリジェクトを受けていません。1本目のリジェクトは将来の自分への投資、と考えると気が楽になります。
迷ったときはこの記事の対応表とチェックリストを開いて、項目ごとに潰していってみてください。確実に前に進めます。