こんにちは、NTTデータ九州ビジネス共創部デジタルビジネス推進室の村尾です。

Salesforceの Summer'26 アップデートの足音が聞こえてきました。今回のリリース内容を見て、全国のシステム管理者・Salesforceエンジニアの皆様はすでに関心が高まっているのではないでしょうか。

今回のアップデートは一言で言うと「データ流出対策と認証セキュリティの非常に厳格な強化」です。
これまでは規約上実施するように、というレベルにとどまっていたセキュリティ関連の設定(主にMFA周り)が強制化されます。

この記事では、特にインパクトの大きい以下の3トピックについて、実際の挙動と対処方法をまとめていきます。

レポート＆ダッシュボードの「ステップアップ認証」
「複数設定 SAML フレームワークへの完全強制移行」
特権ユーザーへの「フィッシング耐性MFA」の強制化

認証周りの設計変更が必要なレベルのアップデートとなります。
ぜひ最後までお付き合いください。

執筆日：2026年6月9日

本記事はSalesforceのSandbox環境での検証結果に基づいています。
実際のリリース仕様とは異なる場合があります。

1. レポートのステップアップ認証

本変更は、データの不正エクスポート等による流出を防ぐため、ログイン状態であっても一定時間が経過するとレポートやダッシュボードの操作時に再度のMFAを求める「ステップアップ認証」というものになります。

「エクスポート」のような操作だけでなく、「ただレポートを閲覧するだけ」でもトリガーされるため、非常に厳格な変更になっています。

🛠️ SandBoxでの検証手順

※6月9日時点での検証となりますので、ブログ公開時の実装状況とは異なる可能性があります。

まずはSandBoxにてステップアップ認証の設定を有効化します。
本番でのデフォルトの認証インターバルは120分(2時間)となっていますが、今回は検証の為最短のインターバルの2分に設定を変更して実施します。

[設定] ＞ [アイデンティティ検証] を開く。
セッションセキュリティレベルポリシーのセクションにある「レポートおよびダッシュボード」を確認。
「定期的なステップアップ認証を要求（Require periodic step-up authentication）」 にチェックを入れる。
「ステップアップ認証期間（分）」を、検証用に最短の 2分に設定して保存。

👀 実際の挙動：2分経ってからレポートを開くと…？

設定完了後、一度ダッシュボードやレポートの画面から離れ、2分間放置します。

2分経過後、レポートを開こうとすると……

ログイン状態であるにもかかわらず、レポートのデータが表示される直前でしっかりと認証を求められました。
Salesforce Authenticator等での承認、あるいは確認コードをクリアして初めて、レポートの中身が表示されます。

※今回はMFA未適用の為、確認コードでの認証を求める画面が表示されています。

💡 認証が走るパターンと走らないパターン

今回の変更にて、レポートを操作する際に認証が走るようになりましたが、実際に認証が走る/走らない場合について整理します。

認証が走る操作

レポート・ダッシュボードの閲覧
└レポートタブからレポートを開く、あるいはダッシュボード上のコンポーネントのソースレポートをクリックして詳細画面に遷移した瞬間。
※ダッシュボード画面でのグラフ等はそのまま閲覧可能。
レポートの実行
└画面上で「検索条件」を変更してレポートを再実行（更新）する操作。
レポートのエクスポート

認証が走らない操作

レポートのスケジュール・登録
└ユーザーがレポートを「毎日朝9時にメールで受け取る」よう登録している場合。これらはアクティブなユーザーセッションが存在しないバックグラウンドコンテキストで実行されるため、認証はスキップされ、通常通りメールが配信されます。
※届いたメール内の「Salesforceで表示」リンクをユーザーがクリックしてブラウザを開いた場合は、その時点で「アクティブセッション」に切り替わるため、ステップアップ認証の対象になります。
コンポーネントとしてLightningページに設置したレポート、ダッシュボードの閲覧
└検証時点ではホームや各種レコード詳細画面にコンポーネントとして設置したレポートやダッシュボードについては、問題なく閲覧・更新が可能でした。
※ただし、「レポートを表示」等をクリックし、レポート詳細画面に遷移しようとした場合は認証が走ります。

2.「複数設定SAMLフレームワーク」への完全移行

外部の認証基盤とSSO連携している組織にとって、今回のSummer'26で最も影響が大きいのがこの変更です。
これまで単一のIdPしか紐づけられなかった古いSAMLフレームワーク（単一設定）が完全に廃止され、複数のIdPとの連携をサポートする新しいフレームワークへの移行が「強制（必須）」となります。

もし古い設定のまま放置した場合、Summer'26の適用と同時にSSOログインが完全に機能しなくなるため、今回のアップデートの中で最も業務影響が大きいポイントです。

💡この変更の背景

従来のSalesforceは「1組織につき外部IdPは1つ」という前提（シングル設定）で設計されていました。しかし現在のビジネス環境では、以下のようなマルチIdP運用が標準化しています。

社内従業員のログインは Okta
グループ会社のメンバーは Microsoft Entra ID
外部顧客（Experience Cloud）は Google Workspace

これら複数の認証基盤を1つのSalesforce組織に共存させ、柔軟にルーティングするためには、裏側のSAMLフレームワークの刷新が不可欠です。プラットフォームの構造を近代化し、セキュリティを底上げするために、古いシングル設定機能が廃止されることになりました。

🛠️必要な対策とシステム管理者の作業

認証ルールが厳格化されるため、IdP側（OktaやEntra ID）の設定変更もセットで必要になります。具体的には以下の3つの作業を行います。

タスク1：IdP側で「Audience属性」を必須化する

新しいフレームワークでは、IdPから送られてくるSAMLレスポンス内に、Audience 属性が正確に含まれていないとSalesforce側で完全にブロック（ログイン失敗）されます。

対応： IdP側の設定画面（SP Entity IDなどの項目）を確認し、Salesforceの「エンティティID（https://saml.salesforce.com または マイドメインのURL）」が正しく指定されているか確認・修正してください。

タスク2：外部IdPに登録している「ログインURL」を書き換える

フレームワークを新しくすると、Salesforce側でIdPからの認証情報を受け取るURL（SAMLログインURL/エンドポイント）が変更され、IdPごとの固有の識別子が含まれた新しいURLが生成されます。

対応： 移行後にSalesforce側で新しく発行されたログインURLをコピーし、IdP側に登録されている 「ACS（Assertion Consumer Service）URL」 や 「宛先URL」 に上書きしてください。

タスク3：【同時に廃止】暗号化「Triple DES」の排除

SAML SSOに関連して、Summer '26では古い暗号化アルゴリズムである「Triple DES（3DES）」が完全に動作しなくなります。

対応： SSO設定の暗号化方式を確認し、より強固な 「AES 128」または「AES 256」 に変更されていることを確認してください。

3. システム管理者・特定権限ユーザーへの「フィッシング耐性MFA」義務化

Summer'26ではMFAの網の目がさらに細かくなります。
これまで「MFA免除ユーザー」権限で回避できていた運用がUI（画面）からのログインに対して無効化されるほか、システム管理者等の特権ユーザーには「フィッシング耐性のあるMFA」が要求されます。

「フィッシング耐性」と言われると難しそうですが、要するにPCの Windows Hello や Macの Touch ID、または物理キー（YubiKeyなど）を使う認証（FIDO2 / WebAuthn）のことです。

🛠️ SandBox環境での設定手順

今回は、身近なデバイス（MacのTouch ID、またはWindows Hello）をSalesforceの組み込み認証システムとして登録してみます。

[設定] ＞ [ID検証] を開く。
「ユーザーが Touch ID や Windows Hello などの組み込み認証システムを使用してIDを検証できるようにする」にチェックを入れて保存。
[設定] ＞ [ユーザー]＞ [登録したいユーザー名] を開く。
「セキュリティキー」の項目を探し、 [登録] をクリック。
ブラウザのポップアップに従い、PCの指紋認証や顔認証を紐づけます。

👀 実際の挙動：ログイン時の体験

登録後、一度ログアウトして再ログインを試みます。

IDとパスワードを入力すると、お馴染みのSalesforce画面ではなく、ブラウザ（ChromeやEdgeなど）のOSネイティブなポップアップが立ち上がり、PC本体の指紋センサーに触れるよう求められます。

これで指紋認証でのログインができました。その他認証手段についても同様の流れとなります。

✍️ Tips

なぜこれが推奨（要件化）されるのか： 従来の「認証アプリに表示された数字を入力する」方式だと、精巧に作られたフィッシングサイト（偽のSalesforceログイン画面）に騙されてユーザーが数字を入力してしまった場合、ハッカーに突破されてしまいます。しかし、この組み込み認証はブラウザとデバイスが「現在接続しているドメイン（URL）」を直接検証するため、偽サイトでは絶対に認証が成功しません。これが「フィッシング耐性」と呼ばれる理由です。
IdP側での対応検討： SSO環境の場合、Salesforceは今後、ログインの成否だけでなく「どのような認証方式で認証されたか（フィッシング耐性があるか）」を識別する機能を強化していくロードマップを持っています。そのため、管理者はSalesforce側だけでなく、外部IdP側（Okta等）でも「管理者アカウントにはFIDO2/WebAuthn（物理キーや生体認証）を必須にする」というポリシー設計を進める必要があります。

📅 システム管理者が今すぐ動くべき「チェックリスト」

今回のSummer'26は、過去のマイナーアップデートとは一線を画す、認証基盤の総点検が必要です。本番適用（6月〜7月）に向けて対策を行っていきましょう。

1. SSOフレームワークの確認
- SalesforceのSSO設定が「複数設定SAMLフレームワーク」になっているか。
- IdpのSSO設定が「複数設定SAMLフレームワーク」に対応しているか。
2. SSO暗号化アルゴリズムの確認
- 暗号化方式が「Triple DES（3DES）」になっていないか。
- 「AES」への変更をIdP担当者と調整する。
3. 管理者アカウントのフィッシング耐性化
- システム管理者全員のPC環境（Windows Hello / Touch ID）を確認し、組み込み認証システムの登録を検証・推進する。
4. 一般ユーザーへの「ステップアップ認証」のアナウンス
- 「MFAでログインしていても、2時間経つとレポート閲覧時に再認証が入る」という仕様変更の告知を行う。

💡 まとめ：スピーディな検証を

今回はSummer '26の変更内容の検証を行いました。

自社やお客様の環境によっては、新たに環境を用意しなければならなかったりとインパクトの大きいアップデートでありながら、それぞれの適用までのリードタイムが比較的短めであるため、スピーディな対応が求められると思います。

しかし、仕様を正しく理解し、SandBoxで事前に検証を実践しておけば、決して恐れるものではありません。
むしろこの機会に組織のセキュリティレベルを高い水準に引き上げておきましょう。

まだ実装時期等の情報が錯綜している現状ですが、出来ることから準備を進めていきましょう。

※本記事は6月9日時点で公開されている情報に基づき作成されており、記載されているサービスの仕様や情報は変更される可能性があります。実際の利用にあたっては、最新の公式ドキュメントをご確認ください。