【必読】なぜ今、Aura ではなく LWR を選ぶべきなのか?

LWCとPublisher Playgroundを用いた実機検証・ネイティブ機能統合【実装・拡張編】

A high-quality, professional editorial photograph of a hand holding a modern smartphone in a bright, minimalist developer's workspace. The phone screen displays a sleek mobile application interface featuring a prominent, glowing biometric authentication symbol, such as a fingerprint or facial recognition icon. In the soft-focus background, a laptop shows a clean code editor with colorful syntax highlighting. The lighting is soft and natural, emphasizing a clean, high-tech aesthetic and the seamless integration of web development into a native mobile environment. 開発・LWC

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

デスクトップ環境でのLWC開発が完了しても、実際のモバイル環境(カメラの起動や生体認証など)でアプリが想定通りに動く保証はありません。ブラウザベースのシミュレーションとネイティブアプリの実行環境の間には、ハードウェアアクセスやOSレベルのルーティングにおいて明確な差異が存在します。

第3回では、Betaプログラムである「Publisher Playground」を活用した実機検証のプロセスと、モバイルデバイス固有の拡張機能(ネイティブ統合およびURL管理)の実装方法を解説します。

LWRって何?どんなメリットがあるの?
そんな疑問を解決するにはまずは以下の記事をご覧ください。
Salesforce LWRとは? Experience Cloudの次世代ランタイムを徹底解説

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ルーティング(リンクがアプリ内で開くか、外部ブラウザに遷移するか)

デバイスネイティブ機能の実装(バーコードスキャナと生体認証)

DXforce Point for Developers

モバイルアプリ化の最大のメリットは、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

DXforceの管理人

福島 瑛二

2013年にJavaエンジニアとしてのキャリアをスタート。2019年にSalesforceと出会い、Salesforceエンジニアの道へ。

デザインや UI/UX の観点からもシステムを捉え、ユーザーにとって心地よい体験を実装することにやりがいを感じています。

CRM(顧客データ)や Data Cloud と連携した高度なサイトを目に見える形で表現できる Experience Cloud に大きな可能性を見出しており、バックエンドのデータ構造とフロントエンドの表現力を極めることがこれからの Salesforce エンジニアに求められるスキルだと確信しています。

Trailblazer: efukushima

福島 瑛二をフォローする

読者の声

タイトルとURLをコピーしました
DXforce 案内エージェント