全従業員ユーザーに対するMFA（多要素認証）の適用準備

この記事では、「影響を受けるユーザーは誰ですか？」で定義されている、特権ユーザーまたは管理者権限を持たないユーザーに対するMFAの要件について説明します。特権ユーザーと管理者はフィッシング耐性のあるMFAの使用が必須ですが、Salesforceは、IDベースの脅威に対する最高レベルの保護を確保するために、すべてのユーザーがフィッシング耐性のあるMFA（セキュリティキーと組み込みAuthenticator）を採用することを強く推奨します。

Salesforce Platform の今後のセキュリティ変更に関するロードマップの詳細については、「2026年6月から開始される新しいセキュリティコントロール要件への準備」を参照してください。

7月6日更新：展開の透明性を高めるため、リリースグループと対象インスタンスごとにまとめた適用スケジュールを公開しました。リリースグループ適用スケジュールを参照して、組織ごとの具体的なスケジュールを確認ください。

動画を見る

全従業員ユーザーに対するMFA要件の概要については、以下の動画をご覧いただくか、リンクをクリックし新しいタブで本動画を開きご覧ください：「全従業員ユーザーに対するMFA」

変更内容

Salesforceは、本番組織とSandbox組織の両方において、直接UIログインとシングルサインオン（SSO）を含むすべての従業員ログインに対して、MFA（多要素認証）を強制的に適用します。

SalesforceでサポートされているMFA検証方法は、セキュリティ強度によって分類されています。

フィッシング耐性のあるMFA (多要素認証)（推奨）：最も安全でシームレスな体験を提供します。これには、組み込みAuthenticator（Touch ID、Face ID、Windows Helloなど）とセキュリティキー（ YubicoのYubiKey、GoogleのTitan Security Keyなど）が含まれます。ユーザーに最速かつ最も安全な認証フローを提供するため、パスキーによるパスワードなしのログインの採用を強くお勧めします。
標準MFA：Salesforce AuthenticatorモバイルアプリとサードパーティのTOTP認証アプリが含まれます。

MFAの適用変更が行われると、パスキーを作成するよう促すプロンプトが表示されるようになります。詳細はリリースノートを参照してください（注：パスキー優先のMFA登録フローのUIラベルは現在、英語のみで利用可能です。その他の言語は、今後のパッチリリースでサポートされる予定です）。

Create a Passkey screen for non-privileged users

変更理由

セキュリティを強化し、組織をより安全に保護するため、Salesforceは全従業員に対してMFA（多要素認証）をシステム的に強制することで、より強固なセキュリティ基盤の構築を進めています。この変更により、盗まれた認証情報、クレデンシャルスタッフィング、フィッシングなどに起因するアカウント乗っ取り（ATO）のリスクを軽減できます。

この変更はいつから適用になりますか？

Sandbox組織：2026年7月10日から開始
本番組織： 2026年7月20日から開始

リリースグループ適用スケジュール

組織の具体的な適用日を特定するには、以下の手順を実施ください。

対象組織のSalesforceインスタンスを特定します。「自分の Salesforce 組織のインスタンス情報の表示」を参照してください。
本ナレッジ記事の「その他のリソース」セクションにある「リリースグループのインスタンスマッピング」表にて、対象組織のインスタンスのリリースグループを確認ください。
下記の「リリースグループ適用スケジュール」で、該当するリリースグループの適用日を確認します。

注：非プレビューSandbox組織のリリース時期は、プレビューSandbox組織とは異なります。リリース時期を確認するには、対象インスタンスごとのリリースグループを組織ごとに確認してください。

リリースグループ	開始日	終了日
Sandbox [プレビュー]	2026年7月10日	2026年7月10日
R0	2026年7月20日	2026年7月20日
R1	2026年7月27日	2026年7月28日
R2a	2026年8月10日	2026年8月17日
R2b	2026年8月10日	2026年8月13日
日本と韓国	2026年9月1日	2026年9月1日
上記以外すべて	2026年9月3日	2026年9月3日

影響を受けるユーザーは誰ですか？

本ナレッジ記事の内容に該当するユーザーは、本番組織またはSandbox組織でSalesforceにログインする（直接UIログインまたはSSOログイン）すべてのユーザーのうち、以下の条件を満たすユーザーが対象です。

システム管理者プロファイル、すべてのデータの編集、すべてのデータの参照、アプリケーションのカスタマイズ、またはApex 開発のいずれかの権限を持たないユーザー
- 注: これらの権限を持つユーザーは、より厳格なフィッシング耐性のあるMFA要件の対象となります。

注：

この要件は、 社内ユーザー（つまり、標準ユーザーライセンスを持つすべてのユーザー）が、貴社の従業員コミュニティまたはその他のExperience Cloud Siteにログインする場合に適用されます。
Chatter Plusのユーザーは社内ユーザーとみなされ、この要件の対象となります。

影響を受けないユーザーは誰ですか？

以下の基準を満たすユーザーは既に準拠しているか、免除対象となっているため、変更はありません。

Experience CloudまたはExperience Siteへのログインでは、MFAの使用は強制されず、組織のシステム管理者が設定可能なオプション設定として引き続き提供されます。この例外は、Experience Cloudユーザーライセンスを持つ外部ユーザーに適用されます。
Chatter ExternalおよびChatter FreeユーザーはMFAの対象外です。
ユーザーが既にMFAを登録しており、かつユーザーに「ユーザーインターフェースログインの多要素認証」権限が割り当てられているか、または組織全体のMFA設定「Salesforce 組織へのすべての直接 UI ログインに多要素認証 (MFA) が必要」が有効になっている場合の、UIから直接するログインユーザー
SSOログインにおいて、 SSO IdPが既に標準MFAまたはフィッシング耐性のあるMFAシグナル（AMR/ACR）をSalesforceに正常に渡しているユーザー。

SSOログインの場合、お客様のIDプロバイダー（IdP）からのIDトークンまたはSAMLレスポンスで業界標準のシグナル（ACR（認証コンテキストクラス参照）およびAMR（Authentication Methods Reference 、RFC 8176））の送信に依存します。

想定動作

管理およびポリシーの変更

組織全体のMFA設定の適用：「Salesforce 組織へのすべての直接 UI ログインに多要素認証 (MFA) が必要」設定が有効になり、管理者はこれを選択解除または無効にすることができなくなります。
MFA免除への影響：「除外ユーザーの多要素認証を放棄 」権限は、MFAを自動的に免除しなくなります。この変更後、この権限を持つユーザーは、ログイン時にID 検証方法の登録と使用を求められます。有効なユースケース（自動テストツールなど）でこの免除を復元するには、Salesforceサポートに連絡して承認を得る必要があります。
トライアル組織の移行：サブスクリプションに移行したトライアル組織には、MFA要件に関する30日間の猶予期間は適用されなくなります。

ユーザーログインと登録の手順

直接 UI ログイン：ユーザーが以前にMFA認証に登録していない場合、サポートされているMFA認証サービスの登録を求められます。以降のすべてのログインでは、MFA認証を完了してログインする必要があります。
強化されたパスワードなしのログイン： login.salesforce.comおよび私のドメインページが更新され、パスワードなしでユーザー名を入力できるようになります。この変更により、パスワードではなくパスキー（組み込みAuthenticatorまたはセキュリティキー）でログインするユーザー体験が向上します。UIログインを使用するテスト自動化は更新が必要になる場合があります。また、9月に予定されているログインエクスペリエンスの変更にもご注意ください。
フィッシング耐性のあるMFAのデフォルト設定：ユーザーが新しいMFA検証方法を登録する必要がある場合、パスキー（組み込み Authenticator またはセキュリティキー。これらはフィッシング対策オプションです）の登録を求められます。フィッシング耐性のあるMFAオプションを必要としないユーザーは、サードパーティ製の認証アプリを選択できます。
アプリケーション内バナー通知は、以下の条件を満たすすべてのユーザーに表示されます。
- シングルサインオン（SSO）が構成されている、または
- 「Salesforce 組織へのすべての直接 UI ログインに多要素認証 (MFA) が必要」設定が無効になっている、または
- 「除外ユーザーの多要素認証を放棄」権限が割り当てられている、または
- 組み込み Authenticator およびセキュリティキーの検証方法がユーザーに提供されていません。

シングルサインオン（SSO）およびシステム連携要件

SSO要件：IDプロバイダーが有効なAMR（Authentication Methods Reference）またはACR（認証コンテキストクラス参照）シグナルを送信しないSSOユーザーは、Salesforce UIで ID 検証方法を登録する必要があります。
OAuth Webサーバーおよびハイブリッドトークンフロー：これらのフローを使用する接続アプリケーションまたは外部クライアントアプリケーションでは、OAuth認証を完了するためにSalesforce UIへのログインが必要となります。このログインはMFA（多要素認証）の対象となります。JWTベアラーまたはクライアントログイン情報フローを使用するアプリは、UIへのログインが不要なため影響を受けません。

認証強度の決定と評価ロジック

認証強度レベル

Salesforce は、すべてのログインをその強度に基づいて評価します。Salesforce に直接ログインする場合でも、シングルサインオン (SSO) プロバイダーを使用する場合でも、ログイン方法 (Salesforce を IdP として使用するか、他の SSO IdP を使用するか) と、存在する特定の検証要素またはシグナルに基づいて、認証は「フィッシング耐性 MFA」、「標準 MFA」、「脆弱な MFA / MFA なし」の 3 つの階層のいずれかに分類されます。分類は、直接ログイン (Salesforce を IdP として使用する場合) するか、SSO 経由でログインするかによって異なります。

分類	*Salesforceへの直接ログイン（Salesforce MFA認証）*	SSO AMR（Authentication Method Reference）シグナル	SSO Authentication Context Class Reference (ACR) シグナル	結果
*フィッシング耐性MFA（推奨）*	セキュリティキー（WebAuthn）、組み込みAuthenticator（Touch ID、Windows Hello）	cert, face, fido, fido2, fpt, hwk, iris, passkey, phr, pki, pop, pwlesspasskey, retina, sc, smartcard, swk, tlsclient, wia, x509	fido, fido2, fpt, hwk, passkey, phr, pki, pwlesspasskey, retina, smartcard, swk, tlsclient, wia, x509	ログイン成功
*標準MFA*	Salesforce Authenticator、TOTP アプリ (Google/Microsoft 認証)	mfa, mobiletwofactorcontract, multipleauthn, okta_verify, pin, pgp, publickey, rsa, timesynctoken, user, vbm	mfa, mobiletwofactorcontract, multipleauthn, okta_verify, pgp, publickey, rsa, timesynctoken, vbm	ログイン成功
*脆弱なMFA／MFAなし*	MFAなし	pwd, sms, tel, email		登録と*標準MFA*認証の使用が完了するまで、ログインはブロックされます。

これらの値は変更される可能性があります。

SSO IdPからのAMRおよびACRシグナルを評価し、標準MFAまたはフィッシング耐性MFAの要件が満たされているか判定する方法

Salesforceは、OIDC または SAML のどちらを使用しているか、またシグナルがAMR値かACR値かによって、SSO IDプロバイダー（IdP）からのシグナルを異なる方法で評価します。 AMR と ACR では、それぞれ受け入れられるシグナル値が異なります (上記の表の値リストを参照してください)。要件を満たすには、SSO IdP は、必要な階層の適切な AMR または ACR 列の値と一致する値を少なくとも 1 つ送信する必要があります。フィッシング耐性リストにある値は、標準 MFA チェックも自動的に満たします。

追加の評価基準：

SAML AMR:

Salesforceは、属性名に amr または authnmethodsreferences が含まれるIdP属性値をAMRシグナルとして解析および評価します。
セミコロンで区切られた文字列（例: hwk;face;mfa）内の属性値は解析および評価されますが、カンマで区切られた値は評価されません。
URN/URL値は : または / で分割されるため、urn:custom:auth:hwk と https://example.com/auth/hwk はどちらも hwk として解決されます。

OIDC AMR:

OIDC AMRは配列（例: [hwk, mfa]）であり、完全一致で比較されます。

ACR（OIDCとSAMLの両方）:

小文字化された文字列に対して contains() チェックを使用するため、mfa のような短いトークンは urn:oasis:names:tc:SAML:2.0:ac:classes:mfa のような完全なURNと一致します。

適用前：準備方法

MFAの設定とユーザーを確認する：
1. 「Salesforce 組織へのすべての直接 UI ログインに多要素認証 (MFA) が必要」設定の状態を確認し、直接MFA権限を持つユーザーを特定します（プロファイル/権限セット経由）。
2. 「除外ユーザーの多要素認証を放棄」権限が割り当てられているすべてのユーザーを特定してください。この権限は変更が適用されると無効になるため、有効なユースケース（自動テストツールなど）で免除を維持するには、Salesforceサポートに問い合わせる必要があります。
組織の認証オプションを設定する：ユーザーが許可するMFA（多要素認証）方法を定義し、初回登録時にユーザーが方法を選択する方法を設定します。
1. 注： Salesforceでは、システム管理者を含む特権ユーザーにフィッシング耐性のある MFA（多要素認証）の使用を義務付けています。そのため、組み込み Authenticator またはセキュリティキーを有効にする必要があります。これらの認証方法をセットアップで有効にすると、組織のすべてのユーザーが利用できるようになります。システム管理者のみに限定して使用することはできません。
2. 【推奨】パスキーを有効にする：ID検証設定で「パスキーを使用したパスワードなしのログインを許可」をオンにすると、より高速でフィッシング耐性が強化されたログインが可能になります。ユーザーは、ユーザー名とパスキー（組み込み Authenticator やセキュリティキーなど）のみを使用してログインすることで、この要件を満たすことができます。詳しくは、パスキーを使用したパスワードなしのログインの有効化をご覧ください。
アクセス復旧手順を確立する：システム管理者がログインの問題を解決するための内部プロセス（一時的な仮の確認コードの生成など）を定義し、定期的なリセットをSalesforceサポートに頼る必要がないようにします。詳しくは、「ユーザーのMFAアクセス問題の解決」を参照してください。
MFA準拠のためのSSOの設定：SSOには主に2つの方法があります。1つは、IDプロバイダー（IdP）を更新して標準のMFA認証を必須とし、必要なAMR/ACRシグナルを送信する方法、もう1つは、SSOログインでSalesforce MFAを有効にする方法です。IdPのMFAサービスを利用する場合は、IDトークン（OpenID Connect用）またはSAMLレスポンスに必要なAMR/ACRシグナルが含まれていることを確認してください。
1. ログイン履歴を確認して、OIDC AMRシグナルを確認してください。
2. SAML ACR 値はまだログイン履歴に記録されていないため (今後のリリースで記録予定)、サードパーティ製の SAML トレーサーを使用して応答を確認してください。Salesforce SAML Validator は AMR/ACR クレームを評価しますが、現時点では「強力」または「弱い」に分類するだけであり、今回の変更で導入された特定の「弱い」、「標準」、「フィッシング耐性」の認証シグナル強度分類の定義を反映するように更新されていません。
事前に登録する：ユーザーにスケジュールを積極的に伝え、ログインの中断を避けるため、適用前にMFA（多要素認証）方法を登録するよう促してください。「Salesforce 組織の ID 検証方法の登録」を参照してください。
MFA実装のテスト：変更を本番組織に反映させる前に、まずSandbox組織でMFAを有効にして、設定とユーザー登録フローを検証してください。Salesforce組織におけるMFA実装のテストについては、「Salesforce組織におけるMFA実装のテスト」を参照してください。

適用後：エラーの解決

以下の手順は、変更によって発生したエラーを解決するものです。

ブロックされたユーザーの特定：Salesforce MFAに登録できない、またはMFAチャレンジを完了できないユーザーのログイン履歴を監視します。ユーザー (Salesforce 組織) の MFA アクセスの問題の解決 （例：ロックアウトされたユーザーの場合、システム管理者はワンタイムログインコードを生成できます）を活用し、追加のヘルプについては多要素認証 (MFA) のよくあるトラブルシューティングを参照してください。
SSOシグナルに関する問題：SSOプロバイダーがフィッシング耐性のあるMFAまたは標準MFA認証を使用しているにもかかわらず、必要なシグナルが送信されない場合、Salesforce MFAへの登録を求められます。Salesforce内でプロンプトが表示されないようにするには、SSOプロバイダーと連携して、ACRまたはAMRシグナルが正しく送信されるようにしてください。
ユーザーのロックアウト：ユーザーがロックアウトされた場合、顧客組織の管理者は一時的な本人確認コードを生成し、古い認証方法を無効にして、再登録を支援できます。詳しくは、「ユーザー (Salesforce 組織) の MFA アクセスの問題の解決」を参照してください。

よくある質問

APIログインにはどのような影響がありますか？

この変更は、UIベースの従業員ログインのみを対象としています。

Salesforce Mobile SDK を使用した Salesforce モバイルアプリ経由のログインには、どのような影響がありますか？

Mobile SDK バージョン 13.2.0 以前では、デフォルトの Mobile SDK 認証モード (WebView) は、セキュリティキーなどのフィッシング耐性のあるMFA メカニズムをサポートしていません。セキュリティキーを MFA オプションとして選択したユーザーはログインをブロックされ、組織が私のドメイン設定で高度な認証を事前に構成し、ログインサーバーとして私のドメインを使用する必要があります。これは、Mobile SDK を使用するすべての Salesforce 内部アプリおよびサードパーティアプリケーションに適用されます。また、Salesforce モバイルアプリケーションのユーザーは、「メールでログイン」オプションを使用できます。
すべてのユーザーに対するログインUXの変更：フィッシング耐性のあるMFA（多要素認証）が必須となったため、Salesforceはログインフローを変更し、ユーザーが「ログイン」をクリックした後に、まずユーザー名項目が表示され、次にパスワードまたはパスキー項目が表示されるようにします。この変更は既存のモバイルSDKアプリで機能するため、コードの変更は不要です。ただし、この2段階フローでは、以前のフローに対応するように設定されている既存の自動テストを更新する必要があります。

変更が組織またはインスタンスに反映されたかどうかを確認するにはどうすればよいですか？

「Salesforce 組織へのすべての直接 UI ログインに多要素認証 (MFA) が必要」が有効になっており、グレー表示されています。

MFAは、本番組織だけでなく、Sandbox組織にも適用されるようになったのですか？

はい。今回の変更により、Salesforceは本番組織とSandbox組織の両方にログインするすべての従業員（社内）ユーザーに対してMFA（多要素認証）を必須とします。これは、Sandbox組織を対象外としていた以前のMFA要件からの変更点です。

Experience Cloud / Community ユーザーには MFA が適用されますか？

いいえ。MFAログイン要件は、従業員（社内）ユーザーのみに適用されます。Experience Cloudにログインする外部ユーザーおよびCommunityユーザーは、MFAログイン義務の対象外です。

注： MFAは、 社内ユーザー（つまり、標準ユーザーライセンスを持つすべてのユーザー）が、貴社の従業員コミュニティまたはその他のExperience Cloud Siteにログインする場合に適用されます。

弊社では既にSSOプロバイダー（例：Okta、ADFS、Entra）を通じてMFAを適用しています。SalesforceのMFAも別途設定する必要があるのでしょうか？

SSOログインはSalesforceのMFA要件を満たすことができます。ただし、IDプロバイダー（IdP）がMFAが使用されたことを証明する有効なAMR（Authentication Methods Reference）またはACR（Authentication Context Class Reference）シグナルを送信を送信した場合に限ります。デフォルトでは、認識されたフィッシング耐性MFAまたは標準MFAシグナルを受信するまで、すべてのSSOログインはMFAなしとして扱われます。SalesforceがIdPからの有効なシグナルを検出できない場合、ユーザーはSalesforce MFAへの登録を求められます。

SalesforceはSSOプロバイダーからどのMFAシグナル値を認識しますか？

許容される値のリストについては、上記の「認証強度レベル」というタイトルのセクションにある表を参照してください。

フィッシング耐性MFAまたは標準MFAのシグナルが検出された場合、ユーザーは追加の認証要件なしに即座にアクセスできるようになります。

ただし、MFAのシグナルが弱い、またはMFAシグナルがない場合は、SalesforceのUIを介してユーザーに検証方法を選択し、Salesforceアカウントにリンクするように促されます。

「除外ユーザーの多要素認証を放棄」権限は引き続き使用できますか？

適用日以降、この権限ではMFA要件が自動的に免除されなくなります。この権限を持つユーザーは、Salesforce UIでMFAの登録と使用を求められます。有効なユースケース（自動テストツールなど）で免除を復元するには、Salesforceサポートに連絡して承認を得る必要があります。

ユーザーまたはシステム管理者がロックアウトされた場合はどうなりますか？

ユーザーがロックアウトされた場合、組織のシステム管理者は一時的な仮の確認コードを生成し、古い認証方法を無効にして、再登録を支援できます。詳しくは、ユーザー (Salesforce 組織) の MFA アクセスの問題の解決を参照してください。

全従業員ユーザーに対するMFAの要件は、Developer Edition、Trail、スクラッチ組織、またはその他の無償組織にも適用されますか？

いいえ。フィッシング耐性MFAの要件は、有償の本番組織とSandbox組織のみに適用されます。Developer Edtion、Trail、スクラッチ組織、その他の無償組織は、この要件の適用対象外です。

「除外ユーザーの多要素認証を放棄」というユーザー権限を持つユーザーを確認するためのSOQLクエリはありますか？

オプション1：PermissionSetAssignmentによるクエリ（権限セットを通じて権限を持つユーザーを検索）

SELECT AssigneeId, Assignee.Name, Assignee.Email, Assignee.Username,

Assignee.IsActive、PermissionSet.Name

FROM PermissionSetAssignment

WHERE PermissionSet.PermissionsBypassMFAForUILogins = true

オプション2：プロファイルによるクエリ（権限が有効になっているプロファイルを検索）

SELECT Id, Name, PermissionsBypassMFAForUILogins

FROM Profile

WHERE PermissionsBypassMFAForUILogins = true

注: API 項目名: PermissionsBypassMFAForUILoginsは、UI の「除外ユーザーの多要素認証を放棄」のユーザー権限に対応します。

変更履歴

※本ナレッジ記事は英語版ナレッジ記事の翻訳版となります。最新情報は英語版ナレッジ記事をご参照ください。

日付	内容
2026年7月10日	Sandbox [プレビュー] リリースグループに対するMFAの適用は、MFA適用後に一部のユーザーがログインできないと報告されたインシデントを受け、Sandbox [プレビュー]リリースグループの適用は2026年7月10日（7月6日～8日から変更）に変更されました。「パスキーの作成」プロンプトは、「Passkey-First MFA Registration and Improved Passkey Experience」で説明されているとおり、想定される動作です。これは製品の不具合ではありません。「変更内容」セクションに、MFAが適用される際にユーザーに表示されるパスキー作成プロンプトのUIスクリーンショットを追加しました。UIラベルは英語のみで表示されます。その他の言語への対応は、今後のパッチリリースで予定されています。
2026年7月8日	非プレビューSandboxインスタンスはプレビューSandboxとは別のリリースグループに属するため、適用スケジュールが異なることを明確化するための注記を追加しました。 R2bリリースグループから、日本と韓国の重複インスタンスを削除しました
2026年7月6日	リリースグループ適用スケジュールおよびリリースグループのインスタンスマッピングを公開しました
2026年7月2日	以下の適用計画の再開と新しいスケジュールを決定しました Sandbox組織：適用開始日は2026年7月6日（当初予定の6月22日から変更）となり、2日間にわたって段階的に実施本番組織：適用開始予定日は2026年7月20日（変更なし）で、15日間にわたって段階的に実施
2026年7月1日	本変更を保留といたしました。再開の計画については近日中に発表いたします。
2026年6月22日	動画再生プレイヤーを追加しました
2026年6月16日	動画を追加しました「影響を受けるユーザーは誰ですか？」セクションを更新しました。従業員コミュニティまたはExperience Cloud Siteにログインする社内ユーザー、およびChatter Plusユーザーは、多要素認証（MFA）の対象となります。「影響を受けないユーザーは誰ですか？」セクションを更新し、Experience Cloudユーザーライセンスを持つすべての外部ユーザー、Chatter Externalユーザー、およびChatter Freeユーザーがこの要件の対象外であることを明記しました。 SSOシグナルの　*user, pin*, および *vbm* は、これらの方法では特定のデバイスとログイン元への暗号化バインディングが提供されないため、フィッシング耐性MFAから標準MFAティアに再分類され、標準MFAが使用されたことを示しています。
2026年6月5日	更新情報と追加情報 SSO AMR/ACRシグナルを含めるように認証強度表を更新しました。 Salesforce が SSO IdP からの AMR および ACR シグナルをどのように評価して、標準 MFA またはフィッシング耐性 MFA の要件が満たされているかどうかを判断するかについての詳細を追加しました。ユーザーロックアウトシナリオにおける手順の明確化新しいよくある質問を追加しました全従業員ユーザーに対するMFAの要件は、Developer Edition、Trail、スクラッチ組織、またはその他の無償組織にも適用されますか？「除外ユーザーの多要素認証を放棄」というユーザー権限を持つユーザーを確認するためのSOQLクエリはありますか？
2026年5月5日	初版