Exchange Online の EWS 廃止：業務システムの担当者が確認すべきこと

業務アプリケーションが Exchange Online の Exchange Web Services (EWS) に依存している場合、再構築を承認する前に、どの機能を使っているか、今後どのように継続するかを確認してください。サポート対象のベンダー更新や連携方法の変更で要件を満たせることもあります。利用可能な方法では業務上必要な処理を支えられない場合に、アプリケーション全体の置き換えを検討します。

予算を承認する立場の人にとって、出発点となるのは簡潔な依存関係の記録です。接続が何を行うのか、誰が管理するのか、どのサポート対象の方法に移行するのか、業務機能が動くことを何で確認するのかを記します。

現在のスケジュールと対象範囲

Microsoft の EWS 廃止に関する告知では、2 段階の移行が示されています。テナントごとに順次行われ、管理者が制御できる無効化は 2026 年 10 月 1 日に始まりました。この移行期間中にアクセスできるかどうかは、テナントの設定とアプリケーション側の制御によります。そのため、日付だけでは現在その接続が遮断されているか判断できません。恒久的な停止は 2027 年 4 月 1 日に始まり、その後は管理者がテナント設定で EWS のアクセスを制御できなくなります。

この告知の対象は Microsoft 365 と Exchange Online です。オンプレミスの Exchange Server における EWS は今回の廃止対象外です。影響を受ける接続が実際にどの環境へ接続しているのか、技術担当者に確認してください。

許可される場合、EWS アクセスを一時的に復旧すれば移行までの時間を確保できます。そのような措置にも担当者を決め、代替方法の完了日を設定してください。アクセスの復旧で分かるのは既存の接続が再び動くことだけであり、アプリケーションが恒久停止に備えられた証拠にはなりません。

技術的な依存関係の運用責任者を明確にする

まず、接続されたシステムを担当する人に確認します。IT 部門には EWS の利用状況を示す資料を依頼し、各アプリケーションの担当者には特定された接続が何を行うのかを尋ねてください。Microsoft の 廃止に関するガイダンスでは、管理者向けの利用レポートや分析ツールが案内されています。

アプリケーション ID は、それを業務機能と結び付けて初めて予算担当者にとって役立つ情報になります。たとえば、ある接続がスケジュール管理システムの予定を更新しているかもしれません。障害が起きると、スタッフが古い予定表を基に業務を進めることになります。その影響を把握すれば、優先順位と結果の承認者を決めやすくなります。

依存関係ごとに、次の項目を記録してください。

• 機能と影響: 接続が何を行うのか、どのくらいの頻度で必要なのか、失敗すると何が起きるのか。
• アプリケーションと責任者: 継続運用を担うシステム、ベンダー、社内担当者。
• 技術要件: 使用中の EWS 操作や機能、対象のメールボックスと環境。
• 継続方法の根拠: 提案されているサポート対象の移行先、それを扱うベンダーのリリースや資料、残っている不足点。
• 実施と受け入れ確認: 誰がいつまでに変更し、どの業務確認に合格する必要があるか。

観測された利用状況のレポートは依存関係の特定に役立ちます。ただし、月末処理のような頻度の低い作業も含め、運用上の重要性はアプリケーション担当者が説明する必要があります。

代替案で必要な機能を確認する

Microsoft Graph は多くの EWS シナリオに対応していますが、完全に同等だと決めつけるべきではありません。Microsoft の機能ロードマップには、残る不足点、代替手段、今後追加されない機能が示されています。たとえば、パブリック フォルダーのインポートとエクスポートは、通常の作成、読み取り、更新、削除の操作とは別の機能です。提案された方法がアプリケーションに必要な操作をカバーするか確認してください。

同じロードマップでは、提供予定日は変更される可能性のある目標だと説明されています。ロードマップに記された四半期がすでに過ぎていても、それだけで提供済みの証拠にはなりません。利用可能な機能と、それを使うリリースをベンダーまたは技術担当者に確認してください。

サポート対象のアプリケーション更新で必要な機能を満たせるなら、費用、展開要件、受け入れ確認の根拠を評価します。連携方法の変更で対応できるなら、その作業範囲を評価します。必要なコンポーネントに適切なサポート対象の方法がない場合は、別のコンポーネント、業務手順の変更、別のアプリケーションを比較します。不足している機能と業務への影響に沿って比較し、判断の根拠を明確にしてください。

検証できる結果を承認する

スケジュール確認を例にすると、連携システムから予定を作成して時刻を変更し、対象ユーザーに対して想定どおりに記録が更新されることを確認します。権限が各自の役割に合っているかも確認してください。操作が失敗するケースも含め、担当者がそれを把握して解決できることを確かめます。テスト前に期待する結果を合意しておきます。

サインインに成功しても、確認できるのは接続の一部です。受け入れ確認では、実際の業務処理と、影響のある失敗ケースの両方を実証します。完了を承認する人が確認内容を見られるよう、結果を依存関係の記録に添付してください。

影響を受ける業務システムの接続について支援が必要であれば、アプリケーションとその機能をお知らせください。私たちは API 連携サービスを提供しています。いただいた情報を基に、必要な作業範囲について話し合えます。