App Store のスクリーンショットを手作業で作る場合、その計算はなかなか過酷です。
3 種類のデバイスサイズ、6 つのロケール、5 枚のスクリーンショットフレームに対応しているとすると、管理すべきスクリーンショットは 90 枚にのぼります。UI を変更したり、オーバーレイのテキストを更新したり、Apple が新しい iPhone を発表したときにデバイスフレームを調整したりすれば、その 90 枚すべてを作り直すことになります。しかも手作業で、です。
ほとんどの個人開発者は一度これをやってみてそのコストに気づき、そして本来あるべき頻度でスクリーンショットを更新するのをやめてしまいます。この判断が、訪問されるたびに製品ページのコンバージョンをじわじわと押し下げているのです。
スクリーンショットの自動化はこの問題を解決しますが、ツールの選択肢は「導入する価値が確かにあるもの」から「節約できる時間より手間のほうが大きいもの」まで幅広く存在します。本記事では、スクリーンショット自動化が実際に何を意味するのか、よくあるアプローチ、そして手作業の限界を超えたタイミングをどう見極めるかを解説します。
スクリーンショット自動化とは
App Store のスクリーンショット自動化とは、デバイス・言語・フレームのあらゆる組み合わせについて手作業で作業することなく、デバイスのスクリーンショットの生成・フレーミング・アップロードをプログラムで行うワークフローのことです。
実際には、次のうちの 1 つ以上を指すのが一般的です。
UI テストによるキャプチャ。 自動化された UI テストを実行し、アプリの特定の状態でスクリーンショットのキャプチャをトリガーします。このアプローチの実装として最も広く知られているのが Fastlane の snapshot ツールです。
デバイスフレーミング。 生のスクリーンショットをデバイスのベゼルの中に配置し、テキストオーバーレイをプログラムで追加します。一般的には Fastlane の frameit や同等のツールを使います。
ローカライズされたテキストの差し込み。 各スクリーンショットのオーバーレイテキストを正しい言語に置き換え、フランス語の製品ページにはフランス語のキャプション、日本語のページには日本語のキャプションが表示されるようにします。
一括アップロード。 完成したスクリーンショットを ASC API 経由で App Store Connect に送信します。多くの場合 CI/CD パイプラインの一部として行われます。
完全なスクリーンショット自動化パイプラインは、この 4 つのステップをすべて処理します。ほとんどの開発者は 1 つか 2 つを自動化し、残りは手作業で対応しています。
Fastlane を使ったアプローチ
Fastlane は iOS のスクリーンショット自動化ツールキットとして最も広く知られています。その snapshot ツールはシミュレーター上で UI テストを実行してスクリーンショットをキャプチャし、出力を保存します。frameit ツールはそれらのスクリーンショットを受け取り、必要に応じてテキストオーバーレイを付けてデバイスフレームの中に配置します。
すでにデプロイに Fastlane を使っている開発者にとっては、スクリーンショット自動化の追加は既存の知識の延長で済みます。設定は Fastfile に記述し、テストはシミュレーターで実行され、出力はフレーム付きスクリーンショットのフォルダになります。
実際に直面する摩擦は次のとおりです。
デバイスフレームの更新がハードウェアのリリースに追いつかない。 新しい iPhone モデルが発売されると、frameit に同梱されているテンプレートが古いままで、新しいデバイス向けに正しくフレーミングされたスクリーンショットを生成する前に手作業での更新やコミュニティのパッチが必要になることがあります。
ローカルマシンへの依存。 Fastlane の snapshot はデフォルトで自分のマシン上で動作します。90 枚のスクリーンショットの実行には最新のハードウェアでも 30〜40 分かかることがあり、その間コンピューターが占有されてしまいます。
ローカライズの手間。 新しいロケールを追加するには、snapshot がローカライズされた文字列を受け取れるよう設定し、そのロケール用のテキストファイルを更新し、すべてのスクリーンショットを再生成してアップロードする必要があります。パイプラインを完全に自動化していなければ、各ステップは手作業になります。
DevOps に割けるリソースを持つチームにとっては、これらは対処可能な問題です。しかし機能をリリースする必要がある個人開発者にとっては、スクリーンショットの更新を先延ばしにする理由になってしまいます。
自動化に価値があるのはどんなとき
スクリーンショットの自動化は、次のいずれかが当てはまるときに最も早く投資が回収できます。
複数のロケールに対応している。 たとえ 2 言語であってもスクリーンショットの数は倍になります。ロケールごとのテキスト差し込みを処理してくれる自動化があれば、本来 40 分かかる作業を、別のことをしている間に走る CI ジョブに変えられます。
UI を頻繁に更新する。 機能をリリースするたびにスクリーンショットの見た目が変わるなら、リリースサイクルごとの手作業による再生成はあっという間に積み重なります。自動化はリリースのボトルネックにならずにスクリーンショットを最新に保ちます。
製品ページのコンバージョンをテストしている。 App Store Connect で Product Page Optimization テストを実行するには、テスト用バリアントのために 2 つ目のスクリーンショットセットが必要になります。そのセットを自動化で作るほうが、手作業で代替案を作成してアップロードするよりも大幅に速くなります。
2 種類を超えるデバイスサイズに対応している。 iPhone 15 シリーズ、iPhone 16 シリーズ、iPad、それぞれが独自のスクリーンショット要件を持っています。3〜5 種類のデバイスフォーマットを手作業で管理するのはスケールしません。
ほとんどの個人開発者にとっての分岐点は、おおむねロケール 2 つ・デバイスターゲット 2 つあたりにあります。それを下回るなら手作業のワークフローでも十分に正当化できます。それを超えると、自動化は導入にかかるコストよりも多くの時間を節約してくれます。
現代的なスクリーンショットパイプラインの姿
個人の個人開発者向けの完全な自動化パイプラインは、次のように動作します。
- 特定のアプリ状態に到達し、それぞれの状態でスクリーンショット関数を呼び出す UI テスト
- それらのテストをすべての対象デバイスシミュレーターに対して実行する CI トリガー（ブランチへのプッシュ、リリースタグ、または手動実行をきっかけに起動）
- デバイスオーバーレイを適用し、ロケールごとに正しいローカライズされたテキストを差し込むフレーミングのステップ
- 完成したスクリーンショットを ASC API 経由で App Store Connect に送信するアップロードのステップ
よりシンプルなローカルの Fastlane 構成との決定的な違いは、CI トリガーによってパイプラインが自分のマシンではなくクラウド上で実行される点です。コードをプッシュすればスクリーンショットが生成されます。あなたは出力を確認し、問題なさそうなら承認して、次の作業に進むだけです。
Marteso はこのモデルを軸に作られています。リポジトリを接続しておけば、プッシュをきっかけにスクリーンショットパイプラインを自動的にトリガーできます。フレーミングとローカライズのステップは、あなたのノート PC ではなく Marteso のインフラ上で実行されます。出力は App Store Connect に届く前にダッシュボードに表示され、確認できます。
目的は、このプロセスから開発者の判断を取り除くことではありません。40 分のローカル実行をなくし、その時間を出力を待つことではなく、出力を確認することに使えるようにすることです。
古いスクリーンショットが生む隠れたコスト
製品ページのデータで一貫して見られるパターンがあります。スクリーンショットパイプラインを自動化した開発者は、手作業で行っている開発者よりも頻繁にスクリーンショットを更新するというものです。これ自体は驚くことではありません。驚くべきなのは、コンバージョンの差の大きさです。
スクリーンショットが古くなっていると、たいてい次のような問題のうち 1 つ以上を抱えています。
- スクリーンショットに写っている UI 要素が現在のアプリと一致しておらず、ユーザーがインストールして違うものを目にしたときに認知的な摩擦が生まれる
- オーバーレイのテキストが、より新しい作業によって置き換えられた機能や価値提案を参照している
- 英語以外のロケールが、更新を後回しにしたために英語のテキストを表示している
これらはそれぞれ小さなコンバージョンの足かせです。これらが合わさると、実際のアプリの品質に対して製品ページが常に実力を発揮できていない状態を生み出します。
その解決策は、より優れたスクリーンショット戦略ではありません。更新プロセスの摩擦を減らし、通常の開発の副産物としてスクリーンショットが最新に保たれるようにすることです。
簡単なチェック
いまスクリーンショットを手作業で管理しているなら、次の問いに目を通してみてください。
- 管理しているスクリーンショットは合計何枚ですか（デバイス数 × ロケール数 × フレーム数）？
- 最後に更新したのはいつですか？
- それ以降、UI はスクリーンショットに写る形で変わりましたか？
- 現在英語のテキストを表示しているローカライズはありますか？
質問 3 または 4 の答えが「はい」なら、製品ページのコンバージョンをひそかに押し下げているスクリーンショット負債を抱えています。英語以外の市場のユーザーが英語のテキストを目にすることで生じる摩擦は、App Store Connect のどこにも現れず、コンバージョン率のデータにしか表れません。
スクリーンショットの自動化は華やかなインフラではありません。それは、ASO の取り組みのほかのすべてを実際に意味のあるものにする、縁の下の配管のようなものです。
Marteso は iOS のスクリーンショットの生成・フレーミング・ローカライズを、CI に接続された単一のパイプラインで自動化します。app.marteso.com から始められます。