SaaS

2026.08.07 09:02 (更新: 2026.08.07)

Exchange OnlineのEWSがいよいよ廃止へ、10月の強制無効化前に8月末までにやっておくこと

Shinsuke Murota

はじめに

どうも、むろです。

今回は、Exchange OnlineのEWS（Exchange Web Services）の廃止に向けて、2026年10月から始まるMicrosoftによる強制無効化と、その前に確認・設定しておきたいことを紹介します

まず意識するのは2026年8月31日という日付となります！

細かいことは置いておいて、まずは現状把握と延命手順を知りたい方は「調査方法と対応手順」の章から読み進めてください！

はじめにまとめ

EWSは2027年4月1日に完全廃止
- それに先立ち、2026年10月1日からMicrosoftがテナントのEWSを順次強制無効化する
強制無効化の対象は「EwsEnabledがデフォルト（Null）のままのテナント」
- 現時点でEWSが動いていても、明示的にTrueを設定していなければ強制無効化の対象になる（デフォルトはNull）
- EWSを利用中かどうかはレポートやスクリプトで確認できる
2026年8月31日までにEwsEnabledをTrueにすると、10月の強制無効化の対象外にできる
2026年10月1日以降は、Trueであっても許可リスト（EwsAllowedAppIDs）に載っているアプリしかEWSを利用できなくなる
- このため、継続利用するアプリのAppIDを調査で確定し、2026年10月1日より前までに許可リストへ登録する
- EwsEnabledがTrueの状態では、許可リストを登録した時点からリスト外のアプリは拒否される
いずれの対応もあくまでも延命であり、2027年4月1日以降は例外なくEWSは利用不可となる

EWSが止まると何が困るのか

EWSはアプリケーションがメールボックスへプログラムからアクセスするためのAPIです

そのため、EWSが止まってもメールの送受信やOutlook・OWA・スマートフォンでの利用には影響ありません

影響を受けるのは、裏側で動いている連携・自動化の類です

バックアップ／アーカイブ製品によるメールボックスの保護（例：Druvaのアーカイブメールボックスのバックアップ）
パブリックフォルダと電話システム・CRMなどの連絡先／予定表の同期
会議室予約パネルなどの空き状況連携
EWS Managed APIで作られた自作スクリプトや社内アプリ

特にアーカイブメールボックス・パブリックフォルダ・Microsoft 365グループメールボックスは、移行先となるMicrosoft Graphに代替APIが存在しない（2026年8月時点）ため、「ベンダーの対応待ち」では解決しない領域です

ユーザーの体感は正常なまま、バックアップやジャーナリングだけが静かに止まり、リストアが必要になったタイミングで初めて「保護されていない期間」に気づく、というのが一番怖いパターンです

スケジュールと挙動の整理

EwsEnabledはTrue／False／Nullの3値で、現在のデフォルトはNullです

Nullの間は「暗黙的に全許可」なので、今EWS連携が動いているからといって、明示的に有効化されているとは限りません

EwsEnabled	2026年10月1日まで	2026年10月1日以降
True	許可リストがなければ全て許可、あればリスト内のみ許可	許可リスト内のアプリのみ許可
False	全てブロック	全てブロック
Null（デフォルト）	全て許可	強制的にFalseへ変更される（＝全てブロック）

ここで押さえておきたいのは、「延命を判断する締め切り（8月末）」と「仕様が変わる日（10月1日）」が別ものという点です

タイミング	起きること	やること
2026年8月末まで	この日までにEwsEnabledを明示的にTrueにしたテナントは、10月の強制無効化の対象外になる	EwsEnabledを明示的にTrueにする（延命の意思表示の締め切り）許可リストは調査完了後、10月1日より前までに登録すればよい
2026年9月	許可リスト未作成のテナントには、Microsoftが利用実績ベースで許可リストを自動生成する	自動生成に任せず、継続利用するAppIDを調査して自分でリストを作成する（自作リストは自動生成で上書きされない）
2026年10月1日〜	NullのテナントはFalseへ順次変更される以降はTrueであっても許可リスト内のアプリのみEWSを利用可能になる（仕様変更）	この日より前までに許可リスト（EwsAllowedAppIDs）の登録を完了させておく
2027年4月1日	EWSの完全廃止管理者による再有効化も不可になる	この日までにMicrosoft Graphへの移行や代替手段の検討を完了させる

参考：Exchange Online EWS, Your Time is Almost Up（Microsoft）

調査方法と対応手順

調査方法と対応手順の全体像

最初に調査方法と対応手順の全体像をフローチャートで示します

EWS Usageレポートで検知しなかった場合でも、EwsEnabledがFalseになっていない限りは、スクリプトによる詳細調査までの実施を推奨します（レポートは最大過去90日分しか確認できないため）

EWSを使っているかをレポートで「大まかに」確認する

Microsoft 365管理センターにEWS Usageレポートが用意されています

管理センターの「使用状況（Usage）」＞「Exchange」＞「EWS Usage」から確認できます
テナント全体のEWSアクティビティの推移と、どのEWS操作（SOAPアクション）がどれくらい呼ばれているかを確認できます

⚠️

レポートの日付範囲は必ず最大まで広げて確認してください

レポートはデフォルトだと直近の短い期間しか表示されません
月次・四半期のバッチ処理やリストア時にしか動かないツールなど、たまにしか動かないアプリは短い期間ではレポートに現れず、「うちはEWSを使っていない」と誤判断する原因になります
画面上部の日付範囲を選択できる最大の期間（本ブログ執筆時点では過去90日）に広げて確認し、可能であれば時期を変えて複数回チェックしましょう。後述の許可リストに登録するAppIDの拾い漏れ（＝10月以降に突然止まるアプリ）を防ぐうえで特に重要です
なお、90日より前の利用実績はこのレポートでは確認できません
- 後述の「90日以上前の確認や詳細調査をスクリプトで行う」で紹介するスクリプトを使うと、監査ログから最大180日（Audit (Premium) 対象ユーザーは最大1年）まで遡って確認できます

どのアプリが呼んでいるか（AppID）は、レポート画面を下にスクロールした「使用状況の詳細」テーブルで確認できます
- 「アプリケーションID」「SOAPアクション」「通話量」「最後のアクティビティの日付 (UTC)」の列で、EWSを呼んでいるアプリがAppID×SOAPアクション単位で一覧表示されます
- テーブル上部の「エクスポート」から、同じ内容をCSV（TenantID・AppID・SoapAction・CallVolume・Date列）としてダウンロードして手元で集計することもできます
- ただし、ここに表示されるのはAppIDのみで、アプリ名までは表示されません

💡

AppIDからアプリの正体を突き止めるには

Entra管理センターの「エンタープライズアプリケーション」→「すべてのアプリケーション」を開く
「フィルターの追加」→「アプリケーション ID」を選択し、レポートで控えたAppIDを貼り付けて「適用」をクリック（上部の検索ボックスはアプリ名・テンプレートID用のため、AppIDを入れてもヒットしません）
ヒットしたアプリの「名前」がそのAppIDの正体です

ここで見つからない場合は、テナント内にサービスプリンシパルを持たないMicrosoftの既知アプリ（ファーストパーティアプリ）の可能性が高いため、AppIDでWeb検索して照合してみてください

意識していなかった標準アプリやバックアップ製品が意外と出てきます

このレポートでテナント全体の依存度とボリュームは把握できますが、「具体的にどのアプリ登録が呼んでいて、誰のメールボックスが影響を受けるのか」までは辿り着きにくいのが実情です

レポートで拾えない「90日より前の利用」や「どのユーザーが影響を受けるのか」は、後述の詳細調査で確認します

10月のEWS強制オフの対象外とする手順

EWS Usageレポートで延命が必要と判断できたら、EwsEnabledを明示的にTrueへ変更します

ここが延命の「有効化スイッチ」で、8月末までに設定しておくと10月の強制無効化の対象外になります

Microsoft 365のグローバル管理者権限が必要です

最初の「現在の設定を確認」の時点では、多くのテナントでEwsEnabledが空欄（Null）のはずです

あわせて、Trueへ変更する前に許可リスト（EwsAllowedAppIDs）が空であることも確認しておくと安全です

すでに許可リストが登録されている場合、Trueにした時点で「リスト内のアプリのみ許可」が適用され、リスト外のアプリが拒否されるためです
心当たりのない値が登録されていた場合は、後述の調査でリストの内容を精査してからTrueへ変更してください

# Exchange Onlineへ接続
Connect-ExchangeOnline

# 接続先テナントの確認（テナント名とテナントID）
# Organizationがテナント名（xxx.onmicrosoft.com）、TenantIDがテナントIDです
# 想定しているテナントに接続できているかを必ず確認してから次へ進んでください
Get-ConnectionInformation | Select Organization, TenantID, UserPrincipalName

# 現在の設定を確認
Get-OrganizationConfig | Select EwsEnabled, EwsApplicationAccessPolicy

# 許可リストが空であることを確認（何も表示されなければ空）
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

# EWSを明示的に有効化（Null → True）
Set-OrganizationConfig -EwsEnabled $true

# Trueになったことを確認（証跡として取得）
Get-OrganizationConfig | Select EwsEnabled, EwsApplicationAccessPolicy

90日以上前の確認や詳細調査をスクリプトで行う

EWS Usageレポートの内容だけでは継続要否が判断できない場合は「どのアプリが、どのユーザー（メールボックス）で使われているのか」の詳細を確認していきましょう

詳細調査で、すでに実際は使われておらず廃止できるEWS接続が見つかるかもしれません

さらに、後述のスクリプト（Find-EwsUsage.ps1）のEWSアクティビティの照会はMicrosoft Purviewの統合監査ログを利用するため、管理センターのEWS Usageレポート（最大90日）より長い期間を遡って確認できます

EWSの利用実績（監査ログ）：Audit (Standard) で180日、E5などのAudit (Premium) 対象ユーザーは最大1年まで遡れます
一方、アプリにサインインしたユーザーの一覧（Entraサインインログ）は保持期間の都合で直近30日分までです（Entra ID P1/P2の場合）
- ただし、アプリごとの「最終サインイン日時」は保持期間より前のものでも確認できます

Microsoftが公開している「Exchange-App-Usage-Reporting」スクリプト（Find-EwsUsage.ps1）を使うと、以下を段階的にCSVで出力できます

EWS関連の権限を持つEntra IDアプリ登録の一覧と最終サインイン日時（対象アプリの洗い出し）
アプリごとのサインインユーザーの一覧（影響を受けるユーザー・メールボックスの特定）
上記ユーザーのライセンスレポート
- 補足：Kiosk・F1・F3などのライセンスの特定が目的です
- これらのライセンスは当初、先行してEWSがブロックされる予定でしたが、2026年6月の公式情報の更新でブロック開始は2026年10月1日へ変更されています

実行には調査スクリプト専用のアプリ登録の作成が必要です（認証方式は証明書とクライアントシークレットのどちらにも対応しています）

具体的な手順は以下のMicrosoft公式の記事に詳しくまとまっています

参考：現場レポート：EWS 廃止前に行う EWS アプリ利用状況の確認と対策（Japan Exchange & Outlook Support Blog）

参考：Notes From the Field: Finding and Remediating EWS App Usage Before Retirement（Microsoft）

なお、公開リポジトリには3つのスクリプトが同梱されていますが、本記事の調査で使うのはFind-EwsUsage.ps1の1つだけです

Find-EwsUsage.ps1
- 本記事で使うメインのスクリプトです
- EWS関連アプリの洗い出し、サインインログ・監査ログの照会、ライセンスレポートの出力ができます
- それぞれで取得できる期間の上限は以下のとおりです
  - EWS関連アプリの洗い出し：期間の制限なし
  - サインインログの照会：最大直近30日分（Entra ID P1/P2の保持期間）
  - 監査ログの照会：調査対象ユーザー（ログが記録されたユーザー）のライセンスに依存します
    - Audit (Standard) の場合：最大180日分
    - E5などのAudit (Premium) 対象ユーザーの場合：最大1年分
  - ライセンスレポート：実行時点の割り当て状況（期間の概念はありません）
Find-EwsApps.ps1
- EWS UsageレポートからエクスポートしたCSVを入力に、AppIDをアプリ名へ一括で解決する補助スクリプトです
- 前述の「AppIDからアプリの正体を突き止めるには」の手作業を自動化するイメージですが、Find-EwsUsage.ps1の出力にはアプリ名が含まれるため、本記事の流れでは使う必要がありません
Graph-FindImpersonation.ps1
- 2025年2月に廃止済みのApplicationImpersonationロールの利用状況を調査するもので、今回のEWS廃止対応とは別テーマのスクリプトです

💡

スクリプトの実行手順とつまずきポイントは記事後半にまとめています

筆者が実際に試したところ思ったよりもつまずきポイントがありました

以下の内容は、記事後半の「Find-EwsUsage.ps1を試した際の気づき」にまとめています（思った以上に長くなったので流れを重視して後ろに置きます。。。）

クライアントシークレット方式での実行手順
- 公式の手順例は証明書の作成が必要なため
Intervalオプションを長くしないと429（Too Many Requests）になる
日本時間の環境で発生するサインインログ照会の無限ループ
macOS/Linuxで実行する際のつまずきポイント
- スクリプトの書き換えが必要

これからスクリプトを実行する方や、実行時にエラーが出て詰まった方はそちらを参考にしてください

出力結果の確認ポイント

最終サインインが新しいアプリから優先的に対応しましょう（現在進行形で本番を支えている可能性が高い）
サインイン記録がないアプリも「安全」と断定せず、休眠・設定ミス・廃止済みのいずれかを検証しましょう
アプリケーション許可（Application permission）で動くアプリは、ユーザーのサインインとしては現れないことがあります
- バックアップ製品などのアプリ自身の権限で動くタイプは、ユーザーのサインイン履歴がなくても稼働中の可能性があります
- このタイプの稼働状況は、Entra管理センターの「サインインログ」でタブを「サービスプリンシパルのサインイン」に切り替えて、対象アプリのサインイン実績を確認してください（既定表示の「ユーザーのサインイン（対話型）」には出てきません）
- あわせて、EWS Usageレポートの「使用状況の詳細」にそのAppIDが現れていないかも確認しましょう（レポートはアプリケーション許可での呼び出しもAppID単位で記録されます）

許可リスト（EwsAllowedAppIDs）を作成する

⚠️

この登録の期限は、許可リストの強制適用が始まる2026年10月1日より前までです

リストはいつでも更新でき、9月の自動生成（後述）が入った場合も後から登録しなおせます
ここまでの流れでEwsEnabledはすでにTrueになっているため、許可リストを登録するとその時点から「リスト内のアプリのみ許可」に切り替わり、リスト外のアプリは拒否されます
- 10月1日を待たずに適用されます
- なお、リスト変更の反映はサーバー側のキャッシュ更新の都合で最大24時間かかる場合があります
許可リストから拾い漏れたアプリは、登録した時点で止まります
バックアップのようにサイレントで動くアプリは止まっても気づけないため、前節の詳細調査まで済ませ、継続利用するAppIDを確定させてから登録してください
- 後から漏れが見つかった場合は、許可リストへ追記すれば復旧できます
- ただし、追記の反映にも最大24時間かかる場合があり、その間は失敗が続くため、そもそも漏れが出ないように事前の調査を徹底してください

EWS Usageレポートや前節のスクリプトの詳細調査で確認できたAppIDのうち、今後も利用を継続したいものを許可リスト（EwsAllowedAppIDs）に登録します

なお、EwsEnabledがNull（未設定）の間は許可リストは無視されますが、本記事の流れではすでに「10月のEWS強制オフの対象外とする手順」でTrueへ変更済みのため、この登録が実質的な「リストの有効化」になります

Microsoft 365のグローバル管理者権限が必要です

注意点として、EwsAllowedAppIDsはリスト全体を上書きする仕様です（追加・削除だけを行う操作はありません）

そのため、「現在のリストを読み取る → CSVへバックアップする → レポートや詳細調査で控えたAppIDを結合する → 全体を書き戻す」という流れで登録します

全体上書きの仕様上、操作ミスで既存のAppIDを消してしまうとそのアプリは10月以降使えなくなるため、書き換え前のリストを必ずCSVに残しておき、万が一のときはそこから書き戻せるようにしておきましょう

# Exchange Onlineへ接続
Connect-ExchangeOnline

# 現在の許可リストを読み取り
$current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs)

# 書き換え前のリストをCSVへバックアップ（誤消去時の復元用）
($current -split ",") | ForEach-Object { [PSCustomObject]@{ AppID = $_ } } | Export-Csv -Path ".\EwsAllowedAppIDs_backup_$(Get-Date -Format 'yyyyMMddHHmm').csv" -NoTypeInformation -Encoding UTF8

# 現在のリストに、レポートや詳細調査で控えたAppIDを結合して書き戻し
$updated = @($current | Where-Object { $_ }) + @("<追加するAppID-1>", "<追加するAppID-2>")
Set-OrganizationConfig -EwsAllowedAppIDs ($updated -join ",")

# 登録内容を確認
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

許可リストがまだ空（未作成）の場合は、レポートや詳細調査で控えたAppIDをカンマ区切りで直接指定しても問題ありません

Set-OrganizationConfig -EwsAllowedAppIDs "<AppID-1>,<AppID-2>"

逆に、誤登録や検証などで登録済みの許可リストを空（未作成の状態）へ戻したい場合は、$nullを指定します

# 許可リストを空（未作成の状態）に戻す
Set-OrganizationConfig -EwsAllowedAppIDs $null

# 空になったことを確認（何も表示されなければ空）
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

空へ戻した後の挙動は時期によって変わる点に注意してください

2026年10月1日より前：EwsEnabledがTrueであれば「リストなし＝全て許可」の状態に戻ります
2026年10月1日以降：「リスト内のアプリのみ許可」の仕様に変わっているため、空のままでは全てのアプリがEWSを利用できなくなります

なお、EwsAllowedAppIDsによる許可リストは現在ロールアウト中の新しい機能のため、テナントに展開されるまではパラメーター自体は見えても値を設定できない場合があります（弊社の検証テナントでは設定可能でした）

参考：Introducing EWSAllowedAppIDs: Preparing for the Final Phase of EWS Retirement（Microsoft）

💡

許可リストを作成しないまま8月を過ぎると、9月にMicrosoftが利用実績ベースで自動生成します

ただし、自動生成は「実際にEWSを呼んだ記録」ベースのため、四半期に1回のバッチやリストア時にしか動かないツールなど、利用頻度の低いアプリはリストから漏れ、10月以降に突然止まる可能性があります
逆に、利用実績さえあれば意図しないアプリも含まれ得ます
このため、自動生成に任せず、管理者自身が必要なアプリだけを載せたリストを作成することが推奨されています
自分で作成したリストは、9月の自動生成処理で上書きされません

上記の背景から本ブログでは明示的に許可リストを追加する手順を記載しています

EwsApplicationAccessPolicyも合わせて確認する

従来のアプリ制御（EwsApplicationAccessPolicy）をすでに使っているテナントは、今後は両方のリストの管理が必要になります
EWSには以前から、EwsApplicationAccessPolicyというアプリ制御機能があります（EnforceAllowListなら「EwsAllowListに載せたアプリだけ許可」、EnforceBlockListなら「EwsBlockListのアプリだけ拒否」という設定）
この従来の仕組みは今回のEWS廃止後も残り、新しいEwsAllowedAppIDsとは別々のチェックとして両方が動きます
つまり10月以降にアプリがEWSを使うには、「EwsAllowedAppIDsに載っている」かつ「従来のポリシーでもブロックされていない」の2つの条件を両方満たす必要があります
例えば、従来のEwsAllowListに登録済みのアプリでも、新しいEwsAllowedAppIDsへの登録を忘れると10月以降は止まります（逆に、新リストに載せても従来のポリシーでブロックしていれば使えません）

Find-EwsUsage.ps1を試した際の気づき

Intervalオプションを長くしないとToo Many Requestsになる

サインインログの照会（GetAppUsage）が、スロットリング（429：Too Many Requests）で失敗することがあります

原因は、GetAppUsageが指定した期間を-Intervalの時間数で分割してGraphへ連続で問い合わせる作りのためで、期間が長い・-Intervalが小さいほどリクエスト数が膨らみ、429が発生しやすくなります

この事象はOSを問わず発生します
- 筆者も実際に429の待ちになってしまいました
429が出た場合は、一度はまったリクエスト制限が解除されるまで再実行しても失敗し続けます

対処としては、15分〜30分ほど待ってから-Intervalを大きめの値（24など）に変更して再実行してください

本記事後述の「クライアントシークレット方式での実行手順」内の手順2の実行例は-Interval 24にしてあります

UTC以外のタイムゾーンで起きる無限ループ

サインインログの照会（GetAppUsage）が終わらず無限ループします

端末のタイムゾーンが日本の場合、指定した期間の照会がすべて終わった後、進捗表示の「Searching between 〜 and 〜」の開始と終了が同一時刻（実行時刻のUTC表記）になったまま、いつまで待っても先へ進まなくなります

原因は、照会ループの終了判定が「UTCへ変換済みの開始時刻」と「ローカル時刻のままの-EndDate」をそのまま比較しているためで、タイムゾーンがUTCより進んでいる環境（日本のUTC+9など）では終了条件が永遠に満たされなくなります

回避策として、-StartDateと-EndDateを最初からUTCで渡すと比較が揃い、ループは正常に終了します（本記事後述の「クライアントシークレット方式での実行手順」内の手順2の実行例はこの形にしてあります）

-StartDate (Get-Date).ToUniversalTime().AddDays(-29) -EndDate (Get-Date).ToUniversalTime()

この事象はタイムゾーン起因のため、OSやPowerShellのエディションを問わず、日本時間ならWindows（Windows PowerShell 5.1含む）でも発生します
- 逆にUTCやUTCより遅れた地域では発生しません
開始と終了が同一時刻の表示になった時点で、指定した期間分の照会とCSV出力自体は完了しています。以降は空振りの照会を繰り返しているだけなので、Ctrl+Cで停止して問題ありません

Windows以外でスクリプトを実行する際の注意

スクリプトはWindows PowerShell 5.1での実行を前提に書かれており、macOS/LinuxのPowerShell 7ではそのままでは動かない箇所があります

本ブログ執筆時点のバージョンを筆者がmacOSで検証した際の情報です
今後のスクリプトの更新で解消される可能性があります

① クライアントシークレット方式では認証が常に401（Unauthorized）で失敗する

シークレットを平文へ戻す処理（PtrToStringAuto）がmacOSでは1文字目しか返さないためで、シークレットの値自体が正しくても失敗します

スクリプト内のPtrToStringAutoをPtrToStringBSTRへ置換すると解消します（証明書方式はこの処理を通らないため影響ありません）

sed -i '' 's/PtrToStringAuto/PtrToStringBSTR/' Find-EwsUsage.ps1

② リクエスト失敗時に、失敗理由が表示されず別のエラーで停止する（修正は任意）

Graphへのリクエストが失敗した際にエラー内容を読み取る処理がWindows PowerShell 5.1専用の書き方（GetResponseStream）のため、失敗の本当の理由が確認できません

なお、この事象のみOSではなくPowerShellのエディション（.NET Frameworkと.NETのAPI差異）に起因するため、WindowsでもPowerShell 7で実行した場合は同様に発生します（Windows PowerShell 5.1では発生しません）

ただし、この処理はリクエストが失敗したときにしか通らないため、スクリプトが正常に動いている限り修正しなくても実害はありません（トラブルシュート時の原因調査用の任意の修正です）

直す場合は、①と同様に以下のワンライナーで置換できます

sed -i '' -e '/GetResponseStream/d' -e 's/$reader.ReadToEnd() | ConvertFrom-Json/$_.ErrorDetails.Message | ConvertFrom-Json/' Find-EwsUsage.ps1

内容としては、該当のcatch処理内の以下の2行を

$reader = New-Object System.IO.StreamReader($response.GetResponseStream())
$responseContent = ($reader.ReadToEnd() | ConvertFrom-Json)

Graphが返すエラーメッセージをそのまま表示する次の1行へ書き換えています

$responseContent = ($_.ErrorDetails.Message | ConvertFrom-Json)

③ 結果表示（Out-GridView）がエラーになる（対処不要）

手順2と手順3では、処理の最後に結果をGUIの表で表示するOut-GridViewが呼ばれますが、このコマンドレットはWindows専用のため、macOS/Linuxでは「The term 'Out-GridView' is not recognized」というエラーになります

エラーになるのは画面表示の部分だけで、CSVの出力自体は行われているため実害はありません

結果の確認は、出力されたCSVをImport-Csvで読み込んで代用してください

Import-Csv "<出力されたCSVのパス>" | Format-Table

クライアントシークレット方式での実行手順

参考記事の手順は証明書認証が中心のため、証明書の作成・登録が不要で手軽なクライアントシークレット方式の実行例を紹介します

事前準備として、参考記事のとおり調査スクリプト専用のアプリ登録を作成し、以下を済ませておきます

スクリプト用のアプリ登録の作成を行う
「APIのアクセス許可」でMicrosoft Graphのアプリケーションの許可として以下の4つを追加し、管理者の同意を付与する
- Application.Read.All
- AuditLog.Read.All
- AuditLogsQuery.Read.All
- Directory.Read.All
「証明書とシークレット」でクライアントシークレットを新規作成し、表示された「値」を控える
- 「値」は作成直後しか表示されません。また、隣の「シークレットID」は認証には使いません（間違えると401エラーになります）
アプリの概要画面で「アプリケーション (クライアント) ID」と「ディレクトリ (テナント) ID」を控える

シークレットはパラメーターにSecureString型で渡す必要があるため、先にRead-Hostで変数へ格納してから実行します（文字列で直接指定すると型変換エラーになります）

# 出力フォルダを事前に作成しておく（存在しないとパラメーターの検証エラーになります）
New-Item -ItemType Directory -Force -Path <出力フォルダのパス>

# シークレットをSecureStringとして格納（以下を実行後にプロンプトに控えたクライアントシークレットの「値」を貼り付け）
$secret = Read-Host -AsSecureString "Client Secret"

# 手順1：EWS関連の権限を持つアプリの一覧と最終サインイン日時を取得
./Find-EwsUsage.ps1 -PermissionType Application -OAuthClientId "<アプリケーションID>" -OAuthTenantId "<テナントID>" -OAuthClientSecret $secret -OutputPath <出力フォルダのパス> -Operation GetEwsActivity

手順1でサインイン実績のあるアプリが見つかったら、アプリごとにサインインしたユーザーの一覧を取得します

# 手順2：対象アプリのサインインユーザー一覧を取得（例：直近29日分。保持期間（30日）の境界を避けるため1日短くしています）
# 日付は後述の「UTC以外のタイムゾーンで起きる無限ループ」を避けるためUTCで指定しています
./Find-EwsUsage.ps1 -PermissionType Application -OAuthClientId "<アプリケーションID>" -OAuthTenantId "<テナントID>" -OAuthClientSecret $secret -OutputPath <出力フォルダのパス> -Operation GetAppUsage -QueryType SignInLogs -Name "<アプリ名>" -AppId <調査対象のAppID> -StartDate (Get-Date).ToUniversalTime().AddDays(-29) -EndDate (Get-Date).ToUniversalTime() -Interval 24

なお、手順2で照会できるのはEntraサインインログの保持期間内（Entra ID P1/P2で直近30日分）に限られます

実行例を29日分にしているのは、保持期間ちょうど（30日前）を指定すると境界上の照会がGraph側のエラーになることがあるためです
一方、手順1のアプリの洗い出しはサインインログではなくEWS関連の権限を持つアプリ登録を列挙する方式のため、期間の制限はありません（「最終サインイン日時」も保持期間より前のものを確認できます）

最後に、手順2で出力されたCSVを元に、影響を受けるユーザーのライセンスレポートを取得します

# 手順3：サインインユーザーのライセンスレポートを取得
./Find-EwsUsage.ps1 -PermissionType Application -OAuthClientId "<アプリケーションID>" -OAuthTenantId "<テナントID>" -OAuthClientSecret $secret -OutputPath <出力フォルダのパス> -Operation GetUserLicenses -AppUsageSignInCsv "<手順2で出力されたCSVのパス>"

その他の補足事項

EwsEnabledは強制的にFalseにされてもNullへ戻して再有効化できる

10月1日以降に強制無効化（False）された場合でも、管理者がEwsEnabledをNullへ戻すことで再有効化できます

Nullへ戻すと、完全廃止（2027年4月1日）までの間は許可リストの制限なしで全てのアプリがEWSを利用できる状態に戻ります

ただし、Nullのままにしておくと、段階的な強制無効化のロールアウトの過程で再びMicrosoftによってFalseへ変更される可能性がある点には注意してください

Microsoftのブログにも、ブロック後もEWSが必要な場合の選択肢として以下のように記載されています

But if you still need to use EWS, you will have two choices:
1. Set EWSEnabled to True and maintain an Allow List (via Baseline Security Mode or Exchange Online PowerShell).
2. Set EWSEnabled back to Null, which re-enables EWS without restrictions until the final deprecation occurs. This will have to be done using Exchange Online PowerShell.

引用元：Exchange Online EWS, Your Time is Almost Up（Microsoft）

なお、引用の1つ目の選択肢のようにTrueへ戻して再有効化することもできますが、10月1日以降は「許可リスト内のアプリのみ許可」の仕様が適用されるため、許可リスト（EwsAllowedAppIDs）の登録もあわせて必要です（リストが空のままでは全てブロックされたままです）

ただし、いずれの方法でも、ブロックされてから気づいて戻すまでの間はEWS連携が失敗し続けます

バックアップ用途の場合は「その期間のバックアップが取得できていない」ことになるため、事後に戻せるからと安心せず、事前の対応をおすすめします

あくまでも「延命」です

ここまでの対応は、2027年3月末までの延命措置に過ぎません

2027年4月1日以降はEwsEnabledやEwsAllowedAppIDsの設定に関わらずEWSが完全に無効化され、テナント管理者がEwsEnabledを制御する権限自体も削除されます。例外や延長はありません

そのため、延命と並行して以下を進めておく必要があります

EWSを利用しているアプリ・スクリプトのMicrosoft Graphへの移行
EWSで連携中のサードパーティ製品があれば、ベンダーへの事前の問い合わせ
パブリックフォルダを利用している場合は、Microsoft 365グループなどへの移行の検討

サードパーティ製品はベンダーへ事前に問い合わせを

バックアップ製品・アーカイブ製品・CRM連携など、EWSで連携中のサードパーティ製品がある場合は、廃止を待たずに事前にベンダーへ問い合わせておきましょう

確認しておきたいのは以下のような点です

その製品がEWSを利用しているか（利用している場合、どの機能が影響を受けるか）
Microsoft Graphへの対応状況と、対応予定時期（ロードマップ）
2026年10月の強制無効化・許可リスト必須化、2027年4月の完全廃止のそれぞれの時点で、利用者側に必要な作業があるか（許可リストへ登録すべきアプリID、バージョンアップ、設定変更など）
Graphに代替APIがない領域（アーカイブメールボックス、パブリックフォルダなど）に依存する機能は、廃止後にどうなるのか・代替手段はあるのか

ベンダー側の対応方針が分かっていれば、「延命期間中に何をどこまでやればいいか」の計画が立てやすくなりますし、逆に対応予定がないと分かれば、早めに製品の乗り換え検討へ動けます

一度確認して終わりではなく、移行が進んでいるか定期的にレポートを再取得して、EWS利用がゼロに向かっていることを確認するのがおすすめです

実際にDruvaのように、影響範囲と利用者側で必要な設定を整理したガイドを公開しているベンダーもあるので、まずは各製品の公式情報を確認し、なければ問い合わせる、という順番がおすすめです

参考：Exchange Online EWS Retirement: Druva Status and Configuration Guide

おわりに

今回の件は「今EWSが動いているから何もしなくて大丈夫」が通用しない、明示的なオプトイン方式になっているのがポイントです

自分のテナントでは使っていないつもりでも、レポートを見ると忘れられたスクリプトや古い製品の連携が意外と出てくるかもしれないので、まずは確認からはじめてみてください

この記事が誰かの役に立ったら嬉しいです！以上、むろでした。

タグ