Microsoft Purview eDiscoveryのエクスポートでFailedItemsが表示されるのにitems.csvに出ない問題の原因と解決策

Microsoft Purview eDiscovery で検索結果をエクスポートすると、locations.csv の FailedItems に数値が出ているのに、items.csv には失敗したアイテムが見当たらない――このギャップに戸惑う管理者は少なくありません。本記事では「なぜ起きるのか」「何が分かり、何が分からないのか」「どう直すのか」を、実務の手順・チェックリスト・再現しやすい検証方法まで含めて徹底整理します。

前提：この記事で解決できること

• 失敗アイテムの“見えない理由”を体系的に理解できます。
• locations.csv の最小限かつ最大限の読み解き方が分かります。
• 場所（Location）単位での再試行に必要なチェックリストと具体的な対処を入手できます。
• 大規模エクスポート時の設計と運用のベストプラクティスをそのまま適用できます。

質問の整理

よくある質問を、要点だけに絞って明文化します。

• Q1：失敗したアイテムを一覧で取得する方法はあるか？
• Q2：どのアイテムが失敗したのかを判別できるか？

結論（先に答え）

結論	詳細
Purview は「失敗アイテム一覧」を生成しない	エクスポートは場所（Location）単位で処理され、場所が失敗するとその場所に含まれるアイテムは一切試行されず、items.csv にも記録されません。したがってアイテム単位の失敗リストは取得できません。
分かるのは場所レベルの失敗のみ	locations.csv の ErrorWarning 列が最も詳細な情報源です。ここに表示されるエラー内容で原因を推測・対処します。
主な失敗原因と対処	Access Denied／アクセス拒否：エクスポート実行ユーザーを eDiscovery Manager ロールに追加。 Mailbox Not Found／メールボックスなし：該当ユーザーが削除・無効化されていないか確認。 Throttled／スロットリング：同時実行数を減らす、または時間をおいて再試行。 Corrupted Item／アイテム破損：該当メールボックスやサイトの整合性を修復して再実行。
修正後に再エクスポート	場所レベルのエラーを解消してから同一の検索スコープで再エクスポート。場所が成功すれば、その場所配下のアイテムが items.csv に出力されます。
事前確認・追加手段	コンテンツ検索のプレビュー：同一ケースでプレビューし、問題の場所にアイテムが存在しアクセス可能か確認。 監査ログの確認：エクスポートの拒否や失敗イベントを追跡。 機能要望の提出：アイテム単位の失敗レポートが必要なら管理センター等から要望を送信。

なぜ「FailedItems はあるのに items.csv にいない」のか

エクスポートの内部は場所 → ジョブ → アイテムという粒度で動きます。ここで重要なのは、「場所が成功すること」が「アイテムを列挙・出力するための前提条件」になっていることです。つまり、メールボックスやサイトなど場所単位で失敗すると、その場所配下のアイテムは列挙フェーズに進めず、items.csv には一切現れません。
一方 locations.csv は、各場所に対するエクスポートの結果概要（成功・失敗・警告、件数、メッセージ）を記録します。ここに表示される FailedItems の数字は「その場所配下で本来対象となるはずだったアイテム数」や「列挙できなかった可能性のあるアイテム数」のサマリとして表現されます。対して items.csv は成功した場所から列挙できたアイテムだけを明細化するため、両者の乖離が起こります。

locations.csv を最大限活用する

場所レベルでしか見えない以上、locations.csv を正しく読み解く力が不可欠です。以下は一般的な列の意味と読み方です。

列名	意味	読み解きポイント
Location	対象の場所（ユーザーのメールボックス、SharePoint/OneDrive サイト、Teams 等）	識別子（メールアドレス、サイト URL）が移行・削除で変わっていないか要確認。
Kind / Workload	種類（Mailbox / SharePoint / OneDrive / Teams など）	ワークロード別にエラー傾向が異なる。切り分けの軸に。
ExportedItems	エクスポートに成功したアイテム数	0 かつ FailedItems > 0 のときは場所レベルでの失敗が濃厚。
FailedItems	失敗（または列挙不可）とみなされたアイテム数	この数だけで「どのアイテムか」は分からない。場所の問題解消 → 再試行が必要。
ErrorWarning	エラー／警告メッセージ	最重要。文字列パターンから原因を特定し対処する。

典型的な行の例を、読み方のメモ付きで示します。

Location,Workload,ExportedItems,FailedItems,ErrorWarning
[email protected],Mailbox,0,154,"AccessDenied: Export account is not authorized"
https://contoso-my.sharepoint.com/personal/user02,OneDrive,0,98,"Site not found or moved"
teamA,Teams,0,120,"Throttled: Please retry later"

• AccessDenied：権限不足。実行アカウントのロール・グループを見直す。
• Site not found：URL 変更や削除。現行 URL を検索し直す。
• Throttled：スロットリング。並列数を下げてリトライ。

主なエラーの原因と対処（ワークロード横断）

パターン	主因	対処	確認観点
AccessDenied / NotAuthorized	ロール不足、ケース権限不足、スコープ外	実行アカウントを eDiscovery Manager に追加。ケースのメンバー権限を再確認。	「誰が」「どのケースで」実行しているか。ケースレベルのアクセス権。
MailboxNotFound / UserNotFound	対象ユーザーの削除・無効化・メールボックス未プロビジョニング	ユーザー状態・ライセンス・メールボックス種別（UserMailbox）を確認。	識別子のスペル、UPN 変更、別テナント移動の有無。
Site not found / URL changed	SharePoint/OneDrive サイトの削除・URL 変更	現行 URL に読み替えて再指定。復元済みか確認。	監査・管理センターでサイト状態を確認。
Throttled / TooManyRequests	スロットリング（API/サービス保護）	同時実行数を下げ、時間を空けて再実行。ジョブを分割。	ピーク時間帯の回避、夜間・週末のバッチ運用。
Timeout / Operation expired	大容量・高負荷・ネットワーク不安定	スコープ縮小、期間絞り、ネットワーク帯域の確保、並列数最適化。	再現性の有無。ファイアウォールやプロキシの制限。
Corrupted item detected	コンテンツ破損・不整合	対象ワークロードで修復を実施（再インデックスや整合性チェック等）。	限定スコープでの再現確認。破損箇所特定のための追加ログ。

「部分的エクスポートは行われない」という前提

同一の場所内で「一部のアイテムだけ成功し、残りが失敗」という動きはしません。場所が失敗した時点で、その場所配下は丸ごと未試行です。失敗の起点はあくまで場所であり、アイテムではありません。従って、items.csv にも失敗アイテムの痕跡は残りません。

PowerShell / Graph でも「アイテム単位の失敗」は取れない

現行の管理シェルや Graph API は、エクスポートの失敗をアイテム単位で可視化するための情報を返しません。やはり場所レベルのエラーを解消 → 再エクスポートが唯一の解です。補助的に以下のようなコマンドで「場所が有効か」「対象が存在するか」を点検すると、原因特定が早まります。

# メールボックスの存在・状態（例）
Get-EXOMailbox -Identity [email protected] | Format-List RecipientTypeDetails, PrimarySmtpAddress, DisplayName

# eDiscovery Manager ロール グループのメンバー確認（例）

Get-RoleGroupMember -Identity "eDiscovery Manager"

# OneDrive/SharePoint サイトの存在確認（例）

# ※ 実環境の URL（個人サイト URL）に置き換える

# Connect-SPOService など事前接続が必要

Get-SPOSite -Identity "[https://contoso-my.sharepoint.com/personal/user_contoso_onmicrosoft_com](https://contoso-my.sharepoint.com/personal/user_contoso_onmicrosoft_com)"

# グループ/Teams の存在確認（例：Entra ID）

Get-MgGroup -Filter "displayName eq 'Team A'" 

再実行（リトライ）の具体手順

1. 失敗場所の抽出：locations.csv を開き、ExportedItems = 0 かつ FailedItems > 0 の行をフィルタします。ErrorWarning でパターン分けします。
2. 原因の是正：前章の表に沿って、権限・存在・URL・並列度・帯域などのボトルネックを解消します。
3. 限定スコープでの検証：問題の場所のみを対象に、期間やクエリを限定して短時間でテストエクスポートします。
4. 本番再エクスポート：同じ検索条件（または分割した条件）で再エクスポートします。成功した場所については items.csv に明細が出力されます。

監査ログで裏取りする

「何が起きていたか」を裏付けたい場合は監査ログが有効です。おおまかな見方は次のとおりです。

• 対象操作で絞る：eDiscovery 検索・エクスポート関連の操作を期間指定で検索。
• 実行アカウントで絞る：誰が開始し、どの場所に対して失敗したかを追跡。
• 失敗メッセージの一致：locations.csv の ErrorWarning と同じ文言・コードが出ていないか照合。

トラブルシュート・フロー（現場で回す手順）

1. 事実確認：locations.csv の FailedItems と ErrorWarning を突合。
2. 範囲を絞る：失敗場所だけを対象にミニマムクエリで再現。
3. 原因を仮説化：権限／存在／URL／スロットリング／ネットワーク／破損のいずれかに分類。
4. 対処を実施：該当カテゴリの対処を適用。
5. 再実行：並列度や時間帯を調整してリトライ。
6. 結果の評価：items.csv に明細が出力されるか、locations.csv のエラーが消えたかを確認。

大規模エクスポートの設計原則（ベストプラクティス）

原則	狙い	実装のコツ
バッチを小分け	スロットリングとタイムアウトの回避	サイズ・期間・ワークロードで分割。例：100GB 未満や 3〜6 か月ごとに。
並列度の最適化	安定性と速度のバランス	ピーク時はスレッド数を下げ、夜間に増やすなど動的に調整。
ネットワーク整備	帯域不足による失敗を抑制	プロキシ・DLP・SSL インスペクションの影響を事前評価。
検証→本番の二段構え	原因切り分けの迅速化	まず限定スコープで成功を確認してから全量へ展開。
ログの標準化	再現・説明責任の担保	locations.csv と items.csv を都度保存し命名規則で管理。

ケース設計のチェックリスト

• ケースのメンバー構成：実行アカウントが適切なロールで参加している。
• 検索スコープ：ワークロード／場所の指定が最新のディレクトリと一致している。
• クエリ：不要な条件が含まれていない（再現・検証用に最小化できる）。
• 実行タイミング：業務ピークから外してバッチを組む。
• 失敗時のルール：ErrorWarning の分類ごとに対処手順が定義されている。

「失敗場所」を高速にあぶり出すための Excel 作業例

1. locations.csv を Excel で開く。
2. テーブル化し、ExportedItems と FailedItems に対してフィルタを設定。
3. ExportedItems = 0 かつ FailedItems > 0 の行を抽出。
4. ErrorWarning に含まれるキーワードで並べ替え（Access、Found、Throttle など）。
5. 同じパターンの場所はバッチで原因対処と再試行を行う。

よくある誤解と正しい理解

誤解	正しい理解
FailedItems に出ているなら、そのアイテムは items.csv のどこかにあるはず。	いいえ。場所が失敗した場合、アイテムの列挙自体が行われないため、items.csv には現れません。
PowerShell や Graph を使えば、失敗アイテムの明細を取得できる。	いいえ。現行機能ではアイテム単位の失敗情報は提供されません。場所のエラーを解消して再エクスポートするしかありません。
同じジョブを何度も実行しても結果は変わらない。	スロットリングや一時的要因で失敗している場合、時間帯や並列度を調整して再試行すると成功することがあります。

ケーススタディ：エラー別の再現と解決

AccessDenied（アクセス拒否）

状況：ErrorWarning に AccessDenied が表示され、ExportedItems = 0、FailedItems > 0。
対処：実行アカウントを eDiscovery Manager に追加し、ケースのメンバー権限も確認。数分〜数十分のロール反映後に限定スコープで再試行。

MailboxNotFound（メールボックス未検出）

状況：退職者や無効化ユーザーのメールボックスが対象。
対処：メールボックスの復元や識別子の確認、必要であればアーカイブの検索スコープ見直し。最新の UPN/SMTP を指定し直して再試行。

Throttled（スロットリング）

状況：大規模実行、ピーク帯、並列数が多い。
対処：並列スレッド数を下げ、夜間にスケジュール。バッチを分割して数回に分ける。

Corrupted item（アイテム破損）

状況：特定の場所だけ繰り返し失敗。
対処：その場所を限定スコープで再検証し、整合性の修復や再インデックス操作を実施後、再エクスポート。

運用テンプレート（使い回せるドキュメント化）

再現性と説明責任を高めるため、次のテンプレートをおすすめします。

• ジョブ台帳：ケース名、検索条件、対象期間、ワークロード、開始/終了時刻、並列度、担当者。
• 結果サマリ：locations.csv の集計（成功/失敗の場所一覧、エラー分類別の件数）。
• 対処履歴：原因仮説、実施対策、再試行結果、残課題。
• 再実行ルール：何が起これば再試行するか、並列度・時間帯の標準値。

「アイテムが見たい」要求との向き合い方

法務・監査の現場では「どのアイテムが失敗なのか」を求められることがあります。しかし、現行仕様ではアイテム単位の失敗把握は不可能です。代替として、次のような合意形成を行うと運用がスムーズになります。

• 場所単位の成功確認：問題の場所が成功に転じたか（ExportedItems が増え、ErrorWarning が消えたか）。
• 差分エクスポート：期間・場所を固定し、成功前後での items.csv 行数の差分で検証。
• 監査ログの根拠：誰がいつ、どの場所を成功/失敗させ、どのエラーだったか。

まとめ

Microsoft Purview eDiscovery のエクスポートで FailedItems と items.csv が一致しないのは、処理の単位がアイテムではなく場所にあるためです。現行仕様では「失敗したアイテム一覧」は生成されません。locations.csv の ErrorWarning を手掛かりに場所のエラーを解消し、限定スコープで再検証しながら再エクスポートする――これが唯一の確実な道筋です。加えて、バッチ分割・並列度最適化・監査ログの活用・ドキュメント化という運用の型を整えれば、失敗の再発を抑え、説明責任にも耐える結果を一貫して得られます。

---

付録：チェックリスト総まとめ

カテゴリ	チェック	合格基準
権限	実行アカウントは eDiscovery Manager、ケース権限は適正か	AccessDenied が出ない
存在	ユーザー/サイト/Teams が現行の識別子で存在するか	NotFound 系のエラーが出ない
スロットリング	並列度・時間帯の最適化ができているか	Throttled が出ても再試行で解消
ネットワーク	帯域・プロキシ・FW の設定でブロックされていないか	Timeout が減少
破損	限定スコープで再現し、整合性修復の目処が立つか	Corrupted item の再発が止まる
ログ	locations.csv/items.csv の版管理と命名規則	差分追跡・説明が即日可能

---

補足：頻出の質問（簡易Q&A）

• 失敗した場所だけ再エクスポートできる？
  はい。問題の場所に限定して小さく再試行し、成功を確認してから全量へ広げるのが安全です。
• 一度成功した場所は再度エクスポートする必要がある？
  基本的には不要です。必要な場合は期間・クエリ固定の差分検証を推奨します。
• 「FailedItems の内訳」はどうやって説明する？
  仕様上、アイテム単位では見えません。場所の成功転換（ExportedItems の増加）と監査ログの事実で説明します。

---

結語

「失敗アイテムを一覧で見たい」という期待は自然ですが、現時点の Purview eDiscovery のエクスポートはその設計になっていません。だからこそ、場所レベルで徹底的に整える――権限・存在・並列・時間帯・ネットワーク――この地道な運用が、最終的に items.csv を確実に満たす最短ルートです。この記事の表やチェックリスト、手順をテンプレート化し、チームで共有・標準化してください。