ExpoアプリのApp Storeスクリーンショット：EAS Submitがスキップする理由と素早く公開する方法（2026年版）
.ipa/.aab を App Store Connect と Play Console にアップロードするだけです――それがリスティングに対して行うすべてです。ストアのスクリーンショットの生成・アップロード・管理は一切行いません。そのため Expo 開発者には独立したスクリーンショットパイプラインが必要です。ビルド（シミュレータ、エミュレータ、または Maestro/Detox）から生フレームをキャプチャし、その後フレーム付き・キャプション付き・多言語対応のマーケティングパネルにコンポーズします。この記事ではキャプチャコマンドを正直に解説し、次にコンポジションツールが担う役割を説明します――キャプチャ自体はツールが行うものではありません。Expo アプリをリリースするとき、リリースフローは最終的にこの1行で終わります：eas submit。EAS がビルドしたものを Apple または Google に届けます。クリーンで、地味で、信頼性があります。そして App Store Connect を開いてビルドを公開しようとすると――スクリーンショットの枠が空のままです。毎回。
EAS は何でもやってくれるように感じられるため、多くの人がここで戸惑います。ビルドし、署名し、申請する。きっとスクリーンショットも処理してくれると思うはずです。しかし実際はそうではなく、ドキュメントにも明確に記載されています。これはバグでも、申請できる未実装機能でもありません――単純に EAS Submit の対象外なのです。
EAS Submitが実際に行うこと（と行わないこと）
EAS Submit はバイナリ配信サービスです。アップロードするのは正確に1つ――コンパイル済みのアプリアーカイブ（iOS なら .ipa、Android なら .aab）をストアの処理パイプラインに届けることです。Expo のドキュメントはその境界を明確に示しています：
「EAS Submit はバイナリをアップロードしますが、ストアリスティングのメタデータ・スクリーンショット・リリースノートは管理しません。」
姉妹ツールの EAS Metadata は、App Store リスティングの一部――アプリ名、サブタイトル、ローカライズされた説明、キーワード、サポート URL など――を設定ファイルから自動化できます。これは本当に便利なので設定する価値があります。ただし、その対象範囲をよく確認してください。スクリーンショットは含まれていません。EAS Metadata が送信するのはテキストであり、画像ではありません。両ストアのスクリーンショットは、引き続き自分で用意してアップロードする必要があります。
つまり、Expo のスクリーンショット問題は2つの独立した作業に分かれます。頭の中で切り分けておくと整理しやすくなります：
- キャプチャ ― ビルドからアプリの実際の画面の生フレームを取得する。
- コンポジション＆ローカライズ ― 生フレームを、ストアが実際に表示するフレーム付き・キャプション付き・多言語対応のマーケティングパネルに仕上げる。
EAS はどちらも行いません。Expo 自身のストアアセットガイダンスでは、フレームを自分でキャプチャし、Figma のようなツールでパネルをデザインするよう案内しています。両方の作業を具体的なコマンドとともに見ていきましょう。
作業1：開発ビルドまたはプレビュービルドからフレームをキャプチャする
実際のアプリのスクリーンショットが必要なので、キャプチャできる場所でアプリを動かす必要があります。Expo の場合、これは開発クライアントまたはプレビュービルドを意味します――Expo Go ではありません。Expo Go は Expo のラッパー UI を表示し、ネイティブ設定が異なる場合があるためです。標準の Expo コマンドでローカルにビルドして実行します：
npx expo run:ios― ネイティブ iOS をプレビルドし、コンパイルして iOS シミュレータでアプリを起動します。npx expo run:android― Android エミュレータ（または接続デバイス）で同じことを行います。
iOS シミュレータでアプリを表示した状態で、Mac のターミナルから1行のコマンドでキャプチャできます：
xcrun simctl io booted screenshot home.png
booted は現在起動中のシミュレータを対象とし、ピクセル精度の PNG を作業ディレクトリに書き出します。ストア向け作業で重要なフラグが2つあります：--type=png（デフォルト、ストアが求める形式）と --mask=ignored 対 --mask=black です――マスクはノッチと角丸を画像にレンダリングするかどうかを制御します。App Store のアップロード向けには、一般的にフラットな矩形ピクセルで取得し、コンポジション時にデバイスフレームを追加する方が適切です。マスクなしのキャプチャが通常の出発点として正解です。
Android では、エミュレータ（またはデバイス）から直接 adb でキャプチャします：
adb exec-out screencap -p > home.png
exec-out を使い、shell screencap は使わないでください。シェルの通常パスは、一部の環境で PNG を疑似端末経由でパイプするためバイナリが壊れます（不正なキャリッジリターンが混入した破損ファイルが生成されます）。exec-out はバイトを直接ストリームするため信頼性があります。複数のエミュレータを起動している場合は、adb devices から取得した adb -s <serial> で対象を指定します。
以上が手動キャプチャの全工程です：プラットフォームごとに1つ、計2つのコマンドで、Expo ネイティブビルドに必要な Xcode と Android SDK 以外の依存関係はありません。
作業1（自動化）：MaestroまたはDetox
適切な画面まで手動で操作してそれらのコマンドを実行するのは、少数のショットであれば問題ありません。2つのデバイスクラスにわたって8画面ある場合や、実際の UI とのズレを防ぐためにリリースのたびにスクリーンショットを再生成したい場合は、アプリを操作してかつフレームを取得できるエンドツーエンドテストツールでキャプチャを自動化します。
Maestro は、Expo 自身がドキュメントの EAS Workflows の例で採用しているツールです。フローはシンプルな YAML で記述するため、学習コストが低く抑えられます。画面まで操作してキャプチャするフローは次のようになります：
appId: com.you.yourapp --- - launchApp - tapOn: "Get started" - assertVisible: "Your dashboard" - takeScreenshot: dashboard
maestro test flows/home.yaml で実行します。takeScreenshot コマンドはテスト出力ディレクトリに PNG を書き出します（MAESTRO_TESTS_DIR でアセットの保存先を任意に設定できます）。同じフローが EAS Workflows 上の CI でも動作します――Expo のドキュメント例では、e2e-test ビルドプロファイルで .apk をビルドし、それに対して .maestro/ フローを実行します――そのため、e2e スイートと同じジョブにスクリーンショットキャプチャを組み込むことができます。
Detox はもう一つの定番の選択肢で、より厳密でプログラム的な JavaScript API を持ちます：
const path = await device.takeScreenshot('dashboard');
ただし、Expo での Detox セットアップについては正直に考えてみましょう。Detox は Expo を公式にはサポートしていません。実際には、npx expo prebuild でネイティブプロジェクトを生成し、JS バンドルを埋め込んだリリース形式のクライアント（開発クライアントではない）をビルドして Detox をそのバイナリに向けることで動作します。これは Maestro の YAML より動かす部分が多く、利点は Detox のより厳密な同期とアサーション API です。すでに Detox を使っているならキャプチャに流用するのは合理的ですが、ゼロから選択する場合でストアスクリーンショットが目的であれば、Maestro の方が軽量なアプローチです。
作業1（手動）：リリース頻度が低い場合の正しい選択
自動化はリリース頻度が高い場合にコストを回収できます。年1〜3回リリースする場合――ほとんどのインディー Expo アプリはこれに該当します――スクリーンショットキャプチャのために Maestro フローや Detox 設定を組み上げるのは、一度払って、ほとんど回収できないコストです。その頻度であれば、次の手順で十分です：
- ビルドを起動する。
npx expo run:ios/run:androidで現実的なデモデータを投入します。 - 各メイン画面に手動で移動する。
- 各画面をキャプチャする。上記の
simctl/adbコマンドで取得します。
20分の手動操作の方が、次のリリースまでに保守方法を忘れるようなテストハーネスを半日かけて組むより現実的です。手動キャプチャを恥じる必要はありません――ストアは PNG がどのように作られたか判別できません。
作業2：コンポジションと50言語へのローカライズ
これがキャプチャツールが意図的に手を出さない部分であり、ストアが実際に評価する部分です。simctl で取得した生の PNG は、白い背景にアプリの UI が映っているだけです。検索で上位に表示され、プロダクトページでコンバージョンを生むのはマーケティングパネルです。スクリーンショットをデバイスフレームの中に収め、ブランドに合った背景を敷き、その画面の価値を伝える1行のキャプションを添えたもの――通常は左から右に読めるマルチパネルのカルーセルとして構成されます。そして App Store では、スクリーンショットはデバイスサイズ×言語ごとにローカライズが必要なため、本格的なリリースでは5枚どころか何十ものバリアントが必要になります。
これがMokbiの出番であり、その境界を正確に伝える価値があります。Mokbi はアプリをキャプチャしません――上記の Expo コマンドでソースフレームを用意するのは引き続きあなた自身です。Mokbi が担うのはその後の工程です。ブラウザで生フレームをドロップして実際のデバイスフレームに収め、キャプションとグラデーション背景を追加し、マルチパネルのカルーセルをレイアウトし、ワンクリックで50言語へのキャプション翻訳と App Store・Play Store の全サイズへの一括エクスポートができます。デザインは透かし入りプレビューで無料、透かしなしの無制限エクスポートとストア公開はサブスクリプションで――Solo €29.99/mo（1アプリ）または Studio €49.99/mo（最大5アプリ）、買い切りはありません。Expo ガイドが触れるだけで流している Figma テンプレートのステップを置き換えるもので、それ以上でも以下でもありません。
現実的な組み合わせワークフロー
- 開発/プレビュークライアントをビルドする。
npx expo run:iosとnpx expo run:androidで、良質なデモデータを投入します。 - ソースフレームをキャプチャする。
xcrun simctl io booted screenshotとadb exec-out screencap -pで手動取得、または MaestrotakeScreenshot/ Detoxdevice.takeScreenshotで自動化――理想的には EAS Workflows 上でリリースのたびに再生成します。 - マーケティングパネルをコンポーズする。生フレームをフレームに収め、キャプションを付け、カルーセルとして配置します。
- ローカライズして一括エクスポートする。対象言語にキャプションを翻訳し、両ストアに必要な全サイズをエクスポートします。
- リスティングアセットをアップロードする。App Store Connect と Play Console にスクリーンショットをアップロード。EAS Metadata を使っている場合はテキストフィールドと組み合わせます。
- バイナリを申請する。
eas submit――EAS が担う唯一のステップです。 - 次のリリース：変更した画面を再キャプチャし、保存済みのコンポジションプロジェクトを開き直してフレームを差し替えて再エクスポートします。キャプションと翻訳はそのまま残ります。
自動化をスキップできる場合
スクリーンショットのズレが実際のコストになっているとき――週次でリリースし、UI が常に変わり、または多数のアプリを管理していてストア画像の陳腐化が許容できない場合――に Maestro または Detox キャプチャを採用します。そのような状況では CI で再生成されるフレームが費用に見合い、React Native のスクリーンショットツール事情（Expo もこれを継承）への投資が正当化されます。
それ以外の方――四半期に一度リリースする人――はスキップして構いません。2つのターミナルコマンドで手動キャプチャし、ブラウザでコンポジションとローカライズを行えば、リリース間に保守するものが何もない状態で、1日の作業で洗練された多言語リスティングが完成します。CI ダッシュボードで見栄えが良さそうだからという理由でツールを選ばず、自分のリリース頻度に合ったツールを選びましょう。
いずれの場合も、バイナリ側は解決済みです：eas submit が担います。アップロード前に現在のストア要件に照らしてスクリーンショットを確認することをお勧めします――Apple は1ピクセルのズレでもリスティングを却下します――それさえクリアすれば、残りの作業は純粋にデザインです。