サイトのゲストユーザが作るレコードの所有者の設定方法
Salesforceサイトのゲストユーザは、いまはレコードの所有者になれません。何が制限され、何を許せるのかを確認してから、標準機能でのオーナー設定と、当時の記事にあったApexの対応例の現在の扱いを説明します。
ゲストユーザに何を許すか
Salesforceサイト(Experience Cloudサイトなど)に来た未ログインの訪問者は、内部的に「ゲストユーザ」として扱われます。このゲストユーザに何を見せ、何をさせるかは、便利さより先にセキュリティの側から決めます。Salesforceは数年かけて、ゲストユーザに既定で許すことを段階的に絞ってきました。
| 時期 | 強制された内容 |
|---|---|
| Summer '20 | ゲストユーザから「View All Users」権限を削除 |
| Winter '21 | 「ゲストユーザのレコードアクセスをセキュアにする」設定と「ゲストが作成したレコードをデフォルトオーナーに割り当てる」設定を有効化。以降は無効化できません |
| Spring '25 | デフォルトオーナーへの割り当て設定自体が削除できなくなり、既定で有効に |
⚠️ 当時の記事はSummer '20・Winter '21の適用時期を扱っていましたが、いまはその先まで進んでいます。現在は、組織の作成時期にかかわらず、Experience Cloudサイトを持つすべての組織でこれらの設定が有効です。
いまはゲストユーザがレコードの所有者になりません
ゲストユーザは、レコードの所有者になれません。サイトのゲストユーザが取引先や取引先責任者を作成すると、そのゲストユーザ自身ではなく、組織内であらかじめ指定した有効なユーザ(デフォルトオーナー)にレコードが割り当てられます。デフォルトオーナーを設定していない場合は、サイトのオーナーが割り当てられます。
あわせて、既定の外部アクセスも変わっています。「ゲストユーザのレコードアクセスをセキュアにする」設定が有効な組織では、すべてのオブジェクトの組織全体のデフォルト(外部アクセス)が強制的に「非公開」になり、この設定は変更できません。ゲストユーザにレコードを読ませたい場合は、次のいずれかに限られます。
| 許される方法 | できること |
|---|---|
| ゲストユーザ共有ルール | 基準(条件)に一致するレコードへの、読み取り専用アクセスのみ |
| 標準のオブジェクト権限・項目レベルセキュリティ | ゲストユーザプロファイルへの権限設定 |
⛔ ゲストユーザは、公開グループやキューに追加できません。手動共有やApexの共有管理(with sharingを外して読ませるのとは別の、共有レコードを作る方法)も、ゲストユーザには使えません。ゲストユーザ共有ルールも所有者ベースは作れず、基準ベースのみです。条件に一致した瞬間、ログインなしの誰にでも読み取りアクセスが渡ることになるため、条件は必要最小限に絞ります。
デフォルトオーナーを標準機能で設定する
Digital Experiencesを開く
設定から「Digital Experiences」を検索し、対象サイトの「All Sites」を選びます。
Administration・Preferencesを開く
サイトのWorkspacesから「Administration」→「Preferences」に進みます。
デフォルトオーナーを選ぶ
「ゲストユーザが作成したレコードのオーナー」の項目で、組織内の有効なユーザを選びます。
保存する
Saveを押します。以降、このサイトのゲストユーザが作成したレコードは、選んだユーザの所有になります。
B2B Commerce for VisualforceのようにDigital Experiencesを使わない構成では、別の設定画面でデフォルトオーナーを指定します。画面の場所はサイトの種類によって違うため、自組織がどちらの構成かをまず確認してください。
当時の記事にあったApexの対応例といまの扱い
当時の記事では、ゲストユーザが作成した取引先レコードを、同じセッションで参照しようとしたときに「参照権限がない」というシステムエラーが起きる例を挙げ、2つの対応を示していました。このうち1つは、いまの仕様では効果がありません。
with sharing・without sharing・inherited sharingは、クラス単位で共有ルールを強制するかどうかを決める修飾子です。with sharingは現在のユーザの共有ルールを強制します。without sharingは共有ルールを適用しません。inherited sharingは、呼び出し元のクラスの共有モードを引き継ぎますが、Visualforceコントローラのように呼び出し元がないエントリポイントとして使われた場合は、既定でwith sharingとして実行されます。当時の記事の「対応例その2」(with sharingをinherited sharingに変える)は、サイトのVisualforceコントローラがエントリポイントである限り、いまの仕様では効果がありません。エントリポイントのinherited sharingはwith sharingと同じ扱いになるため、共有ルールは変わらず強制され、同じ参照エラーが再現します。
「対応例その1」(without sharingに変える)は、いまも技術的にはエラーを止められます。ただし、共有ルールを無視する範囲がクラス全体に広がる点は変わりません。ゲストがアクセスするコントローラでwithout sharingを使うときは、次のように範囲を絞ってください。
| 避ける書き方 | 代わりにすること |
|---|---|
サイトのコントローラ全体をwithout sharingにする | 参照が必要な1つのSOQLだけを、専用の小さなwithout sharingクラスに切り出す |
without sharingのクラスに項目を増やしていく | 返す項目を、画面表示に必要な最小限だけに絞る |
ここで間違えやすい
| 間違い | 何が起きるか |
|---|---|
| ゲストユーザに公開グループ・キュー・手動共有でアクセスを渡そうとする | ゲストユーザには使えません。ゲストユーザ共有ルールのみが選べます |
| 所有者ベースのゲストユーザ共有ルールを作ろうとする | 作成できません。基準ベースのみです |
with sharingをinherited sharingに変えれば参照エラーが直ると考える | エントリポイントではwith sharingと同じ扱いになり、直りません |
| デフォルトオーナーを設定しないまま公開する | サイトのオーナーに割り当てられます。運用担当者を明示的に選んでおきます |
確認した環境
- 2026年9月、help.salesforce.comの公式ヘルプ(Assign Records Created by Guest Users to a Default User in the Org、Secure Guest Users' Sharing Settings and Record Access、Create Guest User Sharing Rules、Guest User Security Policies and Timelines)で、既定の外部アクセスと設定時期を確認しています
with sharing・without sharing・inherited sharingの挙動は、developer.salesforce.comのApex Developer Guide(Use the with sharing, without sharing, and inherited sharing Keywords)で確認しています
まとめ
- ゲストユーザは、いまはレコードの所有者になれません。指定したデフォルトオーナーか、サイトのオーナーに割り当てられます
- 既定の外部アクセスは、ゲストユーザが有効な組織ではすべてのオブジェクトで「非公開」に固定され、変更できません
- ゲストユーザへの読み取りアクセスは、基準ベースのゲストユーザ共有ルールだけが方法です。公開グループ・キュー・手動共有は使えません
inherited sharingは、Visualforceコントローラのようなエントリポイントではwith sharingと同じ扱いになり、当時の記事の対応例その2は効果がありませんwithout sharingを使う場合は、コントローラ全体ではなく、必要な参照だけを切り出した小さなクラスに絞ります
Salesforceの導入・運用についてご相談ください
導入前の検討から、お使いの環境の改修・運用、AIとの連携まで承ります。状況を伺ったうえで、進め方をご提案します。