OutlookのAdmin-Controlled Migrationポリシーとは？新しいOutlook移行の変更点と管理者の確認ポイント

Outlookの「Policy for Admin-Controlled Migration to new Outlook for Windows」は、管理者が従来のOutlook for Windowsから新しいOutlook for Windowsへの移行を段階的に促すためのポリシーです。結論から言うと、これはユーザー任せの切り替えを待つのではなく、組織側で移行タイミング・再通知間隔・戻し可否を制御するための仕組みです。

特に確認すべきなのは、DoNewOutlookAutoMigration、NewOutlookAutoMigrationRetryIntervals、新しいOutlookのトグル表示、COMアドインの利用状況、オンプレミスExchangeを含む対象外環境です。設定を誤ると、想定より早くユーザーが新しいOutlookへ誘導されたり、逆に移行体験が表示されなかったりするため、全社展開の前にパイロット検証が欠かせません。

Outlookの「Admin-Controlled Migration to New Outlook」とは

「Admin-Controlled Migration to New Outlook」は、組織の管理者がポリシーを使って、従来のOutlook for Windowsのユーザーを新しいOutlook for Windowsへ移行させるための管理機能です。

Microsoftの公式ドキュメントでは、グループポリシー、Microsoft 365向けCloud Policy、またはレジストリ値を使って、組織内ユーザーを新しいOutlook for Windowsへアップグレードできると説明されています。(Microsoft Learn)

このポリシーは、単に「新しいOutlookを使えるようにする」設定ではありません。管理者が移行を開始すると、ユーザーには複数段階の案内が表示され、最終的には新しいOutlookの利用が促されます。

従来のOutlookから新しいOutlookへの移行は、今後のOutlook運用に関わる大きな変更です。メール、予定表、アドイン、PST、オフライン利用、業務アプリ連携などに影響する可能性があるため、管理者は「いつ有効化するか」だけでなく、「誰に、どの順番で、どの設定で展開するか」まで決めておく必要があります。

何が変わるのか

今回のポイントは、管理者が新しいOutlookへの移行をより計画的に進められることです。

従来は、ユーザーが画面右上の「新しいOutlookを試す」トグルを自分で操作し、任意のタイミングで新しいOutlookを試す流れが中心でした。Admin-Controlled Migrationを使うと、管理者がポリシーを有効化することで、ユーザーに対して新しいOutlookへの移行体験を段階的に表示できます。

Microsoftは、新しいOutlookへの移行段階を「Opt-in」「Opt-out」「Cutover」の3段階で説明しており、Opt-out段階では新しいOutlookが既定で有効になり、ユーザーは必要に応じて従来のOutlookへ戻せるとしています。Cutover段階では、ユーザーが従来のOutlookへ戻せなくなる予定です。(Microsoft Learn)

管理者にとって重要なのは、次の3点です。

変更点	管理者が見るべきポイント
移行をポリシーで開始できる	対象ユーザー、適用グループ、開始時期を決める
ユーザーに段階的な案内が表示される	ヘルプデスク問い合わせ増加に備える
戻したユーザーに再度移行を促せる	再通知間隔を慎重に設定する
Cloud Policy、GPO、レジストリで制御できる	管理方式を組織の端末管理方針に合わせる
新しいOutlook非対応環境がある	オンプレミスExchange、COMアドイン、業務フローを事前確認する

特に大企業では、全社員に一斉適用するよりも、部門・拠点・業務種別ごとに段階展開するほうが安全です。

対象となる主な環境

Admin-Controlled Migrationの対象は、基本的に従来のOutlook for Windowsを利用しているMicrosoft 365環境のユーザーです。

ただし、すべてのOutlook利用者が同じように対象になるわけではありません。新しいOutlookのサポート状況、ライセンス、メールボックスの場所、管理ポリシーによって挙動が変わります。

Microsoftの公式ドキュメントでは、新しいOutlookはオンプレミス環境ではサポートされないため、Microsoft 365ユーザーのみを対象にする必要があると明記されています。また、ソブリンクラウドでは利用できないため、その環境ではポリシーを有効化しないよう注意が示されています。(Microsoft Learn)

対象にしやすいユーザー

次のようなユーザーは、比較的早い段階でパイロット対象にしやすいです。

ユーザー分類	理由
Exchange Onlineを利用している一般ユーザー	新しいOutlookの主な対象になりやすい
標準的なメール・予定表利用が中心のユーザー	業務影響を検証しやすい
Webアドイン中心のユーザー	COMアドイン依存が少ない
IT部門・情報システム部門	トラブルや差分を早期に把握できる
新機能に前向きな部門	ユーザー教育の成功例を作りやすい

慎重に扱うべきユーザー

一方で、次のユーザーは一括移行の前に個別確認が必要です。

ユーザー分類	注意点
COMアドインを使っているユーザー	新しいOutlookではCOMアドインがサポートされない
オンプレミスExchangeメールボックス利用者	新しいOutlookの対象外となる可能性がある
共有メールボックスや代理アクセスを多用する部門	権限・運用手順の検証が必要
PSTファイルを日常的に使うユーザー	機能差や制約を事前確認する
業務システムとOutlookを連携している部門	アドイン、メールテンプレート、送信処理の確認が必要
ヘルプデスク、営業、法務、経理などメール依存度が高い部門	業務停止リスクが高いため段階展開が望ましい

特にCOMアドインは、移行判断の大きな分岐点です。Microsoftは、新しいOutlook for WindowsではWebアドインがサポートされる一方、COMアドインはサポートされないと説明しています。COMアドインを利用している組織は、Microsoft 365 Apps admin centerのInventoryなどで利用状況を確認し、Webアドインや標準機能への置き換えを検討する必要があります。(Microsoft Learn)

ユーザーにはどのように表示されるのか

Admin-Controlled Migrationを有効にすると、ユーザーは従来のOutlookから新しいOutlookへ段階的に誘導されます。

Microsoftの説明では、ポリシーを有効にした場合、ユーザーは3つのアプリセッション、つまりOutlook起動ごとの段階を通じて移行体験を受けます。新しいOutlookが未インストールの場合は、従来のOutlookの次回起動時にバックグラウンドで新しいOutlookアプリがインストールされます。(Microsoft Learn)

移行体験の流れ

段階	ユーザーに起きること	管理者が注意すべきこと
Step 1	新しいOutlookを試すよう促す案内が表示される	ユーザーは「今はしない」を選べる
Step 2	組織が新しいOutlookの利用を推奨している旨のメッセージが表示される	次回起動時にさらに強い案内へ進む
Step 3	新しいOutlookへの切り替えを促すプロンプトが表示される	閉じた場合でも次回起動時に新しいOutlookへ誘導される

ここで重要なのは、ユーザーがすぐに完全移行を強制されるわけではなく、まず案内・推奨・切り替え促進という段階を踏む点です。

ただし、管理者が再試行間隔を短く設定した場合、ユーザーにとっては「毎回Outlookを開くたびに表示される」と感じられる可能性があります。全社展開前には、案内文面、FAQ、戻し方、問い合わせ窓口を用意しておきましょう。

設定の中心は2つのポリシー

Admin-Controlled Migrationで必ず確認すべき中心的な設定は、次の2つです。

設定名	役割
DoNewOutlookAutoMigration	新しいOutlookへの管理者制御移行を有効化・無効化する
NewOutlookAutoMigrationRetryIntervals	ユーザーが従来のOutlookへ戻した後、再度移行を促す間隔を指定する

この2つを混同すると、想定と異なる展開になります。

たとえば、DoNewOutlookAutoMigrationを有効にしても、再試行間隔を設定しなければ、基本的には移行は一度だけ実行されます。一方、NewOutlookAutoMigrationRetryIntervalsを1に設定すると、従来のOutlookを起動するたびに移行が再試行されるため、かなり強い運用になります。

DoNewOutlookAutoMigrationの意味と設定値

DoNewOutlookAutoMigrationは、Admin-Controlled Migrationの本体となる設定です。

値	意味	実務上の使いどころ
1	新しいOutlookへの移行を有効化	パイロット展開、本番展開
0	新しいOutlookへの移行を無効化	移行を止めたい場合、準備不足の部門を除外する場合
キー削除	ポリシーが無効化され、移行が停止	一時的な解除より管理しづらいため注意

Microsoftの公式情報では、このポリシーを有効化すると移行フローが開始され、無効化すると関連する移行体験の表示が止まるとされています。また、いったん無効化またはレジストリキーを削除した後に再度有効化すると、移行はStep 1から再開されます。(Microsoft Learn)

レジストリで設定する場合の代表的なパスは次のとおりです。

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Options\General]
"DoNewOutlookAutoMigration"=dword:00000001

無効化する場合は次のように設定します。

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Options\General]
"DoNewOutlookAutoMigration"=dword:00000000

ユーザーによる変更を防ぎたい場合は、通常のユーザー設定キーではなく、ポリシー配下のキーを使う運用も検討します。

HKEY_CURRENT_USER\SOFTWARE\Policies\Microsoft\Office\16.0\Outlook\Options\General

レジストリを直接配布する運用は手軽ですが、端末ごとの状態差が出やすくなります。Microsoft 365 Apps admin centerのCloud PolicyやIntuneを使える環境では、グループ単位で対象を制御するほうが管理しやすいです。

NewOutlookAutoMigrationRetryIntervalsの意味と設定値

NewOutlookAutoMigrationRetryIntervalsは、ユーザーが新しいOutlookから従来のOutlookへ戻した後、どのタイミングで再び新しいOutlookへの移行を促すかを指定する設定です。

値	意味	おすすめ度
0 または未設定	再移行を行わない	初回パイロットや慎重な展開に向く
1	従来のOutlook起動のたびに再試行	強制に近い運用。全社適用は慎重に
2〜99000	指定日数後に再度Step 1から移行を促す	段階展開に使いやすい

Microsoftの説明では、このポリシーはAdmin-Controlled Migrationのポリシーが有効である場合にのみ尊重されます。つまり、NewOutlookAutoMigrationRetryIntervalsだけを設定しても、DoNewOutlookAutoMigrationが有効でなければ意図した動作になりません。(Microsoft Learn)

たとえば、30日ごとに再度新しいOutlookを試してもらいたい場合は、次のような考え方になります。

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Options\General]
"NewOutlookAutoMigrationRetryIntervals"=dword:0000001e

0000001eは16進数で30を表します。

管理者が失敗しやすいのは、「強く移行を進めたい」という理由だけで1を設定するケースです。毎回表示される案内は、ユーザーにとって業務妨害に感じられることがあります。特にヘルプデスク負荷や反発を避けたい場合は、まず30日、60日、90日などの間隔で検証するほうが現実的です。

Cloud Policy、グループポリシー、レジストリのどれを使うべきか

Admin-Controlled Migrationは、主に次の方法で管理できます。

管理方法	向いている環境	メリット	注意点
Cloud Policy	Microsoft 365 Appsをクラウド中心で管理している組織	ユーザー単位・グループ単位で制御しやすい	Microsoft 365 Apps admin centerの運用理解が必要
グループポリシー	Active Directory参加端末が多い組織	既存GPO運用に組み込みやすい	リモート端末やEntra ID参加端末では適用設計が必要
Intune	クラウド管理・モダン管理を進めている組織	デバイス・ユーザーグループ単位で展開しやすい	ポリシー競合や適用タイミングの確認が必要
レジストリ	小規模検証、緊急停止、個別端末対応	すぐ試せる	管理が属人化しやすく、監査しにくい

実務では、次のように使い分けると安全です。

まず、IT部門の検証端末ではレジストリで挙動を確認します。次に、パイロットユーザーにはCloud PolicyまたはIntuneで配布します。問題がなければ、部門単位で対象グループを広げます。

いきなり全社GPOで有効化する運用は避けたほうが無難です。新しいOutlookでは、従来のOutlookと異なる点があるため、メール送受信だけでなく、予定表、共有メールボックス、代理送信、アドイン、PST、印刷、検索、通知など、日常業務の細部まで確認する必要があります。

新しいOutlookのトグル表示も確認が必要

Admin-Controlled Migrationを有効にする前に、必ず確認したいのが「新しいOutlookを試す」トグルの状態です。

Microsoftの公式情報では、移行ポリシーを有効にする前提条件として、新しいOutlookのトグルをユーザーに表示可能にしておく必要があると説明されています。トグルが非表示の場合、ユーザーには移行体験が表示されません。(Microsoft Learn)

つまり、次のような状態では、移行ポリシーを有効にしても想定どおりに進まない可能性があります。

状態	起きる可能性があること
新しいOutlookのトグルを非表示にしている	移行体験が表示されない
新しいOutlook自体へのアクセスを制限している	ユーザーが新しいOutlookを起動できない
端末に必要な前提条件が不足している	インストールや起動に失敗する
ユーザーが対象外ライセンス・対象外環境	移行対象にならない可能性がある

「移行を止める設定」と「トグルを隠す設定」と「新しいOutlookの利用自体を禁止する設定」は、それぞれ意味が違います。

移行だけ止めたいのか、新しいOutlookを一切使わせたくないのか、ユーザーに任意で試させたいのかを整理してから設定しましょう。

新しいOutlookの展開前に確認すべき前提条件

新しいOutlookを組織展開する前に、端末側の前提条件も確認が必要です。

Microsoftの展開ドキュメントでは、新しいOutlook for WindowsのインストーラーはMicrosoft StoreまたはOffice CDNから利用できると説明されています。また、対象コンピューターの前提条件として、Outlook on the webが対象メールボックスで有効であること、WindowsやWebView2などの要件を満たすことが示されています。(Microsoft Learn)

代表的な確認項目は次のとおりです。

確認項目	見るべきポイント
Windowsバージョン	新しいOutlookの要件を満たすか
WebView2	最新状態に近いか、更新がブロックされていないか
Outlook on the web	対象メールボックスで有効か
Microsoft Store制限	Store禁止環境ではOffice CDNやIntune展開を検討
既存のOffice更新チャネル	Current Channel、Monthly Enterprise Channelなどの差を確認
ネットワーク	*.office.netなどMicrosoft 365 CDNへの通信が許可されているか
端末管理	Intune、GPO、構成管理ツールのどれで配布するか

新しいOutlookは、従来のOutlookと同じ更新モデルではありません。Microsoftの移行計画ドキュメントでは、新しいOutlookアプリは自動的に更新され、ビルド更新が毎週出荷されると説明されています。安定した更新配信のため、Microsoft 365 CDNへのアクセス許可も確認が必要です。(Microsoft Learn)

開発者・アドイン担当者が確認すべきポイント

開発者や業務アプリ担当者にとって、最大の確認ポイントはアドインです。

新しいOutlookではWebアドインが中心になります。従来のOutlookで使われてきたCOMアドインは、新しいOutlook for Windowsではサポートされません。これは、Outlookと業務システムを深く連携させている企業にとって大きな影響があります。

たとえば、次のような用途でCOMアドインを使っている場合は要注意です。

COMアドインの用途	確認すべき代替策
CRM連携	ベンダー提供のWebアドイン、Graph API連携
電子署名・承認	Webアドイン版の有無
メール誤送信防止	Microsoft Purview、DLP、Webアドイン
添付ファイル暗号化	セキュリティ製品の新Outlook対応状況
名刺管理・顧客管理	SaaS側のOutlook Webアドイン対応
会議アドイン	Teamsネイティブ機能やWebアドイン
アーカイブ・監査	Exchange Online、Microsoft Purview、ベンダー対応

Microsoftは、COMアドインからWebアドインへの移行について、まずインストール済みCOM/VSTOアドインをInventoryで確認し、重要なCOMアドインを特定し、Webアドインや標準機能で代替できるか評価する流れを示しています。(Microsoft Learn)

社内開発のCOMアドインがある場合は、単純な再コンパイルでは対応できない可能性があります。Outlook JavaScript API、Microsoft Graph API、Office Add-insの権限設計を含めて、設計から見直す必要があります。

機能差を確認しないまま移行すると失敗しやすい

新しいOutlookは継続的に改善されていますが、従来のOutlookと完全に同じではありません。

Microsoftの機能比較ページでは、新しいOutlookと従来のOutlookの機能差を一覧で確認できます。たとえば、オフラインサポートやPSTサポートなどは、従来のOutlookと新しいOutlookで提供状況が異なる項目として扱われています。(Microsoft サポート)

移行前には、少なくとも次の業務シナリオを確認しましょう。

業務シナリオ	確認内容
メール送受信	署名、テンプレート、添付、分類、検索
予定表	会議室、代理作成、共有予定表、タイムゾーン
共有メールボックス	表示、送信、代理送信、権限反映
アーカイブ	オンラインアーカイブ、PST、保持ポリシー
セキュリティ	DLP、秘密度ラベル、迷惑メール報告
アドイン	COMアドイン、Webアドイン、業務システム連携
オフライン利用	ネットワーク断時の業務継続
ヘルプデスク	よくある問い合わせ、戻し方、障害時対応

特に現場で問題になりやすいのは、「メールは送れるが、細かな業務手順が変わる」ケースです。たとえば、添付ファイルの扱い、予定表の見え方、検索結果、共有メールボックスの操作手順などは、ユーザーにとって生産性に直結します。

管理者向けの移行ステップ

実務では、次の順番で進めると安全です。

ステップ	作業内容	完了条件
現状把握	Outlook利用状況、ライセンス、メールボックス、アドインを棚卸し	対象外ユーザーと要注意ユーザーが分かる
機能差確認	Microsoftの機能比較表と社内業務を照合	代替策が必要な業務が分かる
パイロット設計	IT部門、代表部門、アドイン利用部門を選定	小さく試せる対象グループができる
ポリシー設計	DoNewOutlookAutoMigrationと再試行間隔を決める	強制度合いが明確になる
展開方法決定	Cloud Policy、Intune、GPO、レジストリを選ぶ	管理方法が一本化される
ユーザー周知	変更点、戻し方、問い合わせ先を案内	ユーザーが混乱しにくい
パイロット展開	限定ユーザーに適用	問題点と問い合わせ傾向を把握
本番展開	部門・拠点単位で段階展開	大きな業務停止なく移行できる
利用状況確認	フィードバック、利用率、問い合わせを確認	次の展開判断ができる

Microsoftも、移行準備としてステークホルダーへの確認、テスト範囲の定義、準備計画の開始を推奨しています。(Microsoft Learn)

推奨される設定パターン

管理者が迷いやすいのは、「どの程度強く移行を促すか」です。組織の準備状況に応じて、次のように考えると判断しやすくなります。

目的	DoNewOutlookAutoMigration	NewOutlookAutoMigrationRetryIntervals	向いているケース
まず一度だけ試させる	1	未設定または0	初回パイロット
定期的に再試行する	1	30や60	段階移行を進めたい
毎回強く促す	1	1	移行方針が確定し、戻しを最小化したい
移行を止める	0	任意	準備不足、障害発生、対象外部門
新しいOutlookに固定する	1	1に加えて戻しトグル制御	十分な検証後の統制環境

初期段階では、DoNewOutlookAutoMigration=1、NewOutlookAutoMigrationRetryIntervalsは未設定または0から始めるのが現実的です。

いきなり毎回再試行する設定にすると、ユーザーの不満や問い合わせが増えやすくなります。新しいOutlookへの移行は、技術的な切り替えであると同時に、ユーザー体験の変更でもあります。

戻しトグルを非表示にする場合の注意点

新しいOutlookへ移行した後、ユーザーが従来のOutlookへ戻せる状態を残すかどうかも重要です。

Microsoftの公式情報では、HideClassicOutlookToggleOutポリシーを使うことで、新しいOutlook内の従来のOutlookへ戻すトグルを非表示にできると説明されています。この設定はExchange PowerShellからメールボックスポリシーとして構成します。(Microsoft Learn)

例として、既定のOWAメールボックスポリシーに対して有効化する場合は次のようなコマンドが示されています。

Set-OwaMailboxPolicy -Identity OwaMailboxPolicy-Default -HideClassicOutlookToggleOut $true

無効化する場合は次のように設定します。

Set-OwaMailboxPolicy -Identity OwaMailboxPolicy-Default -HideClassicOutlookToggleOut $false

ただし、戻しトグルを非表示にするのは、かなり強い統制です。次の条件を満たしてから実施するべきです。

判断基準	確認内容
主要業務が新しいOutlookで完結する	メール、予定表、共有メールボックス、アドインを検証済み
ヘルプデスクが対応できる	戻せない前提の問い合わせ対応手順がある
例外ユーザーの扱いが決まっている	役員、法務、経理、特殊業務部門など
障害時の回避策がある	Web版Outlook、別端末、例外ポリシーなど
ユーザー周知が完了している	変更日、影響、問い合わせ先が明確

戻せない状態にしてから問題が見つかると、業務影響が大きくなります。まずは戻せる状態で展開し、十分に安定してから制御を強めるのが安全です。

利用状況とフィードバックの確認

移行は、ポリシーを配布して終わりではありません。ユーザーが実際に新しいOutlookを使っているか、どこで困っているかを確認する必要があります。

Microsoftの公式情報では、新しいOutlookの利用状況について、Exchange使用状況レポートに含める作業が進むまでは、Microsoft 365管理センターのレポートを使って概算の利用状況を確認する方法が案内されています。また、組織内フィードバックはMicrosoft 365管理センターのHealthからProduct Feedbackを開き、New Outlook for Windowsでフィルターして確認できると説明されています。(Microsoft Learn)

ただし、フィードバックには偏りがあります。新しいOutlookから従来のOutlookへ戻すユーザーは、その過程でフィードバックを求められるため、不満のあるユーザーの声が目立ちやすい点にも注意が必要です。

見るべき指標は、単なる「不満の数」ではありません。

見るべき指標	判断のポイント
新しいOutlookの継続利用率	一度使った後に戻していないか
従来のOutlookへの戻し率	部門・職種ごとの差を見る
問い合わせ内容	操作不明、機能不足、障害を分ける
アドイン関連の問題	特定ベンダーや社内アプリに偏っていないか
業務影響	メール送信遅延、予定表運用、承認処理への影響
教育効果	FAQや動画で解決できているか

問い合わせが多いから移行失敗とは限りません。操作変更に伴う一時的な問い合わせなのか、機能不足による業務継続リスクなのかを分けて判断しましょう。

よくある失敗と回避策

Admin-Controlled Migrationで失敗しやすいポイントを整理します。

失敗例	原因	回避策
ポリシーを有効にしたのに移行体験が出ない	トグル非表示、対象外環境、適用遅延	トグル設定、対象ユーザー、ポリシー適用状況を確認
ユーザーから「勝手に変わった」と問い合わせが増える	事前周知不足	展開前に変更日、戻し方、FAQを案内
重要アドインが使えない	COMアドイン依存を見落とした	Inventoryで棚卸しし、Webアドインや代替策を検証
毎回プロンプトが出て不満が増える	再試行間隔を短くしすぎた	初期は0、30、60日などで段階調整
一部部門だけ業務が止まる	部門固有のOutlook運用を把握していない	パイロット対象に高依存部門を含める
戻しトグルを消してから問題が判明	強制移行が早すぎた	戻せる状態で十分に検証してから制御を強める
レジストリとCloud Policyが競合する	複数管理経路で設定している	管理元を一本化し、優先順位を文書化する

特に多いのは、「メールが使えれば問題ない」と考えてしまうことです。Outlookは単なるメールソフトではなく、会議、承認、顧客対応、監査、セキュリティ運用の入口になっている場合があります。移行前には、部門別の使い方を必ず確認してください。

管理者が今すぐ確認すべきチェックリスト

展開前に、次の項目を確認しておきましょう。

チェック項目	確認済み
Exchange Online利用者とオンプレミスExchange利用者を区別した
新しいOutlookの対象ユーザーと除外ユーザーを決めた
COMアドイン、VSTOアドイン、業務アドインを棚卸しした
Webアドインや標準機能で代替できるか確認した
PST、共有メールボックス、代理送信、予定表運用を検証した
新しいOutlookのトグル表示ポリシーを確認した
DoNewOutlookAutoMigrationの設定方針を決めた
NewOutlookAutoMigrationRetryIntervalsの値を決めた
Cloud Policy、Intune、GPO、レジストリの管理方法を決めた
パイロット対象グループを作成した
ユーザー向けFAQと戻し手順を準備した
ヘルプデスク向けの切り分け手順を準備した
利用状況とフィードバックの確認方法を決めた
問題発生時に移行を停止する手順を用意した

このチェックリストで空欄が多い場合は、まだ全社展開には早い状態です。まずはIT部門や一部部門での検証から始めるのが安全です。

まとめ：移行ポリシーは「有効化」より「設計」が重要

Policy for Admin-Controlled Migration to new Outlook for Windowsは、従来のOutlookから新しいOutlookへの移行を管理者主導で進めるための重要なポリシーです。

確認すべき要点は、次のとおりです。

要点	実務での判断
DoNewOutlookAutoMigration	移行を開始するか止めるかを決める
NewOutlookAutoMigrationRetryIntervals	戻したユーザーへ再度促す間隔を決める
新しいOutlookトグル	非表示だと移行体験が出ない可能性がある
COMアドイン	新しいOutlookではサポートされないため代替策が必要
対象外環境	オンプレミスExchangeやソブリンクラウドは注意
戻し可否	いきなり戻せない状態にしない
展開方法	Cloud Policy、Intune、GPOのいずれかに管理を寄せる
ユーザー教育	FAQ、戻し手順、問い合わせ先を先に用意する

次に取るべき行動は、ポリシーをすぐ有効化することではありません。まず、対象ユーザー、アドイン、業務フロー、トグル設定、再試行間隔を棚卸しし、パイロット展開の設計を行いましょう。

新しいOutlookへの移行は避けて通れないテーマになりつつありますが、管理者が段階的に制御すれば、ユーザーの混乱を抑えながら移行できます。重要なのは、移行を「いつ始めるか」ではなく、「どのユーザーに、どの強さで、どの順番で進めるか」を決めることです。