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

企業がB2BのカスタマーポータルやB2Cのコミュニティを展開する際、ブラウザベースのWebアクセスだけではモバイル体験に限界を感じるケースが増えています。特に、セッション切れによって毎回パスワードを入力する手間の発生や、プッシュ通知などのデバイス固有機能へのアクセスの難しさは、ユーザーの定着率（アダプション）を低下させる実際の課題です。

本連載では、既存の設定を活かしてネイティブアプリを構築する Mobile Publisher について全4回で解説します。第1回は、IT戦略の意思決定者やプロジェクトマネージャー向けに、他手法との比較を交えた導入価値を整理します。

モバイルアプリ化（Branded App）のビジネスニーズ

【仕様】

Mobile Publisherは、ゼロからネイティブコードを記述することなく、既存のExperience CloudサイトをiOSおよびAndroid向けのアプリケーションとして生成するプラットフォームです。Auraフレームワークのテンプレートや、Lightning Web Runtime（LWR）の「Build Your Own (BYO)」テンプレートにシームレスに対応しています。また、Face IDやTouch IDなどの生体認証を利用した永続的ログイン（Persistent Login）機能をサポートしています。

Mobile Publisher では、ブランド設定されたモバイルアプリケーションに次のネイティブ機能を追加できます。

• 永続認証
• 生体認証ロック解除（Face IDやTouch ID）
• 統合バーコードリーダー
• 地理位置情報
• モバイルデバイスに保存されている連絡先
• iOS の Apple Wallet とのインテグレーション
• 下部タブバーナビゲーション
• その他の多くの機能

【見解】

Web向けに投資した開発リソースをそのままモバイル環境へと展開できる（Build Once and Deploy Across Web and Mobile）仕組みは、開発の初期コストを大幅に抑えます。また、セキュリティ要件の厳しいエンタープライズ環境において、ユーザー体験を損なわずに生体認証ログインを提供できる点は、単なるWebサイトのラッパー以上の価値をもたらすでしょう。

「Build vs. Buy」：スクラッチ開発との戦略的比較

モバイル戦略において、「自社開発（Build）」か「既存プラットフォームの活用（Buy）」かの選択は技術的・戦略的な分岐点です。ここでは、React NativeとSalesforce Mobile SDKを用いたスクラッチ開発との比較を行います。

【仕様】

React Nativeは単一のJavaScriptコードベースからiOSおよびAndroid向けのネイティブアプリを生成するフレームワークであり、Salesforce Mobile SDKと連携させることで強固なオフライン機能（暗号化されたローカルストレージや複雑な同期ロジック）や、自由な画面遷移などの完全なUI制御が可能です。

一方、Mobile Publisherはオフラインデータへのアクセスに非対応（最小限）であり、UI設計もSalesforce Lightningフレームワークの構造に依存します。

【見解】

スクラッチ開発は自由度が高い反面、運用保守に起因する技術的負債のリスクが伴います。例えば、Salesforce Mobile SDKがサポートするReact Nativeのバージョンと、React Native自体の最新バージョンとの間に数か月から1年以上のタイムラグが生じるケースが報告されています。ホスティングや、Apple/GoogleのOS仕様変更に伴う継続的なコード改修コストを考慮すると、専任の開発チームを持たない場合、スクラッチ開発のROIは低下しやすいと言えます。

Mobile Publisherが適しているユースケースは？

前述の比較を踏まえ、各手法の適性を整理します。

評価軸	Mobile Publisher (Buy)	React Native等スクラッチ開発 (Build)
市場投入スピード	既存のデータモデルとUI設定を直接再利用するため非常に高速（数週間規模）	企画、UX設計、API統合、テストからなるフルスクラッチ構築が必要（中〜長期間）
UI/UXの設計柔軟性	Salesforce Lightningフレームワークの構造に依存しており、柔軟性は低め（ナビゲーションタブバー等はカスタマイズ可）	自由な画面遷移、アニメーション、独自コンポーネントを設計できる完全なカスタマイズが可能
オフラインデータへのアクセス	最小限、または非対応（常時オンライン接続を前提）	Mobile SDKによる暗号化されたローカルストレージや同期ロジックを実装可能（強力）
要求される開発リソースとスキル	LWC、Experience Builder、および宣言的設定の管理者スキル	JavaScript、React Native、Swift、Kotlin、モバイルDevOpsに関する高度なスクラッチ開発・運用の専門知識
継続的な運用保守コスト	プラットフォームのアップデートはSalesforceが管理する（低〜中）	Nodeパッケージの依存関係解決、OS仕様変更に伴う継続的な改修が必須（高）

【見解】

Mobile Publisherの採用を強く推奨：

• 高度なオフライン同期機能を必要としない場合
• 特殊なハードウェア連携を必要としない場合
• 既存のSalesforceデータに基づくパートナーポータルや社内ツール、B2Cポータルのモバイル化

React Nativeなどによるスクラッチ開発を推奨：

• 電波の届かない環境での作業が中心となるフィールドサービス用途
• 競合他社とUI/UXの独自性で激しく競争するコンシューマー向け市場

第1回のまとめ

Mobile Publisherは、既存のプラットフォーム投資を再利用し、セキュアなモバイル体験を迅速に市場投入するための現実的な選択肢です。自社の要件がプラットフォームの提供範囲（UI制約やオフライン要件など）に合致するかを見極めることが、プロジェクト成功の第一歩となります。

第2回では、開発環境に焦点を当て、Live Previewや仮想デバイス活用した具体的なフロントエンド検証ワークフローについて解説します。

参考URL

Mobile Publisher を使用した Experience Cloud サイト用のブランド設定されたモバイル アプリケーションの作成

Discover How To Transform Your Experience Site Into a Mobile Publisher App

Mobile Publisher for Experience Cloud FAQ

Salesforce Mobile Publisher vs Custom App Development: What Should You Choose?

React vs React Native: Key Differences and Use Cases