inbox-triage

Inbox-Triage — 定期的なメールのトリアージ

inbox-setup と連携します。 このスキルは、inbox-setup が ${WORKSPACE}/Email/ に作成する7ファイルのナレッジベースを使用します。ファイルの仕様は完全に一致している必要があります。references/kb_file_contract.md を参照してください。これは、読み取り側の視点から見たセットアップ側の仕様のミラーです。

定期的なスケジュール（1日1～3回）または必要に応じて実行します。最近のメールを分類し、新しい送信者を調査し、判断の推奨事項を作成し、返信の下書きを作成し（送信は絶対にしません）、整理されたレポートを提供して、今回の実行で得た知見をナレッジベースに反映します。

起動トリガー

• 「受信トレイをトリアージして」
• 「受信トレイのトリアージ」
• 「メールを確認して」
• 「メールのトリアージを実行して」
• 「受信トレイを処理して」
• 「メールに新着はある？」
• 「メールを処理して」
• 「メールのトリアージ」

前提条件

開始時に必要な読み込み（ファイルがない場合は即時終了）：

コア（必須）：

• ${WORKSPACE}/Email/email-taxonomy.md — 分類とレポートの設定
• ${WORKSPACE}/Email/email-patterns.md — 文体、ペルソナ、テンプレート、厳守ルール

コア（任意。存在する場合に読み込み）：

• ${WORKSPACE}/Email/evaluation-framework.md
• ${WORKSPACE}/Email/rate-card.md

更新対象（毎回読み込み、更新）：

• ${WORKSPACE}/Email/blocklist.md
• ${WORKSPACE}/Email/tracker.md

出力：

• ${WORKSPACE}/Email/triage-log/<YYYY-MM-DD>-<run-label>.md — 実行ごとのログ

必須のコアファイルが1つでも見つからない場合は、停止し、最初に inbox-setup を実行するようユーザーに案内します。読み込みと検証には scripts/kb_reader.py を使用してください。

下書きのみ — 送信は絶対にしない

このスキルは下書きを作成します。送信は絶対にしません。

これが、このスキルを自動実行しても安全に保てる特性です。このスキルの本文では何度も明記しています。例外は認められません。

scripts/draft_safety_validator.py が実行後にこのルールを強制します。アクションログに送信に該当するツール呼び出しがあると、検証に失敗します。ルールの全容については、references/drafts_only_safety.md を参照してください。

ステップ 0：確認事項の聞き取り（簡易 — 任意の上書き質問を0～2問）

Inbox-triage は、ナレッジベースに inbox-setup の設定が事前に反映されている状態で定期的に実行することを想定しているため、聞き取りは簡易的に行う設計です。ここでの確認事項の聞き取りでは、今回重要となる上書き質問だけを尋ねます。

Q1（任意。通常の頻度から外れたタイミングで、オンデマンド実行する場合のみ質問）

デフォルトの検索期間である9時間を上書きしますか？はい（時間を指定）／いいえ（デフォルトを使用）から選んでください。

質問する理由： 通常の1日2回の実行頻度から外れてオンデマンドで実行する場合、長い休止後なら期間を広く（24時間）、簡単な確認なら狭く（2時間）したいことがあります。

通常の頻度であれば省略します。

Q2（任意。ユーザーがカテゴリを除外する意図を示して実行した場合のみ質問）

今回、除外するカテゴリはありますか？例：「ニュースレターを除外」「金融関連を除外」。

質問する理由： 機会だけを確認したい場合や、対応中のスレッドだけを片付けたい場合があります。カテゴリを除外すると、実行対象を絞り込めます。

ユーザーがカテゴリ除外の意図を示していない場合は省略します。

停止条件： 質問は最大2問です。デフォルトの呼び出しでは、どちらの質問も省略し、ナレッジベースのデフォルト設定で実行します。このスキルは定期的な実行を迅速に行えるよう最適化されています。聞き取りは例外であり、通常の手順ではありません。

ステップ 1：検索期間の決定

現在の日付から計算します。デフォルトの遡及期間は9時間です（1日2回の実行に適しており、実行間のメールを見落とさないよう、少し重複させています）。

--cadence <CADENCE> --now <ISO> を指定して scripts/search_window_calculator.py を使用します。

now = current_datetime
window_start = now - 9_hours   (default for 2x-daily)
run_label = "Morning" if now.hour < 12 else "Afternoon" if now.hour < 17 else "Evening"

頻度とデフォルトの検索期間の対応（Q1 で上書き可能）：

頻度（email-taxonomy.md S1.Q5 より）	デフォルトの検索期間
1日1回	26h
1日2回	9h
1日3回	6h
オンデマンドのみ	24h（Q1 を質問）

ステップ 2：メール検索

2 つのクエリを使用します（プロバイダーに依存しないアダプターパターン）。

• メイン： window_start 以降の受信トレイと送信済みメール
• サブ： スター付きの未読メール（メインの検索で見つからなかったフラグ付きメールを捕捉）

各メールについて収集する項目：送信者、件名、日付、スニペット、スレッド ID、ラベル。

プロバイダーアダプターの対応表：

プロバイダー	ツール
Gmail	Gmail MCP
Outlook / Microsoft 365	Outlook MCP
IMAP（Fastmail、ProtonMail など）	利用可能な場合は IMAP MCP、それ以外は停止
（メールツールが利用できない場合）	明確なメッセージ「このセッションに登録されたメールツールがありません。」を表示して停止

ステップ 3：分類

email-taxonomy.md の分類体系を適用します。最も優先度の低いカテゴリ（ニュースレター／自動送信／スパム）は、スレッドを一切開かずにスキップします。コンテキストのコストに見合わないためです。それ以外はすべて、スレッド全体を読みます。

ステップ 4：送信者の調査

トラッカー／ブロックリスト／過去のログに記載されていない送信者について：

1. blocklist.md を確認し、一致する場合は自動的にスキップ
2. tracker.md を確認し、既知のスレッドであれば既存のコンテキストを記録
3. 案件の送信者については（評価フレームワークに従い）、ウェブ検索で企業の信頼性、ソーシャルメディアでの存在感、仲介者としての立場を確認

調査を一切行わない対象： 既知の送信者（トラッカーに記載）、社内メール、自動通知、明らかに優先度の低いメール。

ステップ 5：提案

対応が必要なメールには、evaluation-framework.md のフレームワークを適用します。次のように分類します。

カテゴリ	条件	出力
受ける	条件を満たす	対応を推奨し、返信案を作成（ステップ 6）
検討する価値あり	可能性はあるが、ユーザーの判断が必要	重要なコンテキストを提示し、ユーザーが編集できる返信案を作成
辞退	条件を満たさない	「理由」を簡潔に記載（1～3 文）し、丁寧な辞退文を作成
要確認	通常と異なり、ユーザー自身の判断が必要	詳細を提示し、返信案は作成しない（返信の形式はユーザーが決定）

各項目に、簡潔な「理由」、関連するコンテキスト、該当する場合は料金／スケジュールの比較を含めます。

evaluation-framework.md が存在しない場合は、ステップ 5 を一切実行しないでください。

フレームワークの正式な基準については、references/triage_decision_framework.md を参照してください。

ステップ 6：下書き

返信候補として妥当なものすべてについて、email-patterns.md の文体ルールに従って下書きを作成します。

下書きを作成する対象： 案件への返信（受ける／検討する価値あり／辞退）、返信が必要な進行中のやり取り、アクション項目、重要な個人的なメール。

次の場合は下書きを作成しないでください：

• 明らかに返信不要なメール（ニュースレター、自動送信、参考情報）
• ユーザーがすでに返信したスレッド
• ブロックした送信者（新情報によって判断が変わる場合を除く）

作成方法：

• 可能な場合は、既存のスレッド内にのみ下書きを作成します（コンテキストが保たれます）
• to と subject（Re: [original]）を設定します
• 送信操作は絶対に呼び出さないでください。下書きの作成のみ行います。

下書きの本文では、次の要件を必ず守ってください。

• email-patterns.md の文体
• 禁止トークン（S3.Q2 の苦手な表現）
• 結びの言葉のパターン
• ペルソナのコンテキスト
• 厳守事項（S3.Q6 — 交渉不可）
• email-patterns.md に記載された返信の長さ

evaluation-framework.md が存在する場合、下書きのトーンは提案内容に合わせます。

• 受ける → 積極的な姿勢＋具体的な次のステップ
• 検討する価値あり → 関心を示す＋確認の質問を 1～2 個
• 辞退 → 丁寧な辞退＋簡潔な理由（期待を持たせる約束はしない）
• 要確認 → 下書きなし

ステップ 7：レポートの送付

email-taxonomy.md の「レポートの設定」セクションにあるユーザーの希望に従います。デフォルト：HTML 形式で自分宛てのメール下書きを作成します。

件名： 受信トレイのトリアージ — [Day]、[Month Date] ([Run Label])

セクション（順番どおり）：

1. 概要 — 2～3 文。何が起きましたか？緊急のものはありますか？
2. 統計 — 処理済み、作成した下書き、対応が必要、スキップした件数。
3. 対応が必要 — 期限超過の項目、判断が必要な項目、確認が必要な下書き、締め切り。
4. クイックリファレンス — 送信者名のアルファベット順で、メールごとに 1 行。**送信者** — 1 文での要約 + 推奨事項。
5. 詳細カード — 案件、進行中のスレッド、フラグ。各項目には、送信者／件名／カテゴリ、推奨事項とその理由、重要な背景情報を含めます。下書き本文のプレビューは含めないでください（下書きはすでにメールクライアントにあり、ユーザーがそこで確認できます）。
6. フッター — 生成日時 + ナレッジベースの更新概要。

書式設定（HTML の場合）：

• インライン CSS のみ（Gmail は <style> を削除します）
• 推奨事項ごとに色分け：
  • 緑 → 対応する
  • 琥珀色 → 検討する価値あり
  • 赤 → 見送る
  • 紫 → 確認が必要
  • 青 → 進行中の会話

ステップ 8：ナレッジベースの更新

blocklist.md（新しい項目を追記）：

• 新たに断った送信者 + 理由 + 日付
• 観察された行動から得られた新しい辞退パターン（例：「Gmail アドレスから届いた『looking for backend engineers』を含むメールはすべて → 勧誘メールのパターン」）
• ユーザーが例外扱いした項目を削除（ユーザーが「ブロック済み」の送信者に返信した場合 → ブロックを解除）

tracker.md（追記と更新）：

• 今後の対応が必要なメールについて、新しいフォローアップを追加
• 既存のフォローアップを更新（期限の変更、ステータスの変更）
• 解決済みの項目を完了としてマーク
• 期限超過の項目にフラグを付ける
• 30 日を超えて前に解決した項目を削除
• 更新ログにエントリーを追加

実行を重ねる中で観察する学習パターン：

• 下書きがそのまま送信されたか、編集されたか、削除されたか → トーン調整の指標
• ユーザーが見送る推奨事項を例外扱いしたか → フレームワーク調整の指標
• メールに対応したか、無視したか → 分類体系の改善の指標
• 新しい辞退パターン → ブロックリストへの追加

5 回以上実行した後、ナレッジベースの改善案をユーザーに提案します（例：「X からのメールはいつも断っています。自動スキップに追加しますか？」）。

ステップ 9：内部ログ

${WORKSPACE}/Email/triage-log/[YYYY-MM-DD]-[run-label].md に保存します：

• 処理したメールとその分類
• 行った推奨
• 作成した下書き（ID／スレッド参照を含む）
• 行ったナレッジベースの更新
• 追加／解決したフォローアップ
• 注目すべき観察事項（判明したパターン、対処したエッジケース）

このログは、実行後の送信操作を scripts/draft_safety_validator.py が検査するための監査証跡です。

ステップ 10：受信トレイが空の場合の処理

新着メールが 0 件の場合でも：

1. tracker.md を確認し、本日が期限の項目や期限超過の項目を探します
2. 「前回の実行以降、対応が必要な新着メールはありません」という簡易レポートを作成します
3. 期限超過の項目にフラグを付けます
4. トラッカーのルールに従ってエスカレーションします

受信トレイが空の場合は、ステップ 3～6 をすべてスキップします。

重要なルール（繰り返し明記）

1. 下書きのみ — 絶対に送信しない。 例外は認められません。ここでも改めて明記します。
2. プライバシー。 ナレッジベースにパスワードや認証情報を記載しないでください。機密情報についてはスレッド ID を参照してください。
3. 速度より正確さを優先。 確信が持てない場合は、確認が必要としてフラグを付けてください。誤った自動下書きは、下書きがないよりも悪い結果です。
4. ナレッジベースを尊重する。 文書化された設定を唯一の基準とします。独自の判断で覆さないでください。
5. 透明性。 ナレッジベースへの変更はすべてトリアージログに記録してください。
6. 初回の実行には監督が必要です。 この方針をユーザーに伝えてください。

エラー処理

状況	動作
KB ファイルが見つからない	停止し、inbox-setup の実行をユーザーに案内します
メールツールが利用できない	必須ツールについて明確なメッセージを表示して停止します
送信者の調査にウェブ検索を利用できない	調査ステップをスキップし、送信者を調査していないことを記録します
下書きの作成に失敗する	該当する下書きをスキップし、ログに記録します。レポートの処理は続行します
レポートの配信に失敗する	フォールバックとしてレポートをファイルに保存し、ユーザーに通知します
ユーザーに新着メールが100件以上ある	妥当な範囲内にとどめ、メールの件数を知らせ、優先カテゴリのみに絞ることを提案します
送信者がブロックリストとトラッカーの両方に記載されている	トラッカーを優先します（進行中の会話）。不整合をログに記録します

移植性

• Claude Code CLI： ネイティブ対応です。Gmail／Outlook MCP、ナレッジベース用のファイルツール、調査用のウェブ検索を使用します。
• Claude.ai web： メール MCP コネクターが接続されていれば動作します（Gmail MCP が利用可能）。ツールを利用できるか確認してから処理する必要があります。メールツールがない場合は、明確なメッセージを表示して停止します。

ツール

スクリプト	役割
scripts/kb_reader.py	7つの KB ファイルを読み取り、検証します。解析済みの構造を返します。必須ファイルがない場合は、明示的なエラーを表示して停止します。
scripts/search_window_calculator.py	処理間隔と現在時刻から window_start を計算します。run_label を返します。Q1 の上書きを適用します。
scripts/draft_safety_validator.py	実行後、アクションログをスキャンし、送信に該当するツール呼び出しがないか確認します。検出した場合は FAIL となります。「絶対に送信しない」というルールを決定論的に適用します。

参考資料

• references/kb_file_contract.md — 7ファイルの標準契約（読み取り側の視点。../inbox-setup/references/kb_file_contract.md と対応）
• references/triage_decision_framework.md — TAKE IT／WORTH／PASS／FLAG の分類
• references/drafts_only_safety.md — 「絶対に送信しない」という規律の原則

排除すべきアンチパターン

• メールを送信すること（下書きのみ。これは譲れません）
• ナレッジベースのファイルなしで処理すること
• パスワードや認証情報を KB に保存すること
• 実行の最後に学習ループ（KB の更新）を省略すること
• ユーザーが文書化した設定を、自身の判断で上書きすること
• 優先度が最も低いスレッドを読むこと（コンテキストの無駄遣い）
• レポートに下書きのテキストプレビューを含めること（下書きはすでにメールクライアントにあります）
• アダプターパターンを使わずにプロバイダーにロックインすること
• ツールが見つからない場合に、何も通知せず処理を失敗させること

---

バージョン： 1.0.0 ソース仕様： megaprompts/07-inbox-triage-megaprompt.md（メンテナーのローカルドラフト仕様。gitignore 対象で、公開リポジトリには含まれていません） ビルドパターン： パス B（直接変換）。inbox-setup と組み合わせて使用します。