fastlane snapshotで多言語スクリーンショットを自動生成する方法は？2026年チュートリアル

fastlaneの公式ガイドでは、スクリーンショット生成の設定にlanguagesとdevicesを使います。この2つの指定方法を基準に、まず少数の言語とシミュレーターで動作を確かめてください。UIテストで画面を表示できたら、生成画像を確認し、仕様検査とアップロードは別工程として進めます。

単一言語アプリのスクリーンショットを更新したい開発者には、手作業を減らしつつ取りこぼしを防ぐ手順を紹介します。
多言語アプリのローカライズ担当者には、表示言語と画面内容の確認方法を整理します。
リモートMacで自動化を保守する小規模チームには、ログと成果物を追跡可能にする確認項目を示します。

SECTION 01担当範囲に合わせた生成方法

同じfastlane snapshotでも、目的によって先に固定するものが異なります。画面遷移の安定を優先するのか、各言語の表示確認を優先するのかを決めてから、言語と端末の組み合わせを増やしてください。

単一言語アプリの更新

まず、テストが目的の画面まで確実に進める状態を作ります。認証、初回起動の案内、通信待ち、空データ表示などが実行ごとに変わると、スクリーンショットの差がアプリの変更によるものか、テスト状態の違いによるものか判別しにくくなります。

実行前にテスト用アカウントや表示データを一定にし、アニメーションや非同期処理が終わってから撮影するようにします。画像が欠けた場合は、テスト未完了なのか、保存処理の問題なのか、画面自体の品質なのかを分けて確認してください。

多言語アプリのローカライズ

言語名と地域設定を整理し、テスト実行時に意図したローカライズが選ばれているか確認します。たとえば日本語と英語を対象にする場合も、翻訳ファイルが存在するだけでは画面の表示確認になりません。起動後の画面で文言、日付、数値、ボタン幅が対象言語に切り替わっていることを見ます。

Appleは、アプリのローカライズを確認するためのテスト手順を案内しています。ローカライズを指定して実行する方法と、ローカライズ担当者向けのスクリーンショット作成方法を確認し、対象プロジェクトのテスト設定に合わせてください。

fastlaneの設定例は、実際に使う言語コードに置き換えて小さく検証します。

languages(["ja-JP", "en-US"])

この記述だけで、すべてのテストが各言語の画面を正しく通過するとは限りません。アプリ内の言語選択方法やテストプランの設定が異なる場合は、起動引数なども含めて実行中の画面で確認してください。

端末の選定とシミュレーター

スクリーンショット用の端末は、アプリが対応するプラットフォームと、提出先が求める素材を基準に選びます。端末をむやみに追加すると、テスト時間や失敗箇所が増える一方で、素材として必要な画面差が増えないことがあります。

シミュレーターまたは実機でアプリを実行する際の条件を確認し、選んだシミュレーターが利用可能かを先に確かめます。fastlane snapshotで指定した端末が、実行環境に導入済みとは限りません。

テストと撮影条件の固定

Xcode UIテストで画面を撮影する前に、以下をプロジェクトごとに決めてください。

• テストが開始する画面と、撮影対象までの操作経路を明確にします。
• 画面表示に必要なテストデータを固定し、通信内容やアカウント状態の変化を避けます。
• ローディング表示、アニメーション、アラートが残ったまま撮影されないよう、画面遷移の待ち条件を確認します。
• 言語、地域、端末を一つずつ追加し、失敗が出たら最後に加えた条件から切り分けます。
• テスト結果、実行ログ、出力画像を同じ実行単位で保管します。

テストプランを使って条件を整理する場合は、テストを構成してフィードバックを改善するXcodeの案内も参照してください。撮影のたびにデータや画面状態が変わると、同じコードでも画像を比較しにくくなります。

画像が出力されても、テスト成功や素材の合格を意味するとは限りません。テスト結果、ファイルの有無、画像内容を別々に確認し、原因に応じて再実行してください。

fastlane snapshotの出力確認

生成されたスクリーンショットは、設定した出力先と実行ログを照合して確認します。snapshotの設定項目を見ながら、言語や端末ごとの生成対象と保存先を把握してください。プロジェクトや設定により出力の構成は異なるため、特定のファイル名だけを前提にせず、実際のフォルダーを確認します。

不足を見つけたら、次の観点で切り分けます。

• テストが撮影対象の画面まで到達したか。
• 実行ログに失敗や中断が記録されていないか。
• 言語や端末の設定が、意図した実行条件と一致しているか。
• 画像ファイルが保存されていて、開いたときに必要な内容が見えるか。
• 同じ実行のテスト結果と画像を対応づけて追跡できるか。

命名規則は、言語、端末、画面名を見分けられる形にチーム内で統一します。fastlaneが生成したファイル名に頼り切らず、レビュー担当者が中身と対象条件を照合できる一覧も残してください。

リモートMacでの運用

リモートMacで自動生成する場合は、プロジェクトの版、Xcodeの選択状態、必要なシミュレーター、出力ディレクトリを実行前に確認します。作業セッションが終わった後もログと画像を確認できるよう、成果物の保存先と取得手順をCIやチームの運用に合わせて決めてください。

リモート環境でUIテストが起動したことだけでは、指定したすべてのシミュレーターが利用できることや、毎回同じ結果になることまでは確認できません。初回は対象を絞って実行し、失敗時にログ、テスト結果、画像のどこまで残るかを確認してから対象を広げます。

Macを一時的なテスト・撮影環境として用意するなら、MACNOXの料金案内で利用条件を確認し、必要な実行期間や操作方法に合うかを検討できます。常時稼働の大きなテスト群や、物理端末との接続が必要な作業では、手元のMacや専用機のほうが適する場合もあります。

SECTION 02生成後の検査とアップロード

スクリーンショット生成、画像の品質検査、App Store Connectへのアップロードは別の作業です。画像が作られたことだけで、寸法や提出条件を満たすこと、アップロードが完了すること、審査に通ることまでは判断できません。

提出前には、対象プラットフォームと画面サイズに対応するApp Store Connectのスクリーンショット仕様を確認します。画像の見切れ、誤った言語、古い画面、テスト用データの残留を目視で検査し、必要な形式や寸法も照合してください。

その後、スクリーンショットをアップロードする手順に沿って提出します。APIで管理する場合も、App Store Connect APIのスクリーンショット情報を確認し、生成成功とアップロード結果を別々に記録してください。

手作業で言語ごとに画面を開き、撮影して名前を付ける方法は、少数の更新なら分かりやすい一方、再撮影漏れや表示状態のばらつきが起きやすくなります。fastlane snapshotを使う場合も、初期設定やテスト保守は必要ですが、言語・端末・テスト条件を固定できれば、変更後の再生成とレビューを同じ手順にまとめられます。

まずは少数の言語と端末でUIテスト、保存画像、提出仕様の確認まで通し、安定してから対象を広げてください。無人実行を継続するなら、環境の準備と成果物の確認方法も含めて運用設計が必要です。MACNOXの利用プランを確認し、遠隔のMacを使う場合は、自分のスクリーンショット対象とXcode UIテストが実際に動く条件を先に照合してください。

SECTION 03関連記事

• シミュレーターを使った自動テスト環境の受け入れ条件を確認する
• iOSの自動ビルド環境でテストと成果物を管理する
• シミュレーターの起動からテスト結果・スクリーンショットの取得までを確認する