はじめに

Gmailの受信トレイに、4,843スレッドが溜まっていました。そのうち未読が4,438です。開いていないメールが9割を超えていて、その中に返事の要るメールが混ざっています。

フィルタを作れば減る、ということは分かっていました。分からなかったのは、何本作れば終わるのかと、どの送信者から手を付けるのかです。画面で1通ずつ見ながら作っていると、30本作っても、残りがどれだけあるのか見えません。

2026年7月6日の夜に、順番を変えてやり直しました。先に送信者を数え、フィルタの計画を1枚の表にして、まとめて作り、古いメールを受信トレイから退かし、翌朝からは新着を毎朝仕分ける。20時03分に数え始めて、22時00分に数え直したとき、受信トレイは2,019スレッドになっていました。

フィルタの計画は134本です。そのうち、実行ログで作成を確かめられるのは133本でした。残りの1本は時間切れで失敗していて、作り直した記録がありません。題の「133本」は、確かめられるほうの数です。

この資料は、その手順と、途中で踏んだつまずき4件の記録です。つまずきは、起きたこと、原因、直し方、確かめ方の順に書きます。うまくいかなかった点と、記録が合わない点も、そのまま載せます。

範囲と時点

作業したのは2026年7月6日です。毎朝の仕分けは、その夜から10月9日までの記録を使いました。数字は、当時のスクリプトの出力、実行ログ、作業記録に残っているものです。2026年10月10日に、手元のファイルをスクリプトで数え直しました。数え直しに使ったのはPCの中のファイルだけで、Gmailの設定画面やAPIでは確かめ直していません。確かめていない点は、その場所に書きます。
環境はWindowsのPCです（2026年10月10日の時点でWindows 11 Home）。Gmailの操作には、Google Workspace用のコマンドラインの道具 gogcli（コマンド名は gog）を使いました。集計、計画、適用、退避はPythonのスクリプトで、スクリプトの中ではAIを呼んでいません。毎朝の仕分けだけ、Claude Code を画面なしで動かしています。
環境や時期が違えば、結果も変わります。Gmailの画面、API、利用枠の決まりは変わります。gogcliの引数も版で変わることがあります。ここに書いたコマンドが、そのまま通る保証はありません。
受信トレイから外す操作（アーカイブ）や削除は、まとめて行うと、取り消せないことがあります。 この資料の手順では、メールを1通も削除していません。既読にもしていません。やったのは、ラベルを付けることと、受信トレイから外すことだけです。それでも、フィルタを一括で作る前、古いメールをまとめて動かす前には、対象の一覧をご自身の目で確かめてください。
同じ手順で同じ数だけ減ることは、保証できません。届くメールの種類と量は人によって違います。
送信者の名前とアドレスは載せていません。「通販サイトの販促メール」のように種類で書きます。コードの中のアドレス、アカウント、フォルダの場所、ラベルのIDは、置き換えてあります。置き換えた所はその都度書きます。
スクリプト一式の配布は含みません。載せたコードは、私のPCにあるファイルからの抜粋です。

目次

無料部分 - 最初にやったこと　送信者を数える

有料部分 - フィルタの設計（残す・ラベルを付けて受信トレイを飛ばす・削除候補に回す） - 分類の表の持ち方 - 一括適用の手順と、1本だけ失敗した記録 - つまずき1　全件取得の指定で、利用枠を使い切る - つまずき2　認証が1週間ごとに切れる - つまずき3　PowerShellで、カンマ区切りの引数が割れる - 古いメールの退避と、合わない数字 - 毎朝の仕分けの回し方（96日分の記録） - AIに送られるもの - つまずき4　止まっているのに、成功に見える - 補足　日本語の文字化け - まだやっていないこと - 点検リスト

最初にやったこと　送信者を数える

何をしたか

フィルタを作る前に、受信トレイにあるスレッドを、送信者ごとに数えました。Gmailには何も書き込まない、読むだけの処理です。

検索の条件は in:inbox だけです。500件ずつ取ってきて、次のページの目印が返らなくなるまで繰り返します。返ってくる1件ごとの情報のうち、使ったのは、送信者、件名、日付、ラベルの4つです。

送信者ごとに、表示名のほか、次の6つを持たせました。

スレッドの数
そのうち未読の数（ラベルに UNREAD が付いているもの）
そのうち30日より古いものの数
いちばん古い日付と、いちばん新しい日付
Gmailが付けたカテゴリ（プロモーション、新着、ソーシャルなど。いちばん多いもの）
件名の見本を1つ

出力は2つです。人が読むための順位表（Markdown）と、次の工程が読むためのJSONです。

出た数字

2026年7月6日20時03分の集計です。

受信トレイのスレッド: 4,843
うち未読: 4,438
うち30日より古いもの: 3,388
送信者の数: 356

順位表を上から見ると、偏りがはっきりしていました。当時の作業記録で上位に挙げているのは、あるAIサービスから届く定期レポートの324スレッド、出版社の販促メールの213、自治体の防犯メールの165、記事投稿サービスの通知の159です。

あとで作った計画書から数えると、計画に載せた送信者のうち、100スレッド以上あるものは11件で、合わせて1,632スレッドでした。受信トレイの3分の1（33.7%）が、11件の送信者で埋まっていたことになります。計画に載せなかった送信者の中に100以上のものがいたかどうかは、1回目の集計のファイルを2回目で上書きしたので、もう数えられません。

逆の端も見えました。片づけたあとの2回目の集計では、送信者346件のうち、110件は1スレッドしかありません。1通しか来ていない相手にフィルタを作っても、減るのは1通です。

これで、手を付ける順番が決まりました。上から順に見ていき、数の少ない送信者はフィルタの対象にしない。残った分は、毎朝の仕分けに任せます。

確かめ方

集計のスクリプトは、最後に1行、合計を出します。

threads=2019 unread=1746 old=570 senders=346

これは2回目（22時00分）の出力の形です。スレッドの総数が、Gmailの画面で受信トレイを開いたときの数と大きく違わないかを見ます。

もう一つ、順位表を上から30行ほど、自分の目で読みます。数字の上では「多い送信者」でも、中身は残したいメールだった、という相手が混ざっているからです。私の場合、仕事の相談の通知がそうでした（片づけたあとの2回目の集計でも、26スレッドあります）。これは次の工程で、フィルタを作らない側に入れています。

ここから先は有料です。設計の内訳、分類の表、一括適用、つまずき4件、古いメールの退避、毎朝の仕分けと96日分の記録、AIに送られるもの、点検リストを載せています。