Microsoft の「Deprecation of Exchange Web Services in Exchange Online」で管理者が最初に押さえるべき結論は、EWS を使い続ける前提で延命するのではなく、利用中のアプリを棚卸しし、Microsoft Graph へ移行する計画をすぐに始めることです。Exchange Online では 2026 年 10 月から EWS の段階的な無効化が始まり、2027 年 4 月 1 日以降は完全かつ恒久的に無効化されます。移行が間に合わないアプリについては、EWSAllowedAppIDs と EWSEnabled を使って一時的に制御できますが、これは最終期限までの猶予策であり、恒久対応ではありません。(Microsoft Learn)
この記事では、2026年6月下旬時点の公式情報をもとに、Exchange Online の EWS 廃止で何が変わるのか、どのシステムに影響するのか、管理者がどの順番で確認・設定・移行すべきかを実務向けに整理します。
Microsoft の「Deprecation of Exchange Web Services in Exchange Online」とは
「Deprecation of Exchange Web Services in Exchange Online」は、Exchange Online で利用されてきた Exchange Web Services、いわゆる EWS を段階的に廃止する Microsoft の方針です。EWS はメール、予定表、連絡先、フォルダー、通知、同期などを扱うために長年使われてきた SOAP ベースの API ですが、Microsoft は 2018 年に EWS の機能更新を終了する方針を示し、2023 年には Exchange Online で 2026 年 10 月に EWS を無効化する計画を発表しています。(Microsoft Learn)
今回の変更で重要なのは、「古い API が非推奨になる」という一般的な話ではなく、Exchange Online 上の EWS 呼び出しが実際にブロックされる段階に入ることです。Microsoft Learn では、2026 年 10 月から EWS のグローバルな無効化が始まり、2027 年 4 月には完全に無効化されると説明されています。(Microsoft Learn)
対象は Microsoft 365 および Exchange Online の環境です。一方で、オンプレミスの Exchange Server における EWS は今回の廃止対象ではありません。ただし、ハイブリッド構成では「オンプレミスのメールボックスにアクセスするのか」「Exchange Online のメールボックスにアクセスするのか」で対応が変わるため、アプリごとの接続先を分けて確認する必要があります。(JP Messaging)
今回の更新で管理者が確認すべき主なポイント
2026年6月下旬時点で特に重要なのは、EWSAllowedAppIDs による App ID ベースの許可制御です。これは、EWS をすぐに停止できない組織が、残っている EWS 利用を「承認済みアプリだけ」に絞り込むためのテナントレベルの制御機能です。(JP Messaging)
| 確認ポイント | 内容 | 管理者の判断 |
|---|---|---|
| EWS の廃止期限 | 2026年10月から段階的に無効化、2027年4月1日から完全無効化 | 2027年4月以降の延命前提で計画しない |
| EWSAllowedAppIDs | App ID に基づき、EWS を使えるアプリを許可リスト化 | 一時継続が必要なアプリだけ登録する |
| EWSEnabled | テナント単位で EWS の有効・無効を制御 | True/False/Null の意味を期限前後で確認する |
| EWS 使用状況レポート | Microsoft 365 管理センターで EWS を呼び出しているアプリを確認 | まず棚卸しの起点にする |
| Microsoft Graph への移行 | 多くの EWS 操作には Graph API の対応先が用意されている | 移行可否を機能単位で判定する |
EWSAllowedAppIDs を設定すると、テナントレベルの EWSEnabled が True の場合に、許可リストに含まれる App ID のアプリだけが EWS を利用できます。従来の EWSAllowList は User Agent ベースの制御であり、App ID ベースの EWSAllowedAppIDs とは別物です。既存の EWSApplicationAccessPolicy を使っている場合も、App ID 許可リストとの関係を確認する必要があります。(JP Messaging)
影響範囲：どのアプリや業務が止まる可能性があるか
影響を受けるのは、Exchange Online のメールボックスに対して EWS を使ってアクセスしているアプリ、スクリプト、連携サービスです。Microsoft は EWS の依存関係が Microsoft Outlook、Microsoft Office、Microsoft Teams、Microsoft Dynamics 365 などの Microsoft 製品にも存在していたことを示し、Microsoft 製品側でも依存関係の削除を進めていると説明しています。(Microsoft Learn)
企業の現場では、次のような領域で EWS 依存が残っていることがあります。
| 領域 | 具体例 | 起こり得る影響 |
|---|---|---|
| バックアップ・アーカイブ | メールボックスの取得、復元、保管 | バックアップジョブの失敗、復元不可 |
| 移行ツール | テナント移行、メールボックス移行、共存処理 | 移行処理の停止、差分同期の失敗 |
| 予定表・会議室連携 | 会議室予約、空き時間取得、受付端末 | 空き時間表示の失敗、予約連携の停止 |
| 独自アプリ | 社内ポータル、承認ワークフロー、通知処理 | メール送信・予定表更新・フォルダー操作の失敗 |
| 運用スクリプト | PowerShell やバッチでのメールボックス操作 | 定期処理の停止、監査・集計処理の欠落 |
| サードパーティ製品 | 署名、DLP補助、CRM連携、eDiscovery補助 | ベンダー対応が必要、代替APIへの移行が必要 |
注意したいのは、利用者が「EWS を使っている」と認識していないケースです。例えば、古い会議室パネル、長年使っているメール連携ツール、退職者メールボックスのアーカイブ処理、古い .NET アプリの EWS Managed API などは、管理画面上では目立たなくても業務に深く組み込まれていることがあります。
移行期限とタイムライン
EWS 廃止対応では、2027 年 4 月だけでなく、2026 年 8 月末と 2026 年 10 月 1 日が重要な判断ポイントになります。特に、2026 年 10 月以降も一時的に EWS を使う必要がある場合、2026 年 8 月末までに許可リストと EWSEnabled=True の設定を済ませておくことで、10月の自動ブロックによる中断リスクを下げられます。(JP Messaging)
| 時期 | 何が起きるか | 管理者がやること |
|---|---|---|
| 現在 | EWS はまだ利用可能だが、廃止準備期間に入っている | EWS 使用状況レポートで依存アプリを洗い出す |
| 2026年8月末まで | 一時継続が必要なテナントは許可リストと EWSEnabled=True の設定が重要 | EWSAllowedAppIDs を作成し、対象アプリを検証する |
| 2026年9月 | 未構成テナントに対し、利用状況に基づく許可リストの自動作成が行われる可能性がある | 自動作成任せにせず、許可アプリを管理者が確認する |
| 2026年10月1日以降 | 段階的な EWS 無効化が始まり、未対応テナントではブロックが発生する可能性がある | 障害対応ではなく、事前移行・事前許可で備える |
| 2027年4月1日以降 | EWS が完全かつ恒久的に無効化される | EWS 前提の構成を残さない |
Microsoft の公式情報では、2027年4月以降の例外措置はないと説明されています。したがって、EWSAllowedAppIDs は「移行までの制御策」であり、「EWS を使い続けるための恒久的な抜け道」ではありません。(JP Messaging)
EWSEnabled と EWSAllowedAppIDs の動作を正しく理解する
EWS 廃止対応で混乱しやすいのが、EWSEnabled と EWSAllowedAppIDs の関係です。EWSEnabled はテナントレベルで EWS の有効・無効を制御する設定で、True、False、Null の値を取ります。Microsoft のドキュメントでは、2026年10月の EWS 廃止適用により、EWSEnabled パラメーターの動作が変わると案内されています。(Microsoft Learn)
| 設定 | 2026年10月より前の考え方 | 2026年10月以降の注意点 |
|---|---|---|
| EWSEnabled = Null | 既定状態。EWS トラフィックを許可する動作 | 段階的ロールアウトの中で False に変更され、EWS がブロックされる可能性がある |
| EWSEnabled = True、許可リストあり | 許可リスト内のアプリに絞って EWS を許可できる | 許可リスト内のアプリだけが EWS を利用できる |
| EWSEnabled = True、許可リストなし | 2026年10月前は許容的に動作 | 2026年10月以降は、許可リストなしでは実質的にブロック構成になり得る |
| EWSEnabled = False | EWS をブロック | EWS をブロック |
特に危険なのは、「EWSEnabled=True にしておけば安全」と考えることです。2026年10月以降は、EWSAllowedAppIDs の許可リストが空のままでは意図せず EWS が使えない構成になり得ます。Microsoft の説明でも、廃止適用後は許可リストなしで EWSEnabled=True を設定すると、実質的にすべてをブロックする構成になるとされています。(JP Messaging)
管理者が最初に行うべき確認手順
まずは、Microsoft 365 管理センターの EWS 使用状況レポートを確認します。このレポートでは、組織内で EWS を呼び出しているアプリ、SOAP アクション、成功した呼び出し数、最終アクティビティなどを確認できます。レポートは 7日、30日、90日でフィルターでき、データは日次ではなく週次で収集・集計されます。(Microsoft Learn)
Microsoft 365 管理センターで確認する
EWS 使用状況レポートは、Microsoft 365 管理センターの「Reports」から「Usage」を開き、Exchange のレポート内にある EWS usage タブで確認します。必要に応じて CSV にエクスポートし、App ID、SOAP Action、Call Volume、Last Activity date を並べ替えて分析します。(Microsoft Learn)
確認時は、単に「呼び出し数が多いアプリ」だけを見るのではなく、次の観点で分類すると実務に落とし込みやすくなります。
| 分類 | 判断基準 | 次の対応 |
|---|---|---|
| すぐ移行できる | Graph API で同等処理が可能、開発元も対応済み | 移行計画を前倒しで実施 |
| 一時継続が必要 | 2026年10月までに移行困難だが、2027年4月までに置き換え可能 | EWSAllowedAppIDs に登録し、移行期限を明確化 |
| 停止してよい | 既に使われていない、所有者不明、業務影響がない | アプリ登録や許可を削除し、不要な依存を排除 |
| 要調査 | App ID はあるが所有者や用途が不明 | Entra ID のエンタープライズアプリ、監査ログ、部門ヒアリングで特定 |
EWS 使用状況レポートは有力な起点ですが、週次集計である点に注意が必要です。月次・四半期・年次でしか動かない処理、決算期だけ使うアーカイブ処理、移行時だけ使うツールは、直近のレポートに出ない可能性があります。少なくとも 90日分を確認し、運用チームやアプリ所有者への確認も併用するべきです。(Microsoft Learn)
コードとアプリの依存関係を確認する
社内開発アプリがある場合は、EWS Migration Analyzer などの移行支援ツールも活用できます。Microsoft が公開している EWS Migration Tools では、EWS を使うアプリの特定や、Microsoft Graph API への移行検討を支援するツールが提供されています。特に .NET SDK ベースの EWS アプリでは、EWS Code Analyzer によりコード内の EWS 参照を確認できます。(aka.ms)
Microsoft Graph への移行では、EWS の操作単位で対応する Graph API を確認します。Microsoft Learn には、CreateItem、FindItem、GetItem、SendItem、UpdateItem などのメール操作、フォルダー、添付ファイル、ルール、OOF、通知、同期、予定表、グループ関連の EWS API と Graph API の対応表が用意されています。(aka.ms)
EWSAllowedAppIDs の設定例と注意点
EWSAllowedAppIDs は、Exchange Online PowerShell の Set-OrganizationConfig で構成します。Microsoft Learn では、App ID ベースで EWS を許可する例として、次のようなコマンドが示されています。(Microsoft Learn)
Set-OrganizationConfig -EwsAllowedAppIDs "11111111-2222-3333-4444-555555555555,aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"現在の許可リストを確認する場合は、次のように RetrieveEwsOperationAccessPolicy を付けて取得します。Microsoft の説明では、このリストは明示的に要求した場合に取得する設計になっています。(JP Messaging)
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs一時的に EWS の継続利用を選ぶ場合は、許可リストを設定したうえで、テナントレベルの EWSEnabled を True にします。
Set-OrganizationConfig -EwsEnabled $trueただし、ここで大きな注意点があります。EwsAllowedAppIDs に値を設定するコマンドは、既存値に「追加」するのではなく、指定した値でリスト全体を書き換えます。既に登録済みの App ID をコマンドに含め忘れると、そのアプリは許可リストから外れる可能性があります。(JP Messaging)
安全に更新する場合は、現在のリストを取得し、新しい App ID を加えたうえで、更新後の全体リストを書き戻す運用にします。
$current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs)
$newAppId = "99999999-8888-7777-6666-555555555555"
$updated = @($current, $newAppId)
Set-OrganizationConfig -EwsAllowedAppIDs ($updated -join ",")本番環境では、変更前に現在値をエクスポートし、変更後に対象アプリの実動作を確認してください。特に、会議室予約、メール送信、バックアップ、移行ツールなどは、画面表示だけでなく実際のジョブ完了まで確認することが重要です。
Microsoft Graph へ移行する際の判断基準
EWS から Microsoft Graph へ移行する際は、「EWS を使っているアプリ」を単位に考えるだけでは不十分です。同じアプリでも、メール送信、フォルダー同期、予定表の空き時間取得、通知、権限管理など、利用している機能によって移行難易度が変わります。
| EWS の利用内容 | Graph での移行検討 | 実務上の確認ポイント |
|---|---|---|
| メール作成・送信・取得 | Graph の message / sendMail 系 API を確認 | アプリケーション権限か委任権限かを整理 |
| フォルダー操作 | mailFolder 系 API を確認 | 共有メールボックスやアーカイブの扱いを確認 |
| 添付ファイル処理 | attachment 系 API を確認 | 大容量ファイルや分割アップロードの要否を確認 |
| 予定表・空き時間 | calendar / getSchedule 系 API を確認 | 会議室・共有予定表・委任アクセスを検証 |
| 通知・同期 | subscription や delta query を確認 | EWS の pull/streaming notification との設計差を吸収 |
| 管理系処理 | Exchange Online Admin API や PowerShell を確認 | Graph だけで置き換えず、用途に応じて分ける |
Microsoft Graph では、EWS の多くの API に対応する移行先が整理されていますが、すべての EWS シナリオが単純に 1対1 で置き換わるわけではありません。Microsoft Learn でも、Graph との機能差分が残る領域として、メールボックスのインポート・エクスポート、パブリックフォルダー、Microsoft 365 グループ、アーカイブ、繰り返しイベントの delta、Sticky Notes、userConfiguration、管理 API などが挙げられています。(Microsoft Learn)
そのため、移行計画では「Graph API に置き換える」だけでなく、次のように分解して判断します。
| 判断項目 | 確認すること |
|---|---|
| 認証方式 | Basic 認証や古い認証方式に依存していないか |
| 権限モデル | EWS の広いアクセス権限を Graph の最小権限に分解できるか |
| 対象メールボックス | ユーザー、共有、リソース、アーカイブ、グループのどれか |
| 実行頻度 | 常時同期か、バッチ処理か、月次処理か |
| 所有者 | 社内開発か、外部ベンダー製品か、所有者不明か |
| 期限 | 2026年10月までに移行可能か、2027年4月まで一時継続が必要か |
グローバル環境での運用上の注意点
グローバル企業や複数リージョンで Microsoft 365 を運用している場合、EWS 廃止対応はテナント単位の技術対応だけでは終わりません。Microsoft 365 管理センターの EWS 使用状況レポートは worldwide cloud のテナントでは利用できますが、政府機関向けクラウドやソブリンクラウドなどの isolated cloud では管理センター上のレポートが利用できない場合があり、公開ツールや監査ログ API を使った調査が必要になることがあります。(aka.ms)
グローバル運用では、次の観点を早めに決めておくと混乱を減らせます。
| 観点 | 実務で決めること |
|---|---|
| タイムゾーン | 期限を UTC と各地域の業務時間に置き換えて周知する |
| アプリ所有者 | 本社IT、地域IT、外部ベンダーの責任分界を明確にする |
| 変更凍結期間 | 決算期、繁忙期、監査期間と EWS 無効化テストが重ならないようにする |
| 許可リスト管理 | App ID の追加・削除を誰が承認するかを決める |
| 監視 | EWS 呼び出し失敗、Graph API エラー、業務ジョブ失敗を別々に監視する |
| ベンダー対応 | 「EWS 非依存版」のリリース日、設定変更手順、検証方法を文書で確認する |
特に海外拠点が独自に導入したツールは、中央ITのアプリ一覧に載っていないことがあります。EWS 使用状況レポートだけでなく、Entra ID のエンタープライズアプリ、条件付きアクセスのサインインログ、各地域の運用台帳、ベンダー契約情報を突き合わせることが重要です。
よくある失敗と回避策
EWSAllowedAppIDs を恒久対策だと考える
EWSAllowedAppIDs は、EWS の最終廃止までの移行期間を制御しやすくするための機能です。2027年4月1日以降も EWS を使い続けるための設定ではありません。許可リストに登録したアプリも、最終的には Microsoft Graph などのモダン API へ移行する必要があります。(JP Messaging)
EWSEnabled=True だけで安心してしまう
2026年10月以降は、EWSEnabled=True の意味が許可リストと強く結びつきます。許可リストを設定せずに True にするだけでは、想定どおりに EWS を継続利用できない可能性があります。EWS を一時継続する場合は、必ず EWSAllowedAppIDs の中身と対象アプリの動作を確認してください。(JP Messaging)
レポートに出ないアプリを見落とす
EWS 使用状況レポートは週次集計で、表示期間も 7日、30日、90日です。年に数回しか動かない棚卸し処理や、移行時だけ使うツールは見落とされる可能性があります。業務部門やベンダーへの確認を組み合わせ、季節性のある処理も洗い出しましょう。(Microsoft Learn)
User Agent ベースの AllowList と App ID ベースの許可リストを混同する
従来の EWSAllowList は User Agent ベースです。一方、EWSAllowedAppIDs は App ID ベースです。User Agent はアプリ側の送信文字列に依存するため、App ID ベースの制御とは性質が異なります。既存の EWSApplicationAccessPolicy を使っている組織では、両方の制御を整理して、意図しない許可・拒否が起きないように確認してください。(JP Messaging)
ベンダー任せで期限管理しない
サードパーティ製品が EWS を使っている場合、「ベンダーが対応するはず」と考えて放置するのは危険です。管理者側で確認すべきなのは、製品が EWS を使っているか、Graph 対応版が提供されているか、設定変更が必要か、既存データや権限に影響があるか、いつ本番適用できるかです。ベンダーの案内を待つだけでなく、App ID、接続先、移行手順、ロールバック手順を自社の変更管理に組み込む必要があります。
管理者向けの実行計画
EWS 廃止対応は、技術調査、権限設計、ベンダー調整、業務影響確認が絡むため、短期間で片付けるのが難しいテーマです。次の順番で進めると、抜け漏れを減らせます。
| 優先度 | 作業 | 成果物 |
|---|---|---|
| 高 | EWS 使用状況レポートを確認し、CSV を保存 | EWS 利用アプリ一覧 |
| 高 | App ID ごとに所有者、用途、ベンダー、対象メールボックスを特定 | 影響範囲一覧 |
| 高 | Graph 移行可否を API 操作単位で確認 | 移行判定表 |
| 高 | 2026年10月以降も一時継続が必要なアプリを選定 | EWSAllowedAppIDs 候補 |
| 中 | EWSAllowedAppIDs をテスト環境または限定範囲で検証 | 設定手順・検証結果 |
| 中 | ベンダー製品の EWS 非依存版への更新計画を確認 | ベンダー対応表 |
| 中 | 監視と障害時対応を準備 | 監視項目・連絡体制 |
| 低 | 不要な EWS アプリや古いアプリ登録を削除 | セキュリティリスク削減 |
まずは、EWS 使用状況レポートで「何が EWS を使っているのか」を把握してください。そのうえで、移行できるものは Microsoft Graph へ移行し、どうしても 2026年10月以降も必要なものだけ EWSAllowedAppIDs で一時的に許可します。最後に、2027年4月1日までに EWS 依存をゼロにする計画を、アプリ所有者とベンダーを含めて確定させることが重要です。
Microsoft の「Deprecation of Exchange Web Services in Exchange Online」は、単なる API の非推奨通知ではなく、Exchange Online の運用・連携・セキュリティ設計を見直す期限付きの変更です。いま行うべきことは明確です。EWS 利用状況を可視化し、残すものを厳選し、Graph へ移行し、許可リストを延命策ではなく移行管理の道具として使いましょう。
コメント