rcloneでOneDriveからGoogle Driveへ—ローカル容量ゼロで243GBを移行した全記録

2026-01-17
目次

概要

このドキュメントは、高機能コマンドラインツール「rclone」を使用して、OneDrive for BusinessからGoogle Driveへ大容量データを移行するための技術者向け総合手順書です。

この手法は、特にローカルPCに同期されていない数TB級の動画アーカイブなど、大容量フォルダの移行において絶大な効果を発揮します。rcloneはローカルの同期フォルダを介さず、クラウドサービスのAPIを直接操作します。これにより、巨大なローカル空き容量を必要とせず、また数日かかることもある同期プロセスを完全にバイパスできるという核心的な利点があります。

最初に理解すべき重要な事実

rcloneは「クラウド間で直接データを転送する魔法のツール」ではありません。

実際の動作は以下の通りです：

OneDrive (クラウド) → あなたのPC → Google Drive (クラウド)

rcloneを実行しているPCが、OneDriveからデータをダウンロードし、同時にGoogle Driveへアップロードする「中継処理」を絶え間なく行います。ただし、この処理はストリーミング方式で行われるため、ファイル全体をローカルに保存する必要はありません。

つまり「PCを経由しない」のではなく「PCのローカルストレージに全量を保存しなくて済む」というのが正確な表現です。そのため、移行の総スループットは、PCのネットワーク帯域（特にアップロード速度）と安定性に依存します。

このガイドの特徴

このガイドは、単なるコマンドの羅列ではありません。OneDrive for Businessの認証プロセスで多くの技術者が直面する一般的な落とし穴とその体系的な解決策、Windows環境特有のファイル名文字化け対策、中断からの再開方法、そして移行したデータの完全性を保証するための検証プロセスまでを網羅した、極めて実践的なトラブルシューティング集でもあります。

1. 移行プロセスの全体像と前提条件

成功率の高いデータ移行は、明確な計画と準備から始まります。このセクションでは、移行プロセス全体の流れを俯瞰し、作業に着手する前に必要なツールやアカウント情報を整理します。

移行の5フェーズ

移行プロセスは、以下の5つの論理的なフェーズで構成されます。この「設定→事前確認→実行→事後検証→クリーンアップ」という安全な流れに沿って進めることで、予期せぬトラブルを最小限に抑えることができます。

  1. rcloneのセットアップとリモート設定 — 移行元（OneDrive for Business）と移行先（Google Drive）のクラウドストレージをrcloneに認識させるための初期設定です。
  2. 接続パスの確認と事前テスト — 本移行プロジェクト最大の難所である認証をクリアし、rcloneから目的のファイルやフォルダが正しく見えているかを確認する最重要フェーズです。
  3. データ移行の実行 — --dry-runオプションによる綿密なシミュレーションを経て、意図通りの動作を確認した上で、本番のデータコピーコマンドを実行します。
  4. 移行後のデータ整合性検証 — コピーがエラーなく完了したかを客観的なデータで確認し、移行の成功を保証します。
  5. 移行元データのクリーンアップ（任意） — 移行が完全に成功したことを確認した後、必要に応じて移行元のデータを整理します。

前提条件

作業を開始する前に、以下の前提条件が満たされていることを確認してください。

  • rcloneのインストール: Windows環境にrclone.exeが配置され、コマンドプロンプトやPowerShellから実行できる状態（PATHを通すか、フルパスで指定）
  • アカウント情報: 移行元であるOneDrive for Businessアカウント、および移行先であるGoogle Driveアカウントへの正当なアクセス権
  • 実行環境: コマンドプロンプトまたはPowerShellが利用可能なWindows PC
  • 安定したネットワーク: 可能であれば有線LAN接続を推奨（長時間転送中の安定性確保のため）

2. rcloneのセットアップとリモート設定

rcloneの能力を最大限に引き出すためには、まず移行元と移行先のクラウドストレージを「リモート」として正しく設定する必要があります。

2.1. rcloneのバージョン確認とアップデート

rcloneのバージョンが古いと、クラウドサービス側のAPI仕様変更に対応できず、特に認証周りで問題が発生する可能性があります。作業開始前に、バージョンを確認し最新版に保つことを強く推奨します。

バージョン確認コマンド:

rclone version

出力例：

rclone v1.72.1
- os/version: Microsoft Windows 11 Home 23H2 (64 bit)
- os/kernel: 10.0.22631.6199 (x86_64)
- os/type: windows
- os/arch: amd64
- go/version: go1.25.1
- go/linking: static
- go/tags: cmount

自己アップデートコマンド:

rclone selfupdate

注意: selfupdateコマンドは、インストール方法によっては動作しない場合があります（例：パッケージマネージャー経由でインストールした場合）。その場合は、公式サイトから最新版をダウンロードして手動で更新してください。

2.2. Google Driveリモートの追加 (gd)

比較的設定が容易なGoogle Driveから設定を始めましょう。rclone configコマンドを実行すると、対話形式で設定が開始されます。

  1. nを入力して「New remote」を選択します
  2. nameには、このリモートを識別するための短い名前（例: gd）を入力します
  3. Storageの一覧からdriveを探し、対応する番号を入力します
  4. 以降の基本的な質問には、デフォルト値（Enterキーを押すだけ）で問題ありません
  5. 最終的にブラウザが起動し、Googleアカウントでの認証とアクセス許可を求められますので、画面の指示に従ってください

2.3. OneDrive for Businessリモートの追加 (od)

OneDrive for Businessの設定は、個人用アカウントとの混同や組織のセキュリティポリシーにより、複数の落とし穴が存在します。慎重に進めましょう。

  1. 同様にrclone configを起動し、nで新規リモート作成を開始します
  2. nameにはodなど、分かりやすい名前を設定します
  3. Storageの一覧からonedriveを選択します
  4. アカウント種別を尋ねられた際に、「Business (work or school)」を選択することが最初の重要な分岐点です。 ここで誤ると、個人用アカウントに接続されてしまいます

これらのリモート設定が完了しても、特にOneDrive for Businessでは複雑な認証プロセスに起因する問題が発生しがちです。次のセクションでは、その典型的な落とし穴と解決策を詳述します。

3. 最難関：OneDrive for Business認証の落とし穴と解決策

OneDrive for Businessの認証は、本移行プロジェクトにおける最大の技術的難関です。これらの問題は、主に以下の3つの根本原因に分類できます：

  1. アカウントIDの混同 — Personal/Businessの取り違え
  2. rcloneへのアクセス許可設定 — client_id等の誤入力
  3. Microsoftサーバー側の一時的な状態 — 認証基盤の障害

各落とし穴がどれに該当するかを理解することで、より迅速に問題を解決できます。

3.1. 落とし穴①：個人用（Personal）とビジネス用（Business）アカウントの混同

rcloneは認証時に既定ブラウザを起動しますが、そのブラウザが既存のログインセッションを優先するため、意図せず個人用アカウントで認証してしまうケースが頻発します。

現象: rclone configのドライブ選択画面で、(personal)と付いたドライブしか表示されない

原因: 認証時に開かれたブラウザが、個人用のMicrosoftアカウントでログインされた状態だったため。特にEdgeのプロファイルを複数利用している場合に発生しやすい

解決策:

  1. 認証を開始する前に、個人用プロファイルで開いているブラウザウィンドウをすべて閉じます
  2. rcloneがコンソールに出力した認証用URLをコピーし、ブラウザのシークレットモード（InPrivateウィンドウ） で手動で開きます。これにより、既存のセッションから隔離された状態で、目的の職場アカウントでログインできます

3.2. 落とし穴②：client_id と client_secret の誤設定

rcloneの対話設定では、client_idとclient_secretの入力を求められる場面があります。これらは通常、何も入力せずEnterキーを押すのが正解です。

現象: 認証時にAADSTS700016: Application with identifier ... was not foundといったエラーが発生する

原因: client_idにメールアドレスなど、不正な値を誤って入力したため

重要: client_idとclient_secretは、自社でAzure ADに独自のアプリケーションを登録し、そのIDとシークレットキーを付与されたという、極めて高度で特殊な場合にのみ使用します。通常の利用では必ず空のまま進めてください。

解決策:

  1. rclone configを起動し、dを入力して問題のリモート設定を一度削除します
  2. 再度nでリモートを新規作成し、client_idとclient_secretを求められたら、何も入力せずにEnterキーを押してデフォルト設定を使用します

3.3. 落とし穴③：Azure AD/Entra IDの同意エラー (AADSTS650051)

認証プロセス中に、Microsoft Entra ID（旧Azure AD）側で問題が発生することがあります。

現象: 認証後にAADSTS650051: ...service principal name is already present for the tenantというエラーメッセージが表示される

原因: 過去に認証が中途半端に失敗した際のrcloneアプリの登録情報（サービスプリンシパル）が、組織のテナント内に不完全な状態で残り、新たな同意処理と重複してエラーを引き起こしている

解決策（管理者権限がある場合）:

  1. Azure Portalにサインインし、「Microsoft Entra ID」→「エンタープライズアプリケーション」に移動します
  2. アプリケーションID b15665d9-eda6-4092-8539-0eec376afd59 を検索します
  3. 表示されたアプリケーション（rcloneに関連するもの）を選択し、削除します
  4. 数分待ってから、再度rcloneで認証プロセスを試みます

3.4. 落とし穴④：一時的なMicrosoftサーバーエラー (AADSTS90092)

ユーザー側の設定ミスではなく、Microsoftの認証サーバーが一時的に不安定になっていることが原因で発生するエラーです。

現象: 認証プロセスでAADSTS90092: Non-retryable error has occurredというエラーが表示される

原因: Microsoft認証基盤の一時的な障害または高負荷状態

解決策:

  1. 慌てずに数分から数十分の時間を置いてから、再度認証プロセスを実行します
  2. rclone config reconnect od: コマンドで再接続を試みるのも有効です
  3. それでも失敗する場合、認証URLをシークレットウィンドウで手動で開く方法を試してください

4. 接続パスの確認とPowerShellの文字化け対策

認証が成功したら、次にrcloneから目的のファイルやフォルダが正しく見えているかを確認します。また、Windows環境特有の「文字化け」問題もここで解決します。

4.1. 基本的な接続確認と「コロン :」の罠

rclone lsf <remote_name>: は、指定したリモートのルートディレクトリ直下にあるファイルやフォルダを一覧表示するための基本コマンドです。

ここで、初心者が100%陥る罠があります。それは、リモート名の末尾にコロン:を付け忘れることです。

:がないと、rcloneはその名前をローカルフォルダとして解釈しようとし、directory not foundエラーを引き起こします。

# 誤ったコマンド（エラーになる）
rclone lsf od

# 正しいコマンド
rclone lsf od:

4.2. 目的フォルダのパス特定

次に、移行対象であるフォルダがリモート内のどこに存在するかを特定します。以下のコマンドは、-Rオプションで再帰的に、--max-depth 3で3階層までを効率的に探索し、Select-Stringで結果を絞り込む実践的な例です。

# -Rで再帰的に、--max-depth 3で3階層まで探索し、Select-Stringで絞り込む
rclone lsf od: -R --max-depth 3 | Select-String youtube

4.3. PowerShellにおける日本語ファイル名の文字化け対策

上記コマンドを実行した際、日本語を含むファイル名が 譬ｪ萓｡謠帷ｮ嶺ｿよ焚 のように文字化けすることがあります。

原因: この現象は、rcloneが出力する文字コード（UTF-8）と、Windows PowerShellのデフォルトのコンソール表示文字コード（CP932/Shift-JIS）が異なるために発生します。ファイル自体が破損しているわけではなく、表示上の問題です。

解決策: PowerShellで以下の2つのコマンドを実行し、現在のセッションの表示エンコーディングをUTF-8に変更します。

[Console]::OutputEncoding = [System.Text.Encoding]::UTF8
$OutputEncoding = [System.Text.Encoding]::UTF8

これで文字化けは即座に解消されます。

5. 安全なデータ移行の実行

これまでの入念な準備と確認作業を経て、いよいよデータ移行を実行します。しかし、ここでいきなり本番コピーを行うのは賢明ではありません。--dry-runオプションを活用したシミュレーションから始めます。

5.1. ステップ1：ドライラン（事前シミュレーション）の実施

--dry-runは、実際のファイル転送を一切行わずに「何がどこにコピーされるか」だけをログに出力する、極めて重要な安全機能です。

rclone copy "od:youtube" "gd:youtube" --dry-run -P

実行結果にNOTICE: ... Skipped copy as --dry-run is setというログが多数表示されれば、シミュレーションは成功です。

2026/01/04 20:30:25 NOTICE: 2019-06-03 21-24-26.mp4: Skipped copy as --dry-run is set (size 970.496Mi)
2026/01/04 20:30:25 NOTICE: WordPress3.avi: Skipped copy as --dry-run is set (size 2.470Gi)
2026/01/04 20:30:25 NOTICE: msdos.avi: Skipped copy as --dry-run is set (size 5.063Gi)
2026/01/04 20:30:25 NOTICE: 白猫re.avi: Skipped copy as --dry-run is set (size 705.647Mi)
2026/01/04 20:30:26 NOTICE: 2025/claudecode.mp4: Skipped copy as --dry-run is set (size 1.411Gi)
...

5.2. ステップ2：本番コピーの実行

ドライランで問題がないことを確認したら、--dry-runオプションを外して本番のコピーコマンドを実行します。

# タイムスタンプ付きのログファイル名を生成
$ts = Get-Date -Format "yyyyMMdd-HHmmss"

# 本番コピーコマンド
rclone copy "od:youtube" "gd:youtube" -P `
  --transfers 4 --checkers 8 `
  --retries 10 --low-level-retries 20 `
  --fast-list `
  --log-file "rclone-copy-$ts.log" --log-level INFO

各オプションの役割:

オプション説明
copy宛先にファイルが存在しない、または更新されている場合のみコピー
"od:youtube"移行元のパス。スペースを含む可能性を考慮し引用符で囲む
"gd:youtube"移行先のパス
-P / --progress転送の進捗状況をリアルタイムで表示
--transfers 4同時転送ファイル数。大容量ファイル中心なら4〜8が安定
--checkers 8ファイル存在チェックの並列数
--retries 10失敗時のリトライ回数
--low-level-retries 20低レベル（接続等）のリトライ回数
--fast-list大量ファイル時のディレクトリ一覧取得を最適化
--log-file ...すべての操作ログをファイルに記録
--log-level INFOログの詳細度（DEBUG/INFO/NOTICE/ERROR）

5.3. 転送速度のチューニング指針

転送速度は以下の要素で決まります：

  • PCの回線速度（特にアップロード帯域）
  • OneDrive側のダウンロード速度
  • Google Drive側のアップロード速度
  • API制限（Microsoft/Google両方）
  • --transfersの並列数

チューニングの基本方針:

  • 安定重視: --transfers 4 で開始（本ガイドの推奨値）
  • 速度重視: 問題なければ --transfers 6 → 8 と段階的に上げる
  • エラー多発時: --transfers 2 まで下げ、--tpslimit 10（秒間リクエスト数制限）を追加
# API制限に当たる場合のオプション追加例
rclone copy "od:youtube" "gd:youtube" -P `
  --transfers 2 --checkers 4 `
  --tpslimit 10 `
  --log-file "rclone-copy-$ts.log"

5.4. 長時間転送の現実的な運用パターン

TB級のデータ転送は数時間〜数十時間かかることが普通です。現実的な運用パターンを紹介します。

「寝る前に走らせて朝確認」パターン:

  1. 夜、本番コピーコマンドを実行
  2. PCのスリープ設定を無効化（重要）
  3. 朝、進捗を確認
  4. 完了していなければ、そのまま放置して続行

スリープ防止の設定（Windows）:

  • 「設定」→「システム」→「電源とスリープ」→「スリープ」を「なし」に設定
  • または、コマンド実行前に powercfg /change standby-timeout-ac 0 を実行

6. 中断と再開：rclone copyの冪等性

TB級の転送では、途中で止まることは日常茶飯事です。回線断、PCの再起動、API制限など、様々な理由で中断が発生します。

rclone copyは「冪等」である

冪等（べきとう）とは、同じ操作を何度実行しても結果が変わらない性質のことです。

rclone copyは、宛先に既に存在するファイル（同名・同サイズ）をスキップします。つまり、途中で止まっても、同じコマンドをもう一度実行するだけで続きから再開できます。

# 1回目（途中で中断）
rclone copy "od:youtube" "gd:youtube" -P --transfers 4 ...

# 2回目（同じコマンドを再実行 → 続きから）
rclone copy "od:youtube" "gd:youtube" -P --transfers 4 ...

再開時の注意点

  • ログファイル名: タイムスタンプ付きなので、再実行すると新しいログファイルが作成されます。問題ありませんが、後で見返す際は複数のログを確認することになります
  • 更新判定: rcloneはデフォルトで「サイズ」と「更新日時」でファイルの同一性を判定します。移行中に元ファイルを編集しないでください
  • 部分的に転送されたファイル: 大きなファイルの転送中に中断した場合、そのファイルは最初からやり直しになります（部分再開はされません）

7. 移行後のデータ整合性検証

長時間のコピー処理が完了したら、データが完全に、そして正しく移行されたことを確認する検証作業が不可欠です。

7.1. rclone sizeによる概算確認

最も簡単な方法は、rclone sizeコマンドで移行元と移行先の総サイズを比較することです。

# 移行元のサイズを確認
rclone size "od:youtube"

# 移行先のサイズを確認
rclone size "gd:youtube"

両者の「Total objects」と「Total size」が概ね一致すれば、移行は成功と判断できます。

7.2. ログファイルでのエラー確認

より確実な検証として、ログファイル内にERRORが含まれていないかを確認します。

# ログファイル内のエラーを検索
Select-String -Path "rclone-copy-*.log" -Pattern "ERROR"

何も表示されなければ、エラーなしで完了しています。

7.3. rclone checkによる厳密な検証（上級者向け）

rclone checkコマンドを使うと、ファイル単位での整合性を検証できます。

rclone check "od:youtube" "gd:youtube"

重要な注意点: OneDriveとGoogle Driveでは、使用しているハッシュアルゴリズムが異なります（OneDrive: QuickXorHash、Google Drive: MD5）。そのため、rclone checkはハッシュ比較ではなく「サイズ＋更新日時」での比較になることが多いです。これでも実用上は十分な検証になりますが、「ハッシュが一致した」わけではないことを理解しておいてください。

8. （任意）移行元データのクリーンアップ

移行先でのデータ整合性検証が完了した後、必要に応じて移行元のOneDrive for Business上のデータを整理します。

重要な警告

この操作は、移行元データを完全に削除します。 パスの指定ミスは、意図しないデータの完全消失に直結します。--dry-runの出力を精査し、削除対象が正しいことを確認した上で、自己責任において実行してください。

8.1. 推奨：段階的なクリーンアップ

いきなり削除するのではなく、以下の段階的なアプローチを推奨します。

ステップ1: リネームして様子見（最も安全）

# 移行元フォルダをリネーム
rclone moveto "od:youtube" "od:youtube__migrated_20260104"

数日〜1週間、移行先で問題なく運用できることを確認してから、次のステップに進みます。

ステップ2: 削除のドライラン

# 削除対象の確認（実際には削除しない）
rclone delete "od:youtube__migrated_20260104" --dry-run -P

ステップ3: 本番削除

# 本当に削除する（取り消し不可）
rclone delete "od:youtube__migrated_20260104" -P

8.2. フォルダごと削除する場合

rclone deleteはファイルのみを削除し、空のフォルダは残ります。フォルダごと削除したい場合はrclone purgeを使用します。

# フォルダごと完全削除（非常に危険）
rclone purge "od:youtube__migrated_20260104" --dry-run  # まずドライラン
rclone purge "od:youtube__migrated_20260104"            # 本番

注意: OneDriveには「ゴミ箱」機能があり、削除したファイルは一定期間復元可能です。ただし、これに依存した運用は推奨しません。

9. 記事・動画公開時の秘匿情報チェックリスト

rcloneの設定や実行ログを記事や動画で公開する際は、以下の情報の取り扱いに注意してください。

絶対に公開してはいけない情報（危険度：高）

  • token = {...} 内の access_token / refresh_token
  • client_secret
  • 認証URL（state=などのクエリパラメータ付き）
  • 職場アカウントのメールアドレスが丸見えになる画面

マスク推奨（危険度：中）

これらは即座に悪用されるわけではありませんが、公開するメリットがないためマスクを推奨します。

  • drive_id（例: b!AJ-D...W_i → b!AJ-D********W_i）
  • tenant_id（GUID形式）
  • Correlation ID / Trace ID
  • 組織名・SharePointサイトURL

公開しても問題ない情報（危険度：低）

  • コマンド例そのもの（パスやオプション）
  • エラーコードの種類（AADSTS90092など）
  • rcloneのバージョン情報
  • 転送速度やファイルサイズの統計情報

10. まとめとベストプラクティス

本ガイドでは、rcloneを用いてOneDrive for BusinessからGoogle Driveへ大容量データを安全かつ効率的に移行する一連のプロセスを解説しました。

このチュートリアルで得られる重要な知識

  • ローカル同期不要のAPI直接移行: rcloneの最大の利点は、PCに同期されていないフォルダも含め、クラウド上の全データをAPI経由で読み取れる点です。巨大なローカル空き容量を必要とせず、効率的な大容量データ移行が可能です
  • 「PCが中継する」という正しい理解: rcloneは魔法ではなく、PCがデータを中継しています。ただし、ローカルに全量保存する必要がないため、同期フォルダ経由の移行より遥かに効率的です
  • 認証の罠を理解する: OneDrive for Businessの認証は複雑ですが、「Personal/Businessの混同」「client_idの空欄」「ブラウザのシークレットモード活用」といった典型的な罠とその解決策を理解すれば、確実に乗り越えられます
  • 安全第一の実行プロセス: いきなり本番コマンドを実行せず、常に--dry-runでシミュレーションを行い、意図通りの動作を確認してから本番に臨むことが、データ消失事故を防ぐ鍵となります
  • 中断しても再開できる: rclone copyは冪等であり、同じコマンドを再実行するだけで続きから再開できます。TB級の転送では中断は日常茶飯事なので、この性質を理解しておくことが重要です
  • 検証の重要性: rclone sizeによるコピー前後の比較、ログファイルのエラー確認は、移行の成功を客観的に証明するための不可欠なプロセスです

最後に

このガイドで解説した手法とトラブルシューティングの知識は、今後のクラウドデータ管理において、あらゆる場面で役立つ信頼性の高い武器となるでしょう。

本ガイドは、実際のOneDrive for Business → Google Drive移行作業での試行錯誤と、その過程で得られた知見を体系化したものです。

タイトルとURLをコピーしました