SharePoint / OneDriveへのデータ移行で、移行タスクが多すぎて手作業では管理しきれない場合は、SharePoint Migration Tool（SPMT）のJSONまたはCSVによる一括登録を使うのが現実的です。今回確認すべきポイントは、新しい移行方式そのものではなく、SPMTに読み込ませるJSON/CSVファイルを正しい形式で作ることです。
特に重要なのは、CSVでは必要な列をすべて用意し、使わない列も空欄として残すこと、JSONでは最低限 SourcePath と TargetPath を正しく指定することです。列不足、ドキュメントライブラリ名の誤り、OneDrive移行先URLの指定ミス、権限マッピングの未確認は、移行前スキャンや本番移行でつまずきやすいポイントです。
この記事では、2026年6月3日前後に確認されたMicrosoft公式情報をもとに、SharePoint / OneDriveの「Format your JSON or CSV file for data content migration」の内容を、管理者・開発者が実務で確認すべき観点に整理します。SPMTはJSONまたはCSVを使って大量の移行タスク情報を一括アップロードできると説明されています。(Microsoft Learn)
まず押さえるべき結論
今回の公式情報で確認すべき本質は、SPMTの移行タスクを「画面から1件ずつ作る」のではなく、JSONまたはCSVで定義して一括登録できる点です。大量のファイル共有、オンプレミスSharePoint Server、OneDrive移行を扱う組織では、移行先URLやライブラリ名を手入力で繰り返すより、定義ファイルを作ってレビュー・修正・再利用できる形にした方が安全です。
ただし、JSON/CSVによる一括登録は、単に一覧を作ればよいわけではありません。SPMTが期待する列構成やプロパティ名から外れると、移行タスクの作成前にエラーになったり、意図しないライブラリやフォルダーへ移行されたりします。
| 確認項目 | 管理者・開発者が見るべきポイント |
|---|---|
| 対象範囲 | SharePoint、OneDrive、必要に応じてTeams関連の移行先を含むMicrosoft 365移行 |
| 主な対象者 | Microsoft 365管理者、SharePoint管理者、移行担当者、PowerShellやスクリプトで移行定義を作る開発者 |
| 重要な変更・確認点 | JSON/CSVで移行タスクを一括登録する際の入力形式、必須列、任意列、Hub Site関連列、JSONの必須プロパティ |
| すぐ確認すべきこと | CSVの列数、SharePointライブラリの内部名、OneDrive移行先URL、権限・ユーザーマッピング、SPMT設定 |
| 失敗しやすい点 | Shared Documents をCSVにそのまま入れる、空欄列を削除する、移行前スキャンを省略する、権限移行の方針を決めない |
SPMTはオンプレミスSharePointサイトからMicrosoft 365へ移行するための無償の移行ソリューションで、SharePoint Server 2010 / 2013 / 2016 / 2019やSharePoint Foundation 2010 / 2013などからSharePoint、OneDrive、Teamsへの移行をサポートします。(Microsoft Learn)
何が変わるのか：機能追加よりも「移行定義ファイルの正確性」が重要
この情報は、SPMTの新しい移行エンジンが突然追加されたというより、データコンテンツ移行でJSON/CSVファイルをどう整形すべきかを確認するための公式ガイドです。Microsoft Learn上の該当ページでは、CSVによる一括アップロードとJSONによる一括アップロードの両方が説明されています。(Microsoft Learn)
管理者や開発者にとっての影響は、次の3点に集約できます。
まず、移行タスクを大量に作る場合、SPMT画面での手入力よりも、JSON/CSVを使ったほうがレビューしやすくなります。たとえば、部門ごとに移行元ファイルサーバー、移行先SharePointサイト、移行先ライブラリ、サブフォルダーを一覧化し、移行前に関係者へ確認できます。
次に、CSVでは列の意味が固定されます。不要な列を削除してはいけません。Microsoftの説明では、すべての列が存在している必要があり、不要な場合は空欄にできます。(Microsoft Learn)
最後に、JSONでは移行タスクを構造化できます。単純なファイル共有移行だけでなく、SharePointサイト、リスト、サブサイトを含む移行定義を扱いやすくなります。公式例では、JSONの最小必須値として SourcePath と TargetPath が示されています。(Microsoft Learn)
対象となる移行シナリオ
SPMTのJSON/CSV一括登録が特に役立つのは、移行タスク数が多く、手作業ではミスが起きやすいケースです。
たとえば、次のような移行では効果が大きくなります。
- 部門別ファイルサーバーをSharePointの複数サイトへ移行する
- ユーザー別ホームドライブをOneDriveへ移行する
- オンプレミスSharePoint Serverの複数ライブラリをSharePoint Onlineへ移行する
- サイト移行時にHub Site登録やHub Site関連付けも整理したい
- 移行定義をExcelやスクリプトで生成し、レビュー後にSPMTへ投入したい
SPMTはローカルおよびネットワークファイル共有、SharePoint Server 2010 / 2013 / 2016 / 2019のファイル、フォルダー、リストアイテム、権限、バージョン、管理メタデータ、サイト機能など複数の要素の移行をサポートします。(Microsoft Learn)
一方で、JSON/CSVを使えば何でも移行できるわけではありません。移行元の状態、移行先テナントの制限、SharePointのファイル名・パス制限、権限設計、スロットリングの影響を受けます。定義ファイルは「移行の入口」であり、移行計画そのものを代替するものではありません。
CSVファイルの基本フォーマット
CSVでSPMTの移行タスクを一括登録する場合、公式情報では最初の3列が移行元、残りの列が移行先やHub Site関連の指定として整理されています。(Microsoft Learn)
| 列 | 項目 | 必須 | 指定内容 | 実務上の注意点 |
| – | ——————: | -: | ——————————————— | ———————————- |
| 1 | Source | 必須 | オンプレミスSharePoint ServerサイトURL、またはローカルファイル共有パス | ファイル共有の場合はUNCパスやローカルパスを正確に指定する |
| 2 | Source DocLib | 任意 | 移行元SharePoint Serverのドキュメントライブラリ名 | ファイル共有移行では空欄にする |
| 3 | Source SubFolder | 任意 | 移行元ライブラリ内のサブフォルダー | 空欄ならルートから移行。ファイル共有移行では空欄にする |
| 4 | Target Web | 必須 | 移行先SharePointサイトURL | OneDrive移行ではユーザーのOneDrive URLを指定する |
| 5 | Target DocLib | 必須 | 移行先サイト内のドキュメントライブラリ名 | 表示名ではなく内部名が必要になる場面に注意 |
| 6 | Target SubFolder | 任意 | 移行先ライブラリ内のサブフォルダー | 空欄ならライブラリ直下へ移行 |
| 7 | RegisterAsHubSite | 任意 | 移行後にHub Siteとして登録する場合のHub Site名 | SharePointサイト移行向け。次の列と同時指定しない |
| 8 | AssociateWithHubURL | 任意 | 既存Hub Siteへ関連付ける場合のHub Site URL | SharePointサイト移行向け。前の列と同時指定しない |
CSVで最も多いミスは、不要な列を削ってしまうことです。たとえばファイル共有からSharePointへ移行する場合、Source DocLibとSource SubFolderは不要ですが、列自体は残して空欄にする必要があります。公式情報でも、前段で説明された列はすべて存在している必要があり、不要な場合は空欄にできるとされています。(Microsoft Learn)
CSVの記述例
次の例は、ファイル共有からSharePointへ移行するCSVの考え方です。1行に1つの移行元と移行先を定義します。
C:\MigrationData\Sales,,,https://contoso.sharepoint.com/sites/Sales,Documents,Archive
\\fileserver\share\HR,,,https://contoso.sharepoint.com/sites/HR,Documents,Shared
https://sharepoint2016.contoso.local/sites/Project,ProjectDocs,2025,https://contoso.sharepoint.com/sites/Project,Documents,OldProject1行目と2行目はファイル共有移行の例です。2列目と3列目は使わないため空欄ですが、カンマは残します。3行目はオンプレミスSharePoint Serverのライブラリとサブフォルダーを指定する例です。
Shared DocumentsではなくDocumentsを使う場面に注意
標準のドキュメントライブラリは画面上で「Shared Documents」と見えることがあります。しかし、公式情報では、標準のドキュメントライブラリを使う場合、CSVのSource Document Library列では内部名の Documents を使う必要があり、Shared Documents と入力すると「invalid document library」エラーになると説明されています。(Microsoft Learn)
これは日本語環境でも重要です。SharePointの画面表示が「ドキュメント」「共有ドキュメント」のようにローカライズされていても、移行ツールが参照する名前は内部名で判断される場合があります。移行前には、対象サイトのライブラリ一覧やURLを確認し、CSVへ入れる値を統一しておきましょう。
JSONファイルの基本フォーマット
JSONを使う場合は、Tasks 配列の中に移行タスクをオブジェクトとして定義します。公式情報では、最小必須値は SourcePath と TargetPath とされています。(Microsoft Learn)
| JSON項目 | 役割 | 必須度 | 使いどころ |
|---|---|---|---|
SourcePath | 移行元パスまたはSharePoint Server URL | 必須 | ファイル共有、SharePoint Serverサイト、サブサイトなど |
TargetPath | 移行先SharePoint / OneDriveのURL | 必須 | 移行先サイトまたはOneDrive |
TargetList | 移行先ライブラリまたはリスト名 | 任意 | 特定ライブラリへ入れたい場合 |
TargetListRelativePath | 移行先ライブラリ内の相対パス | 任意 | サブフォルダーへ移行する場合 |
Items | リストやサブサイトなどの詳細指定 | 任意 | SharePoint Server移行で細かく指定したい場合 |
Lists | 移行対象リストの対応関係 | 任意 | 移行元リスト名と移行先リスト名を分けたい場合 |
SubSites | サブサイト移行の指定 | 任意 | サイト構造を含む移行定義を扱う場合 |
JSONの記述例
単純なファイル共有移行であれば、次のように書けます。
{
"Tasks": [
{
"SourcePath": "D:\\MigrationData\\Sales",
"TargetPath": "https://contoso.sharepoint.com/sites/Sales",
"TargetList": "Documents",
"TargetListRelativePath": "Archive"
},
{
"SourcePath": "\\\\fileserver\\share\\HR",
"TargetPath": "https://contoso.sharepoint.com/sites/HR",
"TargetList": "Documents",
"TargetListRelativePath": "Shared"
}
]
}JSONでは、Windowsパスのバックスラッシュをエスケープする必要があります。たとえば D:\MigrationData\Sales は、JSON内では D:\\MigrationData\\Sales のように書きます。UNCパスも \\\\fileserver\\share\\HR のようになります。
このエスケープ処理は、開発者がスクリプトでJSONを生成する場合に特に注意が必要です。文字列結合でJSONを作るより、PowerShell、Python、C#などの標準JSONシリアライザーを使った方が安全です。
CSVとJSONはどちらを選ぶべきか
CSVとJSONのどちらを使うべきかは、移行タスクの複雑さで判断すると失敗しにくくなります。
| 判断基準 | CSVが向いているケース | JSONが向いているケース |
|---|---|---|
| 移行内容 | ファイル共有からSharePoint / OneDriveへの単純な移行 | SharePointサイト、リスト、サブサイトを含む複雑な移行 |
| 作成者 | Excelで一覧管理したい管理者 | スクリプトやCI的なチェックを行う開発者 |
| レビュー | 部門担当者に表形式で確認してもらいたい | 構造化データとして差分管理したい |
| ミスの傾向 | 列ずれ、空欄列の削除、内部名の誤り | エスケープ漏れ、プロパティ名の誤り、JSON構文エラー |
| 再利用性 | 同じ形式のタスクを大量に並べる場合に便利 | テンプレート化や自動生成に向いている |
実務では、移行元と移行先の対応表をCSVで作り、複雑なSharePoint Server移行だけJSONに分ける運用も有効です。すべてを1つの形式に統一するより、「レビューしやすさ」と「構造化しやすさ」で使い分ける方が現実的です。
管理者が確認すべき設定
JSON/CSVの形式だけを整えても、移行に必要な権限やSPMT設定が不足していると失敗します。SPMTを使う前に、管理者は権限、前提条件、エンドポイント、SPMT設定を確認するよう公式ドキュメントでも案内されています。(Microsoft Learn)
| 確認項目 | 確認内容 | 放置した場合のリスク |
|---|---|---|
| 管理者権限 | 組織レベルの移行はGlobal AdminまたはSharePoint Admin、サイトコレクション単位ではサイト管理者権限を確認 | 移行先サイトにタスクを作成できない |
| 移行元アクセス | SharePoint Serverやファイル共有に読み取り可能な権限があるか | スキャン失敗、ファイルの取りこぼし |
| SPMT実行端末 | CPU、RAM、空き容量、OS、.NET Frameworkなどを確認 | 移行速度低下、途中停止 |
| ネットワーク | Microsoft 365、SharePoint、Azure関連エンドポイントへ接続できるか | サインイン失敗、アップロード失敗 |
| 権限移行方針 | 権限を保持するか、移行先で再設計するか | 不要な権限継承、アクセス不能、過剰共有 |
| ユーザーマッピング | Microsoft Entra ID参照を使うか、独自マッピングファイルを使うか | 所有者や権限の紐付け失敗 |
| バージョン履歴 | 全バージョンを移行するか、件数制限するか | 移行容量増大、移行時間の長期化 |
| 除外条件 | 拡張子、作成日、更新日、隠しファイル、リスト、サブサイトなど | 不要データの移行、必要データの除外 |
| 作業フォルダー | SPMTの作業フォルダーに十分な空き容量があるか | パッケージ作成失敗、速度低下 |
SPMTの前提条件では、推奨構成として64bitクアッドコア以上、RAM 16GB、SSD 150GB以上の空き容量、1Gbpsネットワーク、Windows Server 2016またはWindows 10以降、.NET Framework 4.6.2以降などが示されています。最低要件でも150GBの空き容量が必要です。(Microsoft Learn)
また、SPMT設定には、スキャンのみ実行、自動移行開始、SharePoint権限保持、ファイル共有権限保持、Microsoft Entra IDによるユーザーマッピング、バージョン履歴、隠しファイル、除外拡張子、無効なファイル名文字の置換などがあります。(Microsoft Learn)
開発者が注意すべき実装ポイント
開発者がJSON/CSVを生成する場合は、単にファイルを出力するだけでなく、SPMTに渡す前の検証を組み込むべきです。移行定義ファイルのエラーは、本番移行当日に発覚すると関係部門との調整に直結します。
CSV生成では列数チェックを必ず入れる
CSVは見た目が単純な分、列ずれに気づきにくい形式です。特に、移行元や移行先にカンマを含む値が入る場合、引用符の扱いを誤ると列がずれます。
CSV生成時は、次のチェックを自動化しておくと安全です。
- 各行の列数が想定どおりか
- 必須列に空欄がないか
- ファイル共有移行の行でSource DocLibとSource SubFolderが空欄になっているか
- Target WebがSharePointまたはOneDriveの想定URLになっているか
- Target DocLibに表示名ではなく移行で必要な名前が入っているか
- RegisterAsHubSiteとAssociateWithHubURLが同時に入っていないか
Hub Site関連列については、Hub Site登録または既存Hub Siteへの関連付けのどちらかを指定する考え方です。公式情報では、サイトをHub Siteとして登録する場合はAssociateWithHubURLを空欄にし、既存Hub Siteへ関連付ける場合はRegisterAsHubSiteを空欄にすると説明されています。(Microsoft Learn)
JSON生成では構文チェックとパスのエスケープを行う
JSONは構造化しやすい反面、構文エラーがあるとファイル全体を読み込めません。手書きではなく、プログラムでオブジェクトを作ってJSONへ変換するのが基本です。
PowerShellであれば、移行タスクをオブジェクトとして作り、ConvertTo-Json で出力する流れが安全です。Pythonなら json.dumps()、C#なら System.Text.Json などを使います。
また、JSONのプロパティ名は大文字・小文字を含めて公式例に合わせるべきです。SourcePath を sourcePath と書いたり、TargetPath を TargetUrl と独自名にしたりすると、SPMTが期待する定義として扱えない可能性があります。
定義ファイルはGitや変更履歴で管理する
移行定義ファイルは、単なる一時ファイルではなく「どのデータを、どこへ、いつ移すか」を示す移行設計書でもあります。特に大規模移行では、CSVやJSONをバージョン管理し、誰がどの移行先を変更したか追えるようにしておくと、トラブル時の切り戻し判断がしやすくなります。
おすすめの管理方法は次のとおりです。
migration-dev.csv、migration-pilot.csv、migration-prod.csvのように環境別に分ける- 移行元部門、担当者、承認日を別シートや管理台帳で持つ
- 本番投入前のファイルにレビュー済みラベルを付ける
- SPMTへ投入したファイルを移行ログと一緒に保管する
移行前に必ず確認したいSPMT設定
SPMTでは、移行前スキャンや権限保持、ユーザーマッピング、バージョン履歴などの設定が移行結果に大きく影響します。JSON/CSVの作成後、すぐ本番移行へ進めるのではなく、設定を確認してから小規模なパイロット移行を実施しましょう。
| 設定 | 推奨される確認方法 |
|---|---|
| Only perform scanning | まずオンにして、移行前評価だけを実施する |
| Start migration automatically if no scan issue found | 本番前は不用意にオンにせず、スキャン結果を確認してから開始する |
| Preserve SharePoint permissions | 既存権限を維持する必要があるか、移行先で再設計するかを決める |
| Microsoft Entra lookup | ユーザーマッピングファイルを使う場合の挙動を確認する |
| Migrate file version history | すべての版を移行するか、件数制限するかを事前に決める |
| Replace invalid filename characters | 無効文字を置換するか、該当ファイルをスキップするかを判断する |
| Filter lists and libraries | 移行対象外のリスト・ライブラリがある場合に設定する |
| SharePoint Migration Tool working folder | 最低でも150GB以上の空き容量を確保する |
無効なファイル名文字の置換設定をオフにすると、該当ファイルはスキップされます。さらに、移行先サーバーに対して100件を超えるエラーを生成するパッケージはブロックされ、そのパッケージ内の有効なファイルもブロックされる可能性があると説明されています。(Microsoft Learn)
Hub Site関連列を使う場合の注意点
CSVの7列目と8列目は、SharePointサイト移行におけるHub Site関連の指定です。通常のファイル共有からドキュメントライブラリへ移すだけであれば、空欄のままで問題ありません。
ただし、サイト構造の再編を伴う移行では、Hub Site登録や関連付けを移行定義に含められるため、管理者は事前に情報アーキテクチャを決めておく必要があります。
注意点は、Hub Site関連の処理が移行の最終段階で行われることです。公式情報では、タスクを完了前に終了した場合、Hub Site関連の作業が実行されない可能性があり、既にHub Siteへ関連付けられているサイトの関連付けは変更されず、既にHub Siteとして登録されているサイトが解除されることもないと説明されています。(Microsoft Learn)
つまり、Hub Site関連列は「後から見れば分かる補足情報」ではなく、移行完了時のサイト構成に影響する重要な指定です。事前に次の点を確認してください。
- 移行対象サイトをHub Siteとして登録するのか
- 既存Hub Siteへ関連付けるのか
- すでにHub Site関連付け済みのサイトが含まれていないか
- 移行タスクを途中停止した場合の再実行手順を決めているか
OneDrive移行で特に気をつけること
OneDrive移行では、移行先がSharePointのチームサイトではなく、ユーザー個人のOneDrive URLになります。CSVの公式例でも、ローカルファイル共有からOneDriveの個人サイトへ移行する行が示されています。(Microsoft Learn)
実務で注意すべきなのは、ユーザーのOneDriveが事前にプロビジョニングされているか、移行先URLが正しいか、退職者・休職者・名称変更ユーザーをどう扱うかです。ホームドライブ移行では、ファイルの移行先だけでなく、所有者・権限・共有リンクの扱いも整理しないと、移行後にユーザーが必要なファイルへアクセスできない事態が起きます。
OneDrive向けCSVを作る場合は、次の項目を別台帳で管理するとレビューしやすくなります。
| 管理項目 | 例 | 確認理由 |
|---|---|---|
| ユーザーUPN | [email protected] | OneDrive所有者の確認 |
| 移行元ホームドライブ | \\fileserver\home\user | 移行元の読み取り権限確認 |
| OneDrive URL | 個人用OneDriveサイトURL | Target Webに入れる値の確認 |
| 移行先ライブラリ | Documents | Target DocLibに入れる値の確認 |
| 除外対象 | tmp、pst、古いバックアップなど | 不要データの移行防止 |
| 承認状況 | 承認済み、保留、対象外 | 本番投入ミス防止 |
移行性能と展開計画の注意点
JSON/CSVを使うと移行タスクを大量に作れますが、大量投入すれば速く終わるわけではありません。移行性能は、移行元の読み取り性能、ネットワーク、ファイルサイズ、ファイル数、SharePoint側のスロットリング、タスクの分割方法に左右されます。
Microsoftの移行性能ガイドでは、よい移行の第一原則として移行元を把握し、移行前に評価・整理することが説明されています。また、パッケージングでは少なくとも250ファイル、転送サイズでは100MB以上250MB未満のパッケージが推奨されています。(Microsoft Learn)
さらに、移行中はSPMTやサードパーティツールがMigration APIを使い、Azureを一時的な保持場所として利用します。Migration APIの段階では、可能であれば異なるサイトコレクションに対して並列タスクを実行することが推奨される一方、5,000件を超える移行ジョブやリクエストを同時にキューへ入れないよう案内されています。(Microsoft Learn)
展開計画では、次の順番で進めると安全です。
| フェーズ | 実施内容 | 成果物 |
|---|---|---|
| 棚卸し | 移行元のファイル数、容量、所有者、更新日、不要データを確認 | 移行対象一覧 |
| 設計 | 移行先サイト、ライブラリ、フォルダー、権限方針を決める | 移行設計書 |
| 定義作成 | CSVまたはJSONでSPMT用の移行タスクを作成 | 移行定義ファイル |
| 構文・列チェック | CSV列数、JSON構文、必須値、URL、ライブラリ名を検証 | チェック済みファイル |
| スキャン | SPMTで移行前スキャンを実施 | スキャンレポート |
| パイロット移行 | 代表部門や少量データで移行結果を確認 | 修正点一覧 |
| 本番移行 | 部門別・サイト別に段階実行 | 移行ログ、完了報告 |
大量移行では、夜間や週末など利用者影響が少ない時間帯を選び、移行タスクを分割して実行するのが基本です。スロットリングはSharePointの信頼性を保つために行われるため、サポート依頼で無効化できるものではありません。(Microsoft Learn)
プロキシ、カスタムスクリプト、カスタムAzure Storageの確認
企業ネットワークでは、SPMT実行端末がプロキシ配下にあるケースがあります。公式設定情報では、SharePointまたはファイル共有移行においてプロキシ接続はサポートされず、既定ではSPMTがシステムプロキシ資格情報を使わないため、構成によってはサインイン失敗やドキュメントライブラリを読み込めないエラーが発生することが説明されています。(Microsoft Learn)
また、SharePointのページやWebパーツを含む移行では、カスタムスクリプト設定も確認が必要です。移行中、一部のWebパーツではカスタムスクリプト許可が必要になる場合があり、少なくとも移行開始24時間前に設定を行うよう案内されています。(Microsoft Learn)
カスタムAzure Storageを使う場合は、コストと認証方式の確認も必要です。SPMT設定では独自Azure Storageの利用、Entra認証によるアップロードや取り込み、暗号化、一時作業ファイル削除などの項目が説明されています。(Microsoft Learn)
これらはJSON/CSVの形式とは直接関係ないように見えますが、本番移行では同時に問題化しやすい設定です。定義ファイルのレビューだけでなく、実行環境のネットワーク・認証・セキュリティ設定も確認してください。
PowerShellで扱う場合の考え方
SPMTはPowerShellからも利用できます。公式情報では、SPMTのすべての機能がPowerShellでもサポートされていると説明されています。(Microsoft Learn)
開発者や移行エンジニアがPowerShellを使う場合は、JSON定義ファイルとの相性がよくなります。たとえば、移行元一覧をCSVで管理し、PowerShellで読み込んでJSONへ変換する、部門ごとに定義ファイルを分割する、移行前のURL存在チェックを行う、といった自動化が可能です。
PowerShellベースの移行では、PowerShell 5.xや.NET Framework 4.6.2以降が長いファイルパス移行のサポートに必要とされています。また、PowerShell 6.0以降はサポートされないと説明されています。(Microsoft Learn)
実務では、次のような役割分担が扱いやすいです。
| 役割 | 担当内容 |
|---|---|
| 管理者 | 移行先サイト、権限、SPMT設定、実行スケジュールを決める |
| 開発者 | CSV/JSON生成、構文チェック、重複チェック、ログ保管を自動化する |
| 部門担当者 | 移行元・移行先の対応表と除外対象を確認する |
| セキュリティ担当 | 権限保持、共有設定、外部共有、監査要件を確認する |
よくある失敗と対策
| 失敗例 | 原因 | 対策 |
|---|---|---|
| CSVを読み込めない | 列数不足、カンマのずれ、不要列の削除 | すべての列を保持し、行ごとに列数チェックを行う |
invalid document library エラーが出る | Shared Documents など表示名を入れている | 内部名 Documents を確認して入力する |
| ファイル共有移行でSource DocLibに値を入れている | SharePoint移行とファイル共有移行の列ルールを混同 | ファイル共有行では2列目・3列目を空欄にする |
| JSONが読み込めない | バックスラッシュのエスケープ漏れ、JSON構文エラー | JSONシリアライザーを使い、投入前に構文検証する |
| 権限が期待どおり移行されない | 権限保持やユーザーマッピング方針が未決定 | Microsoft Entra ID参照またはマッピングファイルを事前に決める |
| 移行が遅い | 小さなファイルが多い、タスク過多、ピーク時間帯に実行 | 移行元を整理し、タスク分割と実行時間帯を見直す |
| Hub Site関連付けが反映されない | タスクを完了前に停止した、既存関連付けがある | Hub Site列の指定と完了状態を確認する |
| SPMTがMicrosoft 365へ接続できない | エンドポイント、プロキシ、認証の問題 | 事前にネットワーク要件とプロキシ構成を確認する |
特にCSVは、Excelで開いて保存したときに文字コードや引用符、先頭のゼロ、パス表記が変わることがあります。移行直前にテキストエディターでも開き、カンマ区切りの構造が崩れていないか確認してください。
管理者・開発者向けの実務チェックリスト
本番移行前には、次のチェックを最低限実施しましょう。
| チェック | 完了条件 |
|---|---|
| 移行元の棚卸し | ファイル数、容量、所有部門、不要データ、最終更新日を確認済み |
| 移行先設計 | サイト、ライブラリ、サブフォルダー、OneDrive URLを確定済み |
| CSV/JSON形式 | 必須列・必須プロパティ、空欄列、JSON構文を検証済み |
| ライブラリ名 | 表示名ではなく、移行で必要な名前を確認済み |
| 権限方針 | 既存権限を保持するか、移行先で再設計するか決定済み |
| ユーザーマッピング | Microsoft Entra ID参照またはマッピングファイルの方針を決定済み |
| SPMT設定 | スキャン、バージョン履歴、除外条件、無効文字置換を確認済み |
| 実行環境 | SPMT端末の空き容量、OS、.NET、ネットワーク接続を確認済み |
| パイロット移行 | 少量データでスキャン・移行・結果確認を実施済み |
| ロールバック方針 | 移行中止、再実行、差分移行、利用者周知の手順を決定済み |
次に取るべき行動
SharePoint / OneDriveのデータ移行でJSONまたはCSVを使う場合、最初にやるべきことは、SPMTへ投入する移行定義ファイルを作ることではありません。まず移行元の棚卸しを行い、移行先のサイト・ライブラリ・フォルダー設計、権限方針、ユーザーマッピング、除外条件を決める必要があります。
そのうえで、単純な移行はCSV、複雑なSharePoint Server移行やスクリプト生成を前提にする場合はJSONを選びます。CSVでは列を削除せず、JSONでは SourcePath と TargetPath を必ず確認してください。標準ドキュメントライブラリの内部名、OneDrive URL、Hub Site関連列、SPMT設定、移行前スキャンまで確認できれば、本番移行時の手戻りを大きく減らせます。
まずは小さな部門や検証用サイトでパイロット移行を行い、エラー内容、移行速度、権限、ファイル名、バージョン履歴、ユーザーからの見え方を確認してください。その結果をCSV/JSONテンプレートへ反映してから、部門別・サイト別に段階展開するのが安全です。
コメント