React NativeアプリのApp Storeスクリーンショットを作成する方法（2026年版）
初めて React Native アプリを App Store に申請するとき、誰も教えてくれないことがあります。ストアが求めるスクリーンショットを生成するビルトインの方法が存在しないのです。ネイティブ iOS 開発者は Xcode の UI テストレコーダーを使い、ネイティブ Android 開発者はビルドシステムに組み込まれた Espresso を使えます。React Native は両者の上に乗っており、実際のアプリロジックは JavaScript で動作しています。しかし、これらのツールはあなたの JS の存在を知りません。ギャップを埋めるのはあなた自身です。
この記事では、New Architecture 時代（RN 0.7x 以降、2026年）において実際に機能するアプローチを、具体的なコマンドとともに解説します。コストについても正直に述べます。どの選択肢にも実際のコストがあるからです。また、キャプチャの後に来る工程、すなわちマーケティングコンポジションとローカライズについても解説します。ソースフレームをどう取得するかに関わらず、これは別の独立した問題です。
本質的な問題：ファーストパーティのパイプラインが存在しない
App Store Connect は正確なピクセル寸法のスクリーンショットを要求します。理想的にはデバイスクラスごと、サポートするロケールごとに1セットずつです。Google Play も独自のサイズを要求します。ネイティブ iOS プロジェクトは XCUITest 経由でシミュレータを操作してフレームを取得できます。React Native も技術的には可能ですが、テストが実行されるのはネイティブシェル（バンドルされたバイナリ）に対してであり、JavaScript コンポーネントに直接アクセスするわけではありません。JS をレンダリングするブラックボックスを自動化しているのです。
この違いは見た目以上に重要です。スクリーンショット自動化が壊れる原因が、React のコードとは無関係なところにあることを意味するからです（Metro バンドラーが起動していなかった、シミュレータが権限ダイアログでフリーズした、ネイティブビルドが JS とズレていた）。また、学習コストが馴染みのある RN スタックではなく、2つのネイティブテストフレームワークの学習曲線になることも意味します。この状況を乗り越える本格的な方法は3つあります。リリース頻度に応じて選びましょう。
選択肢1 — Fastlane snapshot（iOS）と screengrab（Android）
Fastlane はモバイル自動化の定番オープンソースフレームワークであり、そのスクリーンショットモジュールは最も実績のある選択肢です。ただし、React Native 向けのセットアップは最も手間がかかります。ネイティブプロジェクト向けに作られており、RN はあくまで許容範囲内という位置づけだからです。
iOS の場合（snapshot 経由）。Xcode で UI テストターゲットを追加し、キャプチャしたい各画面へアプリを誘導する XCUITest ケースを Swift で書きます。fastlane snapshot init を実行すると Snapfile と SnapshotHelper.swift が fastlane/ フォルダに生成されます。テスト内で setupSnapshot(app) を呼び出してアプリを起動し、各状態で snapshot("01_home") を呼びます。実行は Xcode 内からではなく、ターミナルから fastlane snapshot コマンドで行います（Xcode 内から実行すると正しい出力が得られません）。Snapfile に設定したすべてのシミュレータとロケールでループ処理が行われ、PNG が fastlane/screenshots/ に書き出されます。
React Native 特有の注意点として、snapshot はコンパイル済みアプリを起動するため、デバッグビルドではあらかじめ Metro バンドラーが起動している必要があります。そのため Fastfile（またはラッパースクリプト）で先に Metro を起動しておく必要があります。よく使われる方法は、snapshot 呼び出し前にバックグラウンドの tmux セッションで npx react-native start を起動し、終了後にシャットダウンすることです。JS バンドルを埋め込んだリリースビルドはこの問題を回避できますが、実行のたびにフルリリースビルドが必要です。
Android の場合（screengrab 経由）。まったく別のフレームワークです。screengrab は Espresso を使います。JUnit インストルメンテーションテスト内に Screengrab.screenshot("name") の呼び出しを追加し、権限（DISABLE_KEYGUARD、WAKE_LOCK、CHANGE_CONFIGURATION、ストレージ権限）を宣言し、./gradlew assembleDebug assembleAndroidTest でデバッグ APK とテスト APK をビルドして fastlane screengrab を実行します。出力は fastlane/metadata/android/ に生成されます。iOS と同様に、実行前に Metro とエミュレータが起動済みである必要があります。screengrab は自動で起動しません。
強み：
- CI 統合でズレが生じない。パイプラインに組み込めば、リリースビルドのたびにスクリーンショットが再生成され、常に出荷済みアプリと一致します。
- 本物のロケール別レンダリング。各ロケールは実際のロケール設定でシミュレータ/エミュレータ上で動作するため、日付・数値・通貨がネイティブ形式でレンダリングされます（デザインツールで偽装したものではありません）。
- 無料・オープンソース・成熟済み。サブスクリプション不要、コミュニティ規模が大きく、既知の失敗パターンも豊富です。
弱点（正直に考えてみましょう）：
- 2つのネイティブテストスイートを保守する必要がある。iOS 向けは Swift の XCUITest、Android 向けは Kotlin/Java の Espresso/JUnit — RN 開発者にとっては、どちらも不慣れなスタックかもしれません。
- テストするのはネイティブシェルであって JS ロジックではない。テストはレンダリングされたネイティブビューをアサートするものであり、コンポーネントツリーを認識しません。
- 初回セットアップは1〜2日かかる、そして Metro バンドラーのやり取りは CI の不安定な実行が繰り返し発生する原因になります。
- 出力は生フレーム。キャプションなし、デバイスフレームなし、グラデーションなし、カルーセルなし — シミュレータ解像度の素のアプリ UI だけです。
- iOS には Mac が必要。シミュレータには Xcode が必要です。
コンポジション問題に特化した詳細な比較は、Fastlane snapshot vs ノーコードのApp StoreスクリーンショットとMokbi vs Fastlaneの比較ページをご覧ください。
選択肢2 — Detox スクリーンショット（React Native 専用）
Detox は Wix チームが開発した、React Native 専用のグレーボックスエンドツーエンドテストフレームワークです。すでに e2e テストで Detox を使っているなら、スクリーンショット取得はほぼコストゼロで追加でき、習得すべき学習曲線も理にかなったものです — Swift や Kotlin ではなく JavaScript API です。
キャプチャの呼び出しは、任意のテスト内で1行です：
// full screen
const path = await device.takeScreenshot('01_home');
// a single element
await element(by.id('paywallRoot')).takeScreenshot('paywall');取得した画像をアーティファクトとして保存するかどうかは、--take-screenshots フラグ（none、failing、manual、または all）で制御され、.detoxrc.js で設定します。manual または all モードでは、成功したテストが <artifacts-location>/✓ [test name]/[name].png に書き出されます。アサーションと同じ Detox マッチャーを使ってアプリを各状態に誘導してからスナップショットを撮ります。
強み：
- JavaScript API。アプリと同じ言語でテストを書けます — 第二言語のネイティブテストスイートを保守する必要がありません。
- グレーボックスなので RN を理解している。Detox はアプリのブリッジ/JSI と同期してアイドル状態を待機するため、盲目的なタイミング待ちの XCUITest より格段に安定したスクリーンショットが撮れます。
- 1つのフレームワークで両プラットフォーム対応。同じテストファイルで iOS と Android をキャプチャできます。
- すでに持っている可能性が高い。e2e テストで Detox を使っているなら、スクリーンショット追加の限界コストは小さいものです。
弱点：
- Detox をゼロから立ち上げるのは簡単ではない — ネイティブビルド設定、専用テストビルド、エミュレータ/シミュレータのセットアップが必要です。まだ導入していない場合、これは相応の投資です。
- ロケール対応は自前で行う必要がある。Detox は
snapshotの Snapfile のようにすべての App Store ロケールを自動で網羅しません。ロケール切り替えをスクリプト化するか、異なる設定で再起動する必要があります。 - 出力はやはり生フレーム。Fastlane と同様 — マーケティングレイヤーのない素のアプリ UI です。
- ホストマシンによってスクリーンショットが異なる場合がある（Detox の既知の問題）。CI での比較には影響しますが、ストア用アセットとしては問題ありません。
選択肢3 — 手動キャプチャ（最もシンプルで、意外と侮れない）
iOS シミュレータまたは Android エミュレータを開き、アプリを各画面に手動で誘導して、フレームを取得します。iOS では、シミュレータ上で Cmd-S を押すと正しいサイズの PNG がデスクトップに保存されます。ターミナルから xcrun simctl io booted screenshot home.png でも同じことができ、簡単なスクリプトにも組み込みやすいです。Android では、エミュレータのカメラボタンか adb exec-out screencap -p > home.png で画面をキャプチャできます。実機でも構いません — キャプチャ後に AirDrop またはファイル転送で取り出します。
この方法は軽視されがちですが、実は優秀です。セットアップがゼロで、CI がないので CI で壊れることもなく、年に数回しかリリースしないアプリであれば、ソースフレームを用意する最も早い方法です。デメリットは明白かつ現実的です。手動なので自動再生成はなく、画面を変更したらやり直すまでキャプチャは古くなります。5画面のカルーセルであれば、リリースごとに10分の作業です。年2回しか実行しない自動化を保守するよりも安上がりです。
見落とされがちな工程：コンポジションとローカライズ
3つの選択肢に共通することがあります。どれも素のアプリスクリーンショットしか生成できません。そして素のアプリスクリーンショットは、ストアでコンバージョンを生むものではありません。実際にインストールを動かすApp Storeのカルーセルには、画面周囲のデバイスフレーム、メリットを説明する1行のキャプション、アプリの白ではない背景色、そして5枚のパネルを通じた統一感が必要です。上記のキャプチャツールはそのどれも生成しません。それはこれらのツールの欠陥ではなく、別の仕事です。
これがMokbiの出番であり、境界を明確にしておく価値があります。Mokbi はソーススクリーンショットのキャプチャは行いません — それはシミュレータ、実機、あるいは上記の Fastlane/Detox の役割です。Mokbi が担うのは、その後に来るマーケティングコンポジションとローカライズのレイヤーです。ブラウザエディタに生フレームをドロップし、実際のデバイスフレームで囲み、キャプションを追加し、複数パネルのカルーセルをレイアウトして、ワンクリックで50言語へのキャプション翻訳と全ストアサイズへの一括エクスポートができます。デザインは透かし入りプレビューで無料、無制限のエクスポートと公開はサブスクリプションに含まれます — Solo €29.99/mo（1アプリ）または Studio €49.99/mo（最大5アプリ）、買い切りはありません。キャプチャパイプラインが解決を試みさえしない問題を解決するのが Mokbi の位置づけです。PNG フォルダを、Photoshop を開かず50言語への手動リサイズなしにローカライズ済みのストア公開可能なカルーセルへと変換します。
現実的な組み合わせワークフロー
- ソースフレームのキャプチャ。一つを選びます：頻繁リリースなら CI で Fastlane（snapshot + screengrab）、すでに e2e テストを実行しているなら Detox、頻度が低いリリースなら手動シミュレータキャプチャ。出力：画面ごと・デバイスごとの生 PNG フォルダ。
- コンポジション・キャプション・フレーム付け。生フレームをブラウザエディタにドロップします。デバイスフレームを追加し、メリットのキャプションを書き、5パネルのカルーセルを構築して背景を選びます。
- 翻訳。ワンクリックで50言語にキャプションを一括翻訳し、重要なロケールは手動で目視確認します。
- 一括エクスポート。App Store Connect と Google Play の両方に必要なすべてのサイズで、すべてのロケールを一括エクスポートします。
- 次のリリースでの差し替え。変更された画面を再キャプチャし（Fastlane/Detox を再実行、または手動取得）、保存済みプロジェクトを開き直してスクリーンショットを差し替えて再エクスポートします。キャプションと翻訳の作業はすでに完了しています。
自動化をスキップできる場合
年1〜3回リリースしているなら — ほとんどのインディー React Native アプリはこれに該当します — Fastlane や Detox のセットアップコストはほぼ回収できません。XCUITest と Metro バンドラーのやり取りを1日かけて組み上げて、年2回しかない手動キャプチャの10分を節約しようとするのは、計算が合いません。シミュレータから手動キャプチャし、ブラウザでコンポジションとローカライズを行えば、自動化を一度設定する時間より少ないトータル時間で完了します。
自動化がコストに見合うのは、週次または日次でリリースしていてスクリーンショットのズレが繰り返し発生するバグになっている場合、あるいは複数アプリのポートフォリオを運営していてアプリごとのキャプチャコストが積み上がる場合です。そのスケールになったら、キャプチャステップでは CI 上の Fastlane（またはすでにスタックに入っているなら Detox）が正しい選択です。それでも、マーケティングレイヤーにはブラウザコンポジションツールと組み合わせる必要があります。完成したカルーセルを出力するキャプチャパイプラインは存在しないからです。
エクスポート前に確認しておく価値があるのは、実際にアップロードする必要があるApp Storeスクリーンショットのサイズと、申請却下につながるApp Storeスクリーンショットの要件です。一度正しく把握しておけば、App Review との往復を防げます。