email-whiz

Email Whiz

MCP 経由の Gmail 受信トレイ管理。並列処理を優先し、大容量の受信トレイに最適化されています。

---

標準用語

用語	定義
5バケット	DO / DELEGATE / DEFER / REFERENCE / NOISE — 5つのトリアージ用バケット（以前は「4D+N」）
受信トレイゼロ	受信トレイに、今日対応が必要な項目だけがある状態
ファストレーン	メール本文を読まずに、送信者と件名だけで分類する方法
セキュリティゲート	アーカイブ前に NOISE の件名をキーワード検索する処理（2FA やパスワードリセットを検出）
セッションキャッシュ	`~/.{gemini
ティア	受信トレイのサイズ区分：Small（50件未満） / Medium（50～500件） / Large（500～5k件） / Massive（5k件以上）
quick	軽量モードで Phase 0 をスキップする修飾プレフィックス
コンボ	発見済みの状態を共有して2つのモードを連続実行：<mode> + <mode>
メガウェーブ	10～15件の独立したツール呼び出しをまとめた単一のメッセージ
ベースライン	直近30日間の受信トレイ件数の平均値。破綻の判定はこの値を基準にします
自動ルール	行動パターンの分析から作成される Gmail フィルター
VIP	継続的に返信を受け取り、優先度の高い対応を受ける送信者
エンゲージメント	送信者への返信率：送信した返信数 / 受信したメール数
信頼度	HIGH は80%超 / MEDIUM は50～80% / LOW は50%未満 — 自動ルールの動作を決定します
メモリ	`~/.{gemini
修正	自動分類に対するユーザーの異議。メモリの上書き情報として保存されます
陳腐化	基準期間を超えて確認または使用されていないメモリエントリ（VIP：90日、上書き情報：60日）

---

ディスパッチ

$ARGUMENTS	動作
triage	ファストレーンと5バケットで受信トレイを分類し、カテゴリごとにまとめて処理します
inbox-zero	毎日／毎週のルーティン、進捗追跡、ベースラインに基づく破綻の検出
filters	信頼度スコア付きのパターン検出フィルター候補
auto-rules	行動分析 → テンプレートから Gmail フィルターを自動作成します
analytics	メール量の傾向、返信時間、送信者の頻度、時間帯のパターン
newsletters	購読状況の監査と購読解除プラン
labels	分類体系の分析、統合／名前変更／削除の提案
search <goal>	自然言語 → Gmail 検索クエリ
senders	VIP と不要な送信者の特定
digest	最近の重要なメールの要約
cleanup	アーカイブ候補、重複の検出、一括アーカイブ
audit	スコアとアクションプランを含む、受信トレイの総合ヘルスレポート
quick search または quick digest	Phase 0 をスキップし、モードを直接実行します。quick に対応するのは search と digest のみです
<mode> + <mode>	発見済みの状態を共有してモードを連続実行します（triage + filters）
(空欄)	自動スキャン：Phase 0 とアカウント分析を実行し、優先順位付きのアクションプランを提示します

分類ゲート： $ARGUMENTS が複数のモードに該当する可能性がある場合は、先にユーザーに希望するモードを確認します。

---

ハイブリッドモードプロトコル

読み取り操作 — すぐに実行します： gmail_search_emails、gmail_read_email、gmail_list_email_labels、gmail_list_filters、gmail_get_filter

書き込み操作 — 実行前に確認します： 単一：gmail_modify_email、gmail_delete_email、gmail_create_label 一括：gmail_batch_modify_emails、gmail_batch_delete_emails ラベル：gmail_update_label、gmail_delete_label、gmail_get_or_create_label フィルター：gmail_create_filter、gmail_create_filter_from_template、gmail_delete_filter

メールの削除は、ユーザーが明示的に依頼しない限り禁止です。 独自の判断でgmail_delete_emailやgmail_batch_delete_emailsを呼び出してはいけません。常にアーカイブしてください。削除ツールを使えるのは、ユーザーが直接「削除」と指示した場合のみです。その場合も、まず破壊的操作の警告テンプレート（「DELETE」と入力する確認）を使用してください。

確認形式： templates.mdを参照してください。書き込み操作の前に、必ず対象範囲、件数、取り消し可能性を表示してください。

---

並列化のルール

1. 独立したツール呼び出しは1つのメッセージにまとめます。 独立した呼び出しを順次行うのはバグです。
2. Phase 0はモードの最初のクエリと統合します — 統合できる場合に、2回に分けて順次実行してはいけません。
3. IDセットが重複しない一括操作は並列で実行します。 NOISE + REFERENCE + DEFERは、1つのメッセージで3回呼び出します。
4. Analytics／Audit：大規模な一括実行 — 10～15件の検索クエリを1つのメッセージで実行します。
5. gmail_read_email：1メッセージにつき5～8件を一括処理します（メール全文は大容量です）。
6. フィルターの作成： 競合チェックに合格した後、並列で実行します。
7. コンボモードの境界： 順次実行します（データ依存関係があるため）。ただし、モード2ではPhase 0をスキップします。
8. 1メッセージあたりの呼び出しは最大15～20件です。 それを超えると、429が1件発生しただけでバンドル全体に影響します。
9. 429が発生した場合： 完了済みの結果を保持し、2秒の間隔を空けて順次実行に切り替えます。60秒以内に429が3回発生した場合は、60秒間停止します。

詳細：efficiency-guide.md § 並列呼び出しマップ。

---

Phase -1：メモリの読み込み（quickプレフィックスがある場合はスキップ）

検出を行う前に、ユーザーの長期メモリを読み込みます。セッションごとに1回実行します。

!uv run python scripts/memory.py load --mode <current_mode>

Phase 0のキャッシュ確認と同じメッセージにまとめます（どちらもローカルファイルの読み込みで、API呼び出しはゼロです）：

!uv run python scripts/memory.py load --mode triage
!uv run python scripts/inbox_snapshot.py cache load

メモリが存在する場合は、セッションに反映します：

• VIP送信者 → DO分類を優先的に実施（Pass 1）
• ノイズ送信者 → NOISE分類を優先的に実施（Pass 1）
• 修正内容 → 最優先：競合する優先ルールを上書きします
• トリアージの上書き設定 → 汎用の判断ツリーより先に適用します
• フィルター履歴 → 過去に却下されたフィルターの提案をスキップします
• ラベル設定 → ラベル作成時に優先する命名を使用します
• 受信トレイのパターン → 分析／監査での想定を調整します

メモリが存在する場合は、セッションごとに1回!uv run python scripts/memory.py pruneを実行します。整理された項目数が0より大きい場合のみ、整理された項目を報告します。

---

Phase 0：検出（quickプレフィックスがある場合はスキップ）

前提条件： quickモードでない場合は、まずPhase -1（メモリの読み込み）を実行します。

0a：セッションキャッシュの確認

!uv run python scripts/inbox_snapshot.py cache load 有効なキャッシュ（1時間未満）がある場合は、キャッシュされたラベル、フィルター、tierを使用します。モードに進みます。

0b：検出とモードの並列統合（キャッシュミス）

Phase 0の呼び出しとモードの最初のクエリを、1つのメッセージで実行します：

コア検出（常に実行）：

1. gmail_list_email_labels → ラベル名／IDの対応表 + INBOXのmessagesTotal／messagesUnread
2. gmail_list_filters → 既存のフィルター条件
3. gmail_search_emails → "in:inbox is:unread"（maxResults: 10）→ サンプル

モード固有の追加項目（同じメッセージ内）：

• Triage：+ gmail_search_emails "is:unread"（maxResults: tierごと）
• Inbox Zero：+ "is:unread newer_than:1d" + "label:_deferred"
• Analytics：+ 週ごとのメール量クエリ4件（大規模な一括実行）
• Audit：+ ニュースレター件数 + 送信済み件数 + 期限超過件数（大規模な一括実行）
• Cleanup：+ 古い項目の検出クエリ4件

0c: ティアの評価

INBOX ラベルの messagesTotal を使用します（resultSizeEstimate は信頼できないため、使用しないでください）。

Inbox Size	Tier	maxResults	Strategy
<50	Small	50	すべて処理
50-500	Medium	100	最近のメールと未読メールをサンプリング
500-5000	Large	200	重要度優先、日付範囲で分割
5000+	Massive	200	日付範囲で並列クエリ、ベースラインの破綻

maxResults が 100-200 の理由： MCP サーバーは N+1 フェッチパターンを使用します（各結果で個別の API 呼び出しが発生します）。maxResults=500 の場合、約 501 回の API 呼び出し、約 2505 クォータ単位になります。200 の場合は約 1005 単位です。

Massive ティア： 日付範囲で分割し（30 日単位）、すべての範囲を並列でクエリします。一般スキャンと併せて、必ず is:important is:unread もクエリします。MCP サーバーでは pageToken を使用できません。日付範囲による分割が唯一のページネーション方法です。

0d: セッションキャッシュの書き込み

!uv run python scripts/inbox_snapshot.py cache save --labels '...' --filters '...' --inbox-count N --unread-count M --tier TIER 書き込み操作（フィルター／ラベルの作成、一括変更）の後は、必ずキャッシュを無効化してください。

検出したラベル名は一貫して使用してください。既存の分類体系と競合する名前を作らないでください。

---

自動スキャン（引数なしでの呼び出し）

引数なしで呼び出された場合は、メニューを表示する代わりに、アカウントをインテリジェントにスキャンします。

ステップ 1：メガウェーブによる検出（1 メッセージ）

フェーズ 0 のコア検出と 6 つの分析クエリを、単一のメッセージに統合します（約 10 回の呼び出し）。

• フェーズ 0 のコア：gmail_list_email_labels + gmail_list_filters + gmail_search_emails "in:inbox is:unread"（maxResults: 10）
• 受信トレイの対象範囲：gmail_search_emails "in:inbox has:nouserlabels newer_than:7d"（maxResults: 10）
• ニュースレター：gmail_search_emails "in:inbox (list:* OR subject:newsletter)"（maxResults: 50）
• 保留中の古いメール：gmail_search_emails "label:_deferred older_than:7d"（maxResults: 10）
• バックログ：gmail_search_emails "in:inbox is:unread older_than:7d"（maxResults: 10）
• クリーンアップ候補：gmail_search_emails "in:inbox (subject:receipt OR subject:confirmation) older_than:30d"（maxResults: 10）
• !uv run python scripts/inbox_snapshot.py trend --days 7
• !uv run python scripts/inbox_snapshot.py baseline --days 30

ステップ 2：分析とスコアリング

結果から、ティア（INBOX の messagesTotal に基づく）、破綻のレベル（ベースラインとの比較）、トリアージの必要性（未読バックログ）、フィルターの適用機会（ノイズの多い送信者クラスター）、ニュースレターの負担、クリーンアップの可能性、保留メールの山の状態を算出します。

ステップ 3：アクションプランの提示

Auto-Scan Report テンプレート（templates.md § Auto-Scan Report）を使用します。推定効果を添えて、優先度順に 3～5 件の推奨事項を提示します。それぞれの推奨事項は、いずれかのモードに対応します。

番号、モード名、all（上位 3 件を連続して実行し、フェーズ 0 の状態を引き継ぐ）、または menu（モード一覧全体を表示）で返信するよう案内します。

---

オーケストレーションパターン

このスキルは context: fork で実行されます。内部では次のパターンを適用してください。

分解ゲート（各モードの実行前）

1. そのモードで必要なすべてのツール呼び出しを列挙します
2. 独立（異なるクエリ）か依存（先行する結果が必要）かに分類します
3. 独立した呼び出しはすべて、可能な限り少ないメッセージ数にまとめます
4. 独立した呼び出しを順番に実行しないでください

モードごとのウェーブパターン

Mode	Wave 1	Wave 2	Wave 3	Total
Auto-Scan	フェーズ 0 + 6 件の分析（約 10）	スコアリング（ツール 0 件）	—	約 10
Triage	フェーズ 0 + ファストレーン（約 5）	3 回の batch_modify	5～8 回の read_email	約 16
Analytics	フェーズ 0 + メガウェーブ（約 15）	エンティティごとのバッチ（約 12）	—	約 27
Audit	フェーズ 0 + メガウェーブ（約 14）	エンティティごとのバッチ（約 20）	—	約 34
Cleanup	フェーズ 0 + 古いメールのクエリ 4 件（約 7）	batch_modify（約 3）	—	約 10
Filters	フェーズ 0 + 送信者／件名（約 6）	create_filter（約 5）	—	約 11
Inbox Zero	フェーズ 0 + 未読／保留（約 5）	一括操作（約 3）	—	約 8
Combo	フェーズ 0 + モード 1	モード 1 の操作	更新 + モード 2	変動

---

モード：トリアージ

3 パスで分類します。詳細：triage-framework.md § Fast-Lane、efficiency-guide.md。

パス 1：高速レーン（本文を一切読まない）

検索結果の送信者＋件名＋スニペットのみで分類します：

• メモリの訂正 → 競合するルールを上書きします（最優先）
• メモリの VIP 送信者 → 対応します（メモリの確信度を使用）
• メモリのノイズ送信者 → ノイズ（メモリの確信度を使用）
• noreply@*、notifications@*、calendar-notification@* → ノイズ
• 既知の VIP 送信者（セッションキャッシュから） → 対応します
• 件名が [FYI]／[INFO]／ニュースレター／領収書／確認 → 参照
• 件名が [ACTION]／[URGENT]／期限 → 対応します
• 該当なし → 未判定

パス 1.5：セキュリティゲート（ノイズをアーカイブする前に必須）

すべてのノイズの件名／スニペットをセキュリティキーワードでスキャンします：password reset、verify your、sign-in、unusual activity、2FA、account locked、verification code、one-time password、security alert、new device、suspicious login、recovery phone、two-step verification、confirm your identity、new sign-in method。いずれかに一致した場合 → ノイズからレビューに移します。また、noreply@ のメールで newer_than:7d に該当するものはすべてレビューに移します（ログイン通知には有効期限がなく、コードには期限がありますが、それでも確認できるようにします）。

パス 2：一括操作（1 つのメッセージですべて実行）

事前条件： フェーズ 0 でまだ解決されていない場合は、gmail_get_or_create_label を呼び出して _reference と _deferred を作成します。

gmail_batch_modify_emails を 3 回同時に呼び出します（ID セットは重複しないため、並列実行できます）：

• ノイズ ID → INBOX を削除
• 参照 ID → _reference を追加し、INBOX を削除
• 保留 ID → _deferred を追加し、INBOX を削除

パス 3：本文の確認（未判定＋レビューのみ）

1 メッセージあたり 5～8 件の gmail_read_email を一括で実行します。完全な 5 分類を適用します。パス 2 と同じ並列パターンで結果を一括処理します。高速レーンのトリアージ概要（自動分類率を表示）とともに報告します。フィルター候補として、繰り返し現れるノイズ送信者のパターンを提示します。

---

モード：受信トレイゼロ

体系化された習慣化システムです。詳細：inbox-zero-system.md。

毎日（5 分）： フェーズ 0 ＋ is:unread newer_than:1d ＋ label:_deferred を 1 つのメッセージにまとめます。簡易トリアージ（5 分類）を行います。ノイズ＋参照を一括アーカイブします。報告内容：受信トレイの件数（処理前 → 処理後）。進捗ファイルを更新します。

毎週（15 分）： 1 つのメッセージで 3 つのクエリを実行します：保留の確認＋フィルターの有効性＋ニュースレターの確認。対応、再度保留、またはアーカイブします。weekly_reviews を更新します。

破綻の検出： 絶対値ではなく、過去 30 日間の基準値と比較します。黄色：基準値より 20～50％増加。オレンジ：基準値より 50～100％増加（積極的なトリアージ＋フィルター作成）。赤：基準値より 100％超の増加（完全な破綻対応プロトコル）。加速のトリガー：週ごとの増加率が 2 週間以上にわたり 20％を超える。新規ユーザーは、7 回以上のスナップショットで基準値が確立されるまで、デフォルトで 500 件を使用します。復旧プロトコルについては inbox-zero-system.md を参照してください。

---

モード：フィルター

パターン検出によるフィルターの提案です。詳細：filter-patterns.md。

送信者のクラスタリング＋件名パターン＋gmail_list_filters を、すべて 1 つのメッセージで実行します。候補をスコアリングします：高（件数 ≥20、エンゲージメント <5％）→ 作成を提案。中（≥10、<15％）→ 提案。低 → 表示のみ。作成前に競合を確認します。承認後、複数の gmail_create_filter 呼び出しを 1 つのメッセージで実行します。大規模な場合：90 日分を 30 日ずつの 3 チャンクに分割し、並列でクエリします。

---

モード：自動ルール

詳細な行動分析に基づいて、フィルターを自動作成します。詳細：filter-patterns.md § 自動ルールの検出。

送信者の分析＋件名のマイニング＋フィルターの取得を 1 つのメッセージで実行します。大規模な場合：90 日分を日付範囲ごとに 30 日ずつの 3 チャンクに分割し、すべてを並列で実行します。確信度に基づいてスコアリングします。自動ルールのレポートを提示します。高：確認を得て gmail_create_filter_from_template を実行します。中：個別に確認します。作成時は、複数のフィルターを 1 つのメッセージで作成します。2 週間後に学習ループをスケジュールします。

---

モード：Analytics

mega-wave によるメールコミュニケーション指標。詳細：analytics-guide.md。

すべてのクエリを1つのメッセージで実行します：週ごとの件数4件＋送信数＋受信トレイ到達率＋返信率＋期限超過＋送信者の頻度＋ラベル分布（約12回の呼び出し、メッセージ数を約65％削減）。件数の傾向を「増加」「安定」「減少」に分類します。受信トレイ到達率を算出します（良好：30％未満）。件数上位20人の送信者とエンゲージメントマトリックスを特定します。分析レポート全体を提示します。

---

モード：Newsletters

サブスクリプションを監査します。list:* と subject:newsletter を1つのメッセージで実行します。サブスクリプションごとに頻度と開封率を推定します。「購読解除」「維持」「フィルタリング」に分類します。購読解除リンクを提示します。承認後、フィルタを作成するか、購読解除URLを提示します。詳細：workflows.md § 購読解除戦略。

---

モード：Labels

ラベル分類体系を分析します。gmail_list_email_labels はラベルごとの messagesTotal／messagesUnread を返します。過去30日のアクティビティを分類するには、ラベルごとの検索クエリを10～15件ずつまとめて実行します。重複／類義語、古いラベル（90日以上メッセージがないもの）、階層化が必要なフラットな構造を特定します。「統合」「名前変更」「削除」「再構成」を提案します。統合する場合は、gmail_batch_modify_emails で移行してから gmail_delete_label を実行します。詳細：workflows.md § ラベル階層。

---

モード：Search

クイック対応（Phase 0 なし）。自然言語を Gmail 検索クエリに変換します。意図（誰／何／いつ／ステータス）を解析し、演算子に対応付け、除外条件を追加して、クエリと説明、予想される一致件数を表示します。実行するかどうかを確認します。詳細：filter-patterns.md § Gmail 検索演算子。

---

モード：Senders

VIP とノイズを特定します。サンプル検索と送信者ごとの返信率クエリを1つのメッセージで実行します（送信者の上位件数が12を超える場合は、呼び出し上限を超えないよう、返信率クエリを2つのメッセージに分割します）。VIP：返信率が50％超、または一貫してスター付き。ノイズ：件数が10超、エンゲージメントが0％。送信者レポートを提示します。承認後、VIP フィルタ（重要マークを付ける）またはノイズフィルタを作成します。詳細：triage-framework.md § 送信者のショートカット、workflows.md § VIP 管理。

---

モード：Digest

クイック対応（Phase 0 なし）。is:important newer_than:3d（または is:starred OR is:unread is:important）を検索します。メールごとに送信者、件名、1行の要約を抽出します。「返信」「参考情報」「読む」に分類します。ダイジェストレポートを提示します。次の操作を提案します："open N" | "archive fyi"。詳細：templates.md § ダイジェスト。

---

モード：Cleanup

アーカイブ候補を特定します。古いメールを検出する4つのクエリすべてを1つのメッセージで実行します：領収書／確認メール older_than:30d ＋ 古いニュースレター older_than:30d ＋ 期限切れの保留メール older_than:14d ＋ ラベルなしで既読のメール older_than:60d。すべての結果を、複数の gmail_batch_modify_emails 呼び出しを並行して実行して一括アーカイブします。アーカイブのみを行い、削除はしません。詳細：workflows.md § 一括操作。

---

モード：Audit

mega-wave で受信トレイ全体の健全性を確認します。基本クエリ11件を1つのメッセージで実行します（ラベルごと、送信者ごとのクエリは第2波で実行）：受信トレイの件数、未読率、フィルタ数、受信トレイ到達率、返信率、期限超過、ニュースレターの件数、保留メールの蓄積、送信数、ラベルの健全性、送信者上位20人（メッセージ数を約70％削減）。受信トレイ到達率、フィルタの適用範囲、ラベルの健全性に基づいて0～100点で評価します。すぐに実行できる改善策を上位3件特定します。アクションプランを作成します。詳細：analytics-guide.md、templates.md § 全体監査。

---

対応範囲

対象： Gmail のトリアージ、受信トレイゼロ、フィルタ、自動ルール、分析、ニュースレター、ラベル、検索、送信者、ダイジェスト、クリーンアップ、監査。 対象外： カレンダー、Google Drive、Gmail 以外、リアルタイム監視、CRM。

---

リファレンスファイル一覧

ファイル	内容	読み込むタイミング
references/efficiency-guide.md	キャッシュ、並列呼び出し、ティア、MCP の制約、ファストレーン、ページネーション	すべてのモード
references/triage-framework.md	5 分類の意思決定ツリー、ファストレーンのルール、セキュリティゲート、バッチ処理	トリアージ、受信トレイゼロ
references/filter-patterns.md	Gmail の演算子、フィルターテンプレート、自動ルールのアルゴリズム、学習ループ	フィルター、自動ルール、検索
references/workflows.md	大量整理、VIP、バッチ操作、ラベル階層、購読解除、コンボモード	クリーンアップ、ラベル、送信者、ニュースレター
references/templates.md	すべての確認、レポート、実行結果のテンプレート	すべてのモード
references/inbox-zero-system.md	日次／週次のルーティン、進捗スキーマ、大量整理のベースライン	受信トレイゼロ
references/analytics-guide.md	メール量、返信時間、送信者の頻度、タイミングの方法論	分析、監査
references/tool-reference.md	Gmail MCP の 18 個すべてのツールのシグネチャ、パラメーター、MCP の制約	ツールの選択時

スクリプト：

スクリプト	用途	実行するタイミング
scripts/inbox_snapshot.py save --inbox-count N	受信トレイ件数のスナップショットを保存	受信トレイゼロの確認後
scripts/inbox_snapshot.py trend --days 7	受信トレイの傾向を算出	分析モード中
scripts/inbox_snapshot.py baseline --days 30	大量整理用の移動ベースラインを算出	受信トレイゼロ中
scripts/inbox_snapshot.py cache load	セッションキャッシュ（TTL 1 時間）を読み込む	フェーズ 0 のステップ 0a
scripts/inbox_snapshot.py cache save --labels --filters --inbox-count --unread-count --tier	セッションキャッシュを書き込む	フェーズ 0 のステップ 0d
scripts/inbox_snapshot.py cache clear	セッションキャッシュを無効化	書き込み操作後
scripts/memory.py load --mode MODE	モードで絞り込んだユーザーメモリーを読み込む	フェーズ -1
scripts/memory.py save-sender	VIP またはノイズ送信者を保存	トリアージ／送信者処理後
scripts/memory.py save-correction	ユーザーによる分類の上書きを記録	ユーザーが修正したとき
scripts/memory.py prune	古くなったメモリー項目を削除	セッションごとに 1 回
scripts/memory.py stats	メモリーの概要件数	診断

---

重要なルール

1. どのワークフローを実行する場合も、まず Phase 0 の調査を実行してください（quick モードを除く）。ラベルやフィルターの状態を決めつけないでください
2. 書き込み操作はすべて確認してください。呼び出す前に、対象範囲、件数、取り消し可能かどうかを示してください
3. 類似した操作はまとめて実行してください。gmail_batch_modify_emails を使える場合、gmail_modify_email をループで呼び出してはいけません
4. 既存の分類体系を維持してください。改善案を提示し、黙って名前を変更してはいけません
5. フィルターを作成する前に競合を確認してください。まず gmail_list_filters を呼び出してください
6. フィルターやルールの提案には、すべて信頼度スコアを付けてください
7. 一括操作には必ずロールバック方法を案内してください
8. MCP の失敗には適切に対処してください。efficiency-guide.md § Error Recovery を参照してください
9. 配信停止リンクを提示し、ニュースレターを整理できるようにしてください
10. すぐに実行できる成果を優先してください。すべてのレポートで、影響が大きく手間の少ないものを最初に提示してください
11. 各ルーチンの実行後に、受信トレイゼロの進捗を更新してください
12. ユーザーが明示的に削除を依頼しない限り、メールを絶対に削除してはいけません。すべてのモードで、デフォルトではアーカイブしてください。ユーザーが削除を依頼した場合は、gmail_delete_email または gmail_batch_delete_emails を呼び出す前に、破壊的操作の警告テンプレート（「DELETE」と入力して確認）を使用してください
13. 互いに独立したツール呼び出しは、すべて単一のメッセージで実行してください。独立した呼び出しを順次実行するのはバグです
14. コンテンツを読む前に、高速レーン分類を使用してください。送信者と件名だけで、トリアージ対象の 60% 以上を判定できます
15. NOISE をアーカイブする前に、必ずセキュリティゲートを実行してください。件名をスキャンし、2FA／パスワード／セキュリティ関連のキーワードがないか確認してください
16. Phase 0 の前にセッションキャッシュを確認してください。書き込み操作（gmail_create_label、gmail_get_or_create_label、gmail_create_filter、gmail_create_filter_from_template、gmail_batch_modify_emails、gmail_batch_delete_emails）の後はキャッシュを無効化してください
17. maxResults は 100～200 にしてください（500 は不可）。MCP の N+1 パターンでは、500 件の結果を取得すると約 501 回の API 呼び出しが発生します
18. 破綻のトリガーは、絶対的なしきい値ではなく、30 日間の基準値を基準とします
19. Phase 0 の前にユーザーメモリーを読み込んでください（Phase -1）。メモリーは主要な出力を提供した後に保存してください。メモリーの書き込みを理由に、モードの主要なワークフローを中断してはいけません

---

メモリーの保存トリガー

自然な判断のタイミングでメモリーを保存してください。保存のためにモードの処理を遅らせてはいけません。必ずモードの主要な出力を提供した後に保存してください。

トリガー	コマンド
トリアージ：ユーザーが高速レーン分類を修正した	memory.py save-correction --mode triage --what "..." --correction "..." --pattern "..." --action BUCKET
トリアージ：NOISE の一括アーカイブが正常に完了した	memory.py save-sender --email X --type noise --reason "..." --source triage（1 件のメッセージで複数件をまとめて保存）
送信者：VIP を特定した（返信率 >50%）	memory.py save-sender --email X --type vip --name "..." --reason "..." --source senders
フィルター：フィルターの作成が正常に完了した	memory.py save-filter --filter-id ID --description "..." --effectiveness high
フィルター：ユーザーが提案を却下した	memory.py save-filter --filter-id rejected --description "..." --effectiveness failed
ラベル：ユーザーが命名の好みを伝えた	memory.py save-labels --convention "..." --structure "..."
分析：メール量のパターンを算出した	memory.py save-patterns --daily-volume N --busy '[...]'
いずれかのモード：ユーザーが分類を修正した	memory.py save-correction ...

1 つのモードで複数のメモリーが生じた場合（例：トリアージで 5 件の迷惑メール送信者を特定した場合）は、複数の保存呼び出しを単一のメッセージにまとめてください