FiveVai AI Lab
← 実演一覧に戻る

Fv Data Platform

freee・board・Backlog を毎朝1つに集約し、各役割へ正確な数字を配信するデータ基盤。

SaaSに分散したデータ → 朝8時に集約され、経営・PM・経理が同じ数字を見る状態月次の手集計 → 毎朝自動更新（PL・案件・キャッシュフロー）
見るだけAI難易度 4/5Supabase Edge Functions (Deno) / PostgreSQL 17 / pg_cron

このPoCから得た実装知

  1. 1アプリから各SaaSを直接叩かず、raw/martの基盤を1つ挿むと壊れにくくなる
  2. 2同期は失敗前提。自動リフレッシュ＋3回リトライ＋Slack通知で自己回復させる
  3. 3機密データ（給与・売上）は基盤側のRLS・ロールで閉じ、アプリ実装に依存させない

判断材料

AI 権限レベル
見るだけAI
想定対象部門
経営管理部門PM経理
扱うデータ
freee会計freee人事労務boardBacklogSupabase
人間の承認
不要（閲覧・通知のみ）
失敗時の止め方
ソース（freee/board/Backlog）からは読み取りのみ。書き込みは自社Supabaseに限定。同期を止めてもデータ更新が止まるだけで、源泉のSaaSには影響しない
導入難易度
4 / 5
初期導入期間
1〜2ヶ月（接続するサービス数に依存）
必要な社内担当
情シス・データ担当各SaaSの管理者（freee/board/Backlog）
連携対象 SaaS
freee会計freee人事労務boardBacklogSupabaseSlack
最小構成
まず1サービス（例: Backlog）を日次同期し、1つのmail・mart（例: ベロシティ）を作るところから
横展開先
経営ダッシュボードPM Dashboard入金消込給与チェック勤怠管理

このPoCが向いている会社

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

  • 業務データが freee/board/Backlog など複数SaaSに分散している
  • 役割ごとに「正しい数字」を出すのに毎回手集計している
  • 経営・PM・経理が別々のスプレッドシートを見ている
  • 給与・売上など機密データを含み、誰が何を見られるかを厳密に管理したい

経営インパクト

Before

業務データが各SaaSに分散し、役割ごとに正しい数字を出せなかった

After

朝8時までに4サービスからデータを集約し、各役割へ正確な数字を配信

削減時間
月次の手集計 → 毎朝自動更新
減ったリスク
数字の食い違い・手集計ミスの低減、機密データのアクセス制御
判断の改善
月次PL・案件health・キャッシュフローを毎朝の判断に使える
横展開できる型
raw/mart/meta の3層データ基盤（1基盤 → 多アプリ）

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

最小構成 ─ まずここから
INPUT DATA
  • ▸1つのSaaSのAPIキー/OAuth（例: Backlog）
  • ▸Supabaseプロジェクト
YOU CAN DO
  • ▸日次自動同期
  • ▸1つのmail・mart（例: 開発ベロシティ）
  • ▸同期状況の可視化（sync_status）
発展構成 ─ ここまでつなぐと強い
INPUT DATA
  • ▸freee会計/人事労務・board・Backlog のOAuth
  • ▸Slack Webhook
YOU CAN DO
  • ▸月次PL
  • ▸案件サマリー（health_score）
  • ▸日次キャッシュフロー
  • ▸入金消込（5段階マッチング）
  • ▸ロール別アクセス制御（admin/manager/pm/accounting）
  • ▸Slack日次サマリー

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

経営の痛み
  • 月次PLやキャッシュを見るのに集計待ち
  • リアルタイムに数字が分からない
PMの痛み
  • 案件の予算・進捗・遅延が board/Backlog に分かれて全体が見えない
経理の痛み
  • freeeとboardの突合が手作業
  • 給与など機密データの取り扱いに気を遣う
情シス・データ担当の痛み
  • 各SaaSのAPI・OAuth・同期失敗対応が属人化していた

Intent — なぜ作ったか

各SaaSに分散したデータを1つに集約し、役割ごとに「正しい数字」を毎朝届ける。用途別アプリは個別にAPIを叩かず、この基盤だけを見ればよい状態にする。

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

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

最初の1週間でやること

  • 接続する1サービス（例: Backlog）を決める
  • OAuth/APIキーを発行し日次同期を回す
  • 1つのmail・mart（例: 開発ベロシティ）を作る
  • sync_statusで同期の成否を毎朝確認する

やらないこと

  • いきなり全サービスを繋がない（1つずつ）
  • アプリから各SaaSを直接叩かない
  • 給与など機密をアプリ側のRLS頼みにしない（基盤で閉じる）
  • クライアントにservice_roleを露出しない

費用対効果の考え方

  • 役割別の手集計にかかる工数
  • 数字の食い違いによる手戻り・不信
  • 月次締めの遅れ
  • 機密データ漏洩リスク
このPoCの位置づけ

業務データ基盤の代表事例 — 1つ集約すれば、多くのアプリが正しい数字を見るだけになる

各SaaSに散ったデータを毎朝1つに集約。経営・PM・経理が同じ正しい数字を見る。

導入前チェックリスト

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

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

    この PoC が扱うデータ: freee会計 / freee人事労務 / board / Backlog / Supabase

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

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

    この PoC は閲覧・通知のみで、書き込みは行わない

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

    この PoC の止め方: ソース（freee/board/Backlog）からは読み取りのみ。書き込みは自社Supabaseに限定。同期を止めてもデータ更新が止まるだけで、源泉のSaaSには影響しない

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

    想定担当: 情シス・データ担当 / 各SaaSの管理者（freee/board/Backlog）