SharePoint Migration Tool（SPMT）で移行タスクを作成する際に最初に判断すべきことは、「サイト全体を移すのか」「リストやドキュメント ライブラリ単位で移すのか」「ワークフローを Power Automate へ移すのか」「CSV/JSONで大量登録するのか」です。2026年6月30日に更新された公式情報では、SPMTのタスク作成手順がこの4つの移行パターンを軸に整理されています。英語版の公式ページは 2026年6月30日更新、日本語版では 2026年7月1日更新として表示される場合があります。(Microsoft Learn)
結論として、今回の「Create a task in SharePoint Migration Tool (SPMT) – Migrate to Microsoft 365」は、単なる操作手順ではなく、移行方式の選び方を間違えないための実務向けガイドとして読むべき内容です。特に、SharePoint Server 2016/2019 を利用している組織は、2026年7月14日のサポート終了予定を踏まえ、SPMTによる Microsoft 365 への移行計画を急いで具体化する必要があります。(Microsoft Learn)
SharePoint の「Create a task in SharePoint Migration Tool (SPMT)」で押さえるべき更新ポイント
今回確認すべきポイントは、SPMTの画面操作そのものよりも、移行タスク作成時の判断軸です。公式情報では、移行タスク作成時に、サイト移行、リストとドキュメント ライブラリの移行、ワークフローの移行、CSVまたはJSONファイルを使った一括移行を選択できると説明されています。(Microsoft Learn)
| 移行方式 | 使うべき場面 | 実務上の判断基準 |
|---|---|---|
| サイト移行 | SharePoint Server のサイト構造、サブサイト、ページ、リスト、ライブラリをまとめて移行したい場合 | サイト単位で業務がまとまっており、移行後も同じ情報設計を使いたい場合に向く |
| リストとドキュメント ライブラリの移行 | 特定のライブラリやリストだけを Microsoft 365 に移したい場合 | 部門共有フォルダーや文書管理ライブラリだけを先行移行したい場合に向く |
| ワークフローの移行 | SharePoint Server ワークフローを Power Automate に移行したい場合 | 承認、フィードバック収集、通知などの業務フローをクラウド化したい場合に向く |
| CSV/JSONによる一括移行 | 移行元が多数あり、画面から1件ずつ登録すると非効率な場合 | 複数部門・複数サイト・大量ライブラリを計画的に移す場合に向く |
実務では、「とりあえずサイト移行」を選ぶと失敗しやすくなります。たとえば、古いサブサイト構造をそのまま移す必要がない場合は、リストやライブラリ単位で移したほうが、移行後のSharePoint設計を整理しやすくなります。一方で、サイトのナビゲーション、ページ、リスト、権限構造まで含めて再現したい場合は、サイト移行を選ぶ価値があります。
影響範囲：対象になる環境と管理者
SPMTは、オンプレミスの SharePoint Server 2010、2013、2016、2019、および SharePoint Foundation 2010/2013 から、SharePoint、OneDrive、Teams への移行をサポートします。また、SharePoint Server 2010 のOOTBワークフローや SharePoint Designer 2010/2013 ワークフローの移行にも対応しています。(Microsoft Learn)
今回の情報を確認すべき担当者は、SharePoint管理者だけではありません。移行先のMicrosoft 365テナント管理者、ネットワーク管理者、セキュリティ担当者、業務部門のサイト所有者も関係します。
| 担当者 | 確認すべきこと |
|---|---|
| Microsoft 365 管理者 | 移行先テナント、SharePoint管理者権限、サイト管理者権限、ライセンス、外部共有設定 |
| SharePoint Server 管理者 | 移行元サイト、リスト、ライブラリ、ワークフロー、権限、カスタマイズ状況 |
| ネットワーク管理者 | SPMT端末からMicrosoft 365関連エンドポイントへ接続できるか |
| セキュリティ担当者 | ユーザーマッピング、アクセス許可の移行、証明書ベース認証、監査要件 |
| 業務部門 | 移行対象、不要データ、移行後の運用ルール、切り替え日 |
特にグローバル企業では、一般商用クラウドだけでなく、GCC、GCC High、DoDなどの政府機関向けクラウドを利用している拠点があるかを確認する必要があります。SPMTの設定ページでは、政府機関向けクラウドを使う場合に SPOEnvironmentType の値を変更する手順が案内されています。(Microsoft Learn)
なお、中国の 21Vianet が運用する Office 365 では、SPMTを利用できないと公式情報に記載されています。グローバル展開で中国拠点を含む場合は、同じ移行手順をそのまま適用できない点に注意してください。(Microsoft Learn)
移行期限：SPMTの期限ではなく、SharePoint Serverのサポート期限を基準に考える
今回の「Create a task in SharePoint Migration Tool (SPMT)」ページ自体は、「この日までにSPMTで移行しなければならない」という新しい期限を示しているわけではありません。移行期限として見るべきなのは、利用中のSharePoint Serverや関連製品のライフサイクルです。
Microsoft Lifecycleの公式情報では、SharePoint Server 2016 と SharePoint Server 2019 は 2026年7月14日にサポート終了対象として示されています。SharePoint Server 2019 の製品別ライフサイクルページでも、延長サポート終了日が 2026年7月14日とされています。(Microsoft Learn)
このため、SharePoint Server 2016/2019 を運用している組織では、SPMTのタスク作成手順を「いつか使う移行手順」ではなく、サポート終了前後の移行・アップグレード計画に直結する作業として扱うべきです。
| 状況 | 推奨アクション |
|---|---|
| SharePoint Server 2016/2019 を継続運用している | サポート終了日を基準に、移行可否、代替策、残存リスクを整理する |
| Microsoft 365 へ移行予定だが未着手 | SPMTでスキャンし、移行リスクとデータ量を把握する |
| すでに一部を移行済み | 増分移行と最終切り替え日を決め、移行済みファイルの移動・リネームを制限する |
| ワークフローが残っている | Power Automateへ移行できる処理と再設計が必要な処理を分ける |
| グローバル拠点がある | テナント、クラウド種別、ネットワーク、言語・権限体系を拠点別に確認する |
SPMTで移行タスクを作成する前に確認すべき前提条件
SPMTで移行タスクを作る前に、資格情報、権限、ネットワーク、端末スペックを確認します。公式手順では、SPMTを初めて開くとMicrosoft 365のユーザー名とパスワードが求められ、指定する資格情報は移行先のものである必要があると説明されています。また、プロキシ接続はサポートされず、利用すると「SharePoint login fail」や「Can’t load document library」などのエラーにつながる可能性があります。(Microsoft Learn)
| 確認項目 | 実務での確認ポイント |
|---|---|
| 移行先の権限 | 組織レベルの移行ではグローバル管理者またはSharePoint管理者、サイトコレクション単位ではサイト管理者権限を確認する |
| 移行元の権限 | SharePoint Server側の対象コンテンツに読み取りアクセスできるアカウントを準備する |
| 端末スペック | 推奨要件として、64ビットクアッドコアCPU、16GB RAM、SSD 150GB空き容量、1Gbps NIC、Windows Server 2016またはWindows 10以降、.NET Framework 4.6.2以降が示されている |
| ネットワーク | Microsoft 365、Microsoft Graph、Azure Blob/Queue、SharePoint Onlineなどの必要エンドポイントへの通信を確認する |
| プロキシ | 標準ではプロキシ接続が移行エラーの原因になりやすいため、利用可否を事前に検証する |
| 事前スキャン | 本番移行の前にSPMTのスキャンでリスクを洗い出す |
SPMTの前提条件ページでは、CPU、RAM、ストレージ、ネットワークカード、OS、.NET Frameworkの推奨要件に加えて、認証、Microsoft 365 API、Microsoft Graph、Azure Blob/Queue、SharePoint Onlineなどのエンドポイントが示されています。移行失敗の多くは、SPMTの操作ミスではなく、権限不足、通信制限、事前評価不足から発生します。(Microsoft Learn)
サイト移行を選ぶ場合の手順と判断ポイント
サイト移行は、SharePoint Serverのサイトを単位として、サブサイトを含めて移行したい場合に使います。公式手順では、SPMTを起動してMicrosoft 365の資格情報を入力し、[新しい移行の追加]、[単一ソースURL]、[サイトの移行]を選択し、移行元SharePoint ServerサイトのURLを入力する流れになっています。(Microsoft Learn)
サイト移行で重要なのは、途中で選択するサイト構造です。SPMTでは、従来のサイト構造を保持するか、モダンサイト構造に切り替えるかを選択できます。モダンサイト構造に切り替える場合、昇格されたレベル1のサブサイトをハブに関連付ける選択もできます。(Microsoft Learn)
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| 従来のサイト構造を保持 | 既存のサブサイト構造、権限設計、URL構造をできるだけ残したい | 古い情報設計も一緒に残るため、移行後に整理が必要になることがある |
| モダンサイト構造に切り替える | Microsoft 365移行を機に、フラットなサイト構成やハブサイト中心の設計に見直したい | 移行前にハブサイト、ナビゲーション、所有者、権限設計を決めておく必要がある |
| ハブサイトに関連付け | 部門・地域・事業単位でサイト群を整理したい | 既存ハブに関連付けるのか、移行先をハブとして登録するのかを事前に決める |
実務では、サブサイトが多い環境ほど「そのまま移す」より「移行を機に整理する」ほうが、移行後の運用負荷を下げられます。たとえば、営業部門の古いサブサイトが年度別に大量にある場合、すべてを現役サイトとして移すのではなく、現行業務サイト、アーカイブ、廃棄対象に分けてからSPMTタスクを作成すると、移行後の検索性と権限管理が改善します。
リスト・ドキュメント ライブラリ移行を選ぶべきケース
リストとドキュメント ライブラリの移行は、サイト全体ではなく、特定のリストやライブラリだけを移したい場合に適しています。公式手順では、[単一ソースURL]を選択したうえで、移行の種類としてリストまたはドキュメント ライブラリの移行を選び、移行先として Microsoft Teams、SharePoint、OneDrive を指定できます。(Microsoft Learn)
この方式は、次のようなケースで有効です。
- 部門ファイル共有として使っているドキュメント ライブラリだけを先に移す
- 古いサイトのうち、現行業務で使っているリストだけを移す
- Teamsのチャネル運用に合わせて、関連ドキュメントを移行する
- サイト構造は作り直し、必要なコンテンツだけを移す
注意点は、移行元の「サイト全体の文脈」が失われやすいことです。ライブラリ単位で移す場合でも、ビュー、列、コンテンツタイプ、メタデータ、権限、業務ルールを事前に棚卸ししてください。特に、リストを業務アプリのように使っている場合は、Power Automate、Power Apps、外部連携、通知ルールまで含めて確認する必要があります。
ワークフロー移行は「変換できるか」より「業務として再現できるか」で判断する
SPMTは、SharePoint ServerワークフローをPower Automateへ移行する選択肢を提供しています。ただし、SharePoint Designerワークフローの移行では、すべてのアクションが完全に移行できるわけではありません。公式情報では、SPMT 4.1が SharePoint Designer 2010/2013 ワークフローの移行をサポートする一方で、現在のリリースで移行できるのは一部の一般的なアクションであり、未サポートのアクションもあると説明されています。(Microsoft Learn)
たとえば、メール送信、変数設定、日付までの待機、アイテム作成、承認開始などはPower Automateのアクションへ変換される例があります。一方で、HTTP Webサービス呼び出し、辞書操作、一部の待機処理、レコード宣言、ループ、並列ブロックなど、移行されないアクションも明示されています。(Microsoft Learn)
ワークフロー移行で失敗しやすいのは、「SPMTで移行できたから業務も動く」と考えることです。Power Automateへ変換された後は、承認者、通知先、権限、実行アカウント、エラー時の再実行、監査ログを確認する必要があります。特に承認フローは、移行後に業務部門と一緒にテストし、差し戻し、代理承認、期限切れ、添付ファイルの扱いまで確認してください。
CSV/JSONによる一括移行は、大規模移行の標準手段として使う
移行元が多い場合は、画面から1件ずつタスクを作成するより、CSVまたはJSONファイルを使った一括移行が現実的です。公式手順では、SPMTで[JSONまたはCSVファイルを使用した一括移行]を選択し、CSVまたはJSONファイルの完全なパスを指定して進めます。ファイル内にエラーがある場合は行単位で検出され、修正するまで続行できません。(Microsoft Learn)
CSV一括アップロードでは、移行元、移行元ドキュメント ライブラリ、移行元サブフォルダー、移行先Webなどを列として指定します。多数のタスクを作成する場合に有効で、Excelやテキストエディターで作成できます。(Microsoft Learn)
大規模移行では、CSV/JSONを単なる入力ファイルではなく「移行台帳」として管理すると効果的です。移行元URL、移行先URL、担当部門、所有者、移行方式、移行予定日、検証担当者、完了ステータスを別シートで管理すれば、タスク作成、進捗管理、問い合わせ対応がしやすくなります。
増分移行で注意すべきこと
SPMTでは、移行タスク完了後にタスクを保存し、後で再実行することで、移行元に新しく追加または更新されたファイルだけをコピーできます。これが増分移行です。公式情報では、この設定を変更する場合は最初の移行ジョブを送信する前に変更する必要があり、この設定はグローバルで後続タスクにも適用されると説明されています。(Microsoft Learn)
増分移行は、移行期間が長いプロジェクトで非常に重要です。たとえば、初回移行で大量データを事前コピーし、最終切り替え日に差分だけを移す運用ができます。ただし、公式情報では、最終移行が完了する前に移行済みファイルの名前変更や移動を行わないことが強く推奨されています。これを行うと、ファイルが上書きされる可能性があります。(Microsoft Learn)
| 増分移行の状況 | 結果 |
|---|---|
| 移行元ファイルの更新日時が移行先より古い | ファイルは移行されない |
| 移行先にファイルやリストが存在する | スキャン中に既存オブジェクトがスキップされる |
| 移行元のファイルやオブジェクトの方が新しい | 新しいファイルが移行される |
| 移行元がファイル共有 | ファイルまたはフォルダーパスを基準に検証される |
| 移行元がオンプレミスSharePoint Server | リストアイテムGUIDを基準に検証され、フォルダーパスがフォールバックとして使われる |
実務では、初回移行後に利用者が移行先SharePointでファイル名を変えたり、フォルダーを移動したりしないよう、明確な利用制限を周知してください。最終切り替え前に移行先を自由に編集させると、増分移行時の上書きや重複、差分漏れの原因になります。
設定変更で特に確認すべき項目
SPMTの詳細設定は、移行結果に大きく影響します。公式の設定ページでは、アクセス許可の保持、ユーザーマッピング、バージョン履歴、無効なファイル名文字の置換、サイト設定、管理されたメタデータ、カスタムAzure Storageなどの設定が説明されています。(Microsoft Learn)
| 設定項目 | 確認すべき理由 | 推奨される考え方 |
|---|---|---|
| SharePointアクセス許可を保持する | 移行元の権限を移行先に反映するかを左右する | そのまま移す前に、不要な個別権限や退職者アカウントを整理する |
| Microsoft Entra参照・ユーザーマッピング | 旧ADユーザーとMicrosoft 365ユーザーの対応付けに影響する | グローバル企業では国・拠点ごとのアカウント体系を事前に確認する |
| ファイルのバージョン履歴 | 移行データ量と移行時間に直結する | すべて保持するのか、必要な世代数に絞るのかを情報管理ルールで決める |
| 無効なファイル名文字の置換 | 移行失敗やスキップの原因になる | 置換ルールを決め、業務部門に変更内容を説明する |
| サイト設定の移行 | タイトル、ロゴ、機能、監査設定などに影響する | 移行後に新しいサイト設計へ変える場合は、すべて保持しない選択も検討する |
| 管理されたメタデータ | 用語ストアや分類情報に影響する | グローバル用語ストアを使う場合は、管理権限と用語設計を確認する |
| カスタムAzure Storage | 大量移行時のストレージ利用、コスト、権限に影響する | Entra認証、Storage Blob Data Contributorロール、削除ポリシーを確認する |
カスタムAzure Storageを使う場合、公式情報では、Azure Storage利用時に帯域幅料金が発生する可能性があること、Entra認証を使う場合にストレージアカウントのセキュリティプリンシパルへ「Storage Blob Data Contributor」ロールを割り当てることが説明されています。(Microsoft Learn)
また、SPMTのリリースノートでは、SPMT 4.1.130.0の新機能として、カスタムAzure StorageアクセスのEntra認証が示されています。大量移行やセキュリティ要件の厳しい組織では、従来のアカウントキー運用ではなく、Entra IDベースの認証設計を検討する価値があります。(Microsoft Learn)
管理者が移行前に実施すべきチェックリスト
SPMTの移行タスク作成は、単独の作業ではなく、移行プロジェクト全体の中間地点です。タスクを作る前に、少なくとも次の項目を確認してください。
| フェーズ | チェック項目 |
|---|---|
| 棚卸し | 移行元サイト、リスト、ライブラリ、ワークフロー、容量、所有者を一覧化する |
| 事前評価 | SPMTのスキャンでサイトコンテンツのインベントリと移行リスクを確認する |
| 設計 | 移行先サイト、ハブサイト、Teams連携、OneDrive利用範囲を決める |
| 権限 | 管理者権限、サイト所有者、ユーザーマッピング、ゲスト共有の扱いを決める |
| データ整理 | 不要データ、重複ファイル、古いバージョン、無効なファイル名を整理する |
| ワークフロー | Power Automateへ移行できるものと再設計が必要なものを分類する |
| 通信 | 必要エンドポイント、プロキシ、ファイアウォール、帯域を確認する |
| テスト | パイロット移行で権限、検索、リンク、メタデータ、ワークフローを検証する |
| 本番移行 | 初回移行、増分移行、編集停止、最終切り替えのタイムラインを決める |
| 移行後 | 利用者案内、問い合わせ窓口、旧環境の読み取り専用化、廃止計画を決める |
公式情報では、SPMT 4.0以降でSharePoint Server評価がツールに統合され、移行前にソースサイトをスキャンし、評価結果を確認してから移行を開始できると説明されています。スキャン結果ダッシュボードでは、サイトコンテンツのインベントリと潜在的な移行リスクの概要を確認し、詳細レポートをダウンロードできます。(Microsoft Learn)
よくある失敗と回避策
既存のサイト構造をそのまま移して、移行後に使いにくくなる
古いSharePoint Serverでは、部門、年度、プロジェクトごとにサブサイトが増え続けていることがあります。この構造をそのまま移すと、Microsoft 365移行後も階層が深く、検索や権限管理が複雑なまま残ります。
回避策は、移行前に「現役サイト」「アーカイブ」「廃止」の3分類を行うことです。現役サイトはモダンサイトやハブサイトで再設計し、アーカイブは読み取り中心のライブラリとして分けると、移行後の管理が楽になります。
権限を保持した結果、不要な個別権限まで移行される
SPMTではアクセス許可の保持に関する設定がありますが、既存環境に複雑な個別権限が多い場合、そのまま移すと移行後の監査や問い合わせ対応が難しくなります。(Microsoft Learn)
回避策は、移行前に権限継承の切断箇所、退職者アカウント、旧部門グループ、個人付与権限を棚卸しすることです。移行を機に、Microsoft 365グループ、SharePointグループ、Entra IDグループのどれで管理するかを決めてください。
ワークフローを自動変換できると考えてしまう
SharePoint Designerワークフローには、SPMTで移行されないアクションがあります。未サポートアクションが含まれる場合、既定ではワークフロー移行が停止し、エラーが報告されます。設定により、未サポートアクションをComposeへ変換して移行を継続する選択肢もありますが、それは業務動作の保証ではありません。(Microsoft Learn)
回避策は、ワークフローを「移行対象」ではなく「業務プロセス再設計対象」として扱うことです。移行前に、起動条件、承認者、通知文面、エラー処理、監査要件を確認し、Power Automateで再現すべき仕様を明文化してください。
増分移行中に移行先ファイルを編集してしまう
初回移行後に利用者へ移行先サイトを開放すると、最終切り替え前にファイル名変更やフォルダー移動が発生し、増分移行時の上書きリスクが高まります。公式情報でも、最終移行が終わる前に移行済みファイルの名前変更や移動をしないことが強く推奨されています。(Microsoft Learn)
回避策は、初回移行後の移行先を検証用または読み取り専用にし、編集開始日を明確に分けることです。切り替え日までは、移行元を正本として扱うのか、移行先を正本にするのかを全利用者に周知してください。
次に取るべき行動
SharePoint の「Create a task in SharePoint Migration Tool (SPMT) – Migrate to Microsoft 365」を確認する管理者は、まず移行対象を4分類してください。サイト全体、リスト・ライブラリ単位、ワークフロー、CSV/JSON一括移行のどれに該当するかを決めるだけで、移行設計の精度が上がります。
次に、SPMTのスキャンで移行リスクを確認し、移行先のSharePoint構造、ハブサイト、権限、ユーザーマッピング、バージョン履歴、メタデータ、ワークフロー再設計方針を固めます。SharePoint Server 2016/2019を利用している場合は、2026年7月14日のサポート終了予定を基準に、移行完了日、検証期間、最終切り替え日を逆算してください。
SPMTは無料で使える便利な移行ツールですが、成功の鍵はボタン操作ではなく、移行前の棚卸しと判断です。移行タスクを作成する前に、「何を移すか」「何を捨てるか」「移行後にどう運用するか」を決めることが、SharePoint移行を安全に進める最短ルートです。
コメント