Microsoft Purviewの「Azure PST Import」は、PSTファイルをAzure Blob StorageからExchange Onlineメールボックスへ取り込むための新しい移行方式です。結論から言うと、管理者が最初に確認すべきポイントは、ロールアウト時期の変更、PowerShell前提の運用、Azure Storageの権限、対象メールボックスの前提条件、保持ポリシーや監査への影響です。
2026年5月6日時点の更新では、グローバルロールアウトは当初予定の2026年5月4日開始から、2026年8月31日開始、2026年9月1日完了予定へ変更されています。Azure PST Importは管理者主導の機能であり、一般ユーザーが画面上で何かを操作する変更ではありません。ただし、PST内の過去メールがExchange Onlineへ取り込まれるため、Microsoft Purviewの保持、監査、eDiscovery、コンプライアンス運用には確実に関係します。(cloudscout.one)
Microsoft PurviewのAzure PST Importとは
Azure PST Importは、Azure Blob Storageに保存されているPSTファイルをExchange Onlineメールボックスへ直接インポートするための移行方式です。Microsoft 365 Roadmap ID 557559では、分析フェーズでPSTデータを検証・評価し、その後に実際の移行を実行する、Exchange Migration Serviceの2段階パターンに沿った機能として説明されています。(Microsoft 365 Message Center Archive)
従来のPSTインポートでは、Microsoft Purviewポータルのインポートサービス、AzCopy、マッピングCSV、ネットワークアップロード、ドライブ送付などを組み合わせて運用するケースが一般的でした。Microsoft Learnでも、PSTファイルをMicrosoft 365へ取り込む方法として「ネットワークアップロード」と「ドライブの発送」が案内されています。(Microsoft Learn)
今回のAzure PST Importで特に重要なのは、単に「PSTを取り込める」ことではありません。Azure Blob Storage上のPSTを、PowerShellベースの管理フローで分析してから移行する点が運用上の大きな違いです。
2026年5月6日の更新で押さえるべき変更点
今回の更新は、脆弱性修正のような緊急パッチではなく、Microsoft Purview Data Lifecycle ManagementにおけるPST移行機能の追加・展開に関する変更です。管理者は「いつ使えるか」だけでなく、「既存のPSTインポート手順を置き換えるのか、併用するのか」を判断する必要があります。
| 確認項目 | 内容 | 管理者が取るべき対応 |
|---|---|---|
| ロールアウト時期 | 開始予定が2026年8月31日、完了予定が2026年9月1日に変更 | 本番移行のスケジュールを再調整する |
| 操作方法 | GUIではなくPowerShell cmdletで実行 | PowerShell実行者、権限、手順書を事前に整備する |
| 処理の流れ | エンドポイント作成、Analyzeモード、結果確認、インポート実行、クリーンアップ | いきなり本番投入せず、分析結果を承認する工程を入れる |
| 影響対象 | Exchange Online管理者、Purview DLM管理者、PSTを取り込む組織 | メール、コンプライアンス、Azure担当で役割分担する |
| ユーザー影響 | 直接のユーザー操作は不要 | 取り込まれる過去メールの見え方や保持ルールは説明しておく |
Microsoft 365 Roadmapに掲載される日付や説明は変更される可能性があります。ロールアウト直前に、Microsoft 365管理センターのMessage CenterとRoadmap ID 557559を再確認してから本番作業日を確定するのが安全です。(Microsoft)
既存のPSTインポートとの違い
Azure PST Importを理解するうえで、従来のネットワークアップロード方式との違いを整理しておくと判断しやすくなります。
| 比較項目 | 従来のネットワークアップロード | Azure PST Import |
|---|---|---|
| 主な置き場所 | Microsoftが提供する一時的なAzure Storage領域へアップロード | Azure Blob Storage上のPSTを利用 |
| 主な操作 | Microsoft Purviewポータル、AzCopy、CSVマッピング | PowerShellベースの移行フロー |
| 事前検証 | インポートジョブ作成後に分析・フィルター設定 | Analyzeモードで準備状況を検証してから実行 |
| GUI | Purviewポータルでの操作が中心 | GUIでは利用できないと案内されている |
| 運用上の焦点 | アップロード、マッピング、フィルター | Azure RBAC、エンドポイント、分析結果、移行バッチ管理 |
従来のネットワークアップロードでは、Microsoft Learn上でAzCopyを使ったPSTアップロード手順が説明されています。また、PSTをアップロードするためのSAS URLはパスワードなどと同様に保護すべき情報として扱う必要があります。(Microsoft Learn)
一方、Azure PST Importでは、Azure Storageアカウントやコンテナーの到達性、Office 365 Import ServiceアプリへのStorage Blob Data Readerロール付与など、Azure側の権限設定が失敗要因になりやすい点に注意が必要です。(KbWorks – Microsoft 365 Partner)
影響範囲：誰が対応すべきか
Azure PST Importは、メール移行だけの話ではありません。過去メールをMicrosoft 365内に取り込むため、Exchange Online、Azure、Microsoft Purview、監査、法務・コンプライアンスの境界にまたがる作業になります。
Exchange Online管理者
Exchange Online管理者は、対象メールボックスのライセンス、メールボックス種別、アーカイブメールボックスの有効化、容量制限を確認する必要があります。
特に注意したいのは、従来のPSTインポート手順とAzure PST Importで前提条件が完全に同じとは限らない点です。Microsoft 365の既存PSTインポート資料では、非アクティブメールボックスやハイブリッド展開のオンラインアーカイブメールボックスに関するシナリオが説明されています。(Microsoft Learn)
しかし、Azure PST Importの更新情報では、分析時に対象メールボックスのライセンス、メールボックスが非アクティブまたはソフト削除状態ではないこと、RecipientTypeがUserMailboxであること、アーカイブへの取り込み時はアーカイブが有効であることなどが確認対象として挙げられています。既存手順の経験だけで「このメールボックスにも当然使える」と判断しないようにしましょう。(KbWorks – Microsoft 365 Partner)
Microsoft Purview管理者・コンプライアンス担当者
PSTの中身は、取り込み後にExchange Onlineメールボックス内のデータになります。そのため、既存のMicrosoft Purview保持ポリシー、保持ラベル、訴訟ホールド、削除ワークフロー、監査ログの対象になります。(KbWorks – Microsoft 365 Partner)
たとえば、退職者の過去メールを現行ユーザーのアーカイブメールボックスへ取り込む場合、取り込み後にどの保持ポリシーが適用されるかを事前に確認しないと、想定より長く残る、または想定より早く削除対象になる可能性があります。
Azure管理者
Azure管理者は、PSTを置くStorageアカウント、Blobコンテナー、アクセス制御、ネットワーク制限を確認します。
特に、Office 365 Import ServiceアプリにStorage Blob Data Readerロールを付与しないと、Azure PST Importエンドポイントの作成が失敗すると案内されています。権限付与は広すぎてもリスクになるため、可能な範囲で対象Storageアカウントまたはコンテナーに絞り、誰がいつ付与・削除したかを記録しておくべきです。(KbWorks – Microsoft 365 Partner)
開発者・自動化担当者
開発者や自動化担当者は、PowerShell実行を前提にした運用スクリプト、ログ出力、エラー時の再実行、分析結果の取り込みを設計する必要があります。
ここで重要なのは、コマンドを単発で実行することではなく、状態管理できる移行フローにすることです。たとえば、次の状態を明確に分けて扱います。
| 状態 | 自動化で確認すべきこと |
|---|---|
| エンドポイント作成前 | Azure Storage、RBAC、対象コンテナー、入力ファイルの有無 |
| Analyze実行中 | 分析完了、失敗PST、対象外メールボックス、容量エラー |
| Analyze完了後 | レポート確認、承認、対象件数、想定外データの有無 |
| インポート実行中 | 進行状況、失敗リトライ、重複の可能性 |
| 完了後 | 監査ログ、保持ポリシー、不要権限の削除、PST保管方針 |
管理者が事前に確認すべき設定
Azure Storageの確認
Azure PST Importで最初に詰まりやすいのは、PSTファイルそのものではなく、Azure Storageへのアクセス設定です。
確認すべき項目は次のとおりです。
- StorageアカウントとBlobコンテナーが作成済みである
- PSTファイルのパスとファイル名が入力ファイルの指定と一致している
- Office 365 Import ServiceアプリにStorage Blob Data Readerロールを付与している
- Storageアカウントのネットワーク制限やファイアウォールが、サービスからの読み取りを妨げていない
- 一時的に付与した権限を、移行後に削除する手順がある
Storageアカウント側の設定は、メール管理者だけでは完結しないことがあります。Azureチームが別部門の場合は、ロールアウト前に「誰が権限を付与するか」「本番前にどのテナント・Storageで検証するか」を決めておきましょう。
対象メールボックスの確認
Azure PST ImportのAnalyzeフェーズでは、対象メールボックスの前提条件やクォータが検証されます。事前に次の観点で棚卸ししておくと、分析後の手戻りを減らせます。
| 確認項目 | 見落とした場合の影響 |
|---|---|
| ライセンスが割り当て済みか | インポート対象として扱えない可能性がある |
| RecipientTypeがUserMailboxか | 共有メールボックスや特殊な宛先で失敗する可能性がある |
| メールボックスがソフト削除状態ではないか | 分析で除外・失敗する可能性がある |
| アーカイブへ取り込む場合、アーカイブが有効か | アーカイブ先を指定したインポートが失敗する |
| ArchiveQuota、RecoverableItemsQuotaに余裕があるか | 途中失敗や追加対応が必要になる |
| 保持ポリシー・ホールドの状態 | 取り込み後の削除・保持動作が想定とずれる |
既存のPSTインポート計画では、PSTファイルは20GB以下にするよう案内されており、大きなPSTはインポート性能に影響する可能性があります。Azure PST ImportでもPSTサイズは分析時の確認対象になるため、大容量PSTは事前に分割や対象見直しを検討してください。(Microsoft Learn)
入力ファイルの確認
Azure PST Importでは、バッチ入力ファイルとしてXMLまたはCSVを準備し、Analyzeモードで検証してからインポートへ進む流れが示されています。(KbWorks – Microsoft 365 Partner)
入力ファイルでは、次のミスが起きやすくなります。
| ミス | 具体例 | 防止策 |
|---|---|---|
| メールボックス指定ミス | 退職者の旧SMTPアドレスを指定している | 現在のExchange Online受信者情報と突合する |
| PSTパス不一致 | Blob上のフォルダー名と入力ファイルのパスが違う | 事前にファイル一覧を出力して照合する |
| アーカイブ指定漏れ | アーカイブへ入れるべきPSTをプライマリへ指定 | 対象者ごとにプライマリ・アーカイブを明記する |
| 重複投入 | 同じPSTを別フォルダー指定で再投入 | 過去ジョブ、TargetRootFolder、PSTハッシュを記録する |
| 文字コード・区切り文字 | CSVの文字化けや列ずれ | 小規模データでAnalyzeを先に実行する |
推奨される移行手順
本番移行では、次の流れで進めると失敗を抑えやすくなります。
| 手順 | 作業 | 判断ポイント |
|---|---|---|
| 事前棚卸し | PSTファイル、対象メールボックス、容量、保存場所を一覧化 | 取り込む必要があるPSTだけに絞る |
| Azure準備 | Storageアカウント、コンテナー、RBACを設定 | 権限を最小化し、移行後の削除手順を作る |
| 入力ファイル作成 | XMLまたはCSVで対象PSTとメールボックスを対応付け | プライマリとアーカイブの指定を確認 |
| Analyze実行 | 移行バッチを分析モードで実行 | 失敗、容量不足、対象外メールボックスを修正 |
| レポート確認 | 分析結果をExchange・Purview・法務担当で確認 | 想定外データや保持リスクがないか確認 |
| インポート実行 | 承認後に実際の移行バッチを開始 | 業務時間外や低負荷時間帯を検討 |
| 完了後確認 | 監査、保持、eDiscovery、ユーザー影響を確認 | 不要なAzure権限や一時ファイルを整理 |
ポイントは、Analyzeを「形式的な事前チェック」として扱わないことです。Analyze結果は、実行可否を判断するための承認資料にすべきです。
展開時の注意点
GUIで操作できると思い込まない
今回のAzure PST Importは、PowerShell cmdletのみで完了する運用として案内されています。GUI前提の運用手順書しかない場合、担当者が本番直前に操作できず、展開が止まる可能性があります。(KbWorks – Microsoft 365 Partner)
事前に、PowerShell実行環境、必要ロール、実行者、承認者、ログ保存場所を決めておきましょう。
重複インポートを軽視しない
PSTインポートでは、重複検出の仕組みを理解しておく必要があります。Microsoft LearnのFAQでは、SourceEntryIdベースで重複を検出する一方、件名・日付・本文・サイズなどのコンテンツベースの照合では重複検出しないと説明されています。別のPSTに同じ内容のメールが含まれている場合や、同じPSTを別のターゲットフォルダーへ再インポートした場合は、重複が発生する可能性があります。(Microsoft Learn)
移行前に、PSTファイル名だけでなく、対象者、作成元、取り込み済みジョブ、ターゲットフォルダーを記録しておくことが重要です。
保持ポリシーとホールドを後回しにしない
PSTを取り込むと、そのデータはExchange Onlineメールボックス内のデータとして扱われます。既存の保持ポリシー、保持ラベル、訴訟ホールド、削除ワークフローの対象になるため、メール移行担当だけで判断するとコンプライアンス上のズレが起きます。(KbWorks – Microsoft 365 Partner)
たとえば、過去10年分のPSTを取り込んだ直後に保持期限が切れたデータとして削除対象になるのか、ホールドにより保持され続けるのかは、テナントの設定次第です。移行前に、対象メールボックスへ適用されるポリシーを必ず確認してください。
ユーザー影響は「ゼロ」と考えない
更新情報では、Azure PST Importは管理者主導であり直接のユーザー影響はないとされています。これは、ユーザーが新しいボタンを押したり設定を変えたりする必要がないという意味です。(KbWorks – Microsoft 365 Partner)
しかし、取り込まれた過去メールが検索結果に表示される、アーカイブメールボックスに過去データが増える、eDiscoveryや監査の対象が広がるといった間接的な影響はあります。ヘルプデスクには、「古いメールが突然見えるようになった」「検索結果が増えた」といった問い合わせが来る可能性を共有しておきましょう。
よくある失敗と回避策
| 失敗例 | 原因 | 回避策 |
|---|---|---|
| エンドポイント作成に失敗する | Storage Blob Data Readerロールが不足 | Office 365 Import ServiceアプリへのAzure RBACを確認 |
| Analyzeで大量に失敗する | 対象メールボックス、ライセンス、アーカイブ設定の不備 | 事前にExchange Online側の棚卸しを行う |
| 本番直前に手順が止まる | GUIでできると思い込んでいた | PowerShell前提の手順書と実行リハーサルを用意 |
| 重複メールが増える | 同じ内容のPSTを別ファイル・別フォルダーで再投入 | PST台帳とジョブ履歴を管理 |
| コンプライアンス判断が遅れる | 保持ポリシーやホールドの確認不足 | 移行計画にPurview管理者と法務担当を入れる |
| 移行時間が読めない | PSTサイズや同一メールボックスへの集中投入 | 小規模パイロットで処理時間を測定 |
| 移行後の権限が残る | Azure RBAC削除の手順がない | クリーンアップを作業完了条件に含める |
管理者・開発者が今すぐ準備すべきこと
ロールアウトが先に延びたことで、準備期間は増えました。今やるべきことは、急いで本番移行することではなく、移行対象と運用手順を固めることです。
まず、組織内に残っているPSTファイルを棚卸しします。ファイル名、所有者、対象メールボックス、容量、保存場所、取り込み先、保持要件を一覧化してください。次に、Azure Blob Storageを使う移行方式に切り替えるか、従来のネットワークアップロードやドライブ送付を継続するかを判断します。
そのうえで、テスト用の少数メールボックスを選び、Azure Storage権限、入力ファイル、Analyzeモード、レポート確認、インポート実行、クリーンアップまでを一通り検証します。開発者や自動化担当者が関わる場合は、PowerShellの実行結果をログ化し、失敗時にどこから再開できるかを明確にしておきましょう。
まとめ：Azure PST Importは「移行機能」ではなく「統制されたPST取り込み運用」として設計する
Microsoft PurviewのAzure PST Importは、PSTファイルをExchange Onlineへ取り込むための便利な追加機能です。ただし、成功の鍵はインポート実行そのものではなく、事前分析、Azure権限、対象メールボックスの確認、保持ポリシー、監査、クリーンアップまでを含めた運用設計にあります。
次に取るべき行動は明確です。Microsoft 365管理センターでMessage Center MC1281505とRoadmap ID 557559の最新状況を確認し、PSTファイルの棚卸し、Azure Storageの権限設計、PowerShell手順書、Analyze結果の承認フローを準備してください。ロールアウト後に慌てて対応するより、今のうちに「どのPSTを、どのメールボックスへ、どの保持ルールで取り込むか」を決めておくことが、最も確実な対策です。
コメント