クラウド同期を2つ重ねると起こること
「ファイルを消したはずなのに、しばらくすると勝手に戻ってくる」。
こんな経験はないでしょうか。
これは特定のアプリだけで起きる話ではありません。
Dropbox と Google Drive、iCloud と OneDrive のように、同じフォルダを2つの仕組みで同時に同期していると、構造的に起こり得る現象です。
片方が「ファイルが消えた」と認識し、もう片方が「まだあるはずなのに無くなっている」と認識します。
すると後者が親切心で復元してくれます。
これが延々と繰り返されます。
今回は、僕自身が実際にこれで半日ハマった話を書きます。
普段 i.tes+【アイテスプラス】として中小企業の IT 相談を受けている立場ですが、今回は自分のノート環境で起きたトラブルの記録です。
僕は Obsidian と Claude Code を組み合わせて「外部脳」を育てる、という話をこれまで3本の記事にしてきました。
今回はその4本目です。
シリーズを読んでいなくても、単体で読めるように書いていきます。
消したはずのファイルが、なぜか戻ってくる
きっかけは、Obsidian の Vault（ノートの保管庫）を整理していたときのことでした。
不要になったファイルを、5つの案件フォルダから消していきました。
件数にすると71件です。
NAS 上に残していたコピーと全件を SHA-256 で照合し、一致71件・不一致0件を確認したうえで、削除に踏み切りました。
ところが、消しても消しても、しばらくすると同じファイルが戻ってきました。
半日、行ったり来たりを繰り返しました。
結論から言うと、Dropbox 自体は正常に動いていました。
犯人は、Obsidian に入れていた同期用のプラグイン「remotely-save」が作っていた「控え」フォルダとの二重同期でした。
ここから、どう突き止めたかを順番に書いていきます。
最初は Dropbox を疑いました
Vault は Dropbox のフォルダの中に置いてあります。
ファイルが消えて戻ってくるとなれば、まず疑うのは Dropbox です。
「Dropbox が削除を取り消しているのではないか」。
最初はそう考えて、Dropbox 側の設定ばかり調べていました。
そこで思いついたのが「同期を一時停止してから消せばいい」という対策でした。
一時停止すれば Dropbox は何も見ていないはずなので、その間に消してしまえば安全だろう、という理屈です。
実際に試してみました。
同期を一時停止し、71件をまとめてゴミ箱へ移動し、数え直すと5つの案件フォルダすべてが0件になりました。
ところが、同期を再開した数分後には、ほとんどのファイルがそっくり復活してしまったのです。
これで分かったのは、一時停止は逆効果だったということでした。
止めている間の削除を Dropbox が見ていないため、再開した瞬間に「サーバー側が正しい状態だ」と判断して、配り直してしまいます。
しかも、もう1つの同期の仕組み（Obsidian内で動き続けているremotely-save）は止まっていなかったため、二重に押し戻される形になっていました。
「同期を止めれば安全」という発想そのものが、そもそも間違っていたわけです。
突破口は Dropbox のイベント履歴でした
原因を推測するのをやめて、記録を見ることにしました。
見たのは Dropbox の「イベント履歴」（dropbox.com/events）です。
そこには、削除や追加のログが時系列で並んでいます。
その中の「場所」の欄を見て、はっとしました。
「（ファイル名）」ファイルを削除しました 場所：remotely-save
「output」と他のフォルダを追加しました 場所：ユーザー名のフォルダ
「場所」が2種類あったのです。
自分では1つのフォルダしか同期していないつもりだったのに、記録の上では2つの発生源が存在していました。
この1行が、半日の迷走を終わらせた突破口でした。
同じように「そんなはずないのに」と首をひねった経験のある方も、いらっしゃるかもしれません。
推測で設定をいじり続けるより、ログを見る方がずっと早かったです。
実は Vault が2セットありました
調べてみると、Vault の中身は Dropbox の中に2セット存在していました。
1つは、Dropbox が同期している「本体」です。
これはいつも Obsidian で開いているものと同じ場所です。
もう1つは、Obsidian のプラグイン「remotely-save（Obsidian 内で動くプラグイン）」が作っていた「控え（Dropbox/アプリ/remotely-save/）」です。
これは iPhone に Vault を届けるための中継地点で、本体と双方向に同期する設定になっていました。
ファイルを消す
↓ しばらくすると
remotely-save が起動
↓
「控えにはあるのに、本体から消えている」
↓ 双方向設定なので
本体へ復元
↓
Dropbox アプリがその復元をサーバーへアップ
同じ場所を、2つの仕組みで同時に同期させていました。
これは残念ながら remotely-save の仕様なのでこちらが注意しながら削除するしかない。
これが、消しても消しても戻ってくる仕組みの正体でした。
Dropbox は最初から正常に動いていました。
「本体から消えたものを、控えの通りに戻す」という、双方向同期としては正しい仕事をしていただけだったのです。
「Obsidian を終了してから消す」も思い込みでした
原因が分かったところで、正しい消し方を探る作業に入りました。
最初に立てた仮説は「Obsidian を終了させてから消す必要がある」というものでした。
プラグインが動いているから復元されるのだろう、なら Obsidian を終了してしまえばいい、という考え方です。
ところが、実際に起動中と終了中それぞれで消してみて記録を突き合わせてみると、成功していた実測ログは、すべて Obsidian が起動したままの状態でした。
自分で取っていた監視ログに、ちゃんと「起動中」と書いてあったのに、それを読み落としていたのです。
正しくは逆で、Obsidian を終了すると remotely-save も止まってしまうため、削除がいつまでも本体へ伝わらない、というだけの話でした。
思い込みで手順を組み立てると、自分の取ったデータすら正しく読めなくなる、という反省が残りました。
消す場所を変えたら、その場で消えました
ここでの発想の転換は、私 自身のものでした。
本体からいくら消しても控えが押し戻してくるなら、先に控えのほうを消してみたらどうか、と思いついたのです。
試してみると、あっけないほど簡単に解決しました。
控えから消してから20秒足らずで、本体からも消えました。
そのまま待っても戻ってきませんでした。
削除については、控えのほうが「正」として振る舞っていました。
本体から消すと控えが押し戻し、控えから消すと本体に伝わります。
支配関係が逆転していたわけです。
「全部は戻ってこない」にもちゃんと理由がありました
今回のトラブルには、もう1つ不思議な点がありました。
消したファイルの一部は戻ってくるのに、一部は戻ってこなかったのです。
原因は、控え側の同期プラグインが「1MB を超えるファイルは同期しない※1」という設定になっていたことでした。
つまり、大きいファイルはそもそも控えに存在していなかったのです。
控えに実体がなければ、押し戻しようがありません。
だから、大きいファイルだけは消したままでした。
原因が分かったあとで、戻ってきたファイルをあらためて見直してみました。
戻ってきたファイルは、すべて1MB 以下のものでした。
1MB を超えるファイルは、1つも戻ってきませんでした。
たとえば、作業データ用フォルダにあった大きな画像は、1枚あたり1MB を超えていたため、最後まで一度も戻ってきませんでした。
「戻ったり戻らなかったりする」のは、気まぐれでも不具合でもありません。
戻す側が持っているファイルだけが、戻ってくる。
それだけの、単純な理屈でした。
※1 今回 Obsidian は iPhone とも同期させたかったため、Obsidian（remotely-save）の設定でiPhoneのストレージに負荷がかからないように1MB以下のものしか同期できないようにしていたんです。
それを忘れていました（笑）
検証してわかったこと
最終的に、消し方によって結果がどう変わるかを、実際に手を動かして確かめました。
まずは、うまくいかなかった4つのやり方です。
| やり方 | 結果 |
|---|---|
| Dropbox Web から消す | まるごと復活した |
| Finder から本体を消す（Obsidian 起動中） | 一部が復活し、中途半端なところで釣り合った |
| Obsidian から消す（Obsidian 起動中） | 同じく中途半端なところで釣り合った（4つの中では一番マシ） |
| Dropbox アプリの同期を一時停止してから消す | 逆効果（止めている間の削除を Dropbox が見ていない上に、プラグインは止まらない） |
そして、本体と控え、それぞれをどのタイミングで消すとどうなるかをまとめたのが、この表です。
| 本体から消す | 控えから消す | |
|---|---|---|
| Obsidian 起動中 | ❌ 戻る | ✅ 消える（20秒） |
| Obsidian 終了 → 再起動 | ✅ 消える（15秒） | ✅ 消える |
先ほどの「うまくいかなかった4つのやり方」の中の「Obsidian から消す（起動中）」を合わせると、ここまでで5パターンを1つずつ確認したことになります。
ダメなのは「Obsidian 起動中に、本体から消す」の1パターンだけでした。
それ以外の組み合わせは、すべて正しく削除が反映されました。
消し切ったあと、Vault はこうなりました
正しい手順が分かってからは、5か所の対象フォルダすべてを、問題なく0件まで消し切ることができました。
Vault 全体の容量は、342MB から 61MB まで減りました。
削減率にすると82%です。
一番気になっていたのは、メモ（.mdファイル）が巻き添えで消えていないか、という点でした。
確認したところ、メモが入っていた案件フォルダの件数は、7件・17件・18件・17件と、すべてそのまま残っていました。
残る1つの作業データ用フォルダは、もともと画像や書き出しデータだけの場所だったので、メモの巻き添えはどこにも起きていませんでした。
消えたのは、Vault の容量を圧迫していた画像や書き出しデータだけでした。
この経験から持ち帰ってほしいこと
技術的な設定の話は、環境によって細部が変わります。
ですが、今回の経験から持ち帰ってほしいことは、もっとシンプルな3つです。
おわりに
今回のトラブルは、Dropbox が悪かったわけではありませんでした。
Dropbox は最初から最後まで、設定どおりに正しく動いていました。
原因は、僕自身が iPhone にも Vault を届けたくて入れていた、もう1つの同期の仕組みでした。
便利にしようとして足した仕組みが、思わぬところで足を引っ張っていた、という話です。
このシリーズはいつも書いている通り、あくまで僕自身が試行錯誤している記録です。
同じような環境で同期プラグインを使っている方は、バックアップを取った上で、自己責任で確認してみてください。
この記事は Obsidian × Claude Code「外部脳」シリーズの第4弾です。
コメント