Gmailの受信箱が消えた
一括削除事故：表示画面と本体の話
2026年5月31日
昨日、僕はいつもの習慣でメールの整理をしていました。その何気ない操作のなかで、受信箱に十数年ぶんためてきたメールを、そっくりそのままゴミ箱へ送り込んでしまいました。
しかも、その削除は、僕が普段ほとんど使わない Outlook の上での操作だったにもかかわらず、Gmail の本体にまで波及したのです。
気づいたときには、ゴミ箱のなかに8万通以上のメールが積みあがっていました。
この記事は、その事故がどう起き、僕がどう右往左往し、最終的にどう取り戻したかの記録です。
最初に書いた原稿は、かなり恨み節に近いものでした。けれども、一晩おいて考えると、この事故の本当の論点は、特定の会社への不満ではありませんでした。同期型のサービスでは、「いま画面に表示されているもの」と「データの本体」の区別を誤ると、思わぬ範囲まで操作が及ぶ。そのことでした。
同じ仕組みを使っている方の、転ばぬ先の杖になればと思います。
1. いつもの朝の習慣
僕は毎朝、ニューヨーク・タイムズと Die Zeit の記事の見出しとリードを、それぞれ5本ずつ読みます。
二か月ほど前に作った小さなプログラムが、毎朝6時半に起動して、その日の国際政治、経済などのニュースの文面、つまり見出しとリードを、自分宛てにメールで送ってくれる仕組みです。
AIのエージェント機能と、メールの自動配信を組み合わせたものですが、そのメールを送る口として、僕は Outlook を使っていました。
正直なところ、Outlook は好きではありません。だから、得意でもありません。ふだんは使わない道具です。
けれども、プログラムを作るときに参考にしたものが Outlook を呼び出す作りになっていたので、それを採用しました。おかげで毎朝、Outlook が自動で立ち上がり、僕の Gmail に宛てて送信処理をしてくれます。
ところが Outlook は、立ち上がったついでに、僕の Gmail のメールを一斉に読み込むのです。
僕は毎朝、Gmail の受信箱を必ず整理します。大事なものは読み、そうでないものは未読のままゴミ箱に捨てる。だからゴミ箱には毎日ゴミがたまりますが、Gmail は三十日たてば自動で空にしてくれます。
Outlook は、ふだんは開きません。ただ、このシステムを動かすために自動で起動するので、画面にはアクティブな状態で登場します。
つい目が向いて開いてみると、受信箱には未処理のメールが数通あります。Gmail を先に読んでから Outlook が読み込むまでには時間差があり、その間に届いたものが未処理で載っているのです。
だから僕は、Gmail でやるのと同じことをします。大事なものは読み、そうでないものはゴミ箱へ。
ところが昨日は、ゴミ箱に送るべきメールが多かった。そこでコントロール+Aで全部を選択して、まとめてゴミ箱処理をしたのです。
つまり、受信箱に表示されているものを全部選んで放り込んだ。これがその朝の、なんでもない操作でした。
そして、事故が起きました。
2. Gmailからも消えた
Outlook でゴミ箱に送ったそのとき、Gmail 側の受信箱からも、同じメールが一斉に消えていました。
気づいたのは２時間ほどたってからです。Gmail の受信箱を開くと、数件しかメールがない。「あれ、変だな」とは思いましたが、そのときは「表示の不具合かな」くらいに受け止めていました。
はっきり気づいたのは、さらに数時間後でした。その朝届いた重要なメールをもう一度読もうと受信箱をスクロールしたのに、出てこない。検索すると、ゴミ箱の中にありました。
ここで、ようやくピンときました。
Gmail のゴミ箱を見ると、その朝の既読メール、つまり重要なものも、読まずに捨てたゴミも、ごっちゃに入っています。
僕のもとには毎日たくさんのメールが届きます。その大量のメールに加えて、長年とっておいた大切なメールまでが、見境なく一つの箱に流れ込んでいました。
十年前のメールも、その朝の操作で、まとめてゴミ箱に落ちていたのです。
表示を見ると、8万通あまり。
問題は、そのなかで「読まずに捨てたゴミ」と「読んで保管していた大事なもの」が、まぜこぜになっていたことでした。
まず既読のメールだけを選んで受信箱に戻そうとしましたが、Gmail の画面は100通ずつしか表示してくれません。8万通を100通ずつ相手にしていては、日が暮れます。
3. 原因：表示画面と本体の取り違え
いくつか調べて、事故の構造がわかってきました。原因は二つ重なっていました。
一つめは、つなぎ方です。
Outlook は、僕の Gmail アカウントを IMAP という方式でつないでいます。平たく言えば、Outlook と Gmail という二つの窓が、まったく同じ一つの部屋を映している、ということです。
片方の窓から見えるメールを捨てれば、それは「Outlook の中のコピー」が消えるのではなく、「部屋そのもの」、つまり Gmail の本体から消えます。
二つめが、今回の本当の落とし穴でした。
全選択という動作の違いです。
Gmail のブラウザ画面なら、受信箱でコントロール+Aを押しても、選ばれるのは「いま画面に表示されている分」だけです。その件数は設定で20通、50通、100通などに決められます。
ところが、少なくとも僕の環境では、Outlook の受信箱を開いた状態でコントロール+Aを押すと、画面に表示されていないものまで含めて、受信箱内のメール全体が選択されたように見えました。
だから次にゴミ箱へ送れば、全部が、まとめて移る。しかも、ここが大事なのですが、その時に、確認の問いは一つもありませんでした。
ここからは、設計についての僕の考えです。
以前、僕は iPhone のアプリをいくつも作り、Apple の審査を受けていました。Apple のヒューマンインターフェースの考え方には、「取り返しのつかない操作の前には確認を求めよ」、「破壊的な操作は元に戻せるようにせよ」という原則がはっきりとあり、審査の場でもそれが実装のレベルで問われます。
表示外のものまで巻き込んで、本体に波及する削除を、無警告で実行できる。そういう挙動は、Apple の審査ならおそらく通らないでしょう。
だから僕は、これを単なる自分の不注意とだけは思えませんでした。
破壊的操作に確認を挟まない設計には、やはり問題がある。少なくとも、僕はそう感じました。
もちろん、僕の落ち度もあります。
ふだん使わない道具で、中身をよく確かめずに全選択から削除へ進んだ。これは不注意でした。
ただ、「画面に出ている行が中身のすべてであり、コントロール+Aはその表示分を選ぶ」という認識は、多くのソフトが実際そう動くからこその、ごく自然な期待でもありました。Gmail のWebは、まさにそう動きます。
だからこの事故は、僕の不注意と、設計思想の隙間と、その両方が噛み合って起きた、と考えるのが公平であり、自然なところだと思います。
救いもありました。
Gmail のゴミ箱は30日間、中身を保持してくれます。30日以内のものなら取り戻せる。今すぐ動けば、被害は最小で止められる。
4. 手作業の試みと、その限界
はじめは、Gmail のウェブ画面で地道に戻すつもりでした。
既読のメールだけを絞り込み、年ごとに区切って、少しずつ受信箱へ移す。15年ぶんの検索条件を、1年刻みで用意しました。
ところが、現実が立ちはだかりました。
「すべて選択」を押しても、見えている100通しか動きません。検索条件に一致する全部を選ぶための仕掛けも、うまく働いたり働かなかったり。一度の操作では移しきれず、何度も繰り返さなければなりませんでした。
僕は計算してみました。
一画面100通ずつ、一回15秒から30秒かけて戻すとしたら、8万通、既読のものだけでも数万通を戻すのに、いったい何時間かかるのか。
しかも、既読メールが実際に何通あるのかは、検索画面でははっきり表示されません。
答えは明らかでした。
これは人間の手でやる作業ではありません。
「本当に必要なものだけ差出人で拾えば」とも考えました。役所関係、業界団体、クライアント、大学。けれども、僕のもとには大勢の方から相談ごとのメールが届きます。あとから調べ直す必要が、いつ生じるとも知れません。
差出人を思い出して拾う方式では、必ず取りこぼす。
やはり既読のものは全部戻すしかなく、そして全部となれば、手作業は不可能でした。
5. 方針転換して機械にやらせる
ここで、発想の切り替えに行き着きました。
手で50通、100通ずつ繰り返すのが非現実的なら、Gmail を操作するプログラムを書いて、機械に淡々と片づけさせればよい。
そんなことができるとは思いもよりませんでしたが、僕にはコードを書く環境が手元にあります。慣れた道具で確実にやるのが、事故対応では正解です。
やることの本質は単純でした。
「ゴミ箱にある既読のメール」を一通ずつ、「ゴミ箱から出して受信箱に入れ直す」。
それを、何千通あろうと、プログラムにまとめて繰り返させる。人間は実行して待つだけ。30秒かかる作業を何百回も人がやる代わりに、機械が数分で終わらせます。
この発想の根っこは、僕がいつも物事を読むときに使っている簿記のレンズと、どこか通じています。
既読を「保全すべき資産」、未読を「流してよい費用」と見立て、資産だけを選り分けて元の場所へ戻す。そして手作業のコストを見積もり、高すぎると判れば自動化へ振り替える。
6. 復旧
そこからは、復旧用の小さなプログラムをこしらえました。
プログラムが僕のアカウントに正式にアクセスするためのGoogle側の認証情報を取得し、ゴミ箱の既読メールを受信箱へ戻す道具を用意した、ということです。
作るにあたって、安全だけは念入りにしました。
完全削除のような取り返しのつかない操作は、はじめから一切組み込まない。実行の前には必ず対象の件数を表示して、確認を求める。「数えるだけで何もしない」お試しモードも用意する。
今回の事故が、まさに「確認なしの破壊的操作」で起きたのですから、その反省を道具の設計に折り込んだわけです。
認証情報の取得手順や、プログラムの具体的な中身は、扱いに注意の要る部分も含むため、この記事には書きません。必要な方のために、要点は別の技術メモにまとめておきます。
こうして、十数年ぶんの、僕が読んで保管してきたメールは、もとの場所へ帰ってきました。
7. 教訓
最後に、この一日が残してくれた教訓を書いておきます。いちばん大事な一点から。
日常的に使わない道具で、本体に波及する一括操作をしない。
これが今回の最大の教訓です。慣れていない道具は、操作の結果を正しく予測できません。とりわけ全選択と削除のような破壊的操作は、慣れた道具でだけ、慎重に行うべきでした。
「表示画面」と「データの本体」を区別する。
同期型のサービスでは、画面に見えているものが中身のすべてとは限りません。コントロール+Aが「表示分」を選ぶのか「全件」を選ぶのかは、ソフトによって違います。同じ操作でも結果はまるで変わります。
二つの窓は同じ部屋を映している。
IMAP でつないだメールは、どの画面で消しても本体が消えます。控えを消しているつもりが、本体を削っていることがあります。
破壊的操作には確認を。
これは設計の問題でもあります。取り返しのつかない操作の前に確認を挟むのは、使い手を守る基本的な作法だと、僕は考えます。自分で道具を作るときも、この一点だけは外さないようにしたいと思います。
ゴミ箱には30日の猶予がある。
消えたと思っても、すぐには消えません。あわてず、しかし猶予のあるうちに動くことです。
やれやれの一日でした。