# Guideline 2.3.3：スクショ却下の直し方

> 各デバイスでスクリーンショットの半数超がアプリ使用中の実画面である必要があります。合格例と却下例、ビルド不要の修正法を解説。

元のページ：[Guideline 2.3.3：スクショ却下の直し方](https://devoria.fr/ja/blog/guideline-2-3-3-screenshots-rejected-fix)
著者：[Mehdi Azizi](https://devoria.fr/ja/mehdi-azizi)
公開日：2026-11-04
内容の最終更新：2026-11-04


「Guideline 2.3.3 - Performance - Accurate Metadata」でリジェクトされたら、それはAppleが「スクリーンショットにアプリが実際に使われている様子が写っていない」と判断したという意味です。**ルールは数値で決まっています。デバイスの種類ごとに、スクリーンショットの半数超がアプリの実画面を使用中の状態で見せている必要があります。** リジェクトの対象はバイナリではなく製品ページです。スクリーンショットを差し替えて、同じビルドのまま再提出すれば大丈夫です。

僕自身、2026年10月27日にASO追跡アプリのVigieでこれを経験しました。スクリーンショットは、マスコットのまわりにUIカードを描き直して並べたもので、iPhoneは写っていませんでした。Appleはそれをリジェクトしました。このガイドでは、受け取ったメッセージ、Appleの言う「app in use」の意味、通るものと通らないもの、そしてそれ以来使っているチェックリストを紹介します。引用したルールはAppleの公式ページからのもので、2026年11月3日に再確認しています。

## Appleのメッセージ（原文そのまま）

メッセージはルールの名前から始まり、対象のデバイスサイズが書かれています。Vigieの場合、リジェクト理由の一文はこれでした。

```text
The 6.7-inch iPhone screenshots do not show the actual app in use.
```

2.3.3のリジェクトの中には、審査担当者が何を求めているかを詳しく書いたものもあります。次の例は、iPadの枠にiPhoneのフレームを入れていた開発者が、2024年10月に[Appleのフォーラムに投稿した](https://developer.apple.com/forums/thread/765166)ものです。要件を挙げている部分を原文のまま載せます。

```text
Some or all of the provided screenshots do not sufficiently show
the app in use. Screenshots should highlight the app's core concept
to help users understand the app's functionality and value.

- Marketing or promotional materials that do not reflect the UI
  of the app are not appropriate for screenshots.
- The majority of the screenshots should highlight the app's main
  features and functionality.
- Confirm that the app looks and behaves identically in all
  languages and on all supported devices.
- Make sure that the screenshots show the app in use on the
  correct device, unless they are included to demonstrate that
  the app can be used on multiple Apple platforms. For example,
  iPhone screenshots should be taken on iPhone, not on iPad.
```

要するに、アプリのUIが写っていない広告用ビジュアルはスクリーンショットとして不適切だということです。大半は主要機能を見せる必要があります。そして各スクリーンショットは正しいデバイスで撮ります。iPhoneのスクリーンショットはiPadではなくiPhoneで撮ります。例外は、複数のAppleプラットフォームで動くことを見せたい場合だけです。

## Appleの言う「app in use」とは

[ガイドライン2.3.3](https://developer.apple.com/app-store/review/guidelines/#2.3.3)の本文は短いです。「Screenshots should show the app in use, and not merely the title art, login page, or splash screen.」スクリーンショットはアプリの使用中の様子を見せるもので、ロゴやログイン画面、起動画面だけではダメ、ということです。同じ本文で、上に重ねるテキストや画像は認められています。

[2.3.3に関するApp Reviewのヘルプページ](https://developer.apple.com/help/app-review/guideline-reference/2-3-3-screenshots)には、判断の仕方が書かれています。Appleはデバイスの種類ごとにセット全体を評価し、半数超がアプリの使用中を見せている場合にだけ承認します。言語ごとに別々に判断されます。避けるべきものも挙げられています。

- **ログイン画面や起動画面だけを見せるスクリーンショット**
- **実際とは違うUI**、または誤解を招く広告ビジュアル
- **アプリが埋もれてしまう装飾**、またはUIのないハードウェアだけの画像

**つまり「使用中」とは、提出ビルドの本物のUIに、コンテンツが入っていて、ユーザーがアプリをダウンロードする目的そのものを実行している状態です。** 本物の画面の上に短い見出しを載せても、使用中のスクリーンショットとして扱われます。

## アプリを見せる必要がある枚数

Appleは例を2つ出しています。3枚なら2枚、4枚なら3枚がアプリを見せる必要があります。あとは同じ「半数超」のルールから計算できます。

| 提出枚数 | 使用中の最低枚数 | マーケティング画像の上限 |
| -------- | ---------------- | ------------------------ |
| 1        | 1                | 0                        |
| 2        | 2                | 0                        |
| 3        | 2                | 1                        |
| 4        | 3                | 1                        |
| 5        | 3                | 2                        |
| 6        | 4                | 2                        |
| 8        | 5                | 3                        |
| 10       | 6                | 4                        |

数えるのはデバイスの種類ごと、言語ごとです。使用中のアプリを見せていれば、デバイスごとに1枚だけでも大丈夫です。[スクリーンショットの仕様](https://developer.apple.com/help/app-store-connect/reference/app-information/screenshot-specifications)によると、Dynamic Island搭載の中サイズiPhone用に最低1枚が必須で、サイズごとに最大10枚まで登録できます。UIがすべてのサイズと言語で同じなら、必須の最大解像度だけで足ります。小さいサイズにはApp Store Connectが縮小してくれます。正確な寸法は[App Storeのスクリーンショットサイズ](https://devoria.fr/ja/blog/app-store-screenshot-sizes-2026)にまとめています。

## 通るもの、通らないもの

| スクリーンショット                     | 判定               | 決め手                                                                                    |
| -------------------------------------- | ------------------ | ----------------------------------------------------------------------------------------- |
| アプリの実画面＋上に短い見出し         | 通る               | 追加テキストは2.3.3で認められている                                                       |
| iPhoneに収めたアプリの実画面           | 通る               | 本物のUIを正しいデバイスで                                                                |
| ロゴ、起動画面、ログイン画面だけ       | リジェクト         | ルールに明記されている                                                                    |
| UIのないマーケティング画像             | 少数なら許容       | 大半がアプリを見せている場合のみ                                                          |
| 描き直したUIカードで、アプリ本体がない | リジェクト         | 2026年10月27日の僕のリジェクト                                                            |
| ビルドに存在しないモック画面           | リジェクト         | 実際と違うUI                                                                              |
| 空のスマホ、UIのない背景だけ           | リジェクト         | 避けるべきものに挙げられている                                                            |
| iPadの枠にiPhoneのスクリーンショット   | リジェクト         | デバイス違い（フォーラムのリジェクト例より）                                              |
| 2枚にまたがる画像                      | 通る               | アプリが見えている限り認められる                                                          |
| 他プラットフォームのステータスバー     | 2.3.10でリジェクト | Appleは[ガイドライン2.3.10](https://devoria.fr/ja/blog/guideline-2-3-10-accurate-metadata-rejection)の扱いにしている |

Appleはスマホのフレームを必須にしていません。アプリの全画面スクリーンショットだけで十分です。フレームの利点は、それがアプリの画面だと一目で分かることです。

## 僕のケース：2026年10月27日、Vigieがリジェクト

Vigieのバージョン1.1で、僕はスクリーンショット制作スタジオで流行っていたスタイルを真似しました。横につながる1枚絵、マスコット、そしてスマホ全体の代わりに浮かんだUIカード。カードはこのために描き直したもので、架空のアプリが入っていました。見た目はきれいでした。でも、それはアプリではありませんでした。

審査担当者は、6.7インチiPhoneのスクリーンショットがアプリの使用中を見せていないと書いてきました。反論はしませんでした。向こうが正しかったからです。シンプルなルールでセット全体を作り直しました。

1. **どのパネルにも、シミュレーターのネイティブスクリーンショットを入れたiPhoneを置く。** ピクセル単位でそのまま貼り、UIには手を加えない。
2. **拡大カードはスマホに追加する形でだけ使う。** スマホの代わりには絶対にしない。カードも同じスクリーンショットから切り出す。
3. **装飾はまわりに置く。** 画面の上には重ねない。

このリジェクトでは新しいビルドは不要でした。スクリーンショットを差し替えて、その日の夜に同じバージョンを再提出しました。そのあとでビルドを変えましたが、それはアプリ内のタイトル修正のためで、スクリーンショットとは関係ありません。Vigie 1.1はこのセットで10月29日に配信開始されました。

> 描き直したカードは、どれだけ忠実でもアプリではありません。審査担当者が見たいのは、ユーザーが実際に手にする画面です。

## 新しいビルドなしで直す方法

1. **メッセージを最後まで読む。** 対象のデバイスサイズ、ときには言語が書かれています。最初のセットだけでなく、対象のセットはすべて直す必要があります。
2. **提出したビルドからスクリーンショットを撮り直す。** シミュレーターでも実機でも構いません。本物のコンテンツを入れて、デバイスごと・言語ごとに半数超を使用中の画面にします。
3. **App Store Connectでスクリーンショットを差し替える。** [アセット管理のヘルプ](https://developer.apple.com/help/app-store-connect/manage-app-information/manage-your-app-store-assets)によると、アプリが次のいずれかのステータスのときに差し替えられます：Prepare for Submission、Invalid Binary、Rejected、Metadata Rejected、Developer Rejected。
4. **表示されているステータスに合わせて再提出する。** Metadata Rejectedの場合、[ステータス一覧](https://developer.apple.com/help/app-store-connect/reference/app-information/app-and-submission-statuses)の指示は「メッセージを読み、メタデータを直して、App Reviewのメッセージに返信する」です。提出がUnresolved Issuesになっている場合は、[Appleの手順](https://developer.apple.com/help/app-store-connect/manage-submissions-to-app-review/manage-a-submission-with-unresolved-issues/)に従います。Appsで View App Review Issues & Messages、Resolve、リジェクトされた項目のEdit、Add for Review、最後にResubmit to App Reviewです。
5. **送信したらスクリーンショットにはもう触らない。** 同じステータス一覧によると、Waiting for Reviewの間はスクリーンショットのアップロードも変更もできません。

リジェクトされた項目は、再提出の前に1回しか変更できません。クリックする前に新しいセットを確認しておきましょう。僕なら審査担当者にこう英語で返信します。

```text
Hello App Review team,

Thank you for your feedback regarding Guideline 2.3.3.

We replaced the [6.9-inch iPhone] screenshots in all localizations.
Each screenshot now shows the actual app interface, captured from
the submitted build: [main screen], [key feature], [result screen].

The build is unchanged.

Best regards,
[Your name]
```

良い返信のトーンと書き方は[App Reviewへの返信方法](https://devoria.fr/ja/blog/apple-resolution-center-app-review-rejection-reply)で詳しく解説しています。

## スクリーンショット提出前のチェックリスト

- デバイスの種類ごとに、半数超がコンテンツ入りの実画面になっている。
- 英語だけでなく、すべての言語で同じルールを満たしている。
- ロゴ、起動画面、ログイン画面だけのスクリーンショットがない。
- 見せているUIが、提出ビルドにまったく同じ形で存在する。
- 見出しや装飾があっても、UIが読める。
- iPhoneのスクリーンショットはiPhoneで、iPadのものはiPadで撮っている。
- ステータスバーも含めて、他プラットフォームの痕跡がない。
- ダークモードがあるなら、それを見せる1枚がある（Appleのヘルプページが推奨しています）。
- ファイルはJPEGかPNGで、透過なし。

Appleは[製品ページについてのページ](https://developer.apple.com/app-store/product-page/)で、最初の数枚のスクリーンショットが検索結果に表示されることがあるとも書いています。**僕の考えでは、アプリが役に立っている様子をはっきり見せるスクリーンショットのほうが、キャッチコピーより売れます。** 製品ページに関する他のリジェクト理由は[Appleがアプリをリジェクトする理由](https://devoria.fr/ja/blog/apple-app-rejection-reasons-fixes)にまとめています。

## 一発で通るスクリーンショットを

[App Store Screenshots Kit](https://devoria.fr/ja/kits/app-store-screenshots)には、僕のテンプレートと、アプリの実画面からAppleが求めるサイズでスクリーンショットを作るスキルが入っています。製品ページがリジェクトされたばかりなら、[Review Kit](https://devoria.fr/ja/kits/app-review)に提出前のチェックリスト、僕が直したリジェクト事例、審査担当者への返信テンプレートが入っています。全体の流れは[Appleにアプリをリジェクトされたら](https://devoria.fr/ja/expertise/app-rejected-by-apple)のページにあります。

初めてのリリースを準備中なら、[無料診断を受けてください](https://devoria.fr/ja/diagnostic)。やるべきステップを順番に整理して、僕のAppleリジェクト対策チェックリストを送ります。

## よくある質問

### 「Guideline 2.3.3 - Performance - Accurate Metadata」とはどういう意味ですか？

アプリの使用中の様子を見せていないスクリーンショットに対するリジェクトの名前です。マーケティング画像、起動画面、アプリのものではないUIが多すぎるとAppleが判断した場合に出ます。メッセージには対象のデバイスサイズが書かれていることが多いです。

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

いいえ。リジェクトの対象はApp Storeの製品ページです。App Store Connectでスクリーンショットを差し替え、App Reviewのメッセージに返信して同じバージョンを再提出します。

### アプリの使用中を見せるスクリーンショットは何枚必要ですか？

デバイスの種類ごと、言語ごとに半数超です。3枚なら2枚、4枚なら3枚がアプリを見せる必要があります。使用中のアプリを見せていれば、1枚だけでも大丈夫です。

### App Storeのスクリーンショットにマーケティング用のテキストを入れてもいいですか？

はい。ガイドライン2.3.3は、上に重ねるテキストや画像を認めています。ただしUIを隠してはいけませんし、大半のスクリーンショットはアプリの使用中を見せている必要があります。

### スクリーンショットにiPhoneのフレームは必要ですか？

いいえ、Appleは求めていません。アプリの全画面スクリーンショットで通ります。フレームがあると、それがアプリの画面だと伝わりやすくなります。使うなら正しいデバイスのフレームにしてください。iPad用のスクリーンショットにiPhoneのフレームは絶対にダメです。

### 審査待ちの間にスクリーンショットを変更できますか？

いいえ。Waiting for Reviewのステータスでは、App Store Connectでスクリーンショットのアップロードも変更もできません。変えたいなら、提出を審査から取り下げるか、審査結果を待ってください。


## あなたのプロジェクト

[Review Kit](https://devoria.fr/ja/kits/app-review)：私のApp Store審査チェックリスト、修正済みのAppleのリジェクト事例、Google Play用チェックリスト、Claude Codeのスキル3つ。￥8,500。

[iOS & Android Kit](https://devoria.fr/ja/kits/ios)：Claude CodeでiPhoneとAndroidのアプリを作りましょう。私のアプリのスターターコード、ストア公開までの手順、すべてのキットが揃っています。￥17,500。

[診断：あなたとiPhoneアプリの間にあるもの](https://devoria.fr/ja/diagnostic)：7つの質問、60秒。iPhoneアプリの公開を本当に妨げているもの、4ステップのロードマップ、あなたに合ったキットがわかります。
