FiveVai AI Lab
← 実演一覧に戻る

FiveVai PMダッシュボード

プロジェクトの遅延やブロッカーをAIが自動で見張り、毎日の進捗とバーンダウンをSlackに届けるPM自動化システム。

PMが手で追っていた進捗・遅延 → AIが巡回し、Slackに自動で届く状態巡回・進捗レポート・週次サマリを自動化（人は判断に集中）
承認して動くAI難易度 2/5Claude Code CLI / Backlog・Slack (MCP) / launchd

このPoCから得た実装知

  1. 1AIはチケットを勝手に変えない。検出・通知・提案に徒し、最終判断は人が下す
  2. 2同一課題への連続アラートは24時間空け、通知をノイズにしない
  3. 3タスクワーカーの成果物は『ドラフト』。AIが作って人が確定する

判断材料

AI 権限レベル
承認して動くAI
想定対象部門
PM開発経営
扱うデータ
Backlog課題Slack通知
人間の承認
必要（人が確認してから実行）
失敗時の止め方
Backlogのステータス変更・担当者アサインはせず提案のみ。エージェントを止めれば通知が止まるだけでチケットには影響しない。アカウント操作・権限変更は禁止
導入難易度
2 / 5
初期導入期間
1〜2週間（Backlog/Slack連携と運用ルール設定）
必要な社内担当
PM・進行管理Backlog・Slackの管理者
連携対象 SaaS
BacklogSlack
最小構成
まず巡回（遅延・ブロッカー検出）と日次レポートだけ動かす
横展開先
複数プロジェクトの進捗監視社内タスクの停滞検知週次レビューの自動化

このPoCが向いている会社

以下に1つでも当てはまる会社では、効果が大きい。

  • 複数の案件・プロジェクトが並行し、PMが進捗を手で追っている
  • 遅延やブロッカーに気づくのが遅れ、対応が後手に回る
  • 毎日の進捗共有や週次レビューの準備に時間がかかっている
  • AIに任せたいが、チケットを勝手に変えられるのは怖い

経営インパクト

Before

PMがBacklogを手で巡回し、遅延・ブロッカーの検知と進捗共有に追われていた

After

AIが定時に巡回して遅延・ブロッカーをSlackに通知し、日次レポートと週次バーンダウンを自動配信。PMは判断に集中できる

削減時間
毎日の巡回・進捗まとめ・週次サマリ作成 → 自動
減ったリスク
遅延・ブロッカーの見落とし、対応の遅れを低減
判断の改善
バーンダウンとリスク評価で、週次の意思決定が早くなる
横展開できる型
監視→検知→通知→提案のPMエージェント（実行は人が確定）

このデータがあれば、これができる

最小構成 ─ まずここから
INPUT DATA
  • ▸Backlogの課題（期限・状態・担当）
YOU CAN DO
  • ▸過期課題・ブロッカー・遅延の検出
  • ▸Slackへの巡回通知
  • ▸毎朝の日次進捗レポート
発展構成 ─ ここまでつなぐと強い
INPUT DATA
  • ▸通知先のSlackチャンネル
  • ▸タスクのAI実行可能性
YOU CAN DO
  • ▸週次バーンダウン分析・リスク評価
  • ▸AI実行可能タスクのドラフト成果物
  • ▸報連相が必要な課題の提示
  • ▸連続アラート抑制（24時間）

Pain — どんな痛みがあったか

プロジェクトが複数走ると、PMはBacklogを毎日見て回り、遅延・ブロッカー・未対応を拾い、進捗をまとめてSlackに共有する。これだけで一日が削られる。気づくのが遅れると対応が後手になり、週次レビューの準備にも時間がかかる。AIに任せたいが、チケットを勝手に書き換えられるのは怖い。

Intent — なぜ作ったか

PMの「見張りと共有」をAIに肩代わりさせ、PMは判断と調整に集中する。ただしAIにチケットの変更や決定は任せず、検出・通知・提案に徒する。

Approach / Rationale / Lessons / 改善ログ の続きを読む

Magic Link で 60 秒。クレカ不要・退会即時。

最初の1週間でやること

  • 監視したいプロジェクト（Backlog）を1つ決める
  • 通知先のSlackチャンネルを用意する
  • まず巡回（遅延・ブロッカー検出）と日次レポートだけ動かす
  • 1週間運用して通知の頻度・粒度を調整する

やらないこと

  • AIにチケットの変更や担当アサインをさせない
  • 通知を出しすぎない（連続アラートは間隔を空ける）
  • AIの成果物をそのまま確定しない（ドラフト→人が確認）
  • いきなり全エージェントを動かさない

費用対効果の考え方

  • PMの巡回・進捗まとめ・週次準備の工数
  • 遅延・ブロッカーの見落としによる手戻り
  • 週次意思決定の遅れ
  • 複数案件を1人で見る負荷
このPoCの位置づけ

承認して動くAIの代表事例 — チケットは変えず、見張りと気づきを任せるPMエージェント

AIにチケットは触らせない。遅延とブロッカーの見張りと、毎日の進捗共有だけを任せる。

導入前チェックリスト

商談前に、自社側でこの 5 点を確認しておくと検討がスムーズに進む。

  • 対象となるデータは、自社のどこにあるか

    この PoC が扱うデータ: Backlog課題 / Slack通知

  • そのデータの更新頻度はどれくらいか（毎日 / 週次 / 不定期）

  • 人間の承認が必要な操作は何か

    この PoC は「人が確認してから実行」を前提に設計している

  • 想定どおり動かないとき、止める方法はあるか

    この PoC の止め方: Backlogのステータス変更・担当者アサインはせず提案のみ。エージェントを止めれば通知が止まるだけでチケットには影響しない。アカウント操作・権限変更は禁止

  • 社内の担当者は誰か（運用・データ・承認の窓口）

    想定担当: PM・進行管理 / Backlog・Slackの管理者