Gmailラベルクリーンアップ
大量のGmailバックログを、ユーザー自身の既存ラベルで整理し、新しいメールが自動的にラベル付けされるようにします。
ほとんどのアシスタントに組み込まれているGmailコネクタは、1スレッドにつき1回のAPI呼び出しで、フィルターAPIがありません。これでは数千件のメッセージには遅すぎ、問題が再発するのを防げません。このスキルは代わりに完全なGmail MCPサーバーを使用し、実際のサーバーサイドフィルターと50メッセージのバッチ処理を提供します。
初回実行前
- MCPサーバーをインストールします。
install/INSTALL.mdを参照してください。Google Cloud OAuthデスクトップクライアントと1回のブラウザサインインが必要です。約10分かかります。 - ルールファイルを作成します。
references/rules-TEMPLATE.mdをプライベートファイルにコピーし（テンプレートではmy-rules.mdが推奨されており、.gitignoreで除外済み）、アカウントの過去の履歴から内容を記入します。ルールを決して捏造しないでください。 「ルールの学習」を参照してください。
これを機能させる唯一のルール
ルールはユーザー自身の過去のラベル付けから学習され、決して捏造されません。
送信者または件名ごとに、その送信者が過去にどのラベルに分類していたかを確認し、それをコピーします。送信者が履歴にまったく現れない場合にのみ判断が許され、その場合は「推測」セクションに記録され、後で修正できます。間違ったラベルは修正が簡単ですが、間違ったラベルが300件のメッセージに静かに適用されるのは問題です。
もう一つのルール（苦い経験から学びました）：送信者だけでなく、内容も重要です。 送信者は一つの軸に過ぎません。ウェルビーイング出版社からのお金に関するニュースレターには、お金のラベルも付けるべきです。スレッドには複数のラベルを付けることができます。
ルールの学習
人に聞くのではなく、アカウントに問い合わせてください。各ラベルについて、その中に何が既に入っているかを読み取ります：
search_emails: label:"<ラベル名>"
30～50件の結果を読み取り、送信者を書き留めます。そのリストがルールです。すべてのラベルに対してこれを繰り返します。次に list_email_labels でラベルIDを取得します。これが batch_modify_emails が実際に使用するものです。
これを1回実行し、ルールファイルに書き込み、パスを実行するたびに追加していきます。各パスで、前回見つからなかった送信者が発見されます。
パスの実行
パスとは、境界が定められ、ログが取られ、元に戻せる作業の塊です。200～300メッセージを目標にしてください。1回の実行ですべてを処理しようとしないでください。
1. フィルターが存在することを確認します。
list_filters
ルールファイルのフィルターが欠けている場合は、まず create_filter で作成します。ラベルグループごとに1つずつ、from: 条件を使用します。フィルターは問題が再発するのを防ぐ部分です。
2. ラベルなしのメールを見つけます。
まず受信トレイから：
search_emails: has:nouserlabels in:inbox
受信トレイが意図的にラベルなしのままのメッセージだけになったら、残りの作業はアーカイブです。日付順にページングし、古い境界を毎回移動させます：
search_emails: has:nouserlabels -in:inbox -in:sent -in:draft -in:trash -in:spam -in:chats before:YYYY/MM/DD
1ページあたり50～60件取得します。before: を処理した最も古い結果の日付に設定すると、次の呼び出しは中断した場所から続行します。これはページングトークンよりも信頼性が高く、中断にも耐えられます。
3. ラベルごとにグループ化し、バッチ処理します。
ページ内のメッセージをラベルごとに1つのメッセージIDリストに並べ替え、ラベルごとに1回 batch_modify_emails を addLabelIds とともに呼び出します。メッセージごとに1回の呼び出しは決して行わないでください。
バッチが Too many concurrent requests for user を返した場合は、失敗したIDのみを再試行します。この呼び出しは正確にどのIDが失敗したかを報告します。
4. ログを取ります。 日付付きのエントリを元に戻すログに追加します。以下の「元に戻すログ」を参照してください。
絶対に触らないもの
- ワンタイムログインコード、マジックリンク、パスワードリセット、セキュリティアラート。 これらはラベルなしのままにし、決してゴミ箱に入れません。ログインコードをすぐに見つける必要がある場合、ラベルは役に立たず、ゴミ箱ルールは積極的に害を及ぼします。
- ユーザー自身の「ラベル付けしない」リストにあるもの。 ユーザーがラベルなしのままにしたい出版物や送信者があり、それを伝えてきます。その言葉を聞いた瞬間にルールファイルに書き込みます。
- 家族や個人のメール。ただし、ユーザー自身がその送信者に既にラベルを付けている場合を除きます。
ゴミ箱への移動
ユーザーが明示的に承認したもののみを、件名一致によってゴミ箱に移動します。安全なデフォルトセットは、利用規約とプライバシーポリシーの更新通知です：
subject:("terms of service" OR "terms and conditions" OR "terms of use"
OR "privacy policy" OR "user agreement")
negatedQuery: subject:(code OR verification OR verify OR "security alert" OR password)
否定クエリは必須です。これがないと、「アカウント確認 - 更新された利用規約」というメールがゴミ箱に入ってしまいます。
Gmailのゴミ箱は30日間復元可能です。このスキルでデータが削除されることは決してありません。
元に戻すログ
各パスは1つの日付付きエントリを追加します。これは作業を元に戻し可能かつレビュー可能にする記録です：
- 日付とパス番号。
- フィルターが存在したかどうか、および作成されたフィルター。
- ラベル付けされた件数、およびラベルごとの件数。
- 判断の呼び出し（名前付き）。どの送信者に前例がなかったか、何が決定されたか、その理由。これは後で修正される部分です。
- ラベルなしのまま、触れられなかったことが確認されたもの。
examples/undo-log-EXAMPLE.mdを参照してください。パスが退屈なときでも、特にそのときに書き込んでください。
フィルターは古いメールには適用されません
これは誰もがつまずくので、ユーザーに声に出して伝えてください：
Gmailフィルターは、フィルター作成後に届いたメールにのみ適用されます。 過去には決して遡及しません。したがって、この作業の2つの部分は本当に別々です。フィルターは自動的に未来を処理し、アーカイブのバックログは上記の通り、パスごとに手作業で処理する必要があります。
つまり、数回のパスで実際の大量送信者が判明したら、戻ってその送信者用のフィルターも追加してください。そうしないと、それらの送信者はラベルなしのまま届き続け、バックログが背後で再構築されます。
パスの取り消し
パスの元に戻すログエントリを読み取り、同じメッセージIDに対して removeLabelIds を指定して batch_modify_emails を実行します。ゴミ箱に移動したものについては、untrash が30日間有効です。これが、ログが「完了」だけでなく件数と理由を記録する理由です。