Windows Server上でOneDriveフォルダーへファイルをコピーするバッチをタスク スケジューラで回すと、ログオン中は同期されるのに、RDPのセッションを切断するとアップロードされない――。この現象が起きる理由と、無人でも確実にアップロードさせる現実的な解決策を整理します。
現象の整理：ログオン、切断、ログオフは別物
まず重要なのは、Windowsの「ログオン中」「セッション切断」「ログオフ」が同じではない点です。管理者目線では似て見えますが、OneDrive同期クライアントの挙動やタスク スケジューラの実行コンテキストに大きく影響します。
| 状態 | ユーザーの扱い | デスクトップ（Explorer） | OneDrive同期の期待値 | よくある結果 |
|---|---|---|---|---|
| ログオン中（セッションがアクティブ） | 対話型セッションが存在 | 表示され、ユーザー操作が可能 | OneDrive.exeが動いていれば即時反映しやすい | コピー後、数秒〜数分でアップロードされる |
| セッション切断（ログオフではない） | ユーザープロセスは残ることが多い | 画面は閉じるが、セッション自体は残存 | 環境・ポリシー次第で停止/一時停止が起きやすい | ローカルには更新されるがクラウドに上がらない |
| ログオフ | セッション終了 | 終了 | OneDrive.exeも終了する | 当然同期は動かない（次回ログオンまで保留） |
質問のケースは「ログオフではないのに同期されない」ため混乱しがちですが、OneDrive同期クライアントは“サーバーで無人実行する同期サービス”として設計されていないことが根本原因です。
結論：この挙動はOneDriveの設計思想として“起こり得る”
OneDriveの同期クライアント（OneDrive.exe）は、基本的にユーザーごとの対話型セッションで動くクライアントアプリです。Windowsサービスのように「誰もログオンしていなくても常時動く」前提ではありません。
そのため、次の条件が重なると「タスクは成功したのに同期しない」が発生します。
- タスク スケジューラが非対話（バックグラウンド）の実行コンテキストで動いている
- OneDrive.exeが動いているのは別のセッション（または切断後に一時停止/終了している）
- RDS/リモート環境のポリシーにより、切断セッションが一定時間で終了・凍結・リソース制限される
つまり「仕様として想定されるか？」という問いに対しては、運用上は“想定して設計を変えるべき挙動”と捉えるのが安全です。
なぜ同期されないのか：タスク スケジューラとOneDriveの“居場所”がズレる
ポイントは、タスク スケジューラの設定「ユーザーがログオンしているかどうかにかかわらず実行する（Run whether user is logged on or not）」です。この設定は便利ですが、OneDrive同期との相性はよくありません。
| タスク設定 | 実行セッション | ユーザープロファイル | UI/トレイ | OneDrive同期への影響 |
|---|---|---|---|---|
| ユーザーがログオンしているときのみ実行 | 対話型セッション | 確実に読み込まれる | 利用可能 | OneDrive.exeが同じセッションで動きやすく、同期が進む |
| ログオン有無にかかわらず実行 | 非対話セッション（バックグラウンド） | 読み込みはされるが環境差が出やすい | 利用不可 | OneDrive.exeがそのセッションに存在しないため、同期“自体”は起動しない |
タスクがOneDriveフォルダーにファイルをコピーできても、それは「フォルダーに書き込めた」だけです。同期はOneDrive.exeの責務なので、OneDrive.exeが動いていない／一時停止している状態なら、クラウドには上がりません。
まず切り分けたいチェックリスト
解決策に進む前に、現場でよく効く切り分けポイントをまとめます。原因が「OneDrive停止」なのか「セッション終了」なのかで、対処が変わるためです。
OneDrive.exeが切断後も動いているか
- 切断前にタスク マネージャーでOneDrive.exeが存在するか確認
- 切断後（別管理者でログオンして）プロセス一覧から該当ユーザーのOneDrive.exeが残っているか確認
- 同期アイコンが「一時停止」や「サインインが必要」になっていないか確認
切断セッションが途中でログオフされていないか
「自動ログオフしない」ポリシーを設定していても、RDS関連の別ポリシーが効いているとセッションが終了することがあります。特に次の項目は見落とされがちです。
| 確認項目 | 影響 | 見落としポイント |
|---|---|---|
| 切断されたセッションのタイムアウト | 一定時間後に強制ログオフ | 「自動ログオフしない」設定とは別に存在する |
| アイドル（操作なし）セッションの制限 | 操作がないと切断/終了 | 夜間バッチ中に勝手に切れる |
| 時間制限到達時のセッション終了 | 上限時間でログオフ | RDS環境やGPOで統一設定されていることが多い |
タスクの実行ユーザーとOneDriveのサインインユーザーが一致しているか
OneDriveフォルダーは「そのユーザーのプロファイル配下」にあります。タスクが別ユーザー（SYSTEMや管理者）で動いていると、想定と違う場所に書き込んでいる／OneDriveが監視していない場所に書き込んでいる、という事故が起きます。
- タスクの「実行するユーザー」が、OneDriveにサインインしているユーザーと一致しているか
- スクリプト内で参照するパスが、絶対パスで誤りなく指定されているか（環境変数の解決がズレていないか）
- 「管理者として実行（最上位の特権で実行）」により、アクセス先が想定外になっていないか
最も確実な解決策：Microsoft Graph APIで直接アップロードする
「ユーザーがログオンしていない／セッションが切断された状態でも自動でアップロードしたい」という要件に対して、安定運用しやすいのはOneDrive同期クライアントを介さず、Microsoft Graph APIで直接アップロードする方式です。
Graph API方式が“サーバー運用”に向く理由
- 対話型セッションやトレイ常駐に依存しない
- タスク スケジューラやWindowsサービスなど、無人実行の設計に寄せられる
- 失敗時にリトライ・エラー分類（429/5xxなど）を組み込みやすい
- アップロードした日時・実行者・対象ファイルをログ化しやすく、監査にも強い
全体構成（おすすめの設計）
現場でトラブルが少ない構成は、次の考え方です。
- アップロード先は「個人のOneDrive」よりも、チームで管理できるSharePointのドキュメント ライブラリ（または専用サービスアカウントのOneDrive）を推奨
- 実行アカウントは、人のアカウントではなく専用のアプリ（アプリ登録）として認証
- 権限は広く持たせず、必要最小限（可能なら特定サイトのみ）に絞る
- 資格情報（シークレット/証明書）は、OS上に平文で置かず安全な保管方法を採用
アプリ登録で押さえるポイント
Graph APIで無人アップロードする場合、Azure（Microsoft Entra ID）側でアプリ登録を行い、アプリに権限を付与します。ざっくり手順は次のとおりです。
- Microsoft Entra IDでアプリ登録を作成
- アプリにGraphのアクセス許可を付与（アプリケーション権限）
- 管理者の同意（Admin consent）を付与
- クライアント シークレットまたは証明書を用意
権限は環境により選択肢が変わります。代表例を表にまとめます。
| やりたいこと | 代表的な権限例 | 権限の強さ | 運用のコツ |
|---|---|---|---|
| SharePointサイトの特定ライブラリにアップロード | Sites.ReadWrite.All （またはSites.Selected＋サイト許可付与） | Sites.ReadWrite.Allは強い | 可能ならSites.Selectedで“そのサイトだけ”に限定する |
| 特定ユーザーのOneDriveにアップロード | Files.ReadWrite.All / Sites.ReadWrite.All | 強い | 個人領域に寄せるより、専用の保管先を作る方が安全 |
| 読み取りのみ（検証・一覧取得） | Sites.Read.All / Files.Read.All | 比較的弱い | まずは読み取りで検証し、問題なければ書き込みへ |
アップロード処理の実装イメージ
実装はPowerShellでも可能です。重要なのは「大容量ファイル対応」と「リトライ設計」です。Graphではファイルサイズにより方式を使い分けます。
| ファイルサイズの目安 | 方式 | 特徴 | 向いている用途 |
|---|---|---|---|
| 小さめ（数MB程度） | シンプルアップロード | 1回のPUTで完了しやすい | ログ、テキスト、設定ファイル |
| 大きい（バックアップ/圧縮ファイル等） | アップロード セッション（createUploadSession） | 分割送信・途中再開ができる | 夜間バックアップ、DBダンプ、ZIP |
アップロード セッション方式では、チャンクサイズに推奨や制約があり、320KiBの倍数を選ぶとトラブル回避につながるケースが多いです（最後のチャンクは例外になり得ます）。失敗時は同じセッションURLに対して再送できるため、タスク運用との相性が非常に良いです。
以下は流れのイメージです（環境に合わせて調整してください）。
1) アプリ資格情報でアクセストークン取得（client_credentials）
2) createUploadSession を呼び出し、uploadUrl を受け取る
3) ファイルを分割し、Content-Range を付けてPUT
4) 200/201を確認し、完了ログを出力
5) 429/5xxは待機してリトライ（回数・上限を決める）タスク スケジューラで動かすときの推奨設定
Graph方式にすると、タスクは“普通のバッチ”として安定させやすくなります。おすすめ設定をまとめます。
- 実行ユーザーは専用のサービス用ローカルユーザーまたはドメインユーザー
- 「ユーザーがログオンしているかどうかにかかわらず実行する」でOK
- 「最上位の特権で実行する」は必要な場合のみ（不要なら外す）
- 作業フォルダー（Start in）を明示し、相対パス事故を防ぐ
- ログ出力（成功/失敗/対象ファイル/所要時間）を必ず残す
資格情報の置き方で失敗しないコツ
無人運用では、資格情報をどう守るかが事故ポイントです。最低限、次を意識してください。
- クライアント シークレットをスクリプトに直書きしない
- 可能なら証明書認証を使い、秘密鍵はアクセス制御する
- 保存が必要なら、Windowsの資格情報管理・DPAPI・Key Vaultなどを検討
- 権限は広くしすぎず、対象サイト/フォルダーを限定する
同期クライアントで続ける場合：成立条件と現実的な限界
「エクスプローラー上のOneDriveフォルダーにコピーしたい」「既存運用を変えられない」という事情で同期クライアント継続を選ぶ場合もあります。その場合は、“同期クライアントが動き続ける状態”を維持する運用が必要です。
成立しやすい条件
- OneDrive.exeが対象ユーザーでサインイン済みで、常駐している
- タスクは「ユーザーがログオンしているときのみ実行」にして、同一セッションで動かす
- 切断セッションが時間経過でログオフされない（RDSポリシー/接続設定を確認）
- OneDriveが「一時停止」にならない（ネットワーク制御やプロキシ影響なども確認）
よくある“ハマりどころ”
- RDPを閉じる＝切断のため、無人にすると切断状態が長く続きやすい
- 切断状態のままにしても、環境次第でOneDriveが停止・再サインイン要求になる
- サーバーで個人アカウントを常時ログオンさせるのは、監査・セキュリティ・運用負荷が大きい
「それでも続けたい」場合に、トラブルシュートでよく使う操作を載せます。
OneDriveの再起動（例）
%localappdata%\Microsoft\OneDrive\OneDrive.exe /shutdown
%localappdata%\Microsoft\OneDrive\OneDrive.exeただし、ここまでしても“無人同期”が安定しないケースは珍しくありません。根本的には、クライアント同期でサーバーバッチを回す設計が無理筋になりやすいからです。
どの方式を選ぶべきか：判断の早見表
| 要件 | おすすめ | 理由 |
|---|---|---|
| ユーザーが不在でも確実にアップロードしたい | Graph APIで直接アップロード | セッション依存を排除でき、リトライ設計も可能 |
| 双方向同期をユーザーが使う（PC用途が中心） | OneDrive同期クライアント | クライアントの利便性が高い |
| サーバーのバックアップ保管が目的 | SharePoint/専用保管先＋Graph | 権限・監査・引き継ぎがしやすい |
| 運用の簡易さ優先で“とりあえず動けばよい” | 同期クライアント継続（ただし条件付き） | 初期変更は少ないが、長期安定性は低め |
まとめ：無人運用に寄せるなら“同期クライアント依存”を外す
セッションがアクティブなときだけ同期され、切断するとアップロードされない――という挙動は、OneDrive同期クライアントの特性とタスク スケジューラの実行形態が噛み合っていないことで起きます。
安定運用を目指すなら、OneDriveフォルダーへのコピーに頼るのではなく、Microsoft Graph APIでクラウドへ直接アップロードする構成へ寄せるのが現実的です。結果として、夜間バッチやサーバー常駐の処理でも「いつの間にか同期されていない」を減らせます。
コメント