Microsoftは、Exchange OnlineにおけるレガシーなAPI、Exchange Web Services（EWS）の廃止に向けた最終カウントダウンを開始した。2026年10月1日から段階的な無効化が始まり、2027年4月1日にはサービスが完全に、そして永久にシャットダウンされる。これは、数千万規模のメールボックス、サードパーティ製アプリケーション、そして長年運用されてきた社内オートメーションに甚大な影響を及ぼす、運用上の「大転換」だ。
Microsoft 365環境の管理者は、この「非交渉的」な期限までに、Microsoft Graphへの移行を完遂しなければならない。本稿では、公開された最新のタイムライン、新しい管理制御モデル、そして移行に失敗した組織を待ち受けるリスクについて見てみたい。
20年の歴史に幕：なぜ今、EWSなのか
EWSは、Exchange Server 2007と共に登場して以来、約20年にわたりメールボックスへのアクセスやカレンダー連携、自動化ワークフローの屋台骨を支えてきたSOAPベースのAPIである。しかし、現代のクラウドネイティブな環境において、EWSはセキュリティとスケーラビリティの両面で限界に達している。
MicrosoftがEWSの廃止を急ぐ最大の要因は、セキュリティにある。EWSは現代的なテレメトリやOAuth第一主義の設計思想よりも前の世代の技術であり、一度権限が奪われると、メールボックスに対してあまりにも広範なアクセスを許してしまう構造的な脆弱性を抱えている。特に、昨今の「Midnight Blizzard」のような高度な攻撃グループによるインシデントは、レガシーなアクセスポイントがいかに攻撃者にとって魅力的な標的であるかを浮き彫りにした。
加えて、プラットフォームの集約も重要な戦略だ。Microsoftは現在、エンジニアリングのリソースをMicrosoft 365の共通APIである「Microsoft Graph」に集中させている。GraphはRESTベースで設計され、条件付きアクセスや詳細な権限管理、高度なテレメトリを統合しており、現代のエンタープライズが求めるガバナンスレベルを唯一実現できるインターフェースとなっている。
2026年から2027年に至る「死のロードマップ」
Microsoftが提示したスケジュールは極めて具体的であり、猶予はほとんど残されていない。管理者がカレンダーに刻むべき重要な節目は以下の通りである。
1. 2026年3月1日：フロントラインライセンスの先行制限
すでに一部のテナントで実施、あるいは進行中なのが、ライセンスに基づいたEWS制限である。Exchange Online Kiosk、Microsoft 365 F1/F3などのフロントライン/キオスクSKUを使用しているメールボックスに対し、EWSアクセスがブロックされ始めている。これらのアカウントを安価なサービスアカウントとして利用していた組織は、すでにHTTP 403エラーに直面しているはずだ。
2. 2026年10月1日：デフォルト無効化の開始
この日から、Microsoftはテナントごとに順次、EWSをデフォルトで「無効（False）」に設定していく。事前の設定（後述するEWSEnabled=TrueおよびAppID Allow Listの作成）を行っていないテナントは、このロールアウトが到達した瞬間にEWSを利用するすべてのアプリが停止する。
3. 2027年4月1日：完全かつ永久的なシャットダウン
これが「最終期限」である。この日以降、EWSを制御するすべてのスイッチ（EWSEnabledプロパティなど）が削除され、Exchange OnlineからEWSの機能そのものが消滅する。Microsoftは「これ以降の例外措置は一切認めない」と断言しており、いかなる理由があろうとも延命は不可能だ。
新しい制御モデル「AppID Allow List」の仕組み
2026年10月のデフォルト無効化を乗り切り、2027年4月までEWSを使い続けるための「猶予期間」を得るには、Microsoftが導入する新しい制御モデルを理解する必要がある。
EWSEnabledプロパティの3つの状態
今後の管理は、テナントレベルの EWSEnabled プロパティによって制御される。
- True: EWSの使用を許可する。ただし、後述する「AppID Allow List」に登録されたアプリのみがアクセス可能。
- False: テナント全体でEWSを完全にブロックする。
- Null: 現在のデフォルト。無制限に許可されるが、2026年10月1日以降、Microsoftによって順次「False」へ強制変更される。
AppID Allow Listによる厳格化
2026年初頭に導入される「AppID Allow List」は、特定のサービスプリンシパル（アプリケーションID）に対してのみEWSアクセスを許可するホワイトリスト方式である。これは従来の EWSApplicationAccessPolicy よりも優先される。管理者は2026年8月末までに、自社で使用しているEWS依存アプリを特定し、このリストを構成して EWSEnabled=True に設定しておく必要がある。
注目すべきは、Microsoftが2026年9月時点で準備が整っていないテナントに対し、過去の利用実績に基づいた「自動生成リスト」を適用する可能性がある点だ。しかし、この自動リストは意図しないアプリを許可し続けるリスクがあるため、管理者が主体的にリストを管理することが強く推奨されている。
組織を襲う「スクリームテスト（絶叫テスト）」の脅威
Microsoftは、最終的なシャットダウンの前に「スクリームテスト（Scream Test）」を実施すると警告している。これは、短期間だけ意図的にEWSをオフにし、どのシステムが「悲鳴を上げる（停止して騒ぎになる）」かを確認するためのテストである。
管理者は、突発的なEWSの停止が発生した際、それが単なるシステム障害なのか、Microsoftによる意図的なテストなのかを即座に判断できなければならない。このテストで表面化した依存関係は、2027年4月に確実に「致命傷」となる。ドキュメント化されていない古いスクリプトや、退職したエンジニアが作成した自動化ツールなど、闇に隠れたEWS依存をあぶり出す最後のチャンスとなるだろう。
誰が「被害」を受けるのか：見落としがちな依存関係
EWSの廃止で影響を受けるのは、派手なサードパーティアプリだけではない。日常の業務フローに深く組み込まれた以下の要素が、最もリスクが高い。
- 多機能周辺機器（MFP）の「スキャンしてメール送信」: 多くの古い複合機やスキャナーが、OAuthに対応していないEWSや古い認証方式に依存している。ファームウェアのアップデート、あるいはデバイス自体の買い替えが必要になるケースも少なくない。
- カレンダー同期ツールと会議室予約システム: 多くのISVがGraphへの移行を進めているが、古いバージョンのまま運用されているオンプレミス連携ツールなどは、ある日突然カレンダーが表示されなくなる可能性がある。
- 社内製マクロとPowerShellスクリプト: 共有メールボックスの監視や添付ファイルの自動保存を行っているレガシーなスクリプトの多くは、EWS Managed APIを使用している。これらはコードレベルでの書き換えが必須だ。
- CRM・ERP連携: SalesforceやDynamics以外の、特定業界向け（バーティカル）SaaSなどはGraph対応が遅れているケースがあり、ベンダーとの契約の見直しや、代替手段の検討を迫られるだろう。
管理者が今すぐ着手すべき「優先実行計画」
この「2026年の壁」を乗り越えるために、今週、今月、そして今年中に実施すべきアクションプランを以下にまとめる。
ステップ1：現状の可視化（即時）
Microsoft 365 管理センターの「EWS利用状況レポート」を実行し、どのAppIDがどのメールボックスに、どの程度の頻度でアクセスしているかを完全に把握する。Azure ADのサインインログとExchange Onlineの監査ログを組み合わせ、アプリケーションの「オーナー」を特定することが最優先だ。
ステップ2：ベンダーへの最終勧告（2ヶ月以内）
EWSに依存しているサードパーティベンダーに対し、Microsoft Graphへの移行ロードマップの提出を正式に要求する。2027年1月までにGraph対応が完了しないベンダーは、リプレイスの対象として検討すべきである。
ステップ3：管理者用APIへの先行移行（6ヶ月以内）
Microsoftは、EWSで行っていた管理者向けの操作（フォルダ権限の変更、配布グループ管理など）を代替するために「Exchange Online Admin API（パブリックプレビュー）」をリリースしている。まずはこの低リスクな領域から移行を始め、Graphへの移行プロセスにチームを慣れさせるのが得策だ。
ステップ4：EWSEnabled=Trueの設定（2026年8月まで）
2026年10月の強制無効化を回避するため、自社で精査したAllow Listを適用した上で、プロパティを「True」に明示的に設定する。これにより、2027年4月までの「安全な滑走路」を確保できる。
Graph移行の「落とし穴」：機能パリティの現状
Microsoftは「GraphはEWSとほぼ同等の機能（Near-complete parity）に達した」としているが、実務レベルではいくつかの差異（パリティギャップ）が残っていることに注意が必要だ。
例えば、パブリックフォルダの高度な操作、メールボックスのインポート/エクスポート・フロー、あるいは非常に複雑な再帰イベントのカレンダー同期などにおいて、Graphでは実装が困難、あるいは挙動が異なる場合がある。これらのギャップについては、Microsoftが公開している「Roadmap for parity gaps」を随時確認し、必要であればPowerShellを組み合わせた暫定的なアーキテクチャを構築するなどの工夫が求められる。
インフラの近代化へのラストチャンス
EWSの廃止は、多くの管理者にとって頭の痛い作業であることは間違いない。しかし、これを「負の遺産を一掃するチャンス」と捉えることもできる。古い、安全性の低い統合を現代的なGraphベースのAPIに置き換えることは、組織のサイバーレジリエンスを劇的に向上させる。
2027年4月1日。この日は「エイプリルフール」だが、Microsoftの警告は冗談ではない。その日、あなたのテナントのメールシステムが「悲鳴」を上げるか、それとも洗練されたモダンな環境で静かに運用を続けているかは、今日からの数ヶ月間の行動にかかっている。
Sources