Salesforce Mobile Publisherの配信モデルとLWC設計における技術的制約【リリース運用・制約編】

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

Web開発とは異なり、モバイルアプリ（Branded App）のリリースにはAppleやGoogleといったプラットフォームごとの審査と、厳格なガバナンス要件が伴います。

本連載の最終回となる第4回では、開発・検証を終えた本番運用に向けて、ストアへの配信モデルの選択基準と、アーキテクチャ設計段階で必ず回避しておくべきLWCの技術的制約について解説します。

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

Mobile Publisherアプリ構築における、Playgroundを用いた実機検証プロセスと、カメラ連携などのLWCデバイスネイティブ機能、URL遷移の制御ロジックを解説します。

企業のセキュリティ要件に応じた配信モデルの選択
モバイル特有の制限事項と認証・UIの注意点
LWCベースコンポーネントにおける挙動の差異
連載のまとめ
参考URL

企業のセキュリティ要件に応じた配信モデルの選択

【仕様】
Mobile Publisherは、一般消費者向けの「パブリック配信」と、MDM（モバイルデバイス管理）環境下にあるデバイスへのみ配信する「プライベート配信」をサポートしています。また、ビルドからストア提出までのプロセスとして以下の3つのメソッドが提供されています。

Fully Managed（フルマネージド）: Salesforceがバイナリのビルド、証明書の管理、ストアへのアップロードまでライフサイクル全体を管理します。
Binary Upload（バイナリアップロード）: Salesforceがバイナリを自動的にアップロードし、企業側はスクリーンショットやアプリのメタデータ提出、リリース審査の申請を自ら行います。
Binary Handoff（バイナリハンドオフ）: Salesforceはコンパイル済みのバイナリファイル（.ipa または .aab）の生成のみを行います。企業は自社の秘密鍵でバイナリの再署名（Re-signing）を実施し、自社の経路でストアへアップロードします。

さらに、Apple App Storeのガイドライン（5.1.1）への準拠として、アプリ内からユーザー自身のアカウントデータを削除する機能の実装が必須要件となります。また、ストア掲載用のスクリーンショットは、透明なアルファチャンネルを含まないフラットなPNG形式で作成する必要があります。

【見解】
運用保守のリソースを最小限に抑えたい多くの組織にとっては「Fully Managed」が最適かつ最も一般的な選択肢です。しかし、厳格なセキュリティプロトコルにより外部ベンダーによる最終署名を禁止している金融機関や、確立された内部CI/CDパイプラインを経由してリリースを行うエンタープライズ組織においては「Binary Handoff」が必須となります。プロジェクトの初期段階で自社のセキュリティ担当者と連携し、責任分界点を明確に定義しておくことが重要です。

モバイル特有の制限事項と認証・UIの注意点

【仕様】
Experience Cloud上で設定された共有ルールやデータの暗号化といったセキュリティ機構はそのままアプリに引き継がれますが、アーキテクチャに起因する以下の技術的制限が存在します。

認証とルーティング制限: 生体認証等を用いて別のサイトへパスワードレスで自動認証させる高度なディープリンク認証（Advanced deep linking authentication）はサポートされていません。また、新規登録時に外部システムに情報を渡し、再びExperience Cloudアプリに戻るようなトランジションは推奨されていません。未認証のゲストユーザーにはAPIアクセスが許可されず、非認証ページにはログインURLへの動線が必須です。
UIコンポーネント制限: アプリ内へのiframe要素の統合はサポートされていません。また、iOSおよびAndroidにおけるOSレベルのダークモードはExperience Cloudアプリでは機能しません。

【見解】
パスワードリセットや初期のユーザー登録フローは、モバイルアプリ内で無理に完結させようとすると、Universal Linksの挙動によって正常に遷移しないリスクがあります。これらはデスクトップのWebブラウザ上へ誘導する設計に割り切ることが実務上のベストプラクティスです。また、既存のWebシステムをiframeで埋め込んで強引にアプリ化するアプローチは、スクロール障害などを引き起こすため絶対に避け、LWCによるネイティブなフロントエンド構築を行う必要があります。

LWCベースコンポーネントにおける挙動の差異

デスクトップ環境では正常に動作するコンポーネントも、モバイル環境では予期せぬ制約を受けます。

【仕様】
モバイル環境において制限を受ける主なLWCベースコンポーネントは以下の通りです。

lightning-datatable: モバイル向けに設計されていないため動作が保証されず、表示崩れや予期せぬ動作が発生するリスクがあります。
lightning-map: オフラインモードでは機能せず、エラーメッセージが表示されます。
lightning-formatted-rich-text: target="_blank" 属性を持つURLを処理できず、Salesforceレコードへの内部リンクも機能しません。
lightning-record-form: オフライン時に作成されたドラフトレコードでは機能せず、ルックアップ項目は読み取り専用となります。

【見解】
B2Bポータル等においてデータの一覧表示（データテーブル）は頻出しますが、モバイル画面での利用はUXを著しく損ないます。モバイル対応を行う際は lwc:if を用いて表示制御を行い、デスクトップ環境では lightning-datatable を、モバイル環境ではグリッドやカード形式を用いた専用のカスタムLWCへフォールバックする防御的プログラミングを徹底すべきです。

連載のまとめ

Mobile Publisherは、「迅速な市場投入」「既存プラットフォーム投資の再利用」「セキュリティガバナンスの維持」を実現する戦略的選択肢です。

全4回を通してお伝えした通り、このソリューションは単なる「Webサイトのラッパー」ではありません。設計段階からLWCのモバイル制約を理解し、Local DevとPlaygroundを利用したアジャイルな検証サイクルを確立し、自社に適した配信モデルを選択することで、真のビジネス価値を生み出すことができます。

開発者、アーキテクト、そしてシステム管理者がそれぞれの役割における仕様の境界を把握することで、B2B/B2C双方における高度なモバイルモダナイゼーションを実現できるはずです。