inbox

Inbox — メールトリアージシステム

セットアップから定期的なトリアージまでを、1つのコマンドで処理する自己完結型のメールトリアージスキルです。自身の状態を検出して適切な処理に振り分けるため、どのモードを実行するか覚えておく必要はありません。

状態の検出（必ず最初に実行）

ほかのことを始める前に、ナレッジベース（KB）の有無を確認します。

状態	振り分け先
引数が update	→ 更新モード
${WORKSPACE}/Email/email-taxonomy.md が存在しない	→ セットアップモード
${WORKSPACE}/Email/email-taxonomy.md が存在する	→ トリアージモード

例外的なケース：

• ユーザーが「受信トレイをセットアップして」と言ったものの、KB が存在する場合 → その旨を伝え、「トリアージ／設定の更新／両方のどれを実行しますか？」と尋ねます。
• ユーザーが「受信トレイをトリアージして」と言ったものの、KB が存在しない場合 → 「ナレッジベースが見つかりません。まずセットアップを実行し、その直後にトリアージを実行します。」→ セットアップ → トリアージ
• KB が一部しかない場合（一部のファイルが欠けている場合）→ 欠けているファイルを一覧表示し、「セットアップをすべて実行しますか／不足しているセクションだけを補いますか？」と尋ねます。

---

セットアップモード — ナレッジベースを構築する

KB が存在しない場合に実行します。

実施時のルール

すべてのファイルを一度に生成しないでください。 8つのセクションを1つずつ進めます。次に進む前に、各セクションのファイルを保存します。途中でユーザーがインタビューを中断しても、部分的に完成したKBを利用できます。

• 1ターンにつき質問は1つ。 セクションをまたぐ場合も、複数の質問をまとめないでください。
• すべての質問に「質問する理由」を添える — 何が重要なのかを知ることで、ユーザーはより適切に回答できます。
• 可能な限り回答形式を指定する。 自由回答より選択式を優先します。
• 依存関係に沿った順序にする。 セクションNの内容をセクションN+1に反映します。

8つのセクションを進める際の詳しいルールは、references/grill_me_section_walk.md を参照してください。

ナレッジベース — 作成する7つのファイル

${WORKSPACE}/Email/ に書き込みます。

ファイル	用途	必須？
email-taxonomy.md	分類システムとレポートの設定	はい
email-patterns.md	返信時の文体、トーン、テンプレート、厳守事項	はい
evaluation-framework.md	オファーや機会に関するメールの判断ツリー	ユーザーが売り込みやオファーを受け取る場合のみ
rate-card.md	価格、条件、交渉方針	ユーザーが価格設定をしている場合のみ
blocklist.md	自動スキップする送信者と、学習した辞退パターン	はい（初期データを設定し、時間とともに増やします）
tracker.md	対応中のフォローアップ、期限超過項目、締め切り	はい（ほぼ空の状態で開始します）
triage-log/	実行ごとのログ用ディレクトリ	はい（空の状態で作成します）

終了条件

8つのセクション全体で、質問は合計約25〜31問です。確認のための追加質問を含め、上限は35問です。セクション1でオファーに関するメールのカテゴリがないと判明した場合、セクション4（評価フレームワーク）は完全に省略します。セクション8の確認と引き継ぎメッセージが終わった時点でヒアリングは終了します。設定を変更するには、update モードを使用してください。

セクション1：全体像

次の6つの掘り下げ質問を、1つずつ尋ねます。

• S1.Q1: 「どんな仕事をしていますか？役割と事業について、1〜2文で教えてください。質問する理由： 背景を把握すると、想定されるメールのパターンが見えてきます。個人クリエイターの受信トレイは、大企業のプロジェクトマネージャーの受信トレイとはまったく異なります。」
• S1.Q2: 「受信トレイの大半を占めるのは何ですか？上位1〜2つを選んでください：営業メール／クライアント業務／社内チーム／ニュースレター／カスタマーサポート／財務／その他。質問する理由： 主なカテゴリをもとに分類体系を作成します。」
• S1.Q3: 「おおよその割合を教えてください。例：「業務上の問い合わせが60％、運営業務が20％、不要メールが20％」。質問する理由： 割合を把握することで、トリアージに注力すべき箇所がわかります。」
• S1.Q4: 「トリアージの対象にするメールアドレスを教えてください。質問する理由： 複数ある場合は、アドレスごとに分類体系を設定します。」
• S1.Q5: 「実行頻度はどれですか：1日1回／1日2回／1日3回／必要なときだけ？質問する理由： トリアージ時のデフォルトの検索期間が決まります（1日2回の場合、重複期間は9時間です）。」
• S1.Q6: 「アシスタント、VA、チームメンバーなど、メール管理を手伝う人はいますか？それとも一人で対応していますか？質問する理由： メールを委任している場合、担当者の扱い方が異なります。」

アクション： 頭の中で全体像を組み立てます。まだファイルには書き込みません。オファーに関するメールのカテゴリがあるかどうかを記録します（セクション4の省略判定に使用します）。

セクション 2：メールのカテゴリ

セクション 1 に基づいて 5～7 個のカテゴリを提案します。以下から一部を事前に提案してください。

• 新しい機会
• 対応中のやり取り
• 対応が必要
• 金融
• 重要／個人的なメール
• 情報提供
• 無視／優先度低

次の 3 つの質問を、一度に 1 つずつ尋ねます。

• S2.Q1: 「以下の分類案は、あなたの受信トレイの実情に合っていますか？ はい／だいたい合っている／いいえ。 質問の理由：『いいえ』の場合、他のセクションに進む前に分類を作り直す必要があるためです。」
• S2.Q2: 「不足しているカテゴリはありますか？ あれば挙げてください。（なければスキップしてください。） 質問の理由： カテゴリが不足すると、後続の処理でメールが未分類となり、トリアージの品質が低下するためです。」
• S2.Q3: 「メール 1 通あたりに最も時間がかかるカテゴリはどれですか？ 質問の理由： 返信の下書きにかける労力を、最も重点的に割り当てるカテゴリを特定するためです。」

アクション： カテゴリ、シグナル、カテゴリごとのデフォルトのアクションをまとめた email-taxonomy.md を生成します。

セクション 3：返信スタイルと文体

次の 6 つの掘り下げ質問と、重要なサンプルの依頼を行います。

• S3.Q1: 「文体は、フォーマル／カジュアル／中間のどれですか？ 質問の理由： デフォルトの文体を調整し、次にサンプルを使ってさらに調整するためです。」
• S3.Q2: 「コミュニケーションで苦手なことを 3 つ挙げてください。嫌いなフレーズや避けたい書き出しなどです。 質問の理由： これらを下書きで使用禁止の表現として扱うためです。」
• S3.Q3: 「いつも使うフレーズや結びの言葉を、思いつく限り挙げてください。 質問の理由： これらはあなたの文体を特徴づける表現だからです。」
• S3.Q4: 「状況に応じて、異なるペルソナを使いますか？ 例：アシスタントがあなたの代わりに返信する場合。 質問の理由： ペルソナの文脈によって、一人称と署名の扱いが変わるためです。」
• S3.Q5: 「通常の返信の長さはどれくらいですか？ 一文／短い段落／長め。 質問の理由： 文体のシグナルの中で、長さは最も間違いやすいためです。」
• S3.Q6: 「厳守すべきルールはありますか？ 絶対にしないこと、常にすることなどです。 質問の理由： 厳守すべきルールは、すべての下書きで譲れない条件として適用するためです。」

S3.SAMPLES（最も質の高い入力）：

受信トレイから、実際に送信したメールを 3～5 通貼り付けてください。

質問の理由： 自分の文体についての自己評価は当てになりません。実際のサンプルが最も優れたシグナルです。scripts/voice_sample_analyzer.py を使ってパターンを抽出してください。

アクション： email-patterns.md を生成します。サンプル抽出の手順については references/voice_calibration.md を参照してください。

セクション 4：評価フレームワーク（条件付き）

セクション 1 で機会に関するメールが見つからなかった場合はスキップしてください。 それ以外の場合は、次の 6 つの掘り下げ質問を行います。

• S4.Q1: 「何かを提案されたとき、最初に確認することは何ですか？ 直感的な判断基準を教えてください。 質問の理由： それが意思決定ツリーの最初の項目になるためです。」
• S4.Q2: 「即座に断る理由を 3 つ挙げてください。 質問の理由： これらを自動的に PASS と判断するシグナルにするためです。」
• S4.Q3: 「すぐに興味を持つポイントを 3 つ挙げてください。 質問の理由： これらを TAKE-IT の判断シグナルにするためです。」
• S4.Q4: 「標準的な料金や条件はありますか？ それとも『固定料金なし』ですか？ 質問の理由： 料金表があれば、こちらで作成するためです。」
• S4.Q5: 「交渉時の姿勢は、強硬／柔軟／状況次第のどれですか？ 質問の理由： 反対提案への返信の下書きの文体を決めるためです。」
• S4.Q6: 「必ず対応する VIP の差出人や組織はありますか？ 質問の理由： VIP リストにより、通常の PASS フィルターを迂回させるためです。」

アクション： evaluation-framework.md を生成します。料金がある場合は rate-card.md も生成します。

セクション 5：ブロックリストとパターン

• S5.Q1: 「常にスキップする差出人やドメインはありますか？（なければスキップしてください。） 質問の理由： 自動ブロックリストにより、実行ごとの時間を最も節約できるためです。」
• S5.Q2: 「いつも削除するメールには、どのようなパターンがありますか？ 質問の理由： パターンがあれば、完全一致の条件を保守しなくても、トリアージで類似のメールを自動的にスキップできるためです。」
• S5.Q3: 「時間を無駄にする特定の企業、採用担当者、ニュースレターはありますか？ 質問の理由： これらをブロックリストの初期項目にし、判断を上書きするたびにトリアージで追加していくためです。」

アクション： blocklist.md を生成します。

セクション 6：現在の状況

• S6.Q1: 「追跡中の進行中スレッドを、それぞれ1行の概要とともに一覧にしてください。（なければ省略してください。）質問の理由： これらをトラッカーの項目に登録し、トリアージ時に既存の状況を把握できるようにします。」
• S6.Q2: 「返信期限を過ぎているものはありますか？ 質問の理由： 解決されるまで、トリアージのたびに優先事項としてフラグを立てます。」
• S6.Q3: 「期限のある、時間的制約が厳しい項目はありますか？ 質問の理由： トラッカーで期限を管理し、適切なタイミングで期限超過として表示します。」

アクション： tracker.md を生成し、空の triage-log/ ディレクトリを作成します。

セクション 7：レポートの設定

• S7.Q1: 「配信形式：自分宛てのメール下書き／ワークスペース内のファイル／チャットの要約のみ。質問の理由： トリアージレポートは実行のたびにここに出力されます。」
• S7.Q2: 「詳細レベル：30秒で確認できる概要／詳細な内訳／両方。質問の理由： レポートの長さに影響します。」
• S7.Q3: 「常に最初に表示したい項目はありますか？ 例：期限超過の支払い、VIPからのメッセージなど。質問の理由： レポート冒頭のカスタムルールにより、標準セクションより先に、重視する項目を表示します。」

アクション： レポートの設定を email-taxonomy.md に追記します。

セクション 8：確認と引き継ぎ

作成したファイルをすべて、1文の概要を添えて一覧にします。scripts/kb_validator.py --workspace ${WORKSPACE} を実行し、7ファイルの要件が満たされていることを確認します。

その後、次のように尋ねます。

トリアージシステムの準備ができました。今すぐトリアージを実行しますか？

1. はい — 受信トレイをすぐに処理する
2. いいえ — あとで自分で実行する

はいの場合 → そのまま以下の トリアージモード に移行します。

プライバシーの境界

パスワード、完全な口座番号、SSN、その他の機密性の高い認証情報を KB ファイルに保存してはいけません。 インタビュー中にユーザーが自発的に伝えた場合は、その内容を認識したうえで保存せず、該当するファイルに [stored separately by user] と記載します。

---

トリアージモード — メールの定期トリアージ

KB が存在する場合に実行します。設計上、初回の聞き取りは最小限です。

下書きのみ — 送信禁止

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

これは必須事項です。実行後に scripts/draft_safety_validator.py がこれを検証します。アクションログに送信を行うツール呼び出しが含まれていると、検証に失敗します。references/drafts_only_safety.md を参照してください。

ステップ 0：確認のための質問（任意の上書き質問は 0～2 件）

Q1（通常の実行間隔から外れたオンデマンド実行の場合のみ）：

デフォルトの9時間の検索対象期間を上書きしますか？ はい（時間数を指定）／いいえ。

質問の理由： 通常の実行間隔から外れて実行する場合、検索対象期間を広げたり狭めたりしたいことがあります。

Q2（カテゴリを除外する意図でユーザーが実行した場合のみ）：

今回の実行で除外するカテゴリはありますか？ 例：「ニュースレターを除外」。

質問の理由： 機会を探したり、進行中のスレッドを整理したりするだけでよい場合もあります。

質問は最大2件です。 デフォルトの実行ではどちらも省略し、KB のデフォルト設定で実行します。

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

<CADENCE> と <ISO> にそれぞれ該当する値を指定し、scripts/search_window_calculator.py --cadence <CADENCE> --now <ISO> を使用します。

実行頻度（email-taxonomy.md から取得）	デフォルトの検索対象期間
1日1回	26時間
1日2回	9時間
1日3回	6時間
オンデマンドのみ	24時間（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 文）を示し、丁寧な辞退文を作成
確認が必要	通常とは異なり、ユーザーの直接判断が必要	詳細をすべて提示し、下書きは作成しない

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

ステップ 6：下書き

email-patterns.md の文体ルールに従って下書きを作成します。送信操作は絶対に実行しないでください。下書きの作成のみ行います。

下書き本文では、以下を遵守してください。

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

**次のメールには下書きを作成しないでください：**ニュースレター、自動送信メール、参考情報のみのスレッド、すでに返信済みのスレッド、ブロック対象の送信者。

推奨事項ごとのトーン：

• 対応する → 積極的で、具体的な次のステップを示す
• 検討する価値あり → 関心を示し、確認の質問を 1～2 件する
• 見送る → 丁寧に辞退し、理由を簡潔に示す（期待を持たせる約束はしない）
• 確認が必要 → 下書きは作成しない

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

email-taxonomy.md の設定に従います。既定では、自分宛てのメール下書きを作成します。

件名： Inbox Triage — [Day], [Month Date] ([Run Label])

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

1. 概要 — 2～3 文。何が起きたか、緊急の項目があるかを記載
2. 統計 — 処理済み／作成した下書き／対応が必要／スキップ
3. 要対応 — 期限超過の項目、判断事項、確認が必要な下書き、期限
4. クイックリファレンス — メール 1 件につき 1 行：**送信者** — 要約 + 推奨事項
5. 詳細カード — 案件、進行中のスレッド、要確認事項。下書き本文のプレビューは含めない
6. フッター — タイムスタンプ + KB の更新概要

HTML の書式設定（該当する場合）： インライン CSS のみ（Gmail は <style> を削除します）。色分け：緑 → 対応する、琥珀色 → 検討する価値あり、赤 → 見送る、紫 → 確認が必要、青 → 進行中の会話。

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

blocklist.md： 新たに辞退した送信者とパターンを追記し、ユーザーが例外を認めた場合は削除します。

tracker.md： 新しいフォローアップを追記し、既存項目を更新し、解決済みの項目に印を付け、期限超過を明示し、30 日を超えた解決済み項目を削除し、更新ログに記録を追加します。

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

ステップ 9：内部ログ

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

• 分類した処理対象メール
• 行った推奨
• 作成した下書き（スレッド参照付き）
• 実施したナレッジベースの更新
• 特記事項

scripts/draft_safety_validator.py の監査証跡として使用します。

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

新着メールが 0 件の場合も、以下を行います。

1. tracker.md を確認し、今日が期限または期限超過の項目を探す
2. 最小限のレポートを生成：「前回の実行以降、対応が必要な新着メールはありません」
3. 期限超過の項目を明示する

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

---

更新モード — 設定の更新

/notion inbox update または「受信トレイの設定を更新して」によって開始します。

1. ${WORKSPACE}/Email/ に既存のファイルがあるか検出する
2. ファイルごとに、置き換え／統合／スキップ のどれにするか尋ねる
3. ユーザーが更新を選んだファイルに対応するセクションのみを順に確認する
4. ユーザーが維持するファイルに対応するセクションはスキップする

---

重要なルール

1. 下書きのみ — 絶対に送信しないでください。 これは譲れません。
2. プライバシー。 KB ファイルにパスワードや認証情報を記載しないでください。
3. 速度より正確さを優先してください。 判断に迷った場合は、レビューが必要であることを明記してください。
4. KB を尊重してください。 文書化された設定を唯一の情報源とします。独自の判断で覆さないでください。
5. 透明性。 KB の変更はすべてトリアージログに記録してください。
6. 初回の実行には監督が必要です。 この前提をユーザーに伝えてください。

エラー処理

状況	動作
KB がなく、トリアージが開始された	まずセットアップを実行し、その後トリアージを行います
KB が存在し、セットアップが開始された	その旨を伝え、トリアージ、更新、または両方を提案します
KB が不完全（ファイルが不足）	不足している項目を一覧表示し、セットアップ全体を行うか、不足しているセクションのみを補完するか提案します
ワークスペースにアクセスできない	作業を停止し、ファイルの保存先を伝えて、パスを尋ねます
メールツールを利用できない	明確なメッセージを伝えて停止します
ユーザーが音声サンプルを拒否	自己説明を使い、パターンファイルに調整を繰り返す可能性があることを記載します
ユーザーがインタビューの途中で離脱	部分的な KB を尊重し、確定済みのファイルを使用可能とします
新着メールが 100 件以上	件数を明記し、優先カテゴリのみに絞るか提案します
送信者がブロックリストと追跡リストの両方に存在	追跡リストを優先し、矛盾をログに記録します

ポータビリティ

• Claude Code CLI： ネイティブ対応 — Markdown ファイルをファイルシステムに直接書き込み、Gmail／Outlook MCP を使用します。
• Claude.ai web： ファイルをアーティファクトとして生成し、ワークスペースに保存するようユーザーに指示します。

ツール

スクリプト	役割
scripts/kb_validator.py	セットアップ後に 7 ファイルの KB を検証します（必須ファイルの有無、条件付きファイルと実行したセクションの一致、ヘッダーと構成の正しさ）。
scripts/section_progress_tracker.py	8 つのインタビューセクションをまたぐ進行状況を JSON で管理します。
scripts/voice_sample_analyzer.py	貼り付けられた送信済みメールのサンプルから、音声のパターンを抽出します。
scripts/kb_reader.py	トリアージ開始時に 7 ファイルの KB を読み込み、検証します。必須ファイルが不足している場合は停止します。
scripts/search_window_calculator.py	頻度と現在時刻から window_start を算出します。run_label を返します。Q1 の上書きを優先します。
scripts/draft_safety_validator.py	実行後にアクションログをスキャンし、送信に該当するツール呼び出しがないか確認します。検出した場合は FAIL になります。

参考資料

• references/grill_me_section_walk.md — 8 セクションの進行ルール、スキップ条件、セクションごとの確定
• references/voice_calibration.md — サンプルに基づく音声パターン抽出の理論とアンチパターン
• references/kb_file_contract.md — 7 ファイルの契約（構成、セクション、読み取り動作）
• references/triage_decision_framework.md — TAKE IT／WORTH／PASS／FLAG の分類
• references/drafts_only_safety.md — 絶対に送信しないためのルール

拒否すべきアンチパターン

• メールの送信 — 下書きのみ。これは譲れません
• セクションごとに進めず、KB ファイルを一度にすべて生成する
• 質問をまとめて一度に尋ねる（対話形式で進めるルールに反します）
• 機密性の高い認証情報を KB に保存する
• KB ファイルなしでトリアージを実行する
• トリアージ実行の最後に KB を更新しない
• ユーザーが文書化した設定を独自の判断で覆す
• セットアップの質問で「この質問が重要な理由」を省略する
• トリアージレポートに下書きのプレビューを含める（下書きはすでにメールクライアントにあります）
• アダプターパターンを使わず、特定プロバイダーにロックインする