iCloud Drive 同期トラブルの落とし穴メモ
📌 記事の取り扱いについて（公開当時の内容を含みます — タップで詳細）
本記事は公開当時の体験・気づきをまとめたものです。現在のツール数・プラン数・対象年齢・記事数・仕様とは異なる場合があります。最新の内容は各ツールページをご確認ください。ツールや外部サービスの仕様・料金は変更されることがあるため、利用前には各公式情報も併せてご確認ください。記載に誤りを見つけられた場合はお問い合わせフォームよりご連絡いただけると助かります。
私は2台の Mac を行き来して作業しています。この記事を書いた当時は、プロジェクトのフォルダをまるごと iCloud Drive に入れていました（いまは本体を iCloud の外へ移しています。詳しくは後半の追記に書きました）。
この「2台運用」そのものの全体像や、雲マークを待つ・並行作業をしない、といった日々の運用ルールは 2台のMacをiCloudで行き来する運用 に書きました。環境や運用の話はそちらを読んでもらうとして、この記事は「同期そのものの技術的な落とし穴」に絞ります。
便利な仕組みなのですが、油断すると地味な事故を踏みます。私が実際に踏んで「これは記録しておかないと、また同じところでハマるな」と思ったものを、3つに絞って書いていきます。
落とし穴1: 「hoge 2.txt」型の重複コピーと、その二次災害
一番ひやっとしたのが、ファイルがいつの間にか二重になる現象です。
具体的には、ある日フォルダを覗くと「hoge 2.txt」のように、末尾に半角スペース＋数字が付いたコピーが増えていることがあります。これは iCloud が同期中に「ファイルの食い違いが起きた」と判断したときに、片方を別名で残しておく動きだと理解しています（細かい仕様までは追えていません）。2台のあいだだけでなく、1台で大量のファイルを一気に書き換えたときにも起きました。
厄介なのはここからです。コピーが「hoge 2.txt」として増えるということは、本来の「hoge.txt」のほうが中身を失っている、あるいは消えたように見えるケースがあるのです。私が踏んだときは、元の style.css が消えて、style 2.css だけが残っているという状態でした。
これ単体でも面倒なのですが、もっと怖いのは二次災害でした。
私のサイトは、ファイルが見つからないときに「とりあえずトップページを表示する」挙動をするホスティングに置いています。便利な反面、これが裏目に出ます。たとえば style.css が重複コピー側に逃げて元のファイルが消えても、配信側は「ファイルが無い」と正直にエラーを出さず、代わりにトップページのHTMLを返してしまうのです。
そうすると、ブラウザは「CSSのつもりで読み込んだものがHTMLだった」という状態になります。404（見つかりません）にはならず、通信の結果だけを見ると200（正常）のままなので、機械的なチェックでは気づけません。少なくとも今回のCSSでは、見た目だけがなぜか崩れているという分かりにくい形で現れました。原因にたどり着くまで、余計に時間がかかりました。
教訓は、「ファイルが無いときに別ページで代用する」設定のサイトでは、同期事故で中身が抜けた欠損を、エラーではなく見た目の崩れとして探さないといけない、ということです。重複コピーを見つけたら、本体側の中身が無事かを毎回セットで確認するようにしました。
落とし穴2: ファイルの最終更新時刻(mtime)は当てにならない
次に踏んだのが、ファイルの最終更新時刻にまつわるズレです。
ファイルには「最後に書き換えられたのはいつか」という時刻（よく mtime と呼ばれます）が記録されています。ふつうは「新しいほうが最新」と判断する目安になります。ところが iCloud Drive 配下では、この時刻が同期のタイミングで書き換わってしまうことがありました。実際に中身を編集していなくても、別端末に降りてくる過程で時刻が更新されたように見えるのです。
これに足をすくわれたのが、毎日決まった時間に動く自動処理の「生きているか／止まっているか」の判定でした。
その処理が最後に動いた時刻を、私は単純にファイルの更新時刻で見ていました。すると、本当は毎日ちゃんと動いていたのに「2日続けて止まっている」と誤判定してしまったのです。原因は処理が止まったことではなく、iCloud が再展開したときの時刻を、処理が動いた時刻と取り違えていたことでした。
ここから学んだのは、iCloud 配下のファイルでは「いつ更新されたか」を更新時刻で判断しない、という割り切りです。代わりに、その処理が残す履歴そのもの——私の場合は Git（変更履歴を残す仕組み）の履歴に残る、変更が記録された日時——を見るようにしました。この日時は、ファイルが同期されただけでは書き換わりません。
「ファイルの時刻は嘘をつくことがあるので、本当の履歴は別のところで持つ」。これは iCloud に限らず覚えておくと良さそうな考え方だと感じています。
落とし穴3: 「三重の保険」のつもりが、同じ場所でぶつかった
落とし穴1と2をくぐったうえで行き着いたのが、そもそも本体を iCloud だけに預けない、という設計です。
iCloud Drive で持ち歩けるのは確かに便利です。でも、ここまで書いたとおり、同期は時々ファイルを別名で増やしたり、時刻をいじったりします。「iCloud にしか無い大事なファイル」が同期事故で壊れると、ほかに控えがなければ取り戻せないおそれがあります。
そこで当時の私は、ソースコードや原稿の本体は Git で履歴管理し、そのGit で変更履歴を残しているフォルダごと、丸ごと iCloud に置く、という重ね方にしていました。図にすると入れ子で、「Git で管理されているフォルダ」を「iCloud が同期する場所」に入れている、というイメージです。
この重ね方には、私が「三重の保険」と呼んでいた効きめがありました。
- 保険1: iCloud が同期事故を起こしてファイルが消えても、Git に記録してあれば、その記録した時点の中身には戻せる（記録していない変更までは守られません）。
- 保険2: あとから「いつ・どこを変えたか」を Git の履歴でたどれるので、おかしくなった時点まで巻き戻して再現できる。
- 保険3: 2台の端末でズレが起きても、Git の差分として「どちらが何を変えたか」が目に見える。雲マークを眺めるよりずっと確実です。
ポイントは、iCloud と Git をどちらか選ぶものとして考えない、ということです。iCloud は「同じファイルパスで2台から開ける手軽さ」を、Git は「壊れても戻せる履歴」を担当する。役割が違うので、重ねて使うほど守りが厚くなる——当時はそう考えていました。
ちなみに、この「Git で変更履歴を残しているフォルダごと iCloud に置く」やり方は、当時の私の環境でうまく回っているように見えた、というだけの話です。実際には、このあと同じ場所で iCloud と履歴管理がぶつかりました。
2026年8月の追記：この「重ねる」やり方は、結局そのままでは続きませんでした。変更履歴そのものを入れているフォルダまで同期の対象になっていたため、iCloud と履歴管理がお互いのファイルを取り合って、古い状態に巻き戻る事故が何度か起きたからです。いまは主なプロジェクト本体を iCloud の外（各Macの中）に置き、2台のあいだの受け渡しは GitHub（変更履歴を預けておくネット上の置き場）を経由する形に変えました。「本体は履歴で守る」という考え方は変えていませんが、その履歴のフォルダを iCloud に入れるのはおすすめしません。
まとめ
iCloud Drive にプロジェクトをまるごと置く運用は、公開当初は快適に感じていました。いまはこの運用をやめています。事故の見つけ方は分かってきたものの、巻き戻りが続いたので、最終的には置き場所そのものを変えました。同期には独特のクセがあって、
- 重複コピー（
hoge 2.txt型）で元のファイルが消え、しかも見た目の崩れとしてしか現れないことがある - ファイルの更新時刻は同期で書き換わるので、新旧の判断には使わない
- 本体は Git で履歴を持って守る（ただし、その履歴フォルダごと iCloud に入れるのは避ける／2026年8月の追記）
このあたりを「そういうものだ」と知ってからは、事故に気づくのは早くなりました。ただ、気づけることと起きないことは別で、結局は置き場所のほうを変えることになりました。仕組みを完璧に把握しているわけではありませんが、踏んだ落とし穴を一つずつメモして潰していく、というのが今のところ私には合っています。
← 他の制作記を見る ｜ トップ ｜ お問い合わせ