<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
  <title>Japan Exchange &amp; Outlook Support Blog</title>
  
  <subtitle>日本マイクロソフト Exchange &amp; Outlook サポート チームのブログです</subtitle>
  <link href="https://jpmessaging.github.io/blog/atom.xml" rel="self"/>
  
  <link href="https://jpmessaging.github.io/blog/"/>
  <updated>2026-03-12T01:00:00.000Z</updated>
  <id>https://jpmessaging.github.io/blog/</id>
  
  <author>
    <name>jpmessaging</name>
    
  </author>
  
  <generator uri="https://hexo.io/">Hexo</generator>
  
  <entry>
    <title>Copilot in Outlook：メールと予定表の新しいエージェント体験</title>
    <link href="https://jpmessaging.github.io/blog/copilot-in-outlook-new-agentic-experiences-for-email-and-calendar/"/>
    <id>https://jpmessaging.github.io/blog/copilot-in-outlook-new-agentic-experiences-for-email-and-calendar/</id>
    <published>2026-03-12T01:00:00.000Z</published>
    <updated>2026-03-12T01:00:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>※ この記事は、<a href="https://techcommunity.microsoft.com/blog/outlook/copilot-in-outlook-new-agentic-experiences-for-email-and-calendar/4499798">Copilot in Outlook: New agentic experiences for email and calendar</a> の抄訳です。最新の情報はリンク先をご確認ください。この記事は Microsoft 365 Copilot および GitHub Copilot を使用して抄訳版の作成が行われています。</p><p>Microsoft 365 Copilot は、単発の指示に応答するタスク実行型のエクスペリエンスから、業務用アプリに組み込まれたエージェント型エクスペリエンスへシフトしています。Outlook では、Copilot がメールや予定表において、コンテキストを失ったり余計な操作を増やしたりすることなく、ユーザーの要件をそのまま実行へとつなぐことをサポートします。</p><p>Copilot in Outlook は Work IQ を基盤として、関連するメール、会議、予定表の利用傾向、ならびにそれらの関係性を活用することで、仕事を効率的に進められるよう支援します。また、変更は Outlook 内で直接行われるため、内容を確認・見直ししながら、簡単に改善を重ねることができます。<a href="https://demos.microsoft.com/Microsoft/play/5875/march-moment-agent-apps#/0/1"><strong>今すぐ Copilot in Outlook を試す</strong></a>。</p><h1 id="Copilot-と協働して、送信案を送信可能なメールに仕上げる"><a href="#Copilot-と協働して、送信案を送信可能なメールに仕上げる" class="headerlink" title="Copilot と協働して、送信案を送信可能なメールに仕上げる"></a>Copilot と協働して、送信案を送信可能なメールに仕上げる</h1><p>Copilot in Outlook はユーザーと協働しながらメールの下書き作成から推敲までを支援します。ユーザーの送信案を起点に、送信可能なメールへと仕上げるまでを支援します。送信したい内容を伝えるだけで、Copilot はメールの構成や表現を整えていきます。 </p><h3 id="Outlook-Copilot-がメールを直接作成と更新"><a href="#Outlook-Copilot-がメールを直接作成と更新" class="headerlink" title="Outlook : Copilot がメールを直接作成と更新"></a>Outlook : Copilot がメールを直接作成と更新</h3><iframe width="100%" height="480" src="https://medius.microsoft.com/Embed/video-nc/c4a3c785-cee9-47bf-a778-f5772f714351?r=213267444131" title="Edit with Copilot in Outlook" allowfullscreen="allowfullscreen" frameborder="0" sandbox="allow-scripts allow-same-origin allow-forms"></iframe><div style="text-align: center;"><i>デモ用のため、一部を省略しています。</i></div><p>Copilot in Outlook は、メール本文に最初の下書きを直接作成し、その後もユーザーと対話しながら内容を仕上げていきます。1 回限りの下書き生成ではなく、Copilot はその場で下書きを作成し、目的、対象者、トーンといった確認事項をユーザーと確認しながら、その回答に応じて下書きのメールを随時更新します。これにより、数回の簡単なやり取りで内容を調整し、送信できる状態まで仕上げることができます。すべての変更は Outlook で確認でき、コピー&amp;ペーストや書式崩れの心配もありません。</p><p><strong>プロンプト例:</strong></p><ul><li><p><strong>最初の下書きを作成:</strong> <em>&#x2F;meeting で決定した内容を &#x2F;name に確認し、合意されたスケジュールの詳細を含めたうえで、&#x2F;name に最終承認を依頼するメールの下書きを作成してください。</em></p></li><li><p><strong>トーンと分かりやすさを調整:</strong> <em>文書をより簡潔でプロフェッショナルな表現にし、&#x2F;name が普段と同じトーンで合わせます。また、冒頭に最新のリーダーシップの決定をまとめた短い背景説明の段落を追加してください。</em></p></li><li><p><strong>仕上げと書式調整:</strong> <em>承認依頼の箇所を太字にし、タイムラインをリストから表形式に変更し、件名行に「承認が必要」を追加してください。</em></p></li></ul><p><strong>提供開始時期:</strong> 3 月 9 日より、Windows、Web、モバイル向けの新しい Outlook エクスペリエンスを順次展開します。</p><h3 id="Copilot-Chat：メールを下書きから編集・送信まで一括で処理"><a href="#Copilot-Chat：メールを下書きから編集・送信まで一括で処理" class="headerlink" title="Copilot Chat：メールを下書きから編集・送信まで一括で処理"></a>Copilot Chat：メールを下書きから編集・送信まで一括で処理</h3><iframe width="100%" height="480" src="https://medius.microsoft.com/Embed/video-nc/958d9627-c6dd-4d3c-bb64-9bf34d6c9282?r=795274938405" title="Email From Chat" allowfullscreen="allowfullscreen" frameborder="0" sandbox="allow-scripts allow-same-origin allow-forms"></iframe><div style="text-align: center;"><i>デモ用のため、一部を省略しています。</i></div><p>Copilot Chat では、リクエストからメール送信まで一括で対応できます。Copilot に送信したい内容を伝え、その場で下書きを修正しながら、送信まで行えます。その際、Work IQ が適切なコンテキスト（宛先、スレッド履歴、会議の決定事項）を取り込み、内容に根拠がある、最終確認に適したメッセージへ整えます。</p><p><strong>プロンプト例:</strong></p><ul><li><p><strong>最初の下書きを作成:</strong> <em>&#x2F;meeting から決定した内容をフォローアップし、&#x2F;name と &#x2F;name 宛に次のステップをまとめたメールの下書きを作成してください。</em></p></li><li><p><strong>トーンと分かりやすさを調整:</strong> <em>このメールをより簡潔でエグゼクティブ向けに書き直してください。最初の 2 行に依頼事項を記載してください。</em></p></li></ul><p><strong>提供開始時期:</strong> 3 月 9 日より 先行リリース対象のユーザー向けに順次展開します。</p><h1 id="Copilot-にスケジュール管理や予定表のタスクを任せる"><a href="#Copilot-にスケジュール管理や予定表のタスクを任せる" class="headerlink" title="Copilot にスケジュール管理や予定表のタスクを任せる"></a>Copilot にスケジュール管理や予定表のタスクを任せる</h1><p>Copilot in Outlook は、予定表の変化に応じてユーザーの要件を引き継ぎ、継続的な作業を代行できるようになりました。出欠 (RSVP) の管理や会議の登録など、必要な作業をチャットで Copilot に伝えるだけで、これらを管理する作業を代行します。</p><h3 id="Outlook-Copilot-がユーザーの利用傾向に基づいて予定表を管理"><a href="#Outlook-Copilot-がユーザーの利用傾向に基づいて予定表を管理" class="headerlink" title="Outlook: Copilot がユーザーの利用傾向に基づいて予定表を管理"></a>Outlook: Copilot がユーザーの利用傾向に基づいて予定表を管理</h3><iframe width="100%" height="480" src="https://medius.microsoft.com/Embed/video-nc/fdf3ec84-dd92-44a7-b288-2b863741c613?r=953520227637" title="Custom Instructions" allowfullscreen="allowfullscreen" frameborder="0" sandbox="allow-scripts allow-same-origin allow-forms"></iframe><div style="text-align: center;"><i>デモ用のため、一部を省略しています。</i></div><p>会議出席依頼が次々と届き、出欠 (RSVP) の判断も繰り返されます。カスタム指示を使用すれば、Copilot が出欠対応を代行できます。開催者、会議タイトルのキーワード、勤務時間といった利用傾向に基づいて、承諾、辞退、フォローを自動で判断しつつ、状況の変化はユーザーに通知します。その結果、予定表を整理する手間が減り、スケジュールが常に優先事項に沿った状態に保たれます。</p><h3 id="Copilot-Chat：チャットから予定表を離れずに会議をスケジュール"><a href="#Copilot-Chat：チャットから予定表を離れずに会議をスケジュール" class="headerlink" title="Copilot Chat：チャットから予定表を離れずに会議をスケジュール"></a>Copilot Chat：チャットから予定表を離れずに会議をスケジュール</h3><p>会議をカレンダーに追加する必要がある場合、調整が課題になります。Copilot Chat では、会議のリクエストを伝えるだけで、Copilot が日程調整（参加者の空き時間、時間帯オプション、招待状の詳細）を処理し、各オプションが Outlook カレンダー上にどのように配置されるかを表示します。これにより、最適な時間帯を確認して決定できます。</p><p><strong>プロンプト例：</strong></p><ul><li><p><strong>優先事項に沿って時間を調整:</strong> <em>マネージャーからの会議は、自分が空いていれば常に承諾してください。</em></p></li><li><p><strong>不要な予定を削減:</strong> <em>件名に「office hours」を含む会議は常に辞退し、キャンセルされた会議を削除してください。</em></p></li><li><p><strong>個人の時間を守る:</strong> <em>午後 5 時以降にスケジュールされた会議をフォローしてください。</em></p></li></ul><p><strong>提供開始時期:</strong> Windows、Mac、Web、モバイル向けの新しい Outlook エクスペリエンスを現在利用可能です。</p><h3 id="Copilot-Chat：チャット内で会議の調整から送付まで簡潔"><a href="#Copilot-Chat：チャット内で会議の調整から送付まで簡潔" class="headerlink" title="Copilot Chat：チャット内で会議の調整から送付まで簡潔"></a>Copilot Chat：チャット内で会議の調整から送付まで簡潔</h3><iframe width="100%" height="480" src="https://medius.microsoft.com/Embed/video-nc/96c4e2af-027d-414e-bdd0-4b8c8f7c2b04?r=1004538541110" title="Schedule From Chat" allowfullscreen="allowfullscreen" frameborder="0" sandbox="allow-scripts allow-same-origin allow-forms"></iframe><div style="text-align: center;"><i>デモ用のため、一部を省略しています。</i></div><p>会議を開催する場合、実は一番の負担になるのが調整作業です。Copilot Chat では、会議のリクエストを伝えるだけで、Copilot が日程調整（参加者の空き時間、時間帯、出席依頼の詳細内容）を処理し、それぞれの候補が Outlook 予定表上にどのように配置されるかを示してくれるため、最も都合の良い選択肢を判断します。</p><p><strong>プロンプト例:</strong></p><ul><li><p><strong>空き時間を確認:</strong> <em>[名前1]、[名前2]、[名前3] と会議できる次の利用可能な時間帯を探してください。</em></p></li><li><p><strong>会議をスケジュール:</strong> <em>来週、&#x2F;name1、&#x2F;name2、&#x2F;name3 と Project X の展開計画を決定するために 30 分間の会議を設定してください。会議室を予約し、アジェンダを含めてください。</em></p></li></ul><p><strong>提供開始時期:</strong> 現在、すべての Microsoft 365 Copilot および Outlook エンドポイントにおいて、英語環境で利用可能です。</p>]]></content>
    
    
      
      
    <summary type="html">&lt;p&gt;※ この記事は、&lt;a href=&quot;https://techcommunity.microsoft.com/blog/outlook/copilot-in-outlook-new-agentic-experiences-for-email-and-calendar/44997</summary>
      
    
    
    
    
    <category term="New Outlook" scheme="https://jpmessaging.github.io/blog/tags/New-Outlook/"/>
    
    <category term="Copilot" scheme="https://jpmessaging.github.io/blog/tags/Copilot/"/>
    
  </entry>
  
  <entry>
    <title>Exchange Online における SMTP DANE および MTA-STS コネクタ モードの発表</title>
    <link href="https://jpmessaging.github.io/blog/announcing-smtp-dane--mta-sts-connector-modes-in-exchange-online/"/>
    <id>https://jpmessaging.github.io/blog/announcing-smtp-dane--mta-sts-connector-modes-in-exchange-online/</id>
    <published>2026-03-10T15:00:00.000Z</published>
    <updated>2026-03-10T15:00:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>※ この記事は、<a href="https://techcommunity.microsoft.com/blog/exchange/announcing-smtp-dane--mta-sts-connector-modes-in-exchange-online/4501005">Announcing SMTP DANE &amp; MTA STS Connector Modes in Exchange Online</a> の抄訳です。最新の情報はリンク先をご確認ください。この記事は Microsoft 365 Copilot および GitHub Copilot を使用して抄訳版の作成が行われています。</p><p>Exchange Online における <strong>SMTP DANE および MTA-STS のコネクタ モード</strong> のリリースをお知らせいたします。この更新により、管理者はアウトバウンド コネクタを介してメールを送信する際に、<strong>Exchange Online が最新のメール フロー セキュリティ標準をどの程度厳格に適用するかを明示的に制御できる</strong>ようになります。</p><p>この機能は、<a href="https://learn.microsoft.com/purview/how-smtp-dane-works">SMTP DANE with DNSSEC</a> および <a href="https://learn.microsoft.com/purview/enhancing-mail-flow-with-mta-sts">MTA-STS</a> の既存の機能を基盤として構築されており、重要なメール パスにおける<strong>セキュリティ体制、信頼性、およびパートナーとの相互運用性</strong>のバランスに関するお客様からのフィードバックに対応するものです。</p><h3 id="新機能"><a href="#新機能" class="headerlink" title="新機能"></a>新機能</h3><p>Exchange Online のアウトバウンド コネクタで、<strong>SMTP DANE および MTA-STS モード</strong>の構成がサポートされるようになりました。これにより、各メール フロー シナリオに最適な検証動作を選択できます。</p><p>管理者は以下の設定を構成できます。</p><ul><li><strong>Opportunistic (既定):</strong> Exchange Online は SMTP DANE および MTA-STS の検証を利用可能な場合に試行しますが、宛先がこれらをサポートしていない場合は配信を続行します。</li><li><strong>Mandatory (SMTP DANE のみ):</strong> SMTP DANE with DNSSEC の完全な検証を強制します。検証に失敗した場合、または宛先が SMTP DANE をサポートしていない場合、メールはキューに格納されます。</li><li><strong>None:</strong> コネクタに対する SMTP DANE および&#x2F;または MTA-STS の検証を無効にします。特定のパートナー シナリオでの互換性を優先し、セキュリティを低減します。</li></ul><p>これらの設定は<strong>コネクタごと</strong>に適用されるため、テナント全体の送信メール フロー動作に影響を与えることなく、きめ細かい制御が可能です。</p><h3 id="この機能が重要な理由"><a href="#この機能が重要な理由" class="headerlink" title="この機能が重要な理由"></a>この機能が重要な理由</h3><p>SMTP DANE with DNSSEC および MTA-STS は、ダウングレード攻撃や悪意のある MX リダイレクトからの保護により、トランスポート レベルのメール セキュリティの水準を大幅に引き上げます。しかし、一貫性のない構成や誤った構成のパートナーにメールを送信する場合、<strong>画一的な強制適用は運用上の課題となり得る</strong>というフィードバックをお客様からいただいていました。</p><p>コネクタ レベルのモードにより、以下のことが可能になります。</p><ul><li>パートナーが完全に準拠している場合は<strong>厳格なセキュリティを適用</strong>する</li><li>まだ最新化の途上にあるビジネス クリティカルなパートナーに対して<strong>信頼性の高い配信を維持</strong>する</li><li>運用上の中断なく、<strong>時間をかけて段階的にセキュリティ体制を強化</strong>する</li></ul><h4 id="詳細情報"><a href="#詳細情報" class="headerlink" title="詳細情報"></a>詳細情報</h4><ul><li>ドキュメントの更新と管理者向けガイダンスは Microsoft Learn で公開されています: <a href="https://learn.microsoft.com/powershell/module/exchangepowershell/set-outboundconnector?view=exchange-ps">Set-OutboundConnector (ExchangePowerShell) | Microsoft Learn</a></li></ul><p>お客様がこれらのコントロールを、メール セキュリティ強化の取り組みの一環として活用されることを期待しています。</p>]]></content>
    
    
      
      
    <summary type="html">&lt;p&gt;※ この記事は、&lt;a href=&quot;https://techcommunity.microsoft.com/blog/exchange/announcing-smtp-dane--mta-sts-connector-modes-in-exchange-online/45010</summary>
      
    
    
    
    
    <category term="Exchange Online" scheme="https://jpmessaging.github.io/blog/tags/Exchange-Online/"/>
    
  </entry>
  
  <entry>
    <title>Outlook におけるメールのネイティブな外部送信者表示機能</title>
    <link href="https://jpmessaging.github.io/blog/native-external-sender-callouts-on-email-in-outlook/"/>
    <id>https://jpmessaging.github.io/blog/native-external-sender-callouts-on-email-in-outlook/</id>
    <published>2026-03-01T15:00:00.000Z</published>
    <updated>2026-03-01T15:00:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>※ この記事は、<a href="https://techcommunity.microsoft.com/blog/exchange/native-external-sender-callouts-on-email-in-outlook/2250098">Native external sender callouts on email in Outlook</a> の抄訳です。最新の情報はリンク先をご確認ください。この記事は Microsoft 365 Copilot および GitHub Copilot を使用して抄訳版の作成が行われています。</p><p><strong>翻訳者注：</strong> 英語の原文では一部の Outlook クライアントで展開中とされていますが、現在は対象 Outlook クライアントに展開済みのため、翻訳文では最新の状況を反映した表現としています。</p><h1 id="概要"><a href="#概要" class="headerlink" title="概要"></a>概要</h1><p>一部のお客様では、外部送信者からのメールであることをエンドユーザーに分かりやすく伝えるため、Exchange のトランスポート ルールを使用して、件名の先頭に文言を追加したり、メッセージ本文に注意書きを挿入したりしています。このアプローチにはいくつかの制限があります。例えば、以下のような点です。</p><ul><li>外部ユーザーがスレッドに返信し続けると、件名に重複した [External] タグが表示される可能性があります (一部のお客様は重複を削除するためにカスタマイズされたソリューションを使用しています)。</li><li>件名が変更されると、Outlook の [スレッドとして表示] の機能が機能しなくなり、メッセージが同じスレッドに含まれなくなります。</li><li>変更された件名 (またはメッセージ本文) は、返信または転送時にメッセージの一部として残されるため、スレッドが内部メールになった場合に混乱が生じます。</li><li>トランスポート ルールはエンドユーザーが使用しているクライアント言語を認識できないため、ローカライズに問題が生じる可能性があります。</li><li>件名に追加した文言が多くのスペースを占有してしまい、特に画面の小さいデバイスでは件名をプレビューしづらくなる場合があります。</li></ul><p>上記のフィードバックは認識しており、組織外の送信者からのメールを識別するための、よりネイティブなエクスペリエンスの提供に取り組みました (これは、スパムやフィッシング詐欺といった脅威への対策にも役立ちます。) この機能は、メールに [External] というタグ (クライアント言語設定に基づいてローカライズされます) を表示し、メッセージ閲覧ビューの上部に関連するユーザー インターフェースが表示され、実際の送信者のメール アドレスを確認できるようになります。</p><h1 id="セットアップ方法"><a href="#セットアップ方法" class="headerlink" title="セットアップ方法"></a>セットアップ方法</h1><ol><li>Exchange Online のテナント管理者は、テナント全体の新しいユーザー インターフェースを有効にするため、<a href="https://docs.microsoft.com/powershell/module/exchange/set-externalinoutlook">Set-ExternalInOutlook</a> コマンドレットを実行する必要があります (この機能はすでに提供されています)。また、このコマンドレットを使用して特定のメールアドレスやドメインを許可リストに追加することもできます。</li><li>Outlook on the web は既にこの機能に対応しています。Outlook for Mobile (iOS &amp; Android) および Outlook for Mac でもこの機能を展開しました。具体的なバージョンは以下になります。<ul><li>Outlook on the web: 現在利用可能</li><li>Outlook for Windows: <strong>2023 年 10 月 6 日更新</strong>: <a href="https://learn.microsoft.com/officeupdates/semi-annual-enterprise-channel-preview#version-2308-september-12">半期エンタープライズ チャネル (プレビュー)</a> でも利用可能になりました。Outlook for Windows における [External] タグ表示 (他のクライアントと同様の表示) は、最新チャネルおよび月次エンタープライズ チャネルのバージョン 2211 以降 (ビルド 15831.20190 以上) 、半期エンタープライズ チャネル (プレビュー) や 半期エンタープライズ チャネルのバージョン 2308 以降にリリースされています。<br> 各バージョンのリリース状況については、<a href="https://learn.microsoft.com/officeupdates/update-history-microsoft365-apps-by-date">Microsoft 365 Apps の更新履歴（日付別）</a> をご確認ください。</li><li>Outlook for Mobile (iOS &amp; Android): バージョン 4.2111.0 以降</li><li>新しい Outlook for Mac: バージョン 16.47 以降</li></ul></li></ol><p>現在、外部送信者からのメールに件名の先頭に [External] タグを追加するトランスポート ルールを使用している場合、Outlook の新しいネイティブ機能では、メール アイテムに <em>IsExternalSender</em> という新しい MAPI プロパティが追加されます。現在すべてのクライアント バージョン (上記に記載されているもの) がこの機能に対応しているため、メールが [External] と二重に表示されること (新しいネイティブ機能による表示と、トランスポート ルールによる表示) を避けるため、Outlook のネイティブ外部送信者識別機能をオンにする前に、既存の対象トランスポート ルールをオフにしてください。</p><p>この機能は Microsoft 365 ロードマップ ID 70595 として展開状況を公開していましたが、現在はすでに展開が完了しており、テナント レベルで有効化することが可能です。</p><p>Outlook on the web、Outlook for Mac、および Outlook for Mobile では、メッセージ一覧に <em>External タグ</em>が表示されます。Outlook for Windows と OWA は、閲覧ウィンドウのインフォ バーに送信者のメール アドレスが表示されます。Outlook for Mobile と Outlook for Mac では、メッセージの閲覧ウィンドウに外部タグのみが表示され、実際の送信者のメール アドレスを確認するにはタグをクリックする必要があります。</p><p>Outlook for Windows の閲覧ウィンドウでの外部送信者の表示 (他のクライアントとは若干表示が異なります) :</p><p><img src="/blog/native-external-sender-callouts-on-email-in-outlook/ExternalCalloutsOutlook2.jpg"></p><p><strong>更新 2022 年 11 月 3 日:</strong> Outlook for Windows のメッセージ一覧での新しい External タグ表示 (他のクライアントと同様) :</p><p><img src="/blog/native-external-sender-callouts-on-email-in-outlook/OLupdatedexternal.png"></p><p>Outlook on the web での外部送信者の表示 :</p><p><img src="/blog/native-external-sender-callouts-on-email-in-outlook/NativeOLExternal01.jpg"></p><p>Outlook for iOS での外部送信者のユーザー インターフェース (メッセージ一覧での表示、メール閲覧時の External タグ表示、および External タグをタップした後の送信者メール アドレスの表示) :</p><p><img src="/blog/native-external-sender-callouts-on-email-in-outlook/NativeOLExternal02.jpg"></p><p>PowerShell でこの機能を有効にすると、組織外から受信したメールに External タグが表示されるようになるまで 24 ～ 48 時間かかる場合があります (Outlook クライアントのバージョンが本機能をサポートしている場合)。</p><p>この機能を有効化する際、ユーザーに対して本機能を周知するとともに、必要に応じてトレーニングやドキュメントを更新することをお勧めします。</p><p>ご不明な点やフィードバックがあればお知らせください。</p>]]></content>
    
    
      
      
    <summary type="html">&lt;p&gt;※ この記事は、&lt;a href=&quot;https://techcommunity.microsoft.com/blog/exchange/native-external-sender-callouts-on-email-in-outlook/2250098&quot;&gt;Native ex</summary>
      
    
    
    
    
    <category term="Outlook" scheme="https://jpmessaging.github.io/blog/tags/Outlook/"/>
    
  </entry>
  
  <entry>
    <title>現場レポート：EWS 廃止前に行う EWS アプリ利用状況の確認と対策</title>
    <link href="https://jpmessaging.github.io/blog/notes-from-the-field-finding-and-remediating-ews-app-usage-before-retirement/"/>
    <id>https://jpmessaging.github.io/blog/notes-from-the-field-finding-and-remediating-ews-app-usage-before-retirement/</id>
    <published>2026-02-24T15:00:00.000Z</published>
    <updated>2026-02-24T15:00:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>※ この記事は、<a href="https://techcommunity.microsoft.com/blog/exchange/notes-from-the-field-finding-and-remediating-ews-app-usage-before-retirement/4496469">Notes From the Field: Finding and Remediating EWS App Usage Before Retirement</a> の抄訳です。最新の情報はリンク先をご確認ください。この記事は Microsoft 365 Copilot および GitHub Copilot を使用して抄訳版の作成が行われています。</p><p>本記事では、現在も Exchange Web Services（EWS）を利用している Azure AD アプリの特定方法を実例ベースで解説します。また、Microsoft Graph への移行を進めるうえで考慮が必要となる、Kiosk&#x2F;Frontline ライセンス変更の影響についてもご紹介します。</p><p>Microsoft は 2026 年 10 月 1 日より Exchange Online において EWS のブロックを開始することを発表しています。EWS に依存している基幹業務アプリケーション、サードパーティ製ツール、または自動化処理が残っている場合、まずは「現在何が EWS を使用しているのか」を把握し、そのうえで Microsoft Graph などのサポートされている代替手段への移行計画を立てます。</p><h3 id="変更内容と、今対応が必要な理由"><a href="#変更内容と、今対応が必要な理由" class="headerlink" title="変更内容と、今対応が必要な理由"></a>変更内容と、今対応が必要な理由</h3><ul><li><a href="https://techcommunity.microsoft.com/blog/exchange/retirement-of-exchange-web-services-in-exchange-online/3924440"><strong>Exchange Online における EWS の廃止</strong></a>：Microsoft は <strong>2026 年 10 月 1 日</strong>より Exchange Online において EWS リクエストをブロックする予定です。そのため、EWS を使用した各種連携については、Microsoft Graph への移行が推奨されています。</li><li><a href="https://jpmessaging.github.io/blog/update-to-ews-access-for-kiosk--frontline-worker-licensed-users/"><strong>Kiosk&#x2F;Frontline ライセンス ユーザー向けの EWS アクセス制限</strong></a>：<strong>2026 年 6 月末</strong>より、Microsoft は <strong>EWS へのアクセス権を持たないライセンス</strong> (一部の Kiosk ライセンスや Frontline Worker 向けライセンス) が割り当てられているユーザーに対して EWS へのアクセスをブロックします。この変更により、該当するライセンスを使用しているユーザーでは、10 月の全体的な廃止日より前に EWS ベースの連携が動作しなくなる可能性があります。</li></ul><p>Microsoft Graph への移行を 2026 年 10 月よりも大幅に前倒しで完了する予定であっても、2026 年 6 月末に実施されるライセンス関連のブロックを踏まえ、該当ライセンスが割り当てられたユーザーが EWS を使用しているかどうかを確認する必要があります。そのような確認において有用なのが、<a href="https://github.com/jmartinmsft/Exchange-App-Usage-Reporting">Exchange-App-Usage-Reporting</a> スクリプトです。このスクリプトを活用することで、EWS の権限を持つアプリを洗い出し、直近のサインイン アクティビティとあわせて把握できるため、優先的に対応すべき対象を効率的に見極めることができます。</p><h4 id="まずはメッセージ-センターを確認"><a href="#まずはメッセージ-センターを確認" class="headerlink" title="まずはメッセージ センターを確認"></a>まずはメッセージ センターを確認</h4><p>最初にできることは、テナントの<a href="https://go.microsoft.com/fwlink/p/?linkid=2070717">メッセージ センター</a> (全体管理者またはプライバシー閲覧者のロールが必要です) を確認し、受信トレイまたはアーカイブで “Update active Exchange Web Services Applications” を検索することです。該当するメッセージが見つからない場合は、テナント内で EWS が使用されていない可能性が高く、今回の廃止による影響を受けないと考えられます。なお、EWS の使用状況に関するメッセージの送信は 2025 年 12 月下旬からすべてのテナントに対して開始されています。</p><h3 id="Exchange‑App‑Usage‑Reporting-スクリプトでできること"><a href="#Exchange‑App‑Usage‑Reporting-スクリプトでできること" class="headerlink" title="Exchange‑App‑Usage‑Reporting スクリプトでできること"></a>Exchange‑App‑Usage‑Reporting スクリプトでできること</h3><p>このスクリプトは、次のような実際の運用上の疑問に答えるために設計されています。<em>テナント内で EWS の権限を持つ Azure AD のアプリはどれか、そしてそれらは現在も使用されているのか？</em> 大まかには、次の処理を行います。</p><ol><li>Exchange&#x2F;EWS 関連のアクセス権限を持つアプリケーションを検出します。</li><li>各アプリケーションのサインイン アクティビティを確認し、現在使用されているアプリケーションを特定します。</li><li>テナント内の EWS アクティビティについて監査ログを照会します。</li><li>ソートやアプリ所有者との共有が可能なレポート ファイルを出力します。</li><li>Kiosk または Frontline Worker の特定に役立つユーザー ライセンス レポートを出力します。</li></ol><h4 id="このスクリプトが-Microsoft-365-管理センターの-EWS-使用状況レポートをどのように補完するか"><a href="#このスクリプトが-Microsoft-365-管理センターの-EWS-使用状況レポートをどのように補完するか" class="headerlink" title="このスクリプトが Microsoft 365 管理センターの EWS 使用状況レポートをどのように補完するか"></a>このスクリプトが Microsoft 365 管理センターの EWS 使用状況レポートをどのように補完するか</h4><p>WW (Worldwide) サービスをご使用の場合、<a href="https://learn.microsoft.com/microsoft-365/admin/activity-reports/ews-usage?view=o365-worldwide">Microsoft 365 管理センターの EWS 使用状況レポート</a>は良いスタート ポイントとなります。このレポートでは、テナント全体の EWS アクティビティを集約されており、どの EWS SOAP アクションが呼び出されているかや、時系列でのボリュームを確認できます。これにより、全体的な EWS 依存関係を定量化し、最も負荷の高い EWS ワークロードを特定するのに役立ちます。</p><p>多くのチームが直面する課題は、そのような使用状況をもとに実行可能な対策計画に落とし込むことです（例えば、正確な Entra ID アプリ&#x2F;サービス プリンシパルの特定、それが現在もアクティブに使用されているかどうかの判断、影響を受けるユーザーとメールボックスの特定）。Exchange-App-Usage-Reporting スクリプトは、EWS の使用状況に ID や運用の観点を加えることで、こうしたギャップを解消するために用意されています。</p><ul><li><strong>アプリと所有権の把握</strong>：EWS 関連のアクセス権限を持つ Entra ID アプリ&#x2F;サービス プリンシパルを特定することで、「あるアプリが EWS を呼び出している」から「これが対応すべきアプリ オブジェクトである」という判断へ即座に切り替えることができます。さらに、適切な所有者や担当チームへに引き継ぐことができます。</li><li><strong>最新性と「現在も使用されているか」の判断材料</strong>：アプリをサインイン アクティビティに関連付けるため、現在も実際に認証が行われているアプリと、古くなって廃止を検討してもいいアプリを判別することができます。これにより、対応の優先順位付けが可能になります。</li><li><strong>認証方式と権限モデルの可視化</strong>：使用状況がアプリケーション権限に基づくものか、委任された権限に基づくものかを判別できるようになります。これは、 Microsoft Graph への移行方法を適切に選択するうえで重要であると同時に、最小権限アクセスの設計に役立ちます。</li><li><strong>メールボックス構成に伴うリスク（Kiosk&#x2F;Frontline）</strong>：ユーザー ライセンス レポートより、EWS 依存のワークフローが、早期に EWS アクセス制限の影響 (2026 年 6 月末) を受ける可能性のあるメールボックスに該当するかどうかを特定できます。</li><li><strong>エクスポート可能なアプリ中心の作業リスト</strong>：最後のサインイン日時などでソート&#x2F;共有できる CSV を生成し、エンジニアリング バックログを効果的に推進します。具体的には、所有者の確認、シナリオの確認、EWS 操作と Microsoft Graph エンドポイントへのマッピング、完全移行まで進捗を追跡します。</li></ul><p>実際には、まず管理センターのレポートを使用して<em>何の</em> EWS 操作が、どの規模で発生しているかを把握してから、スクリプトを使用して<em>どの</em>アプリがそれらの操作を行っているのか、<em>誰が</em>そのアプリを所有しているか、<em>そのアプリが現在もアクティブか</em>、そして<em>どの</em>メールボックス&#x2F;ライセンスのユーザーが最初に影響を受ける可能性が高いかを特定します。</p><p>WW (Worldwide) 以外のクラウドを使用しているテナントの場合、管理センターのレポートは使用できないため、スクリプトに大きく依存することになります。</p><h3 id="手順-スクリプトの実行とレポートの生成"><a href="#手順-スクリプトの実行とレポートの生成" class="headerlink" title="手順: スクリプトの実行とレポートの生成"></a>手順: スクリプトの実行とレポートの生成</h3><h4 id="1-コードのダウンロード"><a href="#1-コードのダウンロード" class="headerlink" title="1) コードのダウンロード"></a>1) コードのダウンロード</h4><p>このソリューションのリポジトリは<a href="https://github.com/jmartinmsft/Exchange-App-Usage-Reporting/archive/refs/heads/main.zip">こちら</a>から取得できます。</p><p>注: このアプリケーションには、以下のアクセス権限が必要です:</p><ul><li><strong>AuditLogsQuery.ReadAll</strong> - EWS アクティビティの監査ログを照会するため</li><li><strong>Application.Read.All</strong> - アプリを特定するため</li><li><strong>AuditLogs.Read.All</strong> - サインイン アクティビティを照会するため</li><li><strong>Directory.Read.All</strong> - ユーザー ライセンス情報を照会するため</li></ul><p>これらの権限を追加する手順については、<a href="https://github.com/jmartinmsft/Exchange-App-Usage-Reporting/blob/main/Create%20an%20App%20registration.md">Create an App registration の readme ファイル</a>を参照してください。</p><h4 id="2-アクティブなアプリケーションの取得"><a href="#2-アクティブなアプリケーションの取得" class="headerlink" title="2) アクティブなアプリケーションの取得"></a>2) アクティブなアプリケーションの取得</h4><p>PowerShell セッションを開き、スクリプトをダウンロードしたフォルダーに移動します。実行前に、必要に応じて (例えば、<em>Unblock-File</em> を使用して) ファイルのブロックを解除してください。その後、次のサンプル構文でスクリプトを実行します。</p><figure class="highlight powershell"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">.\<span class="built_in">Find-EwsUsage</span>.ps1 <span class="literal">-OutputPath</span> C:\Temp\Output <span class="literal">-OAuthCertificate</span> <span class="number">8865</span>BEC624B02FA0DE9586D13186ABC8BE265917 <span class="literal">-CertificateStore</span> CurrentUser <span class="literal">-OAuthClientId</span> <span class="number">7</span>a305061<span class="literal">-1343-49c3-a469-378de4dbd90d</span> <span class="literal">-OAuthTenantId</span> <span class="number">9101</span>fc97<span class="literal">-5be5-4438-a1d7-83e051e52057</span> <span class="literal">-PermissionType</span> Application <span class="literal">-Operation</span> GetEwsActivity</span><br></pre></td></tr></table></figure><p>出力結果には、EWS 権限を持つアプリケーションと、関連するサービス プリンシパルの最後のサインイン情報が一覧で表示されます。指定した出力パスに App-SignInActivity-yyyyMMddhhmm という名前の CSV ファイルが作成されます。</p><h4 id="3-アプリケーションのサインイン-アクティビティの取得"><a href="#3-アプリケーションのサインイン-アクティビティの取得" class="headerlink" title="3) アプリケーションのサインイン アクティビティの取得"></a>3) アプリケーションのサインイン アクティビティの取得</h4><p>前の手順での出力結果をもとに、アプリケーションのサインイン アクティビティを取得します（この手順はアプリケーションごとに実行する必要があります）。テナントの規模によっては、StartDate と EndDate を調整し、Interval を 1 時間に設定する必要がある場合もあります。</p><figure class="highlight powershell"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">.\<span class="built_in">Find-EwsUsage</span>.ps1 <span class="literal">-OutputPath</span> C:\Temp\Output <span class="literal">-OAuthCertificate</span> <span class="number">8865</span>BEC624B02FA0DE9586D13186ABC8BE265917 <span class="literal">-CertificateStore</span> CurrentUser <span class="literal">-OAuthClientId</span> <span class="number">7</span>a305061<span class="literal">-1343-49c3-a469-378de4dbd90d</span> <span class="literal">-OAuthTenantId</span> <span class="number">9101</span>fc97<span class="literal">-5be5-4438-a1d7-83e051e52057</span> <span class="literal">-PermissionType</span> Application <span class="literal">-Operation</span> GetAppUsage <span class="literal">-QueryType</span> SignInLogs <span class="literal">-Name</span> TJM<span class="literal">-EWS-SoftDelete-Script</span> <span class="literal">-AppId</span> <span class="number">86277</span>a5c<span class="literal">-d649-46fc-8bf6-48e2a684624b</span> <span class="literal">-StartDate</span> (<span class="built_in">Get-Date</span>).AddDays(<span class="literal">-30</span>) <span class="literal">-EndDate</span> (<span class="built_in">Get-Date</span>).AddDays(<span class="literal">-14</span>) <span class="literal">-Interval</span> <span class="number">8</span></span><br></pre></td></tr></table></figure><p>出力結果には、指定した出力パスで &lt;AppId&gt;-SignInEvents-yyyyMMddhhmm という名前の CSV ファイルが作成されます。</p><h4 id="4-ユーザー-ライセンス情報の取得（Kiosk-Frontline-の識別）"><a href="#4-ユーザー-ライセンス情報の取得（Kiosk-Frontline-の識別）" class="headerlink" title="4) ユーザー ライセンス情報の取得（Kiosk&#x2F;Frontline の識別）"></a>4) ユーザー ライセンス情報の取得（Kiosk&#x2F;Frontline の識別）</h4><p>6 月に予定されている EWS アクセス制限によって影響を受ける可能性のあるユーザーを特定するため、ユーザー ライセンス レポートを生成することで、影響範囲を把握しやすくなります。このライセンス レポートの生成には、前の手順で得られた出力結果を使用できます。また、各アプリケーションごとの結果を含む複数の CSV ファイルを、1 つのユーザー ライセンス レポートにマージすることも可能です。</p><figure class="highlight powershell"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">.\<span class="built_in">Find-EwsUsage</span>.ps1 <span class="literal">-OutputPath</span> C:\Temp\Output <span class="literal">-OAuthCertificate</span> <span class="number">8865</span>BEC624B02FA0DE9586D13186ABC8BE265917 <span class="literal">-CertificateStore</span> CurrentUser <span class="literal">-OAuthClientId</span> <span class="number">7</span>a305061<span class="literal">-1343-49c3-a469-378de4dbd90d</span> <span class="literal">-OAuthTenantId</span> <span class="number">9101</span>fc97<span class="literal">-5be5-4438-a1d7-83e051e52057</span> <span class="literal">-PermissionType</span> Application <span class="literal">-Operation</span> GetUserLicenses <span class="literal">-AppUsageSignInCsv</span> C:\Temp\Output\<span class="number">86277</span>a5c<span class="literal">-d649-46fc-8bf6-48e2a684624b-SignInEvents-20260203122538</span>.csv</span><br></pre></td></tr></table></figure><h4 id="出力結果の見方と対応の優先順位付け"><a href="#出力結果の見方と対応の優先順位付け" class="headerlink" title="出力結果の見方と対応の優先順位付け"></a>出力結果の見方と対応の優先順位付け</h4><p>出力ファイルを取得したら、「last sign-in」でソートしてください。最近のアクティビティがあるアプリは、EWS がブロックされた際に本番環境のワークロードへ影響を及ぼす可能性が高いため、最優先で対応すべきです。一方で、サインイン データが存在しないアプリは、休止状態、構成ミス、または既にリタイアされた可能性があります。ただし、これらは「無視してよい」と判断するのではなく「要検証」として扱ってください。</p><ol><li><strong>各アプリの所有者を特定</strong>します（または、そのアプリと紐づく業務システムを特定します）。</li><li><strong>ワークロードを確認</strong>します。メールボックスへのアクセス パターン (読み取り、送信、予定表、連絡先など) と、アプリケーション権限を使用しているか委任された権限を使用しているかを確認します。</li><li><strong>アプリがアクセスするメールボックスの構成を確認</strong>します。特に、2026 年 6 月末に EWS アクセスができなくなる可能性のある Kiosk&#x2F;Frontline ライセンスが割り当てられているメールボックスでないかを確認します。</li><li><strong>移行先を選定します</strong>。Microsoft Graph API の同等機能や、サポートされている Exchange Online 機能、または EWS 依存を解消するためのベンダー側のアップグレードを検討します。</li></ol><h3 id="Kiosk-Frontline-Worker-の-EWS-ブロックに注意（2026-年-6-月末）"><a href="#Kiosk-Frontline-Worker-の-EWS-ブロックに注意（2026-年-6-月末）" class="headerlink" title="Kiosk&#x2F;Frontline Worker の EWS ブロックに注意（2026 年 6 月末）"></a>Kiosk&#x2F;Frontline Worker の EWS ブロックに注意（2026 年 6 月末）</h3><p>推奨される検証プレイブック：</p><ul><li>スクリプト出力結果を利用して、現在も使用されている EWS アプリのショートリストを作成します。</li><li>各アプリについて、どのメールボックスにアクセスしているかを特定します（アプリケーション アクセス ポリシー、RBAC、サービス アカウント、共有メールボックス、またはユーザー層）。</li><li>メールボックスに割り当てられているライセンスを突き合わせ、EWS 権限を含まない可能性のある Kiosk&#x2F;Frontline SKU が含まれていないかを確認します。</li><li>管理されたテスト（可能であれば非本番環境）を実施し、その連携が当該メールボックスに対して EWS に依存しているか、またベンダーから Graph ベースの更新が提供されているかを確認します。</li><li>必要に応じて、特定のユーザーに対して別のライセンスを追加する必要があるかを評価します（例えば、2026 年 10 月の廃止まで EWS を引き続き使用できる Exchange Online Plan 1 または 2 を追加するなど）。</li></ul><h4 id="対策オプション-EWS-依存が見つかった場合の対応策"><a href="#対策オプション-EWS-依存が見つかった場合の対応策" class="headerlink" title="対策オプション (EWS 依存が見つかった場合の対応策)"></a>対策オプション (EWS 依存が見つかった場合の対応策)</h4><ul><li><strong>製品のアップグレードまたは再構成</strong>: 多くのベンダーは既に Microsoft Graph に移行しています。ベンダーと連携し、Graph 移行に関するガイダンスとタイムラインを確認してください。</li><li><strong>カスタム コードの改修</strong>: EWS 操作 (メール、予定表、連絡先) を Microsoft Graph エンドポイントにマッピングし、認証フロー、スロットリング、権限を再テストします。マッピングの詳細については、<a href="https://learn.microsoft.com/graph/migrate-exchange-web-services-api-mapping">こちら</a>をご覧ください。</li><li><strong>影響範囲の最小化</strong>: どうしても一時的にアプリを継続利用する必要がある場合は、最小権限の原則に基づいて権限を厳密に制限し、必要に応じて RBAC を用いてアクセス可能なメールボックスを限定してください。そのうえで、有効期限を設定した短期的な例外として扱います。</li></ul><h4 id="クイック-チェックリスト"><a href="#クイック-チェックリスト" class="headerlink" title="クイック チェックリスト"></a>クイック チェックリスト</h4><ul><li>Exchange-App-Usage-Reporting を実行し、直近 EWS のサインイン アクティビティがあるアプリを特定します。</li><li>アプリの所有者を特定し、各アプリがアクセスしているメールボックス&#x2F;ワークロードをドキュメント化します。</li><li>2026 年 6 月末に予定されているライセンス関連の EWS ブロックへの影響範囲を評価します (Kiosk&#x2F;Frontline)。</li><li>Microsoft Graph への移行を優先し、エンドツーエンドで機能することを検証します。</li><li>定期的にレポートを再実行し、EWS の使用状況がゼロに向かって減少していることを確認します。</li></ul><p><strong>この投稿の変更点:</strong></p><ul><li><strong>2026 年 2 月 26 日 :</strong> Create app registration readme file へのリンクを改善版に差し替えました。</li><li><strong>2026 年 2 月 25 日 :</strong> レポーティング スクリプトのアプリ登録に関する詳細、およびメッセージ センターで EWS 使用状況を確認する方法を追加しました。</li></ul>]]></content>
    
    
      
      
    <summary type="html">&lt;p&gt;※ この記事は、&lt;a href=&quot;https://techcommunity.microsoft.com/blog/exchange/notes-from-the-field-finding-and-remediating-ews-app-usage-before-reti</summary>
      
    
    
    
    
    <category term="Exchange Online" scheme="https://jpmessaging.github.io/blog/tags/Exchange-Online/"/>
    
  </entry>
  
  <entry>
    <title>Multi-Geo In-Region Routing が一般提供 (GA) 開始</title>
    <link href="https://jpmessaging.github.io/blog/multi-geo-in-region-routing-general-availability/"/>
    <id>https://jpmessaging.github.io/blog/multi-geo-in-region-routing-general-availability/</id>
    <published>2026-02-14T00:41:51.000Z</published>
    <updated>2026-02-14T00:41:51.000Z</updated>
    
    <content type="html"><![CDATA[<p>※ この記事は、<a href="https://techcommunity.microsoft.com/blog/exchange/multi-geo-in-region-routing-general-availability/4494860">Multi-Geo In-Region Routing General Availability</a> の抄訳です。最新の情報はリンク先をご確認ください。この記事は Microsoft 365 Copilot および GitHub Copilot を使用して抄訳版の作成が行われています。</p><p><a href="https://learn.microsoft.com/microsoft-365/enterprise/configure-multi-geo-in-region-routing?view=o365-worldwide"><strong>Multi-Geo In-Region Routing</strong></a> の<strong>一般提供 (GA)</strong> が 2025 年 12 月に開始されたことをお知らせします。この新機能は <a href="https://learn.microsoft.com/microsoft-365/enterprise/microsoft-365-multi-geo?view=o365-worldwide">Microsoft 365 Multi-Geo Capabilities add-on (“Multi-Geo”)</a> の価値を拡張し、世界中に分散されたユーザーを持つ Multi-Geo 環境の管理者に対して、<strong>受信方向の匿名メールとハイブリッド メールが Exchange Online テナントに入る場所</strong>を制御できる機能を提供します。</p><h4 id="なぜ-In-Region-Routing-が必要なのか"><a href="#なぜ-In-Region-Routing-が必要なのか" class="headerlink" title="なぜ In-Region Routing が必要なのか?"></a>なぜ In-Region Routing が必要なのか?</h4><p>既定では、Multi-Geo を使用する Microsoft 365 テナントへの<strong>すべての受信方向の匿名メールとハイブリッド メール</strong>は、最初に<strong>テナントのリージョン</strong>で Exchange Online に入り、その後 Microsoft のセキュアな内部ネットワーク内でメール受信者にリレーされます。世界中に分散されたユーザーを持つお客様にとって、このモデルは業務要件を完全には満たさない場合があります。</p><p>Multi-Geo In-Region Routing は、この課題に対処するために構築されました。</p><h4 id="Multi-Geo-In-Region-Routing-で何ができるのか"><a href="#Multi-Geo-In-Region-Routing-で何ができるのか" class="headerlink" title="Multi-Geo In-Region Routing で何ができるのか?"></a>Multi-Geo In-Region Routing で何ができるのか?</h4><p>In-Region Routing を使用すると、以下の受信メールが Exchange Online に入る地理的な場所を制御できます:</p><ul><li><strong>匿名の受信メール</strong></li><li><strong>オンプレミスからのハイブリッド受信メール</strong></li></ul><p>Multi-Geo In-Region Routing は、テナントが適切に構成されている場合、匿名の受信メールとハイブリッド受信メールが受信者ユーザーと同じ地域の Exchange Online に入ることを確実にするのに役立ちます。</p><h4 id="どのように機能するのか-概要"><a href="#どのように機能するのか-概要" class="headerlink" title="どのように機能するのか (概要)"></a>どのように機能するのか (概要)</h4><p>In-Region Routing により、以下のことができます:</p><ul><li><strong>承認済みドメイン</strong>を特定のリージョンに関連付ける</li><li>これらのドメインを同じリージョンに位置するユーザーと関連させる</li><li>これらのドメインの受信メールとハイブリッド メールが、受信者のリージョンの Exchange Online に入るようにする</li></ul><h4 id="Multi-Geo-の自然な拡張"><a href="#Multi-Geo-の自然な拡張" class="headerlink" title="Multi-Geo の自然な拡張"></a>Multi-Geo の自然な拡張</h4><p>In-Region Routing は Multi-Geo に含まれる機能であり、既存の Multi-Geo 機能に基づいています。適切に構成されると、In-Region Routing ドメインの受信メールはテナントのプライマリ プロビジョニング リージョンに最初に入るのではなく、受信者のリージョンに直接入るようになります。これは、お客様に Microsoft 365 がグローバル環境でどのように動作するかについて、意味のある透過的なコントロールを提供するための 1 つのステップです。</p><h4 id="始め方"><a href="#始め方" class="headerlink" title="始め方"></a>始め方</h4><p>既に Multi-Geo を使用しているか、または使用を計画している場合は、ドメインとユーザーの関連を確認し、In-Region Routing が規制要件または組織要件を満たすのに役立つかどうかを検討する絶好の機会です。</p><p>詳細: <a href="https://learn.microsoft.com/microsoft-365/enterprise/configure-multi-geo-in-region-routing?view=o365-worldwide">複数地域の In-Region ルーティングを構成する - Microsoft 365 Enterprise | Microsoft Learn</a></p>]]></content>
    
    
      
      
    <summary type="html">&lt;p&gt;※ この記事は、&lt;a href=&quot;https://techcommunity.microsoft.com/blog/exchange/multi-geo-in-region-routing-general-availability/4494860&quot;&gt;Multi-Geo In</summary>
      
    
    
    
    
    <category term="Exchange Online" scheme="https://jpmessaging.github.io/blog/tags/Exchange-Online/"/>
    
  </entry>
  
  <entry>
    <title>Exchange Online PowerShell における -Credential パラメーターの廃止</title>
    <link href="https://jpmessaging.github.io/blog/deprecation-of-the--credential-parameter-in-exchange-online-powershell/"/>
    <id>https://jpmessaging.github.io/blog/deprecation-of-the--credential-parameter-in-exchange-online-powershell/</id>
    <published>2026-02-14T00:00:00.000Z</published>
    <updated>2026-02-14T00:00:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>※ この記事は、<a href="https://techcommunity.microsoft.com/blog/exchange/deprecation-of-the--credential-parameter-in-exchange-online-powershell/4494584">Deprecation of the -Credential Parameter in Exchange Online PowerShell</a> の抄訳です。最新の情報はリンク先をご確認ください。この記事は Microsoft 365 Copilot および GitHub Copilot を使用して抄訳版の作成が行われています。</p><p>Exchange Online のセキュリティ強化に向けた継続的な取り組みの一環として、Exchange Online PowerShell モジュールに対する重要な変更についてお知らせします。</p><h4 id="変更内容と理由"><a href="#変更内容と理由" class="headerlink" title="変更内容と理由"></a>変更内容と理由</h4><p>Microsoft は、すべてのサービスにおいて、より安全で最新の認証方式へ段階的に移行しています。この取り組みの一環として、多要素認証 (MFA) は Microsoft クラウド サービス全体における必須のセキュリティ要件となりつつあります。従来の Resource Owner Password Credentials (ROPC) 認証フローは MFA をサポートしていないため、Microsoft によるセキュリティ基準強化の一環として、廃止に向けた段階に入っています。さらに、Microsoft の各種サービスで使用されている認証ライブラリである Microsoft Authentication Library (MSAL) においても、バージョン 4.74.0 以降、ROPC を非推奨としています。</p><p>Exchange Online PowerShell の -Credential パラメーターは ROPC に依存しているため、MFA や条件付きアクセスの要件を満たしていません。MFA の強制適用、先進認証に関する原則、ならびに Microsoft の包括的なセキュリティ基準に対応するため、<strong>2026 年 6 月以降</strong> にリリースされる新しい Exchange Online PowerShell バージョンでは、-Credential パラメーターのサポートが廃止される予定です。</p><p><code>この変更は Connect-ExchangeOnline と Connect-IppsSession の両方のコマンドレットに適用されます。</code></p><p>タイムライン上は 2026 年 6 月までですが、期限まで待たずに可能な限り早期に -Credential パラメーターの使用から移行することを強く推奨します。</p><h4 id="Credential-パラメーターの代替方法"><a href="#Credential-パラメーターの代替方法" class="headerlink" title="-Credential パラメーターの代替方法"></a>-Credential パラメーターの代替方法</h4><p>以下はシナリオ別に利用可能な -Credential パラメーターの代替方法を示します。</p><table><thead><tr><th><strong>シナリオ &#x2F; ユース ケース</strong></th><th><strong>推奨される認証方法</strong></th><th><strong>説明</strong></th><th><strong>公開情報</strong></th></tr></thead><tbody><tr><td><strong>管理者による対話型接続</strong></td><td><em>対話型サインイン (先進認証 + MFA)</em></td><td>管理者向けのセキュアなサインイン。MFA と条件付きアクセスをサポートします。</td><td><a href="https://learn.microsoft.com/powershell/exchange/connect-to-exchange-online-powershell?view=exchange-ps">Exchange Online PowerShell に接続する | Microsoft Learn</a></td></tr><tr><td><strong>Azure の外部でのオートメーション実行</strong></td><td><em>アプリ専用認証</em></td><td>非対話型オートメーション用の証明書ベースまたはシークレットベースのアプリ登録。</td><td><a href="https://learn.microsoft.com/powershell/exchange/app-only-auth-powershell-v2?view=exchange-ps">Exchange Online PowerShell とセキュリティ &amp; コンプライアンス PowerShell での無人スクリプトのアプリ専用認証 | Microsoft Learn</a></td></tr><tr><td><strong>Azure サービス内でのオートメーション実行</strong></td><td><em>マネージド ID 認証</em></td><td>Functions、Automation Accounts、クラウドネイティブなタスクに最適。シークレットを完全に不要にします。</td><td><a href="https://learn.microsoft.com/powershell/exchange/connect-exo-powershell-managed-identity?view=exchange-ps">Azure マネージド ID を使用して Exchange Online PowerShell に接続する | Microsoft Learn</a></td></tr></tbody></table><h4 id="タイムライン"><a href="#タイムライン" class="headerlink" title="タイムライン"></a>タイムライン</h4><ul><li><strong>現在の状態:</strong> <em>-Credential</em> パラメーターは現時点でもサポートされており、2026 年 6 月末までにリリースされるすべてのモジュールで引き続き利用可能です。</li><li><strong>推奨される対応 (即座に実施):</strong> <em>Connect-ExchangeOnline または Connect-IppsSession コマンドレットを使用して Exchange Online に接続する際に、-Credential パラメーターを使わない方法へ切り替え始めてください。</em></li><li><strong>2026 年 6 月以降:</strong> 2026 年以降にリリースされる Exchange Online PowerShell モジュールの新しいバージョンでは、-Credential パラメーターはサポートされなくなります。</li></ul><p>代替認証フローにおいて不足している点やサポートされていないシナリオがありましたら、今後のアップデートで優先的に対応するため、コメント欄でお知らせください。</p><p>更新履歴:</p><ul><li>2&#x2F;17&#x2F;2026: この変更は <em>Connect-ExchangeOnline</em> と <em>Connect-IppsSession</em> の両方に適用されることを追記しました。</li></ul>]]></content>
    
    
      
      
    <summary type="html">&lt;p&gt;※ この記事は、&lt;a href=&quot;https://techcommunity.microsoft.com/blog/exchange/deprecation-of-the--credential-parameter-in-exchange-online-powershell</summary>
      
    
    
    
    
    <category term="Exchange Online" scheme="https://jpmessaging.github.io/blog/tags/Exchange-Online/"/>
    
  </entry>
  
  <entry>
    <title>2026 年 2 月の Exchange Server のセキュリティ更新プログラムが公開されました</title>
    <link href="https://jpmessaging.github.io/blog/released-february-2026-exchange-server-security-updates/"/>
    <id>https://jpmessaging.github.io/blog/released-february-2026-exchange-server-security-updates/</id>
    <published>2026-02-12T06:00:00.000Z</published>
    <updated>2026-02-12T06:00:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>※ この記事は、<a href="https://techcommunity.microsoft.com/blog/exchange/released-february-2026-exchange-server-security-updates/4494076">Released: February 2026 Exchange Server Security Updates</a> の抄訳です。最新の情報はリンク先をご確認ください。この記事は Microsoft 365 Copilot および GitHub Copilot を使用して抄訳版の作成が行われています。</p><p>Microsoft は、以下の製品に存在する脆弱性に対応するセキュリティ更新プログラム (SU) をリリースしました。</p><ul><li>Exchange Server Subscription Edition (SE)</li><li>Exchange Server 2019</li><li>Exchange Server 2016</li></ul><p>以下の Exchange Server のバージョン向けに SU が提供されています。</p><ul><li><a href="https://www.microsoft.com/download/details.aspx?id=108556">Exchange SE RTM</a></li><li>Exchange Server 2019 CU14 および CU15 (アクセスするには、<a href="https://jpmessaging.github.io/blog/announcing-exchange-2016--2019-extended-security-update-program/">ESU プログラム</a>の登録が必要)</li><li>Exchange Server 2016 CU23 (アクセスするには、<a href="https://jpmessaging.github.io/blog/announcing-exchange-2016--2019-extended-security-update-program/">ESU プログラム</a>の登録が必要)</li></ul><p>2026 年 2 月のセキュリティ更新プログラム（SU）は、セキュリティ パートナーから責任を持って報告された脆弱性や、Microsoft の内部プロセスによって発見された脆弱性に対応しています。現時点でこれらの脆弱性を悪用した攻撃は確認されていませんが、環境を保護するため、できるだけ早くこれらの更新プログラムを適用することを推奨します。</p><p>これらの脆弱性は Exchange Server に影響します。Exchange Online のお客様は、今回のセキュリティ更新プログラムで対応された脆弱性について既に保護されていますので、特別な対応は不要です。ただし、環境内に存在する Exchange サーバーや Exchange 管理ツールをインストールしたワークステーションについては、引き続き更新プログラムの適用を行ってください。</p><p>特定の脆弱性 (CVE) に関する詳細は、<a href="https://msrc.security.microsoft.com/update-guide/">Security Update Guide</a> (Exchange SE については Product Family で “Server Software” でフィルター、Exchange Server 2016 および 2019 については Product Family で “ESU” でフィルター) を参照してください。</p><h3 id="Exchange-2016-および-2019-の更新プログラムは-ESU-プログラムでのみ提供されています"><a href="#Exchange-2016-および-2019-の更新プログラムは-ESU-プログラムでのみ提供されています" class="headerlink" title="Exchange 2016 および 2019 の更新プログラムは ESU プログラムでのみ提供されています"></a>Exchange 2016 および 2019 の更新プログラムは ESU プログラムで<em>のみ</em>提供されています</h3><p>Exchange Server 2016 および 2019 は<a href="https://jpmessaging.github.io/blog/support-for-exchange-server-2016-and-exchange-server-2019-ends-today/">サポートが終了</a>しています。</p><p><a href="https://jpmessaging.github.io/blog/announcing-exchange-2016--2019-extended-security-update-program/">拡張セキュリティ更新プログラム (ESU) プログラム</a>に登録しているお客様は、Exchange Server 2016 および 2019 向けの 2026 年 2 月のセキュリティ更新プログラムを受け取ることができます。</p><p>ESU プログラムに登録していない場合は、<a href="https://jpmessaging.github.io/blog/Upgrading-your-organization-from-current-versions-to-Exchange-Server-SE/">Exchange Server SE に移行</a>して、最新のセキュリティ更新プログラムを引き続き受け取ることができます。</p><p><em>既に ESU を購入済みで</em>、最新のセキュリティ更新プログラムへのアクセスに関する情報が必要な場合は、<a href="mailto:&#x45;&#x78;&#x63;&#x68;&#97;&#110;&#103;&#101;&#x61;&#x6e;&#x64;&#83;&#x66;&#x42;&#83;&#101;&#114;&#118;&#101;&#x72;&#x45;&#x53;&#85;&#73;&#x6e;&#113;&#117;&#105;&#114;&#x79;&#x40;&#115;&#x65;&#114;&#x76;&#105;&#x63;&#101;&#46;&#109;&#105;&#x63;&#x72;&#111;&#115;&#111;&#x66;&#116;&#x2e;&#99;&#x6f;&#109;&#x3f;&#x73;&#x75;&#98;&#x6a;&#x65;&#x63;&#x74;&#61;&#87;&#x65;&#37;&#x32;&#48;&#112;&#117;&#x72;&#99;&#104;&#97;&#115;&#x65;&#x64;&#x25;&#50;&#48;&#69;&#x78;&#99;&#104;&#x61;&#110;&#103;&#x65;&#x25;&#x32;&#48;&#69;&#x53;&#85;&#37;&#50;&#x30;&#110;&#101;&#x65;&#100;&#37;&#50;&#x30;&#x61;&#99;&#x63;&#x65;&#115;&#115;">ExchangeandSfBServerESUInquiry@service.microsoft.com</a> にメールを送信してお問い合わせください。</p><h4 id="更新プログラムのインストール"><a href="#更新プログラムのインストール" class="headerlink" title="更新プログラムのインストール"></a>更新プログラムのインストール</h4><p>利用可能な更新パスは以下の通りです。<br><img src="/blog/released-february-2026-exchange-server-security-updates/Feb2026SU.jpg"></p><ul><li><a href="https://aka.ms/ExchangeHealthChecker">Exchange Server Health Checker スクリプト</a>を使用して、更新が必要な Exchange サーバーのインベントリを作成し、各サーバーの更新状況 (CU、SU、手動対応) を確認してください。</li><li>最新の CU をインストールします。<a href="https://aka.ms/ExchangeUpdateWizard">Exchange Update Wizard</a> を利用して、現在の CU と目標 CU を選択し、手順を確認してください。</li><li>更新プログラムのインストール後に再度 Health Checker を実行し、追加の対応が必要かどうかを確認します。</li><li>セットアップ完了後、サーバーを再起動し、すべての Exchange サービスが正常に起動したことを確認します。一部のサービスが無効状態になっている場合は、更新プログラムのインストールが何らかの理由で中断されたことを示しています。詳細については、<a href="https://support.microsoft.com/topic/2024-su-a650da30-f8fb-469d-a449-47396cab0a15">この記事</a>の「回避策 1」を参照してください。</li><li>Exchange Server のインストール中やインストール後にエラーが発生した場合は、<a href="https://aka.ms/ExSetupAssist">SetupAssist スクリプト</a>を実行してください。更新後に問題が発生した場合は、<a href="https://aka.ms/ExchangeFAQ">失敗した Exchange Server の更新プログラムの修復方法</a>や、<a href="https://support.microsoft.com/topic/file-version-error-when-you-try-to-install-exchange-server-november-2024-su-a650da30-f8fb-469d-a449-47396cab0a15">ファイル バージョン エラーに関する KB 記事</a>も確認してください。</li></ul><h4 id="よくあるご質問"><a href="#よくあるご質問" class="headerlink" title="よくあるご質問"></a>よくあるご質問</h4><p><strong>弊社の環境は Exchange Online とのハイブリッド構成ですが、対応は必要ですか？</strong><br>Exchange Online は既に保護されていますが、管理目的のみで利用している場合も含め、オンプレミスの Exchange サーバーには今回のセキュリティ更新プログラム (SU) を必ずインストールしてください。SU 適用後に認証証明書を変更する場合は、ハイブリッド構成ウィザードを再実行する必要があります。</p><p><strong>最後にインストールした SU&#x2F;HU は数か月前のものですが、最新の SU をインストールするためにすべての SU を順番に適用する必要がありますか？</strong><br>すべての SU は累積的です。サポートされている CU を使用している場合、すべての SU や HU を順番にインストールする必要はなく、最新の SU を適用するだけで問題ありません。詳細は<a href="https://techcommunity.microsoft.com/t5/exchange-team-blog/why-exchange-server-updates-matter/ba-p/2280770">こちらのブログ記事</a>を確認してください。</p><p><strong>組織内のすべての Exchange Server に SU をインストールする必要がありますか？”Exchange 管理ツールのみ” インストールされたマシンはどうなりますか？</strong><br><u>すべて</u>の Exchange Server および Exchange 管理ツールがインストールされたすべてのサーバー &#x2F; ワークステーションに SU を適用することを推奨します。これにより、管理ツールのクライアントとサーバー間の互換性が確保されます。稼働中の Exchange Server が存在しない環境で Exchange 管理ツールのみを更新する場合は、<a href="https://learn.microsoft.com/exchange/manage-hybrid-exchange-recipients-with-management-tools#update-the-exchange-server-management-tools-only-role-with-no-running-exchange-server-to-a-newer-cumulative-or-security-update">こちら</a>を確認してください。 </p><p><strong>弊社は Exchange 2016 および 2019 の ESU を登録していません。現在の Exchange 2016 または 2019 の更新プログラムを入手するにはどうすればよいですか？</strong><br>Exchange 2016 および 2019 は現在<a href="https://jpmessaging.github.io/blog/support-for-exchange-server-2016-and-exchange-server-2019-ends-today/">サポートが終了</a>しているため、<a href="https://jpmessaging.github.io/blog/announcing-exchange-2016--2019-extended-security-update-program/">ESU プログラムに登録</a>しているお客様（2026 年 4 月まで有効）のみが、ESU 対象としてリリースされる Exchange 2016 または 2019 の更新プログラムを入手できます。Exchange 2016 または 2019 を引き続き利用しているすべてのお客様には、できるだけ早く <a href="https://jpmessaging.github.io/blog/Upgrading-your-organization-from-current-versions-to-Exchange-Server-SE/">Exchange Server SE に移行</a>することを推奨します。</p><p>本記事公開時点では、関連するドキュメントが完全には利用できない場合があります。</p><p>今後、記事内容に更新があった場合は、こちらに追記します。</p>]]></content>
    
    
      
      
    <summary type="html">&lt;p&gt;※ この記事は、&lt;a href=&quot;https://techcommunity.microsoft.com/blog/exchange/released-february-2026-exchange-server-security-updates/4494076&quot;&gt;Relea</summary>
      
    
    
    
    
    <category term="Exchange" scheme="https://jpmessaging.github.io/blog/tags/Exchange/"/>
    
  </entry>
  
  <entry>
    <title>Exchange Online EWS：廃止期限が迫っています</title>
    <link href="https://jpmessaging.github.io/blog/exchange-online-ews-your-time-is-almost-up/"/>
    <id>https://jpmessaging.github.io/blog/exchange-online-ews-your-time-is-almost-up/</id>
    <published>2026-02-06T03:00:00.000Z</published>
    <updated>2026-02-06T03:00:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>※ この記事は、<a href="https://techcommunity.microsoft.com/blog/exchange/exchange-online-ews-your-time-is-almost-up/4492361">Exchange Online EWS, Your Time is Almost Up</a> の抄訳です。最新の情報はリンク先をご確認ください。この記事は Microsoft 365 Copilot および GitHub Copilot を使用して抄訳版の作成が行われています。</p><p><strong>Exchange Web Services (EWS) は Exchange Online でのサービス終了が近づいています。</strong> この変更については、2018 年に <a href="https://techcommunity.microsoft.com/blog/exchange/upcoming-changes-to-exchange-web-services-ews-api-for-office-365/608055">Exchange Web Services (EWS) の機能更新を終了する</a> と初めて発表しました。その後 2023 年には、<a href="https://devblogs.microsoft.com/microsoft365dev/retirement-of-exchange-web-services-in-exchange-online/">EWS が 2026 年 10 月に Exchange Online で無効化される</a>ことを発表しました。</p><p>本日、2026 年 10 月に開始し、2027 年に EWS を完全に停止するまで段階的に実施される、管理者が制御可能な無効化計画について発表します。本記事では、何が起こるのか、いつ起こるのか、そして管理者が <em>今</em> から何をすべきかについて説明します。</p><p>本日の発表および EWS の廃止は <strong>Microsoft 365 および Exchange Online（すべての環境）にのみ適用されます</strong>。<strong>Exchange Server の EWS に変更はありません。</strong></p><h3 id="EWS-が廃止される理由"><a href="#EWS-が廃止される理由" class="headerlink" title="EWS が廃止される理由"></a>EWS が廃止される理由</h3><p>EWS は約 20 年前に構築されたもので、これまでエコシステムに大きく貢献してきましたが、現在求められているセキュリティ、スケール、信頼性の要件にはもはや適合しなくなっています。過去数年で、以下のような状況が進んでいます。</p><ul><li>Microsoft Graph は、EWS の利用シナリオの大部分において<a href="https://learn.microsoft.com/exchange/clients-and-mobile-in-exchange-online/deprecation-of-ews-exchange-online#roadmap-for-parity-gaps">ほぼ完全な機能互換</a>を達成しています。</li><li>Microsoft 自身のアプリケーションは、既に EWS から移行済みか、または移行をほぼ完了しています。</li><li>多くのサード パーティ ベンダーも既に移行を完了しているか、積極的に移行を進めています。</li></ul><p>EWS を廃止することで、レガシーな機能の範囲を縮小し、プラットフォームの動作を簡素化するとともに、すべてのユーザーにより一貫したモダンなエクスペリエンスを提供できるようになります。</p><h3 id="EWS-はどのように無効化されますか？"><a href="#EWS-はどのように無効化されますか？" class="headerlink" title="EWS はどのように無効化されますか？"></a>EWS はどのように無効化されますか？</h3><p>EWS は <a href="https://learn.microsoft.com/exchange/client-developer/exchange-web-services/how-to-control-access-to-ews-in-exchange"><em>EWSEnabled</em> プロパティ</a> を使用して <strong>テナント単位</strong> で無効化されます。このプロパティは <strong>True、False、Null</strong> (現在の既定値) の 3 つの値があります。また、2026 年初頭に提供予定の新機能として、管理者は <strong>AppID 許可リスト</strong> を定義できるようになります。この機能を有効にすると、そのリストに登録されたアプリのみが EWS にアクセスできるようになります。</p><p>テナント内の <em>EWSEnabled</em> プロパティは、2026 年 10 月 1 日（またはその直後）に以下のように変更されます。</p><table><thead><tr><th><strong>EWSEnabled の値</strong></th><th><strong>2026 年 10 月以前</strong></th><th><strong>2026 年 10 月以降</strong></th></tr></thead><tbody><tr><td><strong>True</strong></td><td>すべての EWS が許可</td><td>許可リスト内のアプリのみ許可</td></tr><tr><td><strong>False</strong></td><td>すべての EWS がブロック</td><td>すべての EWS がブロック</td></tr><tr><td><strong>Null</strong></td><td>すべての EWS が許可</td><td>すべての EWS が許可 (許可リストは無視)</td></tr></tbody></table><p>2026 年 10 月 1 日時点で <em>EWSEnabled</em> が引き続き <strong>Null</strong> に設定されているテナントでは、展開の進行に伴い、値が <strong>False</strong> に変更されます。展開完了後、当該テナント内のすべてのアプリケーションに対して EWS がブロックされます。</p><p>EWS をブロックしたままにしておきたい場合は、特に何もせず、そのままにしておくだけです。</p><p>一方、引き続き EWS を利用する必要がある場合は、次の 2 つの選択肢があります。</p><ol><li><em>EWSEnabled</em> を <strong>True</strong> に設定し、<a href="https://learn.microsoft.com/microsoft-365/baseline-security-mode/baseline-security-mode-settings?view=o365-worldwide">ベースライン セキュリティ モード</a>または Exchange Online PowerShell 経由で許可リストを管理する。</li><li><em>EWSEnabled</em> を <strong>Null</strong> に戻すことで、最終的な廃止が行われるまでの間、EWS が制限なしで再度有効化になります。この操作は Exchange Online PowerShell を使用して行う必要があります。</li></ol><p>さらに、<strong>2026 年 8 月末までに</strong>許可リストを事前に設定し、<em>EWSEnabled</em> を <strong>True</strong> に設定したテナントは、10 月 1 日の自動変更（EWSEnabled&#x3D;False）から除外されます。</p><p>この移行期間を支援するため、2026 年 9 月までに許可リストを作成していないお客様に対して、各テナントの実際の利用状況に基づいて、許可リストを事前に自動作成します。なお、2026 年 10 月に EWS がブロックされた後、引き続き EWS が必要であることに気付いた場合でも、管理者は EWSEnabled を <strong>True</strong> に設定することで EWS を再度有効化できます。ただし、この場合はサービスの一時的な中断が生じることに注意してください。</p><h3 id="主要な日程"><a href="#主要な日程" class="headerlink" title="主要な日程"></a>主要な日程</h3><p><strong>準備期間（現在）</strong></p><p>この段階では、EWS は引き続き利用可能ですが、管理者は以下の準備を行うことが推奨されます。</p><ul><li>Microsoft 365 管理センターで <a href="https://learn.microsoft.com/microsoft-365/admin/activity-reports/ews-usage?view=o365-worldwide">EWS の使用状況レポート</a> を確認し、必要に応じて公開されているスクリプトの使用を検討してください。</li><li>オプション：2026 年 8 月末までに、許可リストを設定し、<em>EWSEnabled</em> を <strong>True</strong> に設定してください。</li><li>Microsoft Graph へのアプリケーション移行を開始してください。</li></ul><p><strong>EWS を引き続き使用しているテナントに対する初回ブロック – 2026 年 10 月 1 日から開始</strong></p><p>2026 年 8 月までに許可リストや、EWSEnabled&#x3D;True を明示的に設定していない Exchange Online テナントでは、EWS は <strong>既定でブロック</strong> （EWSEnabled&#x3D;False）される予定です。この時点で、以下の状態になります。</p><ul><li>管理者が事前に対応を行われていない場合、EWS のリクエストはブロックされます。</li><li>重要な業務フローに影響が出る場合、管理者は EWSEnabled&#x3D;True に設定することで、一時的に EWS を有効化できます。</li></ul><p><strong>EWS の最終的な停止 – 2027 年 4 月 1 日</strong><br><strong>2027 年 4 月 1 日</strong> から、EWS は <strong>完全かつ恒久的に無効化</strong> されます。</p><ul><li>テナント管理者による <em>EWSEnabled</em> を制御する機能は削除されます。</li></ul><p>以下は、タイムラインの図です。<br><img src="/blog/exchange-online-ews-your-time-is-almost-up/EWS01.jpg"></p><h3 id="継続的な情報提供と監視"><a href="#継続的な情報提供と監視" class="headerlink" title="継続的な情報提供と監視"></a>継続的な情報提供と監視</h3><p>予期しない問題を回避するため、管理者にテナント固有の EWS 使用状況のサマリーとリマインダーを含む <strong>monthly Message Center posts</strong> を配信します。</p><p>また、<strong>一時的な「スクリームテスト」</strong> （短い期間に EWS を一時的にオフにしてからオンに戻すテスト）を実施する場合があります。これにより、最終的なカットオフ前に潜在的な依存関係を明らかにするのに役立ちます。詳細については、今後数週間でお知らせします。今のうちに EWSEnabled を True に設定すれば、実施される可能性のある「スクリームテスト」の影響を受けることはありません。</p><h3 id="まとめ"><a href="#まとめ" class="headerlink" title="まとめ"></a>まとめ</h3><p>今こそ、利用環境を評価し、アプリケーションの開発元と連携しながら、Microsoft Graph への移行計画を立てる適切な時期です。早期の対応により、予期しない問題を回避でき、よりスムーズな移行が実現できます。</p><h3 id="よくあるご質問"><a href="#よくあるご質問" class="headerlink" title="よくあるご質問"></a>よくあるご質問</h3><p><strong>既に EWSApplicationAccessPolicy 設定を使用して EWS ブロックを構成しています。新しい許可リストと既存のリストはどのように連携しますか？</strong><br>新しい AppID 許可リストが優先されます。アプリが EWS にアクセスするためには、両方のチェックにクリアする必要があります。</p><p><strong>EWS を使用しているアプリケーションがたくさんあります。移行にどのくらいの作業が必要か全くわかりません。どうすればよいですか！</strong><br>まず、公開されている使用状況ツールをご利用ください (ワールドワイド テナントは<a href="https://learn.microsoft.com/microsoft-365/admin/activity-reports/ews-usage?view=o365-worldwide">こちら</a>)。ほとんどのアプリはごく限られた EWS の機能しか使用していません。最新のツール（AI 活用した移行を含む）を利用することで、想像しているよりも簡単に移行できるケースが多くあります。</p><p><strong>Microsoft Graph API とは機能差分がありますが、EWS から Graph へ本当に移行できるのでしょうか?</strong><br>Microsoft では残っている機能差分を積極的に追跡し、その状況を公開しています。ほとんどの EWS ベースのワークロードは現在移行可能です。最新の機能差分の状況については、このページ <a href="https://learn.microsoft.com/exchange/clients-and-mobile-in-exchange-online/deprecation-of-ews-exchange-online#roadmap-for-parity-gaps">Exchange Online での Exchange Web Services の廃止 | Microsoft Learn</a> を確認してください。このドキュメントは常に最新の内容に更新されており、新しい情報が利用可能になり次第、関連する追加情報へのリンクも随時掲載します。</p><p><strong>オンプレミス Exchange やハイブリッド構成の場合はにどうなりますか？</strong><br>EWS はオンプレミスでは廃止されません。ハイブリッド構成については、アプリケーションがどのようにデータへアクセスしているかによって対応が異なります。オンプレミスのメールボックスへのアクセスは EWS を引き続き使用でき、クラウド メールボックスへのアクセスは Microsoft Graph に移行する必要があります。<br>アプリケーションは Autodiscover を利用して、メールボックスの場所 (オンプレミスかクラウドか) を自動的に判別できます。  </p><p>ただし、Exchange Online への Microsoft Graph 経由のアクセスをサポートするのは Exchange SE のみであるため、ハイブリッド環境におけるオンプレミス メールボックスは Exchange SE を<em>使用することが前提となります</em>。詳細は<a href="https://jpmessaging.github.io/blog/exchange-server-security-changes-for-hybrid-deployments/">こちら</a>をご覧ください。</p><p><strong>2027 年 4 月までに準備が間に合いません。延長を受けることはできますか？</strong><br>2027 年 4 月以降の例外措置はありません。</p><p><strong>2026 年 8 月に許可リストを作成せずに EWSEnabled&#x3D;True を設定できますか？</strong><br>はい、設定できますが、管理者が自分のニーズに合わせて許可リストを作成することをお勧めします。2026 年 9 月には、各テナントの使用状況に基づいて、許可リストが自動作成されます。8 月に EWSEnabled&#x3D;True だけを設定し、9 月に許可リストを自動作成される場合、管理者が把握していないアプリケーション（使用状況が確認されている場合）も含まれる可能性があります。2026 年 10 月以降に許可する EWS アプリケーションを正確に制御するためにも、管理者が自ら許可リストを作成することを推奨します。</p><p><strong>2026 年 8 月までに独自の許可リストを作成した場合、2026 年 9 月にすべてのテナントの自動許可リスト作成処理で、その内容は変更されますか？</strong><br>いいえ。独自の許可リストを作成した場合、自動許可リスト作成処理によって既に作成された許可リストが変更されることはありません。作成済みの許可リストは、そのまま維持されます。</p><p>変更履歴:</p><ul><li>2026&#x2F;2&#x2F;9: 今のうちに EWSEnabled を True に設定することで、将来の「スクリームテスト」から除外されることを示すメモを追加しました</li></ul>]]></content>
    
    
      
      
    <summary type="html">&lt;p&gt;※ この記事は、&lt;a href=&quot;https://techcommunity.microsoft.com/blog/exchange/exchange-online-ews-your-time-is-almost-up/4492361&quot;&gt;Exchange Online EW</summary>
      
    
    
    
    
    <category term="Exchange Online" scheme="https://jpmessaging.github.io/blog/tags/Exchange-Online/"/>
    
  </entry>
  
  <entry>
    <title>すべての Outlook クライアントでモデレーション承認が効率化されました</title>
    <link href="https://jpmessaging.github.io/blog/streamlined-moderation-approvals-now-in-all-outlook-clients/"/>
    <id>https://jpmessaging.github.io/blog/streamlined-moderation-approvals-now-in-all-outlook-clients/</id>
    <published>2026-02-02T15:00:00.000Z</published>
    <updated>2026-02-02T15:00:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>※ この記事は、<a href="https://techcommunity.microsoft.com/blog/exchange/streamlined-moderation-approvals-now-in-all-outlook-clients/4491618">Streamlined Moderation Approvals, Now in All Outlook Clients</a> の抄訳です。最新の情報はリンク先をご確認ください。この記事は Microsoft 365 Copilot および GitHub Copilot を使用して抄訳版の作成が行われています。</p><h4 id="はじめに"><a href="#はじめに" class="headerlink" title="はじめに"></a>はじめに</h4><p><a href="https://learn.microsoft.com/exchange/recipients-in-exchange-online/moderated-recipients-exo/moderated-recipients-exo">Exchange Online のメール モデレーション</a> は、人による確認が必要なメッセージが見過ごされないようにする機能です。ただし、現在のワークフローには制約があり、わかりにくい点もあります。メッセージを承認または拒否するには、モデレーターは投票ボタンをサポートする Outlook クライアントを使用する必要がありますが、すべてのクライアントが対応しているわけではありません (例えば Outlook Mobile などは対応していません)。また、メッセージが分割またはフォークされると、複数の承認リクエストを受け取ることがあります。</p><p>これらの課題に対応するため、<strong>すべての Outlook クライアントでのモデレーション承認</strong>と<strong>承認メッセージの統合</strong>という 2 つのアップデートの展開を開始したことをお知らせします。これらのアップデートにより、モデレーターはより柔軟にモデレーション承認を行うことができ、ノイズを減らしながら迅速に対応できるようになります。</p><h4 id="新機能"><a href="#新機能" class="headerlink" title="新機能"></a>新機能</h4><h6 id="すべての-Outlook-クライアントから承認または拒否が可能に"><a href="#すべての-Outlook-クライアントから承認または拒否が可能に" class="headerlink" title="すべての Outlook クライアントから承認または拒否が可能に"></a><strong>すべての Outlook クライアントから承認または拒否が可能に</strong></h6><p>モデレーション承認メッセージについては、従来の Outlook の投票ボタン機能から、Actionable Messages のアダプティブ カードへ移行します。これにより、<strong>承認 | 拒否</strong> ボタンがメッセージ本文に直接表示されます。投票ボタンとは異なり、Actionable Messages のアダプティブ カードは Windows、Mac、Web、モバイルを含むすべての Outlook クライアントで動作するため、モデレーターは自分に最適なクライアントやデバイスから承認または拒否を行えるようになります。</p><h6 id="承認メッセージの統合"><a href="#承認メッセージの統合" class="headerlink" title="承認メッセージの統合"></a><strong>承認メッセージの統合</strong></h6><p>モデレート対象のメッセージが非常に大きな配布リスト (DL) やグループに送信される場合、遅延を軽減するために Exchange Online はメッセージを複数のコピーに分割することがあります (いわゆる <a href="https://learn.microsoft.com/exchange/reference/bifurcation">分岐</a>)。この場合、各コピーがそれぞれ承認リクエストをトリガーする可能性があります。同様に、トランスポート ルールやポリシーによってメッセージがフォークされた場合も、同じ内容に対して重複した承認リクエストが発生することがあります。今回のアップデートでは、このフローを効率化し、メッセージがフォークされたり複数の経路で処理されたりしても、モデレーターには通常 1 つの承認リクエストのみが表示されるようになりました。ただし、メッセージが本当に複数の承認を必要とする場合は、すべての受信者にメッセージを配信するために各経路で承認が必要となります。</p><h4 id="今回のアップデートによる組織へのメリット"><a href="#今回のアップデートによる組織へのメリット" class="headerlink" title="今回のアップデートによる組織へのメリット"></a>今回のアップデートによる組織へのメリット</h4><ul><li><strong>より迅速で柔軟な承認:</strong> モデレーターは好みのデバイスから対応でき、クライアントを切り替える必要がありません。</li><li><strong>一貫したエクスペリエンス:</strong> Windows、Mac、Web、モバイルで同じ UI と操作が可能です。</li><li><strong>ノイズの軽減:</strong> ほとんどの場合、1 つのメッセージに対して 1 つの承認リクエストのみが届くため、すべての配信経路を正しく保ちながらモデレーション通知の煩雑さを軽減できます。</li></ul><h4 id="これらのアップデートが利用可能となる時期"><a href="#これらのアップデートが利用可能となる時期" class="headerlink" title="これらのアップデートが利用可能となる時期"></a>これらのアップデートが利用可能となる時期</h4><p>モデレーション承認用の Actionable Messages アダプティブ カードは、2026 年 3 月上旬から展開を開始し、2026 年 4 月下旬までに完了する見込みです (Worldwide および GCC 環境向け)。GCC High および DoD 環境では Actionable Messages がまだサポートされていないため、これらの環境では当面の間、従来の投票ボタン方式によるモデレーション承認が継続されます。<br>承認メッセージの統合も同じく 3 月上旬から 4 月下旬にかけて、すべての環境 (Worldwide、GCC、GCC High、DoD) で展開されます。</p><h4 id="管理者向けの注意事項"><a href="#管理者向けの注意事項" class="headerlink" title="管理者向けの注意事項"></a>管理者向けの注意事項</h4><ul><li><p>新しいモデレーション承認エクスペリエンスをすべての Outlook クライアントで利用するには、テナントでメール用の Actionable Messages 機能が有効になっている必要があります。Actionable Messages が無効になっている場合 (既定では有効)、PowerShell で以下のコマンドを実行して有効化できます:</p><pre><code>Set-OrganizationConfig -SmtpActionableMessagesEnabled $true Set-OrganizationConfig -ConnectorsActionableMessagesEnabled $true</code></pre></li><li><p>Actionable Messages 機能は Microsoft 365 でのみサポートされており、オンプレミスの Exchange 環境では利用できません。そのため、Exchange ハイブリッド構成の組織では、オンプレミスのモデレーターには承認ボタンが表示されません。Actionable Messages への移行を円滑に進めるため、2026 年 7 月 31 日まで従来の投票ボタンとアダプティブ カードの両方のエクスペリエンスをサポートします。それ以降は、新しい Actionable Messages アダプティブ カード方式のみがサポートされるため、モデレーターのメールボックスは Microsoft 365 でホストされている必要があります。</p></li><li><p>移行期間中 (7 月末まで)、モデレーターには承認メッセージがさまざまな形式で表示される場合があります。従来の投票ボタンのみ、アダプティブ カードによる承認ボタンのみ、またはその両方が表示されることがあります。7 月末まではすべての形式がサポートされ、正常に動作します。それ以降は、投票ボタンによる承認は廃止され、Actionable Messages のアダプティブ カードによる承認ボタンのみがサポートおよび表示されるようになります。</p></li></ul><p><strong>関連情報</strong></p><ul><li><a href="https://learn.microsoft.com/exchange/recipients-in-exchange-online/moderated-recipients-exo/moderated-recipients-exo">Manage message approval in Exchange Online | Microsoft Learn</a></li><li><a href="https://learn.microsoft.com/exchange/reference/bifurcation">Bifurcation and its technicalities with implications | Microsoft Learn</a></li><li><a href="https://learn.microsoft.com/powershell/module/exchangepowershell/set-organizationconfig?view=exchange-ps">Set-OrganizationConfig (ExchangePowerShell) | Microsoft Learn</a></li></ul><h4 id="よくあるご質問"><a href="#よくあるご質問" class="headerlink" title="よくあるご質問"></a>よくあるご質問</h4><p><strong>Q: 承認メッセージに投票ボタンと新しい承認ボタンの両方が表示されている場合、どちらを使用すればよいですか？</strong></p><p>A: どちらを使用しても問題ありません。</p><p><strong>Q: 組織でメッセージのフォークを引き起こすカスタム トランスポート ルールを使用している場合はどうなりますか？</strong></p><p>A: フォークが発生するシナリオでは、複数の承認リクエストが届く場合があります。すべての宛先にメッセージを配信するには、各経路で承認が必要です。これにより、すべての配信経路が正しく処理されます。</p>]]></content>
    
    
      
      
    <summary type="html">&lt;p&gt;※ この記事は、&lt;a href=&quot;https://techcommunity.microsoft.com/blog/exchange/streamlined-moderation-approvals-now-in-all-outlook-clients/4491618&quot;&gt;S</summary>
      
    
    
    
    
    <category term="Exchange Online" scheme="https://jpmessaging.github.io/blog/tags/Exchange-Online/"/>
    
  </entry>
  
  <entry>
    <title>Exchange Online のメール中断を回避するため、DigiCert Global Root G2 認証局 (CA) を信頼してください</title>
    <link href="https://jpmessaging.github.io/blog/trust-digicert-global-root-g2-certificate-authority-to-avoid-exchange-online-ema/"/>
    <id>https://jpmessaging.github.io/blog/trust-digicert-global-root-g2-certificate-authority-to-avoid-exchange-online-ema/</id>
    <published>2026-02-01T15:00:00.000Z</published>
    <updated>2026-02-01T15:00:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>※ この記事は、<a href="https://techcommunity.microsoft.com/blog/exchange/trust-digicert-global-root-g2-certificate-authority-to-avoid-exchange-online-ema/4488311">Trust DigiCert Global Root G2 Certificate Authority to Avoid Exchange Online Email Disruption</a> の抄訳です。最新の情報はリンク先をご確認ください。この記事は Microsoft 365 Copilot および GitHub Copilot を使用して抄訳版の作成が行われています。</p><p style="background: #f5ff66ed;"><strong>2026 年 2 月 4 日更新:</strong> 一部のメール プロバイダーが 4 月 15 日以降、DigiCert G1 ルート証明書を信頼しなくなる可能性があるとの通知を受けております。これにより、メール エコシステム全体で広範な影響が生じる可能性があります。この状況に先立って、Exchange Online にて証明書の切り替えを実施できるようにするため、お客様は <strong>2026 年 3 月 15 日まで</strong> (以前は 4 月 30 日まで) に DigiCert Global Root G2 認証局を信頼していただく必要があります。</p><p>組織と Exchange Online 間のメール フローの中断を回避するために、Exchange Online との間で <strong>SMTP 経由で</strong>メールを送受信する組織は、<strong>2026 年 3 月 15 日までに</strong>、サーバーとクライアントが <strong>DigiCert Global Root G2 認証局 (Certificate Authority (以降、CA)) およびその下位 CA</strong> を信頼するようにする必要があります。</p><p>ルート CA と下位 CA のチェーンの包括的な一覧は、<a href="https://learn.microsoft.com/azure/security/fundamentals/azure-certificate-authority-details?tabs=certificate-authority-chains#root-and-subordinate-certificate-authority-chains">Azure 証明機関の詳細</a> のドキュメントおよび <a href="https://knowledge.digicert.com/general-information/digicert-trusted-root-authority-certificates#otherroots">DigiCert ナレッジベース</a> で確認できます。</p><p><strong>DigiCert Global Root G2 証明書</strong>を識別するには、以下の情報をご参照ください:</p><p><strong>SHA1 Thumbprint:</strong><br> DF3C24F9BFD666761B268073FE06D1CC8D4F82A4</p><p> <strong>Serial Number:</strong><br> 03:3A:F1:E6:A7:11:A9:A0:BB:28:64:B1:1D:09:FA:E5</p><h4 id="どのような場合に対応が必要か"><a href="#どのような場合に対応が必要か" class="headerlink" title="どのような場合に対応が必要か"></a>どのような場合に対応が必要か</h4><p style="background: #66FF99;"><strong>注:</strong> Windows オペレーティング システムは、既定で証明書の信頼を自動的に更新します。Windows 上でメール ワークロードを実行しているお客様 (例: オンプレミス Exchange Server) で、この Windows 機能を既定のまま有効にしている場合は、対応の必要はありません。</p><p>ただし、組織が SMTP 経由で Exchange Online とメールの送受信を行い、以下の 2 つの条件のいずれかに該当する場合は、「<strong>何をすべきか</strong>」に記載されているインストール手順を実行する必要がある場合があります。</p><p><strong>1.</strong> お客様組織で Windows CTL Updater 機能を無効にしている場合<br>この機能は、信頼されたルート証明書と信頼されていないルート証明書を含む<a href="https://learn.microsoft.com/windows-server/identity/ad-cs/certificate-trust">証明書信頼リスト (CTL)</a> を既定でダウンロードします。グループ ポリシーや <a href="https://learn.microsoft.com/windows-server/identity/ad-cs/configure-trusted-roots-disallowed-certificates">Microsoft 自動更新 URL のリダイレクト</a>を使用して、独自の信頼されたルート証明書および中間証明書のセットを管理している場合、この機能が無効になっている可能性があります。</p><p>信頼されたルート証明書および信頼されていないルート証明書の最終同期状態を確認するには、Windows コマンド プロンプトから以下のコマンドを実行します (注: これらのコマンドを実行すると、この機能が明示的に無効になっておらず、かつ Windows がローカルの AuthRoot CTL が古いか不完全であると判断した場合、Microsoft の信頼されたルート リストのオンデマンド同期が開始されます):</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br><span class="line">2</span><br></pre></td><td class="code"><pre><span class="line">certutil -verifyctl AuthRoot | findstr /i &quot;lastsynctime&quot;</span><br><span class="line">certutil -verifyctl Disallowed | findstr /i &quot;lastsynctime&quot;</span><br></pre></td></tr></table></figure><p>返された時刻が最近のものであれば、Windows CTL Updater 機能は正常に動作しています。ほとんどのお客様はこの機能を無効にしていません。</p><p><strong>2.</strong> Exchange Online との接続やメールの受信に、古いアプリケーション ランタイム環境 (レガシーな Java ランタイム (例: 古い JDK&#x2F;JRE バージョン)、組み込みシステムやアプライアンス、カスタムまたは古い Linux イメージ、エアギャップ環境など) を使用している場合</p><p>この変更は、Exchange Server、セキュリティ アプライアンス、およびサードパーティ製のメール ゲートウェイなど、<strong>Exchange Online に対して完全な証明書チェーン検証を実行するすべてのシステム</strong>に適用されます。サードパーティ製のメール アプライアンスを使用している場合は、ベンダーに直接お問い合わせください。</p><h4 id="なぜこの対応が重要か"><a href="#なぜこの対応が重要か" class="headerlink" title="なぜこの対応が重要か"></a>なぜこの対応が重要か</h4><p>ルート認証局 (CA) は、公開証明書の信頼の基盤を形成しています。オペレーティング システム、ブラウザー、およびアプリケーションは、信頼ストア内のルート証明書に依存しています。CA はこれらのルート証明書を使用して中間 CA 証明書を発行し、中間 CA が TLS やその他のデジタル証明書を発行します。</p><p>ルート CA 証明書が無効になったり信頼されなくなったりすると、その中間 CA によって発行されたすべての証明書も信頼を失います。つまり、ルート CA が明示的に信頼されていない場合、その中間 CA によって発行された証明書も有効ではなくなります。</p><p>Microsoft は、DigiCert Global Root G2 ルート CA から発行された複数の中間 CA を使用して、サービス (Exchange Online など) の TLS 証明書に署名しています。この信頼チェーンが機能するためには、DigiCert Global Root G2 ルート証明書がクライアントの信頼ストアに存在し、信頼されている必要があります。そうでない場合、TLS 接続は失敗します。</p><p>DigiCert Global Root G2 ルート証明書が<strong>インストールされていない</strong>場合、またはクライアントが <strong>TLS ハンドシェイク中にサーバーから中間 CA 証明書を取得できない、もしくは Authority Information Access (AIA) 拡張機能を介して取得できない</strong>場合、以下のような問題が発生する可能性があります:</p><ul><li>厳格な証明書検証が有効になっている場合、クライアントはメールの送信を拒否する可能性があります。または、許可されている場合は暗号化されていない SMTP にフォールバックする可能性があります。</li><li>クライアントは Exchange Online からの受信接続を拒否する可能性があり、メールの取得が失敗または遅延する可能性があります。</li></ul><p>メール クライアントがサーバーを信頼できない場合、セキュリティで保護された通信がブロックされます。</p><h4 id="何をすべきか"><a href="#何をすべきか" class="headerlink" title="何をすべきか"></a>何をすべきか</h4><h5 id="お使いのマシンに-DigiCert-Global-Root-G2-証明書がインストールされているか確認する"><a href="#お使いのマシンに-DigiCert-Global-Root-G2-証明書がインストールされているか確認する" class="headerlink" title="お使いのマシンに DigiCert Global Root G2 証明書がインストールされているか確認する"></a>お使いのマシンに DigiCert Global Root G2 証明書がインストールされているか確認する</h5><p>以下の PowerShell コマンドを使用して、DigiCert ルート証明書が信頼されているかどうかを確認できます:</p><figure class="highlight powershell"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line"><span class="built_in">Get-ChildItem</span> <span class="literal">-Path</span> Cert:\LocalMachine\Root\ | <span class="built_in">Where-Object</span> &#123; <span class="variable">$_</span>.Thumbprint <span class="operator">-eq</span> <span class="string">&quot;DF3C24F9BFD666761B268073FE06D1CC8D4F82A4&quot;</span> &#125;</span><br></pre></td></tr></table></figure><p>このコマンド実行で証明書が返される (Thumbprint と Subject が出力される) 場合、問題はありません。<em>追加の対応は必要ありません</em>:<br><img src="/blog/trust-digicert-global-root-g2-certificate-authority-to-avoid-exchange-online-ema/Cert01.jpg" alt="必要な証明書がローカルの Windows マシンで既に信頼されていることを示す結果"></p><p>その他に、中間 CA 証明書についても検証を推奨します。以下の PowerShell コマンドを使用して、中間 CA 証明書（DigiCert Global G2 TLS RSA SHA256 2020 CA1）が信頼されているかどうかを確認できます。</p><figure class="highlight powershell"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line"><span class="built_in">Get-ChildItem</span> <span class="literal">-Path</span> Cert:\LocalMachine\CA\ | <span class="built_in">Where-Object</span> &#123; <span class="variable">$_</span>.Thumbprint <span class="operator">-eq</span> <span class="string">&quot;1B511ABEAD59C6CE207077C0BF0E0043B1382612&quot;</span> &#125;</span><br></pre></td></tr></table></figure><p>このコマンド実行で結果が返されない、且つ、Windows CTL Updater 機能の再有効化をしたくない場合、以下のいずれかの対応（オプション 1 または 2）を実施する必要があります。:</p><h5 id="オプション-1-最新の-Microsoft-365-ルート証明書チェーン-バンドルを手動でダウンロードしてインポートする"><a href="#オプション-1-最新の-Microsoft-365-ルート証明書チェーン-バンドルを手動でダウンロードしてインポートする" class="headerlink" title="オプション 1 - 最新の Microsoft 365 ルート証明書チェーン バンドルを手動でダウンロードしてインポートする"></a><strong>オプション 1 - 最新の Microsoft 365 ルート証明書チェーン バンドルを手動でダウンロードしてインポートする</strong></h5><p>Microsoft は、Microsoft 365 サービスで必要となる証明書を発行する中間 CA の信頼を確保するために、信頼すべきルート証明書のセットを提供しています。</p><p>証明書バンドル (<strong>.p7b &#x2F; PKCS #7</strong> ファイル形式) は、以下からダウンロードできます:</p><ul><li><a href="https://www.microsoft.com/download/details.aspx?id=102267">Microsoft 365 Root Certificate Chain Bundle – Worldwide</a><ul><li>21Vianet が運営する Microsoft 365 をご利用のお客様は、Worldwide バンドルを使用してください</li></ul></li><li><a href="https://www.microsoft.com/download/details.aspx?id=100934">Microsoft 365 Certificate Bundle - DoD&#x2F;GCC High</a></li></ul><p>ダウンロード後、管理者権限でコマンド プロンプトを開き、以下のコマンドを実行します。パスとファイル名は、取得した実際の .p7b バンドルに合わせて更新してください:</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">certutil -addstore Root &quot;C:\path\to\m365_root_certs.p7b&quot;</span><br></pre></td></tr></table></figure><p>上記の「お使いのマシンに DigiCert Global Root G2 証明書がインストールされているか確認する」セクションで説明した PowerShell コマンドを実行して、インポートが正常に完了したことを確認してください。</p><h5 id="オプション-2-DigiCert-Global-Root-G2-およびその中間-CA-証明書を手動でダウンロードしてインポートする"><a href="#オプション-2-DigiCert-Global-Root-G2-およびその中間-CA-証明書を手動でダウンロードしてインポートする" class="headerlink" title="オプション 2 - DigiCert Global Root G2 およびその中間 CA 証明書を手動でダウンロードしてインポートする"></a><strong>オプション 2 - DigiCert Global Root G2 およびその中間 CA 証明書を手動でダウンロードしてインポートする</strong></h5><p>一部の利用者では、Windows CTL Updater 機能を使用せず、独自の管理ソリューション (例: グループ ポリシー) を用いて、信頼済みおよび信頼されていないルート証明書および中間証明書を管理しているケースがあります。<br>組織で証明書パッケージを管理しており、DigiCert Global Root G2 証明書とその下位認証局チェーンのみを追加する必要がある場合は、<a href="https://learn.microsoft.com/azure/security/fundamentals/azure-certificate-authority-details?tabs=certificate-authority-chains#root-and-subordinate-certificate-authority-chains#root-and-subordinate-certificate-authority-chains">Azure 証明機関の詳細</a> のドキュメントからダウンロードできます。</p><p>.crt ファイルからルート証明書をインポートするには、管理者権限のコマンド プロンプトで以下のコマンドを実行します:</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">certutil -addstore Root &quot;C:\path\to\DigiCertGlobalRootG2.crt&quot;</span><br></pre></td></tr></table></figure><p>.crt ファイルから中間証明書をインポートするには、管理者権限のコマンド プロンプトで以下のコマンドを実行します:</p><figure class="highlight plaintext"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line">certutil -addstore CA &quot;C:\path\to\DigiCertGlobalG2TLSRSASHA2562020CA1-1.crt&quot;</span><br></pre></td></tr></table></figure><p>前のセクションの PowerShell コマンドを使用して、ルート CA 証明書および中間 CA 証明書が正常にインポートされたことを確認してください。</p><h4 id="対応しないとどうなるか"><a href="#対応しないとどうなるか" class="headerlink" title="対応しないとどうなるか"></a>対応しないとどうなるか</h4><p>DigiCert Global Root G2 ルート証明書をインストールせず、システムが古いルート証明書に依存して検証を行っている場合、2026 年 3 月 15 日以降、メール フローが中断される可能性があります。発生する具体的な問題は、オペレーティング システムとアプリケーションの構成によって異なります。以下にいくつかの例を示します:</p><p>Exchange Online がオンプレミスの Exchange Server に接続できない場合、Exchange Online 管理センターでメッセージ追跡を実行すると、以下のような内容が表示されることがあります:</p><blockquote><p>Reason: [{LED&#x3D;450 4.4.317 Cannot establish session with remote server [Message&#x3D;451 5.7.3 STARTTLS is required to send mail]</p></blockquote><p><img src="/blog/trust-digicert-global-root-g2-certificate-authority-to-avoid-exchange-online-ema/Cert02.jpg" alt="受信側サーバーが証明書を信頼しない場合に Exchange Online のメッセージ追跡で表示される可能性があるエラー"><br>オンプレミス環境から Exchange Online に接続しようとする場合にも、同様の問題が発生する可能性があります。オンプレミスのプロトコル ログには、以下のようなエラーが記録されます:</p><blockquote><p>451 5.7.3 STARTTLS is required, 5.7.0 Must issue a STARTTLS command first</p></blockquote><p>OpenSSL を使用して接続する場合 (例: Linux オペレーティング システムを実行しているマシンや、OpenSSL を利用するアプリケーション)、ローカル発行者を取得できません:</p><blockquote><p>OpenSSL s_client -starttls smtp -connect &lt;tenant&gt;.mail.protection.outlook.com:25 -showcerts</p></blockquote><p><img src="/blog/trust-digicert-global-root-g2-certificate-authority-to-avoid-exchange-online-ema/Cert03.jpg" alt="Exchange Online に接続しようとしたときに証明書を信頼していない場合に (例えば) Linux システムで表示される可能性があるエラー"></p><h4 id="まとめ"><a href="#まとめ" class="headerlink" title="まとめ"></a>まとめ</h4><p>このブログ記事に記載されている手順を <strong>2026 年 3 月 15 日までに</strong> 完了することが非常に重要です。これらの更新を実施しない場合、組織と Exchange Online 間のメール フローに重大な中断が発生する可能性があります。</p><p>必要な証明書がインストールされ、最新の状態であることを確認することで、お客様のシステムと Microsoft 365 間の安全で中断のない通信を維持できます。期限後のメール配信に関する潜在的な問題を回避するために、これらの対応を優先的に実施してください。</p><p><strong>備考</strong> Exchange Online をご利用のお客様には、メッセージ センター (MC) にて MC1224565 として本件に関する投稿が公開されています。</p><p><em>更新履歴</em></p><ul><li><strong>2026&#x2F;3&#x2F;12:</strong> この変更は SMTP 経由でメールを送受信するシステムに適用されることを明記しました</li><li><strong>2026&#x2F;2&#x2F;23:</strong> 中間証明書のインポートと検証に関する詳細を追加しました</li><li><strong>2026&#x2F;2&#x2F;10:</strong> 中間証明書に関する注記を追加しました (非常に稀なケースです)</li><li><strong>2026&#x2F;2&#x2F;4:</strong> 業界全体での廃止の進行速度を受けて、期限を 3 月 15 日に変更しました</li></ul>]]></content>
    
    
      
      
    <summary type="html">&lt;p&gt;※ この記事は、&lt;a href=&quot;https://techcommunity.microsoft.com/blog/exchange/trust-digicert-global-root-g2-certificate-authority-to-avoid-exchange-</summary>
      
    
    
    
    
    <category term="Exchange Online" scheme="https://jpmessaging.github.io/blog/tags/Exchange-Online/"/>
    
  </entry>
  
  <entry>
    <title>Exchange Online のパブリック フォルダーのデータおよび保持に関する質問</title>
    <link href="https://jpmessaging.github.io/blog/exchange-online-public-folder-data-and-retention-questions/"/>
    <id>https://jpmessaging.github.io/blog/exchange-online-public-folder-data-and-retention-questions/</id>
    <published>2026-01-29T08:00:00.000Z</published>
    <updated>2026-01-29T08:00:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>※ この記事は、<a href="https://techcommunity.microsoft.com/blog/exchange/exchange-online-public-folder-data-and-retention-questions/4488872">Exchange Online Public Folder Data and Retention Questions</a> の抄訳です。最新の情報はリンク先をご確認ください。</p><p>Exchange Online においてパブリック フォルダーを管理する管理者は、さまざまな要因によるデータ損失が発生するケースに遭遇することがあります。例えば、ユーザーがパブリック フォルダーからメールを削除した後、保持期間の経過後にそのメールを復元する必要が生じる場合や、コンプライアンスや法的要件により、削除済みのデータが必要となる場合があります。このようなリスクを軽減する目的で、Exchange Online ではパブリック フォルダーを対象とした保持ポリシーが用意されています。これらのポリシーを使用すると、削除されたデータを指定した期間または無期限に<u>保持</u>したり、一定の期間が経過したコンテンツを自動的に<u>削除</u>したりすることができます。</p><p>以下のセクションでは、次の内容について説明します。</p><ul><li>パブリック フォルダーの保持ポリシーを構成する</li><li>パブリック フォルダーにおける保持の仕組み</li><li>削除済みデータを復元する方法</li><li>既知の問題とトラブルシューティング</li></ul><h4 id="パブリック-フォルダーの保持ポリシーを構成する"><a href="#パブリック-フォルダーの保持ポリシーを構成する" class="headerlink" title="パブリック フォルダーの保持ポリシーを構成する"></a>パブリック フォルダーの保持ポリシーを構成する</h4><p>削除されたデータがパブリック フォルダーの<a href="https://learn.microsoft.com/exchange/security-and-compliance/recoverable-items-folder/recoverable-items-folder">回復可能なアイテム フォルダー</a> (「ダンプスター」とも呼ばれます) に指定した期間保持されるようにするには、以下の手順に従ってテナントのパブリック フォルダーに対する<a href="https://learn.microsoft.com/purview/create-retention-policies?tabs=other-retention#create-and-configure-a-retention-policy">新しい保持ポリシーを作成</a>します。</p><ul><li><a href="https://purview.microsoft.com/">Microsoft Purview ポータル</a>にサインインし、<strong>ソリューション</strong> &gt; <strong>データ ライフサイクル管理</strong> &gt; <strong>ポリシー</strong> &gt; <strong>アイテム保持ポリシー</strong> の順に移動します。</li><li>処理を続行する前に、<a href="https://learn.microsoft.com/purview/retention-settings#configuration-information-for-exchange-mailboxes-and-exchange-public-folders"><strong>Exchange パブリック フォルダー メールボックス</strong></a>に少なくとも 10 MB のデータが含まれていることを確認してください。Get-MailboxStatistics コマンドを使用して、パブリック フォルダー メールボックス全体のデータ サイズを確認します。<br><img src="/blog/exchange-online-public-folder-data-and-retention-questions/pfh01.jpg"></li><li><strong>新しいアイテム保持ポリシー</strong> を選択して、<strong>アイテム保持ポリシーの作成</strong> の構成を開始し、新しいポリシーに名前を付けます。</li><li><strong>ポリシー スコープ</strong> ページで、管理単位を既定の <strong>完全なディレクトリ</strong> のままにします。現在、このポリシーでは管理単位はサポートされていません。</li><li><a href="https://learn.microsoft.com/purview/retention?tabs=table-overriden#:~:text=Exchange%20public%20folders%20locations%20don%27t%20support%20adaptive%20scopes"><strong>Exchange パブリック フォルダー</strong> はアダプティブ スコープをサポートしていないため、静的スコープを指定する必要があります</a>。<a href="https://learn.microsoft.com/purview/retention-settings#configuration-information-for-exchange-mailboxes-and-exchange-public-folders:~:text=The%20Exchange%20public%20folders%20location%20applies%20retention%20settings%20to%20all%20public%20folders%20and%20can%27t%20be%20applied%20at%20the%20folder%20or%20mailbox%20level.">場所の<strong>除外はサポートされていません</strong></a>。</li><li><strong>コンテンツを保持するか、削除するか、またはその両方を行うかを決定します</strong> ページで、コンテンツの保持と削除に関する設定を指定します。</li></ul><p>保持ポリシーは、コンテンツを保持するのみ、指定した期間保持した後に削除する、または指定した期間後に削除するように構成できます。保持ポリシーの期間は、以下に基づいて設定できます。</p><ul><li>アイテムの作成日時 (例: CreationTime)</li><li>アイテムの最終変更日時 (例: LastModificationTime)<br><img src="/blog/exchange-online-public-folder-data-and-retention-questions/pfh02.jpg"></li></ul><p>詳細については、「<a href="https://learn.microsoft.com/purview/retention-settings#settings-for-retaining-and-deleting-content">コンテンツを保持および削除するための設定</a>」を参照してください。</p><ul><li>構成を完了し、設定を保存します。</li></ul><p>通常、ポリシーの更新がすぐに適用されますが、反映されるまでに<a href="https://learn.microsoft.com/purview/retention-settings?view=o365-worldwide#updating-policies-for-retention">数日</a>かかる場合もあります。レプリケーションが完了すると、Microsoft Purview ポータルまたはコンプライアンス ポータルにて保持ポリシーの状態が「有効 (保留中)」から「有効 (成功)」に変わります。状態が保留のままの場合は、Microsoft サポートにお問い合わせください。<br><img src="/blog/exchange-online-public-folder-data-and-retention-questions/pfh03.jpg"><br><u>注意</u>: <a href="https://learn.microsoft.com/purview/retention?view=o365-worldwide&amp;tabs=table-overriden#preservation"><em>Exchange パブリック フォルダーのメッセージは保持ラベルをサポートしていません</em></a></p><h4 id="パブリック-フォルダーにおける保持の仕組み"><a href="#パブリック-フォルダーにおける保持の仕組み" class="headerlink" title="パブリック フォルダーにおける保持の仕組み"></a>パブリック フォルダーにおける保持の仕組み</h4><p>パブリック フォルダーが保持ポリシーによって保持されている場合、以下のようになります。</p><ul><li>ルートまたはプライマリ パブリック フォルダー メールボックスの InPlaceholds パラメーターにポリシー ID が含まれます。詳細については、こちらの<a href="https://learn.microsoft.com/purview/ediscovery-identify-a-hold-on-an-exchange-online-mailbox">記事</a>を参照してください。<br><img src="/blog/exchange-online-public-folder-data-and-retention-questions/pfh04.jpg"> </li><li><strong>DiscoveryHolds</strong> フォルダーは、各コンテンツ パブリック フォルダー メールボックスの Non_IPM_Subtree 配下に作成されます。その機能は以下のとおりです。<ul><li>同じコンテンツ メールボックス上の DiscoveryHolds フォルダー内に削除されたアイテムを保持します。</li><li>毎日、PublicFolderDiscoveryHoldsProcessor が実行され、各コンテンツ パブリック フォルダー メールボックスの DiscoveryHolds フォルダーとサブフォルダーを処理します。この処理により、インプレース保持期間を満たしていないアイテムやフォルダーは期限切れとして処理されます。</li></ul></li></ul><p>このようなシナリオを考えてみましょう: 保持ホールドが設定されているテナントのパブリック フォルダー (例: “\pf4”) において、”2ndMBX” というコンテンツ メールボックスに、件名が “Test Mail” のメールが含まれているとします。削除を行う前に Get-PublicFolderItemStatistics コマンドを使用することで、当該メールが存在していることを確認できます。</p><p>件名が “Test Mail” のメールが削除されると、当該メールはフォルダーのダンプスター (回復可能なアイテム フォルダー)(例: “\pf4” のダンプスター) に移動され、1 日間保持された後、完全に削除されます。</p><p>保持期間が満了すると、当該アイテムは、所有元フォルダー (例: “\pf4”) のコンテンツ メールボックス内にある DiscoveryHolds フォルダーに移動されます。<br><img src="/blog/exchange-online-public-folder-data-and-retention-questions/pfh05.jpg"> </p><p>保持期間経過後、当該アイテムは、所有元フォルダー (例: “\pf4”) のコンテンツ メールボックス内にある DiscoveryHolds フォルダーに移動されます。<br><img src="/blog/exchange-online-public-folder-data-and-retention-questions/pfh06.jpg">   </p><p>次に、別のシナリオについて考えてみましょう: データが含まれているパブリック フォルダーを削除する場合の例です。例えば、子パブリック フォルダー “\pf5\pf6” に件名が “Test Mail” のメールが含まれているとします。削除を行う前に Get-PublicFolderItemStatistics コマンドを使用することで、当該メールが存在していることを確認できます。</p><p>フォルダー “\pf5\pf6” が削除されると、フォルダーとそのコンテンツは親フォルダーのダンプスター (回復可能なアイテム フォルダー)(例: “\pf5” のダンプスター) に移動されます。</p><p>親フォルダーの保持削除期間が満了すると、フォルダー “\pf6” は、その中に含まれている件名 “Test Mail” のメールとともに、親フォルダー (例: “\pf5”) に対応するコンテンツ メールボックス内の DiscoveryHolds フォルダーに、新しい名前 (FolderName_GUID) で移動されます。</p><p>完全に削除されたフォルダーおよびアイテムは、適用された保持ポリシーで指定された期間に基づいて保持されます。</p><p>管理者として、各コンテンツ メールボックスの TotalDeletedItemSize および TotalItemSize パラメーターを監視し、配置されているパブリック フォルダーにおいて、削除、保持、ならびに作成に関する問題が発生しないようにする必要があります。次のような場合に、問題が発生する可能性があります。</p><p>親フォルダーの保持削除期間が経過した後、フォルダー “\pf6” が、件名 “Test Mail” のメールを含んだ状態で、親フォルダー (例: “\pf5”) のコンテンツ メールボックス内の DiscoveryHolds フォルダー配下へに、新しい名前 (FolderName_GUID) で移動されたことを確認できます。<br><img src="/blog/exchange-online-public-folder-data-and-retention-questions/pfh07.jpg"> </p><p>完全に削除されたフォルダーおよびアイテムは、適用された保持ポリシーで定められた期間に基づいて保持されるものとします。</p><p>管理者として、各コンテンツ メールボックスの TotalDeletedItemSize および TotalItemSize パラメーターを監視し、そのコンテンツ メールボックス上に配置されているパブリック フォルダーにおいて、削除、保持、ならびに作成に関する問題が発生しないようにする必要があります。次のような場合に、問題が発生する可能性があります。</p><ul><li>TotalDeletedItemSize が RecoverableItemsQuota を超過した場合</li><li>TotalItemSize と TotalDeletedItemSize の合計が ProhibitSendReceiveQuota を超過した場合</li></ul><p>これらの値の確認方法と、正常なクォータの維持に関するガイダンスにつきましては、こちらの<a href="https://techcommunity.microsoft.com/blog/exchange/troubleshooting-public-folder-deletion-issues-in-exchange-online/3819379">記事</a>を参照してください。</p><p>注意: クォータの問題が検出された場合は、以下のスクリプトを使用して対処できます: <a href="https://github.com/hazemembaby/Scripts/blob/main/Public%20Folders/CheckEXOMePf/CheckEXOMePf.md">Scripts&#x2F;Public Folders&#x2F;CheckEXOMePf&#x2F;CheckEXOMePf.md at main · hazemembaby&#x2F;Scripts · GitHub</a></p><h4 id="保持ポリシーの対象となっている削除済みパブリック-フォルダー-アイテムを復元する方法"><a href="#保持ポリシーの対象となっている削除済みパブリック-フォルダー-アイテムを復元する方法" class="headerlink" title="保持ポリシーの対象となっている削除済みパブリック フォルダー アイテムを復元する方法"></a>保持ポリシーの対象となっている削除済みパブリック フォルダー アイテムを復元する方法</h4><p>次に、保持ホールドが適用されている完全に削除されたアイテムを復元する方法について説明します。<br><a href="https://learn.microsoft.com/purview/ediscovery-content-search">コンテンツの検索</a>は、完全に削除されたアイテムを検索および復元するための重要なツールです。以下の例で詳しく説明します。</p><p>例えば、パブリック フォルダー内で件名が “Test Mail” の完全に削除されたメール アイテムを検索する場合:</p><p>管理者は、<a href="https://learn.microsoft.com/purview/ediscovery-content-search#create-and-run-a-search">新しいコンテンツ検索</a>から名前を “Look for mails on PF” とした検索を作成し、検索場所に「Exchange パブリック フォルダー」を指定したうえで、件名が “Test Mail” であることを条件として、これらのアイテムを検索できます。</p><p>以下のスクリーンショットは、Purview コンテンツの検索結果と results.csv ファイルを示しています。コンテンツ パブリック フォルダー メールボックス 2ndmbx および 3rdmbx の DiscoveryHolds フォルダー配下に 2 つのアイテムが検出されたことを確認できます。</p><p>Original Path または Location Name フィールドを使用することで、これらのアイテムの場所を確認することができます。<br><img src="/blog/exchange-online-public-folder-data-and-retention-questions/pfh08.jpg"><br>結果をダウンロードすると、以下のような内容が表示されます。</p><pre><code>Original Path: 2ndMBX_fcb8821f@(domain).onmicrosoft.com, Primary, 68fc5185-4bd5-4777-9d3d-f85fd216def5\2ndMBX_fcb8821f@(domain).onmicrosoft.com (Primary)\NON_IPM_SUBTREE\DiscoveryHoldsLocation Name: 2ndMBX_fcb8821f@(domain).onmicrosoft.com</code></pre><p>これらのアイテムを復元するには:</p><ul><li>Purview コンテンツの検索を使用して、検出されたアイテムを PST ファイルに<a href="https://learn.microsoft.com/purview/ediscovery-export-search-results">エクスポート</a>します。</li><li>対象のパブリック フォルダーに対する必要なアクセス許可を持つ状態で、Outlook で <a href="https://support.microsoft.com/office/open-and-close-outlook-data-files-pst-381b776d-7511-45a0-953a-0935c79d24f2#id0ebbf=classic_outlook">PST ファイルを追加または開きます</a>。</li><li>Outlook を使用して、必要なパブリック フォルダーにアイテムを<a href="https://support.microsoft.com/office/move-or-copy-an-item-to-another-folder-in-outlook-19768dfe-86c4-40bf-b82c-1c084b624492#picktab=classic_outlook">コピー</a>します。</li></ul><p>また、完全に削除されたフォルダーは PowerShell を使用して復元することもできます。パブリック フォルダーを<a href="https://learn.microsoft.com/exchange/collaboration-exo/public-folders/restore-deleted-public-folder">復元</a>すると、その配下に含まれるすべてのサブフォルダーとアイテムも復元されます。</p><h4 id="既知の問題とトラブルシューティング"><a href="#既知の問題とトラブルシューティング" class="headerlink" title="既知の問題とトラブルシューティング"></a>既知の問題とトラブルシューティング</h4><p>最後に、以下のセクションでは既知の問題とトラブルシューティングのポイントについて説明します。</p><ul><li>まれに、DiscoveryHolds フォルダーがプライマリ パブリック フォルダー メールボックスから現在のメールボックスへ同期されない場合があります。この問題を解消するには、以下のコマンドを使用して手動で同期を実行してください。</li></ul><figure class="highlight powershell"><table><tr><td class="gutter"><pre><span class="line">1</span><br></pre></td><td class="code"><pre><span class="line"><span class="built_in">Update-publicFolderMailbox</span> <span class="string">&quot;affected mailbox&quot;</span> <span class="literal">-InvokeSynchronizer</span> <span class="literal">-ForceOnlineSync</span> <span class="literal">-FullSync</span></span><br></pre></td></tr></table></figure><p>DiscoveryHolds フォルダーがメールボックス (例: 2ndmbx) に同期されていない場合、ダンプスター (回復可能なアイテム フォルダー) 内のアイテムは処理されません。メールボックスで強制同期を実行すると、DiscoveryHolds フォルダーが同期され、ダンプスター (回復可能なアイテム フォルダー) 内のアイテムが正常に処理されるようになります。<br><img src="/blog/exchange-online-public-folder-data-and-retention-questions/pfh09.jpg"><br><small style="color: gray;">2ndmbx に対して強制同期を実行すると、DiscoveryHolds フォルダーが同期され、ダンプスター (回復可能なアイテム フォルダー) 内のアイテムが正常に処理されるようになります。</small></p><ul><li>Outlook on the Web (OWA) において、以前ユーザーのお気に入りに追加されていた完全に削除されたフォルダは、保持期間が満了するまで、新しい保持名 (“Name_GUID”) のままで表示されることがあります。この場合の回避策として、Outlook on the Web のお気に入りから<a href="https://learn.microsoft.com/exchange/collaboration-exo/public-folders/use-favorite-public-folders">これらのフォルダーをお気に入りから削除する</a>よう、ユーザーへ案内してください。</li></ul><p><img src="/blog/exchange-online-public-folder-data-and-retention-questions/pfh10.jpg"> </p><p>今回の記事がお役に立てれば幸いです。<br>本記事のレビューおよび内容へのご協力をいただいた Bhalchandra Atre に、心より感謝します。</p>]]></content>
    
    
      
      
    <summary type="html">&lt;p&gt;※ この記事は、&lt;a href=&quot;https://techcommunity.microsoft.com/blog/exchange/exchange-online-public-folder-data-and-retention-questions/4488872&quot;&gt;Ex</summary>
      
    
    
    
    
    <category term="Exchange Online" scheme="https://jpmessaging.github.io/blog/tags/Exchange-Online/"/>
    
  </entry>
  
  <entry>
    <title>新しい Outlook for Windows のメール テンプレート機能の紹介</title>
    <link href="https://jpmessaging.github.io/blog/Introduction-to-the-Email-Template-Features-in-New-Outlook-for-Windows/"/>
    <id>https://jpmessaging.github.io/blog/Introduction-to-the-Email-Template-Features-in-New-Outlook-for-Windows/</id>
    <published>2026-01-28T15:00:00.000Z</published>
    <updated>2026-01-28T15:00:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>こんにちは。日本マイクロソフト Exchange &amp; Outlook サポート チームの杉山です。<br>本記事では、新しい Outlook for Windows (以下、新しい Outlook) に 2025 年 11 月に<a href="https://support.microsoft.com/office/c4c33813-1e9a-4304-8499-90fe7f164bd1">新機能</a>として追加されたメール テンプレート機能をご紹介します。<br>メール テンプレートを活用することにより、共通の情報が含まれるメッセージを簡単に作成できますので是非活用ください！  </p><h2 id="メール-テンプレートの作成方法"><a href="#メール-テンプレートの作成方法" class="headerlink" title="メール テンプレートの作成方法"></a>メール テンプレートの作成方法</h2><p>新しい Outlook では以下の手順でメール テンプレートを作成できます。  </p><ol><li>新しいメール メッセージを作成し、共通情報が含まれるメールを作成します。  </li><li>メールを作成後、[ファイル] - [テンプレート] より [メールをテンプレートとして保存] をクリックします。<br>※ [メッセージ] -タブより [メール テンプレート] - [メールをテンプレートとして保存] からも実行できます。  </li><li>[メールをテンプレートとして保存] ダイアログより、メール テンプレートに名前を付け、[保存] をクリックします。</li></ol><p><img src="/blog/Introduction-to-the-Email-Template-Features-in-New-Outlook-for-Windows/Saveemailastemplate.png"></p><h2 id="メール-テンプレートからメールを作成する方法"><a href="#メール-テンプレートからメールを作成する方法" class="headerlink" title="メール テンプレートからメールを作成する方法"></a>メール テンプレートからメールを作成する方法</h2><p>保存したメール テンプレートは新規メール作成時に使用できます。  </p><ol><li>[新規] - [テンプレートからのメール] をクリックします。  </li><li>使用するテンプレートを選択します。</li></ol><p><img src="/blog/Introduction-to-the-Email-Template-Features-in-New-Outlook-for-Windows/Mailfromtemplate.png"><br><img src="/blog/Introduction-to-the-Email-Template-Features-in-New-Outlook-for-Windows/Template.png"></p><h2 id="テンプレートの設定"><a href="#テンプレートの設定" class="headerlink" title="テンプレートの設定"></a>テンプレートの設定</h2><p>保存されたテンプレートは [設定] - [メール] - [テンプレート] より確認できます。<br>※ 新しい Outlook で保存したテンプレートは Outlook on the web でも使用できます。  </p><p><img src="/blog/Introduction-to-the-Email-Template-Features-in-New-Outlook-for-Windows/Settings.png"></p><p>右上の [テンプレートを追加] より OFT ファイルをインポートすることもできます。<br>これにより、従来の Outlook for Windows (以下、従来の Outlook) で利用していたテンプレートの内容をもとに新しい Outlook のテンプレートを追加できます。  </p><p><img src="/blog/Introduction-to-the-Email-Template-Features-in-New-Outlook-for-Windows/Addtemplate.png"></p><div style="margin:1.25em;border-left:4px solid #1a7f37;padding:.5em"><div style="margin:0 0 16px 0;display:flex;align-items:center;line-height:1;color:#1a7f37"><svg viewBox="0 0 16 16" version="1.1" width="16" height="16" aria-hidden="true" style="margin-right:8px"><path fill="#1a7f37" d="M8 1.5c-2.363 0-4 1.69-4 3.75 0 .984.424 1.625.984 2.304l.214.253c.223.264.47.556.673.848.284.411.537.896.621 1.49a.75.75 0 0 1-1.484.211c-.04-.282-.163-.547-.37-.847a8.456 8.456 0 0 0-.542-.68c-.084-.1-.173-.205-.268-.32C3.201 7.75 2.5 6.766 2.5 5.25 2.5 2.31 4.863 0 8 0s5.5 2.31 5.5 5.25c0 1.516-.701 2.5-1.328 3.259-.095.115-.184.22-.268.319-.207.245-.383.453-.541.681-.208.3-.33.565-.37.847a.751.751 0 0 1-1.485-.212c.084-.593.337-1.078.621-1.489.203-.292.45-.584.673-.848.075-.088.147-.173.213-.253.561-.679.985-1.32.985-2.304 0-2.06-1.637-3.75-4-3.75ZM5.75 12h4.5a.75.75 0 0 1 0 1.5h-4.5a.75.75 0 0 1 0-1.5ZM6 15.25a.75.75 0 0 1 .75-.75h2.5a.75.75 0 0 1 0 1.5h-2.5a.75.75 0 0 1-.75-.75Z"></path></svg>Tips</div>画面内に記載の通り従来の Outlook で使用していたテンプレートは <span style="background: linear-gradient(transparent 80%, #ffcc99 80%)">%APPDATA%\Microsoft\Templates</span> に保存されていますので、エクスプローラーなどで OFT ファイルを確認できます。</div><p>メール メッセージのテンプレートの作成については<a href="https://support.microsoft.com/office/43ec7142-4dd0-4351-8727-bd0977b6b2d1#officeversion=new_outlook">こちら</a>の公開情報もご一読ください。  </p><p><strong>本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。</strong></p>]]></content>
    
    
      
      
    <summary type="html">&lt;p&gt;こんにちは。日本マイクロソフト Exchange &amp;amp; Outlook サポート チームの杉山です。&lt;br&gt;本記事では、新しい Outlook for Windows (以下、新しい Outlook) に 2025 年 11 月に&lt;a href=&quot;https://su</summary>
      
    
    
    
    
    <category term="New Outlook" scheme="https://jpmessaging.github.io/blog/tags/New-Outlook/"/>
    
  </entry>
  
  <entry>
    <title>Exchange Online における SMTP AUTH 基本認証廃止スケジュールの更新のご案内
</title>
    <link href="https://jpmessaging.github.io/blog/Updated-Exchange-Online-SMTP-AUTH-Basic-Authentication-Deprecation-Timeline/"/>
    <id>https://jpmessaging.github.io/blog/Updated-Exchange-Online-SMTP-AUTH-Basic-Authentication-Deprecation-Timeline/</id>
    <published>2026-01-28T03:00:00.000Z</published>
    <updated>2026-01-28T03:00:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>※ この記事は、<a href="https://techcommunity.microsoft.com/blog/exchange/updated-exchange-online-smtp-auth-basic-authentication-deprecation-timeline/4489835">Updated Exchange Online SMTP AUTH Basic Authentication Deprecation Timeline</a> の抄訳です。最新の情報はリンク先をご確認ください。この記事は Microsoft 365 Copilot および GitHub Copilot を使用して抄訳版の作成が行われています。</p><p>多くの方が従来の電子メール ワークフローの最新化において、現実的な課題に直面され続け、実行可能で安全な代替手段を導入するために十分な時間が必要とすることを認識しています。</p><p>皆様からのフィードバック、及び、実際の利用状況を踏まえ、より明確なマイルストーンと追加の移行猶予期間を提供するため、<a href="https://techcommunity.microsoft.com/blog/exchange/exchange-online-to-retire-basic-auth-for-client-submission-smtp-auth/4114750">Exchange Online SMTP AUTH Basic Authentication Deprecation</a> のスケジュールを以下のように見直しました。</p><ul><li><strong>2026 年 12 月まで:</strong> SMTP AUTH 基本認証の動作に変更はありません。</li><li><strong>2026 年 12 月末:</strong> SMTP AUTH 基本認証は<strong>既存テナントでは既定で無効化されます。</strong> 管理者は必要に応じて有効化できます。</li><li><strong>2026 年 12 月以降に作成される新規テナントの場合:</strong> SMTP AUTH 基本認証は<strong>既定で使用できません。</strong> サポートされる認証方式は OAuth のみとなります。</li><li><strong>2027 年後半:</strong> SMTP AUTH 基本認証の<strong>最終的な削除日</strong>を発表されます。</li></ul><p>これらの更新は、すべてのクラウド環境を含む当サービスをご利用のお客様に対し、最新の認証方式への移行を計画、検証、展開するための十分な時間を確保しつつ、既定のセキュリティ水準を維持できることを目的としています。</p>]]></content>
    
    
      
      
    <summary type="html">&lt;p&gt;※ この記事は、&lt;a href=&quot;https://techcommunity.microsoft.com/blog/exchange/updated-exchange-online-smtp-auth-basic-authentication-deprecation-tim</summary>
      
    
    
    
    
    <category term="Exchange Online" scheme="https://jpmessaging.github.io/blog/tags/Exchange-Online/"/>
    
  </entry>
  
  <entry>
    <title>新しい Outlook for Windows のオフライン アクセス機能の紹介</title>
    <link href="https://jpmessaging.github.io/blog/Offline-Cache-in-New-Outlook/"/>
    <id>https://jpmessaging.github.io/blog/Offline-Cache-in-New-Outlook/</id>
    <published>2026-01-28T02:00:00.000Z</published>
    <updated>2026-01-28T02:00:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>こんにちは。日本マイクロソフト Exchange &amp; Outlook サポート チームの御正 (ミショウ) です。<br>本記事では新しい Outlook for Windows (2024 年の 8 月から一般公開されました Outlook を示します。以後、新しい Outlook と記します。) のオフライン アクセス機能について解説します。</p><h2 id="そもそもオフライン-アクセスとは"><a href="#そもそもオフライン-アクセスとは" class="headerlink" title="そもそもオフライン アクセスとは"></a>そもそもオフライン アクセスとは</h2><p>オフライン アクセスを利用すると新しい Outlook でネットワーク接続がない環境でもメールを読んだり、下書きメールを作成したりすることができます。<br>オフライン アクセス有効時にネットワーク接続がなくても行える操作は以下の通りです。</p><table><thead><tr><th>Outlook アイテムの読み取り、管理、および表示</th><th>メールに対するアクションの実行</th><th>設定の表示と更新</th></tr></thead><tbody><tr><td>メールの読み取り</td><td>アーカイブ</td><td>Outlook について</td></tr><tr><td>添付ファイルとインライン画像を表示する</td><td>分類</td><td>自動応答</td></tr><tr><td>メールの下書きの作成と保存</td><td>フォルダーへのコピー</td><td>分類</td></tr><tr><td>新しいメッセージを送信トレイに格納する</td><td>削除</td><td>電子メール アカウント</td></tr><tr><td>メールの返信と転送</td><td>フラグ&#x2F;フラグ解除</td><td>連絡先ビュー</td></tr><tr><td>メールの検索</td><td>無視</td><td></td></tr><tr><td>フォルダーの作成、名前の変更、移動、削除</td><td>既読&#x2F;未読としてマーク</td><td></td></tr><tr><td>検索フォルダーの表示</td><td>優先&#x2F;その他への移動</td><td></td></tr><tr><td>アカウントとして追加された共有メールボックスを表示する</td><td>フォルダーに移動する</td><td></td></tr><tr><td>予定表とイベントの表示</td><td>固定 (ピン)</td><td></td></tr><tr><td>連絡先の表示</td><td>迷惑メール &#x2F; 非迷惑メールの報告</td><td></td></tr><tr><td></td><td>フィッシング詐欺の報告</td><td></td></tr><tr><td></td><td>会議出席依頼への RSVP</td><td></td></tr><tr><td></td><td>スヌーズ</td><td></td></tr></tbody></table><p>Title: Outlook でオフライン作業する<br>URL: <a href="https://support.microsoft.com/office/2460e4a8-16c7-47fc-b204-b1549275aac9">https://support.microsoft.com/office/2460e4a8-16c7-47fc-b204-b1549275aac9</a></p><p>新しい Outlook のオフライン アクセス機能ではローカル端末にキャッシュを保存する際に、一般的なブラウザーで利用される Web 標準技術である IndexedDB というデータベースを使用しています。<br>既定で以下のパスにキャッシュが保存されます。</p><pre><code>  %localappdata%\Microsoft\Olk\EBWebView\Default\IndexedDB</code></pre><p><strong>IndexedDB は先にも記載したとおり一般的なブラウザーで利用される Web 標準の技術であり、マイクロソフトでサポートを提供している製品ではありません。サポートでは IndexedDB 自体についてのご質問を受け付けることはできかねますので、予めご了承いただければ幸いです。</strong></p><p>従来の Outlook for Windows (Microsoft 365 Apps や永続的なライセンスの Office に付随する Outlook を示します。以後、従来の Outlook と記します。) でオンライン モードとキャッシュ モードを切り替えられるように、オフライン アクセス機能は新しい Outlook にて以下の手順から有効&#x2F;無効にすることができます。</p><p>手順<br>[設定] - [全般] - [オフライン] の [オフライン時のメール、予定表、連絡先を有効にします] のトグルを切り変えます。</p><p>ちなみに、同様の機能として従来の Outlook でもキャッシュ モードを利用していると、Outlook Data File (.ost) というファイルでローカル端末にメールなどのデータが保持されオフライン環境でも利用することができます。<br>既定ではこの OST ファイルは以下のパスに保存されます。</p><pre><code>  %localappdata%\Microsoft\Outlook</code></pre><p>なお、従来の Outlook の OST ファイルから新しい Outlook の IndexedDB にデータは引き継がれませんので、新しい Outlook でオフライン アクセス機能を利用する場合は新規にメールをダウンロードします。</p><h2 id="よくある質問"><a href="#よくある質問" class="headerlink" title="よくある質問"></a>よくある質問</h2><p>お問い合わせ窓口によくいただく質問をまとめました。</p><p>Q1. オフライン アクセスの利用に必要なデバイス上の空き容量はどれくらいになるの？<br>A1. 残念ながら、一概に必要な空き容量について公開している情報はありません。また、メールのサイズから IndexedDB で使用するファイルがどれくらいのサイズになるか換算する方法もありません。メールの受信数や、それぞれのメールのサイズは利用者によって異なるので、実績ベースでどの程度のサイズが利用されているか確認しましょう。</p><p>Q2. オフライン アクセス機能を管理者から一元管理することはできるの？<br>A2. Exchange Online にアクセスした PowerShell から Set-OwaMailboxPolicy というコマンドを利用して、オフライン アクセス機能を無効化することができます。具体的には、OfflineEnabledWin というパラメーターを False に設定します。OfflineEnabledWin が既定値の True の場合、ユーザーは新しい Outlook の設定画面からオフライン アクセスの設定を自分で有効または無効にできます。False に変更すると、オフライン アクセス機能は無効になり、新しい Outlook の [設定] - [全般] より [オフライン] が非表示になるため、ユーザーは自分自身で有効にできなくなります。</p><blockquote><p>Set-OwaMailboxPolicy &lt;ポリシー名&gt; -OfflineEnabledWin $false</p></blockquote><p>メールボックスにポリシーを割り当てるには以下コマンドを使用します。</p><blockquote><p>Set-CASMailbox &lt;ユーザー名&gt; -OwaMailboxPolicy &lt;ポリシー名&gt;</p></blockquote><p>メールボックスに OwaMailboxPolicy を割り当てる手順は以下の公開情報でも詳しく紹介されているので、確認してみてください。</p><p>Title: Exchange Onlineのメールボックスに対してメールボックス ポリシーを適用または削除する | Microsoft Learn<br>URL: <a href="https://learn.microsoft.com/exchange/clients-and-mobile-in-exchange-online/outlook-on-the-web/apply-or-remove-outlook-web-app-mailbox-policy">https://learn.microsoft.com/exchange/clients-and-mobile-in-exchange-online/outlook-on-the-web/apply-or-remove-outlook-web-app-mailbox-policy</a></p><p>Q3. キャッシュを削除したい場合はどうすればいい？<br>A3. 先に記載した新しい Outlook 内の設定でオフライン アクセス機能を手動で無効化する方法か、PowerShell コマンドでオフライン アクセス機能を無効化します。なお、オフライン アクセス機能を無効にすると IndexedDB フォルダー配下のキャッシュの量は小さくなりますが、IndexedDB フォルダーは完全に削除されません。これは IndexedDB のフォルダーにはキャッシュ以外にも新しい Outlook の設定など様々な情報が保存されるためです。IndexedDB フォルダーを手動で削除しても、次回起動時に自動で作成されます。</p><p>Q4. キャッシュの量を削減する方法はある？<br>A4. キャッシュの量を減らしたい場合は、[メールの保存日数] を短く設定してください。さらに、[添付ファイルを含める] をオフにすることで、キャッシュの量をある程度抑えることができます。</p><p>&lt;手順&gt;<br>新しい Outlook で [設定] を開き、[全般] – [オフライン] にある [メールの保存日数] を短くして [保存] を選択します。</p><p>なお、設定した直後にキャッシュの量が減るわけではなく、データ ベースの処理が実行されることで徐々にキャッシュの量が減っていきます。</p><p>Q5. PC の空き容量が少ない場合、オフライン アクセスの設定はどうなる？<br>A5. PC の空き容量が足りない場合は自動的に保存日数が少なくなったり、オフライン アクセス機能が無効化されたりする可能性があります。</p><div style="margin:1.25em;border-left:.25em solid #8957e5;padding:.5em;"><div style="margin-bottom:16px;display:flex;align-items:center;line-height:1;color:#8957e5"><svg viewBox="0 0 16 16" width="16" height="16" aria-hidden="true" style="margin-right:8px"><path fill=#8957e5 d="M0 1.75C0 .784.784 0 1.75 0h12.5C15.216 0 16 .784 16 1.75v9.5A1.75 1.75 0 0 1 14.25 13H8.06l-2.573 2.573A1.458 1.458 0 0 1 3 14.543V13H1.75A1.75 1.75 0 0 1 0 11.25Zm1.75-.25a.25.25 0 0 0-.25.25v9.5c0 .138.112.25.25.25h2a.75.75 0 0 1 .75.75v2.19l2.72-2.72a.749.749 0 0 1 .53-.22h6.5a.25.25 0 0 0 .25-.25v-9.5a.25.25 0 0 0-.25-.25Zm7 2.25v2.5a.75.75 0 0 1-1.5 0v-2.5a.75.75 0 0 1 1.5 0ZM9 9a1 1 0 1 1-2 0 1 1 0 0 1 2 0Z"></path></svg>重要</div><div>デバイスで使用できる領域のために、設定に基づいて保存するのに十分なローカル ストレージが得られない場合、保存するアイテムの数が削減されるか、オフライン アクセスが無効になる可能性があります。</div></div> <p>Title: Outlook でオフライン作業する<br>URL: <a href="https://support.microsoft.com/office/outlook-2460e4a8-16c7-47fc-b204-b1549275aac9">https://support.microsoft.com/office/outlook-2460e4a8-16c7-47fc-b204-b1549275aac9</a></p><p><strong>本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。</strong></p>]]></content>
    
    
      
      
    <summary type="html">&lt;p&gt;こんにちは。日本マイクロソフト Exchange &amp;amp; Outlook サポート チームの御正 (ミショウ) です。&lt;br&gt;本記事では新しい Outlook for Windows (2024 年の 8 月から一般公開されました Outlook を示します。以後、新し</summary>
      
    
    
    
    
    <category term="New Outlook" scheme="https://jpmessaging.github.io/blog/tags/New-Outlook/"/>
    
  </entry>
  
  <entry>
    <title>新しい Outlook for Windows におけるキーボード ショートカットの設定と活用ガイド</title>
    <link href="https://jpmessaging.github.io/blog/Configuration-and-Usage-Guide-for-Keyboard-Shortcuts-in-New-Outlook-for-Windows/"/>
    <id>https://jpmessaging.github.io/blog/Configuration-and-Usage-Guide-for-Keyboard-Shortcuts-in-New-Outlook-for-Windows/</id>
    <published>2026-01-28T01:00:00.000Z</published>
    <updated>2026-01-28T01:00:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>こんにちは。日本マイクロソフト Exchange &amp; Outlook サポート チームの杉山です。<br>本記事では、新しい Outlook for Windows (以下、新しい Outlook) をより効率的に使いこなすためのキーボード ショートカットに関する Tips をご紹介します。<br>キーボード ショートカットの設定と便利なショートカット キーを活用してみてください！  </p><h2 id="新しい-Outlook-のキーボード-ショートカットの設定方法"><a href="#新しい-Outlook-のキーボード-ショートカットの設定方法" class="headerlink" title="新しい Outlook のキーボード ショートカットの設定方法"></a>新しい Outlook のキーボード ショートカットの設定方法</h2><p>従来の Outlook for Windows (以下、従来の Outlook) と Outlook on the web では利用可能なショートカット キーは異なっていたため、2 つのクライアントを使用する場合には、誤ったショートカット キーを入力してしまうことがありました。<br>一方、新しい Outlook では従来の Outlook と Outlook on the web のどちらのショートカット キーを使用するかを選ぶことができるようになっています。<br>この設定により、以前に使用していたクライアントに合わせたショートカット キーを新しい Outlook でも使用することができます。  </p><p>新しい Outlook では [設定] - [全般] - [アクセシビリティ] の [キーボード ショートカット] より、以下の項目を選択できます。  </p><ul><li>Outlook for Windows (従来の Outlook を指します)  </li><li>Outlook for Web (Outlook on the web を指します)   </li><li>キーボード ショートカットを無効にする</li></ul><p><img src="/blog/Configuration-and-Usage-Guide-for-Keyboard-Shortcuts-in-New-Outlook-for-Windows/KeyboardShortcuts.png"></p><div style="margin:1.25em;border-left:4px solid #ff7518;padding:.5em"><div style="margin:0 0 16px 0;display:flex;align-items:center;line-height:1;color:#ff7518"><svg viewBox="0 0 16 16" width="16" height="16" aria-hidden="true" style="margin-right:8px"><path fill="#ff7518" d="M6.457 1.047c.659-1.234 2.427-1.234 3.086 0l6.082 11.378A1.75 1.75 0 0 1 14.082 15H1.918a1.75 1.75 0 0 1-1.543-2.575Zm1.763.707a.25.25 0 0 0-.44 0L1.698 13.132a.25.25 0 0 0 .22.368h12.164a.25.25 0 0 0 .22-.368Zm.53 3.996v2.5a.75.75 0 0 1-1.5 0v-2.5a.75.75 0 0 1 1.5 0ZM9 11a1 1 0 1 1-2 0 1 1 0 0 1 2 0Z"></path></svg>注意</div>既定では Outlook for Windows が設定されており、多くのショートカット キーは従来の Outlook と同じですが、いくつか違うショートカット キーもございますのでご注意ください。 </div><h2 id="便利なショートカット-キー"><a href="#便利なショートカット-キー" class="headerlink" title="便利なショートカット キー"></a>便利なショートカット キー</h2><p>新しい Outlook のショートカット キーより、Outlook for Windows と Outlook for Web の設定にてそれぞれ利用可能な便利なショートカット キーの一部をご紹介します。  </p><h3 id="Outlook-for-Windows-の設定を使用している場合"><a href="#Outlook-for-Windows-の設定を使用している場合" class="headerlink" title="Outlook for Windows の設定を使用している場合"></a>Outlook for Windows の設定を使用している場合</h3><table><thead><tr><th>操作内容</th><th>ショートカット キー</th></tr></thead><tbody><tr><td>新しいメール メッセージを作成する</td><td>Ctrl+N &#x2F; Ctrl+Shift+M</td></tr><tr><td>このメッセージに返信する</td><td>Ctrl+R</td></tr><tr><td>このメッセージの全員に返信する</td><td>Ctrl+Shift+R</td></tr><tr><td>このメッセージを転送する</td><td>Ctrl+F</td></tr><tr><td>[メール] に移動する</td><td>Ctrl+1</td></tr><tr><td>[予定表] に移動する</td><td>Ctrl+2</td></tr><tr><td>このメッセージ内のテキストを検索する</td><td>Ctrl+Shift+F</td></tr></tbody></table><h3 id="Outlook-for-Web-の設定を使用している場合"><a href="#Outlook-for-Web-の設定を使用している場合" class="headerlink" title="Outlook for Web の設定を使用している場合"></a>Outlook for Web の設定を使用している場合</h3><table><thead><tr><th>操作内容</th><th>ショートカット キー</th></tr></thead><tbody><tr><td>新しいメール メッセージを作成する</td><td>N</td></tr><tr><td>このメッセージに返信する</td><td>R &#x2F; Ctrl+R</td></tr><tr><td>このメッセージの全員に返信する</td><td>Shift+R &#x2F; Ctrl+Shift+R</td></tr><tr><td>このメッセージを転送する</td><td>Shift+F &#x2F; Ctrl+Shift+F</td></tr><tr><td>[メール] に移動する</td><td>Ctrl+Shift+1</td></tr><tr><td>[予定表] に移動する</td><td>Ctrl+Shift+2</td></tr><tr><td>このメッセージ内のテキストを検索する</td><td>Ctrl+F</td></tr></tbody></table><p>Outlook for Windows と Outlook for Web の設定ではショートカット キーが異なるため、以前に使用しているクライアントに合わせた設定に変更してご利用ください。<br>使用可能なショートカット キーは<a href="https://support.microsoft.com/office/3cdeb221-7ae5-4c1d-8c1d-9e63216c1efd">こちら</a>の公開情報を参照いただくか、? (疑問符) キーを入力し、キーボード ショートカットを開いて確認ください。<br>※ 設定ウィンドウではなく、メイン ウィンドウにて ? を入力します。</p><p>? (疑問符) キーを入力し、キーボード ショートカットを開いた画面例<br><img src="/blog/Configuration-and-Usage-Guide-for-Keyboard-Shortcuts-in-New-Outlook-for-Windows/Shortcuts.png"></p><p><strong>本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。</strong></p>]]></content>
    
    
      
      
    <summary type="html">&lt;p&gt;こんにちは。日本マイクロソフト Exchange &amp;amp; Outlook サポート チームの杉山です。&lt;br&gt;本記事では、新しい Outlook for Windows (以下、新しい Outlook) をより効率的に使いこなすためのキーボード ショートカットに関する </summary>
      
    
    
    
    
    <category term="New Outlook" scheme="https://jpmessaging.github.io/blog/tags/New-Outlook/"/>
    
  </entry>
  
  <entry>
    <title>Exchange Online メールボックス クォータの詳細解説</title>
    <link href="https://jpmessaging.github.io/blog/demystifying-exchange-online-mailbox-quotas/"/>
    <id>https://jpmessaging.github.io/blog/demystifying-exchange-online-mailbox-quotas/</id>
    <published>2026-01-28T00:00:00.000Z</published>
    <updated>2026-01-28T00:00:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>※ この記事は、<a href="https://techcommunity.microsoft.com/blog/exchange/demystifying-exchange-online-mailbox-quotas/4486474">Demystifying Exchange Online Mailbox Quotas</a> の抄訳です。最新の情報はリンク先をご確認ください。この記事は Microsoft 365 Copilot および GitHub Copilot を使用して抄訳版の作成が行われています。</p><p>Exchange Online におけるメールボックスのサイズ制限については聞いたことがあるかと思います。まだよくご存じでない方は、以下の「Exchange Online の制限」の記事内にある 2 つのセクションをご確認ください。</p><ol><li><a href="https://learn.microsoft.com/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits#storage-limits">格納域の制限</a> (プライマリ メールボックスおよびアーカイブ メールボックスにおけるサイズ制限)</li><li><a href="https://learn.microsoft.com/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits#mailbox-folder-limits-1">メールボックス フォルダーの制限</a> (回復可能なアイテム フォルダーにおけるサイズ制限)</li></ol><h2 id="メールボックスのサイズ制限と使用容量の確認方法"><a href="#メールボックスのサイズ制限と使用容量の確認方法" class="headerlink" title="メールボックスのサイズ制限と使用容量の確認方法"></a>メールボックスのサイズ制限と使用容量の確認方法</h2><p>既定では、<a href="https://learn.microsoft.com/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits#storage-limits">プライマリ メールボックスとアーカイブ メールボックスのクォータ</a> (プライマリ メールボックスとアーカイブ メールボックスにおけるサイズ制限) の上限値は 100 GB に設定されています。一方、<a href="https://learn.microsoft.com/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits#mailbox-folder-limits-1">回復可能なアイテムのクォータ</a> (回復可能なアイテム フォルダーにおけるサイズ制限) は、保持が設定されていないユーザー (訴訟ホールド、インプレース ホールド、組織のホールド、またはコンプライアンス ポリシーのホールドなどが設定されていないユーザー) の場合は 30 GB、保持が設定されたユーザーの場合は 100 GB に設定されています。<br>自動拡張アーカイブを有効にすると、最大 1.5 TB のアーカイブ メールボックスを利用できるようになりますが、この 1.5 TB の<a href="https://learn.microsoft.com/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits#storage-limits">格納域</a>は複数のアーカイブ メールボックスに分割して割り当てられます。つまり、各アーカイブ メールボックスごとに最大 100 GB のサイズ制限が適用されるため、ArchiveQuota の値は各アーカイブ メールボックスごとに 100 GB のままとなります。このため複数のアーカイブ メールボックスを合わせて、全体として最大 1.5 TB の格納域が提供されます。したがって、自動拡張アーカイブを有効にしても ArchiveQuota が <em>単一の</em> 1.5 TB として表示されることはありません。</p><p>メールボックスのサイズ制限には、主に以下の 3 種類があります。</p><ol><li><strong>ProhibitSendReceiveQuota</strong> – プライマリ メールボックスのサイズ制限値です。ユーザーのプライマリ メールボックスがこの値に達すると、メールの送受信ができなくなります。</li><li><strong>ArchiveQuota</strong> – アーカイブ メールボックスのサイズ制限値です。ユーザーのアーカイブ メールボックス (またはメールボックス シャード) がこの値に達すると、その特定のアーカイブ メールボックス (またはシャード) にコンテンツを追加できなくなります。自動拡張アーカイブを使用すると、複数のアーカイブ メールボックス シャードを持つことができます (メールボックスの各インスタンスはシャードと呼ばれます)。</li><li><strong>RecoverableItemsQuota</strong> – 回復可能なアイテム フォルダーのサイズ制限値です。プライマリ メールボックスまたはアーカイブ メールボックス シャード (メイン アーカイブまたは自動拡張アーカイブ) の回復可能なアイテム フォルダーがこの値に達すると、削除済みアイテム フォルダーからの削除や、回復可能なアイテム フォルダーへのコンテンツの移動ができなくなります。</li></ol><p>これらの各サイズ制限値には、関連する警告のしきい値があります。この警告のしきい値は、ユーザー (または Exchange コンポーネントやクライアント) に対して、警告のしきい値に達していることを通知し、実際のサイズ制限値に近づいていることを知らせるためのものです。</p><p>警告のしきい値は、対応する実際のサイズ制限値よりも<em>低い</em>値に設定されています。</p><p>たとえば、<code>Get-Mailbox &lt;User&gt; | FL alias, *Quota</code> を実行すると、これらすべてのクォータとその値を確認できます。</p><p><img src="/blog/demystifying-exchange-online-mailbox-quotas/q01.jpg"></p><p>以下は、<a href="https://learn.microsoft.com/powershell/module/exchangepowershell/set-mailbox?view=exchange-ps">Set-Mailbox (ExchangePowerShell) | Microsoft Learn</a> から引用した、各クォータの定義です。</p><ul><li><strong>ArchiveQuota</strong> - ユーザーのアーカイブ メールボックスの最大サイズを指定します。アーカイブ メールボックスがこのサイズに達するか超過すると、メッセージを受け付けなくなります。ArchiveQuota の値は ArchiveWarningQuota の値以上である必要があります。</li><li><strong>ArchiveWarningQuota</strong> - ユーザーのアーカイブ メールボックスのサイズに対する警告のしきい値を指定します。アーカイブ メールボックスがこのサイズに達するか超過すると、ユーザーに警告メッセージが表示されます。</li><li><strong>RecoverableItemsQuota</strong> - メールボックスの回復可能なアイテム フォルダーの最大サイズを指定します。回復可能なアイテム フォルダーがこのサイズに達するか超過すると、メッセージを受け付けなくなります。RecoverableItemsQuota の値は RecoverableItemsWarningQuota の値以上である必要があります。</li><li><strong>RecoverableItemsWarningQuota</strong> - メールボックスの回復可能なアイテム フォルダーのサイズに対する警告のしきい値を指定します。</li><li><strong>ProhibitSendReceiveQuota</strong> - メールボックスに対するサイズの制限値を指定します。メールボックスがこのサイズに達するか超過すると、新しいメッセージの送受信ができなくなります。このメールボックスに送信されたメッセージは、エラー メッセージとともに送信者に返送されます。この値は実質的にメールボックスの最大サイズを決定します。この値は ProhibitSendQuota または IssueWarningQuota の値以上である必要があります。</li><li><strong>ProhibitSendQuota</strong> - メールボックスに対するサイズの制限値を指定します。メールボックスがこのサイズに達するか超過すると、新しいメッセージを送信できなくなり、ユーザーに警告メッセージが表示されます。ProhibitSendQuota の値は ProhibitSendReceiveQuota の値以下である必要があります。</li><li><strong>IssueWarningQuota</strong> - メールボックスのサイズに対する警告のしきい値を指定します。メールボックスがこのサイズに達するか超過すると、ユーザーに警告メッセージが表示されます。IssueWarningQuota の値は ProhibitSendReceiveQuota の値以下である必要があります。</li></ul><p>メールボックスには他にも 2 つのクォータが適用されていますが、この記事では取り上げません。</p><ul><li><strong>RulesQuota</strong> (対応する警告のしきい値なし) - メールボックスの受信トレイ ルールのサイズの上限を指定します。</li><li><strong>CalendarLoggingQuota</strong> (対応する警告のしきい値なし) - メールボックスの回復可能なアイテム フォルダー内にある、予定表アイテムの変更を記録するログの最大サイズを指定します。ログがこのサイズを超えると、メッセージング レコード管理 (MRM) が古い予定表ログを削除して空き容量を確保するまで、予定表のログ記録が無効になります。</li></ul><p>Exchange Online では、ProhibitSendQuota、ProhibitSendReceiveQuota、IssueWarningQuota および RulesQuota のみ設定できます。クォータの値は引き下げることも引き上げることもできますが、サブスクリプションまたはライセンスで許可されている最大値を超えることはできません。</p><h2 id="クォータの確認方法と使用容量の確認方法"><a href="#クォータの確認方法と使用容量の確認方法" class="headerlink" title="クォータの確認方法と使用容量の確認方法"></a>クォータの確認方法と使用容量の確認方法</h2><h4 id="プライマリ-メールボックスのクォータ"><a href="#プライマリ-メールボックスのクォータ" class="headerlink" title="プライマリ メールボックスのクォータ"></a>プライマリ メールボックスのクォータ</h4><p>プライマリ メールボックスにおけるサイズ制限の最大値は、ユーザーに割り当てられているメールボックス プランまたはライセンスによって異なります。たとえば、デスクレス ワーカー向けライセンスでは 2 GB、Exchange Online プラン 1 では 50 GB、Exchange Online プラン 2 では 100 GB が上限となります。</p><p>この値は <code>Get-Mailbox &lt;user&gt; | FL ProhibitSendReceiveQuota</code> を実行して確認できます。</p><p><img src="/blog/demystifying-exchange-online-mailbox-quotas/q02.jpg"></p><p>プライマリ メールボックスの使用容量を確認するには、<code>Get-MailboxStatistics</code> コマンドをプライマリ メールボックスに対して実行し、TotalItemSize の値を確認します。</p><p><img src="/blog/demystifying-exchange-online-mailbox-quotas/q03.jpg"></p><p>ProhibitSendReceiveQuota の値から TotalItemSize を差し引くことで、メールボックスの残り容量を確認できます。この例では、以下の計算により約 57.5 GB の空き容量があることがわかります。</p><p><strong>100 - 42.49 &#x3D; 57.51</strong></p><p>プライマリ メールボックスの統計情報は、ユーザーの識別子 (UPN、メール アドレス、エイリアス) を指定して Get-MailboxStatistics コマンドを実行することで取得できますが、メールボックスの MailboxGuid を指定しても同様の結果を得ることができます。以下の例では、mailbox1 にプライマリ メールボックス (545e88f1-5bbe-45d5-bc99-599928eabbd7) とアーカイブ メールボックス (1c2d9561-0b6a-4f6a-9479-902f98b17546) の両方が存在することを示します。</p><p><img src="/blog/demystifying-exchange-online-mailbox-quotas/q04.jpg"></p><p>TotalItemSize の値に含まれるデータ (フォルダー) の種類を確認したい場合は、Get-MailboxFolderStatistics を実行し、TargetQuota が User に設定されているすべてのフォルダーを確認します。<br>以下のようなコマンドから確認ができます。</p><pre><code>Get-MailboxFolderStatistics &lt;user&gt; |FT Name, FolderSize, ItemsInFolder, TargetQuotaGet-MailboxFolderStatistics mailbox1 | group TargetQuota | FT Name, Count</code></pre><p>例として、mailbox1 には TargetQuota が User に設定されたフォルダーが 900 個あり、これらのフォルダーのサイズはすべて TotalItemSize にカウントされます。</p><p><img src="/blog/demystifying-exchange-online-mailbox-quotas/q05.jpg"></p><h4 id="アーカイブ-メールボックスのクォータ"><a href="#アーカイブ-メールボックスのクォータ" class="headerlink" title="アーカイブ メールボックスのクォータ"></a>アーカイブ メールボックスのクォータ</h4><p>アーカイブ メールボックスにおけるサイズ制限値は、メールボックス プランやライセンスに応じて 50 GB または 100 GB となります。この値は <code>Get-Mailbox &lt;user&gt; | FL ArchiveQuota</code> を実行して確認できます。</p><p><img src="/blog/demystifying-exchange-online-mailbox-quotas/q06.jpg"></p><p>アーカイブ メールボックスの使用容量を確認するには、<code>Get-MailboxStatistics -Archive &lt;user&gt;</code> を実行するか、メイン アーカイブの ArchiveGuid または MailboxGuid を指定して実行し、TotalItemSize の値を確認します。</p><p>同様にアーカイブ メールボックス内のどのフォルダーが TotalItemSize に加算されているか確認したい場合は、Get-MailboxFolderStatistics に -Archive スイッチを指定して実行するか、ArchiveGuid を指定して実行し、TargetQuota が User に設定されているフォルダーを確認します。<br>(複数のアーカイブ メールボックス、つまり自動拡張アーカイブが存在する場合には、ArchiveGuid を指定して実行する方法を推奨します。)</p><p><img src="/blog/demystifying-exchange-online-mailbox-quotas/q07.jpg"></p><h4 id="回復可能なアイテム-フォルダーのクォータ"><a href="#回復可能なアイテム-フォルダーのクォータ" class="headerlink" title="回復可能なアイテム フォルダーのクォータ"></a>回復可能なアイテム フォルダーのクォータ</h4><p>前述のとおり、回復可能なアイテム フォルダーにおけるサイズ制限値は、保持が設定されていないユーザーの場合は 30 GB、保持が設定されているユーザーの場合は 100 GB となります。保持が設定されているユーザーはデータを完全に削除することができないため、回復可能なアイテム用により多くの格納域が必要となります。そのため、ユーザーに訴訟ホールドなどの保持が設定されると、サービスによって自動的に 70 GB 増加されます。</p><p>RecoverableItemsQuota の設定値を確認するには、<code>Get-Mailbox &lt;user&gt; | FL RecoverableItemsQuota</code> を実行します。</p><p><img src="/blog/demystifying-exchange-online-mailbox-quotas/q08.jpg"></p><p>回復可能なアイテム フォルダーのサイズ制限値は、プライマリ メールボックスとアーカイブ メールボックスの両方に適用されます。プライマリ メールボックスにおける回復可能なアイテム フォルダーの使用容量を確認するには、以下のコマンドを実行します。</p><pre><code>Get-MailboxStatistics &lt;user&gt; | FL TotalDeletedItemSize</code></pre><p>または</p><pre><code>Get-MailboxStatistics &lt;Primary MailboxGuid&gt; | FL TotalDeletedItemSize</code></pre><p>アーカイブ メールボックスにおける回復可能なアイテム フォルダーの使用容量を確認するには、以下のコマンドを実行します。</p><pre><code>Get-MailboxStatistics &lt;user&gt; -Archive | FL TotalDeletedItemSize</code></pre><p>または</p><pre><code>Get-MailboxStatistics &lt;メイン アーカイブの MailboxGuid または ArchiveGuid&gt; | FL TotalDeletedItemSize</code></pre><p>Get-MailboxStatistics -Archive に関する補足事項:</p><ul><li>複数のアーカイブ メールボックス (メイン アーカイブと自動拡張アーカイブ) が存在する場合、タイムアウトが発生したり、実行に時間がかかる場合があります。これを回避するには、-Archive スイッチではなく、アーカイブ メールボックス シャードの GUID を指定して Get-MailboxStatistics を実行してください。</li><li>複数のアーカイブ メールボックスが存在する場合、統計情報は合算された値で表示されます。個々のサイズを確認したい場合は、アーカイブ メールボックス シャードの GUID を指定してください。</li></ul><p>以下の例では、shared1 というメールボックスのプライマリ メールボックス内の回復可能なアイテム フォルダーには 307 MB、アーカイブ メールボックス内の回復可能なアイテム フォルダーには 1 GB のデータが格納されています。</p><p><img src="/blog/demystifying-exchange-online-mailbox-quotas/q09.jpg"></p><p>回復可能なアイテム フォルダーとそのサイズを確認したい場合、以下のコマンドを実行します。(回復可能なアイテム フォルダー内のサイズの合計が TotalDeletedItemSize になります。)</p><p>プライマリ メールボックスの回復可能なアイテム フォルダーを確認する場合:</p><pre><code>Get-MailboxFolderStatistics &lt;user&gt; -FolderScope RecoverableItems | FT Name, FolderSize, TargetQuota</code></pre><p>アーカイブ メールボックスの回復可能なアイテム フォルダーを確認する場合:</p><pre><code>Get-MailboxFolderStatistics &lt;user&gt; -Archive -FolderScope RecoverableItems | FT Name, FolderSize, TargetQuota</code></pre><p>上記の Get-MailboxStatistics の出力結果に続いて、Get-MailboxFolderStatistics の出力結果も以下に示します。プライマリ メールボックスとアーカイブ メールボックスの両方とも、回復可能なアイテム フォルダーのサイズは 30 GB の制限値を十分に下回っています。</p><p><img src="/blog/demystifying-exchange-online-mailbox-quotas/q10.jpg"></p><p>次に、よくある問題が発生するシナリオとその対処方法について確認しましょう。</p><h3 id="クロステナント-メールボックス移行-CTMM-における-MRS-の使用"><a href="#クロステナント-メールボックス移行-CTMM-における-MRS-の使用" class="headerlink" title="クロステナント メールボックス移行 (CTMM) における MRS の使用"></a>クロステナント メールボックス移行 (CTMM) における MRS の使用</h3><p>既定では、メール ユーザーの回復可能なアイテム フォルダーのサイズ制限値は 30 GB に設定されていますが、移行元メールボックスの回復可能なアイテム フォルダーのサイズ制限値がこのサイズを超えている場合があります (通常は何らかの保持が設定されていることに起因します)。この場合以下のコマンドを実行して、移行先テナントのメール ユーザー オブジェクトに対する訴訟ホールドを有効にすることで、回復可能なアイテム フォルダーのサイズ制限値を 100 GB まで引き上げることができます。これにより、QuotaExceeded の例外による移行時のエラーを回避できます。</p><pre><code>Set-MailUser &lt;id&gt; -EnableLitigationHoldForMigration</code></pre><p>以下の例では、このスイッチを使用してメール ユーザー オブジェクトの RecoverableItemsQuota を 30 GB から 100 GB に引き上げています。</p><p><img src="/blog/demystifying-exchange-online-mailbox-quotas/q11.jpg"></p><p>補足事項:</p><ul><li>このコマンドは、クラウドのみのメール ユーザーだけでなく、ディレクトリ同期された (IsDirSynced &#x3D; True の) メール ユーザーにも適用されます。</li><li>移行元メールボックスがオンプレミス Exchange でホストされており、クラウド上に対応するメール ユーザーが存在する場合のハイブリッド移行のシナリオでは、この手順を使用<em>しないでください</em>。たとえば、オンプレミス上のメールボックスに 70 GB の回復可能なアイテムがあり、そのメールボックスに保持の設定がされていない場合、オンプレミス側で対象のメールボックスに対して訴訟ホールドを有効にすることを推奨します。ディレクトリ同期後、クラウド上の対応するメール ユーザーの回復可能なアイテム フォルダーのサイズ制限値は 100 GB に増加しますが、さらに重要なのは当該メール ユーザーで訴訟ホールドが有効になり、その状態が維持されることです。これにより、ハイブリッド移行を使用してオンプレミスのメールボックスをクラウドに移行する際、メール ユーザーはオンプレミスから同期された LitigationHold フラグを引き継ぎ、Exchange Online 移行後に RetainDeletedItemsFor の設定によって回復可能なアイテムが削除されることを防ぐことができます。</li><li>ハイブリッド移行を行うユーザーに対して Exchange Online から Set-MailUser -EnableLitigationHoldForMigration を実行した場合、次回のディレクトリ同期時にオンプレミス AD から訴訟ホールド フラグが上書きされることにご注意ください。つまり、コマンドを実行することで訴訟ホールドが有効になったと思われるかもしれませんが、オンプレミスのメールボックスで訴訟ホールドが設定されていない場合、その情報が同期されます。したがって、コマンドから訴訟ホールドを有効にしても設定は維持されません。なお、この状況で RecoverableItemsQuota が 30 GB に戻ることはありませんが、メールボックスを Exchange Online に移行した後に回復可能なアイテムが削除される可能性についてご留意ください。</li></ul><p>訴訟ホールドが一時的に有効化された状態:</p><p><img src="/blog/demystifying-exchange-online-mailbox-quotas/q12.jpg"></p><p>ディレクトリ同期後に訴訟ホールドが自動的に無効になった状態:</p><p><img src="/blog/demystifying-exchange-online-mailbox-quotas/q13.jpg"></p><p>なお、移行先テナントのメール ユーザーがディレクトリ同期されており、オンプレミス AD にもメール ユーザーとして存在する場合、訴訟ホールド フラグは次回のディレクトリ同期サイクルで上書きされることはありません。</p><p><img src="/blog/demystifying-exchange-online-mailbox-quotas/q14.jpg"></p><p>また、クロステナント移行の目的でメール ユーザーの訴訟ホールドを有効にした後、Exchange Online でそれを無効にするためのスイッチは用意されていません。移行完了後、ユーザーがメールボックスとして有効になった状態であれば、<code>Set-Mailbox &lt;user&gt; -LitigationHoldEnabled $false</code> を実行して無効にすることができます。ただし、訴訟ホールドを無効にすると回復可能なアイテム フォルダーからデータが削除される可能性がありますのでご注意ください。</p><h3 id="Gmail-および-IMAP-からの大容量メールボックスの-Exchange-Online-への移行"><a href="#Gmail-および-IMAP-からの大容量メールボックスの-Exchange-Online-への移行" class="headerlink" title="Gmail および IMAP からの大容量メールボックスの Exchange Online への移行"></a>Gmail および IMAP からの大容量メールボックスの Exchange Online への移行</h3><p>移行元メールボックスのサイズが 100 GB を超えており、Google または IMAP でホストされている場合、組み込みの大容量メールボックス移行オプションを利用できます。詳細は <a href="https://learn.microsoft.com/exchange/mailbox-migration/automated-large-mailbox-migration-from-imap-sources">Migrate large mailboxes from Google or other IMAP sources to Microsoft 365 Exchange | Microsoft Learn</a> をご参照ください。</p><p>この移行方法を使用すると、Exchange Online における 100 GB のメールボックス制限や ProhibitSendReceiveQuota (プライマリ メールボックスのサイズ制限値) を引き上げる方法について心配する必要はありません。サービスによって自動的に超過分のコンテンツがアーカイブ メールボックスに移行されます。</p><p>なお、現時点では Migration チームがハイブリッド移行向けのソリューションを開発中です。このソリューションは、現在 Gmail や IMAP からの大容量メールボックス移行で提供されているものと同様の機能を提供する予定です。本ブログの執筆時点では、オンプレミス Exchange 上にある大容量のプライマリ メールボックス (100 GB ～ 2 TB) 向けのソリューションは 2026 年 3 月頃に提供が<em>見込まれて</em>います。この開発の第 1 フェーズでは、オンプレミス Exchange 上にある大容量のプライマリ メールボックスのみが対象となります (オンプレミス Exchange 上にある大容量のアーカイブ メールボックスへの対応は後日予定されています)。</p><h3 id="Exchange-Online-でホストされているメールボックス-移行シナリオ以外の場合"><a href="#Exchange-Online-でホストされているメールボックス-移行シナリオ以外の場合" class="headerlink" title="Exchange Online でホストされているメールボックス (移行シナリオ以外の場合)"></a>Exchange Online でホストされているメールボックス (移行シナリオ以外の場合)</h3><p>管理者として、プライマリ メールボックス、アーカイブ メールボックス、または回復可能なアイテム フォルダーがサイズ制限値に抵触するシナリオへの対応をされたことがあるかと思います。このような状況がユーザーに与える影響は以下のとおりです。</p><ul><li><strong>ProhibitSendReceiveQuota に達した場合</strong> – ユーザーはプライマリ メールボックスでメールの送受信ができなくなります。</li><li><strong>ArchiveQuota に達した場合</strong> – ユーザーはアーカイブ メールボックスにデータを移動できなくなります。</li><li><strong>RecoverableItemsQuota に達した場合</strong> – プライマリ メールボックスまたはアーカイブ メールボックスの回復可能なアイテム フォルダーがいっぱいになるため、ユーザーはアイテムを完全に削除できなくなります。また、会議の招待に関する問題が発生する場合もあります。詳細は <a href="https://learn.microsoft.com/troubleshoot/exchange/antispam-and-protection/recoverable-items-folder-full#symptoms">Recoverable Items folder not emptied for mailbox on litigation or retention hold - Exchange | Microsoft Learn</a> をご参照ください。</li></ul><p>管理者は定期的にメールボックスの使用状況を確認することをお勧めします。制限値に近づいているメールボックスを確認するには、Microsoft 365 管理センターの以下のレポートをご利用ください: <a href="https://learn.microsoft.com/microsoft-365/admin/activity-reports/mailbox-usage?view=o365-worldwide#interpret-the-mailbox-usage-report">Microsoft 365 Reports in the admin center - Mailbox usage</a></p><p><strong>ProhibitSendReceiveQuota の制限値に達した場合</strong>、以下のような対処方法があります。</p><ul><li>ユーザーは可能であればメールボックスの空き容量を確保する (不要なメール、迷惑メール、削除済みアイテムを削除する)。</li><li>管理者はアーカイブ メールボックスを有効にし、プライマリ メールボックスからアーカイブ メールボックスへデータを移動するためのアイテム保持ポリシーおよび保持タグを作成する。</li><li>現在ユーザーに割り当てられているライセンスが提供する格納域が少ない場合 (例: Exchange Online P1 の 50 GB)、より多くの格納域を提供するライセンス (Exchange Online P2 の 100 GB) を割り当てることを検討する。</li></ul><p>メイン アーカイブが制限値に到達し (<strong>ArchiveQuota の制限値に到達し</strong>)、かつデータを保持する必要がある場合は、自動拡張アーカイブを有効にする方法があります。これにより、拡張アーカイブ (AuxArchive) が割り当てられ、コンテンツはメイン アーカイブと拡張アーカイブの間で自動的に分割させることができます。また、訴訟ホールドなどの保持が有効化され、かつメールボックス レベルで自動拡張アーカイブが有効な場合、ArchiveQuota は 110 GB まで拡張されます (詳細は後述)。</p><p><strong>RecoverableItemsQuota の制限値に達した場合</strong>、回復可能なアイテム フォルダー内のアイテムを完全に削除する、RecoverableItemsQuota を設定可能な最大値まで引き上げる、または自動拡張アーカイブを有効にしてデータをアーカイブ メールボックスに分割・移動するといった対処方法があります。なお、回復可能なアイテム フォルダー内のアイテムに関する処理として、Exchange Online サービスには Dumpster Expiration Enforcer と呼ばれるコンポーネントが存在します。このコンポーネントでは、回復可能なアイテム フォルダーの警告のしきい値 (RecoverableItemsWarningQuota) を超えると、アイテムの更新日時に基づいて FIFO (先入れ先出し) 方式でアイテムを削除します。この仕組みにより、RetainDeletedItemsFor の期間に到達する前であっても、ユーザーが追加のデータを削除するための空き容量が確保されます。この動作は単一アイテムの回復の設定に関係なく行われます。詳細は <a href="https://learn.microsoft.com/exchange/security-and-compliance/recoverable-items-folder/recoverable-items-folder#single-item-recovery">Recoverable Items folder in Exchange Online | Microsoft Learn</a> をご参照ください。</p><p>ここで、回復可能なアイテム フォルダーのサイズ制限値 (RecoverableItemsQuota) が 30 GB、アーカイブ メールボックスのサイズ制限値 (ArchiveQuota) が 100 GB に設定されており、アーカイブ メールボックスも訴訟ホールドも有効になっていないユーザー メールボックスのシナリオを見ていきましょう。なお、以下の例では説明を簡単にするために LitigationHold パラメーターを使用していますが、RecoverableItemsQuota は他の種類の保持でも同様に増加します。</p><pre><code>Get-Mailbox &lt;user&gt; | FL Alias, ProhibitSendReceiveQuota, ArchiveQuota, RecoverableItemsQuota, LitigationHoldEnabled, ArchiveGuid, AutoExpandingArchiveEnabled</code></pre><p><img src="/blog/demystifying-exchange-online-mailbox-quotas/q15.jpg"></p><p>ユーザーに訴訟ホールドを設定すると、RecoverableItemsQuota が 30 GB から 100 GB に増加します。</p><p><img src="/blog/demystifying-exchange-online-mailbox-quotas/q16.jpg"></p><p>さらにアーカイブ メールボックスを有効にすると、RecoverableItemsQuota は 105 GB まで増加します。</p><p><img src="/blog/demystifying-exchange-online-mailbox-quotas/q17.jpg"></p><p>さらにメールボックス レベルで自動拡張アーカイブを有効にすると、RecoverableItemsQuota と ArchiveQuota はそれぞれ 110 GB まで増加します。</p><p><img src="/blog/demystifying-exchange-online-mailbox-quotas/q18.jpg"></p><p><strong>重要</strong>: 自動拡張アーカイブを有効にすると、メールボックスをオンプレミス Exchange に戻すこと、メールボックスの復元要求 (New-MailboxRestoreRequest) を実行すること、および非アクティブなメールボックスを回復することができなくなります。</p><h4 id="参考資料"><a href="#参考資料" class="headerlink" title="参考資料"></a>参考資料</h4><ul><li><a href="https://learn.microsoft.com/purview/ediscovery-increase-the-recoverable-quota-for-mailboxes-on-hold">Increase the Recoverable Items quota for mailboxes on hold | Microsoft Learn</a></li><li><a href="https://learn.microsoft.com/purview/autoexpanding-archiving">Learn about auto-expanding archiving | Microsoft Learn</a></li><li><a href="https://learn.microsoft.com/purview/enable-autoexpanding-archiving">Enable auto-expanding archiving | Microsoft Learn</a></li><li><a href="https://www.microsoft.com/microsoft-365/blog/2025/12/04/advancing-microsoft-365-new-capabilities-and-pricing-update/">Advancing Microsoft 365: New capabilities and pricing update | Microsoft 365 Blog</a></li></ul><p>この記事がお役に立てば幸いです。最後までお読みいただきありがとうございました。</p><p>この記事の執筆にあたり、Nino Bilic 氏をはじめ、ご協力いただいたすべての皆様に感謝いたします。</p>]]></content>
    
    
      
      
    <summary type="html">&lt;p&gt;※ この記事は、&lt;a href=&quot;https://techcommunity.microsoft.com/blog/exchange/demystifying-exchange-online-mailbox-quotas/4486474&quot;&gt;Demystifying Exch</summary>
      
    
    
    
    
    <category term="Exchange Online" scheme="https://jpmessaging.github.io/blog/tags/Exchange-Online/"/>
    
  </entry>
  
  <entry>
    <title>Graph API を使用したメッセージ トレースのサポートにおけるパブリック プレビューのご案内
</title>
    <link href="https://jpmessaging.github.io/blog/Message-Trace-Support-Using-Graph-API-is-now-in-Public-Preview/"/>
    <id>https://jpmessaging.github.io/blog/Message-Trace-Support-Using-Graph-API-is-now-in-Public-Preview/</id>
    <published>2026-01-21T15:00:00.000Z</published>
    <updated>2026-01-21T15:00:00.000Z</updated>
    
    <content type="html"><![CDATA[<p><span style="background-color: yellow; font-weight: bold;">2026&#x2F;2&#x2F;6 編集: 本機能は正式リリース (GA: Generally Available) されました。オンボーディングに関する詳細な手順は、<a href="https://learn.microsoft.com/exchange/monitoring/trace-an-email-message/graph-api-message-trace">こちら</a> に纏めました。</span></p><p>※ この記事は、<a href="https://techcommunity.microsoft.com/blog/exchange/message-trace-support-using-graph-api-is-now-in-public-preview/4488587">Message Trace Support Using Graph API is now in Public Preview</a> の抄訳です。最新の情報はリンク先をご確認ください。この記事は Microsoft 365 Copilot および GitHub Copilot を使用して抄訳版の作成が行われています。</p><p>Graph API を使用したメッセージ トレースのサポートが正式リリース (GA) となったことをお知らせします。コミュニティからのフィードバックを受けて、メッセージ トレースのエクスペリエンス向上に向けた強化を実施してきましたが、このたび本機能は正式リリース (GA) されました。<br>この RESTful Web API を使用すると、Exchange Online 組織全体での電子メールメッセージを追跡できます。<br>Graph API を使用した新しいメッセージトレース サポートは、既存の Reporting Webservice API を使用したメッセージ トレースを置き換えるものです。<br>詳細については、Graph API ドキュメント <a href="https://learn.microsoft.com/graph/api/resources/exchangemessagetrace?view=graph-rest-beta">exchangeMessageTrace resource type - Microsoft Graph beta | Microsoft Learn</a> をご参照ください。</p><h2 id="オンボーディング"><a href="#オンボーディング" class="headerlink" title="オンボーディング"></a>オンボーディング</h2><p><a href="https://review.learn.microsoft.com/entra/identity-platform/retire-service-principal-less-authentication?branch=main">サービス プリンシパルを使用しない認証の廃止</a>に伴い、本機能を利用するには追加の対応が必要となります。詳細については、以下のオンボーディング ドキュメントをご参照ください。</p><p><a href="https://learn.microsoft.com/exchange/monitoring/trace-an-email-message/graph-api-message-trace">Graph-based message trace API onboarding guide | Microsoft Learn</a></p><p>新しいサービス プリンシパルの作成後、プロビジョニングが完了するまでに数時間かかる場合があります。<br>この間、401 (Unauthorized) エラーが発生する可能性がありますので、プロビジョニングが完了、及び、反映されるまで数時間お待ちください。<br>関連情報については、以下のページをご参照ください。</p><p><a href="https://learn.microsoft.com/entra/identity-platform/retire-service-principal-less-authentication?branch=main">Retirement of service principal-less authentication - Microsoft identity platform | Microsoft Learn</a></p><h2 id="移行ガイダンスおよび廃止スケジュール"><a href="#移行ガイダンスおよび廃止スケジュール" class="headerlink" title="移行ガイダンスおよび廃止スケジュール"></a>移行ガイダンスおよび廃止スケジュール</h2><p>現在、Reporting Webservice を使用したメッセージ トレースを利用している場合は、2026 年 4 月 6 日までに Graph API を使用したメッセージ トレースへ移行してください。</p><p><strong>Reporting Webservice を使用した Message Trace および Message Trace Detail のサポートは、2026 年 4 月 8 日から非推奨 (廃止開始) となります。</strong></p><p>なお、Exchange Online に新規オンボーディングされるすべての組織では、移行作業の一環として、既定では Reporting Webservice を使用したメッセージ トレースへのアクセスはすでに提供されていません。</p><h2 id="スロットリング"><a href="#スロットリング" class="headerlink" title="スロットリング"></a>スロットリング</h2><p>Exchange Online リソースの不正利用・悪用のリスクを低減し、すべてのユーザーに対するサービスの可用性を確保しつつ、予測可能なエクスペリエンスを提供するため、一定時間内のリクエスト数に基づくレート制限（スロットリング）を実装します。Message Trace および Message Trace Detail へのすべての呼び出しは同一の数量制限を共有します。<br>1 テナントあたり、5 分間の実行ウィンドウ内で最大 100 件のメッセージ トレース クエリ リクエストが受け入れられます。過去 5 分間のリクエストが 100 件未満の場合、スロットリングは適用されません。スロットリングの閾値を超えて頻繁にクエリを実行するような自動化など使用されている場合、閾値を超えないように自動化の調整をご検討ください。</p><p>なお、クエリ リクエスト数と結果サイズは同じではありません。1 回のクエリ リクエストで、最大 5,000 件の結果を返すことができます。これにより、5 分間の実行ウィンドウ内で取得可能な最大結果数は 500,000 件となります。クエリを分散させることで、1 日あたり最大 1 億 4,400 万件の結果を取得できます。このスロットリング制限は、すべてのテナントに対する公平性とサービスの可用性を確保するためのものです。</p><table><thead><tr><th><strong>Cmdlet</strong></th><th><strong>テナントレベルの制限</strong></th></tr></thead><tbody><tr><td><a href="https://learn.microsoft.com/powershell/module/exchange/get-messagetracev2?view=exchange-ps">Get-MessageTraceV2</a></td><td>5 分あたり 100 リクエスト</td></tr><tr><td><a href="https://learn.microsoft.com/powershell/module/exchange/get-messagetracedetailv2?view=exchange-ps">Get-MessageTraceDetailV2</a></td><td>5 分あたり 100 リクエスト</td></tr></tbody></table>]]></content>
    
    
      
      
    <summary type="html">&lt;p&gt;&lt;span style=&quot;background-color: yellow; font-weight: bold;&quot;&gt;2026&amp;#x2F;2&amp;#x2F;6 編集: 本機能は正式リリース (GA: Generally Available) されました。オンボーディングに関する</summary>
      
    
    
    
    
    <category term="Exchange Online" scheme="https://jpmessaging.github.io/blog/tags/Exchange-Online/"/>
    
  </entry>
  
  <entry>
    <title>Exchange Onlineにおけるローカル移動要求 – なぜサポートされていないのか</title>
    <link href="https://jpmessaging.github.io/blog/local-move-requests-in-exchange-online-%E2%80%93-why-they%E2%80%99re-not-supported/"/>
    <id>https://jpmessaging.github.io/blog/local-move-requests-in-exchange-online-%E2%80%93-why-they%E2%80%99re-not-supported/</id>
    <published>2026-01-13T15:00:00.000Z</published>
    <updated>2026-01-13T15:00:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>※ この記事は、<a href="https://techcommunity.microsoft.com/blog/exchange/local-move-requests-in-exchange-online-%E2%80%93-why-they%E2%80%99re-not-supported/4484222">Local Move Requests in Exchange Online – Why They’re Not Supported</a> の抄訳です。最新の情報はリンク先をご確認ください。この記事は Microsoft 365 Copilot および GitHub Copilot を使用して抄訳版の作成が行われています。</p><p>Exchange Online では、管理者が New-MoveRequest コマンドレットを使用して、同じテナントまたはデータセンター内でメールボックスを移動することを検討する場合があります。過去の経緯によりこのコマンドは存在していますが、<strong>Microsoft はローカル移動要求をサポートしていません</strong>。この記事では、その理由、リスク、および代わりに使用すべき方法について説明します。</p><p>Microsoft は過去に<a href="https://techcommunity.microsoft.com/blog/exchange/disabling-new-moverequest-for-local-mailbox-moves/1214776">ローカル移動要求を無効化する</a>と述べていましたが、実際には無効化していません。特定の状況下では問題解決に<em>役立つ場合がある</em>ことは認識していますが、<strong>ローカル移動要求の使用はサポート対象外であり、推奨もしていません</strong>。<u>使用する場合は自己責任において行ってください。</u></p><h4 id="ローカル移動要求が問題となる理由"><a href="#ローカル移動要求が問題となる理由" class="headerlink" title="ローカル移動要求が問題となる理由"></a>ローカル移動要求が問題となる理由</h4><p>ローカル移動要求は、もともとオンプレミスの Exchange Server 2010 におけるデータベース間の移動、および Exchange ハイブリッド環境でのオンボーディング &#x2F; オフボーディング シナリオ (Exchange Server と Exchange Online 間でのメールボックスの移動) のためのリモート移動要求として設計されました。その後、同じ New-MoveRequest コマンドを使用して 2 つの異なるテナント間でメールボックスを移行する機能 (クロス テナント移行) や、同一テナント内の異なる地域にメールボックスを持つマルチ Geo 環境向けの機能が追加されました。Microsoft 365 環境では、メールボックスの配置と負荷分散はサービスによって自動的に処理されます。テナント内で手動移動を強制すると、いくつかの問題が発生します。</p><ul><li><p><strong>サポート対象外</strong>: Microsoft サポートは、ローカル移動のトラブルシューティングや処理の迅速化を行うことができません。これらの要求は低優先度のバックグラウンド タスクとして扱われ、完了までに数週間かかる場合があります。詳細については、<a href="https://techcommunity.microsoft.com/blog/exchange/resource-based-throttling-and-prioritization-in-exchange-online-migrations/608020">Resource Based Throttling and Prioritization in Exchange Online Migrations | Microsoft Community Hub</a> を参照してください。管理者がデータセンター内の任意のターゲット サーバーを指定して移動を開始した場合、そのターゲット サーバーが過負荷状態にあるか、あるいは近くメンテナンスが予定されているかを事前に把握することはできません。また、大規模なメールボックス移動によってサーバーに過剰な負荷をかけてしまう可能性があり、その場合は自動負荷分散が状況を検出して修正するまで待つ必要があります。管理者によって開始されたローカル移動はサポートされていないため、完了までに要する時間の目安は提供されていません。一方、Exchange Online による自動的かつ負荷分散された移動については、所要時間の推定値が提供されています: <a href="https://learn.microsoft.com/exchange/mailbox-migration/office-365-migration-best-practices#duration-estimates-for-mailbox-migration-in-exchange-online">Microsoft 365 and Office 365 migration performance and best practices | Microsoft Learn</a></p></li><li><p><strong>関連付けのないデータとなるリスク</strong>: 移動要求は、プライマリ メールボックスとメイン アーカイブ メールボックスの両方に使用できます。ローカル移動要求を使用してデータセンター内でプライマリ シャードやメイン アーカイブ シャードを移動できることは事実ですが、利用には十分な注意が必要です。ローカル移動の完了時にユーザー情報を更新する処理は、プライマリ シャードとメイン アーカイブ シャードを指すユーザーのプロパティ<strong>のみ</strong>を認識しています。もし何らかの方法で MailboxLocation ベースのシャード (ComponentShared や AuxArchive シャードなど) に対して New-MoveRequest を実行した場合、完了処理では MailboxLocation ベースのシャードのデータベースを更新<strong>しない</strong>だけでなく、プライマリ シャードの Database プロパティがリセットされ、プライマリ シャードがダイヤルトーン (関連付けのない) 状態になる可能性があります。この点について十分にご注意ください。</p></li><li><p><strong>手動移動は自動化に置き換えられています</strong>: Exchange Online はインテリジェントな負荷分散と自動修復プロセスを使用しています。そのため、手動によるローカル移動要求は不要であり、多くの場合はかえって逆効果となります。</p></li></ul><h4 id="よくある誤解"><a href="#よくある誤解" class="headerlink" title="よくある誤解"></a>よくある誤解</h4><ul><li><p><strong>ローカル移動ですべてのメールボックスの問題とデータ破損が「修復」される</strong>: 基本的なレベルでは、移動要求はメールボックスをあるデータベースから別のデータベースに移動するだけであり、明示的な修復は行われません。しかし、メールボックス移動では、サービスがターゲット メールボックス内のすべてのアイテムを再作成するため、ソースに何らかの問題があった場合、一部の不良データがそのまま残ってしまう<em>可能性は十分に考えられます</em>。ただし、メールボックス移動を使用して問題をトラブルシューティングする状況は、ベスト プラクティスというよりも例外的なケースであることに注意してください。なぜなら、メールボックスが抱えている特定の問題に対して何の効果もない可能性があり、場合によっては、問題の根本原因を追跡することが不可能になる可能性もあるためです。</p></li><li><p><strong>ローカル移動によってメールボックスのパフォーマンスが向上する</strong>: そうではありません。メールボックスのパフォーマンスは、手動での再配置ではなく、サービス レベルの最適化に依存します。手動で移動した場合、(たとえ成功したとしても) より多くのリソースの負荷を受けるサーバーにメールボックスが配置される可能性もあります。</p></li></ul><h4 id="ローカル移動の代わりに検討すべき対処方法"><a href="#ローカル移動の代わりに検討すべき対処方法" class="headerlink" title="ローカル移動の代わりに検討すべき対処方法"></a>ローカル移動の代わりに検討すべき対処方法</h4><p>メールボックスの問題に遭遇した場合、またはデータを再作成する必要がある場合は、<strong>サポートされている方法</strong>を実施してください。</p><ul><li><p><strong>根本原因を調査する</strong>: Microsoft サポートにケースを起票いただき、問題を適切に調査および解決してください。エンジニアリング チームがメールボックスの移動を選択する場合もありますが、このプロセスは十分に検討された上で正当な理由に基づいて実施され、また監視されています。</p></li><li><p><strong>サービス側の自動処理に任せる</strong>: Exchange Online は、メールボックスの配置を継続的に監視し、再バランス化を行っています。手動での介入が必要になることはほとんどありません。</p></li></ul><h4 id="実施すべきことと避けるべきこと"><a href="#実施すべきことと避けるべきこと" class="headerlink" title="実施すべきことと避けるべきこと"></a>実施すべきことと避けるべきこと</h4><p><strong>実施すべきこと:</strong></p><ul><li>メールボックスの問題に対する根本原因の調査。</li><li>最適なパフォーマンスを得るために、サービスの自動負荷分散を信頼。</li></ul><p><strong>避けるべきこと:</strong></p><ul><li>Exchange Online 内でローカル移動要求の開始。</li><li>ローカル移動要求を使用してシャード レベルの移動や拡張されたアーカイブの移動。</li><li>ローカル移動要求について、サポートによる迅速化やトラブルシューティングへの期待。</li></ul>]]></content>
    
    
      
      
    <summary type="html">&lt;p&gt;※ この記事は、&lt;a href=&quot;https://techcommunity.microsoft.com/blog/exchange/local-move-requests-in-exchange-online-%E2%80%93-why-they%E2%80%99re-n</summary>
      
    
    
    
    
    <category term="Exchange Online" scheme="https://jpmessaging.github.io/blog/tags/Exchange-Online/"/>
    
  </entry>
  
  <entry>
    <title>Exchange Online の外部受信者数の制限 (MERRL) 廃止について</title>
    <link href="https://jpmessaging.github.io/blog/exchange-online-canceling-the-mailbox-external-recipient-rate-limit/"/>
    <id>https://jpmessaging.github.io/blog/exchange-online-canceling-the-mailbox-external-recipient-rate-limit/</id>
    <published>2026-01-06T15:00:00.000Z</published>
    <updated>2026-01-06T15:00:00.000Z</updated>
    
    <content type="html"><![CDATA[<p>※ この記事は、<a href="https://techcommunity.microsoft.com/blog/exchange/exchange-online-canceling-the-mailbox-external-recipient-rate-limit/4483498">Exchange Online canceling the Mailbox External Recipient Rate Limit</a> の抄訳です。最新の情報はリンク先をご確認ください。この記事は Microsoft 365 Copilot および GitHub Copilot を使用して抄訳版の作成が行われています。</p><p>重要な変更をお知らせ：<strong><a href="https://techcommunity.microsoft.com/blog/exchange/exchange-online-to-introduce-external-recipient-rate-limit/4114733">Exchange Online における外部受信者数の制限</a>の実装は、現時点で無期限に中止されることになりました</strong>。</p><p>お客様から、この制限により大きな運用上の課題が生じているとのフィードバックをいただきました。特に、現在利用可能な一括送信サービスの機能が限定的であることが課題として挙げられています。皆様からのフィードバックを真摯に受け止め、セキュリティと使いやすさのバランスを保ちながら、運用上の混乱を最小限に抑えたソリューションの提供に取り組んでまいります。</p><p>私たちが目指すものは変わりません：</p><ul><li>スパムや悪意のあるメール活動など、Exchange Online の<strong>不正利用の対策</strong></li><li>基幹業務アプリケーション (LOB) が Exchange Online を通じて一括メールを送信するなどの<strong>不適切な使用の防止</strong></li></ul><p>今後は<strong>お客様の業務ワークフローへの影響を最小限に抑える</strong>方法でこれらの課題に対処する予定です。つまり、サービスを保護しながら、お客様の運用ニーズを尊重する、よりスマートで適応的なアプローチを採用してまいります。</p><h3 id="変更されない事項"><a href="#変更されない事項" class="headerlink" title="変更されない事項"></a>変更されない事項</h3><p><a href="https://learn.microsoft.com/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits#sending-limits">Exchange Online の制限</a>に記載されている<strong>受信者数の制限</strong>および<strong>テナントレベルの外部受信者数の制限</strong>は変更されません。</p><p>日頃よりフィードバックとご協力をいただき、ありがとうございます。私たちは皆様の声に耳を傾け、Exchange Online を安全で信頼性が高く、お客様にとって使いやすいものにするため、今後も取り組んでまいります。</p>]]></content>
    
    
      
      
    <summary type="html">&lt;p&gt;※ この記事は、&lt;a href=&quot;https://techcommunity.microsoft.com/blog/exchange/exchange-online-canceling-the-mailbox-external-recipient-rate-limit/44</summary>
      
    
    
    
    
    <category term="Exchange Online" scheme="https://jpmessaging.github.io/blog/tags/Exchange-Online/"/>
    
  </entry>
  
  <entry>
    <title>TERRL と MERRL について</title>
    <link href="https://jpmessaging.github.io/blog/About-Terrl-and-Merrl/"/>
    <id>https://jpmessaging.github.io/blog/About-Terrl-and-Merrl/</id>
    <published>2025-12-24T15:00:00.000Z</published>
    <updated>2025-12-24T15:00:00.000Z</updated>
    
    <content type="html"><![CDATA[<p style="background: #66FF99;"><strong>2026 年 1 月 6 日 クラウドホスト型メールボックスの外部受信者数制限 (MERRL) に関する重要な更新:</strong> 現在この制限の実装は<strong>キャンセル</strong>されており、実施されないことになりました。このブログ記事に関しましては記録として残されております。詳細については、<a href= https://techcommunity.microsoft.com/blog/exchange/exchange-online-canceling-the-mailbox-external-recipient-rate-limit/4483498>Exchange Online canceling the Mailbox External Recipient Rate Limit</a> (日本語翻訳版は<a href= https://jpmessaging.github.io/blog/exchange-online-canceling-the-mailbox-external-recipient-rate-limit/>こちら</a>) をご覧ください。</p><p>こんにちは。日本マイクロソフト Exchange &amp; Outlook サポート チームの山﨑です。<br>2025年4月より、Exchange Online における送信制限の仕組みが大きくアップデートしました。<br>これまで主に「1 メールボックスあたりの送信制限 RRL（Recipient Rate Limit）」が中心でしたが、新たに以下の 2 つの制限が導入されました。<br>下記のリンクでは、それぞれの制限についてより詳細をまとめているので、ぜひ下記のリンクのブログもご参照ください。</p><ul><li><a href="https://jpmessaging.github.io/blog/introducing-exchange-online-tenant-outbound-email-limits/">TERRL  (Tenant External Recipient Rate Limit)</a>: テナント単位の組織外宛てメッセージの受信者数の制限</li><li><a href="https://jpmessaging.github.io/blog/exchange-online-to-introduce-external-recipient-rate-limit/">MERRL (Mailbox External Recipient Rate Limit)</a>: メールボックス単位の組織外宛てメッセージの受信者数の制限</li></ul><p>本記事では、上記の TERRL と MERRL の違いと背景、既存の制限について解説します。</p><h2 id="目次"><a href="#目次" class="headerlink" title="目次"></a>目次</h2><p><a href="#1-%E3%81%9D%E3%82%82%E3%81%9D%E3%82%82%E3%81%AA%E3%81%9C%E6%96%B0%E3%81%97%E3%81%84%E5%88%B6%E9%99%90%E3%81%8C%E5%BF%85%E8%A6%81%E3%81%AA%E3%81%AE%E3%81%8B%EF%BC%9F">1. そもそもなぜ新しい制限が必要なのか？</a><br><a href="#2-TERRL-%E3%81%A8-MERRL-%E3%81%AE%E9%81%95%E3%81%84">2. TERRL と MERRL の違い</a><br><a href="#3-Exchange-Online-%E3%81%AE%E6%97%A2%E5%AD%98%E3%81%AE%E5%88%B6%E9%99%90%E3%81%AB%E5%A4%89%E5%8C%96%E3%81%AF%E3%81%82%E3%82%8B%EF%BC%9F">3. Exchange Online の既存の制限に変化はある？</a><br><a href="#4-%E3%81%BE%E3%81%A8%E3%82%81">4. まとめ</a>  </p><h2 id="1-そもそもなぜ新しい制限が必要なのか？"><a href="#1-そもそもなぜ新しい制限が必要なのか？" class="headerlink" title="1. そもそもなぜ新しい制限が必要なのか？"></a>1. そもそもなぜ新しい制限が必要なのか？</h2><p>Exchange Online はクラウドサービスである以上、すべてのテナントが公平にリソースを利用できるよう、スパムや誤送信、悪意ある利用を防ぐための制限が設けられています。<br>従来は RRL が主な制限でしたが、これではテナント全体での送信量をコントロールするには不十分でした。<br>そこで導入されたのが、テナント単位での送信制限「TERRL」です。一方でメールボックス単位での送信制限は「MERRL」と呼ばれます。</p><h2 id="2-TERRL-と-MERRL-の違い"><a href="#2-TERRL-と-MERRL-の違い" class="headerlink" title="2. TERRL と MERRL の違い"></a>2. TERRL と MERRL の違い</h2><p>それぞれの違いについて以下の表に簡単にまとめます。</p><table><thead><tr><th>項目</th><th>TERRL</th><th>MERRL</th></tr></thead><tbody><tr><td>名称</td><td>Tenant External Recipient Rate Limit</td><td>Mailbox External Recipient Rate Limit</td></tr><tr><td>単位</td><td>テナント単位</td><td>メールボックス単位</td></tr><tr><td>対象</td><td>組織外宛てメッセージの受信者数</td><td>組織外宛てメッセージの受信者数</td></tr><tr><td>制限方式</td><td>ライセンス数に応じたテナント全体の上限</td><td>1 メールボックスあたり最大 2,000 件&#x2F;日</td></tr><tr><td>目的</td><td>テナント全体の送信量制御とリソース保護</td><td>個別ユーザーの濫用防止</td></tr></tbody></table><p>それぞれの展開スケジュールや詳細については、冒頭のブログにまとめていますので、ぜひご確認ください。</p><h2 id="3-Exchange-Online-の既存の制限に変化はある？"><a href="#3-Exchange-Online-の既存の制限に変化はある？" class="headerlink" title="3. Exchange Online の既存の制限に変化はある？"></a>3. Exchange Online の既存の制限に変化はある？</h2><p>Exchange Online において元々適用されていた送信制限 RRL は、そのまま適用されます。<br>こちらに関して動作に変わりはありませんが、1 メールボックスから送信されるメッセージの受信者数が 24 時間あたりに 10,000 を上回ってしまうとメッセージの送信が制限されます。<br>また TERRL や MERRL とは異なり、組織内の受信者も組織外の受信者もどちらもカウントされますのでご注意ください。<br><a href="https://learn.microsoft.com/ja-jp/office365/servicedescriptions/exchange-online-service-description/exchange-online-limits#sending-limits-1">公開情報</a>では例も含めてご案内しておりますため、気になる点があればご確認ください。</p><h2 id="4-まとめ"><a href="#4-まとめ" class="headerlink" title="4. まとめ"></a>4. まとめ</h2><p>このブログでは、MERRL と TERRL の違いについてまとめました。<br>名前は似ていますが、MERRL と TERRL で注意すべきメッセージ数が異なる (テナント全体での制限なのか、メールボックス単位での制限なのか) ため、ご注意ください。<br>また TERRL に関しては展開が一時停止している状況でもあるため、今後のアップデートをお待ちいただけますと幸いです。<br>今後のアップデートも含め、より各制限の詳細を知りたい方はぜひ冒頭のブログもご参照ください。      </p><p>本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。</p>]]></content>
    
    
      
      
    <summary type="html">&lt;p style=&quot;background: #66FF99;&quot;&gt;&lt;strong&gt;2026 年 1 月 6 日 クラウドホスト型メールボックスの外部受信者数制限 (MERRL) に関する重要な更新:&lt;/strong&gt; 現在この制限の実装は&lt;strong&gt;キャンセル&lt;/strong&gt;</summary>
      
    
    
    
    
    <category term="Exchange Online" scheme="https://jpmessaging.github.io/blog/tags/Exchange-Online/"/>
    
  </entry>
  
</feed>
