Microsoft Entra の「Configure adaptive session lifetime policies」は、条件付きアクセスでサインイン頻度とブラウザーセッションの永続化を制御するための設定ガイドです。結論から言うと、今回確認すべきポイントは「トークン有効期間を個別に短くする」のではなく、Microsoft Entra Conditional Access のセッション制御で、ユーザー・アプリ・リスク・デバイス状態に応じて再認証タイミングを設計することです。(Microsoft Learn)
特に管理者は、Sign-in frequency を厳しくしすぎて MFA 疲れや業務影響を増やさないこと、Persistent browser session が「Stay signed in?」設定より優先されること、旧来の configurable token lifetime と併用しないことを確認する必要があります。公式ページ上で確認できる対象記事の更新日は 2026年4月2日ですが、本稿では 2026年7月2日時点で確認できる Microsoft Learn の内容を基に、グローバル環境での影響範囲と実務上の確認ポイントを整理します。(GitHub)
Microsoft Entra の「Configure adaptive session lifetime policies」とは
「Configure adaptive session lifetime policies」は、Microsoft Entra ID の条件付きアクセスを使って、ユーザーの認証セッションをどの程度維持するか、どのタイミングで再認証させるかを構成する手順です。主に次の2つを扱います。
| 設定項目 | 役割 | 実務での使いどころ |
|---|---|---|
| Sign-in frequency | ユーザーがリソースへアクセスし続けられる時間を制御し、必要に応じて再認証を求める | 管理者、機密アプリ、外部ネットワーク、リスクの高いユーザーに再認証を求めたい場合 |
| Persistent browser session | ブラウザーを閉じた後もサインイン状態を維持するかを制御する | 会社管理端末では利便性を高め、共有端末や個人端末では永続化を避けたい場合 |
Microsoft Entra ID の既定のユーザーサインイン頻度は、ローリングウィンドウで 90 日です。ただし、頻繁に認証を求めれば安全になるとは限りません。ユーザーが認証画面に慣れすぎると、不審な MFA 要求や偽の認証プロンプトを見落とすリスクが高まるためです。(Microsoft Learn)
そのため、Microsoft Entra のセッションライフタイム設計では、「全ユーザーに短い再認証間隔を強制する」のではなく、条件付きアクセスのシグナルを使って、必要な場面だけセッションを短くする考え方が重要です。
今回の更新ポイントとして押さえるべき内容
今回の公式情報で管理者が実務上確認すべきポイントは、単なる UI 手順ではなく、セッション制御の設計方針です。
サインイン頻度は「時間指定」または「毎回」を選べる
Sign-in frequency では、Periodic reauthentication による時間・日数指定、または Every time を選択できます。たとえば、機密性の高い管理ポータルや重要業務アプリでは短めにし、一般的な Microsoft 365 利用ではユーザー体験を損なわない範囲で設定するのが現実的です。(Microsoft Learn)
ただし、「Every time」は常に便利な選択肢ではありません。公式情報では、Every time を選んだ場合でも 5 分のクロックスキューが考慮され、直近 5 分以内に MFA を完了している場合は再度プロンプトされない動作が説明されています。また、過度な再認証はユーザーの生産性を下げ、意図しない MFA 承認を誘発する可能性があります。(Microsoft Learn)
Persistent browser session は「Stay signed in?」より優先される
Persistent browser session は、ブラウザーを閉じて再度開いた後もサインイン状態を維持するかを管理者側で制御する設定です。Microsoft Entra Conditional Access で Persistent browser session を構成している場合、同じユーザーに対して会社のブランド設定にある「Stay signed in?」よりも条件付きアクセス側の設定が優先されます。(Microsoft Learn)
これは、グローバル企業や複数拠点のテナントで特に重要です。ロケールごとのブランド設定に頼っていると、ユーザーの選択に依存した運用になりがちです。一方、条件付きアクセスで制御すれば、対象ユーザー、アプリ、場所、デバイス状態に応じて一貫したセッション管理ができます。
configurable token lifetime からの移行確認が必要
旧来の configurable token lifetime を使っている環境では、同じユーザーとアプリの組み合わせに対して、configurable token lifetime と Conditional Access のセッション制御を別々に作成する構成はサポートされません。Microsoft は refresh token と session token lifetime に関する configurable token lifetime を 2021年1月30日に廃止し、Conditional Access の authentication session management に置き換えています。(Microsoft Learn)
つまり、移行期限として新たな日付が示されているというより、すでに旧方式は廃止済みであり、残存設定の棚卸しが必要という位置づけです。既存テナントで過去に PowerShell や Microsoft Graph を使ってトークン有効期間を構成していた場合は、Conditional Access 側へ設計を寄せるべきです。
影響範囲：どのユーザー・アプリ・端末に関係するか
Adaptive session lifetime policies の影響は、Microsoft 365 全体に広がる可能性があります。公式情報では、Sign-in frequency は OAuth2 または OIDC に準拠したアプリで機能し、Microsoft 365 Admin portal、Exchange Online、SharePoint、OneDrive、Teams Web client、Azure portal などの Microsoft ネイティブアプリが対象例として挙げられています。(Microsoft Learn)
| 対象 | 影響の例 | 管理者が見るべきポイント |
|---|---|---|
| 一般ユーザー | 再認証プロンプトの増加、ブラウザー再起動後の再サインイン | 業務時間中に頻繁な MFA が発生していないか |
| 管理者・特権ユーザー | Azure portal、Microsoft Entra admin center、PIM 操作時の再認証 | 特権操作だけを短いセッションにできているか |
| モバイルユーザー | サインイン頻度の間隔到達後に認証が遅くなる場合がある | Intune、MAM、証明書認証との組み合わせ |
| 外部ユーザー・ゲスト | 拠点、国、信頼済み MFA、クロステナント設定の影響 | ゲストだけ過剰にブロックしていないか |
| 共有端末・非管理端末 | 永続ブラウザーセッションによる残存リスク | Persistent browser session を許可すべきでない端末を除外できているか |
特にモバイルデバイスでは、サインイン頻度の間隔後の認証に平均 30 秒程度かかる場合があり、複数アプリで同時に発生する可能性があります。また、iOS で証明書を第一要素として使うアプリに Sign-in frequency と Intune mobile application management policies が両方適用されると、ポリシー発火時にサインインがブロックされる既知の問題も示されています。(Microsoft Learn)
設定変更で確認すべき3つのポリシー
公式手順では、主に3つのポリシー構成が示されています。
Sign-in frequency control
Sign-in frequency control は、ユーザーが再認証を求められる頻度を制御する基本設定です。設定場所は、Microsoft Entra admin center の Entra ID > Conditional Access > Policies です。対象ユーザーやクラウドアプリを選び、Access controls > Session で Sign-in frequency を選択します。(Microsoft Learn)
実務では、いきなり全ユーザー・全アプリに短い時間を設定するのは避けるべきです。たとえば、以下のように段階を分けると影響を抑えられます。
| 利用シーン | 推奨される考え方 |
|---|---|
| Exchange Online、SharePoint Online など主要 Microsoft 365 アプリ | アプリ間で認証プロンプト頻度をそろえ、ユーザー体験を安定させる |
| 管理ポータル、財務、人事、機密データ | 一般アプリより短い再認証間隔を検討する |
| 低リスクな社内端末 | 過度に短くせず、SSO とデバイス準拠状態を活用する |
| 外部ネットワーク、非管理端末 | 短めのセッションや永続化禁止を検討する |
公式情報でも、Exchange Online や SharePoint Online など主要な Microsoft 365 アプリでは、最適なユーザー体験のために認証プロンプト頻度をそろえることが推奨されています。(Microsoft Learn)
Persistent browser session
Persistent browser session は、ブラウザーセッションを永続化するかどうかを制御します。この制御では「All Cloud Apps」、現在の表記では「All resources」に相当する範囲を選択する必要があります。理由は、ブラウザーセッションの永続化が認証セッショントークンによって制御され、同じブラウザーセッション内のタブが単一のセッショントークンを共有するためです。(Microsoft Learn)
運用上の判断基準は明確です。会社管理端末で、デバイス準拠や Microsoft Entra join が確認できる場合は、ユーザー体験を重視して永続化を許可しやすくなります。一方、共有 PC、キオスク端末、個人端末、外部委託先の端末では、サインイン状態が残ること自体がリスクになるため、永続化を抑制する設計が向いています。
Risky user 向けの Every time 再認証
公式手順では、User risk が High のユーザーに対して、MFA authentication strength とパスワード変更を要求し、Session で Sign-in frequency を Every time にする構成例が示されています。作成時は Report-only にし、確認後に On へ切り替える流れです。(Microsoft Learn)
このポリシーは、すべてのユーザーに常時厳しい再認証を強いるためのものではありません。ID Protection のリスク検出を使える Microsoft Entra ID P2 環境で、リスクが高いユーザーに限定して強い制御をかけるための設計です。条件付きアクセスで risk-based policy を使うには Microsoft Entra ID P2 が必要です。(Microsoft Learn)
管理者が設定前に確認すべきチェックリスト
設定変更前には、以下の確認を行うと失敗を防ぎやすくなります。
| 確認項目 | 確認する理由 | 対応例 |
|---|---|---|
| 旧 configurable token lifetime が残っていないか | Conditional Access のセッション制御と競合する可能性がある | Microsoft Graph PowerShell でポリシーを棚卸しし、CA へ移行 |
| Remember MFA on trusted devices が有効か | Sign-in frequency と組み合わせると予期しないプロンプトが増える可能性がある | Sign-in frequency 利用前に無効化を検討 |
| 緊急アクセスアカウントを除外しているか | 管理者ロックアウトを避けるため | break-glass アカウントを条件付きアクセスから除外 |
| 対象アプリを広げすぎていないか | 重要でないアプリまで再認証が増える | 機密性・リスク別に対象を分ける |
| モバイル・iOS の利用状況 | 既知の遅延やブロックに該当する可能性がある | パイロットユーザーで検証 |
| レポート専用モードで検証したか | 本番影響を出さずに適用結果を確認するため | Report-only でサインインログを確認 |
条件付きアクセスは柔軟ですが、その分、設計を誤ると管理者ロックアウトや過剰な MFA プロンプトにつながります。Microsoft の条件付きアクセス展開ガイドでも、本番展開前に緊急アクセスアカウントの除外、パイロットグループでのテスト、認証方法登録、ユーザーへの事前周知が重要とされています。(Microsoft Learn)
推奨される設定手順
実務では、以下の順番で進めると安全です。
| 手順 | 作業内容 | 成功条件 |
|---|---|---|
| 1 | 現在のサインインログを確認する | どのアプリ・端末・地域で認証が多いか把握できている |
| 2 | 既存の再認証関連設定を棚卸しする | configurable token lifetime、Remember MFA、Stay signed in? の状態が分かる |
| 3 | 対象ユーザーと対象アプリを絞る | 全社一括ではなく、リスクや業務重要度で分けられている |
| 4 | Report-only でポリシーを作成する | 実際のサインインに対する適用結果を確認できる |
| 5 | パイロットユーザーで検証する | 想定外の MFA 増加、モバイル遅延、アプリブロックがない |
| 6 | ユーザーへ変更内容を周知する | 「いつ」「何が変わるか」「困った時の連絡先」が伝わっている |
| 7 | 本番有効化後もログを監視する | 失敗サインイン、問い合わせ、ポリシー競合を追跡できる |
Report-only mode では、ポリシーを強制せずに評価結果をサインインログへ記録できます。新しい条件付きアクセスポリシーを本番適用する前に、Report-only タブや Conditional Access タブで結果を確認する運用が推奨されます。(Microsoft Learn)
サインインログで見るべきポイント
Microsoft Entra のサインインログは、内部アプリやリソースへのサインインを記録し、誰が、どのアプリで、どのリソースへアクセスしたかを確認できます。管理者は Entra ID > Monitoring & health > Sign-in logs から確認できます。(Microsoft Learn)
Adaptive session lifetime policies を導入した後は、特に以下を見ます。
| ログ観点 | 見るべき内容 |
|---|---|
| Authentication Details | Session Lifetime Policies Applied が想定どおりか |
| Conditional Access | 対象ポリシーが Success、Failure、Not applied のどれか |
| Report-only | 本番有効化前に、ユーザーアクションが必要になるか |
| Client app | ブラウザー、モバイル、デスクトップアプリで挙動差がないか |
| Device info | 管理端末・非管理端末で意図した差が出ているか |
| Location | 外部ネットワークや国・地域条件が想定どおりか |
「ポリシーを作ったのに再認証されない」という場合、アプリ側が Microsoft Entra ID に定期的にリダイレクトしていない、独自 Cookie を保持している、非対話サインインとして処理されている、といった要因が考えられます。Sign-in frequency は OAuth2、OIDC、または条件を満たす SAML アプリで機能しますが、アプリの実装によって体験が変わる点に注意が必要です。(Microsoft Learn)
よくある失敗と回避策
再認証を短くしすぎてユーザー体験が悪化する
セキュリティ強化のつもりで、すべてのユーザーに短い Sign-in frequency を設定すると、問い合わせ増加や MFA 疲れにつながります。特に「Every time」は、機密アプリ、VPN/NaaS、PIM、Azure Virtual Desktop、リスクユーザーなど、明確な理由がある場面に限定するのが安全です。(Microsoft Learn)
「Stay signed in?」と Persistent browser session の関係を誤解する
会社ブランド設定の「Stay signed in?」を調整しても、条件付きアクセスの Persistent browser session が同じユーザーに適用されていれば、条件付きアクセス側が優先されます。グローバルテナントでは、ロケール別表示よりも、条件付きアクセスの一貫した制御を基準に設計しましょう。(Microsoft Learn)
緊急アクセスアカウントを除外していない
条件付きアクセスの設定ミスで全管理者が締め出されると、復旧に大きな時間がかかります。Microsoft は、緊急アクセスまたは break-glass アカウントをポリシーから除外することを推奨しています。(Microsoft Learn)
モバイルと iOS の既知の問題を見落とす
モバイルでは再認証に時間がかかる場合があり、iOS で証明書認証と Intune MAM を組み合わせる構成ではブロックが発生する可能性があります。全社展開前に、実際の端末・実際のアプリでパイロット検証してください。(Microsoft Learn)
Microsoft Entra Private Access に Every time を適用しようとする
公式情報では、Microsoft Entra Private Access は Sign-in frequency の Every time をサポートしていません。Private Access を含む設計では、Every time ありきではなく、対象アプリやアクセス経路に応じた別の制御も検討する必要があります。(Microsoft Learn)
グローバル環境での設計ポイント
グローバル企業では、国・地域、端末管理状況、外部委託先、ゲストユーザー、現地の業務時間が混在します。そのため、1つのセッションポリシーを全世界へ一律適用するより、リスクと業務影響で分ける設計が現実的です。
| 設計軸 | 推奨方針 |
|---|---|
| 地域 | 高リスク地域や想定外の国からのアクセスは別ポリシーで制御 |
| 端末 | 管理端末は利便性、非管理端末は短めのセッションや永続化抑制 |
| 役割 | 管理者、財務、人事、開発者など高権限ユーザーは厳格化 |
| アプリ | Microsoft 365 全般と機密アプリを同じ頻度にしない |
| ゲスト | クロステナントアクセス設定や信頼済み MFA の扱いを確認 |
| サポート体制 | 各地域の業務時間に合わせて段階展開する |
条件付きアクセスは、ユーザー、デバイス、場所などのシグナルを組み合わせてアクセス制御を自動化する仕組みです。Microsoft の展開ガイドでも、ポリシーは柔軟である一方、望ましくない結果を避けるための計画が重要とされています。(Microsoft Learn)
管理者が次に取るべき行動
まず行うべきは、新しいポリシー作成ではなく、現状把握です。サインインログで認証プロンプトの発生状況を確認し、旧 configurable token lifetime、Remember MFA on trusted devices、Stay signed in?、既存の条件付きアクセスポリシーを棚卸ししてください。そのうえで、Sign-in frequency と Persistent browser session を、ユーザー種別・アプリ重要度・端末状態ごとに分けて設計します。
実装時は、必ず Report-only で開始し、パイロットユーザー、モバイル端末、主要 Microsoft 365 アプリ、管理ポータル、ゲストユーザーを含めて検証します。問題がなければ、ユーザーへ変更内容を周知したうえで段階的に On へ切り替えるのが安全です。
Microsoft Entra の adaptive session lifetime policies は、単に「ログインを長くする」「短くする」設定ではありません。認証疲れを避けながら、危険な場面だけ再認証を強めるためのセッション設計です。管理者は、セキュリティと生産性の両方を見ながら、条件付きアクセスのセッション制御へ運用を集約していきましょう。
コメント