Each language version is independently generated for its own context, not a direct translation.
🍎 iCloud の「嘘」と「真実」
この論文の核心は、**「iCloud は『ファイルシステム』を装っているが、実は『交渉システム』に過ぎない」**という点にあります。
1. 魔法の箱という嘘（カテゴリの誤謬）
Apple は iCloud を「あなたのパソコンのフォルダが、魔法のようにすべてのデバイスにコピーされる箱」と宣伝しています。
- ユーザーの思い込み: 「ファイルを保存したら、すぐに他の端末にも反映されるはずだ」「ファイル一覧に表示されていれば、それは中身が入ったファイルだ」と信じています。
- 現実: iCloud は、**「ファイル一覧は表示するが、中身は必要になるまで送らない（データレスファイル）」**という仕組みを使っています。
- 比喩: これは、**「図書館の目録には本の名前が載っているが、実際に本棚から本を取り出そうとすると、その本がどこか遠くの倉庫に隠されていて、取り出せるかどうかわからない」**ような状態です。
- 問題点: 「目録（一覧）」と「本（中身）」が一致しないため、プログラム（Git やビルドツールなど）が「ファイルがあるはずだ」と信じて作業を始めると、突然「ファイルが見つからない」とエラーになり、データが壊れてしまいます。
2. 「タイムマシン」と「Git」が壊れる理由
iCloud は、**「最後に書き換えた方が正解（Last-Writer-Wins）」**というルールで競合を解決します。しかし、これは「時計の時間」に頼っているため、時計がズレていると大惨事になります。
- Git（バージョン管理）の悲劇:
- Git は「ファイルのロック（鍵）」を使って、誰が書き込んでいるか管理します。
- iCloud はその「鍵（ロックファイル）」を単なるファイルとして扱って、他の端末に送ってしまいます。
- 比喩: 二人の作家が同じ原稿を編集しようとして、A が「今から書くから鍵をかける」と言いました。しかし、iCloud がその「鍵」を B の部屋に送ってしまいました。B は「鍵があるから、A が書いている」と思い込み、原稿を書けなくなります。あるいは、iCloud が「A と B が同時に書いた」と誤解し、「A の原稿」と「B の原稿」を勝手に「A_2」という名前でコピーしてしまい、元の原稿を消去してしまうことがあります。
- 結果: 論文では、366GBものデータが、iCloud の同期ミスによって「消えた」「重複した」「中身がバラバラになった」という実例が紹介されています。
3. 「時間」の魔法が解ける瞬間
iCloud の最大の問題は、**「過去から未来へ、一方向にしか進めない（FITO）」**という考え方です。
- 現実のネットワーク: 通信は時々切れます（飛行機に乗る、地下鉄に入るなど）。
- iCloud の対応: 通信が切れている間、それぞれの端末で勝手に変更を加えます。そして通信が復旧した瞬間、iCloud は「どちらの時間が新しいか」だけを見て、**「古い方のデータを消して、新しい方で上書きする」**という暴挙に出ます。
- 比喩: 二人の兄弟が、別々の部屋で「家族の歴史」を書いています。通信が切れている間、兄は「お父さんが誕生日を祝った」と書き、弟は「お父さんが旅行に行った」と書きました。通信が復旧した瞬間、iCloud は「弟の方が少し後に書いたから、兄の文章は消して弟の文章に統一する」と判断します。しかし、実際には「お父さんは誕生日に旅行に行った」のが真実だった場合、iCloud はその真実を消去してしまいます。
🌊 解決策：OAE（オープン・アトミック・イーサネット）の提案
著者は、iCloud のような「上からの無理やりな解決」ではなく、**「物理的な現実（リンクの状態）」**に忠実な新しい仕組みを提案しています。
1. 三角形の信頼関係（Triangle Topology）
現在のクラウドは「すべての端末が中央のサーバーに繋がる」星型です。サーバーが迷ったり、通信が切れたりすると、誰が正しいか判断できません。
- 新しい考え方: 3 台の端末（A, B, C）が、お互いに直接繋がって「三角形」を作ります。
- 比喩: A と B の通信が切れた時、C が「A と B は今、繋がっていないね」と仲介役（トランザクション管理）になって、**「待て、まだ確定していないから、無理やり上書きするな」**と止めます。
- メリット: 通信が切れている間は「進めない（待機）」状態になり、**「間違ったデータで上書きして壊す」**という最悪の事態を防ぎます。
2. 「双方向の確認」がなければ進まない
iCloud は「送ったから送れた」と思い込みますが、OAE は**「受け取った側から『確かに受け取った』という返事が来るまで、送ったことにはしない」**というルールを徹底します。
- 比喩: 手紙を送る際、iCloud は「ポストに入れたから送れた」と言いますが、OAE は「相手が『受け取りました』と返事をくれるまで、手紙はポストに入れない（あるいは、受け取れなかったら元に戻す）」という仕組みです。これにより、**「送ったつもりなのに消えた」「重複して送れた」**という悲劇がなくなります。
📝 まとめ：この論文が言いたいこと
iCloud の失敗は「バグ」ではなく「設計思想の誤り」です。
- 「通信が不安定な世界」で「完璧なファイルシステム」を真似しようとしたことが、すべての原因です。
- 「目録がある＝ファイルがある」という前提が崩れているため、開発者や自動化ツールは常に失敗します。
データは「消えない」べきです。
- iCloud は「時間」で勝敗を決めてデータを消去しますが、本当は「両方のデータを保存し、人間がどうするか決める」べきです。
解決策は「物理的な現実」に立ち返ることです。
- 通信が切れている間は「待機」し、確実な「双方向の確認」があって初めて「完了」とする。
- 中央のサーバーに頼らず、端末同士が直接繋がり、互いに監視し合う「三角形」のネットワークを作る。
一言で言えば：
「iCloud は、『魔法のように何でも完璧に同期する』という嘘を信じているから失敗します。本当の解決策は、『通信が切れている時は無理に進まず、お互いに確認し合う』という、少しだけ面倒だが確実な現実を受け入れることです。」
この論文は、私たちが「クラウドは万能だ」と思い込んでいることに警鐘を鳴らし、**「データは物理的な実体であり、安易に消去したり上書きしたりしてはいけない」**という、非常に哲学的で重要なメッセージを伝えています。