ファイルサーバーの資料をSharePoint Onlineへ移行すると、ドキュメントライブラリの作成日（Created）がアップロード日になり、監査や運用で困ることがあります。元の作成日時を残す3つの実践策（PnP PowerShell、カスタム列、SPMT）を手順と注意点つきで解説します。
SharePoint Onlineで「作成日（Created）」がアップロード日に変わるのはなぜ？
SharePoint Onlineのドキュメントライブラリにある「作成日（Created）」と「更新日（Modified）」は、ファイルそのものの“Windowsファイルシステムの日時”ではなく、ライブラリ内のアイテム（リストアイテム）として登録された日時です。ブラウザーでドラッグ＆ドロップや「アップロード」をすると、その時点で新しいアイテムが作られるため、基本的にCreated/Modifiedはアップロード時点の値になります。
つまり、手動アップロードだけで「ローカルの元の作成日時」をSharePoint標準のCreatedに反映させることは難しく、“移行ツール”や“API/スクリプトでメタデータを上書きする仕組み”が必要になります。
まず整理：残したい「日時」はどれ？（混同しやすいポイント）
「元の作成日時」と一口に言っても、実務では複数の“日時”が登場します。ここを最初に整理しておくと、移行後のトラブル（表示が合わない、監査で説明できない、検索が不便など）を減らせます。
| 日時の種類 | 主な意味 | どこで見える | 落とし穴 |
|---|---|---|---|
| ローカルの作成日時（CreationTime） | ファイルがそのサーバー上で作られた時刻 | Windowsのプロパティ | コピーや復元、移動で変わる場合がある（運用・ツール次第） |
| ローカルの更新日時（LastWriteTime） | 最後に内容が更新された時刻 | Windowsのプロパティ | エクスプローラー操作や一部アプリ保存で意図せず更新されることがある |
| Office文書の内部プロパティ（作成/最終更新など） | Word/Excel/PowerPointが保持する文書プロパティ | Officeのファイル情報 | Office以外のファイル（PDF、画像等）にはない／編集で変化する |
| SharePointの作成日（Created） | ライブラリに“アイテムとして登録”された時刻 | ライブラリ列（Created） | 通常アップロードではアップロード日時になるのが基本 |
| SharePointの更新日（Modified） | ライブラリ上で最後に更新された時刻 | ライブラリ列（Modified） | メタデータ編集でも更新される（内容更新と区別が必要） |
| カスタム列（例：元の作成日） | ローカルの日時を“業務用に保持”する | 任意の列として表示・検索 | 列を作るだけでは自動で埋まらない（投入手段が必要） |
この整理を踏まえると、やりたいことは次のどちらかに分かれます。
- A：SharePoint標準のCreated/Modified自体を、元の日時に合わせたい（監査・要件が厳しい、検索・並び替えも標準列で行いたい）
- B：SharePoint標準のCreated/Modifiedはアップロード日でもよいが、元の日時を別の列で見たい（運用上の表示・管理が目的）
解決策の全体像：現実的な3パターン
ローカルの元日時をSharePointに持ち込む方法は、現場ではだいたい次の3パターンに収束します。
| 方法 | SharePoint標準Created/Modifiedを元に戻せる | 「元の作成日」列での管理 | 向いているケース | 注意点 |
|---|---|---|---|---|
| PnP PowerShellでアップロード＋メタデータ明示設定 | 条件次第で可能 | 可能 | 対象範囲が明確／スクリプト運用できる／細かく制御したい | 権限・手順が必要／大量移行は設計が要る |
| 「元の作成日」カスタム列を作って分離管理 | 不要（標準列はそのまま） | 必須 | 表示・検索に使えればOK／標準列の改変要件がない | 投入を自動化しないと手作業地獄になりやすい |
| SharePoint Migration Tool（SPMT）で移行 | 目的を満たしやすい | 必要なら可能 | ファイルサーバー→SharePointの本格移行／日時・属性を極力維持したい | 事前準備（パス、権限、ライブラリ設計）が重要 |
PnP PowerShellで「アップロード時に日時メタデータを明示設定」する
スクリプトでアップロードする最大のメリットは、アップロードと同時にメタデータを指定できることです。要件が「標準のCreated/Modifiedも元に戻したい」場合も、ツールや権限条件が揃えば実現しやすくなります。
事前に確認すべきポイント
| 確認項目 | 理由 | 最低限の目安 |
|---|---|---|
| 権限 | システム列（Created/Modifiedなど）を書き換えるには権限が必要になりやすい | サイト/ライブラリ管理相当の権限を想定 |
| タイムゾーン | ローカルとSharePoint側で表示がずれる原因になりやすい | どのタイムゾーンの値を登録するか決める |
| バージョン管理 | メタデータ更新で版が増える、更新者が変わる等が起きやすい | 移行中は版管理の運用を一時調整することも検討 |
| 必須列/コンテンツタイプ | 必須メタデータがあるとアップロードが失敗しやすい | 必要な列はスクリプトで同時投入する |
基本方針：おすすめは「標準列にこだわる前に、元日時をカスタム列にも保存」
実務では、監査要件が厳しくない限り、次の二段構えが安全です。
- まず「元の作成日」「元の更新日」などのカスタム列を作って、確実にそこへ保存する
- 必要な場合のみ、SharePoint標準のCreated/Modifiedにも反映を試みる（権限・制約により失敗する可能性があるため）
ライブラリに作っておきたいカスタム列（例）
ドキュメントライブラリに、次のような列を用意しておくと運用が安定します。
| 列名（例） | 種類 | 用途 | ポイント |
|---|---|---|---|
| 元の作成日 | 日付と時刻 | ファイルサーバーのCreationTimeを保存 | 並び替え・フィルタで使いやすい |
| 元の更新日 | 日付と時刻 | ファイルサーバーのLastWriteTimeを保存 | 更新履歴の目安になる |
| 移行元パス | 1行テキスト | 移行元のフルパスや共有名 | 問い合わせ対応が楽になる |
| 移行バッチID | 1行テキスト | 何回目の移行/どのジョブか識別 | 差分移行・失敗追跡に有効 |
サンプル：ローカル日時を読み取り、ファイルをアップロードし、カスタム列へ投入する
以下は考え方が伝わる形の例です。実際の列内部名（Internal Name）やライブラリ名、フォルダー指定は環境に合わせてください。PnP PowerShellはバージョンによりパラメータや挙動が変わることがあるため、実行前にヘルプで確認してください。
# 事前：PnP PowerShell をインストール（未導入の場合）
# Install-Module PnP.PowerShell -Scope CurrentUser
# SharePoint に接続（対話ログイン例）
Connect-PnPOnline -Url "https://{tenant}.sharepoint.com/sites/{site}" -Interactive
$libraryName = "ドキュメント" # 例：Documents / Shared Documents の表示名に合わせる
$targetFolder = "Shared Documents/General" # ライブラリ配下のフォルダー（例）
# ローカルのファイル一覧（必要に応じてフィルタ）
$files = Get-ChildItem "D:\FileServerData" -File -Recurse
foreach ($f in $files) {
$originalCreated = $f.CreationTime
$originalModified = $f.LastWriteTime
# 1) まずアップロード（カスタム列に元日時を保存）
Add-PnPFile -Path $f.FullName -Folder $targetFolder -Values @{
"元の作成日" = $originalCreated
"元の更新日" = $originalModified
"移行元パス" = $f.FullName
}
# 2) ここで必要なら、標準の Created/Modified を上書きする処理を追加
# （環境・権限・手順により可否が分かれるため、検証用サイトで必ずテスト）
}
標準のCreated/Modifiedも元に戻したい場合の考え方
「SharePointのCreated/Modifiedを元の日時にしたい」という要件はよくありますが、ここは少し癖があります。SharePoint標準列はUIでは編集できず、スクリプトでも更新方法（Updateの種類）や権限、ライブラリ設定に影響されます。
- アップロード後に、そのファイルのリストアイテムを取得してフィールド値を書き換える
- 更新時に「版を増やす/増やさない」「更新者を変える/変えない」などの挙動を制御する
- 監査・保持ポリシー・レコード管理が有効な場合、想定通りに変更できないことがある
このため、本番の前に検証用サイトで、少数ファイルでのリハーサルを必ず行うのが現実的です。要件が厳しいほど、後述のSPMTや移行API（移行専用仕組み）を優先した方が「やり直し」が減ります。
大量移行で失敗しやすいポイント（PnP運用のコツ）
- スロットリング対策：大量処理は一気に投げず、待機やリトライを入れる（一定件数ごとに休むなど）
- フォルダー設計：深い階層や長いパスはエラー要因になりやすい。移行前に棚卸しする
- 必須メタデータ：必須列があるとアップロードが止まる。移行バッチ中は必須解除を検討するか、必須値を同時投入する
- エラー記録：成功/失敗ログ、再実行できる設計（移行バッチIDや移行元パス列）があると復旧が早い
「元の作成日」用のカスタム列を作って、表示・検索・管理を分離する
「標準のCreatedがアップロード日でも構わない。元の日時が参照できれば良い」という場合、最もシンプルで事故が少ないのがカスタム列方式です。SharePointの設計思想としても、「システム列はシステムの意味で使い、業務要件は業務列に持つ」方が運用で崩れにくい傾向があります。
カスタム列方式の手順（実務向け）
- 列を作る：ライブラリに「元の作成日（日時）」と「元の更新日（日時）」を追加する
- ビューに出す：利用者が普段見るビューに、その列を表示する（必要なら並び替えキーにする）
- 投入方法を決める：手作業ではなく、一括投入の仕組みを用意する（スクリプト／移行ツール／バッチ）
- 運用ルールを決める：移行後にファイルが追加される場合、元日時をどう扱うか（“移行対象のみ”として固定する等）
「列を作ったのに埋まらない」問題をどう解決するか
ここが一番つまずきポイントです。列は箱であって、値は勝手に入りません。投入は次のどれかで行うことになります。
| 投入方法 | おすすめ度 | 特徴 | 向く状況 |
|---|---|---|---|
| スクリプト（PnP PowerShell等）でアップロード時に投入 | 高 | 確実に埋まる／ルールを統一できる | 移行対象が多い、標準化したい |
| 既にアップロード済みのファイルに対して一括更新 | 中 | 後追いで埋められるが、元日時情報をどこから取るかが課題 | 移行が先に走ってしまった |
| Power Automate（フロー）で更新 | 中 | 仕組みは作りやすいが、ローカルのCreationTimeをフロー単体で取得できない | アップロード時に別経路で元日時を渡せる |
| 手作業（プロパティ編集） | 低 | 少量なら可能だが、量が増えると破綻 | ごく少数・例外対応 |
Power Automateは便利ですが、ローカルのファイルサーバーに存在していたCreationTime/LastWriteTimeを、SharePoint上で“自動的に復元”することはできません。自動化したい場合は、アップロード時点で「元日時」を何らかの形で渡す（スクリプトで列に書き込む、メタデータCSVから反映する、移行ツールを使う等）が必要です。
検索・並び替えで困らないための工夫
- 列は「日付と時刻」型で作る（テキスト列にすると並び替えが崩れやすい）
- ビューで「元の作成日」で並び替え、フィルタ（年、月など）を作っておく
- 必要に応じて「元の作成日」「元の更新日」をインデックス列にする（大量データでのフィルタ性能に効く）
- 監査用途なら「移行元パス」「移行バッチID」も一緒に持つ（問い合わせ対応が圧倒的に楽）
SharePoint Migration Tool（SPMT）を使うのが最短ルートになりやすい
ファイルサーバーからSharePoint Onlineへの移行が目的なら、結論としてSharePoint Migration Tool（SPMT）を使うのが最短で要件を満たしやすいケースが多いです。スクリプトでCreated/Modifiedを調整するのは実現できても、運用規模が大きいほど「例外処理」「再実行」「レポート」「差分移行」などで苦労しがちです。
SPMTが強い理由（現場目線）
- 移行用途に最適化：ファイルサーバー→SharePointの移行で起きがちな制約（パス、文字、サイズ等）を前提に設計されている
- メタデータ（日時など）の維持を目的にした移行シナリオに適している
- 移行レポートが残り、失敗分の洗い出しや再実行がしやすい
- 差分移行（一度移して終わりではなく、切り替えまで何度か同期する運用）を組みやすい
SPMT導入前にやっておくと成功率が上がるチェック
| チェック項目 | 内容 | やっておくと得すること |
|---|---|---|
| 移行対象の棚卸し | 不要ファイル、重複、古いログ等を整理 | 移行時間と容量を削減、検索品質も向上 |
| パス/ファイル名の健全化 | 長すぎるパス、禁止文字、末尾のドット等 | 移行エラーの大半を事前に潰せる |
| SharePoint側のライブラリ設計 | フォルダー構成、権限、必須列、ビュー | 移行後の「使いにくい」を防ぐ |
| 切り替え手順 | いつ凍結するか、差分をどう取るか | 業務停止を最小化しやすい |
SPMTの運用イメージ（ざっくり手順）
- 移行先のSharePointサイトとドキュメントライブラリを準備する（必要ならカスタム列も作成）
- SPMTで移行元（ファイル共有/ローカルパス）と移行先（サイト/ライブラリ/フォルダー）をマッピングする
- テスト移行（少量）→ レポート確認 → 問題が出るパターンを潰す
- 本移行（初回は全量）→ 切り替え前に差分移行を数回
- 切り替え後にスポットチェック（日時、ファイル数、重要フォルダー）
「とにかく元の作成日を残したい」「移行作業を現実的に終わらせたい」という要件なら、スクリプトよりSPMTがフィットしやすいのはこの流れのためです。
ケース別：どの方法を選ぶべき？（迷ったらここ）
| あなたの状況 | おすすめ | 理由 | 次にやること |
|---|---|---|---|
| ファイルサーバーから大量に移行（数万〜） | SPMT | 移行レポートと差分移行が現実的。日時維持要件にも対応しやすい | 棚卸し→テスト移行→本移行計画 |
| 対象は限定的で、スクリプト運用できる | PnP PowerShell | 細かい制御（列投入、フォルダー分岐、命名規則）が可能 | カスタム列作成→小規模検証→本番バッチ |
| 標準Createdはアップロード日でよい。元日時が見えればOK | カスタム列方式 | 運用が壊れにくく、説明もしやすい | 列を作る→投入手段を決める |
| 監査要件で、標準Created/Modifiedが元日時である必要がある | SPMT（優先）/ PnP（要検証） | 標準列の書き換えは制約が出やすい。移行用途の手段が安全 | 検証環境で要件を満たすか確認 |
実務でハマりやすい落とし穴と対策
タイムゾーンずれ（“日付が1日ずれる”問題）
ローカルのファイル日時は端末のタイムゾーンで表示され、SharePointはサイト設定・ユーザー設定に依存して表示されます。移行スクリプトで日時を投入する場合は、「入力する日時がローカル時刻なのか、UTCなのか」を統一しないと、一覧で見たときに1日ずれる事故が起きます。
- 移行前に「SharePointでの表示」と「投入値」の関係を少数データで検証する
- 社内標準として、元日時は「元のローカル時刻のまま保存」などルールを決める
メタデータ更新で「更新日（Modified）が変わってしまう」
SharePointでは、ファイル内容を変えていなくても、プロパティ（メタデータ）を編集するとModifiedが更新されることがあります。要件が「元の更新日時を残す」なら、標準Modifiedに頼り切らず、「元の更新日」列を持つ設計が堅牢です。
必須列・コンテンツタイプのせいでアップロードが止まる
運用中のライブラリに必須列があると、移行時にファイルが作れずエラーになります。解決策は次のいずれかです。
- 移行期間だけ必須を緩める（移行後に整備する）
- スクリプト/移行ツールで必須値も同時に投入する
権限継承が複雑で、移行後に「見える/見えない」が崩れる
ファイルサーバーのACLをそのまま持ち込みたい要件は多いですが、SharePointの権限モデルと完全一致しません。まずは、
- 「サイト単位」「ライブラリ単位」「フォルダー単位」で権限を再設計できないか
- 例外権限は最小化できないか
を検討し、どうしても必要な場合のみツール側の権限移行を使う方が、長期運用で破綻しにくいです。
移行後の確認方法：日時が“期待通り”保持されているかチェックする
「移行したつもり」でも、運用で困るのは“期待と違う”ケースです。以下の観点でスポットチェックをしておくと安心です。
| チェック項目 | 確認方法 | 合格ライン例 |
|---|---|---|
| 重要フォルダーの代表ファイル | 元の作成日/元の更新日列を表示し、ファイルサーバーと突合 | 差がない（または想定したタイムゾーン差のみ） |
| 並び替え・フィルタ | 「元の作成日」で昇順/降順、年/月フィルタ | 意図通りに並ぶ |
| 検索 | 「元の作成日」列での絞り込み、条件検索 | 業務で使える速度と精度 |
| 監査・説明性 | 「標準CreatedはSharePoint登録日」「元の作成日は業務列」と説明できるか | 運用ルールが文章化できている |
まとめ：SharePoint Onlineで作成日を守るには「標準列にこだわる範囲」を決める
SharePoint Onlineにファイルをアップロードすると、標準の作成日（Created）がアップロード日になるのは基本仕様です。そのうえで、要件に応じて次のように割り切ると、移行の成功率が上がります。
- 表示・管理が目的：カスタム列（元の作成日/元の更新日）を作り、スクリプトやツールで確実に投入する
- 標準Created/Modified自体を元に戻す必要がある：移行用途に強いSPMTを優先し、スクリプトは検証前提で使う
- 大量移行：例外処理やレポート、差分移行まで考えると、ツール中心の設計が現実的
「どこまでをSharePoint標準列に反映するか」「業務要件は業務列で持つか」を最初に決め、少量の検証→本番移行の順で進めるのが、作成日時問題を最短で解決する近道です。
コメント