Overview / 運用 AI / LINE Routing 管理

LINE Routing 管理

LINE source (user_id / group_id) ↔ talent_id の mapping を管理し、 未割当 message を見える化。 新 talent 加入 / 退所時の紐付け漏れを 0 にする。

検討中 (LINE-MEMORY 統合 GO 待ち)

最終更新: 2026-05-13 / 担当: 伊藤

01解決する課題

LINE は talent との 1 次連絡手段だが、 source mapping が手動かつ属人化している現状。

02目的

LINE routing の透明化 (誰が誰宛 / 何が未割当 / どこが archived) を 1 画面で実現し、 mapping 漏れの早期発見と退所時の archive を確実にする。 LINE-MEMORY との二重管理を避け、 talent_mgmt 側を SoT (single source of truth) として運用する。

03期待される効果

主 KPI

未割当 alert 発火数 ↓

「黒箱で消える message」 を pilot 期間中ゼロ化。

補助 KPI

退所時 archive 漏れ 0

退所 talent の LINE が active のままになる事故を防ぐ。

定量効果 (見込み)

手動転送 -80%

担当変更時の message 転送作業を構造的に削減。

定性効果

manager 心理負荷↓

「誰宛か不明な LINE」 が消える安心感。

04HOW (実装方式)

運用形態半自動 (新規 source の検出は自動、 mapping 確定は manager の handover 操作)。
新規 tableline_sources(id, tenant_id, source_type, ext_source_id, current_talent_id, status, first_seen_at, archived_at)
status enum: unassigned / active / archived
3 面 UI Source 一覧: 全 source の current_talent_id / status を一覧
Mapping 履歴: talent 担当変更時の routing 変遷ログ
未割当キュー: 新規 source が status=unassigned で滞留している list
手順① 新 talent 追加時、 manager が LINE ID を入力 → unassigned で登録
② talent が friend 追加 → first message 検出で status=active に遷移
③ 退所時、 manager 操作で archived に。 message 取込停止。
関連 schema (既存)talent_mgmt.line_threads, talent_mgmt.line_messages (Phase 1 で既に migration 済)。 これに line_sources table を追加。
LINE-MEMORY 連動LINE-MEMORY (misao / hjax / sonoro) は独立稼働。 本モジュールは talent_mgmt 側専用 mapping。 ext_source_id で LINE-MEMORY 側 thread と join 可能。
権限manager 全員が unassigned キューを閲覧可。 mapping 変更は担当 manager と executive のみ。

05現状

設計のみ。 codex review 済 (Sprint 4 候補)、 Supabase migration 未作成、 LINE-MEMORY 統合 GO 判断 (operator) を待っている。 既存 talent_mgmt.line_threads / line_messages table は migration 済だが、 source mapping table は無い状態。

06残す / 残さない の判断材料

本モジュールは「LINE bot を実 talent に対して使うか」 が最大の前提条件。

代替検討

LINE 公式アカウント管理画面 + Notion table での手動管理で代用可能か? → talent 数 ≤10 名なら可能。 ≥20 名規模になった時点で本モジュールが必要に。 pilot で実際の数値を測ってから判断する。

07関連リンク

前: 統合 inbox 次: LINE 抽出