GeminiのGoogleドライブ全削除騒動を検証：rcloneの「ゴミ箱だけ表示」はバグだったのか？

2026年11月4日、Xで「AIにGoogleドライブのファイル整理を任せたら、データを全部削除された」という投稿が話題になった。投稿画像に写ったAIの説明には、rclone --drive-trashed-only の「バグ」が原因だったという主張がある。

しかし、同じバージョンのrcloneを実際に動かしてみると、別の構図が見えてきた。問題の本質は「ゴミ箱内のファイル」と「そこへ到達するために表示される通常フォルダ」の取り違え、そしてGoogle Drive APIで完全削除を実行したことにある可能性が高い。

検証の前提：この記事は手元で実施した読み取り専用の再現テスト、rclone公式資料、Google Drive API公式資料、Xの投稿画像を突き合わせた技術的考察。投稿者の実際の操作ログやGoogle側の監査ログは確認していないため、AIが何を実行したかについては投稿画像中の自己申告に基づく。

発端：何が起きたと報告されているのか

発端はてささんのX投稿（2026年11月4日）。添付されたスクリーンショットでAIは、Googleドライブの実データを完全削除したと謝罪している。

画像中のAI自身の説明を整理すると、次のようになる。

--drive-trashed-only を指定した一覧に、ゴミ箱にない通常フォルダが混ざっていた。
AIはそれらを「ゴミ箱の古いコピー」と誤認した。
トップレベルのフォルダをID指定でGoogle Drive APIの files.delete に渡し、完全削除したと説明した。
保存容量が3.36TiBから34MiBに減ったと報告した。

ここで重要なのは、この説明が事故を起こしたとされるAIの自己申告であること。具体的な削除リクエストや結果のログは、今回確認できた資料には含まれていない。したがって、「この機序で事故が起きた」と断定せず、どこまで実証できるかを分けて検証する。

実機検証：rclone v1.75.2で何が表示されたか

検証環境はWindows 11、rclone v1.75.2、Google Drive。マイドライブには通常状態の ChatGPT フォルダを残し、比較用として画像2件と「ごみ」フォルダをゴミ箱へ移動した。「ごみ」フォルダ内にも画像ファイルが含まれている。

ふだん使うrcloneの ChatGPT: リモートは ChatGPT フォルダをルートに制限しているため、検証では設定ファイルを変更せず、コマンドに --drive-root-folder-id root を追加してマイドライブのルートを参照した。

実行したのは一覧表示だけ。削除・復元・移動は一切行っていない。

1. 通常の一覧表示

rclone lsf ChatGPT: --drive-root-folder-id root --max-depth 2

例：

ChatGPT/
ChatGPT/MCP-guide-20261104/
ChatGPT/chappy-official-three-view.png
ChatGPT/chappy-transfer-test.png

ゴミ箱に入れた画像と「ごみ」フォルダは表示されなかった。

2. ゴミ箱限定の一覧表示

rclone lsf ChatGPT: --drive-root-folder-id root --max-depth 2 --drive-trashed-only

実際の出力：

ChatGPT/
IMG_20261101_010309.jpg
IMG_20261102_180842.jpg
ごみ/
ごみ/mcp-beginners-diagram.png
ごみ/日本文化と世界をつなぐ風景.png
ChatGPT/MCP-guide-20261104/

ここが落とし穴。ゴミ箱に入れていない ChatGPT/ と ChatGPT/MCP-guide-20261104/ まで表示された。 ただし、通常状態の画像ファイルは表示されていない。

3. ファイルだけを抽出するとどうなるか

rclone lsf ChatGPT: --drive-root-folder-id root --recursive --drive-trashed-only --files-only

実際の出力：

IMG_20261102_180842.jpg
IMG_20261101_010309.jpg
ごみ/mcp-beginners-diagram.png
ごみ/日本文化と世界をつなぐ風景.png

この条件では、ゴミ箱内のファイル4件だけが表示され、通常ファイルの混入は確認できなかった。 一方、--files-only はフォルダを一覧から除くだけであり、これ単独で安全な削除処理が保証されるわけではない。

なぜゴミ箱にないフォルダが出てくる？

実は、rclone公式のGoogle Driveドキュメントには --drive-trashed-only について「ゴミ箱内のファイルを元のディレクトリ構造で表示する」と明記されている。

さらに2022年のrclone公式フォーラムでの同じ疑問に対し、開発者Nick Craig-Wood氏が、通常のディレクトリを表示しないとその内部のゴミ箱ファイルに到達できないこと、rcloneはゴミ箱の全データをドライブ全体から一括検索するのではなく、フォルダをたどるため通常フォルダも表示されることを説明している。

したがって、通常フォルダが表示されたという事実だけでは、v1.75.2固有のバグとは言えない。 少なくともこの挙動は以前から説明されている仕様と一致する。画面上の「表示対象」と、Google Drive API上の「そのフォルダ自体がゴミ箱にあるか」は別の話なのだ。

公式ドキュメント：rclone Google Drive / –drive-trashed-only

Geminiは何を勘違いしたと考えられるのか

投稿画像中のAIの説明と今回の再現結果を突き合わせると、次の推定シナリオが成り立つ。

一覧の意味を取り違えた。 --drive-trashed-only の出力にあるフォルダを、「表示されたものは全部ゴミ箱の中身」と解釈した。
通常フォルダを「削除済みの古いコピー」と誤分類した。 実際はゴミ箱内のファイルに到達するために表示されていた、生きたフォルダだった可能性がある。
削除対象のIDを照合しないまま、不可逆なAPIを使った。 画像中では files.delete を使用したと説明されている。
上位フォルダの削除で被害が連鎖した。 Google Drive APIでは、フォルダへの files.delete は所有する配下のアイテムも削除対象にする。

特に3と4が致命的。Googleの公式API仕様では、files.delete はゴミ箱を経由せず完全削除する操作。フォルダを対象にすると、その配下の所有アイテムも削除される。ゴミ箱に入れる操作と同じではない。

つまり「ゴミ箱を片付ける」というつもりで、生きたトップレベルのフォルダIDに完全削除をかけると、そこから大量のデータが消えても不思議ではない。今回のスクリーンショットに書かれた事故説明とは整合する。ただし、実際にそのIDへAPIが送信されたかは操作ログなしでは検証できない。

これはrcloneのバグ？ AIのミス？

確認項目	判定
v1.75.2で通常フォルダがゴミ箱限定一覧に出る	実機で再現した
通常ファイルまでゴミ箱限定一覧に混入する	今回のテストでは再現せず
通常フォルダの表示は既知の仕様か	公式ドキュメントと開発者の説明に一致
問題のAIがフォルダを誤認して完全削除したか	投稿画像中の自己申告。操作ログ未確認
v1.75.2固有の不具合が原因だったか	今回の証拠からは認められない

結論は、「rcloneのゴミ箱表示バグで全削除された」とする説明には根拠が足りず、むしろAIが既知の表示仕様を誤解し、危険な削除APIを使った可能性があるというもの。ただし事故当事者のログがない以上、最終的な原因の断定は控えたい。

AIにクラウド整理を任せるなら

まず読み取り専用で対象を列挙し、ファイル・フォルダ・ゴミ箱状態を個別に照合する。
「整理」「ゴミ箱を片付ける」を、完全削除の許可と解釈させない。
フォルダ単位の削除や files.delete は、対象IDと配下の件数を明示して人間の承認を取る。
削除前のバックアップや別の復元手段を確保する。
rclone自身の破壊的操作なら --dry-run や --interactive を活用する。ただしGoogle Drive APIの files.delete にrcloneの --dry-run が自動的に効くわけではない。
アクセス範囲を専用フォルダに制限するなど、必要以上の権限を与えない。

今回の教訓は「AIはコマンドを実行できるか」ではなく、「その一覧が何を意味しているか理解しているか」「削除対象を独立に検証したか」にある。技術的には小さな取り違えでも、完全削除APIと組み合わされば大事故になり得る。

参考資料

検証日：2026年11月4日。rclone v1.75.2 / Windows 11。検証作業は一覧表示のみで、ファイルに変更を加えていない。