Microsoft EntraのSAML SSO更新ポイント｜AMR/ACR値と管理者の確認事項

Microsoft Entra の「Single sign-on SAML protocol」の2026年6月25日更新でまず確認すべきなのは、SAML SSOの基本フローが置き換わったかではなく、認証方法を表す値の扱いです。特に、SAML応答内の AuthnContextClassRef、authnmethodreferences、必要に応じて追加する amr 要求を、アプリ側の認可・監査・MFA判定で使っている場合は影響を受ける可能性があります。公式情報の範囲では、明確な移行期限や廃止日は示されていません。ただし、otp をより細かい AMR 値に置き換えるロールアウトが案内されているため、固定文字列で認証方式を判定している実装は早めに検証すべきです。(Microsoft Learn)

2026年6月25日の更新で押さえるべきポイント

今回の Microsoft Entra SAML SSO 関連の更新は、「新しいSSO方式への強制移行」というより、Microsoft Entra ID が SAML 2.0 の認証要求と応答で扱う値をより明確にした更新と見るのが実務的です。Microsoft Learn の該当ページは2026年6月25日に更新され、GitHub上の更新履歴でも「SAML AMR and ACR values per authentication method」を文書化した変更として確認できます。(Microsoft Learn)

確認項目	更新・確認すべき内容	管理者の実務対応
SAML SSOの基本フロー	サービスプロバイダーが `AuthnRequest` を送り、Microsoft Entra ID が `Response` を返す流れは従来どおり	既存のSAML連携をすぐ作り直す必要はない
`AuthnContextClassRef`	認証方法ごとに返されるクラス名の対応が整理された	アプリが認証強度を判定している場合、想定値と実トークンを照合する
`authnmethodreferences`	パスワード、MFA、FIDO2、パスキー、Windows Hello for Business、証明書認証などの値が整理された	`multipleauthn` や認証方式別の値をアプリ側でどう扱うか確認する
`amr` 要求	Salesforce以外のSAMLアプリでは、AMR要求を受け取るためにオプション要求の追加が必要	必要なアプリだけ `amr` と `include_granular_amr` の追加を検討する
`otp` の扱い	SAMLとOIDC v2.0トークンで、より細かいAMR値への置き換えがロールアウト中	`otp` だけに依存した条件分岐を避ける
移行期限	該当ページ上では明確な移行期限・廃止日は示されていない	期限対応ではなく、影響アプリの棚卸しと段階検証を優先する

Microsoft Entra の SAML SSO は何をしているのか

Microsoft Entra の SAML SSO は、Microsoft Entra ID を ID プロバイダー、業務アプリやSaaSをサービスプロバイダーとして連携させる仕組みです。公式ドキュメントでは、クラウドサービス側が HTTP Redirect binding で AuthnRequest を Microsoft Entra ID に渡し、Microsoft Entra ID が HTTP POST binding で Response をクラウドサービスに返す流れとして説明されています。(Microsoft Learn)

SAML連携では、単に「ログインできるか」だけでなく、次の値が一致しているかが重要です。

用語	実務での意味	よく確認する場所
`AuthnRequest`	アプリから Microsoft Entra ID へ送る認証要求	アプリ側のSAML設定、SAMLトレース
`Response`	Microsoft Entra ID からアプリへ返す応答	SAMLレスポンス、アプリ側ログ
`Assertion`	認証結果やユーザー属性を含む本文	SAMLレスポンス内
`Issuer`	要求元または発行元を示す識別子	アプリID URI、エンティティID
`Audience`	このトークンを受け取るべき相手	アプリ側のAudience検証設定
ACS URL	SAML応答を受け取るURL	Reply URL、Assertion Consumer Service URL
`NameID`	認証ユーザーを表す識別子	SAML属性、アプリのユーザー紐付け設定

実務では、SSO障害の原因は「Microsoft Entraが止まっている」よりも、Issuer、ACS URL、証明書、属性名、アプリ側の固定値判定の不一致であることが多くあります。今回の更新も、特にアプリ側で認証方法の値を細かく見ている場合に注意が必要です。

AuthnRequestで確認すべき設定

AuthnRequest は、アプリが Microsoft Entra ID に「このユーザーを認証してほしい」と依頼するメッセージです。Microsoft Entra ID が期待する代表的な値として、ID、Version、IssueInstant、AssertionConsumerServiceURL、ForceAuthn、IsPassive などがあります。ID は応答の InResponseTo に使われ、Version は 2.0、IssueInstant はUTCの日時文字列として扱われます。(Microsoft Learn)

特に重要なのは、AssertionConsumerServiceURL と Issuer です。AssertionConsumerServiceURL を指定する場合は、Microsoft Entra ID 側に登録されているクラウドサービスの RedirectUri と一致する必要があります。また、Issuer は Microsoft Entra ID 内でクラウドサービスを表す ServicePrincipalNames のいずれかと正確に一致する必要があり、一般的にはアプリ登録時に指定したアプリ ID URI が使われます。(Microsoft Learn)

AuthnRequestの実務チェック表

項目	確認内容	失敗しやすいポイント
`ID`	数字で始まらない一意のIDになっているか	ライブラリ更新後にID形式が変わり、応答照合に失敗する
`Version`	`2.0` になっているか	古いSAML実装や独自実装で不正な値になる
`IssueInstant`	UTC形式で出力されているか	サーバー時刻のずれで調査が難しくなる
`AssertionConsumerServiceURL`	Entra側の Reply URL / Redirect URI と一致しているか	本番・検証環境のURLを取り違える
`Issuer`	アプリID URIやエンティティIDと正確に一致しているか	末尾スラッシュ、大文字小文字、`spn:` の扱いで不一致になる
`ForceAuthn`	再認証を強制したい場面だけ使っているか	常時有効にしてユーザー体験を悪化させる
`IsPassive`	サイレント認証の要件に合っているか	対話が必要な条件付きアクセスと相性が悪い場合がある

RequestedAuthnContext を含める場合、Comparison は exact に設定する必要があります。また、Subject 要素を AuthnRequest に含めることはサポートされておらず、ユーザーを指定したい場合は login_hint パラメーターを使うのが公式の説明です。(Microsoft Learn)

ResponseとAssertionで確認すべき設定

SAMLの Response は、Microsoft Entra ID がアプリに返す認証結果です。成功時には、Destination がサービスプロバイダーの RedirectUri に設定され、InResponseTo は元の AuthnRequest の ID に対応します。Issuer は https://sts.windows.net/<TenantIDGUID>/ の形式で、Microsoft Entra テナントを示します。(Microsoft Learn)

Assertion には、認証されたユーザー、署名、有効期間、Audience、属性、認証方法などが含まれます。Microsoft Entra ID は成功したサインオンに対してアサーションに署名し、署名にはメタデータドキュメントの IDPSSODescriptor 要素に含まれる署名キーが使われます。(Microsoft Learn)

管理者が見落としやすいのは、有効期間と時刻同期です。公式ドキュメントでは、NotBefore は Assertion の IssueInstant と同じか1秒未満だけ後になり、Microsoft Entra ID はサービスプロバイダーとの時刻差に対するバッファーを追加しないと説明されています。また、NotOnOrAfter は NotBefore の70分後です。アプリサーバーの時刻がずれていると、正しいSAML応答でも期限切れや未有効として扱われる可能性があります。(Microsoft Learn)

Response側の確認ポイント

項目	確認内容	実務上の判断基準
`Destination`	アプリの受信URLと一致しているか	リバースプロキシやロードバランサー配下では外部URLで検証する
`InResponseTo`	送信した `AuthnRequest` の `ID` と対応しているか	IdP開始SSOとSP開始SSOで挙動差がないか確認する
`Issuer`	Microsoft Entra テナントの発行者として信頼しているか	テナントIDの取り違えに注意する
署名	Microsoft Entra のメタデータに基づき検証しているか	証明書ローテーション時に手動更新が必要なアプリは要注意
`Audience`	アプリ側のエンティティID・アプリID URIと一致しているか	末尾スラッシュや環境別URIの差分を確認する
有効期間	アプリサーバーの時刻が正しいか	NTP同期を前提にする
属性	`NameID`、UPN、Object IDなどの用途が適切か	認可には変更されにくい識別子を優先する

今回重要なACRとAMRの違い

今回の更新ポイントを理解するには、ACRとAMRを分けて考える必要があります。

ACRに相当するのが、SAMLの AuthnContextClassRef です。これは「どの認証コンテキストで認証されたか」を表します。たとえば、パスワード認証なら Password、FIDO2セキュリティキーやデバイスバインドのパスキー、Windows Hello for Business、MFAとして使われる証明書ベース認証では SmartcardPKI が返るケースがあります。Microsoft Entra ID は、複数の認証方法が使われた場合、最も強い方法を AuthnContextClassRef に反映すると説明しています。(Microsoft Learn)

AMRに相当するのが、authnmethodreferences や amr 要求で扱われる「実際に使われた認証方法」の値です。公式ドキュメントでは、パスワード、Authenticator、OATH、SMS、電話、FIDO2、パスキー、Windows Hello for Business、証明書ベース認証、一時アクセスパスなどに対する値が整理されています。(Microsoft Learn)

認証方法	`AuthnContextClassRef` の見方	`authnmethodreferences` / `amr` の見方	管理者の注意点
パスワード	`Password`	`password`	パスワードのみを高保証認証として扱わない
Microsoft Authenticator TOTP	`TimeSyncToken`	従来は `otp` 系、粒度化後は `totp`	`otp` 固定判定を見直す
ハードウェア OATH	`TimeSyncToken`	従来は `otp` 系、粒度化後は `hotp`	TOTPとハードウェアOATHを区別したい場合に要検証
SMS	`MobileOneFactorUnregistered` または `MobileTwoFactorContract`	従来は `otp` 系、粒度化後は `sms`	SMSを許可・除外するアプリ側ロジックに注意
電話	`Telephony` または `MobileTwoFactorContract`	従来は `otp` 系、粒度化後は `tel`	電話認証を個別に扱う場合に影響
FIDO2セキュリティキー	`SmartcardPKI`	`fido` と `multipleauthn`	フィッシング耐性MFAの判定候補になる
デバイスバインドパスキー	`SmartcardPKI`	`fido` と `multipleauthn`	FIDO2と同じ値で扱う設計が必要
同期パスキー	`SoftwarePKI`	`fido` と `multipleauthn`	デバイスバインドとの差をどう扱うか決める
Windows Hello for Business	`SmartcardPKI`	`hwk` と `multipleauthn`	ハードウェアバインドキーとして評価する
証明書ベース認証	MFA時は `SmartcardPKI`、単一要素CBAでは `X509`	`x509` と `multipleauthn` など	単一要素CBAとMFAとしてのCBAを混同しない
一時アクセスパス	`Unspecified`	従来は `otp` 系、粒度化後は `tap`	緊急アクセス運用と監査で区別したい

Microsoft Entra ID は、SAMLとOIDC v2.0トークンの両方で、otp をより細かいAMR値に置き換えるロールアウトを進めていると説明しています。具体的には、Authenticator TOTPは totp、ハードウェアOATHは hotp、SMSは sms、電話は tel、メールOTPは emailotp、一時アクセスパスは tap として扱われる方向です。(Microsoft Learn)

影響を受けやすいアプリと受けにくいアプリ

今回の更新は、すべてのSAMLアプリで即座に障害が起きる類の変更ではありません。影響が出やすいのは、SAMLレスポンスの中身をアプリ側で細かく解釈している環境です。

アプリの状態	影響度	確認すべきこと
SAML署名、Issuer、Audience、NameIDだけを検証している	低	通常のSSOテストで十分な場合が多い
MFA完了有無を `multipleauthn` で判定している	中	MFA未完了・完了時のレスポンス差分を確認する
`otp` を固定文字列として判定している	高	`totp`、`hotp`、`sms`、`tel`、`emailotp`、`tap` を想定した実装にする
FIDO2、パスキー、Windows Hello for Businessを高保証認証として扱う	高	`fido`、`hwk`、`SmartcardPKI`、`SoftwarePKI` の扱いを確認する
Salesforce SAMLアプリ	低〜中	`amr` は既定で送信されるため、基本的には追加設定不要。ただしアプリ側の判定ロジックは確認する
独自開発のSAML SP	高	SAMLレスポンスのパース、属性名、値の許容リストを検証する
AD FS など旧IdPから Microsoft Entra ID へ移行中のアプリ	高	旧IdPのAMR/ACR表現と Microsoft Entra ID の値の差分を洗い出す

特にグローバル企業では、同じSaaSでも地域や事業部ごとにSAML設定が分かれていることがあります。日本の本社環境では問題がなくても、海外テナントや買収企業のテナントでは、古いSAMLライブラリ、独自の属性マッピング、別の証明書更新運用が残っているケースがあります。今回のようなトークン値の整理は、全社共通のSSO棚卸しを進めるよいタイミングです。

`amr` 要求を使う場合の設定変更

公式ドキュメントでは、Salesforceアプリケーションでは amr 要求が既定で送信されるため構成変更は不要とされています。一方、その他のSAMLアプリケーションでAMR要求を受け取りたい場合、アプリケーション管理者はアプリ登録に、include_granular_amr 追加プロパティ付きのオプション amr 要求を追加する必要があります。(Microsoft Learn)

Microsoft Entra のオプション要求は、管理センターのアプリケーションUIまたはマニフェストから構成できます。マニフェストでは optionalClaims オブジェクトを使い、IDトークン、アクセストークン、SAML 2トークンごとに異なる要求を指定できます。また、対応する要求では additionalProperties により要求の動作を変更できます。(Microsoft Learn)

SAMLトークンにAMRを出したい場合の考え方は、次のようになります。実際に適用する前に、対象アプリの検証環境でSAMLレスポンスを取得し、アプリ側が期待どおりに処理できるか確認してください。

{
  "optionalClaims": {
    "saml2Token": [
      {
        "name": "amr",
        "essential": false,
        "additionalProperties": [
          "include_granular_amr"
        ]
      }
    ]
  }
}

設定変更前に確認すること

確認項目	理由
アプリが本当に `amr` を参照しているか	参照していないアプリに不要な要求を追加しても、管理対象が増えるだけになる
`authnmethodreferences` と `amr` のどちらを使う設計か	同じ「認証方法」でも属性名や値の扱いが異なる場合がある
アプリ側が未知の値を許容できるか	ロールアウト中の新しい値でログイン失敗になるリスクを避ける
Salesforceかどうか	Salesforceでは `amr` が既定で送信されるため、他アプリと同じ前提で設定しない
本番前に複数の認証方法でテストしたか	パスワードだけのテストでは、FIDO2やTAPの値を確認できない

管理者が実施すべき確認手順

SAML SSOの更新対応では、いきなり設定を変更するより、先に「どのアプリが認証方式の値を使っているか」を把握することが重要です。

手順	作業内容	成果物
1	Microsoft Entra ID のエンタープライズアプリから、SAML SSO利用アプリを一覧化する	SAMLアプリ台帳
2	各アプリで `AuthnContextClassRef`、`authnmethodreferences`、`amr` を参照しているか確認する	影響有無の分類
3	代表ユーザーでSAMLレスポンスを取得する	現在のレスポンスサンプル
4	パスワード、MFA、FIDO2、パスキー、Windows Hello for Business、証明書認証など、利用中の方法でテストする	認証方法別の値一覧
5	アプリ側の認可条件、監査ログ、MFA判定ロジックを確認する	修正対象コード・設定一覧
6	必要なアプリだけ `amr` オプション要求を追加する	変更済みマニフェストまたは設定記録
7	本番反映後、失敗ログとサインインログを監視する	障害検知・切り戻し判断

特に、アプリ側で「otp があればMFA済み」「Password でなければ強い認証」などの単純な判定をしている場合は注意が必要です。Microsoft Entra ID がより細かい値を返すようになると、想定外の文字列として扱われ、ログイン拒否、権限不足、監査ログの欠落につながる可能性があります。

移行期限はあるのか

今回の公式情報の範囲では、SAML SSOの利用停止日や強制移行期限は示されていません。したがって、管理者が取るべき行動は「期限までに一斉移行する」ではなく、「認証方法の値に依存するアプリを洗い出し、ロールアウト中のAMR値に耐えられる実装へ直す」ことです。(Microsoft Learn)

社内で期限を設定するなら、次のように優先度を分けると現実的です。

優先度	対象	推奨対応
高	金融、個人情報、管理者向け、特権操作を扱うアプリ	すぐにSAMLレスポンスを取得し、認証方式判定を検証する
高	FIDO2、パスキー、Windows Hello for Businessを利用しているアプリ	`fido`、`hwk`、`SmartcardPKI` などの扱いを確認する
中	MFA完了をアプリ側で判定しているアプリ	`multipleauthn` と新しいAMR値の扱いを確認する
中	外部SaaSでSAML属性をカスタマイズしているアプリ	ベンダードキュメントと実レスポンスを照合する
低	標準的なSAMLログインだけを行い、認証方式をアプリ側で見ていないアプリ	通常のSSO疎通確認と証明書期限管理を継続する

よくある失敗と回避策

SAML SSOのトラブルは、設定値の小さな差で発生します。今回の更新確認とあわせて、既存設定の品質も見直しておくと、将来の証明書更新や認証方法追加にも強くなります。

失敗例	原因	回避策
SSO後にアプリへ戻れない	ACS URL / Reply URL が一致していない	検証環境・本番環境のURLを分けて台帳化する
`Audience` エラーになる	アプリID URIやエンティティIDが不一致	末尾スラッシュ、大文字小文字、`spn:` 付き値を確認する
MFA済みなのにアプリで拒否される	アプリ側が古いAMR値だけを許可している	値を単一文字列ではなく許容リストで扱う
パスキー導入後に認可条件が合わない	FIDO2や同期パスキーの値を想定していない	`fido`、`SmartcardPKI`、`SoftwarePKI` の扱いを設計する
TAP利用時の監査が曖昧になる	`otp` 扱いのままでは一時アクセスパスを区別しにくい	`tap` への粒度化を前提にログ設計を見直す
署名検証に失敗する	証明書更新やメタデータ更新が反映されていない	メタデータURL利用か、手動更新手順を明文化する
時刻エラーになる	アプリサーバーの時刻ずれ	NTP同期とSAML有効期間の監視を行う
`Subject` 指定でエラーになる	Microsoft Entra ID が `AuthnRequest` 内の `Subject` をサポートしない	`login_hint` パラメーターを使う

アプリ側の実装で見直すべき判断基準

SAMLレスポンスをアプリ側で処理している場合、認証方式の値を「完全一致の固定文字列」だけで判定するのは避けた方が安全です。Microsoft Entra ID が値をより細かくするロールアウトを進めている以上、今後も認証方法の追加や表現の変更が起こり得ます。

実装上は、次の考え方が実務向きです。

設計方針	具体例
認証方式をカテゴリで扱う	`fido`、`hwk`、`x509` を高保証認証カテゴリとして扱う
未知の値をログに残す	すぐ拒否するだけでなく、検知できるようにする
認可条件をEntra側にも寄せる	条件付きアクセスや認証強度を使い、アプリ側判定を最小化する
値の追加に備える	許容リストを設定ファイル化し、コード修正なしで更新できるようにする
本番と同じ認証方法でテストする	パスワードだけでなく、FIDO2、TAP、証明書認証などを実際に試す

アプリ側で強い認証を要求する場合、SAMLレスポンスだけで完結させるのではなく、Microsoft Entra の条件付きアクセスや認証強度の設計と合わせて考えることが重要です。SAML属性はアプリが受け取る結果であり、ポリシー制御そのものではありません。高リスク操作や管理者操作では、Entra側で要求する認証条件と、アプリ側で確認するトークン値の両方を整合させる必要があります。

グローバル環境での確認ポイント

グローバル向けに Microsoft Entra SAML SSO を運用している場合、影響範囲は1つのテナント内に閉じないことがあります。海外拠点、買収企業、地域別SaaS、外部パートナー向けアプリで、それぞれ異なるSAML設定が使われているケースがあるためです。

特に確認したいのは、次の4点です。

観点	確認内容
テナント差分	本社テナントと海外テナントでアプリ登録や要求設定が違わないか
SaaS差分	同じSaaSでも国・地域別インスタンスでACS URLや属性要件が違わないか
認証方法差分	地域によってSMS、電話、FIDO2、証明書認証の利用状況が違わないか
監査要件差分	国や業界ごとの監査で、MFA方式の記録が必要か

AMR値の粒度化は、単なる技術仕様の変更ではなく、監査やセキュリティレポートにも影響します。たとえば、これまで「OTP」としてまとめていたログを、TOTP、SMS、電話、メールOTP、一時アクセスパスに分けて見たい場合、アプリ側やSIEM側のパースルールも更新が必要です。

まず実施すべきアクション

Microsoft Entra の SAML SSO を運用している管理者は、次の順で確認すると効率的です。

期限の目安	実施内容
すぐ	SAML SSO利用アプリを一覧化し、重要度を分類する
1〜2週間以内	重要アプリのSAMLレスポンスを取得し、`AuthnContextClassRef` と `authnmethodreferences` を確認する
1か月以内	`otp`、`multipleauthn`、`fido`、`hwk`、`x509` などを使う判定ロジックを棚卸しする
検証後	必要なアプリに `amr` と `include_granular_amr` のオプション要求を追加する
継続	新しい認証方法の追加時に、SAMLレスポンスとアプリ側判定を必ず確認する

今回の更新で最も避けたいのは、「SSOログインは成功しているが、アプリ側の認可や監査が誤っている」状態です。Microsoft Entra ID から返されるSAMLレスポンスの値を確認し、アプリがその値をどう使っているかを明確にすることが、今回の更新への最も実用的な対応です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

Microsoft EntraのSAML SSO更新ポイント｜AMR/ACR値と管理者の確認事項

2026年6月25日の更新で押さえるべきポイント

Microsoft Entra の SAML SSO は何をしているのか