究極の個人秘書 × チームメール監視
独立実験環境 設計書

01 プロジェクト概要と目的 OVERVIEW

aohashi.dev/dev-home/ は「タブ切替型のリンク集」に近い状態。今回のラボでは、タスク単位で情報が集約され、AIが能動的に次の一手を示し、その場で相談できる「**タスク中心の個人秘書OS**」を作る。さらにその思想を応用してチームメールの放置を検出する「管理者視点の監視レイヤ」を派生させる。

コンセプトの関係

02 事例調査サマリ BENCHMARK

海外20製品＋国内3製品を調査。ここで得た「使えるパターン」と「避けるべき罠」を次章の設計に織り込んでいる。

2.1 ①個人秘書まわりのインタラクション事例

採用するベストプラクティス（①）

1. スペースキーでPeekパネル（Linear式）— タスク選択→Space→右パネル450px幅。
2. 関連資料の自動サーフェス（Mem.ai式）— タスク選択時、右パネル下半分にSlack/Drive/過去タスクの候補が浮上。
3. AI提案は3チップ（Todoist式）— 長文禁止。[分解][コツ][締切]のような3ボタン。
4. Contextドロップダウン（Coda式）— チャット上部に「このタスク／このプロジェクト／全体」の明示切替。
5. @mention（Cursor式）— チャットで @タスク @資料 @人 を補完付きで指定。
6. 右下フローティング→サイドパネル→全画面（Sunsama / Notion式）— チャットの段階開示。

2.2 ②メール監視まわりの製品事例

03 ① タスクダッシュボード 設計 TASK DASHBOARD

画面の主役は「タスク一覧」。AIも資料もチャットも、タスクを中心に周りに配置する。現行dev-homeは「タブ切替でリンクを並べる」構造だが、ここから「タスクを選ぶと全てが追随する」構造に転換する。

3.1 画面レイアウト

┌──────────┬────────────────────┬──────────────────┐
│          │                    │  COMPANION PANEL  │
│  SIDEBAR │   TASK LIST        │  （450px幅）       │
│  (240px) │                    │                  │
│          │   - カード形式      │  [上半分]          │
│  ・今日   │   - 優先度で並ぶ    │   タスク詳細＋     │
│  ・今週   │   - hoverで軽い    │   AI次の一手3チップ│
│  ・全て   │     ツールチップ   │                  │
│  ・記憶   │   - Spaceで右に    │  [下半分]          │
│  ・資料   │     Peek展開       │   関連資料（自動   │
│          │                    │   サーフェス）     │
└──────────┴────────────────────┴──────────────────┘
                                       ┌────────┐
                                       │ 💬 Chat│ ← 右下固定
                                       └────────┘
                                  クリックで右Panelを拡張

3.2 主要インタラクション

3.3 データモデル（MVP）

Task {
  id, title, description, status, priority,
  due_at, created_at, updated_at,
  linked_resources: [                 // 手動＋自動検出
    { type: 'drive'|'slack'|'gmail'|'url', id, label, preview }
  ],
  ai_recommendations: [               // 直近の生成キャッシュ
    { chip: 'decompose'|'tips'|'deadline', content, generated_at }
  ],
  chat_history: [                     // タスクごとに分離
    { role, content, created_at }
  ],
  source: 'manual'|'email'|'calendar'|'ai_suggested'
}

3.4 AI機能の内部

3.5 CLAUDE.md「AI最小化」原則との整合

04 ② チームメール監視 設計 TEAM MAIL WATCHER

「全員のメールを裏で読んで、放置を検出してリーダーにアラート」。技術は ASAP メールAI の仕組みを下敷きにしつつ、**複数アカウント対応**と**本文非保存設計**を足す。

4.1 認証方式の比較と決定

4.2 未返信判定ロジック（疑似コード）

FOR thread IN inbox（直近30日）:

  # Step 1: そもそも返信が要るか（全部if文で判定）
  IF List-Unsubscribe ∈ headers        → SKIP（メルマガ）
  IF Auto-Submitted: auto-generated     → SKIP（自動返信）
  IF my_address ∈ BCC only              → SKIP（情報共有）
  IF sender ∈ known_bot_list            → SKIP

  # Step 2: 最終発言者チェック
  IF thread.last_message.direction == 'outbound':
    CONTINUE（既に返信済み）

  # Step 3: 営業時間換算の経過
  elapsed = business_hours(now - last_inbound.received_at)
  IF 24h ≤ elapsed < 48h                → status = WARN（黄）
  IF elapsed ≥ 48h                      → status = ALERT（赤・リーダー通知）

  # Step 4: 曖昧ケースだけAIに聞く（CLAUDE.md AI最小化原則）
  IF status == WARN AND 件名に「FYI」「確認不要」等あり:
    ask_LLM("このメールは返信必須か?") → 1トークンでY/N補正

ポイント：ステップ1〜3は全部プログラムで完結。AI呼び出しは境界ケースだけ。CLAUDE.mdの「if文 > LLM」方針に厳密に沿う。

4.3 アーキテクチャ

4.4 プライバシー設計（最重要）

4.5 チームリーダー視点のダッシュボード

4.6 アラート疲れ対策

• デフォルトは朝夕のダイジェストだけ（9時・18時）。
• 赤（48h超）だけリアルタイム、しかもチャンネルへのメンションは同スレッドにつき1回まで。
• しきい値はチームごとにカスタマイズ（営業=24h、開発=72h等）。
• 一時停止機能でバカンス時・出張時は自動的に通知抑制。

05 独立環境の構成 ISOLATED LAB

本番（aohashi.net、secretary-ai-dev、ASAP Cloud Run）は一切触らない。新しいサブドメイン・新リポジトリ・新GCPプロジェクトを立て、事故ってもロールバック不要な設計にする。

06 ロードマップ ROADMAP

承認後のスケジュール案。各フェーズはゲート判定。前フェーズが動かない限り次には進まない。

ゲート判定基準

• Phase 0 → 1: lab.aohashi.net にダミーページが表示される／Cloudflare Access で青橋Googleログインが通る／GCPプロジェクトが分離されている
• Phase 1 → 2: ①のデモ機能が斉藤さんのテストで「使える」判定／Claude API料金が想定内／dev-home並みの動作速度
• Phase 2 → 完成: saito@ と sales@ の2アカウントで1週間運用／誤検出率10%以下／本文非保存が機能／Slack通知の疲れ具合を実測

07 リスクと対策 RISK

08 今日決めたい論点 DECISIONS

設計を前に進めるには、斉藤さんの判断が必要なポイントが8つある。推奨案（★）を提示しているが、変更可能。

1. ドメイン名

   ラボ環境の公開URL。recommended は短く覚えやすい方。

   lab.aohashi.net next.aohashi.net sandbox.aohashi.net r2.aohashi.net

2. GCPプロジェクト分離

   本番 aohashi-infra と同居するか、新プロジェクトを切るか。

   新プロジェクト aohashi-lab を作成 既存 aohashi-infra 内で別サービス

3. 着手順

   ①②どっちから攻める？

   Phase 0 → ① → ②（段階的） 並行 ②は別会話に分離

4. ①のタスク入力源

   タスクはどこから来る？複数選択可。

   手入力（優先） Gmail抽出 Googleカレンダー Slack DM 現行dev-homeからインポート

5. ①の関連資料ソース

   どこまで横断検索する？

   Google Drive Gmail Slack Notion ローカルMarkdown

6. ②のテスト対象アカウント

   最初に接続するテスト用Gmailを教えてください。

   saito@bluebridge.me sales@bluebridge.me 他に保有のテストアカウント → 列挙してください

7. ②の本文保存ポリシー

   本文をFirestoreに保存するか。

   保存しない（メタデータのみ） 保存する（暗号化・90日削除）

8. ②のリーダー宛アラート先

   チームリーダー（saito@）にはどのチャネルで飛ばす？

   Slack DM Slackチャンネル（#lab-alert） メール ダッシュボード内通知のみ