Guide

EWS から Microsoft Graph への移行ガイド

Microsoft は 2026 年 10 月 1 日に Exchange Online 向け EWS をブロックし、2027 年 4 月 1 日に完全廃止します。本ガイドでは、廃止スケジュール、認証モデルの変更(NTLM から OAuth 2.0)、機能パリティの差異、3 つの移行パスを解説します。Graph API のコード例とプロバイダー非依存の代替手段も掲載。Gmail、Outlook、Exchange、Yahoo、iCloud、IMAP に対応。

Written by Caleb Geene Director, Site Reliability Engineering

Reviewed by Nick Barraclough

VerifiedCLI 3.1.1 · Exchange · last tested April 11, 2026

廃止のタイムライン

Microsoft は 2026 年 10 月 1 日に Exchange Online 向け Exchange Web Services (EWS) を完全にブロックし、2027 年 4 月 1 日に完全廃止します。この廃止は、世界中の 4 億以上の Microsoft 365 商用シートに影響します。Microsoft は 2023 年 9 月に廃止を最初に発表し、その後 3 回スケジュールを前倒ししています。

Microsoft の公式廃止ページによると、主要な日程は以下の通りです:

日付内容
July 1, 2026F1、F3、Kiosk ライセンスで EWS に対して HTTP 403 が返され始める
August 2026一時的な免除を受けるための AppID AllowList 設定の期限
October 1, 2026AllowList 未登録の非 Microsoft アプリに対して EWS がブロックされる
April 1, 2027EWS が完全に廃止。再有効化なし、例外なし

何もしなければ、EWS ベースのコードは 2026 年 10 月からエラーを返すようになります。TechCommunity の発表によると、Microsoft はオプトインしていないテナントに対して EWSEnabled=False を設定する予定です。

オンプレミス Exchange:影響なし

EWS の廃止は Exchange Online(Microsoft 365)のみに適用されます。オンプレミスで稼働する Exchange Server 2016 および 2019 は、廃止日の発表なく完全な EWS サポートを維持します。ハイブリッド Exchange を運用する組織(Microsoft の推定ではエンタープライズ Exchange 導入の約 40%)は、クラウドメールボックスを Graph API に移行する必要がある一方、オンプレミスメールボックスは引き続き EWS を使用するという分断に直面します。

このデュアルプロトコルの現実は、ハイブリッド環境が 2 つの認証フローと 2 つの API サーフェスを必要とすること、あるいはメールボックスの場所に基づいてリクエストを適切なプロトコルにルーティングする抽象レイヤーが必要であることを意味します。

認証モデル:NTLM/Basic から OAuth 2.0 へ

EWS から Microsoft Graph への移行では、NTLM、Kerberos、または Basic Auth を Azure AD(現 Entra ID)アプリ登録を通じた OAuth 2.0 に置き換える必要があります。Microsoft は 2022 年 10 月に Exchange Online の Basic Auth を廃止しており、Graph API はローンチ当初から OAuth 2.0 を必須としています。アクセストークンは 60-90 分で期限切れとなり、リフレッシュトークンは 90 日間有効で、その後再認証が必要です。

  • Azure AD アプリを登録し、Mail.Read、Mail.Send、Calendars.ReadWrite などのスコープを設定
  • フローを選択:ユーザーコンテキスト用の認可コード(委任)フロー、デーモン/サービスアプリ用のクライアント資格情報(アプリケーション)フロー
  • トークンライフサイクルを管理:アクセストークンは 60-90 分、リフレッシュトークンは 90 日で期限切れ
  • 管理者の同意:アプリケーションレベルのアクセス許可にはテナント管理者の承認が必要

以下のコードは、EWS Basic Auth と Graph OAuth 2.0 認証の違いを示しています。EWS は接続に最低 3 行で済みましたが、Graph では API 呼び出しの前に適切なスコープを設定した Azure AD アプリ登録が必要です。

# EWS(旧)- Basic Auth または NTLM
$cred = Get-Credential
$service = New-Object Microsoft.Exchange.WebServices.Data.ExchangeService
$service.Credentials = $cred
$service.Url = "https://outlook.office365.com/EWS/Exchange.asmx"

# Graph API(新)- MSAL を使用した OAuth 2.0
Connect-MgGraph -Scopes "Mail.Read","Mail.Send"
$messages = Get-MgUserMessage -UserId "me" -Top 10

機能パリティの差異(2026 年 4 月時点)

Microsoft Graph API はメール、カレンダー、連絡先の主要操作をカバーしていますが、少なくとも 4 つの領域で EWS との完全なパリティが不足しています:アーカイブメールボックスアクセス、パブリックフォルダー CRUD、メールボックスのインポート/エクスポート、定期イベントの差分クエリです。Microsoft は 2024 年以降、四半期ごとのリリースでギャップを埋めてきましたが、完全なパリティの達成日は明言していません。

下の表は、各 EWS 機能の Graph API 対応状況を示しています。データは Microsoft の TechCommunity の更新情報に基づいており、最も参照される 10 の EWS 機能を網羅しています:

EWS 機能Graph API の対応状況
Archive mailbox access利用不可
Public folder CRUD予定なし -- Outlook クライアントのみに制限
Mailbox import/export利用不可
Recurring event delta queries部分的にサポート
User configuration (dictionary items)Exchange Admin API(プレビュー)で対応
Extended properties (custom MAPI props)singleValueExtendedProperties でサポート
Autodiscover不要 -- Graph は単一エンドポイントを使用
Mail read/send/search完全パリティ
Calendar events CRUD完全パリティ
Contacts CRUD完全パリティ

Microsoft は一部のギャップに対する一時的なブリッジとして Exchange Admin API をリリースしました。しかし、すべてのパリティギャップが解消される確定日程はありません。

3 つの移行パス

EWS から移行する組織には 3 つの選択肢があります:Microsoft Graph API への直接移行、一時的な AppID AllowList 延長への登録、またはプロバイダー非依存の抽象レイヤーの採用です。適切な選択は、タイムライン、ハイブリッド Exchange の要件、アプリケーションがサポートするプロバイダー数によって異なります。Microsoft 自身の計画ガイダンスによると、Graph への直接移行には 2-6 か月を要するチームがほとんどです。

パス 1:Microsoft Graph API への移行

公式パスでは、すべての EWS 呼び出しを Graph の同等機能に置き換えます。Microsoft は、コードベースをスキャンして EWS 操作を Graph API の同等機能にマッピングする EWS コードアナライザーを提供しています。アナライザーは各 EWS メソッド、呼び出し回数、対応する Graph エンドポイントを一覧にした CSV レポートを出力します。

# EWS: 件名でメールを検索
$view = New-Object Microsoft.Exchange.WebServices.Data.ItemView(50)
$filter = New-Object Microsoft.Exchange.WebServices.Data.SearchFilter+ContainsSubstring(
  [Microsoft.Exchange.WebServices.Data.ItemSchema]::Subject, "invoice")
$results = $service.FindItems(
  [Microsoft.Exchange.WebServices.Data.WellKnownFolderName]::Inbox, $filter, $view)

# Graph: 同じ操作
$messages = Get-MgUserMessage -UserId "me" -Filter "contains(subject, 'invoice')" -Top 50

メリット: Microsoft エコシステム内にとどまり、最新機能にアクセスできる。 デメリット: Azure AD アプリ登録、OAuth トークン管理、非 Microsoft プロバイダー非対応、機能パリティの差異。

パス 2:一時的な AppID AllowList

AllowList は EWS アクセスを 6 か月間延長し、2026 年 10 月から 2027 年 4 月 1 日まで利用可能です。テナント管理者は 2026 年 8 月までにアプリケーションのクライアント ID を登録する必要があり、登録しない場合、免除は適用されません。Microsoft のドキュメントでは、これは 1 回限りの延長であり、2027 年 4 月以降の更新オプションはないと警告しています。

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

# アプリを AllowList に追加
Set-OrganizationConfig -EwsAllowList @{Add="your-app-client-id"}
Set-OrganizationConfig -EwsEnabled $true

メリット: すぐにコード変更が不要。 デメリット: 問題を 6 か月先送りするだけ。EWS は 2027 年 4 月 1 日に完全廃止。

パス 3:統合抽象レイヤーの使用

プロバイダー非依存の抽象レイヤーは EWS と Graph のルーティングを内部で処理するため、Microsoft がプロトコルを廃止してもコードを変更する必要がありません。Nylas CLI は Exchange Online、オンプレミス Exchange、Gmail、Outlook、Yahoo、iCloud、IMAP に単一のインターフェースで接続します。同じコマンドがプロトコル固有のロジックなしで 6 つのプロバイダーすべてで動作します。

# インストール
brew install nylas/nylas-cli/nylas

# 認証(OAuth、EWS、Graph を内部で処理)
nylas auth config

# メール読み取り -- メールボックスが
# Exchange Online(Graph)、Exchange オンプレミス(EWS)、Gmail のいずれでも動作
nylas email list --limit 10

# 検索
nylas email search "invoice" --limit 50

# 送信
nylas email send \
  --to "colleague@company.com" \
  --subject "Report" \
  --body "The report is ready: <report-download-link>"

メリット: プロトコル固有のコード不要、Azure AD アプリ登録不要、すべてのプロバイダーで動作、オンプレミスとクラウドを単一インターフェースで対応。 デメリット: 外部依存。Nylas API キーが必要。

比較表

3 つのアプローチは認証の複雑さ、プロバイダーカバレッジ、移行コストが異なります。EWS は 3 つの認証方式(NTLM、Kerberos、Basic)をサポートし、Graph API は OAuth 2.0 のみを必須とし、Nylas CLI は単一の設定コマンドで認証を処理します。以下の表は、移行計画に影響する 7 つの運用上の懸念事項について 3 つの方式を比較しています。

懸念事項EWS(廃止予定)Graph APINylas CLI
認証NTLM / Basic / OAuthOAuth 2.0 のみ1 回の nylas auth config
Azure AD アプリの要否不要(Basic)/ 必要(OAuth)必要不要
オンプレミス Exchange対応非対応対応(内部で EWS を使用)
Exchange Online2026 年 10 月にブロック対応対応(内部で Graph を使用)
Gmail、Yahoo、iCloud非対応非対応対応
トークン管理手動手動(MSAL)自動
必要なコード変更該当なし(廃止予定)EWS からの全面書き換え1 回限りの移行

ハイブリッド Exchange:デュアルコードベースの問題

ハイブリッド Exchange 環境では、2026 年 10 月以降、クラウドメールボックス用の Microsoft Graph とオンプレミス Exchange Server 用の EWS という 2 つの別々のコードパスを維持する必要があります。Microsoft Graph はオンプレミス Exchange Server をサポートしていないため、分割デプロイメントを持つ組織は単一の Microsoft API に統合できません。Microsoft のハイブリッドドキュメントによると、ハイブリッド構成はエンタープライズ Exchange 導入のかなりの割合を占めています。

このデュアルプロトコルの分断により、同一アプリケーション内で 2 つの認証フロー(Graph 用の Azure AD OAuth とオンプレミス EWS 用の NTLM または Kerberos)、2 つの API サーフェス、2 つのエラーハンドリングセットが必要になります。Nylas プラットフォームはこのルーティングを内部で処理し、メールボックスがクラウドかオンプレミスかを検出して、コード変更なしで適切なプロトコルを使用します。

移行チェックリスト

EWS の完全な移行は、認証、API サーフェス、エラーハンドリング、影響を受けるすべてのライセンスタイプにわたるテストに及びます。Microsoft は、Azure AD アプリ登録、管理者の同意、テストサイクルを考慮して、2026 年 10 月の期限の少なくとも 3 か月前に移行を開始することを推奨しています。以下の 6 ステップは、監査から本番カットオーバーまでのエンドツーエンドプロセスをカバーしています。

  1. EWS の使用状況を監査 -- Microsoft の EWS コードアナライザーを実行して、すべての EWS 呼び出しをインベントリ化
  2. パリティギャップを確認 -- EWS 操作を上記の機能差異表と比較
  3. 2026 年 8 月までにアプリを登録 -- 時間が必要な場合は、アプリを AllowList に追加
  4. F1/F3 ライセンスで先にテスト -- これらは 2026 年 3 月にブロック済みで、既に新しい動作になっている
  5. ハイブリッドに備える -- オンプレミス Exchange がある場合、デュアルプロトコル分断への対処方法を決定
  6. Microsoft の更新を監視 -- 機能パリティのギャップは四半期ごとに解消されている

よくある質問

EWS の廃止は、タイムライン、オンプレミスへの影響、機能差異、移行の代替手段に関する疑問を引き起こします。以下は、Microsoft の TechCommunity フォーラムや公式廃止ドキュメントで取り上げられているトピックに基づく、移行を計画する開発者からの最も一般的な 4 つの質問です。

Exchange Online 向け EWS はいつ廃止されますか?

Microsoft は 2026 年 10 月 1 日から非 Microsoft アプリの EWS リクエストをブロックします。2026 年 8 月までに AppID AllowList を設定したテナントには一時的な免除が適用されます。すべての EWS アクセスは 2027 年 4 月 1 日に完全に廃止されます。

オンプレミス Exchange Server でも EWS は廃止されますか?

いいえ。EWS は Exchange Server 2016 および 2019 で引き続き完全にサポートされます。廃止は Exchange Online(Microsoft 365)のみに影響します。

Graph API に不足している EWS 機能は何ですか?

2026 年 4 月時点で、Graph API にはアーカイブメールボックスアクセス、パブリックフォルダー CRUD、メールボックスのインポート/エクスポート、定期イベントの完全な差分サポートがありません。Microsoft は四半期ごとにギャップを埋めていますが、完全なパリティの達成日は明言していません。

移行を完全にスキップできますか?

はい。抽象レイヤーを使用する場合は可能です。Nylas プラットフォームは Exchange Online、オンプレミス Exchange、その他 4 つのプロバイダーに単一のインターフェースで接続します。プロバイダー側の廃止によるコード変更は不要です。

次のステップ

EWS 移行パスの計画後、以下のガイドでは Nylas CLI を使用した Exchange の具体的な操作を解説しています。各ガイドには、テスト済みのコマンド、プロバイダー固有のトラブルシューティング、6 つのサポート対象プロバイダーのコード例が含まれています。