App Store スクリーンショット自動化：2026 fastlane snapshot リモート Mac チュートリアル // NOVAKVM エンジニアリングブログ

[ SECTION_01 ] 少数なら手動、多言語・複数端末なら自動化

App Store スクリーンショット自動化は、撮影対象が少なく更新頻度も低い場合は不要です。画面、言語、端末の組み合わせが増える場合は、fastlane snapshotを使い、リモート Macで繰り返し実行できる形にするのが現実的です。

対象者は、App Storeのローカライズ版を複数作る独立開発者です。手元にMacがなく、Xcode UI TestsとiOS Simulatorを使いたいWindows・Linux開発者にも向いています。公開作業のたびに同じ撮影を行う小規模チームも対象です。

[ SECTION_02 ] 撮影マトリクスを先に分解する

スクリーンショット作成は、次の4工程に分けて考えます。

アプリの画面を自動で捕獲する
画像に端末フレームや説明文を加える
言語別・端末別のファイルを整理する
App Store Connectへアップロードする

fastlane snapshotが担当する中心部分は、XCTest UI Testsを利用した原画像の撮影です。画像の装飾はframeitなどの別工程、アセットの送信はdeliverやApp Store Connect側の機能に分かれます。役割を混ぜると、撮影成功後に装飾やアップロードで失敗した原因を追いにくくなります。

条件	手動撮影	fastlane snapshot
画面数	少ない	多い
言語	単一または少数	複数ロケール
端末	代表端末だけ	iPhone、iPad、向き違いなど
更新頻度	低い	リリースごとに更新
運用場所	手元のMac	常用または一時利用のリモート Mac
向いている判断	一回限りの確認	同じ作業の反復

判断の基準は、インストールの簡単さではありません。撮影マトリクスの変更を、どれだけ安全に再生成できるかです。言語や端末が増えるほど、手動作業では順番違い、古い画面、別アカウントの表示が混ざりやすくなります。

[ SECTION_03 ] 最小構成は専用UIテストから始める

最初はすべての端末や言語を登録しません。専用のUI Test Target、共有Scheme、代表的な画面遷移だけを用意し、1つの撮影経路を最後まで通します。fastlaneの公式スクリーンショット手順でも、XCTestを起点にした撮影設定が案内されています。

固定する設定

次の値は、実際のプロジェクト名に置き換えて管理します。

Bundle ID：com.example.placeholder
Scheme：ExampleApp-UI
UI Test Target：ExampleAppScreenshotTests
テスト用アカウント：SCREENSHOT_USER
撮影先：./screenshots/<locale>/<device>/
起動引数：-uiTestMode -screenshotData

テストデータは本番利用者の履歴から取得しません。ログイン済み状態、購読中の状態、空データ、機能フラグを起動引数またはローカルの初期データで再現します。通信結果に依存する場合は、応答の遅延やエラー画面が撮影素材へ混入しないよう、撮影用の固定経路を分けます。

初回成功の確認方法

「UIテストが通った」だけでは不十分です。次の順番で確認します。

SchemeがUI Testを実行対象にしているか確認する
Simulatorを初期化し、テスト用データを投入する
起動引数でログイン状態と画面フラグを指定する
snapshotからXCTest UI Testsを実行する
言語別・端末別の画像ファイルが生成されているか確認する
ファイル名と撮影順を確認する
Xcodeのテスト結果と生成ログを保存する
HTML形式の結果を開き、失敗したテストと画像を照合する

AppleのXcodeにおけるテスト結果の確認方法も参照できます。成功判定をテスト終了コードだけにせず、画像、命名、結果レポートの3点で行うと、空ファイルや途中停止を見落としにくくなります。

[ SECTION_04 ] 多言語版は画面状態とロケールを分けて管理する

言語を切り替えるだけでは、正しいローカライズ素材になりません。表示言語、地域の書式、テストデータ、動的テキストを個別に確認します。たとえば日本語表示なのに英語の商品名や別地域の通貨が残ると、撮影は成功していても公開用素材としては使えません。

fastlane snapshotの対象ロケールは、プロジェクトの設定ファイルで明示します。公式のsnapshot設定とパラメーターに合わせ、実際にアプリが対応する言語だけを登録します。

各言語で同じ画面ノードを比較します。確認対象は、文言の欠落、ボタンの切り詰め、行数の変化、日付・通貨の書式、読み込み中表示です。画面内のテキストを座標でタップするテストは翻訳変更に弱いため、アクセシビリティ識別子を設定し、XCUIElementQueryの仕様に沿って要素を取得します。

注意：撮影用アカウントを通常の開発アカウントと共用しないでください。購読状態やオンボーディング履歴が変わると、同じテストでも別のスクリーンショットが生成されます。

[ SECTION_05 ] 端末別の撮影は必要な表示先だけに絞る

App Store Connect用の画像は、アプリの表示先と画面サイズを基準に決めます。すべてのSimulatorを機械的に動かすのではなく、現在の配信対象、iPhoneとiPadのレイアウト差、縦向き・横向きの必要性を先に整理します。

Appleのスクリーンショット仕様には、表示先ごとの寸法が掲載されています。たとえば掲載されている例では、6.9インチiPhone用は1320×2868ピクセル、6.7インチiPhone用は1290×2796ピクセル、13インチiPad用は2064×2752ピクセルです。これらはプロジェクトの対象表示先と、Appleがその時点で案内する仕様を照合して使います。

撮影グループ	設計する内容	失敗しやすい点	判定
iPhone縦	主要画面の同じ順序	長い文言の切り詰め	必須画面を確認
iPhone横	横向き対応画面のみ	横向き未対応の誤登録	対応時だけ実行
iPad縦	2カラムや大画面レイアウト	iPhone用座標の流用	専用識別子を使用
iPad横	横長の主要導線	モーダル位置のずれ	実機相当の表示を確認
特殊状態	空データ、購読、機能フラグ	テストデータの混在	固定起動で再現

App Store Connectは条件に応じて画像を扱いますが、自動縮小だけに頼ると、重要な文字や余白の見え方を確認できません。特定サイズでレイアウトを変えるアプリでは、その表示先向けに個別撮影する方が安全です。

[ SECTION_06 ] 装飾とアップロードを撮影結果から切り離す

原画像ができた後に、マーケティング用の装飾を加えます。frameitは端末フレームなどを作る工程であり、frameitの公式仕様を確認して、原画像を上書きしない出力先を設定します。

撮影直後のディレクトリは、次のように分けると差分確認が容易です。

screenshots/
  raw/
    ja-JP/
      iphone/
  framed/
    ja-JP/
      iphone/
  upload/
    ja-JP/
      iphone/

アップロード前には、次の項目を確認します。

ロケールのフォルダーがApp Store Connectの表示言語と一致しているか
端末グループと画像の向きが一致しているか
同じ画面が意図した順序で並んでいるか
エラー画面、ローディング画面、デバッグ表示が混ざっていないか
不要な透明チャンネルや破損ファイルがないか
既存素材を削除する処理が含まれていないか
App Store Connect側の処理状態が完了しているか

AppleのApp Store Connectへのスクリーンショット登録手順を基準にし、アップロード直後に公開済みと判断しないことが重要です。処理状態と実際のプレビューを確認してからリリース作業へ進みます。

[ SECTION_07 ] リモート Macでは直列実行を基準にする

リモート Macでの実行は、開発者が常にリモートデスクトップを見続ける必要はありません。必要なのは、Xcode、対象のSimulator Runtime、十分なディスク領域、安定したユーザーセッション、そしてログを回収できる実行経路です。

最初から複数Simulatorを同時に起動すると、画面操作の競合、ランタイムの起動失敗、ストレージI/Oの集中、接続切断後の状態不明が起きやすくなります。これは環境ごとに変わるため、一般的な処理時間や同時実行数を固定値として扱わず、単一端末の成功を基準に段階的に増やします。

手順は次の通りです。

リモート Macへ接続し、XcodeとSimulatorの起動を確認する
1言語・1端末・1経路で直列実行する
生成画像、テストログ、HTML結果を保存する
別言語を追加し、文言とテストデータの差分を確認する
別端末を追加し、縦横レイアウトを確認する
失敗した端末だけを指定して再実行する
切断後もログと成果物を回収できることを確認する
資源の余裕を確認した後に、限定的な並列実行を試す

短期の撮影だけなら、NOVAKVMのMac環境を一時的な実行場所として検討できます。常用する場合は、Simulator Runtimeや生成画像でディスクが埋まらないよう、Macのストレージ運用に関する案内も確認しておくと管理しやすくなります。

[ SECTION_08 ] よくある運用上の疑問

fastlane snapshotで多言語の素材をそろえる考え方

言語リストだけを増やすのではなく、ロケール、地域書式、テストデータ、ログイン状態を同じ撮影条件として定義します。各言語の同じ画面ノードを比較し、翻訳の欠落や文字の切り詰めを検出してから装飾工程へ進みます。

手元にMacがない場合の一括撮影

XcodeとiOS Simulatorを動かせるリモート Macがあれば、手元にMacがなくても一括撮影は可能です。ただし、ブラウザー越しの画面確認だけに依存せず、UIテストのログ、生成ファイル、HTML結果を保存する運用が必要です。

ログイン状態とテストデータの固定

撮影専用アカウントと初期化可能なデータを用意し、起動引数で購読状態や機能フラグを指定します。本番APIのユーザー履歴を使うと再現性が失われるため、撮影用の固定データまたはモック経路を用意します。

複数Simulatorの並列実行が不安定になる理由

XcodeとSimulator Runtime、ディスクI/O、ユーザーセッションを同じMac上で共有するからです。実行速度を先に追うのではなく、直列の基準結果を保存し、負荷を観察しながら並列数を増やします。失敗端末を単独で再実行できる構成も必要です。

[ SECTION_09 ] 現在の環境とリモート Macを比較して選ぶ

WindowsやLinuxだけで開発している場合、画面設計や共通コードの作業は継続できます。しかし、Xcode UI Tests、Simulator、App Store Connect向けの最終素材確認を別環境へ分けると、設定差分、ファイル転送、ログイン状態の再現、作業時間の断片化が負担になります。

Macを購入すれば常時利用できますが、スクリーンショット作成だけが目的で、更新時期が限られる場合は過剰投資になり得ます。反対に、毎日大量のUIテストを走らせるチームや物理デバイス接続が必要な案件では、専用の自所有環境の方が適しています。

多言語・複数端末の撮影を一時的にまとめたい場合は、NOVAKVMのリモート Macを使うと、購入前に実行手順と必要な運用量を確認できます。まず最小構成を直列で成功させ、更新頻度と撮影マトリクスが固まった段階で、短期利用か継続利用かを選ぶのが安全です。［CTA］

よくある質問

fastlane snapshotで複数の言語の画面をまとめて撮影するにはどうしますか？

言語ごとに対象のロケールを定義し、XCTest UI Testsが同じ画面遷移とテストデータを再現できる状態にします。端末の地域設定、動的テキスト、ログイン状態も分けて管理し、生成された言語別フォルダーを比較してから公開用素材に進めます。

手元にMacがなくてもiOSアプリのスクリーンショットを一括生成できますか？

XcodeとiOS Simulatorを実行できるリモート Macがあれば可能です。ただし、接続が切れても処理が止まらない運用、ログの回収、失敗した端末だけを再実行する手順を先に用意してください。

fastlane snapshotでログイン状態やテストデータを固定する方法はありますか？

テスト専用アカウント、初期化可能なローカルデータ、起動引数による機能フラグを組み合わせます。通常利用者の履歴や本番APIの応答に依存すると、撮影ごとに画面が変わるため、ネットワーク状態も含めてテスト用に分離する必要があります。

リモート Macで複数のiOS Simulatorを同時に動かすと失敗しやすい理由は何ですか？

各SimulatorがXcode、ランタイム、ディスクI/O、ユーザーセッションを共有するためです。最初から並列化せず、まず単一端末で成功条件を固定します。その後、負荷と失敗ログを確認しながら実行単位を増やし、問題が出た端末だけ個別に再実行します。

App Store スクリーンショット自動化：2026 fastlane snapshot リモート Mac チュートリアル