はじめに

Salesforce Developers Blog で、Salesforce Multi-Framework が GA（General Availability）になったという記事が公開されていました。

米国版：2026年7月16日公開
日本語抄訳：2026年7月23日公開

Salesforce Multi-Framework は、Salesforce 上で React アプリをネイティブに構築・実行するための仕組みとして紹介されています。公式ブログでは、GraphQL による Salesforce レコード操作、Apex 呼び出し、UI API 経由でのユーザーコンテキスト取得ができると説明されています。ここでいう認証やトークン管理が不要という説明は、アプリ側でアクセストークンを直接扱わなくてよい、という意味であり、Salesforce の権限モデルが不要になるわけではありません。

この記事では、実際のハンズオン手順ではなく、「何が GA になったのか」「LWC とどう分けて考えるとよさそうか」「試す前に何を確認すべきか」を整理します。

※本記事は個人の整理メモです。仕様判断は、必ず英語版の公式ドキュメント・公式ブログを優先してください。日本語抄訳にも「正式言語は英語」と明記されています。

Salesforce Multi-Framework とは

Salesforce Multi-Framework は、公式ブログでは Headless 360 Platform 上で動作するフレームワーク非依存のランタイムとして説明されています。GA時点の利用可能条件としては、公式ブログで Summer '26 リリース以降のすべての Hyperforce 組織 と説明されています。

今回の公式記事では、主に React アプリを Salesforce 上で動かす文脈で紹介されています。

ざっくり整理すると、次のような位置づけです。

React アプリ
  ↓
Salesforce Multi-Framework
  ↓
Salesforce Platform
  ├─ GraphQL によるデータ操作
  ├─ Apex 呼び出し
  └─ UI API によるユーザーコンテキスト取得

従来、Salesforce 上の画面開発といえば Lightning Web Components（LWC）を中心に考えることが多かったと思います。Multi-Framework は、そこに React という選択肢を Salesforce のランタイム上に持ち込むものと捉えると理解しやすそうです。

今回 GA で変わったこと

公式ブログで確認できる主な変更点は以下です。

本番組織へのデプロイが可能になった

GA 発表ブログでは、Summer '26 リリース以降のすべての Hyperforce 組織で利用可能と説明されています。
一方、現行の Developer Guide では、Enterprise / Performance / Unlimited / Developer / Partner Developer Edition、Hyperforce 上での稼働、デフォルト言語が英語であることが利用条件として記載されています。実際の利用可否は、最新の Developer Guide と対象組織の Setup で確認するのが安全です。

本番組織
Sandbox
Developer Edition
Scratch 組織

ここで大事なのは、単に「Summer '26 以降のすべての Salesforce 組織」と読むのではなく、公式ブログ上の表現では Hyperforce 組織であることが前提になっている点です。

ここは実務上かなり重要です。
記事中の表現だけで判断するより、実際の対象組織の Setup で Multi-Framework / Salesforce App Domain 関連の設定が確認できるかを見る、という温度感で捉えるのがよさそうです。

確認観点としては、たとえば次のようなものがあります。

対象組織のリリースが Summer '26 以降か
対象組織が Hyperforce 上で稼働しているか
対象組織が公式ブログで示されている利用条件に合っているか
Setup の「React Development with Salesforce Multi-Framework」で有効化状態を確認できるか
本番導入前に Sandbox で検証できるか

Salesforce App Domain が使われる

公式ブログでは、Multi-Framework の従業員向けアプリは salesforce.app ドメイン上で動作すると説明されています。

これは単なるURLの違いというより、ブラウザの同一オリジンポリシーを使って、アプリ間の Cookie やストレージを分離するための仕組みとして説明されています。

個人的には、ここは Multi-Framework を理解するうえで大事なポイントだと感じました。

React アプリを Salesforce に載せる場合でも、単に「どこかに静的ファイルを置いて iframe で表示する」という話ではなく、Salesforce 側のセキュリティモデルやブラウザの境界を前提にしたランタイムとして設計されている、と捉えると整理しやすいです。

Data SDK が GA になり、API に破壊的変更がある

公式ブログでは、Data SDK も GA になったと説明されています。
ただし、Beta から GA への移行では破壊的変更があります。

確認できる範囲では、たとえば次のような変更が挙げられています。

パッケージ名が @salesforce/sdk-data から @salesforce/platform-sdk に変更
sdk.graphql 自体がなくなるのではなく、読み取りは sdk.graphql?.query()、書き込みは sdk.graphql?.mutate() を使う形に変更
mutation では、パラメーターキーも query ではなく mutation を使う
result.data が undefined になり得るため、optional chaining が推奨されている

Beta 版で試していた人は、GA になったからそのまま本番化できる、とは考えない方がよさそうです。
まずは SDK のパッケージ名、呼び出しメソッド、mutation 時のパラメーターキー、レスポンスの扱いを見直す必要があります。

AppLauncher ではなく CustomApplication が推奨に

Beta 版で使われていた AppLauncher ターゲットは非推奨となり、従業員向けアプリでは CustomApplication が推奨されると説明されています。

ここで注意したいのは、単に .uibundle-meta.xml の <target> を AppLauncher から CustomApplication に書き換えるだけではなく、Custom Application 側のメタデータも必要になる点です。公式ブログでは、UI Bundle を参照する Custom Application メタデータファイルと、アプリの表示権限を付与する Permission Set が必要と説明されています。

なお、顧客向けアプリの Experience ターゲットは変更ありません。

このあたりは、既存の Beta 検証資産がある場合に見落としやすいポイントです。コードだけでなく、メタデータ、権限、アプリの公開先も含めて確認した方がよさそうです。

LWC と React / Multi-Framework をどう分けて考えるか

ここからは公式情報を踏まえた個人の整理です。

Salesforce 開発では、引き続き LWC が自然な選択肢になる場面は多いと思います。
一方で、Multi-Framework は React を前提にした既存の知識・部品・開発体験を活かしたい場面で候補になりそうです。

LWC が向いていそうなケース

Salesforce 標準画面との親和性を重視する
Lightning Experience 内で自然に動くコンポーネントを作りたい
Salesforce 開発者・管理者が保守しやすい構成にしたい
既存の LWC / Aura / Apex 資産と近いところで拡張したい

React / Multi-Framework が向いていそうなケース

React ベースの UI 資産や設計知見を活かしたい
Salesforce 外のフロントエンド開発者も参加しやすい構成にしたい
GraphQL や Data SDK を使って、Salesforce データを扱う React アプリを作りたい
Salesforce Platform のセキュリティやガバナンスの中で React アプリを動かしたい

ただし、これは「LWC より React がよい」という単純な話ではなさそうです。
むしろ、Salesforce ネイティブな拡張は LWC、React の開発体験やエコシステムを活かしたいアプリは Multi-Frameworkというように、用途で分けて考えるのが現実的だと思います。

なお、公式ブログでは今後のロードマップとして、Lightning 内で LWC と外部 React コンポーネントを共存させる Microfrontends にも触れられています。現時点では今後の予定として扱われているため、今すぐ Lightning 内へ自然に埋め込む前提ではなく、用途を分けて考えるのがよさそうです。

試す前に確認したいこと

Multi-Framework は GA になりましたが、実際に試す前には、少なくとも次の点を確認しておくとよさそうです。

1. 自分の組織で利用できるか

公式ブログでは、Summer '26 リリース以降のすべての Hyperforce 組織で利用可能と説明されています。

まずは Setup の React Development with Salesforce Multi-Framework に移動し、以下を確認します。

「About Salesforce Multi-Framework」メッセージが表示されるか
「Enable Salesforce App Domain」トグルがオンになっているか
対象組織のリリースが Summer '26 以降か
対象組織が Hyperforce 上で稼働しているか
本番導入前に Sandbox で検証できるか
Government Cloud など通常と異なる環境での利用可否は、最新の公式ドキュメントや Salesforce サポートで個別に確認する
Developer Guide に記載されている対象 Edition か
組織のデフォルト言語が英語という現行の利用条件を満たしているか

記事やブログだけで判断せず、実際の対象組織の Setup 表示で確認するのが安全です。

2. Beta 版からの移行影響がないか

Beta 版で作成したアプリがある場合、以下は見直し対象です。

SDK パッケージ名（@salesforce/sdk-data から @salesforce/platform-sdk）
sdk.graphql?.query() / sdk.graphql?.mutate() への変更
mutation 時のパラメーターキー（query ではなく mutation）
result.data の undefined 考慮
.uibundle-meta.xml の <target> を AppLauncher から CustomApplication に変更
<uiBundle> 参照を持つ Custom Application メタデータの追加
アプリの表示権限を付与する Permission Set の追加
Scratch 構成の UiBundleSettings を削除
顧客向けアプリの Experience ターゲットは変更不要

特に SDK 周りは、ビルドエラーだけでなく、実行時のデータ取得・更新処理にも影響する可能性があります。

3. 認証・権限を「不要」と誤解しない

公式ブログでは、React アプリから GraphQL、Apex、UI API を利用する際に、認証やトークン管理が不要と説明されています。

ここでいう「不要」は、アプリ側でアクセストークンや認証処理を直接扱わなくてよい、という意味で捉えるのが安全です。

Salesforce の権限モデルが不要になるわけではありません。
GraphQL / UI API によるデータアクセスでは、コンテキストユーザーのオブジェクト権限や項目レベルセキュリティなどが反映され、UI API では共有設定も考慮されます。Apex については実行モードや実装によって権限の扱いが異なるため、個別に確認する必要があります。

4. 本番用途なら運用・保守体制も見る

React アプリとして作れるようになると、フロントエンド開発の自由度は上がりそうです。
一方で、Salesforce 管理者だけで保守できる範囲を超える可能性もあります。

本番利用を考えるなら、技術検証だけでなく次も確認した方がよさそうです。

誰が React アプリを保守するか
Salesforce リリース時の回帰テストをどう行うか
パッケージ・依存ライブラリの更新をどう管理するか
権限変更や項目変更にどう追従するか
LWC と React アプリの使い分けルールをどう決めるか

今後のロードマップとして触れられていること

公式ブログでは、今後のロードマップとして次の項目が挙げられています。

Microfrontends：Lightning 内で LWC と外部 React コンポーネントを共存させ、イベントを受け渡す
Angular サポート
ローカライゼーション：Translation Workbench やメタデータを使った言語・ロケール・タイムゾーン対応
Managed packages：Multi-Framework アプリを管理パッケージとして構築・テスト・配布・デプロイする
App management：App Manager からアプリ名、説明、URL などを管理する

ここは「今すぐ使える機能」ではなく、今後の予定として読む必要があります。
特に、ISV / OEM 文脈での管理パッケージ配布や、日本語環境でのローカライゼーションを前提にする場合は、実際の提供状況を公式情報で確認した方がよさそうです。

まず試すならどういう順番がよさそうか

まだ手元で検証していないため、具体的な成功手順としては書きません。
ただ、調査メモとしては、次の順番で確認すると整理しやすそうです。

公式ドキュメントと英語版ブログを確認する
Developer Edition または Sandbox で Setup の「React Development with Salesforce Multi-Framework」を確認する
「Enable Salesforce App Domain」トグルと「About Salesforce Multi-Framework」メッセージを確認する
公式の開始手順に沿って最小構成の React アプリを作る
GraphQL で読み取りだけ試す
Apex 呼び出しを試す
権限違いのユーザーで挙動を確認する
本番化する場合の保守・リリース手順を整理する

特に最初は、更新系の処理よりも、読み取り系の GraphQL から試す方が安全そうです。

今回の整理ポイント

Salesforce Multi-Framework GA のポイントは、次のように整理できそうです。

React アプリを Salesforce 上でネイティブに動かす選択肢が GA になった
GraphQL、Apex、UI API との連携が公式ブログで説明されている
Summer '26 リリース以降のすべての Hyperforce 組織で利用可能と説明されている
対象として本番組織、Sandbox、Developer Edition、Scratch 組織が挙げられている
ただし、公式ブログ上の条件は Hyperforce 組織であることが前提なので、自組織の稼働基盤と Setup 表示を確認する必要がある
Beta からの移行では SDK、パラメーターキー、メタデータ、権限セットに注意が必要
LWC の置き換えではなく、用途に応じた選択肢として見るのがよさそう

まとめ

Salesforce Multi-Framework の GA は、Salesforce 開発者にとって React を Salesforce Platform 上で扱う選択肢が本番検討しやすくなったという点で注目できる内容です。

ただし、すぐに既存の LWC 開発を置き換える話ではなく、組織の有効化状態、権限モデル、Beta からの変更点、保守体制、今後のロードマップを確認したうえで検討するのがよさそうです。

まずは Sandbox や Developer Edition で、公式ドキュメントに沿って小さく試し、LWC と React / Multi-Framework の役割分担を整理するところから始めるとよいと思います。

参考（公式情報）

Build with React on Salesforce: Multi-Framework Is Now GA
https://developer.salesforce.com/blogs/2026/07/build-with-react-on-salesforce-multi-framework-is-now-ga
React で作り、Salesforce で動かす: Salesforce Multi-Framework が GA に（日本語抄訳）
https://developer.salesforce.com/blogs/2026/07/build-with-react-on-salesforce-multi-framework-is-now-ga-jp
Salesforce Multi-Framework 公式ドキュメント
https://developer.salesforce.com/docs/platform/multiframework/guide/
Build with React, Run on Salesforce: Introducing Salesforce Multi-Framework（Beta 発表記事）
https://developer.salesforce.com/blogs/2026/04/build-with-react-run-on-salesforce-introducing-salesforce-multi-framework
Salesforce Multi-Framework Recipes
https://github.com/trailheadapps/multiframework-recipes