Microsoft Graph APIは終了する？EWS廃止とAzure AD Graph終了の期限・移行手順【2026年11月】

Microsoft Graph APIそのものが終了する予定はありません。「Graph APIが終わる」という話の正体は、2025年8月31日に完全廃止されたAzure AD Graphと、Exchange Onlineで2026年10月1日から既定で無効化が始まったExchange Web Services（EWS）の2つです。この記事では、Graph本体の非推奨ルールを確認したうえで、EWSの日程、テナント内でEWSを呼んでいるアプリの洗い出し方、403応答の原因の見分け方、EWSの操作をGraph APIへ置き換える対応表とPythonのコードを順に解説します。日付と仕様は2026年11月7日時点の公式ドキュメントに基づきます。

まとめ：Graph本体は続き、止まるのはEWSと廃止済みの旧API

Graph APIのv1.0は存続しています。個別のAPIを削除するときは、少なくとも24か月前に非推奨が宣言されるため、ある日突然すべてが止まることはありません。

いま手を打つべきなのはEWSです。Exchange Onlineでは2026年10月1日以降、EWSの設定を明示していないテナントから順に無効化が進み、2027年4月1日には管理者の設定にかかわらず完全に止まります。Outlookのメールや予定表をEWSで読み書きしている社内ツール、勤怠や会議室予約との連携、メールアーカイブ製品は、Graph APIへの書き換えか、対応版への更新が必要です。

Azure AD Graph（graph.windows.net）はすでに使えません。まだ呼んでいるコードがあれば、エラーで止まっているはずです。

Graph APIの終了と誤解されやすい2つの廃止とGraph本体の存続方針

「終了」と検索される背景には、Graphの名前を含む別のAPIの廃止と、Graph以前の旧APIの廃止が混ざっています。対象と時期を分けて確認します。

Graph本体のv1.0は存続し個別APIの削除は24か月前に予告される規則

Microsoft Graphのバージョン管理と重大な変更の方針は、一般提供（GA）になったAPIを削除する場合、少なくとも24か月前に非推奨として宣言すると定めています。同じページには、現時点で非推奨またはサポート対象外のバージョンは無いとも書かれています。

例外は2つです。https://graph.microsoft.com/beta のAPIは、予告なく変更や廃止が起こりうるもので、本番利用はサポートされません。もう1つはSDKで、最新より古いメジャーバージョンは、最新版のリリースから12か月間だけセキュリティ修正を受けます。終了のリスクがあるのはGraphそのものより、betaに依存したコードと更新していないSDKです。

2025年8月31日に完全廃止されたAzure AD Graphと移行の参照先

Azure AD GraphからMicrosoft Graphへの移行ガイドによると、Azure AD Graphは2024年8月31日以降に作成したアプリから使えなくなり、2025年2月1日からは既存のアプリも拡張アクセスの明示的なオプトインが必要になりました。拡張アクセスも2025年8月31日に終わり、完全に廃止されています。

ユーザーやグループを graph.windows.net で操作していたアプリの書き換えは、エンドポイントとアクセス許可の読み替え、ADALからMSALへの移行まで、Entra IDのアプリをMicrosoft GraphとMSALへ移行する手順で詳しく扱っています。この記事では以降、作業がいま発生しているEWSを中心に解説します。

2026年10月1日から既定で止まり2027年4月1日に消えるEWSの日程

EWSはExchange Server 2007から使われてきたSOAPのAPIで、Graph APIの一部ではありません。ただし移行先がGraphに指定されているため、「Graphへの移行期限」として話題になります。Exchange OnlineでのEWSの廃止に記載された日程は次のとおりです。

対象はMicrosoft 365とExchange Onlineで、オンプレミスのExchange ServerのEWSは引き続きサポートされます。Exchangeチームの公式ブログ（2026年10月27日更新）は、2027年4月以降の例外や延長は認めないと明記しています。

EWSを呼ぶアプリをテナントの利用状況とソースコードの両面から洗い出す手順

棚卸しは、テナント側で「実際に呼ばれているアプリ」を確認し、開発側で「呼んでいるコード」を突き合わせる順に進めます。片方だけでは、外部ベンダー製品か、利用頻度の低いバッチを見落とします。

管理センターのEWS使用状況レポートでアプリIDとSOAP操作を一覧する

EWSの使用状況レポートは、Microsoft 365管理センターの［レポート］［使用状況］から［Exchange］を選び、［EWSの使用状況］タブで開きます。期間は過去7日・30日・90日から選べます。

詳細表には、アプリケーションID、SOAPアクション、呼び出し数、最後のアクティビティ日（UTC）が並び、CSVでエクスポートできます。アプリケーションIDをEntra IDのエンタープライズアプリケーションで照合すれば、どの製品やどの社内アプリかが分かります。

注意点は集計の粒度です。データは毎日ではなく週単位で集計され、反映まで最大10日かかります。月末や四半期末にしか動かない処理は、90日の期間で確認してください。

ソースコードとライブラリ依存からEWS呼び出しを機械的に検索するコマンド

社内で開発したアプリは、エンドポイントのURLとEWS用ライブラリの名前でリポジトリ全体を検索します。EWS Managed APIのNuGetパッケージ名、Python・Node.js・Javaの代表的なEWSクライアント名を検索語に入れておくと、設定ファイルに埋もれた呼び出しも拾えます。

# リポジトリ直下で実行（ripgrep を使用）
rg -n -i \
  -e "EWS/Exchange\.asmx" \
  -e "Microsoft\.Exchange\.WebServices" \
  -e "ExchangeService\(" \
  -e "exchangelib" \
  -e "ews-javascript-api" \
  -e "ews-java-api" \
  --glob "!node_modules/**" --glob "!*.min.js" .

# 依存定義だけを確認する場合
rg -n -i -e "exchangelib" -e "Microsoft\.Exchange\.WebServices" -e "ews-javascript-api" \
  -g "requirements*.txt" -g "pyproject.toml" -g "package.json" -g "*.csproj" -g "pom.xml" .

ヒットした箇所は、使用状況レポートのSOAPアクション（FindItem、GetItem、SyncFolderItems など）と突き合わせて、実際に本番で呼ばれている操作から移行の対象にします。コードにあってレポートに出てこない操作は、使われていない機能の可能性があり、移行せずに削る判断もできます。

403応答のX-EWS-Policy-Reasonで停止の原因を切り分ける判定方法

すでに止まったアプリでは、まず応答ヘッダーを見ます。EWSに対するアクセスの制御によると、アクセス制御で拒否された要求には、HTTP 403と X-EWS-Policy-Reason ヘッダーが返ります。値は2種類だけです。

HTTP/1.1 403 Forbidden
X-EWS-Policy-Reason: EWS is disabled for this user or tenant

HTTP/1.1 403 Forbidden
X-EWS-Policy-Reason: EWS is blocked by policy for this user or tenant

1つ目は組織またはメールボックスの EwsEnabled で無効になっている状態、2つ目はアプリIDの許可リストかUser-Agentのポリシーで拒否された状態です。ヘッダーが無い403は、権限不足など別の原因として調べます。Exchange Online PowerShellで現在の設定を確認するコマンドは次のとおりです。

Connect-ExchangeOnline

# 組織全体の EWS 有効化と User-Agent ポリシー
Get-OrganizationConfig |
    Format-List EwsEnabled,EwsApplicationAccessPolicy,EwsAllowList,EwsBlockList

# アプリ ID の許可リスト（このパラメーターを付けないと表示されない）
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy |
    Format-List EwsAllowedAppIDs

# 特定メールボックスの設定（組織で無効なら、ここが True でも使えない）
Get-CASMailbox -Identity "taro.yamada" | Format-List EwsEnabled

EwsEnabled : False なら、2026年10月の自動無効化が適用されたか、管理者が明示的に止めた状態です。許可リストは、変更が反映されるまで最大24時間かかります。直後に再試行して失敗しても、設定の誤りとは限りません。

EWSの操作をMicrosoft Graphの要求へ置き換える対応表と同期処理のコード例

EWSからGraphへの書き換えは、SOAPのXMLをRESTのJSONに置き換える作業です。操作の多くは1対1で対応先があり、迷うのは同期と通知の設計です。

FindItemやSendItemなど主要なEWS操作とGraph APIの対応表

EWSからGraph APIへのマッピングから、連携でよく使う操作を抜き出すと次のとおりです。

EWSで保存していたアイテムIDは、Graphのメッセージ一覧で返るIDと形式が違います。データベースにEWSのIDを持っているシステムは、translateExchangeIds で変換してから切り替えないと、過去データとの紐付けが切れます。SendItemの置き換え先になるsendMailの実装と送信元の絞り方は、Microsoft Graph APIでメール送信する手順で解説しています。

権限の付け方も変わります。EWSアプリのGraph移行ガイドが指摘するように、EWSはメールボックス全体を許可するかしないかの二択でした。Graphでは読み取りだけなら Mail.ReadBasic.All、本文も読むなら Mail.Read と、用途ごとに範囲を絞れます。権限設計の考え方は親記事のMicrosoft Graph APIとはで解説しています。

差分同期のポーリングをmessage deltaへ書き換えるPython実装

EWSの SyncFolderItems で受信トレイの差分を定期取得していた処理は、message: delta に置き換えます。初回は全件、2回目以降は前回の @odata.deltaLink を呼ぶだけで差分だけが返る仕組みです。次のコードはアプリ専用アクセスで1つのメールボックスを同期する例で、pip install msal requests で動きます。

# graph_delta_sync.py : EWS の SyncFolderItems を Graph の message delta に置き換える
import json, os, pathlib, time
import msal, requests

TENANT_ID = os.environ["TENANT_ID"]
CLIENT_ID = os.environ["CLIENT_ID"]
CLIENT_SECRET = os.environ["CLIENT_SECRET"]
MAILBOX = os.environ["MAILBOX_UPN"]          # 同期するメールボックスの UPN
STATE = pathlib.Path("delta_state.json")     # 前回の deltaLink を保存する

def get_token():
    app = msal.ConfidentialClientApplication(
        CLIENT_ID,
        authority=f"https://login.microsoftonline.com/{TENANT_ID}",
        client_credential=CLIENT_SECRET,
    )
    result = app.acquire_token_for_client(scopes=["https://graph.microsoft.com/.default"])
    return result["access_token"]

def sync():
    headers = {"Authorization": f"Bearer {get_token()}", "Prefer": "odata.maxpagesize=50"}
    if STATE.exists():
        url = json.loads(STATE.read_text())["deltaLink"]
    else:
        url = (f"https://graph.microsoft.com/v1.0/users/{MAILBOX}"
               "/mailFolders/inbox/messages/delta?$select=subject,from,receivedDateTime")
    while True:
        r = requests.get(url, headers=headers, timeout=30)
        if r.status_code == 429:                # スロットリング時は指定秒数だけ待つ
            time.sleep(int(r.headers.get("Retry-After", "10")))
            continue
        r.raise_for_status()
        body = r.json()
        for m in body["value"]:
            if "@removed" in m:                 # 削除・移動されたメッセージ
                print("removed", m["id"])
            else:
                print(m.get("receivedDateTime"), m.get("subject"))
        if "@odata.nextLink" in body:           # 同じラウンドの続きがある
            url = body["@odata.nextLink"]
            continue
        STATE.write_text(json.dumps({"deltaLink": body["@odata.deltaLink"]}))
        break

if __name__ == "__main__":
    sync()

差分の取得はフォルダー単位で、受信トレイと送信済みを両方同期するなら2本の deltaLink を持ちます。公式リファレンスの注記どおり、既読と未読の切り替えや、フォルダーからの移動も差分の一部です。@removed を無視すると、手元の一覧に消えたメールが残り続けます。$filter は receivedDateTime の比較だけ、$search は使えない点も、EWSの検索条件をそのまま移せない箇所です。

プッシュ通知をGraphの変更通知へ移すときの権限と購読の注意点

EWSのストリーミング通知やプッシュ通知は、Graphのサブスクリプション作成に置き換えます。メッセージの通知に必要な権限はアプリ専用アクセスで Mail.Read で、読み取りだけで足りる場合に書き込み権限は使えません。

EWSとの大きな違いは、通知先のURLが外部から到達できるHTTPSで、作成時の検証要求に応答できる必要がある点です。社内ネットワークの中だけで動いていたEWSのプル通知を移すなら、公開エンドポイントを用意するより、先ほどのdeltaを数分おきに呼ぶ方が構成は単純です。同じ changeType とリソースの組でもう1つ作ろうとすると409 Conflictになるため、再起動のたびに作り直す実装も見直します。

2027年4月までにEWSの移行を終えるための判断基準とGraphで代替できない機能

移行の順番は、Graphに対応先がある操作から先に進め、対応先の無い機能は代替手段を別に決める、の2段階です。延命の設定は、移行が間に合わないアプリにだけ使います。

Graphに追加されない3機能とロードマップ待ちの機能を分ける基準

EWS廃止の公式ページは、Graphに追加されないことが確定した機能として、パブリックフォルダーの汎用的な作成・読み取り・更新・削除、Microsoft 365グループのメールボックスの汎用的な操作、従来の探索メールボックスへのアクセスの3つを挙げています。これらに依存する処理は、Graphへの移行を待たずに設計を変えます。探索メールボックスの用途はPurviewの電子情報開示APIへ、グループの会話はGraphのグループ会話APIへ移す方針です。

アーカイブメールボックスの操作、連絡先リスト、メモ（IPM.StickyNote）、フォルダー内の全メッセージを一括で既読にする操作などは、2026年第3〜第4四半期を目標とするロードマップに載っています。公式は、表に無いEWSの機能は完全無効化までにGraphで提供されると考えないよう求めています。2026年11月時点で提供時期が来ていない機能に依存するなら、2027年4月1日に間に合わない前提で代替案を並行して用意してください。

EWSEnabledで延命してよい条件と移行を前倒しすべきアプリの見分け方

止まったEWSアプリは、Set-OrganizationConfig -EWSEnabled $true で一時的に戻せます。Exchangeチームの復旧手順（2026年10月21日）によると反映は通常1時間未満で、まれに最大4時間かかります。ただし2026年10月以降は、True にしても EwsAllowedAppIDs に載ったアプリしか通らず、一覧が空ならEWSは許可されません。

延命してよいのは、ベンダーの対応版が2027年3月までに出ると確約されている製品と、Graph側の対応がロードマップで示されている機能だけです。社内で開発したアプリで、使っている操作が対応表に全部載っているなら、延命せずに移行を前倒しします。延命の期限は2027年4月1日で固定されており、設定で稼いだ時間は移行の作業時間にしかなりません。

見落としが多いのは、ヘッダーの判定やID変換、権限の絞り込みまで含めた移行範囲の見積りです。アプリが複数の部署にまたがり、社内で棚卸しから書き換えまで手が回らない場合は、Microsoft 365・Copilot導入支援で、EWSの利用状況の確認とGraphへの移行開発だけを切り出して任せる方法もあります。

Graph自体の非推奨を見逃さないための変更ログとSDK更新の運用

EWSの移行を終えた後に備えるのは、Graph内の個別APIの非推奨です。24か月の予告はMicrosoft Graphの変更ログに掲載されるため、使っているリソース名（message、subscription など）で月1回確認する運用にしておけば、期限の2年前に気付けます。

コード側では、本番の要求URLに /beta/ が含まれていないかをCIで検査し、Graph SDKは最新のメジャーバージョンに上げておきます。古いメジャーバージョンのSDKはセキュリティ修正が12か月で止まるため、EWSのように期限が迫ってから慌てる構図を、SDKの側でも作らないことが目的です。

よくある質問

Microsoft Graph APIの終了とEWSの廃止について、問い合わせの多い質問を公式ドキュメントの記述に沿って答えます。

Microsoft Graph API自体が終了する予定はありますか？

2026年11月7日時点で、終了の予定は公表されていません。公式のバージョン管理方針には、非推奨やサポート対象外のバージョンは現在無いと書かれています。一般提供済みの個別APIを削除するときも、少なくとも24か月前に非推奨が宣言されます。終了が話題になるのは、廃止済みのAzure AD Graphと、2026年10月から無効化が進むEWSがGraphへの移行を求めているためです。

EWSが止まったアプリを一時的に動かす方法はありますか？

テナント管理者が、ベースラインセキュリティモードの画面かExchange Online PowerShellの Set-OrganizationConfig -EWSEnabled $true で再有効化できます。反映は通常1時間未満です。ただし2026年10月以降は、アプリIDの許可リスト（EwsAllowedAppIDs）に載ったアプリしか使えず、リストの変更は反映に最大24時間かかります。この方法は2027年4月1日以降は使えません。

オンプレミスのExchange ServerのEWSも廃止されますか？

廃止されません。今回の無効化はMicrosoft 365とExchange Onlineだけが対象で、オンプレミスのメールボックスは引き続きEWSを使えます。ハイブリッド構成では、オンプレミスのメールボックスはEWS、クラウドのメールボックスはGraphと呼び分けが必要になります。Graph APIはオンプレミスのExchangeをサポートしていない点にも注意してください。

Graph APIのbeta版は突然使えなくなりますか？

使えなくなる可能性があります。公式の方針では、betaのAPIには随時、重大な変更や廃止が発生することがあり、本番アプリでの利用はサポートされません。v1.0に昇格する保証もありません。本番の処理でbetaにしか無い機能を使っている場合は、v1.0に同じ機能が来ていないかを定期的に確認し、来た時点で切り替えてください。

EWS使用状況レポートに出てこないアプリは影響を受けませんか？

影響を受けないとは言い切れません。レポートは週単位の集計で、反映まで最大10日かかります。期間も最長90日のため、年1回の決算処理のように利用頻度が低いアプリは表示されないことがあります。ソースコードの検索と、EWSを使う製品のベンダーへの確認を併用して、レポートの外にある呼び出しを拾ってください。

関連記事

• Microsoft Graph APIの料金：無料の範囲と従量課金APIの単価・有効化手順【2026年11月】：移行後のGraph連携で費用がかかる経路
• SharePoint APIとは？REST APIとGraphの使い分け・Sites.Selected権限とリスト操作の実装例：SharePoint側で廃止された認証方式とGraphへの寄せ方
• Microsoft Entra ID（旧Azure AD）とは？読み方・ADとの違い・料金と始め方【2026年10月】：EWSのアプリIDを照合するエンタープライズアプリケーションの基礎
• Microsoft 365とは｜Office単体との違い・含まれるサービスと導入で詰まる点：Exchange Onlineを含むサービス構成の全体像