// 01「指定どおりに作ったはず」が古くなる
先に、この記事を書くことになった経緯を書いておきます。
私たちがスクリーンショット作成ツール「StoreShots」を作ったとき、出力サイズは適当に決めたわけではありません。 公式のドキュメントと、App Store Connect / Google Play Console で実際に指定されているサイズを確認して決めました。 当時はそれで正しかったはずです。
ところが最近あらためて仕様を確認したところ、必須とされる表示サイズが入れ替わっていました。 ツールが出力していた値は、いつのまにか「必須」ではなく「上位が無い場合のフォールバック」という位置づけに変わっていたのです。
ここで重要なのは、仕様が変わったことを知らせてくれる仕組みがないという点です。 仕様表は静かに更新されます。一度調べて実装したら、自分から見に行かない限り古い値を使い続けることになります。 サボっていたわけではなく、確認する動機が発生しなかっただけ、という状況は誰にでも起こり得ます。
そして調べ直す過程で、そもそも「全サイズ作る必要はない」という前提を理解していなかったことに気づきました。 それがこの記事の本題です。
// 02結論：必須は実質2つだけ
App Store の場合、提出が必須なのは次の2つです。アプリが対応するプラットフォームによって決まります。
| 対象 | 表示サイズ | ポートレート | 条件 |
|---|---|---|---|
| スマートフォン | 6.9インチ | 1320 × 2868 |
iPhone で動作するアプリは必須 |
| タブレット | 13インチ | 2064 × 2752 |
iPad で動作するアプリは必須 |
スマートフォン向けについては、6.9インチを提出しない場合に限って
6.5インチ（1284 × 2778）が必須になります。
つまり「6.9インチか、無ければ6.5インチ」という二段構えです。
どちらか一方があれば公開はできます。
スクリーンショットは1画面あたり1〜10枚まで登録できます。 形式は JPEG または PNG で、アルファチャンネル（透過）を含められません。 書き出し時に透過が残っているとアップロードで弾かれるので、背景は必ず不透明にしてください。
// 03提出しなかったぶんはどこから来るのか
では、6.9インチだけ提出した場合、他のサイズの端末を使っているユーザーには何が表示されるのでしょうか。
答えは「上位の表示サイズから自動的に縮小して生成される」です。 しかもこれは1段階ではなく、連鎖になっています。 6.9インチから6.5インチが作られ、その6.5インチからさらに下位が作られる、という具合です。
スマートフォン：自動スケーリングの連鎖
-
6.9インチ 1320 × 2868（必須）
-
6.5インチ 1284 × 2778
- 6.3インチ 1179 × 2556 ほか
-
6.1インチ 1170 × 2532 ほか
-
5.5インチ 1242 × 2208
-
4.7インチ 750 × 1334
- 4インチ 640 × 1136
-
4.7インチ 750 × 1334
-
5.5インチ 1242 × 2208
-
6.5インチ 1284 × 2778
タブレット：自動スケーリングの連鎖
-
13インチ 2064 × 2752（必須）
-
12.9インチ 2048 × 2732
-
10.5インチ 1668 × 2224
- 9.7インチ 1536 × 2048
-
10.5インチ 1668 × 2224
- 11インチ 1488 × 2266 ほか
-
12.9インチ 2048 × 2732
この図の読み方は単純です。ある段のサイズを提出しなければ、その1つ上の段から縮小されて埋められます。 頂点さえ用意しておけば、下位はすべて自動で埋まります。
「全サイズ分の画像を用意しなければ公開できない」という誤解は、 仕様表に並んだ数値の多さから来ているのだと思います。実際には表の大半は 「自分で用意してもいいし、しなくてもいい」枠です。
// 04それでも自分で用意する価値があるケース
自動スケーリングは縮小です。縮小である以上、次のような弱点があります。
- 細い文字がつぶれる — キャッチコピーを小さめの級数で入れていると、下位サイズで読めなくなることがあります
- アスペクト比が完全には一致しない — 表示サイズ区分ごとに縦横比が微妙に違うため、余白の付き方や切れ方が意図とずれる場合があります
- 訴求内容を出し分けられない — 画面が小さい端末では情報量を減らしたい、といった調整ができません
判断の目安としては、こう考えると整理しやすいです。
| 状況 | 対応 |
|---|---|
| 個人開発・リリース直後・まず公開したい | 必須サイズのみで十分 |
| 文字を多用したスクショで訴求している | 下位サイズも自分で用意して可読性を確認 |
| 広告を出す・ASO に本腰を入れる | 主要な表示サイズはネイティブ解像度で用意 |
最初から全部作り込む必要はありません。まず必須サイズで公開して、 効果を測りながら必要な区分だけ足していくのが現実的です。
// 05Google Play は設計思想が違う
ここまで App Store の話をしてきましたが、Google Play は考え方がまったく異なります。 固定の数値を指定するのではなく、範囲で条件を示す方式です。
| 項目 | 要件 |
|---|---|
| 枚数 | 最低2枚（推奨は4枚以上） |
| 寸法 | 各辺 320px 以上 3840px 以下 |
| 辺の比率 | 長辺が短辺の2倍を超えないこと |
| アスペクト比 | 縦向き 9:16 / 横向き 16:9 |
| 推奨解像度 | 短辺 1080px 以上 |
| 形式 | JPEG または 24bit PNG（透過なし） |
| フィーチャーグラフィック | 1024 × 500 |
| アプリアイコン | 512 × 512 / 32bit PNG（透過あり） |
範囲指定なので、条件を満たす1種類を作れば済みます。
縦向きなら 1080 × 1920 以上の 9:16 を用意しておけば、まず問題ありません。
App Store のような「表示サイズ区分ごとの提出」という概念自体がないぶん、こちらのほうが単純です。
フィーチャーグラフィック（1024 × 500）はスクリーンショットとは別枠の必須素材です。
ストア掲載ページの先頭に表示されるバナーで、スクショを何枚用意しても代わりにはなりません。
忘れやすいので、提出前に必ず確認してください。
// 06サイズの次は構図
ここまではあくまで「器」の話です。実際に成果を左右するのは、その中に何をどう配置するかという構図の設計になります。
私たちが自作アプリのスクショを作ったときは、ランキング上位のアプリを一通り眺めて構成の型を把握し、 そのうえで自分のアプリで見せたい機能の数から逆算して枚数を決めるという進め方をしました。 このあたりの具体的な手順は情報量が多いので、別記事にまとめました → ストアのスクショ、構図はほぼ6パターン — 型をシルエットで整理する
// 07提出前チェックリスト
- スマートフォン向けに 6.9インチ（
1320 × 2868）を用意した（または6.5インチで代替した） - タブレット対応アプリなら 13インチ（
2064 × 2752）を用意した - 書き出した画像に透過が含まれていない
- 指定どおりのピクセル数ちょうどで書き出されている（1px のずれでも弾かれます）
- Google Play 向けに 9:16・短辺 1080px 以上の画像を2枚以上用意した
- Google Play のフィーチャーグラフィック（
1024 × 500）を用意した - 下位表示サイズを自動生成に任せる場合、文字が縮小に耐えるかを確認した
- 提出直前に公式の仕様表をもう一度確認した
// ref参照した公式ドキュメント
- Apple — Screenshot specifications（App Store Connect Help）
- Google — プレビュー アセットを追加してアプリを紹介する（Play Console ヘルプ）
本記事の数値は 2026年7月時点で公式ドキュメントを確認したものです。仕様は予告なく更新されるため、 提出前には必ず上記の一次情報をご確認ください。 App Store は Apple Inc.、Google Play は Google LLC の商標です。本記事は各社が提供・承認したものではありません。