Rcloneとは｜使い方と70以上のクラウドを同期するsync/copy/mountの違い【2026年実測】

Rclone とは、Google Drive・Amazon S3・OneDrive など70以上のクラウドストレージを、ひとつのコマンド体系で扱えるオープンソースのCLIツールです。rclone config で接続先を登録すれば、あとは remote:path という同じ書式でコピー・同期・マウントができます。この記事では「何ができるか」「最初の3コマンド」「データを消しうる sync と安全な copy の違いを実際に動かして検証した結果」を、公式ドキュメントと実機検証の両方に沿って順に押さえます。

RAG全般の解説は RAGとは？仕組み・構築・ベクトルDB選定までの2026年実装マップ へ。本記事はRAGの前段（原本収集）に効くRclone単体の使い方にフォーカスする。

概要｜Rcloneとは何ができるツールか

Rcloneは、Google Drive・Dropbox・AWS S3・OneDrive・Azure Blob Storageなど、70を超えるクラウドストレージサービスに対応したコマンドラインツール。異なるプラットフォーム間でのファイル同期・転送・削除をLinux/Windows/macOS上で統一されたコマンドで実行できる。公式READMEは自らを「クラウド版rsync」と説明しており、この一言が最も実態に近い。2013年から開発が続き、GitHubで★59,705（2026年9月11日時点・MITライセンス）を獲得している。最新版はv1.75.1（2026年9月4日リリース）。

Rcloneは特定企業の製品ではなく、コミュニティ主導で開発されるOSSプロジェクトだ。企業向けの有償サポート・GUIを提供するライセンスモデルではなく、CLIそのものは完全無料で全機能が使える。「rclone とは」を一言でいえば、複数のクラウドを1つのコマンド体系に統一するアダプタ層であり、各クラウドの公式CLI・SDKを個別に覚える必要をなくす。

開発は今も活発で、GitHubの最終コミットは本記事確認時点（2026年9月11日）当日付いている。数か月おきにメジャーリビジョン相当の機能追加が入るペースなので、「以前試したときはできなかった」機能が今はサポート済みということも珍しくない。導入を迷っている場合は、まず対応ストレージ一覧で自分の使うサービスが載っているかを確認するのが最短の判断材料になる。

主な機能｜70以上のクラウドを扱う主要オプション

・マルチクラウド対応：Google Drive、Dropbox、S3、Azure、OneDrive、Mega、Seafileなど70以上のストレージに対応し、1つのツールで統一管理
・双方向同期：rclone bisyncで2つのストレージ間の差分を双方向に反映
・フィルタリング機能：--min-sizeや--excludeパターンで転送対象を拡張子・サイズ・日時で絞り込み
・帯域幅制限：--bwlimitで転送速度を制御し、ネットワークへの負荷を時間帯ごとに調整
・チェックサム検証：転送後のファイル整合性をハッシュで自動確認し破損を防止
・マウント機能：rclone mountでクラウドストレージをローカルファイルシステムとしてマウント
・サーバーサイドコピー：対応サービス同士なら自分の回線を経由せずクラウド間を直接転送

Rcloneが対応するのは「クラウドストレージ」だけではない。公式READMEは対応先を区分ごとに列挙しており、代表的な区分は次の通りだ。

最後の「仮想（ラップ型）」がRcloneらしい部分だ。cryptやunionは実サービスではなく、他のリモートを包んで挙動を変える仮想リモートとして設定する。たとえば「S3に置くが中身は暗号化したい」なら、S3リモートを作ってからそれをラップするcryptリモートを作り、以降はcrypt側の名前だけを使う。同名でも法人版と個人版で挙動が違うことがある（共有ドライブの扱いなど）ため、本番投入前に小さなディレクトリでcopyとcheckを通しておくのが確実だ。

クイックスタート｜インストールから最初の3コマンドまで

インストール後にやることは実質3つ。rclone configで接続先を登録し、rclone lsdで見えるか確認し、rclone copyで運ぶ——これが「rclone 使い方」の全体像です。

インストール（Linux/macOS）：

curl https://rclone.org/install.sh | sudo bash

Windows・パッケージマネージャ経由のインストール手順は公式インストールガイドにまとまっている。コンテナ環境ではDocker Hub公式イメージ（rclone/rclone）も配布されており、CI/CDパイプラインに組み込む場合はバイナリの都度インストールより起動が速い。

最初の3コマンド：

# 1. 接続先（リモート）を対話形式で登録する
#    「n」で新規 → 名前を付ける（例: gdrive）→ サービスを選ぶ → 認証
rclone config

# 2. 登録できたか確認する（リモート名の後ろのコロンを忘れない）
rclone listremotes           # 登録済みリモート一覧
rclone lsd gdrive:           # 直下のディレクトリ一覧
rclone ls gdrive:Documents   # ファイル一覧（サイズ付き）

# 3. コピーする（コロンの左がリモート名、右がパス）
rclone copy /home/me/data gdrive:backup/data
rclone copy gdrive:backup/data s3:my-bucket/data   # クラウド → クラウド

登録した接続情報は~/.config/rclone/rclone.confにOAuth 2.0トークンやAPIキーとして保存される。認証方式は対応クラウド側の実装に応じてOAuth・APIキー・IAMロールのいずれかになり、rclone configの対話フロー内で自動的に該当する認証方式が提示される。

実際に使ってみた結果｜sync/copy/–dry-runを実機検証

上の3コマンドに続いて、Rcloneでいちばん事故が起きやすいsyncとcopyの違いを、実際に動かして検証しました（rclone v1.75.0・macOS arm64・2026年8月26日実施。2026年9月4日にv1.75.1がリリースされているが、公式changelogにsync/copy/dry-run/mountの挙動変更は含まれていないため結果はそのまま有効）。

sync は宛先を送信元と同一にするコマンドで、宛先にしか無いファイルを削除します。 宛先にだけ存在するファイル only_in_dest.txt を置き、同じ送信元から copy と sync を1回ずつ実行した結果です。

syncの1回の実行で、送信元に存在しないというだけの理由で宛先のファイルが消えます。取り消しはできません。

# まず何が起きるか見る（実際には転送も削除もしない）
rclone sync /data s3:my-bucket --dry-run

--dry-runを付けて同じ構成を実行すると、削除対象を名指しで予告したうえでファイルは残りました。

NOTICE: keep.txt: Skipped copy as --dry-run is set (size 2)
NOTICE: will_be_deleted.txt: Skipped delete as --dry-run is set (size 2)
Deleted:                1 (files), 0 (dirs), 2 B (freed)

消さずに退避する--backup-dirも実測した。

rclone sync src dst --backup-dir trash

実行後、dstにはkeep.txtだけが残り、消えるはずだったwill_be_deleted.txtはtrash/に移動していた。ミラーは維持したいが取り返しのつかない削除は避けたい運用では、これが実質の安全網になる。

アーキテクチャ｜サーバーサイドコピーの仕組み

Rcloneはローカルを経由せず、対応クラウドサービス間のサーバーサイドコピーを活用して高速転送を実現する。S3やBackblaze B2など、サーバーサイドコピーAPIを持つサービス同士であれば、クライアントの帯域幅を消費せずに転送が完結する。

設定ファイル（~/.config/rclone/rclone.conf）にはOAuthトークンが平文で保存される。共有サーバーやCI/CD環境で使う場合は、RCLONE_CONFIG環境変数で設定ファイルのパスを変更する、rclone configのsオプションで設定自体をパスフレーズ暗号化する、Google DriveならOAuthトークンではなくサービスアカウントJSONを使う、といった対策がある。

この構成を支えているのが実装言語の選択だ。RcloneはGo言語で書かれており、外部ランタイムに依存しない単一バイナリとしてビルドされる。対応OSはLinux・Windows・macOSに加えRaspberry Pi・Androidまで及び、同じソースから各プラットフォーム向けバイナリをクロスコンパイルできるのがGoを選んだ理由の一つだ。転送は既定でデフォルトのリトライ機構を備え、--retriesフラグで回数を指定でき、失敗したファイルは記録され後から再転送できる。

整合性検証にはMD5・SHA-1をはじめとする複数のハッシュアルゴリズムが使われ、転送のたびに常時チェックされる。rclone checkコマンドで送信元と宛先のハッシュを突き合わせれば、「見た目のファイル数は合っているが中身が壊れている」ような取りこぼしを人手の目視ではなくコマンドで検出できる。タイムスタンプもファイル側に保存されるため、--update（-u）フラグを使えば宛先の方が新しいファイルはスキップする、といった片方向の上書き防止も可能だ。前述の--retries（デフォルト3）・--low-level-retries（デフォルト10）という数値は、公式ドキュメントだけでなくrclone本体のソースコード fs/config.go（165〜176行目付近）でも同じ値が定義として確認できる。

日本語ファイル名を扱う場合は、Unicode正規化の違いにも注意したい。macOSのローカルファイルシステムは分解済み（NFD）形式でファイル名を保持するため、クラウド側が結合済み（NFC）形式で管理していると、見た目は同じ日本語名でも内部表現が食い違い比較がずれることがある。公式ドキュメントは--local-unicode-normalizationフラグでNFCへ正規化できるとしつつ、「rcloneは同期処理内でUnicode正規化を考慮して比較するため、通常はこのフラグを使う必要はない」とも明記している。前述のRAG原本集約で「営業資料」「議事録」のような日本語ディレクトリ名を使う場合、macOSからの収集で表示が崩れるなどの異常が出たら、まずこのフラグの存在を思い出すとよい。

競合ツールとの比較｜gsutil・rsyncとの違い

vs gsutil/aws-cli：Google CloudやAWSの純正ツールは該当クラウド専用。Rcloneは複数ストレージに対応し、ストレージ間の直接転送をサポートしており、学習コストも1つのコマンド体系で済む。

vs CloudBerry、MSP360：商用クラウドバックアップツールと異なり、Rcloneはオープンソース無料。GUIがなく機能は限定的だが、スクリプト化・自動化の自由度が高い。

vs rsync：rsyncはローカルやSSH経由のファイル同期専門。Rcloneはクラウド認証・API経由の転送を前提設計で、帯域幅制限やチェックサムもクラウド環境向けに最適化されている。

判断基準を1つに絞るなら、「対応クラウドの数」と「クラウド間の直接転送の要否」で決めるのが早い。単一クラウドしか使わないならベンダー純正CLI（gsutil・aws-cli）で十分だが、2つ以上のクラウドを跨ぐ運用ではRcloneのremote:pathという共通構文が学習コストを大きく下げる。GUIが必須の非エンジニア向け運用ではCloudBerry/MSP360のような商用ツールが向く。

実践的な使い方｜バックアップ・マウント・RAG収集

1. 帯域制限つきの定期バックアップ（cron + --bwlimit）——業務時間帯に回線を食い潰さないための必須オプション。

# 毎日深夜2時にS3へバックアップ、転送速度10MB/sに制限
0 2 * * * rclone sync /data s3:my-backup-bucket --bwlimit 10M --log-file /var/log/rclone.log

--bwlimit "08:00,1M 22:00,off"のように時間帯指定も可能。

2. クラウドをローカルドライブとしてマウント

rclone mount gdrive: ~/mnt/gdrive --vfs-cache-mode writes

既存のファイラーやエディタからそのまま開けるが、大量の細かい読み書きには向かない。書き込みを伴うなら--vfs-cache-modeを付けないとアプリ側が失敗することがある。

3. RAGパイプラインの原本集約——RAGを組むときに最初にぶつかるのは、ベクトルDBの選定ではなく原本がどこにあるか分からない問題だ。営業資料はGoogle Drive、議事録はOneDrive、ログはS3という状態から始まることが多く、Rcloneはこの収集レイヤーを1本のコマンドに畳める。

rclone copy gdrive:営業資料 ./corpus/sales   --include "*.{pdf,docx,pptx}"
rclone copy onedrive:議事録  ./corpus/minutes --include "*.{docx,md}"
rclone copy s3:archive/2025  ./corpus/archive --max-age 365d
rclone check ./corpus s3:archive/2025   # 取りこぼしゼロをコマンドで確認

--include/--excludeで拡張子や期間を絞ってから落とすのが要点だ。全部落としてから不要分を捨てるより、転送量も時間も桁で変わる。--max-ageは更新日時での絞り込みで、「直近1年分だけをインデックスする」といった要件をそのまま書ける。定期的に取り直す運用なら、収集先はcopyで積み増し、インデックス済みの成果物側だけをsyncでミラーする構成にすると安全だ（原本側をうっかりsyncすると、前述の「宛先が消える」事故がそのままRAGの原本コーパスに起きる）。

収集レイヤーをRcloneに寄せる利点は2つある。1つは認証を1か所に集約できることだ。サービスごとのSDK・トークン管理を個別に書かずに済み、rclone.confだけを守ればよくなる。もう1つは再実行が安全なことだ。同一ファイルはサイズと更新時刻（またはハッシュ）で判定してスキップするため、cronで毎日回しても無駄な転送が起きない。

集めた原本の中身をテキストに落とす工程は別のツールの仕事になる。PDFの表や数式まで拾うならMinerU｜PDFをマークダウンに変換するOSSツール、その先のチャンク分割・検索・生成を一気通貫で組むならRAGFlow｜エンタープライズRAGエンジンの導入と使い方が対応する。LangChainでRAGを実装する場合はLangChainを使ったRAGの構築方法も参照されたい。

4. クラウド移行・冗長バックアップ——既存のオンプレミスストレージやGoogle DriveのデータをAWS S3へ移行する場合、rclone copyはテラバイト単位のデータも帯域幅制限を設定しながら無停止で移行できる。単一クラウドの障害に備えるなら、S3とBackblaze B2に同じデータを二重保存する冗長構成も同じcopyコマンドの繰り返しで組める。

# S3からBackblaze B2へも同じデータを保存する冗長バックアップ
rclone copy /data s3:primary-bucket
rclone copy /data b2:secondary-bucket --bwlimit 10M

暗号化が要る場合：rclone configで”crypt”を選び既存リモートをラップすると、ファイル名も中身もクラウド事業者側から見えなくなる。復号にはRcloneの設定（パスフレーズ）が必要なので、設定の紛失＝データの紛失になる。

よくあるエラーと確認手順：

転送失敗時は既定でリトライが働く。--retries（デフォルト3回）は転送全体のやり直し回数、--low-level-retries（デフォルト10回）はAPI呼び出し単位の再試行回数で、両者は別レイヤーの設定だ。失敗したファイルだけを記録して後から再転送することもでき、大量ファイルの夜間バッチでネットワークが不安定でも運用が破綻しにくい設計になっている。

まとめ｜Rcloneが向いている人・向いていない人

Rcloneは「クラウドのファイルをローカルに全部落としてから、別のクラウドに上げ直す」という作業をコマンド1つに置き換えるツールだ。向いているのは、複数ストレージ運用中のエンジニア、cron等で定期バックアップを自動化したい人、テラバイト単位のファイル移行を控えている組織、オンプレとクラウドのハイブリッド環境を扱う人。GUIでの操作に慣れたチームより、スクリプト化・自動化を前提に運用するチームとの相性がよい。

導入前に確認しておきたい点も正直に書く。マウント機能はネットワークレイテンシのぶんローカルディスクほど速くない。GUIは無いためWebUIが欲しいなら別ツールとの組み合わせが要る。何より「同期していたから安心」は成立しない——syncは送信元の状態をそのまま宛先に反映するため、送信元で誤ってファイルを消したまま同期すると宛先からも消える。世代管理が要る用途では--backup-dirで退避先を指定するか、宛先側のバージョニング機能を有効にしておく。