新しいOutlook for Windows移行完全ガイド：PST・共有メールボックス・アドイン対応【2026年版】

更新日：2026年6月8日

「新しいOutlook for Windows（New Outlook）」への移行とは、Microsoftが2024年以降に段階的に展開している、Web技術（Monarchプロジェクト）ベースの新クライアントへ従来のMSI/Win32版Outlookから切り替える作業のことです。2026年に入り、Microsoftは多くの組織に対して「クラシックOutlook」の延長サポートスケジュールを通知しており、ヘルプデスクには「共有メールボックスが表示されない」「PSTファイルが開けない」「アドインが動かない」といった問い合わせが急増しています。正直なところ、私が前職で約3,000台のキッティングを担当した際にも、ここに挙げた3つはほぼ毎週出ていました。本ガイドでは、新しいOutlook for Windowsへの移行で発生する典型的なトラブルと、Intune／グループポリシー／PowerShellを使った実践的な対処手順を、2026年6月時点の最新仕様にあわせてまとめます。

新しいOutlookとクラシックOutlookの違いは？

新しいOutlook for Windowsは、Outlook on the web（OWA）と同じWebレンダリングエンジン（WebView2 + Monarch）を採用しており、クラシックOutlook（Win32版、MSI/Click-to-Run）とはアーキテクチャが根本的に異なります。クラシックOutlookがMAPIプロファイルとローカルOSTキャッシュを使うのに対し、新Outlookは原則としてMicrosoft 365クラウド上のメールボックスを直接参照し、ローカルキャッシュは限定的（オフラインモードでも数十日〜90日が上限）です。この設計変更により、Copilot for Outlookの応答速度や、複数アカウントの同時表示、Loopコンポーネントの統合などが改善された一方、長年クラシックOutlookに依存してきた運用では「あれが動かない」が大量に発生します。

2026年6月時点で、新OutlookはMicrosoft Learnの公式ロードマップに従い、エクスチェンジ・オンプレミス専用テナント、サードパーティIMAP、PSTのライブ参照といった残された機能ギャップを順次解消しています。ヘルプデスク側としては、「現状の機能差マップ」を社内Wikiにまとめておいて、利用部門と合意したうえで段階移行する運用が現実的だと思います。

移行計画とロールアウト戦略

移行を成功させる鍵は、「全社一斉切替」を避け、業務影響の小さい部門から段階的に切り替えることです。具体的には、(1)ヘルプデスク自部門でドッグフーディング、(2)情報システム部門と一部リテラシーの高い部署でパイロット（30〜50ユーザー）、(3)バックオフィス、(4)営業・サポート、(5)経営層の順で展開するパターンが標準的です。

各フェーズで「アドイン互換性」「共有メールボックス」「会議室予約」「定型文／署名」「PST資産」の5項目をチェックリスト化し、未解決のブロッカーがあればフェーズを進めない、という判断が大事です。私の経験上、ここを甘くすると後段の経営層フェーズで一気に問い合わせが噴き出します。

切替方法は3通りあります。ユーザー自身がクラシックOutlook右上のトグルで切り替える方式は段階移行に向きますが、運用統制が効きません。Intuneやグループポリシーで一括強制する方式は統制が効く一方、未準備の部門からの突発的問い合わせを招きます。一番おすすめなのは、Microsoft 365管理センターの「新しいOutlook管理ポリシー」で対象セキュリティグループ単位に既定切替を行い、ロールバック可能な設定で運用する折衷案です。詳細な手順は当サイトのOutlookが起動しない・フリーズする原因と対処法でも触れている診断の流れと合わせて、移行前ベースラインの取得をお勧めします。

PSTファイルが開けない・インポートできない

新しいOutlookではPSTファイルを「データファイルとして追加」する機能がなく、クラシックOutlookでPST内に保存していたメール・予定表・連絡先は、メニューの「設定 → 全般 → インポート」からPSTを選択してオンラインメールボックス（プライマリまたはOnline Archive）に取り込む必要があります。インポート中はPSTファイルが他プロセスから開かれていないこと、ファイルサイズが50GB未満であることが前提です。50GBを超えるPSTは事前に scanpst.exe による整合性チェックと、MicrosoftのPSTファイル分割ガイダンスを参照して分割してください。

大量のユーザーに対して一括処理を行う場合は、Microsoft 365コンプライアンスセンターの「インポートサービス」を使い、AzCopy経由でPSTをAzureストレージにアップロードしてからメールボックスへ取り込みます。以下はAzCopyで100ユーザー分のPSTを社内ファイルサーバーからアップロードする例です。

# AzCopyでPSTをAzureストレージにアップロード（Microsoft 365インポートサービス）
$sasUrl = "https://3c3e01ab98f7400b9a04e9.blob.core.windows.net/ingestiondata?sv=..."
$srcDir = "\\fileserver01\PST_Archive"

azcopy.exe copy "$srcDir\*.pst" "$sasUrl" `
  --recursive=true `
  --log-level=INFO `
  --put-md5

# アップロード後、PST Import Mapping File (CSV) を作成
# Workload,FilePath,Name,Mailbox,IsArchive,TargetRootFolder,SPFileContainer,SPManifestContainer,SPSiteUrl
# Exchange,,user01.pst,user01@contoso.com,FALSE,/ImportedPST,,,

共有メールボックスが表示されない

クラシックOutlookでは、ユーザーに「フルアクセス」権限が付与されると自動マッピング機能により共有メールボックスがプロファイルに自動追加されていました。新Outlookでも2026年4月のアップデート以降、自動マッピングはサポートされていますが、初期表示までに数分から数時間のタイムラグが発生することがあります。すぐに表示させたい場合は、左ペインを右クリックし「共有メールボックスを追加」から手動でアドレスを入力します。

表示されない場合の典型的な原因は次の3つです。第1に、フルアクセス権限が AutoMapping false で付与されているケース。第2に、テナントの認証方法ポリシーでパスワード認証のみが許可され、新Outlookに必要なModern Authenticationトークンが取得できないケース。第3に、共有メールボックスのライセンスが付与されておらず、メールボックスサイズが50GBを超えてしまっているケースです。PowerShellで自動マッピングの状態を確認・修正するには、次のスクリプトが有効です。

# 共有メールボックスへの権限と自動マッピング状態を確認
Connect-ExchangeOnline -UserPrincipalName admin@contoso.com

# 対象共有メールボックスの権限を一覧表示
Get-MailboxPermission -Identity "support@contoso.com" |
  Where-Object { $_.IsInherited -eq $false -and $_.User -notlike "NT AUTHORITY*" } |
  Select-Object User, AccessRights, IsInherited

# 自動マッピングを有効化して再付与（既存権限はいったん削除）
Remove-MailboxPermission -Identity "support@contoso.com" `
  -User "tanaka@contoso.com" -AccessRights FullAccess -Confirm:$false

Add-MailboxPermission -Identity "support@contoso.com" `
  -User "tanaka@contoso.com" -AccessRights FullAccess `
  -AutoMapping $true -InheritanceType All

権限変更後は、対象ユーザーがいったん新Outlookをサインアウトし、Windowsの資格情報マネージャーから古いOfficeトークンを削除すると、即時反映されます。私自身、ここを飛ばして30分悩んだことがあるので、トークンクリアはルーチンに組み込むのがおすすめです。認証関連で詰まる場合は、ヘルプデスクの定番対策をまとめたMicrosoft Entra ID SSPR完全導入ガイドのトラブルシューティング節も参考にしてください。

アドインが動作しない問題への対処

新しいOutlookはCOMアドイン（DLLベース）を一切サポートしません。サポートされるのは、Office.jsで実装されたWeb Add-ins（マニフェストXML、または新方式のUnified App manifest）のみです。Salesforce、SAP、kintone、CybozuといったメジャーSaaSベンダーは2025〜2026年にかけて新方式のアドインをリリースしていますが、社内開発のCOMアドインや、PDF統合・電子署名・電子帳簿保存法対応の一部ベンダー製品は依然として未対応のものがあります。

移行前にアドイン棚卸しを行う際は、各クライアントにPowerShellでインストール済みアドインを列挙し、ベンダー側のロードマップと突き合わせます。

# インストール済みのOutlook COMアドインを列挙（クラシックOutlook）
$paths = @(
  "HKLM:\Software\Microsoft\Office\Outlook\Addins",
  "HKLM:\Software\Wow6432Node\Microsoft\Office\Outlook\Addins",
  "HKCU:\Software\Microsoft\Office\Outlook\Addins"
)
foreach ($p in $paths) {
  if (Test-Path $p) {
    Get-ChildItem $p | ForEach-Object {
      $props = Get-ItemProperty $_.PSPath
      [PSCustomObject]@{
        Path        = $_.PSChildName
        FriendlyName = $props.FriendlyName
        LoadBehavior = $props.LoadBehavior
        Description  = $props.Description
      }
    }
  }
}

移行できない基幹アドインがある場合は、(1)代替Web Add-inをベンダーに要求、(2)該当ユーザーだけクラシックOutlookに残す例外グループ運用、(3)Power AutomateやGraph APIで業務フローを置き換える、の3つの選択肢を検討します。Microsoft自身もOffice Add-ins開発ガイドで移行パスを公開しているので、社内開発アドインがある組織は早めに着手してください。

Microsoft IntuneとGPOによる中央管理

新Outlookの展開・抑止・既定化は、Microsoft Intuneの「設定カタログ」とMicrosoft 365 Apps管理用ADMXテンプレートで完結します。Intune環境では、デバイス → 構成プロファイル → 新規作成 → Windows 10以降 → 設定カタログ → 「Microsoft Outlook 2016」カテゴリ配下に、新Outlook関連の設定が約20項目用意されています（2026年6月時点）。

主要な設定キーは次のとおりです。NewOutlookMigrationUserSetting（自動移行の挙動：0=ユーザー選択、1=既定で新、2=強制移行）、HideNewOutlookToggle（クラシック側のトグルボタンを非表示）、NewOutlookAutoMigrationRetentionPeriod（クラシックへのロールバック許可期間、日数指定）。グループポリシーで設定する場合は、Microsoftが配布する最新のADMX（office16.admx, outlk16.admx）をPolicyDefinitionsフォルダーに配置し、「ユーザーの構成 → 管理用テンプレート → Microsoft Outlook 2016 → Outlook Options → Other」配下から構成します。詳細はMicrosoftの新Outlook管理ドキュメントに最新値がまとまっています。

# Intuneのレジストリ設定相当（GPOを使わない場合のIntune設定カタログ値）
# パス: HKCU\Software\Policies\Microsoft\Office\16.0\Outlook\Preferences

# 強制的に新Outlookへ移行（ユーザー選択不可）
NewOutlookMigrationUserSetting (DWORD) = 2

# クラシックOutlookのトグルボタンを非表示にしてロールバックを抑止
HideNewOutlookToggle (DWORD) = 1

# 30日間はロールバックを許可（緊急時の保険）
NewOutlookAutoMigrationRetentionPeriod (DWORD) = 30

クラシックOutlookに戻す方法

移行直後に重大な業務影響が出た場合、新Outlookの左上の「新しいOutlookを試す」トグルをオフにすることでクラシックOutlookに即座に戻せます。ただし、Intuneや管理者ポリシーで HideNewOutlookToggle が1に設定されている場合、ユーザー側でのロールバックはできません。この場合はヘルプデスク経由で次のいずれかを実施します。

1. Intuneの構成プロファイルで NewOutlookMigrationUserSetting を0に変更し、対象ユーザーの再サインインを待つ（10〜30分）。
2. 緊急対応として、ローカル管理者権限で HKCU\Software\Microsoft\Office\16.0\Outlook\Options\General 配下の DoNewOutlookAutoMigration を0に書き換え、Outlookプロセスを完全停止後に再起動。
3. PowerShellで winget install Microsoft.Office を使い、クラシックOutlookを含むMicrosoft 365 Apps（Current Channel）を再インストール。

恒久対応として、社内SLAでは「業務影響Sev1=15分以内」「Sev2=2時間以内」のロールバック手順をRunbook化し、ヘルプデスク全員が手順書なしで実行できる状態を作っておくことを推奨します。あわせて、ファイル共有や同期系のトラブルが連鎖発生しやすいタイミングでもあるため、当サイトのOneDrive同期トラブルの対処ガイドとセットでチームに共有しておくと、初動対応の時間をかなり短縮できます。