条件付きアクセスのレポート専用モードで影響を確かめてから有効にする｜結果の読み方と、止まる人の一覧の作り方（Entra ID）

たとえば、全員に多要素認証を求めるポリシーをテンプレートから作り、［ポリシーの有効化］が［レポート専用］のまま1週間たったとします。そろそろオンにしたいけれど、オンにした日に誰が止まり、誰が多要素認証を求められるのかを、どこで見ればいいのか分からない。［分析情報とレポート］のブックは、Azure の Log Analytics（ログをためて検索するサービス）が要るとされていて、Azure の契約が無い会社では使えそうにない。

この記事を読むと、レポート専用の結果をどの値で読み、Azure の契約が無くても、オンにすると影響が出る人の一覧をどう作るかが分かります。結果に出てこない人の確かめ方と、オンのポリシーを直すときの試し方も書きます。当社は Microsoft 365 の導入を支援している会社で、ライセンスの販売はしていません。

結果は4つ。オンにしたら何が起きるかで読む

条件付きアクセス（決めた条件を満たすときだけ、Microsoft 365 などへのサインインを通す Entra ID の機能）のポリシーには、オン・オフのほかに［レポート専用］の状態があります。レポート専用のポリシーはサインインのたびに評価されますが、適用はされません。社員が多要素認証を求められることも、ブロックされることもありません。Microsoft の公式の技術文書のサイトである Microsoft Learn（以下、Learn）では「レポートのみ」とも書かれていますが、同じ状態です。

ポリシーの欄の作り方、緊急用アカウントの外し方、レポート専用で置く期間（少なくとも1週間）は条件付きアクセスの設定方法の記事に、写真の下の警告にあるセキュリティの既定値群から切り替える順番は多要素認証を全員に有効にする記事に書いています。この記事は、置いた後の結果の読み方から始めます。

レポート専用のポリシーの結果は、1回のサインインごとに次の4つのどれかになります。値の名前と説明は Learn の表記です（Microsoft Learn「条件付きアクセス ポリシーの影響の分析」）。

表の「準拠した端末」は、端末を管理する Intune で会社の基準を満たすと判定された端末のことです。例の「全員に多要素認証を求める」ポリシーなら、結果は主に「レポートのみ: ユーザー アクションが必要」か「レポートのみ: 成功」になります。前者は多要素認証の記録がまだ無いサインイン、後者はすでにあるサインインです。「レポートのみ: ユーザー アクションが必要」の人は、オンにすると多要素認証を求められます。その人が多要素認証の方法を登録しているかを、オンにする前に確かめておきます。機種変更などで登録し直す人の扱いは多要素認証のリセットと再登録の記事に書いています。

「レポートのみ: 失敗」に出たサインインは、オンにすると止まります。レガシ認証（古い方式のサインイン）のブロックのように、止めることが目的のポリシーなら、ここに出るのは止めたい相手です。それでも、古いメールソフトや複合機のように、止めると業務が止まるものが混ざっていないかを確かめます。「レポートのみ: 未適用」は、除外した人や、場所の条件に当たらないサインインです。当たるはずの人がここに出ていたら、ポリシーの対象の欄を見直します。

1回のサインインには、ふつう複数のポリシーが評価されます。あるポリシーが通しても、別のポリシーで止まることがあります。そのため、1つのポリシーの結果だけでは、その人がオンにした後に入れるかは決まりません。

この記事に関連するサービス

M365・Google Workspace の移行と設定の相談移行と設定を、1件から相談できます。詳しく見る →Microsoft 365 導入支援Exchange・SharePoint・Teamsの移行から権限設計・Copilot活用まで詳しく見る →Google Workspace 導入・移行支援Gmail移行から権限設計・Gemini活用まで詳しく見る →AIセキュリティ診断・規約・ルール整備AIを使う前に、出す前に。安全の確認と、規約・ルールの整備を詳しく見る →Notion 導入支援議事録・ナレッジ・タスクを一箇所にまとめる詳しく見る →

見る場所は3つ。Azure が無ければ、サインイン ログを JSON で落として一覧にする

Learn は、レポート専用の結果を見る場所として、［ポリシーへの影響］、サインイン ログ、［分析情報とレポート］のブックの3つを挙げています。要るものと、見える範囲が違います。

ポリシーへの影響（プレビュー）：傾向をつかむ

［ポリシーへの影響］は、ポリシーが組織の対話型のサインイン（パスワードの入力など、本人が操作したサインイン）にどう効くか、または効きそうかの要約を、過去24時間・7日間・1か月の範囲で見せる画面です。少なくともセキュリティ閲覧者のロールがあれば見られ、サインインの例を開いて詳細へ進むこともできます。2026年11月6日の時点で、Learn ではプレビューの扱いです（Microsoft Learn「条件付きアクセス ポリシーの影響の分析」）。Learn のこの説明には、Log Analytics などの準備は挙がっていません。ただ、説明は要約とサインインの例までで、影響の出る人の一覧を書き出せるという説明はありません。当社の環境にはポリシーが無く、この画面は見ていません。

サインイン ログ：1件ずつ確かめる

サインイン ログで1件のサインインを開くと、詳細に［条件付きアクセス］と［レポート専用］のタブがあり、レポート専用のポリシーの結果は［レポート専用］のタブに出ます。止まりそうな人を見つけたら、ここで、どのポリシーのどの条件に当たったかを確かめます。サインイン ログを見るには、少なくともレポート閲覧者のロールが要ります（Microsoft Learn「ID アクティビティ ログをカスタマイズおよびフィルター処理する方法」）。対話型と非対話型（アプリが本人の代わりに裏で行うサインイン）のサインインは別のタブに分かれているので、両方を見ます。列の選び方と、乗っ取りを疑う行の見方はサインイン ログの見方の記事に書いています。

当社の環境で開くと、このタブにはポリシー名・制御の許可・セッション制御・結果の列があり、下に、ユーザー リスクやサインイン リスクのポリシーでサインインが中断されることもあり、このタブには条件付きアクセスのポリシーだけが出る、という注記がありました。注記によれば、そうしたリスクのポリシーによる中断は、このタブでは分かりません。

一覧を絞るフィルターには［条件付きアクセス］がありますが、同じページが挙げる選択肢は［適用されていません］［成功］［失敗］の3つで、レポート専用の結果は入っていません。当社の環境でも、フィルターの項目に［条件付きアクセス］があることは確かめましたが、その選択肢までは開いていません。レポート専用の結果で絞れないとすると、1週間分を1件ずつ開いて探すのは手間がかかりすぎます。

JSON でダウンロードして、一覧を作る

Azure の契約が無い会社で、影響が出る人の一覧を作るなら、サインイン ログをダウンロードします。Learn は、レポート専用の結果を含めるには JSON の形式を選ぶよう書いています（Microsoft Learn「条件付きアクセスに関する分析情報とレポート」）。ダウンロードは1ファイル100,000件まで、時刻は UTC（日本時間から9時間引いた時刻）です（Microsoft Learn「Microsoft Entra ID でログをダウンロードする方法」）。期間とアプリをフィルターで絞ってから落とすと、件数を抑えられます。対話型と非対話型のサインインは別々に落とします。

ファイルの中で見るのは、サインインごとのポリシーの結果です。Microsoft Graph（Microsoft 365 のデータを読むための公式の仕組み）の説明では、サインインの記録の appliedConditionalAccessPolicies という項目に、ポリシーごとの名前（displayName）と結果（result）が入ります。result の値には reportOnlySuccess・reportOnlyFailure・reportOnlyNotApplied・reportOnlyInterrupted があります（Microsoft Learn「appliedConditionalAccessPolicy リソースの種類」）。同じページは、Graph でこの4つの値を受け取るには、要求に Prefer: include-unknown-enum-members という指定を付けるよう書いています。名前から、reportOnlyFailure が「レポートのみ: 失敗」に当たります。reportOnlyInterrupted は「レポートのみ: ユーザー アクションが必要」に当たると当社は見ていますが、Learn にこの2つを対応づけた説明は見当たりませんでした。

当社は、ポリシーの名前と result で行を絞り、ユーザー・アプリ・日時の列を並べた表を作ることをお勧めします。オンにする判断に要るのは「止まるサインイン」と「多要素認証を求められるサインイン」が誰の、どのアプリかで、この表があれば1件ずつ開かずに済むからです。ただし、管理センターからダウンロードした JSON に、上の項目名がそのまま入っているかは、当社では確かめていません。初めて落としたときに、ファイルの中を一度見てください。

サインイン ログが残るのは、P1 のライセンスで30日です（Microsoft Learn「データ保持のMicrosoft Entra」）。1週間見るなら足りますが、長く置いたポリシーの初めのころの結果は消えていきます。

分析情報とレポートのブック：Log Analytics にログを送っている会社向け

［条件付きアクセス］>［分析情報とレポート］のブックは、ポリシーを選び、時間の範囲（4時間から90日）、ユーザー、アプリを指定して、結果ごとの人数かサインイン数を出します。レポート専用のポリシーとオンのポリシーを組み合わせた影響も見られます。使うには、サインイン ログを受け取る Log Analytics のワークスペースが要ります。ブックに出るのは、ログを送り始めた後のサインインだけです（Microsoft Learn「条件付きアクセスに関する分析情報とレポート」）。

Log Analytics は、Azure の中でログをためて検索するサービスです。ワークスペースは Azure のサブスクリプション（Azure の利用の契約）の中に作るものです（Microsoft Learn「Microsoft Entra ログを Azure Monitor ログと統合する」）。Log Analytics の既定の料金は、取り込んだデータの量と保持の期間による従量課金です（Microsoft Learn「Azure Monitor ログのコストの計算とオプション」）。

当社の検証用の環境で開くと、上のとおり［アクセス許可がありません］と出て、ブックは表示されませんでした。Learn は、ブックを使う条件に、Log Analytics のワークスペースのほか、Entra ID と Log Analytics の両方のロールを挙げています（Microsoft Learn「条件付きアクセスに関する分析情報とレポート」）。当社はこの環境の Log Analytics の準備も、サインインしたアカウントのロールも確かめておらず、何が足りないための表示かは、画面からは分かりません。

Azure の契約がまだ無い会社が、レポート専用の結果を見るためだけに Log Analytics を用意する必要はない、と当社は考えます。オンにする判断に要る一覧は、ダウンロードした JSON から作れるからです。ログを長く残す目的がすでにあるなら、ブックも使えます。

記録に残るのは、その期間にあったサインインだけ

1週間見て「レポートのみ: 失敗」が0件でも、それだけではオンにしてよいとは言えません。記録は、実際にあったサインインにだけ残るからです。休暇中の人、月に一度しか使わない給与のアプリ、年に一度の手続きは、1週間のうちに出てこないことがあります。月末・月初にしか使わない処理がある会社は、その日を観察の期間に含めます。

経営者・経理・管理者など、止まると仕事が止まる人は、記録に出ていなくても What If（特定の人のサインインに、どのポリシーが当たるかを試す道具）で一通り試します。What If はレポート専用のポリシーも評価に含めます（Microsoft Learn「What If ツールを使用した条件付きアクセス ポリシーのトラブルシューティング」）。What If の開き方と入力の欄は条件付きアクセスの設定方法の記事に書いています。

ほかにも、記録の外にあるものが3つあります。くわしくは関連する記事に書いているので、ここでは要点だけにします。

• セキュリティ情報の登録など、利用者の操作を対象にしたポリシー（Learn では「ユーザー アクション」。結果の値の「ユーザー アクションが必要」とは別のもの）は、レポート専用で評価できるものから外されています（Microsoft Learn「条件付きアクセス ポリシーの影響の分析」）。記録が出ないことがあり、その扱いは条件付きアクセスの設定方法の記事に書いています。
• 準拠した端末を求めるポリシーをレポート専用にしていると、macOS・iOS・Android の利用者に端末の証明書を選ぶ画面が出ることがあります。Learn は、レポート専用の間はそのポリシーから Mac・iOS・Android を外すよう書いています。GPS で国を判定する場所を使うポリシーでは、レポート専用でも位置の共有を求められ、共有しないとブロックされることがあります（IP と国でサインインを制限する記事）。
• Microsoft が作って管理するポリシーは、レポート専用のまま置いておくと、テナント（Microsoft 365 を契約している組織の単位）に届いてから30日以上たったあとに有効になります。場合によっては30日より早く有効になることもあります。有効になる2週間前に、メールとメッセージ センターで知らせが来ます（Microsoft Learn「Microsoft が管理する条件付きアクセス ポリシー」）。届いたら、［ポリシー］の一覧で中身と除外を確かめます。

オンにしてよいかを決める順番

当社は、次の順で確かめてからオンにすることをお勧めします。記録で分かることと、記録の外で試すことを分けておくと、見落としが減るからです。

一覧に出た人には、オンにする日と、多要素認証の登録が要るかを先に知らせます。止まるサインインのうち止めてはいけないものは、除外を足す前に、なぜ当たったかを［レポート専用］のタブで確かめます。オンにするときは、［ポリシーの有効化］を［レポート専用］から［オン］に替えて保存します。オンにした直後の確かめ方と、締め出されたときの戻り方は条件付きアクセスの設定方法の記事に書いています。

オンのポリシーを直すときは、コピーをレポート専用で

すでにオンにしたポリシーを直したいときに、そのポリシーをレポート専用に戻して試すのは避けます。オンからレポート専用に替えると、その間はそのポリシーが適用されなくなるからです（Microsoft Learn「条件付きアクセスに関する分析情報とレポート」）。全員の多要素認証のポリシーなら、試している間、そのポリシーによる多要素認証は求められません。

Learn は、直したい内容を入れたコピーをレポート専用で作り、元のオンのポリシーと結果を比べる方法を挙げています。思ったとおりの結果なら、元のポリシーを直し、コピーを消します（Microsoft Learn「条件付きアクセス ポリシーの影響の分析」）。ポリシーはレポート専用・オン・オフを合わせて、テナントあたり240個までです（Microsoft Learn「条件付きアクセスのデプロイを計画する」）。試し終えたコピーは残さずに消します。

次にすること

まず、［条件付きアクセス］>［ポリシー］で、レポート専用のままになっているポリシーと、それぞれいつ作ったかを確かめてください。1週間以上たったものから、サインイン ログを JSON でダウンロードし、止まるサインインと多要素認証を求められるサインインの一覧を作ります。まだポリシーを作っていない会社は、条件付きアクセスの設定方法の記事の、最初に作るポリシーから始めてください。当社では、条件付きアクセスの設計とあわせた Microsoft 365 の導入支援も行っています。