Exchange OnlineのEWSは2027年4月1日に終了：連携をMicrosoft Graphへ移行する

暗い部屋で、メールの受信トレイを表示した開いたノートパソコン

MicrosoftはExchange OnlineでExchange Web Services（EWS）の停止を始めました。最初の強制措置は今月実施され、その後はEWSの設定に一度も触れていないテナントが1つずつ停止され、2027年4月1日にはすべてのMicrosoft 365テナントでEWSがなくなります。Microsoftは、2027年4月以降の例外はないとはっきり述べています。

自社で作ったものがEWSでMicrosoft 365のメールボックスとやり取りしているなら、遅くともその日に、場合によってはずっと早く動かなくなります。よくあるのは次のようなものです。顧客とのメールを取引先ごとに保存するCRM、アーカイブや保持のスクリプト、会議室の予約画面、共有のサポート用メールボックスを読むチケット管理システム、チームごとのメール数を数える集計ジョブです。対処はMicrosoft Graphに対する書き直しで、EWSでできたことの一部にはGraphに相当するものがまったくありません。

日付ごとに何が起きるか

MicrosoftはテナントごとのEWSをEWSEnabled設定で制御しており、値はNull（既定値）、True、Falseの3つです。その隣に、いまでは2つ目の設定EWSAllowedAppIDsがあります。引き続きEWSを使ってよいアプリケーションIDのリストです。現在のMicrosoft Learnのページは概要を示しています。「2026年10月：すべての組織でEWSのグローバルな無効化を開始」、そして「2027年4月：EWSを完全に無効化」です。

詳細は、Exchangeチームによる10月1日の投稿EWS Deprecation Is Hereにあります。世界共通の商用クラウドについては次のとおりです。

2026年10月2日、太平洋時間の終業時：Microsoftは、EWSEnabledがTrueで許可リストのないすべてのテナントを記録します。
2026年10月8日と9日：それらのテナントについて、Microsoftが許可リストを作成し、過去60日間にEWSを使ったアプリケーションIDで埋めます。
2026年10月10日から：EWSEnabledがTrueの場合、許可リストが必須になります。リストにないアプリは拒否されます。
その後の第2段階：NullのままのテナントはEWSEnabledがFalseに設定され、すべてのアプリケーションでEWSがブロックされます。各テナントはメッセージセンターで7日前に警告を受け、Microsoftはその少し前に60日分の利用状況から許可リストを作成するので、管理者はTrueにしてEWSを再び有効にできます。
2027年4月1日：EWSは「完全かつ恒久的に無効化」され、テナント管理者はEWSEnabledをまったく変更できなくなります。

Microsoftのほかのクラウドのテナントには、メッセージセンターを通じてそれぞれのスケジュールが示されます。

許可リストで稼げるのは時間であって、解決ではない

自動で作られるリストは60日分の通信をもとにしており、Microsoft自身の9月4日のガイダンスは、それが「実行頻度の低いアプリケーションを見落とす可能性がある」と警告しています。四半期末のエクスポートや年末のアーカイブのジョブはリストに載らず、次に実行されたときに失敗します。

許可リストの変更が反映されるまでには24時間、EWSEnabledの変更には約1時間かかります。障害が起きてから修正しても、少なくとも1日は失います。

テナントの現状を確認するには、Exchange Online PowerShellを使える管理者が次を実行します。

Get-OrganizationConfig | Format-List EWSEnabled
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

対象となる組織、読まなくてよい組織

オンプレミスのExchange Serverは影響を受けません。 Microsoftは、この廃止が「Microsoft 365とExchange Onlineのみ」に適用され、「Exchange ServerのEWSには変更はない」としています。すべてのメールボックスが自社のサーバー上にあるなら、ここで読むのをやめて構いません。

ハイブリッド構成は詳しく確認する必要があります。 オンプレミスのメールボックスは引き続きEWSを使えますが、クラウドのメールボックスはGraphに移行しなければなりません。Microsoftの9月30日のハイブリッドに関する投稿は、いますぐ対応が必要な2つのケースを扱っています。その1つは、アーカイブがExchange Onlineにあるオンプレミスのメールボックスで、当面の助言は、EWSを有効にしたままハイブリッドのアプリケーションを許可リストに入れることです。

パッケージソフトウェアはベンダーの仕事です。 EWSを呼び出しているのが市販の製品なら、Graph版を提供するのはベンダーの仕事で、自社の仕事はベンダーから日付を引き出してアップデートを入れることです。Microsoft自身のクライアントも同じで、利用状況レポートにまだ表示され、更新されるまで許可リストが必要なものがあります。

社内のコードは自社の仕事です。 スクリプト、社内サービス、カスタマイズしたオープンソースのツール、何年も前に制作会社が作った連携には、直してくれる上流がいません。作業があるのはそこです。規模の目安として、EWSでExchangeとやり取りするためのPythonライブラリexchangelibは、過去1か月にPyPIから117万4,625回ダウンロードされています。その一部はオンプレミスでの利用ですが、どれだけのコードがEWSを直接話しているかの感覚はつかめます。

ステップ1：EWSを使っているものをすべて見つける

まず、Microsoft 365管理センターのEWS利用状況レポート（レポート、使用状況、Exchange、そしてEWSの使用状況タブ）から始めます。アプリケーションごとに、Microsoft EntraのアプリケーションID、そのアプリケーションが呼び出したすべてのSOAPアクション、呼び出しの件数、最終アクティビティの日付が表示されます。7日、30日、90日の期間でさかのぼることができ、CSVにエクスポートできます。

知っておくべき点が3つあります。

データは週単位で集計され、表示されるまで最長で10日かかります。
アプリケーションIDは所有者ではありません。各IDをMicrosoft Entraのエンタープライズアプリケーションと照合し、それを運用している人やチームを探してください。誰も知らないIDがいくつか出てくるはずです。
SOAPアクションの列を見れば、それぞれの作業の大きさが分かります。FindItemとGetItemしか呼ばないアプリなら短い作業です。SyncFolderItems、Subscribe、ExportItemsを呼ぶアプリなら、プロジェクトになります。

90日でも年次のジョブは漏れるので、反対側からも確認してください。スケジュールされたタスクやcronのエントリ、そしてEWSのエンドポイント（Exchange.asmx）、.NET用のEWS Managed API、exchangelibを対象にしたコードリポジトリの検索です。Microsoftの廃止に関するページには、.NETのコード向けのEWSアナライザー（Visual StudioとVS CodeでEWSの呼び出しを指摘し、Graphでの相当機能を提案するもの）と、AIを使ったリファクタリングのチュートリアルへのリンクもあります。

ステップ2：各連携をどうするかを決める

リストにあるすべてのアプリケーションに、4つの答えのどれかを割り当てます。

廃止する。 誰も止めなかったから存在しているだけの連携もあります。
アップデートする。 ベンダーの製品は、ベンダーのアップグレードで対応します。日付をいま合意してください。
Microsoft Graphに対して書き直す。 社内のコードの既定の答えです。
設計し直す。 Graphが今後も持つことのない機能に依存しているもの（後述）です。

Microsoftは、ワークフローを実装し直す方法としてPower Platformも挙げています。添付ファイルをフォルダーに転送するスクリプトなら、それが最も安上がりな答えかもしれません。

Graphへの書き直しに実際に含まれるもの

EWSの操作のほとんどにはGraphに直接対応するものがあり、MicrosoftはEWSからGraphへの対応表を管理しています。対応づけは簡単な部分です。難しいのは、対応表に出てこない部分です。

権限は狭くなり、それは利点である

サインインしたユーザーなしでEWSを使うアプリはEWSのアプリケーション権限を持っており、Microsoftはこれを「すべてのメールボックスへのフルアクセス」と説明しています。Graphはこれを個別の権限に分けています。Mail.Read、Mail.ReadBasic、Mail.Send、Calendars.ReadWrite、MailboxSettings.Readなどです。

アプリが到達できるメールボックスを限定することもできます。Exchange OnlineのアプリケーションのRBACは、管理スコープや管理単位に対して権限を割り当てるもので、従来のアプリケーションアクセスポリシーに取って代わります。会議室の予約画面には、12の会議室メールボックスの予定表だけを読ませ、それ以外には触れさせない、ということができます。落とし穴が1つあります。この方法で付与した権限は、Microsoft Entraでのテナント全体の付与に上乗せされるので、EntraでMail.Readへの同意が残っていれば、スコープは何も制限しません。Entraの付与を削除してください。

アプリの認証には、可能な限りクライアントシークレットではなく証明書を使い、認証情報をスクリプトやリポジトリに置かないでください。

同期と通知は、翻訳ではなく作り直しになる

メールボックスのデータのローカルコピーを持つものにとって、通常これが最大の変更です。

同期。 SyncFolderItemsはGraphのメッセージのデルタクエリに、SyncFolderHierarchyはメールフォルダーのデルタクエリに対応します。メッセージのデルタは1フォルダーずつ動くので、メールボックス全体を同期するには、フォルダーのツリーを追跡し、フォルダーごとに別々のデルタリンクを保存する必要があります。フィルターは限られており（受信日のみ）、結果にはフィルターに一致しない場合でも、削除、フォルダー外への移動、既読状態の変化が含まれます。

通知。 EWSのストリーミング通知とプッシュ通知の購読は、Graphの変更通知になります。通知は自社で運用するWebhook、またはAzure Event HubsやEvent Gridに届きます。WebhookはMicrosoftの側から到達できなければならないので、ファイアウォールの内側から接続を張りっぱなしにしていたスクリプトにとっては、アーキテクチャの変更です。メール、予定表、連絡先の購読は最長10,080分（7日弱）、通知にデータが含まれる場合は1,440分しかもたないので、何かが更新し続けなければなりません。1つのメールボックスで有効にできる購読は、すべてのアプリケーションを合わせて最大1,000件です。

うまくいくパターンは次のとおりです。通知はヒントとして扱い、デルタクエリを実行して何が変わったかを確認し、さらにタイマーでもデルタクエリを実行して、通知を取りこぼした場合に失われるはずのものを拾います。

データ、ID、スループット

保存されたID。 CRMやチケット管理システムが、メールとレコードを紐づけるためにEWSのアイテムIDを保存しているなら、その紐づけを変換する必要があります。Graphには、まさにそのためのtranslateExchangeIds関数があります。この変換は、独立した移行ステップとして計画してください。
検索。 ResolveNamesはPeople APIに、GetUserAvailabilityはgetScheduleに、不在時の設定はメールボックスの設定に対応します。近いものではありますが、同一ではありません。
スロットリング。 Graphは、アプリとメールボックスの組ごとに、10分あたり10,000リクエスト、同時リクエスト4件、5分あたり150 MBのアップロードに制限しています。1つのメールボックスに対して数十のEWSスレッドを並行して走らせていた一括処理のジョブは、これらの数字に合わせて設計し直さなければなりません。

欠けている機能と、今後も来ない機能

Microsoftは、Graphにまだないメールボックス機能のロードマップを公開しています。そこには、アーカイブ、パブリックフォルダー、グループのメールボックスに対する完全な忠実度でのインポートとエクスポート、インプレースアーカイブへのアクセス、Exchange Admin APIによるフォルダーの権限、MIMEからの下書きでないメッセージの作成などが含まれます。目標の多くは2026年第4四半期です。いくつかは第3四半期の予定でしたが、その四半期はすでに終わっているので、それを前提に設計する前に、実際に何が提供されたかを確認してください。Microsoft自身の警告では、ロードマップにない機能について、EWSが止まる前にGraphで相当するものが出ることを「当てにしないでください」とされています。

Graphに今後も来ないことが確定している機能が3つあります。

パブリックフォルダーへの汎用的なアクセス（フォルダーとアイテムの作成、読み取り、更新、削除）。
Microsoft 365グループのメールボックスへの汎用的なアクセス。 代わりにGraphは、グループの会話、スレッド、投稿を扱います。
探索用メールボックスへのアクセス。 Microsoftは代わりにPurviewの電子情報開示を案内しています。

ツールがこれらのどれかに依存しているなら、コードを移植するだけでは足りません。まずデータやワークフローを別の場所に移す必要があり、それには書き直しより長い時間がかかります。

6か月計画

今日から2027年4月1日までは6か月弱です。現実的な順序は次のとおりです。

2026年10月：現状を把握する。 EWSEnabledと許可リストを確認します。利用状況レポートの90日分をエクスポートします。Microsoftが作成したリストを見直し、載っているべきでないものを削除し、把握している実行頻度の低いジョブを追加します。テナントがまだNullなら、MicrosoftがFalseに切り替えて何が壊れるかを知ることになるのを待たずに、自分でリストを設定してTrueにすることを検討してください。

2026年11月：選別する。 すべてのアプリケーションIDに、担当者と答え（廃止、アップデート、書き直し、設計し直し）を割り当てます。コードをスキャンします。パブリックフォルダー、グループのメールボックス、探索用メールボックスに触れるものに印を付け、いますぐ設計し直しに着手します。権限のスコープを絞ったGraphのアプリ登録を作成します。

2026年12月から2027年1月：構築する。 業務が真っ先に困る連携から始めます。同期と通知の仕組みは一度作って再利用します。保存されたIDを変換します。

2027年2月：新旧を並行して動かす。 EWSがまだ動いている間に、新旧のバージョンを同じメールボックスに対して動かし、出力を比べます。1つずつ受け入れが済んだら、そのIDを許可リストから外します。それ自体がテストにもなります。24時間待ち、ほかに止まったものがないことを確認してください。

2027年3月：自分でEWSを止める。 4月1日よりかなり前に、EWSEnabledをFalseに設定します。見落としたものは、まだEWSを有効に戻せるうちに失敗します。4月1日を過ぎると、その選択肢はなくなります。四半期や年次のジョブも、それまでに意図的にテスト実行してください。第1四半期の締めに動くジョブは、EWSがなくなった後で初めて動くことになるからです。

ご相談先

難しいのは、最初に作った開発者がもういない連携です。当社のレガシーシステムの保守サービスは、まさにそのためのものです。既存のコードを読み、EWSの部分をMicrosoft Graphに対して書き直し（権限、同期、通知、IDの移行）、数字が一致するまで新旧を並行して動かします。自社のチームの中で働くエンジニアが必要なら、スタッフ増強サービスをご覧ください。

利用状況レポートが誰も知らないアプリケーションIDだらけなら、office@c9group.devまでご連絡ください。