これまで、Ripplic のパイプラインはすべてローカルフォルダから始まっていました。FSEvents がフォルダを見張り、あらゆる変更を選んだ宛先へ一方向にレプリケーションする——次のアップデートで、この起点がクラウドに移ります。Google Drive がソースになれるようになりました。
Google Drive ──▶ Cloudflare R2
──▶ Amazon S3 / MinIO / B2 / GCS（S3 互換ストレージすべて）
──▶ 別の Google Driveファイルは Drive から宛先へ直接流れます。間にサーバーは存在しません——あなたの Mac が唯一の経路で、認証情報は macOS のキーチェーンから一歩も外に出ません。これは Ripplic が初日から掲げてきた約束であり、クラウドソースでも曲げません。
3 番目のパイプラインが Google Drive のフォルダから読み取り、AWS us-east-1 の S3 バケットへレプリケーション中（15.5 MB/s）。各パイプラインは独立していて、遅い宛先が他を止めることはありません。
サーバーなしで変更を検知する
ローカルフォルダはイベントをアプリに push できますが、クラウドはできません。Google の push 通知には公開 HTTPS エンドポイント、つまりサーバーが必要だからです。Ripplic はサーバーを持たないので、Drive が提供するもう一つの仕組みを使います：changes.list デルタフィードです。
Google のサーバーは、あなたの Drive で起きたすべての変更のジャーナルを保持しています。Ripplic はそのジャーナルへのカーソルを持ち、30 秒ごとに「ここから何が起きた？」と尋ねます。答えは変更リストと新しいカーソル。カーソルはディスクに保存されるので、アプリを再起動してもフィードは中断した正確な位置から再開します——再スキャンは不要です。
この設計をスケールさせる性質はこれです：静かなポーリング 1 回のコストは、Drive の大きさと完全に無関係。フォルダに 100 ファイルあろうと 10 万ファイルあろうと、小さな HTTPS リクエスト 1 つ。変更があったときのコストは変更の数に比例し、ツリー全体のサイズには決して比例しません。
イベントは事実ではなくヒント
Ripplic のエンジンは、あらゆる変更イベントをヒントとして扱います。検証する価値はあるが、鵜呑みにして動くことはない。ヒントされたパスは Drive の実際のメタデータとローカルインデックスに照合されてから、初めて転送が始まります。イベントの欠落も重複も順序の乱れも——すべて無害です。定期的なフルスキャンがすべてを裏支えし、正確性が個々のイベントの捕捉に依存することはありません。
厄介なケースにもきれいな答えが出ます。Drive でファイル名を変えると、旧パス（削除ポリシーに従って処理——デフォルトはフラグのみ、あなたの許可なしに何も削除されません）と新パスの両方がヒントされます。フォルダの名前変更は配下のすべてのパスを変えるので、エンジンはツリー全体の再スキャンにフォールバックします——エラーではなく、優雅な縮退です。
Mac が 1 週間オフラインだったら？
Ripplic を閉じていた——あるいは Mac がスリープしていた——間に、Drive で何百ものファイルが変わったとします。追いつくために履歴を再生することはありません。パイプラインは起動のたびに、まず全ファイルのチェックサムとサイズをローカルインデックスと突き合わせる完全比較を行います。実際に違うものだけが転送され、留守中に 100 回編集されたファイルもアップロードは 1 回だけ——最終版だけです。
その後、デルタフィードが保存済みカーソルから再開し、Google がその間のすべての変更を再生します。大半はすでに比較で処理済み——それで構いません。重複ヒントはもともと無害に設計されているからです。休止が長すぎてカーソル自体が失効していたら、ソースは新しいカーソルを取得してもう一度フルパスを要求するだけ。エラーではなく、優雅な縮退です。
これを中断に強くしている細部がひとつ：カーソルはそのバッチの処理が完了した後にだけ永続化されます。キャッチアップ自体が中断されても、次回起動は最後に完了した位置から再開。取りこぼしは決して起きません。
ドリフトはどう扱う？
状態がずれるもうひとつの経路があります。誰かが Ripplic を経由せず宛先を直接触った場合——たとえば S3 コンソールでオブジェクトをいくつか削除した、など。日々の照合はソースとローカルインデックスを比べるもので、意図的に毎回宛先まで監査はしません。だからこの種のドリフトは普段は見えません。そのために Ripplic には独立した監査経路があります：パイプラインメニューの「Verify Destination Now」と、パイプライン再開時の自動監査です。
監査のやることはシンプルです。インデックスが「同期済み」と信じているファイルごとに、宛先にオブジェクトがまだ存在し、サイズが一致するかを確認する。欠けていたり合わなかったりしたら、その同期状態をクリアする——次のパスで壊れたファイルだけが再アップロードされます。無傷のファイルは 1 つも余計に送りません。修復は常にソースから外へ向かって流れ、宛先の状態がソースに書き戻されることはありません。一方向は鉄則で、ドリフト修復も例外ではありません。
現在の監査は存在とサイズを検証します。次の段階では、Ripplic がすでに保持しているブロック単位のハッシュを使って内容を直接比較すること、そしてスケジュール監査（アイドル時に日次・週次で自動実行）に取り組んでいます。目標は変わりません：宛先が誰にも触られていないことを「信じる」必要はなく、ワンクリックで「証明」できるべきです。
変わっていないファイルは 1 バイトもダウンロードしない
Drive はファイルごとのメタデータに MD5 チェックサムとサイズを含めて返します。Ripplic はそれをインデックスと比較して変更を判定します——「実は同一だった」と確かめるためだけに中身をダウンロードすることはありません。実際に転送するときはチャンク単位でストリームするので、20 GB の動画も 2 KB のメモも、メモリ使用量は同じくフラットです。
読み取り専用であることが設計
Drive を宛先として接続するときの権限は drive.file——Ripplic は自分が作ったファイルにしか触れません。ソースは逆の問題で、既存のファイルが見えなければならないため drive.readonly を求めます。要は「読み取り専用」：Ripplic のソースに書き込みが起きることはありません。一方向は一方向です。ソースが机の上のフォルダでも、クラウドの Drive でも。
正直な制限をひとつ：Google ドキュメント・スプレッドシート・スライドにはレプリケーションできるファイルバイトがありません——クラウド文書としてのみ存在します。Ripplic は近似品をエクスポートするのではなく、スキップする道を選びました。
リリース時期
ソースとしての Google Drive は現在テスト中で、次のアップデートで登場します。既存のソース（ローカルフォルダ・外付けドライブ）と宛先はそのまま。Dropbox と OneDrive も同じ設計図に従います——エンジンはもともと「デルタフィード」を母語として育っているので。