ある芸能事務所では、 案件・連絡・意思決定の 8 割以上 が LINE グループの中で起きている。 事務所だけでなく、 LINE でクライアント / 部下 / パートナー とやり取りする 経営者 / PM / マネージャー も同じ。 でも、 後から 「誰がいつ何を約束したか」 「何が未対応か」 を探すのは現実的に不可能 — 数十のグループ、 数百件の発言の中に重要な情報が散らばっているからだ。
LINE Memory Pro は、 その埋もれた業務記憶を AI で構造化し、 Issue (主題) → Task Tree (依存関係付きタスク群) → Slack 承認 → Google Calendar 予約 → LINE 自動 reply まで一気通貫で自動化する SaaS。
※ 数値は talent-mgmt pilot 対象 5 事務所 (LUV / LIS / PR / buggy / itou_dept) のヒアリングによる試算 (2026-05)
※ 初期 PoC は noisiii の 関根 — 伊藤 ライン (1 ペア 実 LINE) で 2026-05-13 着手
事務所運営の現場では、 メールも Slack も Notion も超えて LINE が 1 次窓口 になっている。 タレント本人 / クライアント / 制作会社 / 経理 / 税理士 — 全員が LINE でつながる。 しかし LINE は本来「会話アプリ」 であり、 業務管理ツールではない。 後から検索することも、 task を整理することも、 依存関係を可視化することもできない。
LINE グループには 世間話、 雑談、 業務、 確認、 決定 が混在する。 タレントが 「最近モチベが下がっていて辞めたいかも」 と書いた発言が、 数時間後の 「撮影楽しみです!」 と並んで流れていく。 重要度の見分けは AI でないと現実的にできない。
「税理士が合っていない」 という主題は、 単発の task ではない。 「本人と話す」 「候補を出す」 「面談する」 「切り替える」 という 依存関係を持つ複数 task の集合。 でも現状の運用ではすべてが「コメント」 のレベルで一緒くたに扱われ、 解決状態が見えない。
Talent Hub (社内 task / 案件 / 評価管理) と LINE (一次窓口) が分離していて、 manager がいちいち情報を転記している。 LINE で受けた相談を Talent Hub の task にコピペ、 Talent Hub で確定した内容を LINE で返信、 という二度手間が常態化。
埋もれた 80% を AI で構造化し、 manager の朝ルーチンを 1 画面に再構築する。
キーワード事前フィルタ + Claude による重要度判定で、 200+ talent の会話から「対応必須」だけを抽出。 manager は重要 alert のみ受け取る。
「依頼主体 / 実行主体 / 期限」 の 2/3 充足で task 候補化。 priority (P0-P3) × urgency (今日中/今週/今月) で 4×4 matrix に整理。
「ドラマ志向 → CM 志向」 「やりたい / 辞めたい」 等の発言を継続観測。 manager が見落としやすい profile signal を candidate として通知。
抽出された task 候補は Talent Hub UI から approve / reject。 承認すると internal_tasks に転記され、 担当者にアサインされる。
1 事務所 = 1 LINE Official Account = 1 tenant。 200+ タレントでも bot は 3-5 程度で運用。 tenant 間のデータは完全分離。
P0×今日中は realtime、 P0×今週は朝サマリー、 P3 は週次。 priority × urgency 別の routing rule を tenant ごとにカスタマイズ可能。
task が approve された / リマインダー / 朝サマリー / escalation 等を 当該 LINE group に自動 push。 承認トリガー or schedule トリガーで group 内のタレントにも可視化。
「増田が税理士を気に入っていない」 のような 主題 (Issue) を AI が依存関係付きの Task Tree に自動分解。 各 task に担当者・関係者・type (meeting/action/...) を AI が推論、 Slack で 「全て承認」 1 クリック → meeting 系は Google Calendar に自動予約 → LINE group に reply まで完結。 1 Issue あたり所要時間 10 分 → 30 秒 に短縮 (20 倍効率化)。
→ Issue 自動分解 設計を読む運用 AI の核 — タレントを伸ばすための 仮説 → 企画 → タスク化 → 実行 を一気通貫
LINE 業務記憶だけで終わらせない。 抽出された task 候補と issue を、 タレント運営の仮説立案 → 配信企画 → 具体タスク → カレンダー投入まで橋渡しする 3 つの最重要機能。
1 talent 1 SNS 戦略書。 狙い (vision) + ターゲット + コンテンツ仮説 (Reels/TikTok/YT Shorts 3-5 案) + KPI (3m/6m/12m) + 実行タスクまで AI が自動生成。 manager 承認で月次/週次 task に分解、 2 週間サイクルで自動再評価 (KPI 未達 / 志向変化検出で v2 提案)。
受験中 + オープン公募 を一括管理。 talent × audition の AI matching で「誰がどれを受けるべきか」 を 0-100% score で提案 (年齢 / 性別 / スキル / 狙い / 過去実績 / LINE 意思確認 の 7 要素加重)。 manager 承認で application 登録 + 年間オーディション計画に自動反映。
💡 LINE Memory との接続
LINE で抽出された 意思確認 「CM やりたい」 → オーディション matching score にプラス。 志向変化 「ドラマ志向 → CM 志向」 → SNS 戦略書 v2 再提案の trigger。 会議 task 「税理士の件 1on1」 → 年間カレンダーに自動投入 + LINE group に reply。 3 機能はすべて LINE Memory が抽出した signal を入力に動く。
LINE bot は機能を盛り込みすぎると、 manager が「結局何が大事か分からない」 状態になる。 LINE Memory Pro は onboarding 時に必要機能をチェックリストで選択 (後から追加・変更可)、 bot 担当者が 「あったらいい機能」 を常時投稿、 月次 review で導入判断する設計。
15 機能を 必須 / 任意 / β の 3 段で提示。 client (事務所) が tenant 設定で必要機能だけ ON。 後から ops/feature-requests/ で追加・変更可能、 operator 確認なしで切替できる granularity。
bot 担当者 (manager / executive) が「こんな機能あったらいいな」 を一文で投稿。 一覧で priority + vote が見える、 月次 review で roadmap / rejected を判定。 現場の声が消えずに積み上がる。
毎月末 executive 主催で priority + votes を review、 「roadmap 化」 / 「もう少し検討」 / 「却下」 を即決。 decision_reason を記録して「言っても何も変わらない」 不満を防ぐ。
📋 config.yaml の features セクション例 (noisiii_pilot)
features: keyword_filter: true # 必須 importance_scoring: true # 必須 slack_realtime_alert: true # 必須 extract_task_candidates: true # 任意 (commercial 標準) priority_urgency_classify: true # 任意 (commercial 標準) escalation_24h: true # 任意 extract_issues: true # β (PoC で検証) extract_profile_signals: true # β (PoC で検証) sns_strategy_signal: true # β (FLAGSHIP 連携) audition_matching_signal: true # β (FLAGSHIP 連携) annual_calendar_push: false # β (Phase 2) line_push_task_approved: false # β (Phase 3) line_push_reminder: false # β (Phase 3) line_push_morning_digest: false # β (Phase 3)
| 時期 | Phase | 達成内容 |
|---|---|---|
| 2026-05-13 (初期 PoC 着手) |
PoC | noisiii の 関根 — 伊藤 ライン で最初のアカウント運用。 1 ペアの実 LINE で extract_task_candidates / extract_issues / priority × urgency の有効性を検証。 commercial pilot 前の最小実証。 |
| 2026-05-15 (pilot 開始) |
Phase 1 |
priority/urgency 別 Slack 通知 + escalation worker。 既存 webhook 維持で payload 整理。 buggy / itou_dept から start。
→ 詳細 |
| 2026-06 月内 | Phase 2 着手 |
Slack App 作成 + tenant_slack_integrations migration。
|
| 2026-07 〜 8 月 | Phase 2 完了 |
Slack App OAuth2 install flow。 既存 5 client (buggy/itou_dept/luv/lis/pr) を移行。 webhook 個別配布廃止。
→ 詳細 |
| 2026-09 月以降 | Phase 3 |
双方向 Interactive Components。 Slack 内で approve / reject / snooze 完結。 Slash commands + App Home tab。
→ 詳細 |
現状 (incoming webhook) の限界、 multi-tenant 化の課題、 Phase 1-3 の実装計画。 schema 追加 + UI フロー含む。
→ 読む承認・schedule・escalation の各トリガーで LINE group へ push 通知。 idempotency / opt-in / rate limit / 失敗時 fallback 設計。
→ 読む主題から AI で 5 task + 8 subtask + 依存関係 + 担当者を自動推論。 Slack 1 クリック承認 → Google Calendar 予約 → LINE reply まで一気通貫。
→ 読む自社代行 (アイコン込みフルマネージド) / ハイブリッド (クライアント名義 + 自社代行作成、推奨) / クライアント完全 DIY の 3 案。 各方式の手間 / ブランド / data owner / 解約性を比較。
→ 読むDB を正とし、tenant ごとに Mastra runtime / storage / LINE token を分離。GraphQL API、管理画面、Slack App Home / Lists / Modal、詳細 DB schema まで含めた本番設計。
→ 読む6 step で初期セットアップを完了する mock wizard。 会社情報 → LINE Bot 作成方式選択 → Slack 通知 → 使う機能選択 → 確認 → 完了。 入力は localStorage 保存。
→ 試す「あったらいい機能」 を常時投稿。 LINE Bot DM (1on1 で「機能要望: …」) でも自動投稿、 AI が構造化して即一覧反映。 月次 review で priority + votes で governance。
→ 一覧 + 投稿service_role_key 管理、 RLS、 LINE webhook 署名検証、 PII filter、 GDPR/個情法対応。
🚧 準備中