5 月に、クラウド管理のリモート メールボックス向けの書き戻しのパブリック プレビューを発表しました。それ以来、多くのお客様がこの機能を有効にし、フィードバックを寄せてくださいました。このたび、クラウド管理のリモート メールボックス向けの書き戻しが一般提供 (GA) になりました。

書き戻しは、WW、GCCH、DoD、21Vianet の各環境で利用でき、テナントあたり最大 600,000 個のクラウド管理メールボックスをサポートします。

簡単なおさらい

クラウド管理のリモート メールボックスでは、ディレクトリ同期されたメールボックスの IsExchangeCloudManaged を true に設定することで、Exchange 属性の Source of Authority (SOA) を Exchange Online に移行できます。

ユーザー ID は引き続きオンプレミスの Active Directory から同期されますが、Exchange 属性は Exchange Online で編集できるようになります。管理者は、Exchange Online PowerShell、Exchange 管理センター、Microsoft 365 管理センターからこれらのプロパティを更新できます。

書き戻しはこの機能を拡張し、Exchange 属性に対する重要な一連の変更を、Microsoft Entra Cloud Sync を通じて Exchange Online からオンプレミスの Active Directory に同期します。これは、オンプレミスの基幹業務アプリケーションが Active Directory から Exchange 属性を引き続き読み取る組織に役立ちます。

Microsoft Entra Connect Sync をすでに使用している場合でも、アンインストールや置き換えは必要ありません。Cloud Sync は Connect Sync と並行して動作します。

• Connect Sync は、これまでどおりディレクトリ ID と属性を同期します。
• Cloud Sync は、Exchange 属性の書き戻しを処理します。

一般提供での変更点

最大 600,000 個のクラウド管理メールボックスをサポート

パブリック プレビュー期間中、書き戻しはクラウド管理メールボックスが 200,000 個未満のテナントをサポートしていました。一般提供では、テナントあたり 600,000 個のクラウド管理メールボックスまでサポートします。

この上限の引き上げにより、大規模な組織でも、オンプレミスの Active Directory で必要な Exchange 属性の値を最新の状態に保ちながら、Exchange 属性をクラウドで管理できるようになります。

mail 属性の書き戻し

パブリック プレビュー期間中に最も多く寄せられた要望の 1 つが、オンプレミスの Active Directory への mail 属性の書き戻しでした。

このフィードバックを受け、一般提供では、サポートされる書き戻し対象に mail 属性を追加しました。Exchange Online で WindowsEmailAddress に加えた変更を、Active Directory の対応する mail 属性へ書き戻せるようになりました。

書き戻しでは、次の属性を含む 24 個の属性がサポートされるようになりました。

• extensionAttribute1 から extensionAttribute15
• msExchExtensionCustomAttribute1 から msExchExtensionCustomAttribute5
• msExchRecipientDisplayType
• msExchRecipientTypeDetails
• proxyAddresses
• mail

属性の完全な一覧は、ID、Exchange 属性、および書き戻しをご確認ください。

既存のパブリック プレビュー構成では 1 つの更新が必要

2026 年 8 月 3 日以降に作成された Exchange 属性の書き戻し構成では、mail 属性の書き戻しが既定で有効になります。新たに作成された構成では、追加の操作は必要ありません。

2026 年 8 月 3 日より前に作成された構成は、mail 属性を書き戻すように自動更新されません。パブリック プレビュー期間中に書き戻しを有効にした場合は、次の手順を実行してください。

1. Microsoft Entra 管理センターで、Exchange Online 属性の書き戻し構成を開きます。
2. [属性マッピング] を選択し、[既定のマッピングに戻す] を選択します。
3. 同期ジョブが再起動すると、mail 属性の書き戻しが有効になります。

詳しい手順は、ドキュメントのよく寄せられる質問をご確認ください。

テナント全体の SOA に関する重要な注意事項

テナント全体の Exchange 属性 SOA は、Exchange Online へのメールボックス移行が完了し、オンプレミスで Exchange メールボックス、メールが有効なユーザー、リモート メールボックスを作成しなくなった組織を対象としています。

オンプレミスのメールボックス移行や受信者の作成を続けている間は、テナント全体の SOA を有効にしないでください。有効にすると、新しく同期された Exchange 受信者が、Exchange Online で必要な MailUser を持たない ID のみのユーザーとして Microsoft Entra ID に表示される場合があります。その結果、メールボックスのオンボーディングと移行がブロックされます。

テナント全体の SOA を有効にする前に、ハイブリッド環境でのリモート メールボックスの Exchange 属性のクラウド ベースの管理に記載されている前提条件とガイダンスをご確認ください。

最後の Exchange Server の廃止に向けて

Exchange 属性のクラウド管理と書き戻しを利用すると、ID の管理に Active Directory を引き続き使用しながら、受信者管理におけるオンプレミスの Exchange Server への依存を解消できます。

サーバーを廃止する準備ができたら、SOA をクラウドへ移した後に最後の Exchange Server を廃止するの手順に従ってください。このガイドでは、前提条件、ハイブリッド構成のクリーンアップ、Exchange Server のアンインストール、アンインストール後の Exchange Online のクリーンアップについて説明しています。

Exchange 属性の SOA は、Exchange Online メールボックスを持つユーザー オブジェクトに適用されます。メールが有効なグループやメール連絡先をクラウドから管理する場合は、グループ SOA または連絡先 SOA の移行を使用してください。

始めるには

• ハイブリッド環境でのリモート メールボックスの Exchange 属性のクラウド ベースの管理を確認する。
• Exchange 属性の書き戻しを有効にする方法に従って構成する。
• 書き戻し属性の完全な一覧を確認する。
• 最後の Exchange Server の廃止ガイドを読む。

パブリック プレビューに参加し、フィードバックをお寄せくださった皆さまに感謝します。皆さまのご意見を受けて、一般提供では mail 属性の書き戻しを追加しました。

一般提供版を利用した感想を伺えることを楽しみにしています。

ここ数週間、2026 年 10 月以降も Exchange Server 2016/2019 の ESU プログラムが延長される可能性について、いくつか質問をいただいています。

実際、Exchange 2016 / 2019 向け拡張セキュリティ更新プログラムを発表 では延長はないとお伝えしていましたが、その後 2026 年 10 月に終了予定の Exchange Server 2016/2019 向け ESU プログラム 第 2 期 提供開始のお知らせ を新たに提供することとなりました。

現在は、第 2 期 Exchange ESU の中間地点を迎えようとしている状況です。
Exchange 2016/2019 ESU プログラムが、これ以上延長される予定はありません。 2026 年 10 月の終了をもって、現在第 2 期 ESU を契約いただいている場合でも、Exchange Server 2016/2019 向けの追加の更新プログラムは提供されません。

Exchange Server 2016 または 2019 を本番環境で引き続き利用している場合は、以下の情報を確認してください。

• 現行バージョンから Exchange Server SE へのアップグレード
  オンプレミス Exchange を継続利用する予定の場合に、Exchange Server SE への移行手順を説明しています。
• Exchange 2019 から Exchange SE への “インプレース アップグレード” が低リスクである理由
  Exchange 2019 CU14/CU15 から Exchange SE RTM へのインプレース アップグレードが、大きな技術的変更を伴わず、リスクの低い移行である理由について説明しています。

また、Exchange licensing FAQs の “What is Exchange Server Subscription Edition (SE) and how is it licensed?” セクションも確認してください。Exchange Server 2019 と Exchange Server SE のライセンス要件は同じです。

Microsoft は、以下の製品に存在する脆弱性に対応するセキュリティ更新プログラム (SU) をリリースしました。

• Exchange Server Subscription Edition (SE)
• Exchange Server 2019
• Exchange Server 2016

以下の Exchange Server のバージョン向けに SU が提供されています。

• Exchange SE RTM
• Exchange Server 2019 CU14 および CU15 (アクセスするには、第 2 期 ESU プログラム の登録が必要)
• Exchange Server 2016 CU23 (アクセスするには、第 2 期 ESU プログラム の登録が必要)

2026 年 7 月のセキュリティ更新プログラム (SU) は、セキュリティ パートナーから責任を持って報告された脆弱性や、Microsoft の内部プロセスによって発見された脆弱性に対応しています。

これらの脆弱性は Exchange Server に影響します。Exchange Online のお客様は、今回のセキュリティ更新プログラムで対応された脆弱性について既に保護されていますので、特別な対応は不要です。ただし、環境内に存在する Exchange サーバーや Exchange 管理ツールをインストールしたワークステーションについては、引き続き更新プログラムの適用を行ってください。

特定の脆弱性 (CVE) に関する詳細は、Security Update Guide (Exchange SE については Product Family で “Server Software” でフィルター、Exchange Server 2016 および 2019 については Product Family で “ESU” でフィルター) を参照してください。

レガシー Exchange セキュリティ グループの存在確認

今回の 2026 年 7 月の SU リリースと直接関係ありませんが、Exchange Health Checker スクリプト で、非常に古く既に非推奨となっている Exchange Server のセキュリティ グループである Exchange Domain Servers と Exchange Enterprise Servers の存在有無も確認できるようになりました。これらのグループは Exchange Server 2007 以降で非推奨となっており、現在は使用されるべきではありません。また、最新の Exchange セキュリティ グループよりも広範な権限を持つ可能性があるため、存在する場合は削除することを推奨します。関連ドキュメントはこちら を参照してください。

また、既にオンプレミスの Exchange Server をすべて廃止している環境についても、これらのグループが残っていないか確認し、存在する場合は削除することで、不正利用のリスク低減につながります。さらに、オンプレミスの Exchange Server を完全に廃止している環境では、これらのグループの削除に加え、関連する Active Directory オブジェクトのクリーンアップも実施することをお勧めします。詳細は、こちらの記事 を確認してください。

CVE-2026-42897 の緩和策の削除について

2026 年 7 月の更新プログラムをインストールしても、既に適用済みの CVE-2026-42897 緩和策は自動的には削除されません。そのため、7 月の SU をインストールした後は、適用方法に応じて以下の対応を実施してください。

Exchange Emergency Mitigation (EM) Service を使用して緩和策を適用していた場合:

• 緩和策 M2.1.0 の IIS ルールを削除 します。

ダウンロード可能な EOMT スクリプト https://aka.ms/UnifiedEOMT を使用して緩和策を適用していた場合:

• 緩和策をロール バック します。

Exchange 2016 および 2019 の更新プログラムは第 2 期 ESU プログラムでのみ提供されています

Exchange Server 2016 および 2019 はサポートが終了 しています。2026 年 5 月から 10 月までの間にリリースされる Exchange Server 2016 および 2019 のセキュリティ更新プログラムを入手できるのは、第 2 期 Extended Security Update (ESU) プログラム に登録しているお客様のみです。

第 2 期 ESU プログラムに参加していない場合は、Exchange Server Subscription Edition (SE) に移行 して、最新のセキュリティ更新プログラムを引き続き受け取ってください。

既に第 2 期 ESU を購入済みで、最新のセキュリティ更新プログラムへのアクセスに関する情報が必要な場合は、ExchangeandSfBServerESUInquiry@service.microsoft.com にメールを送信してお問い合わせください。

このリリースの既知の問題

• Wrapper messages appear in shared mailbox inbox in hybrid environments | Microsoft Support

更新プログラムのインストール

利用可能な更新パスは以下の通りです。

• Exchange Server Health Checker スクリプト を使用して、更新が必要な Exchange サーバーのインベントリを作成し、各サーバーの更新状況 (CU、SU、手動対応) を確認してください。
• 最新の CU をインストールします。Exchange Update Wizard を利用して、現在の CU と目標 CU を選択し、手順を確認してください。
• 更新プログラムのインストール後に再度 Health Checker を実行し、追加の対応が必要かどうかを確認します。
• セットアップ完了後、サーバーを再起動し、すべての Exchange サービスが正常に起動したことを確認します。一部のサービスが無効状態になっている場合は、更新プログラムのインストールが何らかの理由で中断されたことを示しています。詳細については、この記事 の「回避策 1」を参照してください。
• Exchange Server のインストール中やインストール後にエラーが発生した場合は、SetupAssist スクリプト を実行してください。更新後に問題が発生した場合は、失敗した Exchange Server の更新プログラムの修復方法や、Exchange Server の更新プログラムをインストールしようとしたときのファイル バージョン エラー も確認してください。

よくあるご質問

CVE-2026-42897 の緩和策がリリースされたとき、いくつかの既知の問題が報告されていました。この更新プログラムではそれらは解決されていますか？
はい。2026 年 7 月の SU をインストールし、緩和策を削除すると、緩和策による既知の問題も解決されます。

一部のサーバーを更新したものの、他のサーバーを更新できない場合、更新できないサーバーでは CVE-2026-42897 の緩和策を有効にしたままにできますか？更新済みのサーバーと、緩和策を利用したままのサーバーが混在していても問題ありませんか？
2026 年 7 月の SU 以降に更新できないサーバーでは、緩和策を引き続き利用できます。ただし、そのサーバーでは緩和策による既知の問題も引き続き発生します。また、この更新プログラムを適用した後、組織内のすべての Exchange サーバーが更新されるまで、Office Online Server (OOS) と Exchange Server の統合が期待通りに機能しない場合があります。

弊社の環境は Exchange Online とのハイブリッド構成ですが、対応は必要ですか？
Exchange Online は既に保護されていますが、管理目的のみで利用している場合も含め、オンプレミスの Exchange サーバーには今回のセキュリティ更新プログラム (SU) を必ずインストールしてください。SU 適用後に認証証明書を変更する場合は、ハイブリッド構成ウィザードを再実行する必要があります。

最後にインストールした SU/HU は数か月前のものですが、最新の SU をインストールするためにすべての SU を順番に適用する必要がありますか？
すべての SU は累積的です。サポートされている CU を使用している場合、すべての SU や HU を順番にインストールする必要はなく、最新の SU を適用するだけで問題ありません。詳細はこちらのブログ記事 を確認してください。

組織内のすべての Exchange Server に SU をインストールする必要がありますか？”Exchange 管理ツールのみ” インストールされたマシンはどうなりますか？
すべての Exchange Server および Exchange 管理ツールがインストールされたすべてのサーバー / ワークステーションに SU を適用することを推奨します。これにより、管理ツールのクライアントとサーバー間の互換性が確保されます。稼働中の Exchange Server が存在しない環境で Exchange 管理ツールのみを更新する場合は、こちら を確認してください。

弊社は Exchange 2016 および 2019 の第 2 期 ESU を登録していません。現在の Exchange 2016 または 2019 の更新プログラムを入手するにはどうすればよいですか？
Exchange 2016 および 2019 は現在サポートが終了 しているため、第 2 期 ESU プログラム に登録しているお客様 (2026 年 5 月から 10 月まで有効) のみが、2026 年 5 月以降にリリースされる Exchange 2016 または 2019 の更新プログラムを入手できます。Exchange 2016 または 2019 を引き続き利用しているすべてのお客様には、できるだけ早く Exchange SE にアップグレード することを推奨します。

本記事公開時点では、関連するドキュメントが完全には利用できない場合があります。

この記事は今後更新される可能性があります。更新があればここに記載します。

2023 年 4 月にクラウドベースのメッセージの取り消し機能をリリースしてから (参考: Cloud-based Message Recall in Exchange Online)、メッセージの取り消し機能を利用できる範囲や方法の拡張を進めてきました。これには、Outlook on the web と Outlook モバイルのサポート、受信者への取り消し通知、取り消し可能なメッセージの最大経過日数、さらに外部ラウンドトリップ ルーティングへの対応が含まれます (参考: Exchange Online Message Recall Updates)。

ただし、これまでは 1 つの制約がありました。これは、メッセージの取り消し機能は同一テナント内でしか機能しなかった点です。今回、多くの要望をいただいていたクロステナント組織の強化として、次の機能を発表します。

• クロステナント メッセージ取り消し機能 (テナント管理者が許可リストに登録した組織間での利用)

同一テナントという制約

メッセージの取り消し機能は、プライバシー保護の観点から Exchange Online のサービス範囲内で動作するよう設計されています。そのため、これまでは送信者と受信者が同じ Microsoft 365 テナントに所属している場合のみ利用可能でした。受信者が別のテナントに所属している場合は、たとえ組織間で密接な連携や信頼関係があったとしても、送信したメッセージを取り消すことはできませんでした。

この制限については、多くのお客様から機能上の課題としてご意見をいただいていました。パートナー企業や子会社、関連会社など、異なるテナント間で日常的に共同作業を行っている環境でも、自社テナントの場合と同様にメッセージの取り消しができるようにしてほしいという要望が寄せられていました。

クロステナントにおけるメッセージの取り消しの概要

クロステナントにおけるメッセージの取り消しでは、テナント管理者が他の Microsoft 365 テナントを許可リストに追加できます。許可リストに登録されたテナントから送信されたメッセージは、受信側テナントに対して同一テナント内と同じように取り消しを実行できます。

制御の主体は 受信側テナント (メッセージを受け取る組織) です。クロステナントでのメッセージの取り消しは、受信側テナントの管理者が送信側テナントを明示的に許可リストへ登録している場合にのみ実行されます。これにより、受信側組織は自組織のユーザー メールボックスに対して、どの外部テナントからのメッセージの取り消しを許可するかを完全に管理できます。この機能は既定では無効になっており、管理者が 1 つ以上のテナントを許可リストへ追加するまで、クロステナントでのメッセージの取り消しは実行されません。

動作イメージ

Microsoft 365 を利用している Contoso と Fabrikam という 2 つの組織が連携している例で説明します。

1. Contoso の管理者が、Fabrikam のテナントをクロステナント メッセージの取り消し許可リストに追加します。
2. Fabrikam のユーザーが、Contoso のユーザー宛てに送信したメッセージの取り消しを実行します。
3. Contoso 側で Fabrikam が許可リストに登録されているため、メッセージの取り消し要求が同一テナント内での取り消しと同様に処理されます。

一方で、Fabrikam が Contoso の許可リストに登録されていない場合、メッセージの取り消しは失敗します。Fabrikam の送信者は、取り消し状態レポートで「組織間では取り消せない」ことを確認できます。許可リストは受信側テナントに対する取り消し要求を制御する仕組みであり、どの外部テナントを信頼するかは各組織が独自に判断します。

Exchange Online PowerShell での設定

管理者は Exchange Online PowerShell を使用して、クロステナント メッセージの取り消しに関する設定を構成できます。

テナントでクロステナント メッセージ取り消しを有効化または無効化するには、次のパラメーターを設定します。$True で有効、$False (既定値) で無効です。

1

Set-CrossTenantRecallConfiguration -CrossTenantRecallEnabled [$true | $false]

許可リストに追加または削除する外部テナントを指定するには、取り消しを許可する組織のテナント ID を設定します。

1

Set-CrossTenantRecallConfiguration -AllowedSenderTenantIds @{Add="<tenantId 1>","<tenantId 2>"}; {Remove="<tenantId 1>","<tenantId 2>"} 

送信者と受信者に見える動作

許可リストに登録されたテナントの送信者がメッセージを取り消すと、受信側テナントの受信者には同一テナント内取り消しと同様に取り消しが反映されます。受信側テナントで受信者向けのメッセージの取り消し通知が有効化されている場合、クロステナントのメッセージの取り消しにも同じ通知が適用されます。送信側テナントが受信側の許可リストに登録されていない場合は、送信者には「組織間では取り消せない」旨の通知が返されます。

提供時期

クロステナントにおけるメッセージの取り消し機能は、Worldwide、GCC、GCC High、DoD、Microsoft 365 operated by 21Vianet に対して、8 月中旬から展開を開始し、9 月中旬までに完了する予定です。
ぜひご活用いただき、フィードバックをお寄せください。

Exchange Server の今後のアップデートで、OWA Light を廃止・無効化する計画をお知らせします。OWA Light は、ブラウザーのサポート状況、ネットワーク帯域、アクセシビリティ技術が現在とは大きく異なっていた Web の黎明期に作られました。今後は、ブラウザー間の互換性、アクセシビリティ、セキュリティを重視した最新の Outlook on the web の機能向上に投資していきます。

現在も OWA Light を利用している場合は、標準の Outlook on the web へ移行するとともに、OWA Light について記載されている社内ガイド、ブックマーク、トレーニング資料、ヘルプデスク向けのサポート手順や案内文、アクセシビリティ対応の運用手順を見直す必要があります。

OWA Light の画面は以下のとおりです。

変更内容

今後提供予定の Exchange Server の更新プログラム（2026 年 8 月頃を予定）において、OWA Light を無効化し、廃止する予定です。この変更が適用されると、ユーザーは OWA Light を選択したり OWA Light にリダイレクトされたりすることはできなくなり、代わりに最新の Outlook on the web を使用することになります。

本お知らせは、Exchange Server (オンプレミス環境) を対象としています。OWA Light の廃止については、2024 年 8 月にも発表しています。

変更の理由

OWA Light は長年にわたり多くの利用者に活用されてきました。古いブラウザーや低速な回線環境、フル機能の Outlook Web App を利用できない環境でメールにアクセスするために、シンプルな Web インターフェイスとして設計されました。

従来の OWA Light を別途維持することは、システムの複雑さを増す要因となります。最新の Web の脅威に対する防御を強化する際、コンテンツのレンダリング パス、操作画面、互換性レイヤーなど、各要素について評価と保守が必要です。

Exchange Server の管理者は、この機会に OWA Light に依存しているユーザー、運用プロセス、ドキュメントを特定し、移行に向けた準備を進めることをお勧めします。

OWA Light を今すぐブロックするには、OWA メールボックスポリシーを作成または既存のものを更新します。

1

Set-OwaMailboxPolicy -OwaLightEnabled $false

OwaMailboxPolicy がすべてのメールボックスに割り当てられていることを確認してください。OwaMailboxPolicy の割り当てには Set-CasMailbox -OwaMailboxPolicy <Name> コマンドレットを使用します。

さらに、OWA ログオン ページの OWA Light 選択メニューを無効にします。以下のコマンドを実行してください。

1

Set-OwaVirtualDirectory -LogonPageLightSelectionEnabled $false

詳細は、Set-OwaMailboxPolicy および Set-OwaVirtualDirectory のドキュメントを参照してください。

まとめ

OWA Light は、Web がそれを必要としていた時代に重要な役割を果たしてきました。現在では、標準の Outlook on the web エクスペリエンスこそが注力すべきプラットフォームです。OWA Light を廃止することで、レガシー機能の維持に伴う負担を軽減し、継続的なエンジニアリング作業を簡素化するとともに、ユーザー体験のさらなる向上を実現していきます。

Outlook アドイン向け Outlook アドイン API 要件セット 1.16 が一般提供になりました。今回のリリースは、メッセージと情報のセキュリティ強化に注力するとともに、COM/VSTO アドインと Web アドインの機能ギャップを埋めるための継続的な取り組みを反映しています。

Mailbox 1.16 では、以下の API とプラットフォームの更新が導入されています。

• イベント ベースのワークフローで、保護されたメッセージや添付ファイルを復号できる。
• 組織内で Exchange Web Services (EWS) トークンがサポートされているかどうかを確認できる。
• メール アイテム内のインライン添付ファイルを簡単に識別できる。
• メール アイテムから、従来より多くの受信者情報を取得できる。
• SessionData の保存容量が拡張され、セッション中により多くのデータを保持できる。

メッセージの復号を簡単に実装

Outlook アドイン API 要件セット 1.16 では、新たに OnMessageDecrypt イベントが追加されました。これにより、ユーザーが保護されたメッセージを開いたときに、Outlook アドインは自動的に復号できます。イベント ベースのワークフローは、暗号化されたメッセージの識別、メッセージの復号、復号後コンテンツの表示、必要に応じたエラー通知の表示までを処理します。このワークフローが処理に必要な一連の操作を担うため、開発者はアドイン内では組織のセキュリティ要件を満たす暗号化および復号化プロトコルの定義と実装に集中できます。

アドインでの復号機能を実装する方法について詳しくは、暗号化 Outlook アドインを作成する を参照してください。また、復号アドインのサンプルを実際に試す場合は、Outlook でメッセージを暗号化および復号するサンプル をご利用ください。

組織内での EWS トークン対応状況を確認

Exchange Online 環境では EWS トークンは既に無効化されていますが、一部の組織では引き続きオンプレミス環境を運用しています。Office.context.mailbox.diagnostics.ews.getTokenStatusAsync API の導入により、アドインは組織内で EWS コールバック トークンがサポートされているかどうかを判定できるようになりました。これにより、利用可能な環境では推奨される認証方式を使用しながら、必要に応じて従来環境との互換性も維持することができます。

データ損失防止とコンテンツ処理ワークフローを強化

Mailbox 1.16 では、データ損失防止とコンテンツ処理のシナリオをサポートするために、既存 API も強化されています。

• contentId プロパティによって添付ファイル API が拡張され、コンテンツ検査やレンダリングのワークフローで、メール アイテム内のインライン添付ファイルを簡単に識別できるようになります。
• Recipients API の getAsync メソッドは、メール アイテム内の任意の受信者フィールドから最大 1,000 件の受信者を返せるようになりました。この上限の拡張により、データ損失防止ソリューションは、より多くの受信者を 1 回の処理で評価できるようになります。
• SessionData オブジェクトは、アドインごとに最大 2,621,440 文字までサポートするようになりました。これにより、アドインは一つのセッション内で、より多くのデータをシームレスに保存および取得できるようになります。

ぜひ Outlook アドインで新しい Mailbox 1.16 の新機能をご活用ください。Happy coding!

こんにちは。日本マイクロソフト Exchange & Outlook サポート チームの阿部 (アベ) です。

Outlook のテンプレート運用に関するお問い合わせの中で、「MSG ファイルと OFT ファイルの違いは何か」「新しい Outlook ではどのように定型メールを運用するべきか」といった質問をいただくことがあります。

特に従来の Outlook for Windows (従来の Outlook) を利用していた環境では、MSG ファイルをテンプレート代わりに配布していたケースも見られます。一方で、新しい Outlook for Windows (新しい Outlook) への移行を検討する際には、それぞれの形式の目的や役割を理解しておくことが重要です。

この記事では、MSG と OFT の違いを整理しながら、新しい Outlook で利用できるテンプレート機能について紹介します。

はじめに

メール本文や件名などの定型情報を再利用したい場合は、用途に応じて適切な仕組みを選択することが重要です。

• MSG はメッセージの保存に適した形式
• OFT はテンプレート用途向けに設計された形式
• 新しい Outlook では Outlook on the web と共通のテンプレート機能を利用できる
• メール作成を効率化する目的では、OFT やテンプレート機能の利用が選択肢となる

重要なのは、「メールを保存すること」と「新しいメールを作成すること」を区別して考えることです。

MSG ファイルとは

MSG は Outlook メッセージを保存するための形式です。
受信メールや送信済みメールを保存したり、特定のメールをエクスポートしたりする用途で利用されます。
MSG ファイルには本文や添付ファイルだけではなく、メッセージを構成するさまざまな MAPI プロパティも保存されます。

例えば以下のようなプロパティが含まれる場合があります。

• PR_ENTRYID
• PR_SEARCH_KEY
• PR_CONVERSATION_INDEX
• PR_CLIENT_SUBMIT_TIME
• PR_MESSAGE_DELIVERY_TIME

また、Internet Message ID や会話スレッドに関連する属性など、メッセージ固有の情報が保持される場合もあります。

このような特性から、MSG は「作成済みのメッセージを保持するための形式」と考えることができます。

OFT ファイルとは

OFT (Outlook Form Template) は Outlook がテンプレート用途のために提供している形式です。
利用者が OFT ファイルを開くと、新しいメール アイテムとして作成されるため、定型文を繰り返し利用するシナリオに適しています。

例えば以下のような用途が考えられます。

• 障害通知
• メンテナンス通知
• 問い合わせ回答
• 変更作業案内
• 運用手順に基づく定型メール

従来の Outlook においてテンプレートを共有する場合、OFT はテンプレート利用を前提として設計された仕組みといえます。

テンプレート運用で考慮したい MSG と OFT の違い

MSG と OFT はどちらも Outlook で利用できるファイル形式ですが、その設計目的は異なります。
MSG は既存のメッセージを保存することを目的としており、メッセージ固有の各種プロパティを保持できます。
一方、OFT は新しいメッセージを作成するためのテンプレートとして設計されています。
この違いを理解しておくと、運用方針を検討しやすくなります。

例えば以下のように整理できます。

もちろん、MSG ファイルを開いて内容を編集し、新しいメールとして利用することもできます。
しかし、MSG は保存済みメッセージを保持することを目的とした形式であり、メッセージ固有のプロパティが含まれる場合があります。一方で、OFT やテンプレート機能は定型メールの再利用を目的として設計されています。
定型文を組織内で共有するシナリオなどでは、これらの機能を活用することで、テンプレートとして管理しやすい運用を実現できます。

そのため、定型メールの運用を検討する際には、利用シナリオに適した機能を選択することが重要です。

新しい Outlook のテンプレート機能

新しい Outlook は Outlook on the web と共通の基盤を利用しています。
そのため、従来の Outlook で利用されてきた OFT ベースの運用とは異なるアプローチが採用されています。
新しい Outlook では Outlook on the web と共通のテンプレート機能を利用できます。

この機能を利用することで、例えば以下のような定型文を登録できます。

• 問い合わせ回答
• 障害通知
• 作業完了連絡
• メンテナンス案内
• 各種通知メール

繰り返し利用する文章をテンプレートとして管理できるため、日常的なメール作成を効率化できます。
また、Outlook on the web と新しい Outlook の間で共通の操作性が提供されるため、クライアントごとの差異を意識する場面も少なくなります。

テンプレート機能の利用方法や活用シナリオについては、以下の記事で詳しく紹介しています。

• 新しい Outlook for Windows のメール テンプレート機能の紹介

新しい Outlook への移行を検討している場合は、従来のテンプレート運用を見直すきっかけとして、こちらの機能も併せて確認することをお勧めします。

従来の Outlook と新しい Outlook の違い

テンプレートに関する観点で整理すると、次のようになります。

新しい Outlook への移行を検討する場合は、従来の OFT ベースの運用をそのまま移行するのではなく、現在利用可能なテンプレート機能も選択肢として検討できます。

まとめ

MSG と OFT は似た用途で語られることがありますが、それぞれ異なる目的で設計されています。

• MSG はメッセージ保存形式
• OFT はテンプレート用途向けの形式
• 新しい Outlook では Outlook on the web と共通のテンプレート機能を利用できる
• メール作成を効率化する際は、用途に応じたテンプレート機能の利用を検討できる

テンプレート運用を検討する際は、「保存済みのメッセージを保持したいのか」「新しいメールを効率的に作成したいのか」を切り分けて考えることがポイントです。

MSG、OFT、テンプレート機能はそれぞれ異なる目的で設計されています。利用シナリオに応じて適切な機能を選択することで、より管理しやすく分かりやすい運用につながります。

Exchange Online における Exchange Web Services (EWS) の廃止は、最終フェーズに入りつつあります。過去数年にわたり、Microsoft は製品チーム、独立系ソフトウェア ベンダー (ISV)、エコシステム全体のお客様と協力し、ワークロードを Microsoft Graph やその他のモダン API へ移行してきました。多くの移行は完了しており、その他の移行も順調に進んでいます。

Exchange Online で EWS の段階的な無効化が始まる 2026 年 10 月が近づく中、管理者が制御しやすく、予測しやすい形で準備を進められるようにするため、新しい機能 EWSAllowedAppIDs を導入します。これは、Exchange Online EWS: 廃止期限が迫っています でお知らせした許可リスト機能です。

EWSAllowedAppIDs は、管理者が残っている依存関係を把握し、承認済みアプリケーションだけに EWS アクセスを制限し、廃止の適用が始まる際の中断リスクを減らすための実用的な手段になります。

この機能は現在ロールアウトを開始しています。すべてのテナントで Get-OrganizationConfig を実行した際にパラメーターを確認できるはずですが、ロールアウトが対象テナントに到達するまではリストを設定できません。

EWSAllowedAppIDs とは

EWSAllowedAppIDs はテナント レベルの許可リストです。Exchange Online 管理者は、App ID に基づいて、EWS へのアクセスを引き続き許可するアプリケーションを明示的に定義できます。

構成すると、テナント レベルの EWSEnabled が True に設定されている場合、許可リストに App ID が含まれているアプリケーションだけが、そのテナントで EWS を引き続き使用できます。

この機能は、広範で制限のない EWS アクセスから、廃止期間中に厳密に範囲を絞った意図的な利用へ移行する最終段階を支援するために設計されています。

注: Exchange で長年提供されてきた EWSAllowList 機能は、App ID ではなく User Agent に基づきます。なお、EWS だけでなく REST/Graph にも適用されます。両方を併用できますが、それぞれ呼び出し元アプリケーションの異なる情報を基準に動作します。

管理者は、この機能を使用して次のことができます。

• EWS を引き続き必要とするアプリケーションを特定する
• 承認済みアプリケーションだけに EWS アクセスを制限する
• Exchange Online における EWS の最終的な廃止に備える

EWSAllowedAppIDs が EWS の最終段階にどう関係するか

以前に、Exchange Online で EWS の段階的な無効化を 2026 年 10 月に開始するとお知らせしました。

EWSAllowedAppIDs が重要な理由を理解するには、この日付の前後で Exchange Online の動作がどのように変わるかを見るとわかりやすくなります。廃止モデルでは、既存の組織レベル設定 EWSEnabled と、新しい EWSAllowedAppIDs 許可リストを組み合わせて使用します。(EWSEnabled スイッチの動作と設定方法については、こちら をご確認ください)

2026 年 10 月より前は、依存関係の棚卸し、許可リストの展開、EWS を引き続き必要とするアプリケーションの検証を行う時間を確保するため、意図的に許容的な動作になっています。

2026 年 10 月より前:

この 10 月より前の期間により、管理者は既存のアプリケーションをすぐに停止させることなく、許可リストを展開してテストできます。

2026 年 10 月に何が変わるか

2026 年 10 月以降、Exchange Online はテナントを廃止適用の動作へ移行し始めます。

この時点以降、許可リストを構成せずに EWS を有効化しても、制限なしで「すべてを許可する」モードとしては動作しなくなります。

2026 年 10 月以降:

これは管理者が理解しておくべき最も重要な動作変更です。適用開始後は、許可リストなしで EWSEnabled=True を設定すると、実質的にすべてをブロックする構成になります。

この変更は意図的なものです。目的は EWS を無期限に利用できるようにすることではなく、EWS がまだ必要であることの明示的な確認を求め、その利用を既知の承認済みアプリケーションに絞ることです。

廃止プロセスの目的は、単に EWS を無期限に「オン」のままにすることではなく、次のことにあります。

1. EWS がまだ必要であることの明示的な確認を必須にする
2. 利用範囲を既知の承認済みアプリケーションに絞る
3. Microsoft Graph とモダン API への移行を加速する

テナント管理者が何もしない場合

現在、多くのテナントでは EWSEnabled が未設定 (Null) のままになっており、この状態では制限のないアクセスとして動作します。

2026 年 10 月に段階的な廃止ロールアウトが始まると、これらのテナントでは段階的な停止プロセスの一環として EWS が無効化されます (EWSEnabled が False に設定されます)。

その時点で EWS がまだ必要な管理者は、明示的な対応を行う必要があります。

推奨される流れは次の通りです。

1. EWSAllowedAppIDs 許可リストを構成または検証する (9 月に、未構成のテナント向けにこのリストを設定するとお伝えしています。詳細はこちらをご確認ください。ただし、正しい内容であることを確認する責任は管理者にあります)。
2. EWSEnabled=True を設定する

この作業を事前に完了している組織では、より広範な廃止ロールアウト中に中断が発生する可能性を大きく減らせます。

この機能を今有効化することを強く推奨する理由

EWSAllowedAppIDs は 2026 年 10 月だけを目的とした機能だと考えるべきではありません。この機能の最大の価値は、適用が始まる前の準備期間にあります。

許可リストを今展開して検証することで、管理者は未知の依存関係を見つけ、不要になったアプリケーションを削除し、まだ EWS に依存しているベンダーと調整を始め、Microsoft Graph への移行を始める時間を確保できます。

• 未知の EWS 依存関係を検出する
• 不要になったアプリケーションを削除する
• まだ EWS を必要としているベンダーに連絡する
• Microsoft Graph API への移行を始める
• 例外が本当に必要なアプリケーションを検証する
• 将来のサポート エスカレーションやサービス停止を減らす

段階的な無効化の影響を受け始めてから対応する管理者は、修復に使える時間がかなり短くなり、中断が発生する可能性も大幅に高くなります。

管理者向けの推奨される次の手順

Exchange Online 管理者には、今すぐ次の作業を始めることを強く推奨します。

EWS の利用状況を棚卸しする

組織内で現在 EWS を使用しているすべてのアプリケーションとサービスを特定します。テナントで利用可能な場合は EWS 使用状況レポートを使用し、テナントの使用状況をまとめたメッセージ センターの投稿も確認します。詳しくは、現場レポート: EWS 廃止前に行う EWS アプリ利用状況の確認と対策 をご確認ください。

許可リストを作成する

EWS を引き続き必要とすることがわかっているアプリケーションだけを含む EWSAllowedAppIDs 許可リストを作成します。これには、Office や Power Query for Excel など、Microsoft のファースト パーティ製クライアント アプリが含まれます。使用状況レポートにアプリケーションが表示され、引き続き使用する場合は、そのアプリケーションをリストに追加する必要があります。

管理者が許可したいアプリケーションを既に把握している場合は、1 つ以上の App ID を指定して、新しい許可リストを直接作成できます。

例:

1

Set-OrganizationConfig -EwsAllowedAppIDs "11111111-2222-3333-4444-555555555555,aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee"

このコマンドは、現在の値を指定した承認済みアプリケーションのセットに置き換えます。

値を設定した後、管理者は次のコマンドで構成済みのリストを確認できます。

1

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsAllowedAppIDs

RetrieveEwsOperationAccessPolicy の使用はパフォーマンス上の理由で必要です。このリストは、管理者が明示的に要求した場合にのみ取得するようにしています。

このリストへの変更が反映されるまでに、最大 24 時間かかる場合があります。パフォーマンス上の理由から、サーバーはメモリ内のキャッシュを 24 時間ごとにのみ更新します。

このプロパティを設定すると、リスト全体の値が書き込まれる点に注意してください。プロパティに既に App ID が含まれている場合、新しいコマンドに含めない限り、それらは置き換えられます。この点については次の例も参照してください。

徹底的にテストする

許可リストに含めたすべてのアプリケーションが期待通りに動作し続けることを検証し、見落とした依存関係がないか確認します。App ID を追加または削除する必要がある場合は、現在のリストを読み取り、更新後のリストを計算してから、値全体を書き戻す必要があります。現時点では、このコマンドレットは 1 件ずつ追加または削除する操作をサポートしていません。

リストを更新する 2 つの例を示します。

例: 新しい App ID を追加する

一般的なパターンは、現在のリストを読み取り、新しい App ID を追加してから、結合したリスト全体を書き戻す方法です。

1
2
3
4
5
6
7
8

# 現在の許可リストを読み取る
$current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs)
# 追加する新しい App ID を定義する
$newAppId = "99999999-8888-7777-6666-555555555555"
# 既存の値と新しい値を結合する
$updated = @($current, $newAppId)
# 更新後の許可リストを書き戻す
Set-OrganizationConfig -EwsAllowedAppIDs ($updated -join ",")

例: App ID を削除する

現時点では単一項目の削除操作がないため、削除する場合もリスト全体を再計算する必要があります。

1
2
3
4
5
6
7
8
9
10

# 現在の許可リストを読み取る
$current = (Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Select-Object -ExpandProperty EwsAllowedAppIDs)
# 削除する App ID を定義する
$removeAppId = "99999999-8888-7777-6666-555555555555"
# コンマ区切りのリストを個々の App ID に分割する
$appIds = $current -split ","
# 指定した App ID を削除する
$updated = $appIds | Where-Object { $_ -ne $removeAppId }
# 更新後の許可リストを書き戻す
Set-OrganizationConfig -EwsAllowedAppIDs ($updated -join ",")

全体像

EWS は、約 20 年にわたって Exchange エコシステムを支えてきました。

しかし、セキュリティ、信頼性、コンプライアンス、スケーラビリティに関する現在の要件を満たすには、よりモダンな API プラットフォームが必要です。Microsoft Graph は、Exchange Online の大半の連携シナリオにおける長期的な戦略プラットフォームです。

EWSAllowedAppIDs は、EWS からの迅速な移行を促しながらも、最終的な移行を管理しやすく予測しやすいものにするために設計されています。

早めに準備した組織ほど、この移行を円滑に進められます。今のうちに依存関係を棚卸しし、2026 年 10 月より十分前に許可リストを検証しておく管理者は、段階的な廃止が始まったときに中断を避けるうえで、はるかに有利な状況になります。

準備を始めるなら今です。

全体計画、機能差分の対応状況、関連リソースへのリンクに関する最新情報は、Exchange Online における Exchange Web Services の廃止 のページをご確認ください。

この記事の更新履歴:

• 2026/08/06: 組織の関係について追記しました。組織の関係に関連する EWS トラフィックは、許可リストの状態に関係なくブロックされません (MC1447678 関連)。

プッシュ、プル、ストリーミングの各通知タイプをサポートする Exchange Web Services (EWS) の通知フレームワークから Microsoft Graph のサブスクリプション モデルへ移行することは、統合され、ステートレスで、イベント ドリブンなフレームワークへ移行することを意味します。このフレームワークは Exchange データ以外もサポートします。Microsoft Graph では Webhook によって通知が簡素化されますが、EWS のプッシュ、プル、長時間接続という複数のモデルを置き換えるには、アーキテクチャの再設計が必要です。

アプリケーションを移行するには、待機時間を短縮する リッチ通知 (rich notifications) や、安定したアイテム追跡を実現する 不変 ID (immutable IDs) など、Microsoft Graph のモダンな機能を組み込むことができます。移行を成功させるには、単純にイベントを待ち受けるだけではなく、ほぼリアルタイムの変更通知と、整合性を取るための デルタ クエリ (delta queries) を組み合わせるハイブリッド戦略が必要です。また、クラウド ネイティブ環境における厳格な同時実行数と可用性のしきい値にも対応する必要があります。

EWS 通知

アプリケーションでは、EWS 通知として 3 種類の通知を使用できます。それぞれ、待機時間、スケーラビリティ、接続管理の面で異なるトレードオフがあります。

• プッシュ通知: イベントが発生するたびに、Exchange がアプリケーションでホストされているリスナー エンドポイントへ HTTP/HTTPS 要求を送信します。
• プル通知: アプリケーションが定期的に Exchange を呼び出し、新しいイベントがあるかどうかを確認します。
• ストリーミング通知: Exchange への長時間接続 (HTTP GET 経由) を確立し、イベントが発生したときにサーバーからクライアントへイベントをプッシュできるようにします。これにより、公開エンドポイントは不要になります。

Microsoft Graph 変更通知

Microsoft Graph の変更通知は 1 種類のみで、Webhook によって配信されます。これは、サブスクライブしたイベントが発生したときに、アプリケーションでホストされているリスナー エンドポイントへ送信される HTTP POST 要求です。このモデルでは、常時ポーリングを行わずに、ほぼリアルタイムの更新を実現できます。

より高度なシナリオでは、Microsoft Graph は Azure Event Hubs を通じた変更通知の配信もサポートしています。このオプションはエンタープライズ グレードのアプリケーションにより適しており、特に高スループットや分散処理の環境で、セキュリティ、スケーラビリティ、信頼性を高められます。

Microsoft Graph リッチ通知 (rich notifications)

Microsoft Graph リッチ通知を使用すると、変更通知に、そのイベントを発生させたアイテムに関する関連データを含めることができます。リアルタイム通知のシナリオでは、アイテムが届いてからクライアントに通知されるまでの待機時間を短縮でき、新しいメッセージの件名や送信者などの主要な詳細へすぐにアクセスできます。

リッチ通知は、従来の EWS 通知と比べて、特定のユース ケースを簡素化します。リアルタイム通知が主な要件であるアプリケーションでは、リッチ通知によって、アイテム データを取得するための後続の呼び出しを減らせます。

Microsoft Graph におけるプル通知と変更追跡

EWS では、前回の通知以降の変更を取得するために、通知は GetEvents 操作に依存していました。プッシュ通知とプル通知では、サブスクリプション マーカーとして機能するウォーターマークを利用できました。Microsoft Graph では、同等の機能がデルタ クエリによって提供されます。

デルタ クエリを使用すると、アプリケーションは前回のクエリ以降に追加、更新、削除されたデータだけを要求して変更を追跡できます。接続を維持したり、イベントをポーリングしたりする代わりに、Microsoft Graph から返された delta token をアプリケーションで保存し、後続の要求でそれを使用して前回の続きから処理できます。

Microsoft Graph は、以下のリソース タイプに対するデルタ クエリをサポートしています。

• フォルダー: 個別のメール、連絡先、予定表フォルダー。
• アイテム コレクション: メッセージ、連絡先、イベント、to do (タスク)。

予定表データについては、定期的なシリーズが 1 つのマスター イベントとして表される展開されていない定期的なデータを公開するイベント コレクションと、指定した時間範囲内の各回が個別のイベントとして展開される予定表ビューの両方で、デルタ クエリがサポートされます。

不変 ID (Immutable IDs)

Microsoft Graph では、メールボックス アイテムの不変 ID が導入されています。これは EWS には直接対応するものがない機能です。不変 ID は、メッセージ、連絡先、イベントなどのアイテムに対する安定した一意の識別子であり、メールボックス内でそのアイテムが存在している間は一定に保たれます。

EWS や Microsoft Graph の itemId 値は、アイテムがフォルダー間で移動されると変わりますが、不変 ID は変わりません。そのため、アプリケーションが ID を外部に保存している場合でも、メールボックス内でフォルダー移動が発生しても同じアイテムを参照し続けることができます。

不変 ID により、EWS と比べてアプリケーション設計を簡素化できます。EWS では、開発者がアイテム移動操作の後に外部保存されたアイテム識別子を追跡し、更新しなければならないことがよくありました。これは通知でよくあるユース ケースです。不変 ID では、その追加の追跡ロジックが不要になります。その結果、コードはより堅牢になり、保守しやすくなります。

ただし、メールボックス間やメールボックスからアーカイブ ストアへの移動など、メールボックスの境界をまたいでアイテムが移動される場合、不変 ID は無効になります。これは、アイテムに新しい ID が割り当てられるためです。メールボックスとアーカイブ間で移動されるアイテムをアプリケーションで追跡する必要がある場合は、代わりにカスタム拡張プロパティの使用を検討してください。

EWS と Microsoft Graph のサブスクリプションの違い

EWS では、通常、特定のメールボックス フォルダー、またはメールボックス内のすべてのフォルダーに対してサブスクリプションを作成します。

Microsoft Graph では、受信トレイや予定表などの特定のフォルダー タイプ、または messages、contacts、events などのリソース コレクションに対して変更通知サブスクリプションを作成できます。ただし、このモデルは EWS より制約があります。サポートされるフォルダー タイプは少なく、すべてのメールボックス フォルダーに対して同じ粒度を提供するものではありません。

たとえば、メールボックス内のすべてのメール フォルダーを EWS 通知でサブスクライブしている EWS アプリケーションを考えてみます。このアプリケーションでは、新しいメールが届いたことに加えて、メールが処理済みフォルダーへ移動されたことも検出する必要があります。Microsoft Graph では、代わりに /messages コレクションをサブスクライブして、メールボックス全体の通知を受け取ります。

移動を追跡するために、アプリケーションは作成イベントと削除イベントを監視し、parentFolderId を確認してアイテムの場所を判断します。標準のアイテム ID はメッセージがフォルダー間で移動されると変わるため、アプリケーションは不変 ID を使用して、メールボックス全体でアイテムの同一性を関連付けます。その後、アプリケーションはデルタ クエリを使用してこれらの変更の整合性を取り、新しく受信したメッセージと移動されたメッセージを区別できるようにします。

カスタム フォルダーのギャップ

Microsoft Graph サブスクリプションは、すべてのメールボックス フォルダーで機能するわけではありません。カスタム フォルダーや、従来のクライアント機能に関連付けられることが多いフォルダーには、Microsoft Graph の messages、contacts、events、to do エンドポイントからアクセスできません。カスタム フォルダーについては、Exchange の外部で代替ソリューションを見つけるか、Webhook を利用できる messages などのサポート対象エンドポイントへコンテンツを移行できます。

ストリーミング サブスクリプションのギャップ

Microsoft Graph は EWS のストリーミング サブスクリプション モデルに相当する機能を提供していないため、ストリーミング通知を使用しているアプリケーションでは、通常、アーキテクチャの再設計が必要です。長時間接続を維持する代わりに、Microsoft Graph は Webhook ベースの通知に依存します。この通知には、公開アクセス可能なエンドポイントが必要です。

一般的なアプローチは、Microsoft Azure や同等のクラウド プロバイダーなど、安全な公開エンドポイントを公開できる高可用性プラットフォームでアプリケーションをホストすることです。このホスティングにより、信頼性、スケーラビリティ、受信通知の適切な処理を確保できます。モバイルやデスクトップなど、デバイス ベースの通知アプリケーションでは、簡略化された通知を以下のようなモバイル プッシュ サービスに転送するバックエンド処理レイヤーを使用できます。

• Apple Push Notification service (APNs) for iOS
• Firebase Cloud Messaging (FCM) for Android

より大量の通知を扱うシナリオやエンタープライズ シナリオでは、Azure Event Hubs によって、多数の通知を取り込んで処理するための、よりスケーラブルで回復性の高いパターンを利用できます。

ストリーミング サブスクリプションから移行することで、永続的な接続を維持することに伴うセキュリティと運用上のリスクも軽減されます。このアプローチにより、より堅牢でクラウドに適したアーキテクチャになります。

イベント タイプの違い

EWS は Microsoft Graph よりも細かいイベント タイプを提供します。移行時にはこの違いを考慮してください。

アイテムの作成と新しいメールの到着

• EWS: NewMail (受信トレイ固有) または Created (その他のフォルダー)。
• Microsoft Graph: Created (メッセージ、連絡先、イベントで統一)。

Microsoft Graph は専用の NewMail イベントを公開しません。新しいアイテムは単に created として表されます。つまり、created イベントは、新しく配信されたメールを表す場合もあれば、フォルダーへコピーまたは移動されたアイテムを表す場合もあります。

アプリケーションが NewMail 固有の動作に依存している場合は、receivedDateTime や createdDateTime などのメッセージ プロパティを使用して、そのメッセージが配信されたものなのか、単に移動またはコピーされたものなのかを推測する必要があります。

✏️ 変更と更新

• EWS: Modified
• Microsoft Graph: Updated

これらの操作は機能的に同じです。

🗑️ 削除とライフサイクル

• EWS: Deleted、Moved、Copied
• Microsoft Graph: Deleted

Microsoft Graph は、明示的な moved または copied イベント タイプを公開しません。これらの操作を区別することが重要なシナリオでは、アプリケーションはフォルダー間のイベントを関連付け、immutableId を使用して意図を推測する必要があります。

たとえば、メッセージが受信トレイからカスタム フォルダーへ移動されると、Microsoft Graph は受信トレイで delete イベントを、移動先フォルダーで create イベントを生成します。immutableId は同じままであるため、これら 2 つのイベントを関連付けて、操作が移動であると識別できます。

一方、コピー操作では、移動先フォルダーで新しい immutableId を持つ create イベントが発生し、元のフォルダーには対応する削除イベントは発生しません。

これは、移動とコピーの操作が明示的に公開されていた EWS からの変化です。Microsoft Graph では、開発者はイベント パターンと識別子を使用して基になる操作を判断する、より解釈的なアプローチを採用する必要があります。

Tips

サブスクリプションを扱う場合、clientState 値は、GET 要求を使用して特定のサブスクリプションを取得したときにのみ返されます。サブスクリプションを列挙するときには含まれません。この場合、clientState プロパティは常に null です。

スロットリング

EWS と Microsoft Graph では異なるスロットリング モデルが使用されており、サブスクリプションはその違いが重要になる領域の 1 つです。Microsoft Graph では、Exchange によってメールボックスごとに 4 つの同時接続という厳格な制限が適用されます。この制限は、サブスクリプション処理によってトリガーされる要求を含む、すべてのアクティブな要求に適用されます。アプリケーションが大きなアイテムを処理したり、大量のイベントを扱ったりする場合、この制限を超えてスロットリングが発生する可能性があります。

よくある落とし穴は、各通知を独立した作業単位として扱い、それを処理するために並列要求を作成することです。負荷がかかった状態では、同時接続数の制限を超え、待機時間が増え、スロットリングが繰り返される可能性があります。その結果、全体のスループットは向上するどころか低下します。

これらの制約の中で効率的に動作するには、より制御された処理モデルを採用してください。受信イベントをキューに入れ、並列バーストではなく管理されたパイプラインで処理します。同じアイテムに対する複数の作成通知や更新通知など、近いタイミングで発生したイベントをまとめる重複排除ロジックを実装し、冗長な処理を避けてください。

さらに、メールボックスに対して同時に行われる要求が常に 4 つ以下になるように、クライアント側の同時実行制御 (たとえば、制限付きワーカー プールやセマフォ) を適用します。回復性とスループットをさらに高めるには、バックオフを伴う再試行ロジックを組み込み、アイテム全体の取得を繰り返すよりも、デルタ クエリなどの軽量な操作を優先してください。

Webhook エンドポイントのパフォーマンスとスロットリングのしきい値

Microsoft Graph Webhook と EWS プッシュ通知のもう 1 つの重要な違いは、通知エンドポイントのパフォーマンスと可用性がどのように適用されるかです。Microsoft Graph は Webhook の応答性を積極的に監視し、しきい値を超えた場合にバック プレッシャーを適用します。

10 分間のウィンドウ内で、10 秒を超える応答が 10% を超えると、slow state がトリガーされます。この状態になると、Microsoft Graph はすべての新しい通知について、配信前に約 10 秒の遅延を挿入します。リアルタイム通知のシナリオでは、これにより目に見える待機時間が発生し、通知が利用者の期待と同期しなくなる可能性があります。

より深刻な drop state は、同じ 10 分間のウィンドウ内で、10 秒を超える応答が 15% を超えるとトリガーされます。この場合、Microsoft Graph は最大 10 分間、エンドポイントへの新しい通知の配信を一時的に停止します。この期間中に生成された通知は、エンドポイントの回復後に再送されないため、イベントの取りこぼしにつながる可能性があります。

Microsoft Graph Webhook は、リスニング エンドポイントに対して、EWS のプッシュ通知やストリーミング通知よりも厳しいパフォーマンス要件を課します。アプリケーションは受信をすばやく確認応答し、回復性と復旧のためのロジックを組み込む必要があります。通知の取りこぼしや遅延に対応するには、データの一貫性を維持するために、デルタ クエリを使用した整合性確認プロセスが必要です。

Microsoft は、以下の製品に存在する脆弱性に対応するセキュリティ更新プログラム (SU) をリリースしました。

• Exchange Server Subscription Edition (SE)
• Exchange Server 2019
• Exchange Server 2016

以下の Exchange Server のバージョン向けに SU が提供されています。

• Exchange SE RTM
• Exchange Server 2019 CU14 および CU15 (アクセスするには、第 2 期 ESU プログラムの登録が必要)
• Exchange Server 2016 CU23 (アクセスするには、第 2 期 ESU プログラムの登録が必要)

2026 年 6 月のセキュリティ更新プログラム (SU) は、セキュリティ パートナーから責任を持って報告された脆弱性や、Microsoft の内部プロセスによって発見された脆弱性に加え、以前お知らせした CVE-2026-42897 (Exchange Server の 2026 年 5 月の脆弱性 CVE-2026-42897 への対処) に対応しています。

これらの脆弱性は Exchange Server に影響します。Exchange Online のお客様は、今回のセキュリティ更新プログラムで対応された脆弱性について既に保護されていますので、特別な対応は不要です。ただし、環境内に存在する Exchange サーバーや Exchange 管理ツールをインストールしたワークステーションについては、引き続き更新プログラムの適用を行ってください。

特定の脆弱性 (CVE) に関する詳細は、Security Update Guide (Exchange SE については Product Family で “Server Software” でフィルター、Exchange Server 2016 および 2019 については Product Family で “ESU” でフィルター) を参照してください。

Exchange Emergency Mitigation (EM) と Feature Flighting サービスの継続利用に必要な更新

サービス側の変更により、Exchange を 2026 年 6 月の更新プログラム以降に更新していない場合、Exchange Emergency Mitigation (EM) と Exchange Flighting サービスは、2026 年 7 月以降にリリースされる構成ファイルを利用できなくなります。既にダウンロードされ適用済みの緩和策は引き続き機能しますが、更新プログラムをインストールしない限り、2026 年 7 月以降に新しい緩和策を利用できません。

詳細は、Exchange mitigation and flighting services fail due to “Unknown Issuer” error を参照してください。

インストール後の CVE-2026-42897 緩和策

セキュリティ強化と環境全体の防御力向上に向けた継続的な取り組みの一環として、クロスサイト スクリプティング攻撃への保護を引き続き強化しています。CVE-2026-42897 の緩和策は有効なままにしておくことを推奨します。この緩和策は追加の防御層となり、さらなる改善がリリースされるまで継続的な保護を確保するのに役立ちます。追加情報は、提供可能になり次第お知らせします。最新情報については、こちらの記事 2026 年 7 月の Exchange Server のセキュリティ更新プログラムが公開されました をご確認ください。

2026 年 6 月の更新プログラムをインストールしても、既に適用済みの CVE-2026-42897 緩和策は自動的には削除されません。そのため、インストール後に緩和策を削除する場合は、以下の対応を行ってください。

Exchange Emergency Mitigation (EM) Service を使用して緩和策を適用していた場合:

1. 緩和策 M2.1.0 の再適用をブロックします。CVE-2026-42897 の緩和策を有効なままにしておくことを推奨しているため、2026 年 6 月の SU に更新済みのサーバーに緩和策が適用されないようにする変更は、現時点ではまだ行っていません。そのため、まず緩和策が再適用されないようにブロックする必要があります。
2. 緩和策 M2 の IIS ルールを削除します。

ダウンロード可能な EOMT スクリプト https://aka.ms/UnifiedEOMT を使用して緩和策を適用していた場合:

1. 緩和策をロール バックします。

Exchange 2016 および 2019 の更新プログラムは第 2 期 ESU プログラムでのみ提供されています

Exchange Server 2016 および 2019 はサポートが終了しています。2026 年 5 月から 10 月までの間にリリースされる Exchange Server 2016 および 2019 のセキュリティ更新プログラムを入手できるのは、第 2 期 Extended Security Update (ESU) プログラムに登録しているお客様のみです。

第 2 期 ESU プログラムに参加していない場合は、Exchange Server Subscription Edition (SE) に移行して、最新のセキュリティ更新プログラムを引き続き受け取ってください。

既に第 2 期 ESU を購入済みで、最新のセキュリティ更新プログラムへのアクセスに関する情報が必要な場合は、ExchangeandSfBServerESUInquiry@service.microsoft.com にメールを送信してお問い合わせください。

このリリースの既知の問題

• Wrapper messages appear in shared mailbox in hybrid environments after installing the June 2026 Security Update | Microsoft Support

更新プログラムのインストール

利用可能な更新パスは以下の通りです。

• Exchange Server Health Checker スクリプトを使用して、更新が必要な Exchange サーバーのインベントリを作成し、各サーバーの更新状況 (CU、SU、手動対応) を確認してください。
• 最新の CU をインストールします。Exchange Update Wizard を利用して、現在の CU と目標 CU を選択し、手順を確認してください。
• 更新プログラムのインストール後に再度 Health Checker を実行し、追加の対応が必要かどうかを確認します。
• セットアップ完了後、サーバーを再起動し、すべての Exchange サービスが正常に起動したことを確認します。一部のサービスが無効状態になっている場合は、更新プログラムのインストールが何らかの理由で中断されたことを示しています。詳細については、この記事の「回避策 1」を参照してください。
• Exchange Server のインストール中やインストール後にエラーが発生した場合は、SetupAssist スクリプトを実行してください。更新後に問題が発生した場合は、失敗した Exchange Server の更新プログラムの修復方法や、Exchange Server の更新プログラムをインストールしようとしたときのファイル バージョン エラーも確認してください。

よくあるご質問

CVE-2026-42897 の緩和策がリリースされたとき、いくつかの既知の問題が報告されていました。CVE-2026-42897 の修正 (2026 年 6 月 SU) では、それらは解決されていますか？
はい。2026 年 6 月の SU をインストールし、緩和策を削除すると、既知の問題も解決されるはずです。ただし、SU をインストールしても緩和策は自動的には削除されません。また、もうしばらくの間は緩和策を有効にしておくことを推奨しています。

一部のサーバーを更新したものの、他のサーバーを更新できない場合、更新できないサーバーでは CVE-2026-42897 の緩和策を有効にしたままにできますか？更新済みのサーバーと、緩和策を利用したままのサーバーが混在していても問題ありませんか？
2026 年 6 月の SU 以降に更新できないサーバーでは、緩和策を引き続き利用できます。ただし、そのサーバーでは緩和策による既知の問題も引き続き発生します。また、この更新プログラムを適用した後、組織内のすべての Exchange サーバーが更新されるまで、Office Online Server (OOS) と Exchange Server の統合が期待通りに機能しない場合があります。

サーバーを 2026 年 6 月以降の更新プログラムに更新しましたが、緩和策が原因の既知の問題がまだ発生しています。なぜですか？
2026 年 6 月以降の更新プログラムをインストールしても、緩和策は自動的には削除されません。上記の説明を確認してください。現時点では緩和策を有効なままにしておくことを推奨していますが、上記の手順で削除することもできます。

弊社の環境は Exchange Online とのハイブリッド構成ですが、対応は必要ですか？
Exchange Online は既に保護されていますが、管理目的のみで利用している場合も含め、オンプレミスの Exchange サーバーには今回のセキュリティ更新プログラム (SU) を必ずインストールしてください。SU 適用後に認証証明書を変更する場合は、ハイブリッド構成ウィザードを再実行する必要があります。

最後にインストールした SU/HU は数か月前のものですが、最新の SU をインストールするためにすべての SU を順番に適用する必要がありますか？
すべての SU は累積的です。サポートされている CU を使用している場合、すべての SU や HU を順番にインストールする必要はなく、最新の SU を適用するだけで問題ありません。詳細はこちらのブログ記事を確認してください。

組織内のすべての Exchange Server に SU をインストールする必要がありますか？”Exchange 管理ツールのみ” インストールされたマシンはどうなりますか？
すべての Exchange Server および Exchange 管理ツールがインストールされたすべてのサーバー / ワークステーションに SU を適用することを推奨します。これにより、管理ツールのクライアントとサーバー間の互換性が確保されます。稼働中の Exchange Server が存在しない環境で Exchange 管理ツールのみを更新する場合は、こちらを確認してください。

弊社は Exchange 2016 および 2019 の第 2 期 ESU を登録していません。現在の Exchange 2016 または 2019 の更新プログラムを入手するにはどうすればよいですか？
Exchange 2016 および 2019 は現在サポートが終了しているため、第 2 期 ESU プログラムに登録しているお客様 (2026 年 5 月から 10 月まで有効) のみが、2026 年 5 月以降にリリースされる Exchange 2016 または 2019 の更新プログラムを入手できます。Exchange 2016 または 2019 を引き続き利用しているすべてのお客様には、できるだけ早く Exchange SE にアップグレードすることを推奨します。

本記事公開時点では、関連するドキュメントが完全には利用できない場合があります。

この記事の重要な更新:

• 2026 年 7 月 14 日: 2026 年 7 月の Exchange Server のセキュリティ更新プログラムが公開されました へのリンクを追加しました。既知の問題に対処するため、2026 年 7 月の Exchange Server セキュリティ更新プログラムをインストールした後は、CVE-2026-42897 の緩和策を削除してください。
• 2026 年 7 月 13 日: 既知の問題セクションを追加しました
• 2026 年 6 月 15 日: 緩和策のブロックに関する説明を明確化しました
• 2026 年 6 月 11 日: ドキュメント公開に関する問題のバナーを削除しました (現在は解決済み)

Outlook コミュニティの皆さま、こんにちは。Outlook チームで Principal Product Manager を務める Vicki Milton です。

この 1 年の間に、新しい Outlook for Windows には、オフラインのサポート、共有メールボックス、PST ファイル対応など、重要な機能が追加されました。さらに、それらの大きなマイルストーンに加え、日々の業務をより効率的に行えるようにするための細かな改善も継続的に提供しています。

この記事では、新しい Outlook for Windows で生産性を高める 15 の機能を紹介します。整理された作業環境を保ちながら、日常的な操作の手間を減らし、重要な業務をスムーズに進めるのに役立つ機能です。

メール機能

メールは現在でも、コミュニケーションの管理や優先順位の整理、フォローアップに欠かせない存在です。Outlook には、メールの作成や整理に役立つ定番の機能に加えて、受信トレイの管理をよりスムーズかつ効率的に行える新しい機能も用意されています。

1. メールをピン留めする: 重要なメールをすぐ見つけられるようにできます。 ピン留め機能を使うと、選択したメールを受信トレイの上部に固定表示できます。新しいメールが届いても埋もれないため、常に確認しやすい状態を保てます。例えば、出張の予定、承認待ちのメール、対応中の依頼など、頻繁に確認したい重要なメールの管理に便利です。優先度の高いメールを見える場所に置いておくことで、メール検索にかかる時間を減らし、現在の作業に集中しやすくなります。

2. メールを再通知する: 必要なタイミングでメールを再表示できます。 再通知機能を使うと、メールを一時的に受信トレイから非表示にし、指定した日時に再表示させることができます。これにより、今すぐ対応が必要なメールに集中しつつ、あとで対応したいメールを適切なタイミングで再確認できます。特に、追加情報を待っている依頼、予定された作業、集中できる時間にまとめて対応したいタスクなどの管理に便利です。

3. 複数のカテゴリをまとめて追加する: 少ない操作でメールを整理できます。 カテゴリを使って受信メールを管理している場合、Outlook では 1 回の操作で複数のカテゴリを付けられます。プロジェクト、優先度、フォローアップ状況など、複数の情報をまとめて付けたいときに、何度もメニューを開き直す必要がありません。特に多くのメールをまとめて整理するときに便利です。

4. 一括処理: 繰り返し行う受信トレイの整理作業を減らせます。 一括処理機能を使うと、特定の送信者から届くメールに対して自動処理を設定できます。たとえば、一定期間後に広告メールを自動削除したり、スレッド内の最新メールだけを残したり、定期的に届く通知を自動でフォルダーへ移動したりできます。これにより手作業でのメール整理を減らし、本当に対応が必要なメールに集中しやすくなります。

5. スケジュール送信: 自分の都合のよいタイミングで作成し、適切な時間に送れます。 スケジュール送信機能を使うと、自分の都合がよいタイミングでメールを作成し、相手に届いてほしい時間に送信できます。これにより、相手が確認しやすい時間帯にメールが届くようになるほか、より計画的なコミュニケーションが可能になります。また、送信を忘れないように下書きのままに残したり、リマインダーを設定したりする手間も減らせます。

6. フォルダー共有の簡素化: フォルダー共有をより簡単に行えます。 これまでメール フォルダーを共有する際は、特にサブフォルダーの場合、追加のアクセス権設定が必要になることがありました。現在 Outlook では、フォルダーを共有する際に、親フォルダーに必要な表示権限も自動で設定できるようになっています。これにより、設定の手間を減らせるだけでなく、共有相手がフォルダーを閲覧できないといった問題も起こりにくくなります。そのため、フォルダー共有をより簡単かつ安心して行えるようになります。

カレンダーと会議の機能

多くの人にとって、日々の業務は会議や予定変更、そして次に何を進めるべきかを関係者と共有・調整することによって進んでいます。Outlook には、予定の調整や会議の管理をより簡単にし、やりとりの手間を減らしながら、その後のフォローアップもしやすくする機能が用意されています。

7. 会議をフォローする: 会議に参加しなくても内容を把握できます。 フォローする という RSVP オプションを使うと、会議には参加しないものの、会議後のまとめを確認できるようになります。予定が重なって会議に参加できない場合や、リアルタイム参加までは不要な会議でも内容だけ把握しておきたい場合に便利です。会議の結果や共有資料を後から確認できるため、必要な情報を逃さずに、カレンダーの予定も整理しやすくなります。

8. 保存されたビュー: よく使うビューに、すぐ切り替えられます。 保存済みビュー を使うと、特定のカレンダーの組み合わせを保存して、毎回設定し直さなくてもすぐに切り替えられます。例えば、個人予定用、チーム予定用、プロジェクト予定用など、用途ごとに表示を使い分けることが多い場合に便利です。必要なカレンダーをすぐに表示できるため、予定確認やスケジュール調整を効率よく行えます。

9. 会議の追跡機能の改善: 出欠回答をより効率よく管理できます。 Outlook では、開催者が参加者の出欠状況を確認・管理しやすくするための機能があります。たとえば、状況確認 ビューで参加者一覧を並べ替えたり、名前を検索したりできるほか、必要に応じた返信内容をコピーしたりダウンロードしたりできます。特に参加者の多い会議で、出欠状況をすばやく確認したい場合に役立ちます。

10. 会議のまとめ: 会議後に必要な情報を 1 か所で確認できます。 Teams 会議の後、Outlook の予定表イベントには 会議のまとめ が表示され、録画、文字起こし、共有ファイルへのリンクをまとめて確認できます。何が話されたのかを振り返ったり、内容を再確認したり、参加できなかった会議にあとから追いついたりしやすくなります。必要な資料がまとまっているため、会議後の確認作業を効率よく行えます。

11. 適用されたフィルター: カレンダーの見た目をすっきりさせます。 フィルター を使うと、自分が参加しない会議や、辞退済みの予定、参考情報だけの予定を非表示にできます。予定表が見やすくなり、スケジュール確認や予定の重複チェックをしやすくなります。また、本当に対応が必要な会議に集中しやすくなります。特に予定が多い人にとって、スケジュール管理をより簡単に行える便利な機能です。

12. 定期的な予定を変更する: 過去の予定はそのまま残しつつ、今後の予定だけ更新できます。 予定が変更になった場合、Outlook では定期的な予定シリーズの「今回とこれ以降のすべてのイベント」をまとめて変更できます。これにより、過去の会議記録はそのまま残しながら、今後の時間、場所、議題などを簡単に変更できます。開催者にとって更新作業がしやすくなり、参加者への影響も最小限に抑えられます。

個人設定と各種設定

設定を少し調整するだけで、日々の業務効率を高めることができます。アカウントやカレンダーの切り替えがしやすくなったり、自分の使いやすい形で Outlook を利用できるようになります。ここでは、Outlook をより使いやすくする設定関連の機能を紹介します。

13. メール アカウント名を変更する: どの受信トレイかを見分けやすくなります。 Outlook で複数のアカウントを使っている場合、それぞれに分かりやすい名前を付けられます。アカウントをすぐ見分けやすくなり、誤ったアカウントからメールを送信してしまうリスクを減らせます。日常的に複数アカウントを切り替えて使う際の操作も分かりやすくなります。

14. テーマ: 見やすく快適な画面デザインを選べます。 Outlook では、テーマや色を変更して、自分の好みに合わせた画面表示にできます。こうした表示設定は、特にメールや予定表を長時間使う人にとって、見やすさや使いやすさに大きく影響します。例えば、ダーク モードや色のカスタマイズを使うことで、目への負担を軽減し、より快適に Outlook を使えるようになります。

15. キーボード ショートカット: 慣れた操作方法をそのまま利用できます。 Outlook では、設定 から自分の好みにあったショートカットの種類を選べます。これまで使っていた操作習慣を保ちやすくなり、新しい環境に慣れるまでの時間も短縮できます。特に、従来の Outlook for Windows や Outlook on the web から移行する場合でも、慣れたショートカットを利用できるため、違和感なく使い始められます。

これらの機能は、新しい Outlook for Windows でより効率よく作業できるようにするための取り組みの一部です。大量のメールを処理する場合でも、予定表を管理する場合でも、自分の働き方に合わせて設定を調整する場合でも、日々の作業の負担を減らし、生産性を高めるのに役立ちます。

詳しい情報や設定手順は、Microsoft サポートの記事 と Learning Path をご覧ください。

こんにちは。日本マイクロソフト Exchange & Outlook サポート チームの相場 (アイバ) です。

本記事では、会議予約の際に利用できる Copilot の機能である「会議室の再予約 (Rebook)」と「再スケジュール (Reschedule)」について説明します。

会議室の再予約 (Rebook) と再スケジュール (Reschedule) について

会議室の再予約 (Rebook) とは

会議室の予約ができなかった場合に自動的に別の会議室を Copilot が予約する機能です。
Microsoft 365 Copilot ライセンス (以下、Copilot ライセンス) を持つユーザーが新しい Outlook や Outlook on the web で利用できます。

再スケジュール (Reschedule) とは

予定の登録後、開催者の予定表に時間帯が重複する別の予定が登録された場合、Copilot が自動的に別の時間帯へ予定を移動する機能です。
Copilot ライセンスを持つユーザーが新しい Outlook や Outlook on the web で利用できます。

以降では、それぞれの動作について詳しく説明します。

会議室の再予約 (Rebook) の動作

設定方法

会議の作成画面で [拒否された会議室を再予約する] (または [拒否された会議室の再予約]) のチェックを ON にした上で会議室の予約を行います。(既定では本設定は OFF の状態です)
なお、本設定は以下の 2 か所にありますので、いずれかのチェックを ON にします。

※ 画面右の「Places Finder」の画面は会議室を指定する項目で [すべてのルームを参照する] をクリックすることで表示されます。

設定後の動作

予約しようとした会議室で既に同じ時間帯に別の予約が入っているなどの理由で予約ができなかった場合、会議の開催者は以下のような会議室予約の辞退メールを受け取ります。

その後、Copilot によって同じ時間帯に別の会議室の予約が行われ、以下の通知が開催者に送信されます。

再スケジュール (Reschedule) の動作

設定方法

まず会議の作成画面にて [競合が発生した場合は、Copilot にこのイベントの再スケジュールを任せます。] のチェックを ON にします。

続けて、右に表示されている [受け入れ可能な時間] をクリックして、予定の移動を受け入れる期間を指定します。

設定後の動作

同じ時間帯に別の予定が登録されると自動的に再スケジュールを有効にした予定が別の時間に移動します。

会議の再スケジュールが行われた場合、Copilot により再スケジュールが行われたことを示す以下のメールを会議の開催者は受け取ります。

※ 再スケジュールが発生したことは画面右上の通知からも確認することができます。

また、会議の参加者に対しても会議の時間が変更されたことを示すメールが送信されます。

注意

再スケジュールの機能は個人の予定または 1:1 の会議でのみ利用することができます。会議の参加者に 2 名以上を指定した時点で [競合が発生した場合は、Copilot にこのイベントの再スケジュールを任せます。] の設定はグレーアウトされ、利用することができませんのでご注意ください。

本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

長い年月がたった今でも、サポートが終了している IIS 6.0 の SMTP 仮想サーバー機能を使い続けている環境が見られます。このコンポーネントがどれほど古いかというと、IIS に組み込まれていた SMTP 仮想サーバー スタックは Windows Server 2003 の時代のものです。この記事では、IIS SMTP の利用を終了し、サポートされている Microsoft のソリューションへ移行するための実践的な選択肢を紹介します (IIS SMTP 仮想サーバーはすでに長らくサポート対象外です)。

これまで 特定のシナリオ においては、最後のオンプレミス Exchange サーバーを残しておくことを推奨してきました。特に多いのは、すべてのメールボックスを Exchange Online に移行した後も、オンプレミスのアプリケーションがメール リレーのために Exchange を必要としているケースです。

一方で、Exchange Online のみを利用している環境では、最後のオンプレミス Exchange サーバーをすでに廃止している、あるいはもともと利用していないケースもあります。こうした環境では、さまざまな理由により、アプリケーションや Fax、プリンターから Exchange Online 経由の直接メール リレーを構成できない場合があります。このような場合、IIS SMTP の利用を廃止するための最もシンプルでサポートされた方法は、スタンドアロンの Exchange Edge Transport サーバーに置き換えることです。これにより、複数のアプリケーションやデバイスを個別に管理する代わりに、1 台または少数の Edge サーバーに集約して管理できるため、管理の効率化にもつながります。

あまり知られていないかもしれませんが、スタンドアロンの Exchange Edge Transport サーバーは、運用負荷は最小限に抑えることができます。

ここでの “スタンドアロン” の意味を明確にしておくことが重要です。スタンドアロンの Edge Transport サーバーは、Active Directory サイトにサブスクライブされていない 構成です。サーバーがドメイン参加しているかどうかは本質的に関係ありません。重要なのは、Edge Transport サーバーが Active Directory に対して Edge サブスクリプションされていない点です。この構成では、Active Directory 側から見ると、この Exchange サーバーの存在は認識されません。

なぜこれが重要なのでしょうか。それは、Edge Transport サーバーを AD サイトにサブスクライブすると、EdgeSync や Direct Trust 用の専用証明書、追加の運用上の考慮事項など、構成が複雑になるためです。この記事の目的は、環境に不要な複雑さを持ち込まずに、レガシーな IIS 6.0 SMTP サーバーの利用を最終的に廃止できる、シンプルで手間のかからない、かつサポートされた方法を紹介することです。

利用できる選択肢の全体像をつかむために、次のフローチャートをご覧ください。

¹ アプリケーションやデバイスが、Exchange Online のメールボックス宛てのみに送信するのか、それとも外部ドメインにも送信するのかを確認することが重要です。要件に応じて、次の 記事 にあるオプションを検討してください。外部ドメインへの送信 (つまり Exchange Online 経由のリレー) が必要な場合は、次の方法があります。

• TLS 証明書ベースの SMTP リレー用コネクタ を構成する: これはより安全なリレー方法です。証明書の Subject または Subject Alternative Name (SAN) に、Microsoft 365 の 承認済みドメイン が含まれている必要があります。

または

• IP アドレス ベースの SMTP リレー用コネクタ を構成する: こちらはセキュリティ面で劣るため、推奨されません。この方法では、MAIL FROM に指定する送信ドメインが、テナントの承認済みドメインのいずれかと一致している必要があります。

証明書ベースと IP ベースのどちらのコネクタを選ぶ場合でも、次の 記事 に記載された要件を満たしていることを確認してください。

すべてのオンプレミス アプリケーションを Exchange Online に切り替えることは可能か

次のように、複数の課題 (制約) が存在する可能性があります。

• 外部へのアウトバウンド通信が許可されていないアプリケーション
• 所有者や設定が不明なレガシー アプリケーション
• 既存アプリケーションの更新や再構成が難しい

アプリケーションやデバイスから Exchange Online へ直接送信またはリレーするには、いくつかの課題があります。たとえば、TLS/STARTTLS をサポートしていないアプリケーションやデバイスがあるほか、拠点にあるプリンターなど複数のエンドポイントに対して証明書を管理すると、運用が複雑になり、セキュリティ リスクも高まります。

このような場合には、スタンドアロンの Edge Transport サーバーを導入する方がより適しています。これにより、SMTP リレー機能を集約し、個々のデバイスやアプリケーションに厳格な TLS 要件や証明書要件を求めることなく、Exchange Online や外部ドメインへ安全にメールを送信できるようになります。

これらのアプリケーションではどの認証方式を使っているか

たとえば、Basic 認証や NTLM を使用している場合です。これらのいずれかを使っている場合は、次の点に注意が必要です。

• Exchange Online では SMTP の Basic 認証は廃止されます
• Exchange Online の SMTP シナリオでは NTLM はサポートされていません

そのため、これらの認証方式に依存していると、Exchange Online を利用できない可能性があります。

IIS 6.0 SMTP の利用状況の評価

IIS SMTP サーバーを置き換えると決めたら、最初に行うべき最も重要な作業の 1 つは、現在の利用状況を詳細に評価することです。

まだログ取得を有効にしていない場合は、次の手順で設定してください。
IIS → SMTP Virtual Server → Properties → Enable Logging → Properties → Advanced

その後、どのアプリケーションやシステムが IIS SMTP サーバーに依存しているかを特定できるよう、必要な拡張ログ項目をすべて選択します。

また、十分な量のデータを取得できるよう、一定期間ログを収集することをお勧めします。これにより、断続的にしか使われないアプリケーションや、利用頻度の低いシステムも把握しやすくなります。

そのほか、次の点も確認してください。

Access タブ → 認証 (Authentication)
有効になっている認証方式を確認します。たとえば次のような項目です。

• 匿名アクセス (Anonymous access)
• Basic 認証 (Basic Authentication)
• 統合 Windows 認証 (Integrated Windows Authentication)

Access タブ → リレー制限 (Relay Restrictions)

リレーが特定の IP アドレス一覧に制限されているか、またその制限範囲が適切かを確認します。

Delivery タブ → 詳細設定 (Advanced)

送信メールがどのようにルーティングされているかを確認します。

• smart host を使用しているか、それとも DNS 参照を直接実行しているか

smart host を構成している場合は、次の点も確認してください。

• Access タブ → Outbound Security に戻る
• smart host への接続に認証が必要かどうか、および使用している認証方式を確認します。

これらの設定を Exchange Edge Transport に対応付ける際には、次の点を意識してください。

• IIS SMTP の Access タブで設定した内容は、通常 Edge Transport サーバーの 受信コネクタ (Receive Connector) に対応します。
• IIS SMTP の Delivery タブで設定した内容は、送信コネクタ (Send Connector) に対応します。

IIS SMTP のログ取得を有効化し、十分なデータを収集できたら、次はログを分析して利用状況の傾向を把握します。主な確認項目は次のとおりです。

• IIS SMTP サーバーを利用しているアプリケーションの送信元 IP アドレス
• 送信者 SMTP アドレス
• 宛先 SMTP アドレス
• アプリケーションごと・日ごとのメール送信量

IIS SMTP のログは、特に大規模環境では分析しやすい形式とは言えません。そのため、有用な情報を引き出すには、主に次の方法があります。

• Log Parser と Log Parser Studio を使って、独自の SQL クエリを作成する
  または
• IIS SMTP ログを Copilot に共有し、要件に応じて解析させる

もう 1 つ重要な評価ポイントは、アプリケーションが IIS SMTP サーバーへどのように接続する設定になっているかです。

• アプリケーションは IIS SMTP サーバーを固定 IP アドレス (ハードコード) で指定しているのか、それとも DNS エイリアスを使用しているのかを確認します。エイリアスは CNAME レコードまたは ホスト (A) レコード が使用されている場合があります。

アプリケーションが DNS エイリアスを使っている場合は、Exchange Edge Transport への移行は比較的シンプルです。この場合、DNS でエイリアスに紐づく IP アドレスを更新するだけで、メール フローを切り替えることができます。一方で、アプリケーションが固定 IP アドレスで構成されている場合は、移行の難易度が上がります。この場合は、主に以下の 2 つの方法が考えられます。

1. 各アプリケーションを個別に更新する方法 : IIS SMTP サーバーの IP アドレスを Exchange Edge Transport の IP アドレスに置き換えます。最もクリーンな方法ですが、作業時間がかかり、運用面の負荷も高くなりがちです。
2. 既存の IIS SMTP の IP アドレスを再利用する方法 : 同じ IP アドレスを Exchange Edge Transport サーバーにセカンダリ IP として割り当てます。Microsoft は一般的に Exchange 環境での IP 再利用を推奨していませんが、これは主に Active Directory と統合された Exchange の役割を想定したガイダンスです。今回のように Edge Transport がスタンドアロンであり、Active Directory にオブジェクトを保持しないため、十分に計画・管理されたうえであれば、IP 再利用は許容できる場合があります。

IIS SMTP に関するすべてのデータを収集・分析したら、Exchange Edge Transport の展開に進むことができます。

評価フェーズでさらに詳細が必要な場合は、FAQ セクションを参照してください。そこでは、一般的な注意点や IIS SMTP 特有の考慮事項について説明されています。

Exchange Edge Transport の考慮事項

IIS SMTP を廃止し、メール リレーに Exchange Edge Transport 役割を使うと決めた場合、次に重要となるのは、Edge Transport サーバーをドメイン参加済みのマシンに展開するかどうかです。

Microsoft では一般的に、Edge Transport 役割をドメインに参加していないサーバーに展開することを推奨しています。ただし、この推奨は主に、Edge Transport を境界ネットワークに配置し、Mailbox サーバーを含む Active Directory サイトとサブスクリプションを構成する従来の Exchange 環境を前提としています。

Exchange の Mailbox 役割が存在しないシナリオでは、認証・セキュリティ・管理要件に基づいて判断する必要があります。この判断の参考として、以下の点を確認してください。

• ドメイン サービス アカウントを使って Basic 認証や統合 Windows 認証を実施する必要があるか: 必要な場合は、Edge Transport をドメイン参加サーバーとして展開する必要があります。
• ローカル アカウントで認証できるか (例: ドメイン依存のない Basic 認証): 可能な場合は、ドメイン参加していないサーバーでも対応できます。
• GPO (Group Policy Objects) や一元的なセキュリティ ベースラインを適用する必要があるか: 必要な場合、一元管理とコンプライアンス適用を実現するために、ドメイン参加構成を検討してください。

なお、Edge をドメイン参加サーバーにインストールするかどうかにかかわらず、Active Directory へのサブスクリプションを作成しない構成では、Edge のインストール時に Exchange Server 向けのスキーマ拡張や AD の事前準備は不要です。

要件

設計方針が決まったら、最新の状態に更新されたサーバーに Exchange Edge Transport 役割をインストールします。環境準備は 公式の前提条件ドキュメント に従って進めてください。必要なコンポーネントは次のとおりで、比較的限定されています。

• .NET Framework
• Visual C++ 2012 Redistributable
• Active Directory Lightweight Directory Services (AD LDS)

追加の Exchange 役割や依存コンポーネントは不要です。

ネットワークおよびセキュリティ:

• Edge サーバーと、メール リレーに Exchange Edge Transport を利用するアプリケーション/デバイス間では、TCP 25 番ポートの通信を許可する必要があります。通常、これらのアプリケーションやデバイスが組織内部ネットワークにある前提であるため、インターネットへは公開しない構成が一般的です。
• 外部ネットワークとの SMTP 通信を可能にするため、Edge サーバーから外部への TCP ポート 25（アウトバウンド通信）も許可する必要があります。
• 一般的なセキュリティ ベスト プラクティスに従って、サーバーを適切にセキュリティ強化 (ハードニング) を実施してください。
• Exchange Server で動作するウイルス対策ソフトについては、この 記事 を参照してください。Edge Transport に必要な除外項目は、「Servers」列で確認できます。

高可用性が必要な場合は、2 台のスタンドアロン Edge Transport サーバーをロード バランサー配下、または DNS ラウンドロビン構成で展開することを検討してください。これにより、Windows や Exchange のパッチ適用などのメンテナンス時に発生するサービス影響を最小限に抑えられます。

承認済みドメイン

Exchange Edge Transport 役割のインストール手順は比較的シンプルなため、この記事では詳細な手順を取り上げません。ここでは、Edge Transport サーバーはすでに正常に展開され、稼働している前提とします。

最初のステップは、Edge Transport サーバーで承認済みドメインを構成することです。具体的なコマンド構文や必要なパラメーターについては、関連ドキュメント を参照してください。

なお、スタンドアロンの Edge Transport 役割には Resolve エンジンがありません (例: Active Directory や ADAM に対する受信者/送信者の検証機能) が存在しない点に注意が必要です。そのため、この構成においては Authoritative ドメインと Internal Relay ドメインの違いは、Edge Transport サーバーの動作に実質的な影響を与えません。

受信コネクタ

Edge Transport をインストールすると、この記事 で説明されている通り、受信コネクタが自動的に作成されます。

要件に合わせて受信コネクタをカスタマイズするには、アプリケーションがメール リレーのために IIS SMTP をどのように使用していたかを理解する必要があります。ここでは、承認済みドメインが contoso.com のみであると仮定します。

• アプリケーションが、認証なしで contoso.com 宛てに送信している場合 (例 : [app1@contoso.com] から [john@contoso.com] への送信): 既定のコネクタを使用でき、新しいコネクタの作成は不要です。
• アプリケーションが Basic 認証または統合 Windows 認証を使い、送信元 SMTP アドレスとして contoso.com を使用して、任意の受信者へ送信する場合 (例 ： [app1@contoso.com] から [john@contoso.com] と [adele@fabrikam.com] へ送信):

1. ExchangeUsers のアクセス許可グループで新しい受信コネクタを作成し、認証方式として BasicAuth および/または Integrated を設定したうえで、アプリケーションの IP アドレスまたは IP アドレス範囲を RemoteIPRanges に追加します。

1

New-ReceiveConnector -Name "BasicAuth" -AuthMechanism BasicAuth -RemoteIPRanges "192.168.0.1" -PermissionGroups ExchangeUsers -Custom -Bindings 0.0.0.0:25

1. 次に、コネクタへ ms-Exch-SMTP-Accept-Authoritative-Domain-Sender 権限を追加します。前述のとおり、Edge Transport には Resolve エンジンがないため、認証されたユーザーのプライマリ SMTP アドレスを検証することができません。この権限を付与しない場合、”550 5.7.60 SMTP; Client does not have permissions to send as this sender” エラーが発生します。

1

Get-ReceiveConnector BasicAuth | Add-ADPermission -User "NT AUTHORITY\Authenticated Users" -ExtendedRights "ms-Exch-SMTP-Accept-Authoritative-Domain-Sender"

• アプリケーションで オープン リレー が必要な場合 (推奨はされません) は、この 記事 の手順に従って設定することが可能です。

送信コネクタ

新規に Exchange Edge Transport をインストールした場合、既定で送信コネクタは作成されません。そのため、最初から手動で送信コネクタを構成する必要があります。

前述のとおり、まずは現在の IIS SMTP サーバーが送信リレーをどのように処理しているかを把握することが重要です。具体的には、次の点を確認します。

• DNS 参照を直接実行しているか、またはスマートホストを使用しているか (必要に応じて Basic 認証の有無も確認)
• ドメインごとに異なるルーティングを設定する必要があるか

これらの情報は、Edge Transport サーバーの送信コネクタ設定に直接影響します。送信コネクタの作成と設定に必要なコマンドやパラメーターの詳細は、関連ドキュメント を参照してください。

メール フローの切り替え

この段階で、IIS SMTP の評価は完了しており、アプリケーションが DNS レコード経由で接続しているのか、固定 IP アドレスで接続しているのかを把握できている前提とします。

• DNS エイリアスを使用している場合 (例: CNAME または A レコード):
  移行は比較的シンプルです。DNS レコードの参照先を Exchange Edge Transport サーバーに更新することで、メール フローを切り替えることができます。
• アプリケーションが固定 IP アドレスを使用している場合:
  既存の IIS SMTP サーバーの IP アドレスを再利用する方法を検討します。手順は比較的シンプルです。
  • IIS SMTP サーバー側でネットワーク インターフェイス (NIC) を無効化する
  • IIS SMTP サーバーで使用していた IP アドレスを、Exchange Edge Transport サーバーにセカンダリ IP として割り当てる
  • IIS SMTP サーバーに紐づいていた既存の DNS A レコードを、Exchange Edge Transport サーバーを指すように更新する

ベスト プラクティスとして、本番切り替えを行う前に、まずは一部のアプリケーションでメール フローを検証してください。これにより、潜在的な問題を早期に特定し、スムーズに移行を進めることができます。

(任意) Exchange Online をスマートホストとして設定する

Exchange Online テナントを利用している場合、Edge の送信コネクタでテナントの MX をスマートホストとして設定することで、スタンドアロン Edge Transport から Exchange Online 経由でメールをリレーできます。必須ではありませんが、Exchange Online の承認済みドメインと同じドメイン名の証明書をバインドすることを推奨します。これにより、適切な メッセージの帰属 (message attribution) が行われ、Edge Transport から送信されるメールは Originating として扱われます。

• まず、テナントの MX レコードを確認します。確認方法はこの 付録 を参照してください。
• 送信コネクタのスマートホストとして MX レコードの値を設定します。
• 証明書をローカル コンピューターの「個人」ストアにインポートし、SMTP サービスを割り当てます。
• 証明書を送信コネクタにバインドします。

1
2
3

$Cert = Get-ExchangeCertificate -Thumbprint "<new certificate thumbprint>"
$TLSCertificateName = "<i>$($Cert.Issuer)<s>$($Cert.Subject)"
Set-SendConnector -Identity "Send Connector Identity" -TlsCertificateName $TLSCertificateName

• コネクタに次のプロパティを設定します。

1

Set-SendConnector -Identity "Send Connector Identity" -RequireTLS $True -TlsAuthLevel DomainValidation -TlsDomain mail.protection.outlook.com

• 次に、Exchange Edge Transport から送信されるこれらのメッセージを正しく識別 (属性付け) させるため、Exchange Online 側で Inbound コネクタを作成します。

1

New-InboundConnector -Name "FromEdgeTransport" -ConnectorType OnPremises -SenderDomains * -RequireTls $True -TlsSenderCertificateName "Your Certificate CN"

最後に、こちら の説明に沿って、公開 DNS の SPF レコードに EOP と Edge Transport のグローバル IP アドレスを追加してください。これは、外部の受信者にメールがなりすましと判定されたり、EOP によって Edge からのメールがなりすましと判定されたりすることを防ぐための重要な設定です。さらにセキュリティを強化したい場合は、DKIM を有効化 や、ドメインの DMARC ポリシーを作成 することも検討してください。

FAQ

IIS SMTP で Basic 認証に使用されているドメイン アカウントまたはローカル アカウントの確認方法は?
残念ながら、IIS SMTP のログだけでは、メール送信時に Basic 認証で使用されたアカウントを確認することはできません。以下の XML クエリを使用して、セキュリティ イベント ビューアーのログをフィルターすることができます。

1
2
3
4
5
6
7
8
9
10
11

<QueryList> 
 <Query Id="0" Path="Security"> 
  <Select Path="Security"> 
   *[System[(EventID=4624)]]
    and 
   *[EventData[Data[@Name='LogonType']='3']]
    and 
   *[EventData[Data[@Name='ProcessName']='C:\Windows\System32\inetsrv\inetinfo.exe']] 
  </Select>
 </Query>
</QueryList>

IIS 6.0 SMTP をやめて Exchange Edge Transport に移行するメリットは?
IIS 6.0 はすでにサポート終了しているため、今後はセキュリティ更新プログラムや Microsoft サポートによる支援を受けることができません。技術的な観点では、Exchange Edge Transport 役割を利用することで、メール フローに関する機能や制御の幅が大きく向上します。たとえば次のような点です。

• メッセージ追跡ログやパイプライン トレースなど、より詳細なログ機能を利用できる
• 強化されたセキュリティと制御機能
• トランスポート ルールの適用が可能 (ただし、Exchange Mailbox 役割に比べると機能は限定的)

総合的に見ると、Exchange Edge Transport はレガシーな IIS SMTP と比較して、より先進的でセキュア、かつ管理しやすいソリューションと言えます。

スタンドアロンの Edge Transport で Address Rewrite 機能は使えるか?
使えます。ただし、いくつか重要な注意点があります。

Inbound Address Rewrite は、スタンドアロン Edge Transport でもサポートされており、期待どおりに動作します。ドキュメント に記載されている標準的な手順に従って、安全に構成することができます。

一方、Outbound Address Rewrite には制約があります。この機能は Address Rewriting Outbound Agent に依存しており、MAIL FROM が「認証済み」として扱われる場合にのみ動作します。具体的には、X-MS-Exchange-Organization-AuthAs: Internal ヘッダーが付与されている必要があります。

一見すると、Basic 認証や統合 Windows 認証を使えば条件を満たせるように見えます。しかし、スタンドアロン Edge Transport 環境では そうなりません。スタンドアロン Edge Transport に送信する際にどの認証方式を使っても、X-MS-Exchange-Organization-AuthAs ヘッダーは常に Anonymous になります。

その結果、通常の構成では Outbound Address Rewrite エージェントは実行されません。

スタンドアロン Edge Transport でメッセージを Internal として扱わせ、Outbound Address Rewrite を有効にするための唯一のサポートされた方法は、受信コネクタに ExternalAuthoritative 認証を設定することです。これにより、AuthAs の値は実質的に Internal になります。

ただし、ExternalAuthoritative を有効にすると、受信コネクタは実質的に オープン リレー のような状態になります。そのため、IP アドレス制限や厳格なアクセス制御などの適切な対策を必ず実施し、不正利用を防ぐ必要があります。詳細はこの 記事 を参照してください。

スタンドアロン Edge Transport から送信されるメールに対して、Microsoft 365 の IP スロットリングはどのように適用されるか?
「Exchange Online をスマートホストとして設定する」セクションの推奨に従っている場合、Hybrid メール フローと同様の扱いになります。オンプレミスのハイブリッド Exchange 環境からスタンドアロン Edge Transport へ移行する場合は、従来の Exchange Server で使っていたグローバル IP アドレスを、そのまま新しい Edge Transport でも継続して使うことを推奨します。これは、その IP アドレスに既存の送信実績があり、信頼性（レピュテーション）が確立されているためです。

スタンドアロン Edge Transport を Azure VM として展開できるか?
展開は可能です。ただし、Azure VM からの SMTP アウトバウンドは、Enterprise Agreement または Microsoft Customer Agreement for enterprise (MCA-E) サブスクリプションを利用している場合にのみサポートされます。詳細はこの 記事 を参照してください。

また、アプリケーションから Azure VM への適切なネットワーク接続を確立する必要があります。通常は、Azure ExpressRoute などのネットワーク ルーティングを構成し、オンプレミスから Edge Transport VM へ安全かつ安定して通信できるようにします。

Edge Transport で Exchange Online をスマートホストとして使っているが、メールが “AuthAs:Anonymous” として受信される。Internal 扱いに変更できるか?
Edge Transport 役割は、Edge が Mailbox Exchange Server にサブスクライブされているか、スタンドアロンかにかかわらず、ヘッダーの昇格 (header promotion) を行いません。この処理は、Mailbox 役割が担当しており、Organization ヘッダーを CrossPremises へ昇格させたうえで、Edge はその結果をそのまま使用します。ヘッダー昇格の詳細はこの 記事 を参照してください。

Edge Transport から送信されたメッセージを “AuthAs:Internal” として扱うための唯一の方法は、Exchange Online の Inbound コネクタで TreatMessagesAsInternal 属性を有効にすることです。この方法は、送信元ドメインが Exchange Online の承認済みドメインと一致している場合にのみ有効です。

本記事のレビューとサポートをいただいた Arindam Thokder 氏に感謝します。

今回は、何度か質問を受けたテーマを短く取り上げます。組織でリソース メールボックスを作成したものの、実際にどのメールボックスが使われているのか把握したい、というケースを考えてみてください。もっともな要望です。

ここでいうリソース メールボックスには、会議室メールボックス、設備メールボックス、Workspace が含まれます。残念ながら、本記事執筆時点では、リソース メールボックスの実際の利用状況を把握できるネイティブ レポートはありません。そこで、その状況を把握するためのいくつかの方法を紹介します。環境に合うものを選んでください。

オプション 1: Get-CalendarViewDiagnostics を使う

Get the ID of a meeting - Exchange | Microsoft Learn

この方法では、指定したメールボックスの予定表を確認し、指定した期間内に予定表に存在するすべての会議の情報を出力できます。

次の例では、過去 6 か月から未来 6 か月までの予定表上の会議一覧を取得します。

1

Get-CalendarViewDiagnostics resource@contoso.com -WindowStartUtc (Get-Date).AddMonths(-6) -WindowEndUtc (Get-Date).AddMonths(6)

この方法は高速に結果を返し、対象も予定表に限定されます。一方で、会議の件名は公開されているプロパティではないため、取得できません。

ただし、どの会議室に予定が入っているか、あるいは全体件数だけを把握したいのであれば、この方法は非常に有効です。

この方法の利点は、Exchange Online PowerShell に豊富なフィルター機能があることです。たとえば、会議室メールボックスだけ、あるいは設備メールボックスだけを対象に簡単に絞り込めます。

例:

1
2

$roommailboxes = Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails RoomMailbox
$roommailboxes | ForEach { Write-Host "Processing Mailbox $($_.Displayname)" ; Get-CalendarViewDiagnostics $_ -WindowStartUtc (Get-Date).AddMonths(-6) -WindowEndUtc (Get-Date).AddMonths(6) }

オプション 2: Graph を使って予定表イベントの詳細を取得する

List calendarView - Microsoft Graph v1.0 | Microsoft Learn

リンク先の記事の下部に、要求例が掲載されています。これを PowerShell で使うには、Microsoft.Graph.Calendar モジュールと、適切な Graph 権限を追加した Microsoft Entra ID のアプリ登録が必要です。

利用できる権限の種類は、委任された権限またはアプリケーション権限です。

• 委任された権限では、ユーザー アカウントを使って Graph API にアクセスするため、サインインが求められます。
• アプリケーション権限は、サインイン画面を使えない非対話型のアプリケーションやスクリプト向けです。

アプリケーション権限を使う例を示します。

1. Microsoft Entra ID でアプリ登録を作成します。
2. Graph のアプリケーション権限 Calendars.Read を追加します。これにより、アプリケーションはすべてのメールボックスの予定表データを読み取れます。
3. 認証用のクライアント シークレットを作成するか、証明書をアップロードします。証明書を使う場合は、自己署名証明書でもかまいません。
4. PowerShell を起動して Graph モジュールをインポートします。

1

Import-Module Microsoft.Graph

5. 証明書を使って PowerShell から Graph に接続します。

1

Connect-MgGraph -ClientId <App ID> -TenantId <your tenant ID> -CertificateThumbprint <cert thumbprint>

または、クライアント シークレットを使って接続します。

1

Connect-MgGraph -ClientSecretCredential -TenantId <your tenant ID>

6. 指定した期間の予定表アイテムを一覧表示し、開催者、件名、開始時刻、終了時刻などのプロパティを表示します。ここでも、Get-CalendarViewDiagnostics と同じく、過去 6 か月から未来 6 か月までを対象にしています。

1

Get-MgUserCalendarView -UserId resource@contoso.com -StartDateTime (Get-Date).AddMonths(-6) -EndDateTime (Get-Date).AddMonths(6) | select @{n='Organizer';e={$_.Organizer.EmailAddress.Name}}, subject, @{n='StartTime';e={$_.Start.DateTime}},@{n='EndTime';e={$_.End.DateTime}}

Graph にもフィルター機能はありますが、個人的には Exchange Online PowerShell ほど簡単ではありません。Exchange Online PowerShell と Graph PowerShell の両方に同じセッションで接続できるのであれば、両者を組み合わせて、変数に格納したメールボックス一覧に対して実行できます。

例:

まず、Exchange Online PowerShell でメールボックス一覧を取得します。

1

$roommailboxes = Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails RoomMailbox

次に、Graph PowerShell を使って予定表イベントを取得します。

1

$roommailboxes | foreach {Write-Host "Processing Mailbox $($_.DisplayName)"; Get-MgUserCalendarView -UserId $_.PrimarySmtpAddress -StartDateTime (Get-Date).AddMonths(-6) -EndDateTime (Get-Date).AddMonths(6) | select @{n='Organizer';e={$_.Organizer.EmailAddress.Name}}, subject, @{n='StartTime';e={$_.Start.DateTime}},@{n='EndTime';e={$_.End.DateTime}}}

上の例で示したもの以外にも、利用できるプロパティはあります。どのプロパティを表示したいかは、ご自身で判断する必要があります。開催者や開始、終了時刻のように Type プロパティとして返るものもあるため、上の例のように式を組み立てて処理する必要があります。Graph は、PowerShell 以外にも HTTP、C#、Java など多くの言語から利用できます。

Graph を使う方法では、特定のメールボックス群だけにアクセスを制限することもできます。たとえば、リソース メールボックスのみに限定するといったことが可能です。

Role Based Access Control for Applications in Exchange Online | Microsoft Learn

これにより、Microsoft Entra ID のアプリが、どのメールボックスから予定表の詳細を取得できるかを制御できます。

設定するには、まず管理スコープを構成し、受信者フィルターを使って対象のメールボックス一覧を定義します。その後、Microsoft Entra ID 側の Graph 権限を削除し、Exchange Online 側で RBAC (New-ManagementRoleAssignment) を使って権限を付与します。

オプション 3: Get-MailboxFolderStatistics を使う

非常にシンプルにリソース メールボックスの利用状況を把握したいだけであれば、Get-MailboxFolderStatistics で十分な場合があります。IncludeOldestAndNewestItems と FolderScope を組み合わせることで、予定表フォルダーを対象にできます。

例:

1

Get-MailboxFolderStatistics resource@contoso.com -IncludeOldestAndNewestItems -FolderScope Calendar

Get-CalendarViewDiagnostics と同様に、複数の受信者に対して一括実行できます。

例:

1

$roommailboxes | Foreach { Get-MailboxFolderStatistics $_ -IncludeOldestAndNewestItems -FolderScope Calendar}

この用途で Get-CalendarDiagnosticObjects は使わないでください

最後に、Calendar Diagnostic Logs と Get-CalendarDiagnosticObjects コマンドレットを使おうとするケースを見かけます。この方法は使わないでください。

Get Calendar diagnostic logs for Exchange Online mailboxes - Exchange | Microsoft Learn

たしかに会議の詳細を取得すること自体はできますが、これは大量の予定表イベントを一括収集する目的で設計されたものではありません。もともとは、個別の会議に関する問題をトラブルシューティングするための仕組みです。Calendar Diagnostic Log のデータには、予定表だけでなく、受信トレイ、送信済みアイテム、削除済みアイテム、さらに Calendar Logging などの回復可能なアイテム フォルダーを含む、予定表関連の情報が格納されるほかのフォルダーのデータも含まれます。単一の会議を照会するだけでも、1,000 件を超えるログが返ることがあります。そのため、多数の会議を対象にメールボックスへ一括実行すると、失敗したり、タイムアウトしたり、エラーが発生したりする可能性があります。この方法を使って問題が発生し、実際その可能性はかなり高いのですが、サポートへ問い合わせても、案内するのは結局ここで紹介した別の方法になります。

まとめると、どのリソース メールボックスが実際に使われているかを把握できるネイティブ レポートはありませんが、利用できる方法はいくつかあります。既に Exchange Online PowerShell に接続しているのであれば、Get-CalendarViewDiagnostics が最も簡単な選択肢かもしれません。Get-CalendarViewDiagnostics で公開されている以上のプロパティが必要な場合や、別の言語を使うカスタム アプリケーションで利用したい場合は、Graph を使う方法を推奨します。

更新 (2026 年 8 月 3 日): [クラウド管理のリモート メールボックス向けの書き戻しが一般提供になりました](/blog/writeback-for-cloud-managed-remote-mailboxes-now-generally-available/)。

前回の記事では、クラウド管理のリモート メールボックスのパブリック プレビューとクラウド管理のリモート メールボックスの一般提供をご紹介しました。これは、組織内の “最後の Exchange Server” を廃止するための重要な一歩です。コミュニティからの反響は非常に大きく、寄せられたフィードバックは今後のロードマップにも反映されています。

今回は、この取り組みに関する 2 つの新しいマイルストーンをお知らせします。

1. クラウド管理のリモート メールボックス向けの書き戻しがパブリック プレビューになりました。
2. 最後の Exchange Server への依存がもう残っていない組織向けに、SOA をクラウドへ移した後に最後の Exchange Server を廃止するガイドを Microsoft Learn で公開しました。

クラウド管理のリモート メールボックス向けの書き戻し: パブリック プレビュー

ディレクトリ同期されたメールボックスで IsExchangeCloudManaged を True に設定すると、Exchange 属性の Source of Authority (SOA) は Exchange Online に移ります。氏名や部署などの ID 属性の SOA は引き続きオンプレミスの Active Directory に残りますが、proxy addresses、アドレス帳への表示 / 非表示、カスタム属性などの Exchange 関連属性はクラウドで編集できるようになります。

これまでは、Exchange 属性の SOA をクラウドへ移しても、その属性はクラウド側で編集できるだけで、オンプレミス AD には戻りませんでした。これは、proxyAddresses やカスタム属性などをオンプレミス AD から直接参照する基幹業務アプリケーションを使っている組織にとって課題でした。SOA がクラウドに移ると、オンプレミス AD 側にあるこれらの属性がクラウドと同期しなくなり、値にずれが生じ始めるためです。

そのギャップを埋めるのが Writeback (書き戻し) です。 書き戻しを有効にすると、Exchange Online で対象の Exchange 属性に加えた変更が、Microsoft Entra Cloud Sync を通じてオンプレミスの Active Directory に自動的に書き戻されます。これにより、オンプレミス AD の情報を最新の状態に保ちつつ、Exchange 属性の SOA をクラウドへ移した後も基幹業務アプリケーションを継続して利用できます。

動作の仕組み

書き戻しでは、Exchange Online からオンプレミス AD への転送に Microsoft Entra Cloud Sync を利用します。すでに Microsoft Entra Connect Sync を利用している場合でも、アンインストールや置き換えは不要です。Cloud Sync は Connect Sync と並行して動作し、Connect Sync はこれまで通りディレクトリ同期を担当し、Cloud Sync は Exchange 属性の書き戻しだけを担当します。既存のメールボックスやユーザー、同期構成に影響はありません。

Cloud Sync のプロビジョニング エージェントのインストール、書き戻し用の同期ジョブの構成、往復同期の確認手順は、次のドキュメントにまとまっています: ハイブリッド環境でのリモート メールボックスの Exchange 属性のクラウド ベースの管理。

パブリック プレビュー中の制限と GA の予定

パブリック プレビュー期間中、書き戻しは 200,000 未満のクラウド管理メールボックスを持つテナントをサポートします。この上限は一般提供 (GA) のタイミングで引き上げます。一般提供はすでに開始されており、詳細はクラウド管理のリモート メールボックス向けの書き戻しの一般提供開始をご確認ください。

どの属性が AD に書き戻され、どの属性が書き戻されないかを含む完全な一覧は、ID、Exchange 属性、および書き戻しで確認できます。

新しいドキュメント: 最後の Exchange Server を廃止する

メールボックスがクラウド管理となり、必要であれば書き戻しも準備できたら、次に浮かぶのは、この取り組み全体の目的である “最後の Exchange Server をどうやって実際に廃止するのか” という疑問です。

この手順を最初から最後まで説明する新しいガイドとして、SOA をクラウドへ移した後に最後の Exchange Server を廃止するを公開しました。

このガイドでは、次の内容を扱っています。

• 前提条件 : すべてのメールボックスとパブリック フォルダーが Exchange Online に移行済みであること、すべてのディレクトリ同期メールボックスがクラウド管理になっていること、DNS とメール ルーティングが Exchange Online を向いていること、SMTP リレーの依存関係を移行済みであることを確認します。
• 削除前の確認 : 環境が変わっている可能性もあるため、作業を始める直前に前提条件をあらためて確認します。
• ハイブリッド構成のクリーンアップ (Exchange 稼働中) : Hybrid Configuration オブジェクト、HCW が作成した IntraOrganizationConnector、ハイブリッド コネクタ、組織の関係、フェデレーション信頼と証明書、OAuth サービス プリンシパル資格情報、Hybrid Agent (モダン ハイブリッドのみ) を削除します。
• 最後の Exchange Server のアンインストール : 最終的なアンインストール前チェックを行い、Setup /m:Uninstall を実行します。
• Exchange Online 側のハイブリッド クリーンアップ (アンインストール後) : オンプレミス側のアンインストールでは削除されない、クラウド側の孤立したハイブリッド オブジェクトを削除します。

これまで、最後の Exchange Server の削除手順が最初から最後まで明確に文書化されていないことを理由に作業を保留していた場合は、まさにそのためのドキュメントです。

始めるには

廃止に向けた取り組みを始めるために書き戻しのパブリック プレビュー開始を待っていたなら、今が着手のタイミングです。

• 書き戻しの設定手順と属性一覧について、更新されたドキュメントを確認する。
• エンドツーエンドのアンインストール手順について、新しい廃止ガイドを読む。
• 書き戻しの 200k 制限が導入の妨げになっている場合は、こちらのフォームから連絡する。GA のタイミングで上限を引き上げる予定ですが、どの規模であれば導入できるのか把握したいとしています。
• コメント欄で経験や提案を共有する。皆さまのフィードバックがこれまでのリリースを形作ってきました。今回もご意見をお待ちしています。

“AD を同期しているから” という理由だけで Exchange Server を維持する時代は、終わりに近づいています。

2026 年 7 月 14 日更新: 2026 年 7 月のセキュリティ更新プログラムのリリース ブログ記事をご確認ください。インストール後は、CVE-2026-42897 の緩和策を継続して適用しておくことを推奨する必要がなくなります。2026 年 7 月の Exchange Server のセキュリティ更新プログラムが公開されました

2026 年 5 月 14 日、Microsoft は Exchange Outlook Web Access (OWA) に影響する報告済みの脆弱性 CVE-2026-42897 を公開しました。攻撃者は特別に細工したメールを利用者に送信することで、この問題を悪用する可能性があります。利用者が Outlook Web Access でそのメールを開き、一定の操作条件が満たされると、ブラウザーのコンテキストで任意の JavaScript が実行される可能性があります。

影響を受けるオンプレミスの Exchange Server バージョンは次の通りです。

• Exchange Server 2016 (すべての更新レベル)
• Exchange Server 2019 (すべての更新レベル)
• Exchange Server Subscription Edition (SE) (すべての更新レベル)

Exchange Online はこの脆弱性の影響を受けません。

緩和策

オプション 1 (推奨): Exchange Emergency Mitigation サービス (Exchange EM Service)

Exchange EM Service を有効にしている組織向けに、Microsoft は Exchange Server 2016、2019、SE 用の自動緩和策を公開しました。この緩和策は既に公開済みで、自動的に有効化されます。

あらためての案内になりますが、EM Service は 2021 年 9 月にリリースされ、既定で有効になっています。このサービスの詳細は、Exchange Emergency Mitigation (EM) サービス をご確認ください。

EM Service を有効にしている組織では、サーバーに CVE-2026-42897 向けの緩和策が適用されているかどうかを次の方法で確認できます。緩和策の ID は M2.1.x です。

• ドキュメントの Viewing Applied Mitigations に記載された手順で確認する
• 組織内の EM Service の状態と適用済み緩和策をすばやく確認するには、Exchange Health Checker スクリプト を実行する。HTML レポートには EEMS check の結果が含まれます

EM Service は、この脆弱性をすぐに緩和するための最善の方法です。現在 EM Service を無効にしている場合は、直ちに有効化することを推奨します。

なお、サーバーで稼働している Exchange Server のバージョンが 2023 年 3 月より前のものである場合、EM Service は新しい緩和策を確認できません。詳細は、Exchange Emergency Mitigation サービスは大幅に更新が遅れているサーバーでは機能しない可能性があります をご確認ください。現在利用している Exchange の正確なバージョンは、Exchange Server のビルド番号とリリース日 のページにあるオプション 1 またはオプション 2 で確認できます。

オプション 2: スクリプトによる緩和策の適用

EM Service を利用できない組織 (たとえば、切断された環境やエアギャップ環境) 向けに、次の手順でこの緩和策を有効化できます。

1. 次の URL から、最新版の Exchange on-premises Mitigation Tool (EOMT) をダウンロードします。

   https://aka.ms/UnifiedEOMT

2. 管理者権限で起動した Exchange 管理シェル (EMS) からスクリプトを実行し、サーバーごと、またはすべてのサーバーへ一括で緩和策を適用します。

単一サーバー:

1

.\EOMT.ps1 -CVE "CVE-2026-42897"

すべてのサーバー:

1

Get-ExchangeServer | Where-Object { $_.ServerRole -ne "Edge" } | .\EOMT.ps1 -CVE "CVE-2026-42897"

なお、OWA へのアクセスに Internet Explorer または Internet Explorer モードの Microsoft Edge を利用しているクライアントでは、緩和策は機能しません。Internet Explorer は Content Security Policy (CSP) をサポートしていないためです。

緩和策適用時の既知の問題

上記いずれかの方法で CVE-2026-42897 の緩和策を適用した後、次の既知の問題が発生する場合があります。

• OWA のカレンダー印刷機能が動作しないことがあります。回避策として、印刷したいカレンダーの内容をコピーするかスクリーンショットを取得するか、デスクトップ版の Outlook を利用してください。
• 受信者側の OWA の閲覧ウィンドウで、インライン画像が正しく表示されないことがあります。回避策として、画像はメール添付ファイルとして送信するか、デスクトップ版の Outlook を利用してください。
• OWA Light バージョン (OWA の URL の末尾が /?layout=light のもの) は正しく動作しません。この機能は数年前に既に 非推奨 になっており、通常の本番運用向けではありません。OWA Light は今後数か月以内に恒久的に無効化される予定です。詳細は、Exchange Server における OWA Light 廃止のお知らせ をご確認ください。
• 緩和策の適用後、OWACalendar.Proxy healthset が Unhealthy と表示され始めることがあります。Exchange Server の各種監視ソリューションを利用している場合、これによりアラートが発生する可能性があります。この問題が発生した場合は、修正が提供されて緩和策が解除されるまで、監視プラットフォーム側でこれらのアラートを無視することを推奨します。
• 公開された予定表が 500 エラーで正常に動作しない場合があります。
• 緩和策の詳細に “Mitigation invalid for this exchange version.” と表示されることがあります。これは表示上の問題であり、状態が “Applied” となっていれば緩和策は正しく適用されています。この問題への対処方法は現在調査中です。

恒久的な対処

Microsoft は、影響を受ける Exchange Server バージョン向けのセキュリティ更新プログラムを準備しており、今後リリースと告知を行う予定です。リリースされた更新プログラムの詳細は、2026 年 6 月の Exchange Server のセキュリティ更新プログラムが公開されました をご確認ください。

Exchange SE 向けの更新プログラムは、一般公開のセキュリティ更新プログラムとして提供されます。一方、Exchange Server 2016 と Exchange Server 2019 向けの更新プログラムは、Exchange Server 2016/2019 向け ESU プログラム 第 2 期 提供開始のお知らせ にある通り、第 2 期 Exchange Server ESU プログラムに参加している組織にのみ提供されます。第 1 期のみ参加していた組織は、2026 年 4 月でそのプログラムが終了しているため、この更新プログラムを受け取れません。

このブログ記事の更新履歴:

• 2026/07/08: OWA Light が今後数か月以内に恒久的に無効化される予定であることを追加 (Exchange Server における OWA Light 廃止のお知らせ)
• 2026/06/09: 2026 年 6 月の Exchange Server のセキュリティ更新プログラムが公開されました の内容を反映
• 2026/05/20: 公開された予定表の既知問題を追加
• 2026/05/18: 緩和策では Internet Explorer または Internet Explorer モードの Microsoft Edge を利用するクライアントは保護されないという注記を追加
• 2026/05/17: OWACalendar.Proxy healthset が Unhealthy と表示される既知の問題を追加
• 2026/05/14: OWA Light に関する既知の問題を追加
• 2026/05/14: 緩和策の ID (M2.1.x) を追加
• 2026/05/14: 緩和策の詳細に誤った Description が表示される既知の問題を追加

Microsoft は、以下の製品向け Hotfix Update (HU) を公開しました。

• Exchange Server Subscription Edition (SE)

今回の HU は、以下の特定のバージョンの Exchange Server に対して提供されています。

• Exchange SE RTM

2026 年 5 月の HU には、新しい Exchange Server のセキュリティ更新プログラムは含まれていませんが、新機能が含まれています。詳細は公開された KB 情報をご確認ください。

Exchange のハイブリッド リッチ共存呼び出しを Graph API へ移行する更新

2026 年 5 月の Hotfix 更新には、Exchange Server のハイブリッド リッチ共存で利用する呼び出しを、Exchange Web Services (EWS) から REST ベースの Microsoft Graph API に切り替えられる機能が含まれています。これは、ハイブリッド展開における Exchange Server のセキュリティ変更 で案内した取り組みの継続となります。

注: Exchange 2016 と 2019 はサポートが終了しています。これらのバージョン向けに、Graph API のハイブリッド呼び出しを利用するための更新プログラムは提供されません (Exchange 2016 / 2019 の ESU で提供される更新にも、この機能は含まれません)。 現在も Exchange 2016 または 2019 でオンプレミスのメールボックスを運用している場合は、2026 年 10 月以降もテナントで EWS の利用を許可 する必要があります。さらに、Exchange Online で EWS が無効化される 2027 年 4 月までに、すべてのサーバーを Exchange SE へ必ずアップグレードする必要があります。これらのサポート対象外バージョンにおけるリッチ共存機能は、2027 年 4 月以降は完全に動作しなくなります。そのため、オンプレミス環境については、できるだけ早急にサポート対象外のバージョンからアップグレードしてください。サポート対象外バージョンの利用は、環境にリスクをもたらす可能性があります。

詳細は、Exchange SE ハイブリッドのオンプレミス リッチ共存を Graph API に移行する方法 と Exchange ハイブリッド専用アプリを展開する をご確認ください。

更新プログラムのインストール

利用可能な更新パスは以下の通りです。

• Exchange Server Health Checker スクリプトを使用して、更新が必要な Exchange サーバーのインベントリを作成し、各サーバーの更新状況 (CU、SU、手動対応) を確認してください。
• 最新の CU をインストールします。Exchange Update Wizard を利用して、現在の CU と目標 CU を選択し、手順を確認してください。
• 更新プログラムのインストール後に再度 Health Checker を実行し、追加の対応が必要かどうかを確認します。
• セットアップ完了後、サーバーを再起動し、すべての Exchange サービスが正常に起動したことを確認します。一部のサービスが無効状態になっている場合は、更新プログラムのインストールが何らかの理由で中断されたことを示しています。詳細については、この記事の「回避策 1」を参照してください。
• Exchange Server のインストール中やインストール後にエラーが発生した場合は、SetupAssist スクリプト を実行してください。更新後に問題が発生した場合は、失敗した Exchange Server の更新プログラムの修復方法 や、ファイル バージョン エラーに関する KB 記事 も確認してください。

Hotfix 更新の FAQ

なぜこの HU は月初に公開されたのですか。緊急の更新ですか。
Hotfix 更新プログラムはセキュリティ更新を含まないため、「Patch Tuesday」の公開スケジュールには連動しません。Exchange の Hotfix Update は任意のものとなります。

直近のセキュリティ更新プログラムをインストールしました。後から公開された Hotfix 更新プログラムもインストールすべきですか？
Exchange Server の HU は オプションの更新プログラム ですが、組織にとって有益な機能や修正が含まれている場合があります。詳細については、リリース KB 記事をご確認ください。

以前のセキュリティ更新プログラムをまだインストールしていません。後からリリースされた HU をインストールする前に、最後に利用可能な SU をインストールする必要がありますか？
Exchange の更新プログラム (HU または SU) はすべて 累積更新 です。そのため、新しい SU または HU には、以前の古い SU または HU の変更内容も含まれます。古い更新を未適用でも、新しい更新を直接適用して問題ありません。

私たちの Exchange サーバーは Windows/Microsoft Update を通じて自動的に更新されます。その場合、HU 更新プログラムも自動的にインストールされますか？
この HU はサーバー向けの任意の更新です。Microsoft Update Catalog には公開されません。必要な場合は Download Center から入手してください。

HU でリリースされた新機能や修正は今後の更新プログラムにも含まれますか、それともこの特定の HU をインストールする必要がありますか？
この HU に含まれる内容は、今後リリースされる Exchange SE の更新プログラムにも含まれます。

HU を (必要に応じて) アンインストールすることは可能ですか？
はい。HU は SU と同様にアンインストールすることが可能です。

この記事の公開時点では、関連するドキュメントが完全に利用可能でない場合があります。

この記事は今後更新される可能性があります。更新があれば、ここに追記されます。

Exchange ActiveSync (EAS) の証明書ベースの認証 (CBA) を Exchange Online に直接行う方式の廃止を発表します。2026 年末までに、直接的な CBA 接続のサポートを終了します。その日以降、CBA を使用する EAS クライアントは Microsoft Entra ID を介して認証を行う必要があります。クライアント証明書を直接 Exchange Online に送信することはできなくなります。

即時適用として、新しいテナントがレガシー フローを使用できないようにブロックを展開し、最初から Entra ID フローのメリットを享受できるようにします。

重要: この変更は、Outlook Mobile やオンプレミスの Exchange Server など、他の Exchange Online の認証シナリオには影響しません。この変更は、Exchange Online に対して CBA を使用する Exchange ActiveSync (EAS) クライアント (ネイティブの組み込みモバイル メール アプリなど) に固有のものです。この廃止は、Exchange Online におけるレガシー認証パターンの排除によるセキュリティ強化の継続的な取り組みの一環です。

なぜ直接 EAS CBA を廃止するのか？

EAS の証明書ベースの認証は、組織がパスワードなしでモバイル デバイスのアクセスを許可するための方法として導入されました。クライアント証明書を使用して、高度にセキュアなパスワードレスのサインイン体験を提供します。CBA では、各ユーザーはテナントのルート証明機関によって検証された証明書を持ち、その証明書の公開キーを使用した TLS ハンドシェイクによって認証を行います。つまり、秘密キーやパスワードがネットワーク上で送信されることはなく、基本認証よりも安全な代替手段を提供します。この構成に関するこれまでのガイダンスはこちらにあります。

しかし、現在の Exchange への直接的な EAS CBA の実装はレガシー認証方式と見なされています。現在のフローでは、ユーザー証明書は MDM 構成中にモバイル デバイスにプッシュされます。ユーザーが EAS に接続してメールを同期する際、Exchange が証明書を受信し、後続のすべての処理と検証を自ら行います。

この設計には重大な懸念があります。クライアント自体が標準の OAuth アクセス トークンを取得しないため、最新の認証プラクティスから逸脱しています。また、Exchange は内部的な高権限メカニズムに依存してデータにアクセスします。さらに、Microsoft Entra ID はクライアントと Exchange Online 間の直接的な証明書ベースの認証を「レガシー認証」の一形態として分類しており、レガシー認証をブロックする条件付きアクセス ポリシーによってブロックされます。これにより、管理者はレガシー認証をすべてブロックするか、CBA を含めてすべて許可するかの二択を迫られることになります。

新しいモデルでは、他のクライアント アプリと同様に、EAS クライアントが Microsoft Entra ID に対して直接証明書ベースの認証を行うことが求められます。提案されるセキュアなフローは次のとおりです。
クライアントは検証のために証明書を Microsoft Entra ID に送信し、Microsoft Entra ID が証明書を検証して OAuth アクセス トークンをクライアントに返します。
その後、クライアントはこの OAuth トークンを Exchange Online に提示して認証を行います。
証明書認証を完全に Microsoft Entra ID に移行することで、管理者は特定のプロトコルに対する例外なく、すべてのクライアント アクセスに対して最新のセキュリティ制御とポリシーを統一的に適用できます。

この変更は、Exchange Online の認証スタックを最新化する継続的な取り組みの一環でもあります。過去数年間で基本認証などの旧式の認証方式を段階的に廃止し、最近では専用の ActiveSync CBA エンドポイント (マルチテナント向けの outlook-cba.office365.com、DoD 向けの outlook-dod-cba.office365.us、GCC-High 向けの outlook-cba.office365.us) を導入しました。これにより TLS 1.3 のサポートを追加し、セキュリティと信頼性を強化しています。Entra ベースの CBA を要求することは、この取り組みにおける次の論理的なステップであり、レガシー認証の排除における最後の残りのギャップの 1 つを解消するものです。

影響を受けるかどうかの確認方法

Exchange ActiveSync CBA を使用しているか Entra ベースの CBA を使用しているか不明な場合、確認する方法がいくつかあります。

まず、モバイル デバイス管理 (MDM) 構成を管理している担当者に確認してください。認証タイプが OAuth ではなく Certificate に設定されている場合、この構成を使用している可能性があります。

もう 1 つの方法は、Entra のサインイン イベント ログを確認することです。Exchange CBA を使用するリクエストは、クライアント アプリが「Exchange ActiveSync」として表示され、認証の詳細に証明書が使用されていることが示されます。以下は、Entra のサインイン ログ レポートでのフローの表示例です。

認証方法として「Certificate」が表示されます。

今後 1 週間以内に、Exchange CBA を使用しているテナントに対してこの変更に関するメッセージ センター投稿を送信する予定です。投稿が送信された後、この記事を更新します。

CBA 認証は意図的に構成する必要があるものであり、組織で構成していない場合、この廃止の影響は受けません。

Entra ベースの CBA への移行方法

Exchange ActiveSync で CBA を使用してモバイル デバイスのセキュリティを強化してきた組織があることを理解しています。スムーズな移行を確保するため、管理者は 2026 年末の期限よりも十分前に、デバイスを新しい Entra ID ベースの CBA 方式に移行する計画を今すぐ開始することをお勧めします。Entra CBA と EAS CBA の PKI および CA のセットアップは基本的に同じであるため、移行は簡素化されるはずです。以下は、移行を成功させるための主要な手順と考慮事項です。

• Microsoft Entra CBA をテナントで有効にする: 証明機関 (CA) が Microsoft Entra ID で構成されていることを確認します。少なくとも 1 つの CA と中間 CA が構成されている必要があり、各ユーザーは信頼された PKI から発行された証明書にアクセスできる必要があります。また、各 CA にはインターネットに公開された URL から参照可能な証明書失効リスト (CRL) が必要です。Microsoft は ドキュメントで Entra CBA のセットアップに関する詳細なガイダンスを提供しています。
• ユーザー証明書の準備: 各ユーザーのクライアント証明書に正しい ID 情報が含まれていることを確認します。Exchange ActiveSync クライアントでは、証明書にユーザーの Exchange Online でのルーティング可能なメール アドレスが含まれている必要があります。Subject Alternative Name (SAN) フィールドの Principal Name または RFC822 Name の値に含まれている必要があります。Microsoft Entra ID は RFC822 Name の値をディレクトリのプロキシ アドレス属性にマッピングします。詳細はこちらを参照してください。現在の証明書が直接 EAS CBA に使用されていた場合、この要件を既に満たしている可能性が高いですが、証明書の SAN にユーザーのメール アドレスが含まれていることを確認してください。
• デバイス構成の更新: モバイル デバイスが Entra ID に対して証明書認証を行う方法を計画します。多くの場合、デバイスのメール プロファイルや MDM/Intune デバイス構成プロファイルの更新が必要になる場合があります。新しいフローでは、変更をサポートするためにサードパーティのクライアント ベンダーとの連携が必要になる場合があります。クライアント証明書を使用した Entra (Azure AD) 認証の有効化に関する具体的な手順については、モバイル デバイスまたはメール アプリのベンダーにお問い合わせください。この機能が構成されると、ユーザーはサインイン時にパスワードを入力する代わりに、証明書の選択プロンプトが表示されます。
• テストと監視: 広範な展開の前に、パイロット グループのデバイスとユーザーで新しい Entra CBA ログイン フローをテストすることをお勧めします。Entra ID のサインイン ログと Exchange ActiveSync デバイス レポートを監視して、レガシー CBA 方式を引き続き使用しているデバイスを特定してください。古い方式を使用しているユーザーに積極的に連絡し、更新された構成への移行を支援してください。
• 廃止のタイムライン: 計画にあたっては 2026 年末の期限を念頭に置いてください。サービスの中断を避けるため、この日付よりも十分前に移行を完了することをお勧めします。その間、直接影響を受けるテナントにはメッセージ センターを通じて詳細を共有し、移行をサポートするためにドキュメントを必要に応じて更新します。

まとめ

直接 Exchange ActiveSync CBA を引き続き使用しているお客様には、Entra ベースの CBA への移行計画を今すぐ開始することを強くお勧めします。Microsoft Entra の方式は、証明書ベースでフィッシング耐性があり、パスワード不要という点で同等かそれ以上のセキュリティを提供するうえ、最新の認証エコシステムやセキュリティ制御との統合がはるかに優れています。この変更は、すべての Exchange Online 接続が最新のセキュリティ標準に準拠することを確保し、不必要な昇格された権限を持つ内部的な高権限トークンへの依存を排除することで、組織のデータを保護するのに役立ちます。

認証インフラストラクチャへの変更が困難であることを理解しているため、この移行のために 2026 年末まで長い猶予期間を設定しています。この期間を通じてガイダンスとサポートを引き続き提供します。これらのセキュリティ改善の導入にご協力いただきありがとうございます。共に、すべてのお客様にとって、より安全でセキュアな Exchange Online エクスペリエンスを実現しましょう。ご質問や Entra CBA のセットアップに関するサポートが必要な場合は、Microsoft サポート (Entra / Identity) またはアカウント チームにお問い合わせください。この移行をできるだけスムーズに進められるよう、サポートいたします。

メールボックスのインポートおよびエクスポート用 Microsoft Graph API が、一般提供 (GA) になりました。パブリック プレビューを経て、本番環境で利用できる状態になり、組織や開発者は Microsoft Graph を通じて Exchange Online のメールボックス データをより効率的に管理、移行、統合できるようになります。

昨年、従来の Exchange Web Services (EWS) API に代わる、モダンで堅牢な選択肢としてメールボックスのインポート / エクスポート API のパブリック プレビューを公開しました。EWS の廃止が予定されている中で、Exchange Online のメールボックス データを完全な忠実度でインポートおよびエクスポートできる、安全でスケーラブルな将来志向のソリューションが求められていました。プレビュー期間中には多くのフィードバックが寄せられ、本番環境向けに API の改善と強化が行われました。

一般提供で利用できる主な機能

• メールボックス階層の探索: メールボックス構造をたどり、フォルダーやサブフォルダーにアクセスし、個々のメールボックス アイテムを列挙できます。
• メールボックス アイテムの完全な忠実度でのサポート: IPM サブツリー内で、メッセージ、連絡先、予定表アイテムを含むあらゆる種類のメールボックス アイテムにアクセスできます。
• フォルダー管理: メールボックス フォルダーの作成、更新、削除を行い、必要に応じてメールボックス コンテンツを整理できます。
• 拡張プロパティ: フォルダーやアイテムに対して単一値および複数値の拡張プロパティを利用でき、標準の Microsoft Graph メタデータでは表現できない独自のデータ シナリオに対応できます。
• きめ細かなアクセス許可スコープ: アプリケーションやユーザーが必要な範囲でのみメールボックス データを読み取り、エクスポート、インポートできるように、細かい制御を適用できます。

サポート対象

初期の GA リリースでは、次のメールボックス タイプがサポートされます。

• プライマリ メールボックス
• 共有メールボックス

一方で、初期の GA リリースには次のメールボックス タイプは含まれていません。

• アーカイブ メールボックス
• パブリック フォルダー
• グループ メールボックス

これらのメールボックス タイプも重要であることは認識されており、特に EWS からの移行を計画している組織やパートナーにとっては関心の高い項目です。これらの領域の対応は引き続き進められており、今後の進捗は別途案内される予定です。

また、エクスポートされるアイテム形式は、汎用的なデータ交換形式として使うことを目的としたものではなく、アイテムの忠実度を維持するために意図的に不透明な形式になっています。つまり、サポートされる正しい利用パターンは、アイテムをエクスポートし、返されたストリームを保持したうえで、それを Exchange Online メールボックスへ再インポートするために使うことです。

スロットリング、可搬性、本番利用時の考え方

メールボックスのインポート / エクスポート API では、Microsoft Graph の他の Outlook リソースと同じ標準の Outlook resource limits が適用されます。

詳細情報と利用開始

プレビュー段階で API を評価していた場合、API モデルは大きく変わっていないため、プライマリ メールボックスや共有メールボックスのシナリオでは GA 版への移行は比較的スムーズです。これから使い始める場合は、まず Microsoft Learn の Use the mailbox import and export APIs in Microsoft Graph を参照し、その後で自分のシナリオに対応するインポートおよびエクスポート メソッドを確認してください。

約 1 年前に、ハイブリッド展開における Exchange Server のセキュリティ変更 を案内しました。この変更は、一部のメールボックスをオンプレミスでホストしていて、オンプレミス ユーザーが Exchange Online ユーザーとのリッチ共存機能 (空き時間情報の参照、メール ヒント、プロフィール写真の共有) を必要とする Exchange ハイブリッド環境に影響するものです。

この変更は、次の 2 段階で計画されていました。

• ステージ 1: Exchange ハイブリッド専用アプリへの移行。これは 2025 年 10 月に完了しました。オンプレミスでメールボックスをホストしている Exchange ハイブリッド環境では、オンプレミス ユーザーのリッチ共存機能を維持するために、Exchange ハイブリッド専用アプリの作成が必要になっています。
• ステージ 2: Exchange ハイブリッドにおける EWS 呼び出しの廃止と、REST ベースの Microsoft Graph API 呼び出しへの切り替え。現在はこの段階にあります。なお、リッチ共存のすべてのシナリオがまだ完全にサポートされているわけではなく、すべてのクラウド環境で Graph API を使ったハイブリッド呼び出しを利用できるわけでもありません。詳細は、ドキュメント をご確認ください。

Exchange Online における Exchange Web Services (EWS) の廃止は最終段階に近づいています。詳細は、Exchange Online EWS：廃止期限が迫っていますをご確認ください。このため、リッチ共存機能を必要とするすべての組織は、ステージ 1 をすでに完了している場合も含めて、オンプレミス環境に Exchange Server Subscription Edition (Exchange SE) の更新プログラムをインストールし、Exchange ハイブリッド専用アプリの権限を、より細かい Graph API の権限モデルへ切り替える必要があります。この対応は、2026 年 10 月までに完了する必要があります (この時点で EWS は既定で無効化されます)。遅くとも、Exchange Online で EWS が恒久的に無効化される 2027 年 4 月までには完了が必要です。

次の図は、ハイブリッド セキュリティ強化のタイムラインにおけるステージ 2 を示しています。

Graph API をハイブリッド ワークフローで使い始める Exchange ハイブリッド利用組織が実施すべきこと

ステップ 1: オンプレミスの Exchange SE サーバーに、2026 年 5 月の Hotfix Update (またはそれ以降) をインストールします。

• 関連リンク : 2026 年 5 月の Exchange Server の Hotfix 更新プログラムが公開されました

ステップ 2: すべてのオンプレミス Exchange SE サーバーに更新プログラムのインストールが完了したら、サポートされているシナリオで Graph API ベースのハイブリッド ワークフローを有効化するため、ドキュメント に記載された手順を実施します。

注: Exchange 2016 と Exchange 2019 はサポートが終了しています。これらのバージョン向けに、Graph API を利用するハイブリッド呼び出しのための更新プログラムは提供されません (Exchange 2016/2019 の ESU として提供される更新プログラムにも、この機能は含まれません)。引き続き Exchange 2016 または Exchange 2019 サーバーでオンプレミスのメールボックスをホストしている場合、2026 年 10 月以降もテナントで EWS の利用を許可し続ける必要があり、2027 年 4 月までにすべてのサーバーを Exchange SE にアップグレードする必要があります (この時点で Exchange Online の EWS は無効化されます)。サポート対象外のバージョンでは、リッチ共存機能は 2027 年 4 月に恒久的に動作しなくなります。できるだけ早く、サポート対象外のオンプレミス環境をアップグレードすることを強く推奨します。サポート対象外のバージョンを運用し続けることは、環境を危険にさらす可能性があります。

Exchange ハイブリッド専用アプリの作成と利用に関する FAQ は、機能ドキュメント をご確認ください。