Windows Outlook の PST からクラウドへ｜移行時の破損と容量の注意

長年、Windows Outlookを利用してきた企業にとって、ローカルPCに蓄積された「PSTファイル」は、過去のビジネスの足跡であると同時に、管理上の大きな「負債」となっています。PCのハードディスク故障によるデータ消失リスク、デバイス紛失時の情報漏洩、そして何よりOutlookの動作を著しく低下させる肥大化問題。これらの課題を解決するために、PSTファイルをMicrosoft 365（Exchange Online）などのクラウド環境へ統合することは、現代のITインフラ整備において避けては通れないタスクです。

しかし、PSTファイルの移行は、単なるファイルのコピー＆ペーストでは済みません。ファイル構造の脆弱性に起因する「破損」、クラウド側の仕様による「容量制限」、そして大量データ転送による「ネットワーク負荷」。これら実務上のハードルを正しく理解し、対策を講じなければ、移行作業そのものが業務を停止させるリスクを孕んでいます。

本記事では、IT実務者の視点から、PSTファイルをクラウドへ安全かつ確実に移行するための具体的な手法、エラー回避策、そして移行後の運用設計までを徹底的に解説します。

OutlookのPST移行をクラウド化すべき理由とリスクの正体

かつてメールサーバー（Exchange Server等）の容量が極めて限定的だった時代、古いメールをローカルのPSTファイル（個人用フォルダーファイル）へ退避させることは標準的な運用でした。しかし、この運用は現代のワークスタイルにおいては多くの弊害を生んでいます。

なぜローカルのPST運用は限界なのか（脱オンプレ負債）

PSTファイルはローカルドライブ上での動作を前提に設計されています。これをネットワークドライブやクラウドストレージ（OneDrive, SharePoint）上で直接開くことは、Microsoftによって公式に非推奨とされています。同期の競合や排他制御の不備により、ファイルが瞬時に破損する恐れがあるためです。

また、昨今のSaaS導入が進む中で、メールデータだけが特定の物理PCに紐付いている状態は、ハイブリッドワークの阻害要因となります。インフラの最適化を進める上では、メールデータをクラウドへ集約し、あらゆるデバイスから安全にアクセスできる環境を構築することが先決です。こうしたインフラの「負債」を剥がすアプローチについては、以下の記事も参考になります。

SaaSコストとオンプレ負債を断つ。バックオフィス＆インフラの「標的」と現実的剥がし方（事例付）

移行時に直面する「3つの壁」：破損・容量・ネットワーク帯域

PST移行を難しくしているのは、以下の3つの要因です。

• 破損: 長年使われたPSTは、内部インデックスが壊れていることが珍しくありません。壊れたままクラウドへ流し込むと、移行プロセスが途中で停止します。
• 容量: Exchange Onlineの一般的なプラン（Business Standardなど）では、1ユーザーのメールボックス容量は50GBです。対して、PSTファイルが50GBを超えているケースは多々あり、そのままではインポートできません。
• ネットワーク帯域: 1社100名の社員が平均20GBのPSTを保有している場合、合計2TBのデータ転送が発生します。業務時間中にこれを実行すれば、社内回線はパンクします。

PSTからMicrosoft 365（Exchange Online）への移行手法比較

移行規模と技術レベルに応じて、主に3つの手法が存在します。自社の環境に適したものを選択してください。

※詳細な仕様については、Microsoft公式ドキュメント（ネットワークアップロードを使用して PST ファイルをインポートする）をご確認ください。

移行前の必須工程：PSTファイルの整合性チェックと修復

移行失敗の最大の原因は、PSTファイル自体の破損です。クラウドへアップロードする前に、必ず「受信トレイ修復ツール（SCANPST.exe）」を実行する必要があります。

受信トレイ修復ツール（SCANPST.exe）の正しい使い方

1. Outlookを完全に終了します。
2. C:\Program Files\Microsoft Office\root\Office16（バージョンにより異なる）にある SCANPST.exe を実行します。
3. 対象のPSTファイルを選択し、「開始」をクリックしてエラーをスキャンします。
4. エラーが検出された場合、「修復」を実行します。この際、必ずバックアップを作成するオプションを有効にしてください。

注意点: ファイルサイズが20GBを超えるような巨大なPSTの場合、SCANPST自体の処理に数時間から1日かかることがあります。また、SCANPSTで修復しきれない致命的な破損がある場合は、市販のサードパーティ製修復ソフトの検討が必要になることもあります。

【重要】PSTの「容量制限」と「アーカイブ」の設計

クラウドへ移行する際、最も頭を悩ませるのが「容量の壁」です。Microsoft 365の主要プランにおけるメールボックス容量は以下の通りです。

• Microsoft 365 Business Basic / Standard: 50GB
• Microsoft 365 Business Premium / E3 / E5: 100GB

50GBを超える巨大PSTをどう分割・移行するか

移行元PSTが50GBを超えている場合、そのまま50GB制限のプランにインポートすることはできません。この場合、以下のいずれかの対策を講じます。

1. プランのアップグレード: E3プラン以上を契約し、100GB枠を確保する。
2. PSTの分割: Outlookの「古い項目の整理」機能を使用し、年単位などでPSTを複数のファイルに分割してから、個別にインポートする。
3. アーカイブメールボックスの活用: 次項で詳述するオンラインアーカイブ機能を有効にし、そちらへインポートする。

インプレース アーカイブ（オンラインアーカイブ）の有効活用

「インプレース アーカイブ」とは、メインのメールボックスとは別に提供されるクラウド上の追加ストレージです。Business Premium以上のライセンスでは、このアーカイブ容量が非常に大きく（自動拡張アーカイブが有効なら最大1.5TBまで）、巨大な過去ログの移行先として最適です。

移行マッピングファイル（CSV）を作成する際、ターゲットをメインメールボックスではなくアーカイブメールボックスに指定することで、メインの50GB/100GB枠を消費せずに済みます。

実践ステップ：ネットワークアップロードによる一括移行手順

ここでは、実務で最も多用される「ネットワークアップロード（AzCopy）」を用いた一括移行の手順を解説します。

手順1：Azure AzCopyの準備とSAS URLの取得

1. Microsoft Purview コンプライアンスポータル（https://compliance.microsoft.com/）にアクセスします。
2. 「データ生命周期管理」＞「Microsoft 365」＞「インポート」を選択します。
3. 「新しいインポートジョブ」を作成し、SAS URL（Azureストレージへのアクセスキー付きURL）をコピーします。

手順2：PSTファイルのアップロード

コマンドプロンプトまたはPowerShellを開き、AzCopyツールを使用してファイルをAzure上のテンポラリストレージへ転送します。

azcopy copy “/path/to/psts” “取得したSAS URL” –recursive=true

このフェーズが最も時間を要します。夜間や週末に実行し、ネットワーク帯域への影響を最小限に抑えましょう。

手順3：移行用マッピングファイルの作成

どのPSTファイルを、どのユーザーの、どのフォルダ（またはアーカイブ）に入れるかを定義するCSVファイルを作成します。以下の項目が必須です。

• Workload (Exchange)
• FilePath (Azure上のパス)
• Name (PSTファイル名)
• Mailbox (宛先メールアドレス)
• IsArchive (FALSEならメイン、TRUEならアーカイブへ)
• TargetRootFolder (インポート先のフォルダ名)

手順4：インポートジョブの作成と監視

作成したCSVをインポートジョブにアップロードし、分析（検証）を実行します。エラーがなければ、インポートを開始します。進捗率はパーセンテージで表示されるため、定期的に監視してください。

こうしたデータ移行やシステム間の連携を自動化する考え方は、会計ソフトの移行など他のバックオフィス業務でも非常に重要です。例えば、以下の記事で解説している会計データの移行実務も、PST移行と同じく「データの整合性」と「マッピング」が成否を分けます。

freee会計導入マニュアル｜旧ソフト移行ガイド

よくあるエラーとトラブルシューティング

移行作業中には、必ずと言っていいほどエラーが発生します。代表的なものと対処法を挙げます。

「MapiExceptionMaxObjsExceeded」エラー

フォルダ内のアイテム数が多すぎる、またはフォルダ階層が深すぎる場合に発生します。クラウド側の制限に抵触しているため、インポート前にPST側でフォルダ整理を行うか、インポート設定で一部のアイテムをスキップする調整が必要です。

ネットワーク切断による中断

AzCopyはレジューム（再開）機能を備えています。同じコマンドを再実行すれば、転送済みのファイルはスキップされ、未転送分から再開されます。一度失敗しても、慌てて最初からやり直す必要はありません。

移行後の「脱PST」運用ガイド

無事に移行が完了したら、二度とローカルにPSTファイルを作らせないための統制をかけることが重要です。これが不十分だと、数年後にまた同じ「PSTの山」を抱えることになります。

PSTの作成をポリシーで禁止する方法

グループポリシー（GPO）またはMicrosoft Intuneを使用して、Outlookの設定を強制します。

• PSTの新規作成を禁止: 「ユーザーが新しい PST ファイルを追加できないようにする」を有効化。
• 既存PSTの読み込み専用化: 移行が完全に終わった段階で、既存のPSTへの書き込みを制限します。

メールボックスをクラウドへ移行し、さらに業務アプリ全体のID管理を統合することで、退職時のデータ削除漏れやシャドーITの防止にも繋がります。統合的なアイデンティティ管理については、こちらのガイドが参考になります。

SaaS増えすぎ問題と退職者のアカウント削除漏れを防ぐ。Entra ID・Okta・ジョーシスを活用した自動化アーキテクチャ

まとめ：クラウド移行でメール資産を負債から資産へ

PSTファイルからクラウドへの移行は、単なるデータの引っ越しではありません。脆弱なローカル保存から、セキュアで可用性の高いクラウド基盤へのアップグレードであり、組織のデジタルガバナンスを確立するための重要な一歩です。

移行時には「破損」と「容量制限」という大きな壁がありますが、事前のSCANPSTによる修復、そしてオンラインアーカイブを組み合わせた容量設計を適切に行えば、安全な移行は十分に可能です。本記事で紹介したネットワークアップロードの手順を参考に、計画的なデータ集約を進めてください。