統合 inbox
Discord / LINE / email / Slack を 1 画面で source badge 付き表示し、 talent 別 / 担当者別に俯瞰する。 連絡の分散による反応漏れを潰すモジュール。
最終更新: 2026-05-13 / 担当: 伊藤
01解決する課題
連絡 source が分散していることで manager が日々時間と注意力を消費している実態を可視化する。
- 連絡 source が 4 種以上に分散 (Discord = 社内 / LINE = talent / email = 外部 / Slack = 監督)、 manager は毎日全部巡回している。
- 「どの source に来た連絡だったか」 を後から探すのに 5-10 分かかる。
- talent からの LINE を、 別 manager に手動転送する作業が日常発生している。
- 外部からの email が CC 漏れで担当者に届かず、 1 週間放置されるケースがある。
- 「未読 message が多すぎて反応漏れが起きそう」 という manager の心理的負荷。
02目的
source 横断で「talent 別 / 担当者別の連絡一覧」 を提供し、 反応漏れを構造的に潰す。 ただし全 source の adapter を組むのは重い実装になるため、 「value vs cost」 が見合うかを pilot で見極める。
03期待される効果
補助 KPI
反応漏れ ↓
定量効果 (見込み)
manager 巡回時間 -30 分/日
定性効果
心理的負荷↓
前提条件
LINE-MEMORY 統合先行
04HOW (実装方式)
| 運用形態 | 半自動 (取り込みは自動、 既読 / 紐付けは manager 操作)。 |
|---|---|
| data source 4 種 |
Discord: bot / webhook (botchan-mini 連携想定) LINE: LINE-MEMORY 統合 (Phase 2、 line-routing module 依存) email: Gmail OAuth (harness mailbox ito.ai.harness@gmail.com 既存基盤を流用可)Slack: agent2 channel reflection (Slack Webhook URL 既存) |
| 正規化 schema | 新規 talent_mgmt.inbox_messages table (source_type / ext_msg_id / talent_id / handler_user_id / posted_at / read_at / body / attachments_jsonb)。 |
| UI | 独立 page (/ops/inbox/) で source badge + priority sort + talent 紐付け + 既読 toggle。 タレント page 内には talent 別 sub-view を embed。 |
| RLS | manager は担当 talent 分のみ閲覧可。 全社 message (source 不問) は executive のみ。 |
| 実装重さ | 各 source の adapter (4 種) + 正規化 schema + RLS + UI = M-L サイズ (2-3 sprint)。 LINE adapter は LINE-MEMORY 統合 GO 待ち。 |
05現状
mock のみ。 旧 ops.html の Tab 2 で UI 試作実装あり (5630753)、 工事中切替で非表示中 (25045a7)。
実 adapter は未実装。 schema も未作成。 LINE-MEMORY 統合の GO 判断 (operator) を待っている状態。
- mock UI: 旧 ops.html Tab 2 の "Inbox" セクション (archived)
- 関連 mock data:
data-inbox.js - 関連 commit:
5630753(mock 実装),25045a7(工事中切替) - schema 設計書: 未作成 (line-routing と同 sprint で着手予定)
06残す / 残さない の判断材料
本モジュールは存続価値の閾値が高い。 以下が満たされなければ削除候補で問題なし。
- pilot 期間中 manager が「source 分散で困った」 と週 3 回以上発言する (= 痛みの実在確認)。
- LINE-MEMORY 統合が GO になっている (前提条件。 NO なら本モジュールも NO)。
- email / Slack 経由の連絡が talent 1 名あたり週 3 件以上発生する (= source 数値の実在)。
- 個別 source の native 通知 (Discord 1 ch 集約) で代替可能と manager が判断しない。
- 反応漏れの実例 (response 24h 以上遅延) が pilot 期間中に 3 件以上発生する。
代替検討 (本モジュール無しで済む案)
① Discord channel 1 本に全 source を webhook 集約する。 ② 各 native app の通知を OS レベルで unified inbox 化 (macOS / iOS 標準機能)。 ③ talent 数 20 名規模なら manager の頭で持ちきれる可能性も大。 単独実装は LINE-MEMORY 統合とセットで再評価する。