この記事はバージョン Summer ’26 において執筆しています。
現在の動作と異なる場合がありますので、ご認識おきください。
デスクトップ環境でのLWC開発が完了しても、実際のモバイル環境(カメラの起動や生体認証など)でアプリが想定通りに動く保証はありません。ブラウザベースのシミュレーションとネイティブアプリの実行環境の間には、ハードウェアアクセスやOSレベルのルーティングにおいて明確な差異が存在します。
第3回では、Betaプログラムである「Publisher Playground」を活用した実機検証のプロセスと、モバイルデバイス固有の拡張機能(ネイティブ統合およびURL管理)の実装方法を解説します。
Publisher Playgroundによる実機検証(UAT)のプロセス
仮想デバイスでのデバッグを終えた後、より本番に近い環境での実機検証(UAT: ユーザー受入テスト)を行うための強力なツールが用意されています。
【仕様】
「Publisher Playground(プレイグラウンドアプリ)」は、Mobile Publisherの正式なライセンスを購入する前に、アプリ内の体験を実際に評価できるBetaプログラムのアプリケーションです。iOS版はAppleのTestFlight経由で、Android版はGoogle Playストアからインストールできます。
Playground App for iOS / Playground App for Android
アプリ内にExperience CloudサイトのURLを入力することで、ネイティブアプリのシェル内でサイトがどのようにレンダリングされるかを確認できます。
【見解・ノウハウ】
Playgroundアプリの真価は、ブラウザベースのシミュレーションでは再現が困難なデバイスネイティブ機能を本番さながらに評価できる点にあります。これを開発の早期サイクルに組み込むことで、後戻り工数を最小化できます。
具体的には以下のテストが可能です。
- Face IDやTouch IDを利用した生体認証ログイン
- プッシュ通知の受信テスト
- ネイティブのファイル共有機構を通じたアップロードおよびダウンロード
- URLルーティング(リンクがアプリ内で開くか、外部ブラウザに遷移するか)
デバイスネイティブ機能の実装(バーコードスキャナと生体認証)
モバイルアプリ化の最大のメリットは、Webの技術スタック(LWC)からモバイル固有のハードウェア機能にアクセスできる点です。
【仕様】
Salesforceが提供する「Nimbusフレームワーク」を通じ、LWC内に lightning/mobileCapabilities モジュールをインポートすることで、JavaScript APIからハードウェアリソースへのアクセスが可能になります。Barcode Scannerを利用すれば、モバイルデバイスのカメラを起動してQRコードなどをスキャンできます。これらの機能はデスクトップ環境では動作しないため、コード内で isAvailable() によるAPIの可用性確認を行うことが推奨されています。
【サンプル】
以下は、バーコードスキャナと生体認証を呼び出すLWCの実装例です。Playgroundアプリを使用してこのコンポーネントをモバイル実機で開いた場合のみスキャンボタンが表示され、ネイティブのカメラや生体認証機能が立ち上がります。
▼バーコードスキャナ
画像

動画
▼生体認証
画像

動画(Verifyingの時に端末で指紋認証しています)
URL Managementとシームレスなルーティング制御
モバイルアプリ内でのリンク遷移を制御することは、ユーザーの操作体験に直結します。
【仕様】
Mobile PublisherのURL Management設定では、ユーザーがリンクをタップした際のルーティング処理を定義できます。方法は4つ(In-App Web View、In-App Browser、In-App Shared Cookie Browser、External Browser)存在します。
多要素認証(MFA)やSAMLのリダイレクトは、設定リストに未登録でもログイン画面のWebビュー内で自動的に処理されます。また、Experience CloudのサイトURL自体(ベースドメイン)を例外リストに入れると深刻なログイン障害を引き起こすため禁止されています。拡張ドメイン移行の際は、assetlinks.json 等の更新が必要です。
参考:Manage How URLs Open from Your App
【見解】
LWC内で外部リンク(例: PDFや外部のSaaS画面)を開く実装を行った場合、デスクトップブラウザでは単純な別タブで開く挙動になりますが、モバイルアプリでは「アプリ内で開いて戻るボタンを出すか(In-App Browser)」「完全にChromeなどの外部ブラウザへ追い出すか(External Browser)」によってUXが大きく変わります。
Playgroundアプリを用いた実機検証では、URL Managementの設定を変更しながら実際にリンクをタップし、ルーティングが想定通りに機能しているか(特に認証セッションが切れないか)をテストすることが不可欠です。
第3回のまとめ
Publisher Playgroundを利用することで、LWCのハードウェアアクセス API(lightning/mobileCapabilities)やURLルーティングの設定結果を、エンドユーザーのデバイス環境で正確に検証することが可能となります。これにより、Webサイトの単なる延長ではなく、真にモバイルに最適化された体験(Branded App)の提供が実現します。
最終回となる第4回では、本番運用に向けたストアへの配信モデルと、設計段階で回避しておくべきLWCコンポーネントの技術的制約について解説します。
参考URL
lightning/mobileCapabilities Module
Manage How URLs Open from Your App
Preview Your Mobile Experience Cloud Site with Publisher Playground (Beta)
Playground App Virtual Device Builds






読者の声