LWCのモバイル開発を加速するLive Previewと仮想デバイス検証【開発・検証環境編】

この記事はバージョン Summer ’26 において執筆しています。
現在の動作と異なる場合がありますので、ご認識おきください。

前回の「戦略・比較編」では、Mobile Publisherの導入価値とスクラッチ開発との棲み分けについて整理しました。本記事（第2回）では、LWC開発者やフロントエンドエンジニア向けに、開発と検証の反復スピードを劇的に高めるツールとワークフローに焦点を当てます。

LWC（Lightning Web Component）のフロントエンド開発において、コードを編集するたびにSalesforce組織へデプロイし、ブラウザをリフレッシュして変更を確認するサイクルは、1回の反復に数十秒の時間を要します。このデプロイ待ちの時間は、開発者の生産性を著しく低下させる実際の課題です。

第2回では、開発スピードを最大化するためのローカルプレビュー環境（Live Preview）の導入と、デスクトップ上の仮想デバイス（エミュレータ）を用いたフロントエンドの検証ワークフローについて解説します。

Salesforce Mobile Publisherの導入価値とスクラッチ開発との比較【戦略・比較編】

B2B/B2Cポータルのモバイル体験を向上させるMobile Publisherのビジネス価値を解説します。React Native等によるスクラッチ開発との比較を通じ、最適なユースケースを提示します。

Live Previewを活用したアジャイルなフロントエンド開発
デスクトップシミュレータを用いた仮想デバイス検証とデバッグ
1. iOSの仮想検証手順
2. Androidの仮想検証手順
第2回のまとめ
参考URL

Live Previewを活用したアジャイルなフロントエンド開発

【仕様】

Summer ’26（APIバージョン67.0）より、従来の「Local Dev」に代わり「Live Preview」アーキテクチャが導入されました。Live PreviewはIDE拡張機能およびSalesforce CLIに標準で統合されており、これまでの @salesforce/plugin-lightning-dev プラグインや sf lightning dev app コマンドは不要（非推奨）となっています。

ソースコードを保存すると、WebSocketとHMR（Hot Module Replacement）技術により、ページ全体のリロードなしにブラウザやエミュレータ上のコンポーネントが即座に更新されます。

【見解・ノウハウ】

HMRの最大のメリットは、アプリケーションの状態（State）を保持したままUIの微調整を行える点にあります。これにより、入力フォームの途中状態などを保ちながらスタイルやロジックの修正が可能となり、APIコールの消費を60〜80%削減しつつ、開発スピードを劇的に向上させることができます。

AntigravityなどのモダンなIDE環境において、旧アーキテクチャのプラグイン依存関係エラー（コマンドが起動しない等の問題）に悩まされることなく、標準機能として高速なプレビュー環境を利用できるようになりました。コンポーネントの状態（State）を保持したままUIの微調整が可能となるため、APIコールの消費を削減しつつフロントエンドの開発スピードを劇的に向上させることができます。

Step 1: Scratch組織の設定と作成

【仕様】

Scratch組織でプレビュー機能を利用するためには、プロジェクトのルートディレクトリにある config/project-scratch-def.json において enableLightningPreviewPref を true に設定する必要があります。

【構成したサンプル】

また、モバイル特有のセキュリティ環境を開発段階から再現するために、mobileSettings 内の enableS1EncryptedStoragePref2 の設定も重要です。
エンタープライズ向けのモバイルアプリ（Branded App）を開発する場合、これを true に設定してScratch組織を作成することを推奨します。これにより、モバイルデバイスのローカルストレージにキャッシュされるデータが内部的に暗号化されるという、本番環境に近いセキュリティ要件下でのコンポーネント動作（特にデータの読み込みパフォーマンス等）を、開発初期からシミュレーションできます。

以下の構成例を用いてScratch組織を作成します。

{
  "orgName": "MobileDevOrg",
  "edition": "Developer",
  "features": [],
  "settings": {
    "lightningExperienceSettings": {
      "enableLightningPreviewPref": true
    },
    "mobileSettings": {
      "enableS1EncryptedStoragePref2": true
    }
  }
}

設定ファイルを保存した後、ターミナルから以下のコマンドを実行してScratch組織を作成します。

sf org create scratch -f config/project-scratch-def.json -a MobileDev -d -y 30

スクラッチ組織でライブプレビューが有効になっていることを確認します。

Step 2: Komaci（ESLintプラグイン）の導入と静的解析の実行

1. パッケージのインストール

ターミナルで以下のコマンドを実行し、プラグインをインストールします。

npm install --save-dev @salesforce/eslint-plugin-lwc-graph-analyzer

2. eslint.config.js の修正

① プラグインのインポート（ファイルの冒頭付近）他の require ステートメントの近くに以下を追加します。

const lwcGraphAnalyzerPlugin = require('@salesforce/eslint-plugin-lwc-graph-analyzer');

② LWC設定ブロックへのプラグインとルールの追加

defineConfig 内の // LWC configuration ブロック（LWCモジュールを対象とする部分）に、plugins と推奨の rules を組み込みます。

    // LWC configuration
    {
        files: ['**/lwc/**/*.js'],
        plugins: {
            '@salesforce/lwc-graph-analyzer': lwcGraphAnalyzerPlugin
        },
        rules: {
            ...lwcGraphAnalyzerPlugin.configs.recommended.rules
        },
        extends: [lwcConfig]
    },

LWCコードを対象に静的解析を実行し、モバイル環境のベストプラクティスに準拠しているか確認するコマンドです。

npx eslint force-app/main/default/lwc/ --no-error-on-unmatched-pattern

Step 3: Live Previewの起動

【仕様】

作成したScratch組織を対象に、Salesforce CLIの標準コマンドまたはIDEの拡張機能（UI）からLive Previewを起動します。これにより、ローカル環境でシミュレートされたプレビューサーバーが立ち上がります。

【見解】

まずはSalesforce Live Preview拡張機能のインストールが必要です。

LWCのhtmlやjsファイルを右クリックし「SFDX: Open in Lightning Preview」を選択することで、ブラウザが自動的に開き、対象のLWCがマウントされた状態になります。

Step 4: コンポーネントの編集とリアルタイム反映（HMR）

【仕様】

Live Preview起動中にソースコード（HTML、JavaScript、CSS）を保存すると、WebSocketとHMR（Hot Module Replacement）技術により、ページ全体のリロードなしにブラウザやエミュレータ上のコンポーネントが即座に更新されます。

【見解】

この機能の最大の利点は、アプリケーションの状態（State）を保持したままUIの微調整が可能となる点です。

例えば、複数の画面遷移を伴う入力フォーム（ウィザード形式のUI）を開発しているとします。「最終確認画面」まで画面を進めた状態でCSSを修正して保存しても、Live Previewであれば画面全体がリロードされることはありません。入力中のデータや「最終確認画面」の表示状態を維持したまま、変更したスタイルだけが即座に適用されます。モバイル向けの緻密なレイアウト調整において、このアジャイルなサイクルは不可欠です。

デスクトップシミュレータを用いた仮想デバイス検証とデバッグ

ローカルでの開発がある程度進んだら、モバイル特有の挙動を確認するための仮想デバイス検証（Virtual Device Builds）へ移行します。

【仕様】

Android環境: Android StudioのVirtual Device Managerを使用して、APIレベル30以上、RAM容量4096MB以上を割り当てたエミュレータを構築します。Salesforceから提供される仮想デバイス用ビルド（.apkファイル）をインストールした後、Google ChromeのDevToolsと接続することで、ネットワークリクエストのモニタリングやJavaScriptのステップ実行が可能となります。
iOS環境: macOS上のXcode Simulatorを使用し、Safariの「開発」メニューを通じたWeb InspectorによるDOMツリーの調査を行います。

【見解・ノウハウ】

仮想デバイス検証は、実機を用意しなくても多様な画面サイズやOSバージョンでのレイアウト崩れを素早く検知できる点で非常に有効です。特にChrome DevToolsやSafari Web Inspectorを利用したデバッグは、モバイルブラウザ特有のCSSの解釈違いや、パフォーマンスのボトルネックを特定する上で欠かせないプロセスとなります。

MacBookを開発機として使用している場合、最大のメリットはXcode Simulator（iOS）とAndroid Studioのエミュレータ（Android）の両方を同じPC上で稼働させることができる点にあります。（※Windows PCではXcode Simulatorを実行できないため、iOSの仮想検証が不可能です）。
もし、プロジェクトがiOS向けとAndroid向けの両方のアプリをリリースする計画であれば、MacBook上で両方のシミュレータを利用してUI崩れやネットワーク通信のデバッグを行うのが標準的なアプローチです。

実務上のワークフローは以下のようになります。

Androidの仮想検証: MacBook上でAndroid Studioを立ち上げ、APIレベル30以上、RAM 4096MB以上のエミュレータを構築します。Salesforceから提供される仮想デバイス用ビルド（.apk）をインストールし、Chrome DevToolsでデバッグを行います。
iOSの仮想検証: MacBook上でXcode Simulatorを立ち上げ、iOSの仮想デバイスビルド（.app）をインストールします。Safariの「開発」メニューからWeb Inspectorを用いてDOMツリーなどのデバッグを行います。

コンポーネントのレスポンシブ崩れや通信のボトルネックをこのデスクトップ上の段階で特定し、Local DevのHMRを利用して即座に修正・確認を行うことで、後続の実機テストの工数を大幅に削減できます。

iOSの仮想検証手順

Step 1: Xcode Simulatorの起動
macOSでiOSデバイスをエミュレートする環境を起動します。

MacBookにApp StoreからXcodeをインストールして起動します。
Xcodeのメニューバーから「Xcode」>「Open Developer Tool」>「Simulator」を選択し、シミュレータを起動します（起動しない場合は [Xcode] > [Settings] > [Components] からSimulatorをダウンロード。最新のiOSだとPublisher Playgroundが対応していない場合があるため右下の [Add Platforms] ボタンから旧バージョンをダウンロード）。
シミュレータの「File」>「Open Simulator」から、検証対象とするiOSのバージョンとデバイスモデルを選択します。

Step 2: 仮想デバイス用ビルド（.app）のインストール
Salesforceから取得したデバッグ用の .app ファイルをシミュレータにインストールします。

Preview Your Experience Site on iOS (Simulator) | Salesforce Help から、検証用の「Virtual Device Build（iOS用）」をダウンロードします（ZIP形式の場合は解凍し、.app ファイルを取り出します）。
起動しているシミュレータの画面上に、ダウンロードした .app ファイルを直接ドラッグ＆ドロップします。
エミュレーター上にPublisher Playgroundアプリケーションがインストールされています。

Step 3: アプリの起動とSafari Web Inspectorの準備
シミュレータ内でアプリを起動し、Safariからデバッグできる状態を構成します。

シミュレータの画面上で、インストールしたPlaygroundアプリをタップして起動します。
アプリの初期画面で、検証対象となるExperience CloudサイトのURL（例: https://[ドメイン]/[サイト名]/）を入力し、ログインまたはアクセスを確立します。

Step 4: Safariからの接続とLWCのデバッグ
SafariのWebインスペクタを使用して、アプリ内のLWCフロントエンドコードを調査します。

MacBookでSafariブラウザを起動します。
Safariのメニューバーから「Safari」>「設定」>「詳細」タブを開きます。
ウィンドウ最下部にある「Webデベロッパ用の機能を表示」にチェックを入れます。Safariのメニューバーに追加された「開発」をクリックします。
ドロップダウンメニューの中から、現在起動中のシミュレータ名にマウスカーソルを合わせます。
サブメニューとして、シミュレータ内で実行されているアプリ名やExperience CloudのURL（WebViewのコンテキスト）が表示されるので、それをクリックします。
独立したWebインスペクタのウィンドウが開きます。「要素」タブでのDOMツリーの確認、「コンソール」タブでのログ確認、「ネットワーク」タブでのAPI通信のモニタリングなど、デスクトップのSafariと同様の手法でLWCのデバッグを実行できます。

Androidの仮想検証手順

Step 1: Android Studioでのエミュレータ（AVD）構築
Android Studioを使用して、テスト対象のデバイス（ここではPixelの標準的なプロファイル）をエミュレートする環境を構築します。

MacBook上でAndroid Studioを起動し、右上の [︙] > [Virtual Device Manager] を開きます。
[+] (Create Virtual Device) をクリックし、ハードウェアプロファイルとして Pixel 9 などを選択し [Next] で進みます。
Configure virtual device 画面で、APIレベル30（Android 11）以上のイメージ（例: API 37）をダウンロードして選択します。
続いて [Additional settings] をクリックし、「Emulated Performance」セクションの「RAM」を 4096 MB 以上に設定します。
設定を保存し、構築したエミュレータを起動します。

Step 2: 仮想デバイス用ビルド（.apk）のインストール
Salesforceから取得したデバッグ用の.apkファイルを、起動したエミュレータにインストールします。

Preview Your Experience Site on Android (Emulator) | Salesforce Help から、検証用の Playground Emulator Build (.apk) をダウンロードします。
Finder(MacOS)やExplorer(WindowsOS)の.apkファイルをエミュレータにドラッグ＆ドロップします。
エミュレーター上にPublisher Playgroundアプリケーションがインストールされています。

Step 3: アプリの起動とExperience Cloudサイトへの接続
エミュレータ内でアプリを起動し、テスト対象のサイトを読み込ませます。

エミュレータの画面上で、インストールしたPlaygroundアプリをタップして起動します。
アプリの初期画面で、検証対象となるExperience CloudサイトのURL（例: https://[ドメイン]/[サイト名]/）を入力し、ログインまたはアクセスを確立します。

Step 4: Chrome DevToolsとの接続とデバッグ
LWCのフロントエンドコードをChrome DevToolsからインスペクトし、デバッグを実行します。

MacBook上でGoogle Chromeブラウザを起動します。
アドレスバーに chrome://inspect/#devices と入力して開きます。
エミュレータ内でExperience CloudのWebView（ページ）を開いていると、Chromeの画面上の「Remote Target」セクションに、該当するデバイスとWebViewのURLが表示されます。
表示されたURLの下にある「inspect」というリンクをクリックします。
独立したDevToolsのウィンドウが開き、エミュレータ上で表示されているLWCのDOMツリー（Elementsタブ）、コンソールログ（Consoleタブ）、APIコールなどのネットワーク通信（Networkタブ）を、デスクトップブラウザのLWCをデバッグするのと全く同じ感覚で調査・ステップ実行できます。

第2回のまとめ

Local Devを利用した高速なLWCの修正サイクルと、Chrome DevToolsやSafari Web Inspectorを用いたデスクトップ上の仮想デバイス（シミュレータ）でのフロントエンド検証を組み合わせることで、手戻りの少ないアジャイルな開発サイクルを実現できます。

しかし、デスクトップ環境だけでは、実際のカメラの起動やプッシュ通知、URL遷移の制御といった「デバイスネイティブ」の挙動を正確に評価することはできません。第3回では、Betaプログラムである「Publisher Playground」を活用した実機検証のプロセスと、モバイルデバイス固有の拡張機能の実装方法について解説します。