Exchange OnlineのEWS廃止は、もう「将来の予定」ではなく、Microsoft 365管理者が今すぐ棚卸しを始めるべき移行案件です。結論から言うと、Exchange Web Services（EWS）は2026年10月からExchange Onlineで段階的に無効化が始まり、2027年4月には完全に無効化される予定です。社内アプリ、外部ベンダー製品、カレンダー連携、メール連携ツールを使っている組織は、EWS Usage Reportsで利用状況を確認し、Microsoft Graphへの移行可否を判断する必要があります。(Microsoft Learn)
今回のポイントは、EWS廃止の影響が「一部の古いサードパーティアプリ」だけに限られないことです。Microsoftは、Outlook、Office、Teams、Dynamics 365などMicrosoft製品側のEWS依存も解消対象に含めており、管理者には自社テナント内のEWS利用を可視化して、移行計画を前倒しすることが求められます。(Microsoft Learn)
Exchange Onlineの最新動向: Deprecation of Exchange Web Services in Exchange Onlineで何が変わったか
Microsoftの公式ドキュメント「Deprecation of Exchange Web Services in Exchange Online」では、2018年にEWSの機能更新停止が発表され、2023年にはExchange OnlineでEWSを2026年10月から無効化する方針が示された経緯が整理されています。2026年時点の重要な更新は、EWS廃止の対象がサードパーティアプリだけでなく、Microsoft製品を含む広い範囲に拡大している点です。(Microsoft Learn)
EWSは長年、メール、予定表、連絡先、フォルダー、空き時間情報などを扱うために使われてきたAPIです。しかしExchange Onlineでは、今後の標準的な連携先はMicrosoft Graphになります。単にエンドポイントを差し替えるだけではなく、認証、権限、APIの呼び出し方、データ取得方法を見直す移行作業として捉える必要があります。MicrosoftはEWSとMicrosoft Graph APIの対応関係を公開していますが、すべての機能が完全に一対一で置き換わるわけではありません。(aka.ms)
特に管理者が注意したいのは、2026年10月の時点でEWSを使う業務アプリが残っていると、メール取得、予定表同期、予約システム、CRM連携、監査・アーカイブ系ツールなどが止まる可能性があることです。影響範囲は開発部門だけでは把握しきれないため、Microsoft 365管理者、セキュリティ担当、業務部門、外部ベンダーを巻き込んだ棚卸しが必要です。
2026年4月更新で押さえるべき実務ポイント
2026年4月時点で、Exchange OnlineのEWS廃止対応は「方針確認」から「実装準備」の段階に入っています。Microsoft Learnでは、EWS Usage Reports、EWS Analyzer tool、AI assisted code analysis and refactoringなど、分析と移行を進めるための手段が紹介されています。(Microsoft Learn)
| 更新ポイント | 管理者が受け取るべき意味 | すぐ行うべきこと |
|---|---|---|
| 2026年10月からEWS無効化が始まる | 期限直前の確認では間に合わない | 90日以内のEWS利用アプリを洗い出す |
| 2027年4月に完全無効化予定 | 一時的な回避策に頼り続けられない | Graph移行、廃止、ベンダー更新の判断を完了する |
| Microsoft製品側のEWS依存も解消対象 | 「Microsoft製だから安全」とは限らない | クライアント更新、Message Center、Exchange Blogを継続確認する |
| Graphとの機能差分がまだ残る | すべてのEWS処理を単純置換できない | 代替設計、暫定許可、業務影響を整理する |
| EWS Usage Reportsが利用可能 | 推測ではなく実利用データで判断できる | Application ID、SOAP Action、最終利用日をCSVで管理する |
重要なのは、Graphの機能差分が完全に解消されるまで待たないことです。Microsoft自身も、すべての差分が埋まるのを待つのではなく、アクティブなEWSアプリを特定し、移行を開始するよう促しています。(Microsoft Learn)
EWS廃止スケジュールを整理する
Exchange OnlineのEWS廃止は、一日で全テナントが突然止まるというより、段階的な無効化として進む予定です。ただし、組織内でEWS利用状況を把握していない場合、段階的であっても業務停止のリスクは十分にあります。(TECHCOMMUNITY.MICROSOFT.COM)
| 時期 | 内容 | 管理者の対応 |
|---|---|---|
| 2018年7月 | EWSの機能更新停止を発表 | 新規開発でEWSを採用しない |
| 2023年 | Exchange OnlineでEWSを2026年10月から無効化する方針を発表 | 既存アプリの棚卸しを開始 |
| 2024年1月 | Midnight BlizzardのセキュリティインシデントによりEWS廃止の緊急度が上昇 | セキュリティリスクとして扱う |
| 2025年 | EWS Usage Reports、EWS Code Analyzer、管理APIプレビューなどが追加 | レポートとツールで実利用を確認 |
| 2026年10月 | EWSのグローバルな無効化が開始 | 重要アプリの移行・許可リスト対応を完了 |
| 2027年4月 | EWSが完全に無効化予定 | EWS依存を残さない |
オンプレミスのExchange ServerにおけるEWSそのものは、このExchange Onlineの廃止とは切り分けて考える必要があります。ただし、ハイブリッド環境では、対象メールボックスがExchange Online側にあるか、オンプレミス側にあるかで影響が変わります。クラウドメールボックスにアクセスするアプリは、Exchange OnlineのEWS廃止計画の対象として確認すべきです。(TECHCOMMUNITY.MICROSOFT.COM)
影響を受けやすいアプリと業務
EWSを使っているかどうかは、アプリ名だけでは判断できません。見た目は新しいSaaSや内製ツールでも、裏側でEWSを使ってメールボックスや予定表にアクセスしていることがあります。特に、長く運用している業務アプリ、退職者から引き継いだスクリプト、ベンダーが詳細仕様を公開していない連携機能は注意が必要です。
| 対象 | 影響例 | 確認すべきポイント |
|---|---|---|
| 予定表・会議室予約システム | 空き時間取得、予定作成、予約同期が失敗する | GetUserAvailabilityや予定表関連SOAP Actionの利用有無 |
| メール連携アプリ | メール取得、送信、フォルダー操作が止まる | CreateItem、FindItem、GetItem、SendItemなどの利用有無 |
| CRM・SFA連携 | 顧客メールの自動取り込みが止まる | どのメールボックスにアクセスしているか |
| 監査・アーカイブ・バックアップ系 | メールボックス内容の取得や保存に影響 | Graphで代替できる範囲と未対応領域 |
| 内製PowerShell・バッチ処理 | 夜間処理や定期同期が失敗する | 認証方式、Application ID、最終実行日 |
| 外部ベンダー製品 | ベンダー更新待ちで移行が遅れる | Graph対応版の有無、提供時期、設定変更要否 |
業務部門に説明するときは、「EWSが廃止されます」だけでは伝わりにくいです。「メールを自動で取り込む機能」「会議室予約の空き時間確認」「カレンダー同期」「問い合わせ管理システムのメール連携」など、利用者が理解できる業務機能に置き換えて説明すると、影響調査が進みやすくなります。
まずEWS Usage Reportsで利用状況を確認する
最初に行うべき作業は、EWS Usage Reportsによる棚卸しです。このレポートでは、組織内でEWSを呼び出しているアプリごとに、使用されたSOAP Action、成功した呼び出し量、Application ID、最終アクティビティ日などを確認できます。期間は直近7日、30日、90日でフィルターでき、データは日次ではなく週次で集計されます。(Microsoft Learn)
確認手順は次の流れで進めます。
| 手順 | 作業内容 | 見るべき項目 |
|---|---|---|
| 1 | Microsoft 365管理センターを開く | Reportsにアクセスできる権限があるか |
| 2 | Reports > Usage > Exchangeを開く | EWS usageタブが表示されるか |
| 3 | 90日分のデータを確認する | Active apps、Daily average call volume |
| 4 | Usage detailsをCSVでエクスポートする | Application ID、SOAP Action、Call Volume、Last Activity |
| 5 | アプリ所有者を特定する | Entra IDのエンタープライズアプリ、ベンダー名、社内担当者 |
| 6 | 対応方針を分類する | Graph移行、ベンダー更新、廃止、暫定許可 |
ワールドワイドクラウドではMicrosoft 365管理センターのレポートが第一候補です。一方、政府機関向けクラウドやソブリンクラウドなど一部環境では、管理センター上のレポート提供状況が異なる場合があります。その場合は、Microsoftが公開しているEWS Migration Toolsの利用可否も確認してください。(aka.ms)
棚卸し後は「移行」「廃止」「保留」を分ける
EWS利用アプリを見つけたら、すべてを同じ優先度で扱うのではなく、業務影響と移行難易度で分類します。特に、毎日大量に呼び出しているアプリ、全社的な業務に関わるアプリ、所有者が不明なアプリは早めに対応すべきです。
| 優先度 | 判断基準 | 対応方針 |
|---|---|---|
| 高 | 毎日利用、基幹業務、利用部門が多い、所有者不明 | すぐに担当者を決め、Graph移行またはベンダー対応を開始 |
| 中 | 利用頻度は低いが業務上必要、Graph代替がありそう | 2026年夏までに移行テストを完了 |
| 低 | 90日以上利用なし、廃止予定、重複機能 | 無効化候補として整理し、関係者に確認 |
| 要注意 | Public Folder、Archive、Recurring Event Deltaなど差分領域に関係 | Graphの対応状況を確認し、代替設計を検討 |
Microsoft Learnでは、Microsoft Graph APIがまだ完全に対応していない主な領域として、Public Folder、Microsoft 365 Groups、Archive、Recurring Event Delta、Sticky Notes CRUD、User Configuration、Administration APIsなどが挙げられています。一部はプレビューとして進んでいますが、実運用ではプレビュー機能の利用可否、サポート条件、リリース時期を確認してから判断すべきです。(Microsoft Learn)
Microsoft Graph移行で確認するポイント
EWSからMicrosoft Graphへ移行する場合、まずはEWSのSOAP Action単位で、GraphのどのAPIに置き換えられるかを確認します。Microsoftは、Messages、Folders、Attachments、Inbox Rules、MailTips、OOF設定、Notifications、Synchronization、Calendar、Groupsなどについて、EWS APIとMicrosoft Graph APIの対応表を公開しています。(aka.ms)
ただし、対応表があるからといって、既存コードを機械的に置換できるとは限りません。EWSはSOAPベース、Microsoft GraphはRESTベースのAPIであり、認証、権限スコープ、ページング、差分同期、エラー処理、スロットリング対策を設計し直す必要があります。移行計画では、次の観点を必ず確認してください。
| 確認項目 | 具体的に見ること |
|---|---|
| 権限 | Application permissionかDelegated permissionか、最小権限で設計できるか |
| 認証 | 古い認証方式や埋め込み資格情報が残っていないか |
| API対応 | 既存EWS SOAP Actionに対応するGraph APIがあるか |
| データ差分 | EWSで取得していたプロパティがGraphで取得できるか |
| 性能 | 大量メールボックス処理、夜間バッチ、再試行制御に問題がないか |
| 運用 | 監視、ログ、障害時の切り戻し手順があるか |
内製の.NETアプリでEWS SDKを使っている場合は、EWS Migration Analyzerの利用も検討できます。このツールは、EWSを使うコードベースを分析し、Microsoft Graph APIへの移行準備を支援する目的で公開されています。現時点では、EWSの.NET SDKを使ったアプリに対するコード分析が中心です。(aka.ms)
EWSEnabledと許可リストは「延命策」として慎重に使う
Exchange Onlineでは、EWSアクセス制御にEWSEnabled設定が関係します。MicrosoftのExchange Team Blogでは、テナント単位でEWSを無効化する仕組みや、True、False、Nullの扱い、AppID Allow Listによる制御について説明されています。2026年10月以降も一部アプリでEWSを使う必要がある場合、管理者は許可リストとEWSEnabledの設定を正しく理解しておく必要があります。(TECHCOMMUNITY.MICROSOFT.COM)
設定確認の基本はExchange Online PowerShellです。変更前に、まず現在値を確認してください。
Get-OrganizationConfig | fl EWSEnabledユーザー単位の状態も確認する場合は、対象メールボックスに対して次のように確認します。
Get-CASMailbox [email protected] | fl EWSEnabled注意すべき点は、EWSを一時的に許可できたとしても、それは恒久対策ではないことです。Microsoftは、2027年4月以降の例外はないと説明しています。許可リストは「移行までの業務停止を避けるための管理策」と位置付け、Graph移行やアプリ廃止の計画とセットで運用すべきです。(TECHCOMMUNITY.MICROSOFT.COM)
管理者・IT部門・業務部門が取るべき行動
EWS廃止対応は、Microsoft 365管理者だけで完結しません。Application IDからアプリ名や所有者を特定し、業務部門に利用有無を確認し、ベンダーにGraph対応状況を問い合わせる必要があります。特にグローバル組織では、地域ごとに異なるSaaSやローカルベンダー製品が使われていることがあるため、各国拠点のIT担当にも確認を依頼しましょう。
| 役割 | 今すぐ行うこと | 成果物 |
|---|---|---|
| Microsoft 365管理者 | EWS Usage Reportsを確認し、CSVをエクスポート | EWS利用アプリ一覧 |
| セキュリティ担当 | EWS利用をレガシーアクセスリスクとして評価 | リスク分類、優先順位 |
| アプリ所有者 | EWS SOAP Actionと業務機能の関係を確認 | 移行要件、テスト項目 |
| 開発者 | Graph API対応表とEWS Analyzerで移行可否を確認 | 改修見積もり、検証コード |
| ベンダー管理担当 | 製品のGraph対応版、提供時期、設定変更を確認 | ベンダー回答一覧 |
| 業務部門 | 影響を受ける業務フローを確認 | 業務影響リスト、受け入れテスト |
業務部門には、「2026年10月から段階的に止まる可能性があるため、メール・予定表連携を使うアプリを申告してほしい」と伝えるのが効果的です。専門用語のEWSを前面に出すより、実際の業務機能を挙げたほうが、見落としを減らせます。
よくある失敗と回避策
EWS廃止対応で失敗しやすいのは、技術的な移行そのものよりも、調査範囲の狭さです。管理者がEntra IDのアプリ登録だけを見て「該当なし」と判断しても、古いスクリプト、ベンダー製品、部門導入SaaSがEWSを使っているケースがあります。
| 失敗しやすいポイント | なぜ危険か | 回避策 |
|---|---|---|
| 90日レポートだけで判断する | 四半期・年次処理のアプリを見落とす | 業務カレンダーと照合する |
| Application IDの所有者が不明なまま放置 | 停止時に誰も対応できない | Entra ID、購買情報、部門ヒアリングで特定 |
| ベンダー回答を待つだけ | 期限直前にGraph対応が間に合わない可能性 | 代替製品、機能停止時の手順も検討 |
| Graph移行を単純置換と考える | 権限・同期・性能で問題が出る | 小さな機能からPoCを実施 |
| EWS許可リストを恒久対策にする | 2027年4月以降は使えない | 移行完了日を設定して管理する |
特に、Application IDが分かってもアプリ名がすぐに分からない場合があります。その場合は、EWS Usage Reportsの最終利用日、SOAP Action、呼び出し量、アクセス先メールボックス、Entra IDのエンタープライズアプリ情報を組み合わせて、所有者を絞り込む必要があります。
2026年夏までに完了させたいチェックリスト
2026年10月の段階的な無効化を考えると、管理者は2026年夏までに「何がEWSを使っているか」「止めてよいか」「Graphへ移行できるか」「一時的に許可が必要か」を判断しておきたいところです。Exchange Team Blogでは、2026年8月末までに許可リストを構成しEWSEnabled=Trueに設定したテナントは、2026年10月1日前後の自動変更から除外される旨が説明されています。(TECHCOMMUNITY.MICROSOFT.COM)
| 期限の目安 | チェック項目 |
|---|---|
| 今すぐ | EWS Usage Reportsを確認し、CSVで保存する |
| 2週間以内 | Application IDごとに所有者、用途、重要度を記録する |
| 1か月以内 | ベンダーへGraph対応状況と対応版の提供時期を確認する |
| 2026年夏まで | 重要アプリのGraph移行テストまたは代替策を完了する |
| 2026年8月末まで | EWS継続が必要な場合の許可リスト方針を確定する |
| 2026年10月前 | 業務部門と停止時の影響、切り戻し、問い合わせ窓口を確認する |
| 2027年4月前 | EWS依存を完全に解消する |
最後に行うべきことはシンプルです。Microsoft 365管理センターでEWS Usage Reportsを開き、90日分の利用状況をエクスポートしてください。その一覧をもとに、アプリ所有者、業務影響、Graph移行可否、ベンダー対応状況を1つの台帳にまとめます。Exchange OnlineのEWS廃止対応は、早く棚卸しを始めた組織ほど、停止リスクを小さくできます。
コメント