Contents
BI ツールを入れてダッシュボードまで作ったあと、その数字をチームに「届く」状態にするところまで設計しきれずに止まっている、というのは多くの会社で見かける景色です。
ダッシュボードは存在しているのに、経営会議の場ではじめて数字に触れる人がいたり、PdM が「先週の数字どこで見れたっけ」と聞きに来たりする状況が、自然と続いてしまう。
そこを抜けていったチームを横で見ていると、たとえばこんな景色になっています。
月曜の朝、
#weekly-kpiに「先週比 +18%、過去 4 週で最大」と AI 要約が届いていて、PdM はそれを起点に週初の議題を組む営業マネージャーが朝会前に
#sales-dailyを覗けば、前日の商談数・受注・パイプラインが並んでいる経営会議の前日 22 時には、議題ごとのダッシュボードが PDF で議論役に配信されていて、当日になって資料を準備する仕事が消えている
マーケのチャンネルでは、広告 ROAS が前週比 −15% を割ったときだけアラートが飛び、普段は静かに保たれている
月初の朝、
#kpi-monthlyに先月の総括が文章で落ちているから、経営会議は冒頭の振り返りスライドなしで、いきなり議論から入れる
並べると用途は違って見えますが、これらはどれも ひとつの仕組み で成立しています。SQL を書いて、結果を AI に要約させ、Slack か Email に流す。基本はそれだけ。
Codatum の Workflow を使うと、この SQL → AI 要約 → 配信 の 3 ステップが 30 分くらいで組めて、一度作ってしまえば毎週・毎日・条件発火と、好きなタイミングで勝手に走り続けてくれます。
数字を集めて整える作業がチームから消えると、データチームは「数字を運ぶ係」から外れて、分析や設計のほうに時間を使える。事業側はダッシュボードを能動的に開かなくても、自分の業務範囲の数字に毎日触れる状態になる。Workflow 1 本が、チームに数字のリズムをそっと差し込んでくれる感覚です。
この記事では、その 3 ステップで「月曜朝の週次 KPI 配信」を組む手順を、実機の画面付きで紹介していきます。
全体像 — 3 ステップで「届く」を作る
Workflow は、スケジュール (Trigger) と Step の組み合わせでできていて、今回組むのはこの 3 つの Step です。
Run Query — 既存の保存済みクエリを実行する
LLM — 結果を AI に文章で要約させる
Slack — Liquid テンプレートで組んだメッセージを配信する
肝になるのは、前の Step の結果を次の Step が変数として参照できるところ。これがあるから、毎週流れるメッセージは「今週の数字」によって中身が変わってきます。固定文をスケジュールで流すだけのいわゆる "メール配信ツール" とは違って、定期配信が 毎回違うレポートとして届く 仕組みになります。
Trigger — 「毎週月曜の朝 8 時に走る」を 1 画面で
Workflow を新規作成すると、最初に聞かれるのが Trigger、つまり いつ走らせるか です。
Repeat every で時間 / 日 / 週 / 月から粒度を選び、週次なら曜日を複数指定できます (月・水・金、平日のみ、など)。Start time と Timezone まで指定できるので、「日本時間で毎週月曜 8 時」がそのままワンクリックで設定できる。
設定は内部で Temporal という workflow エンジンに渡されていて、起動時に 10 秒の jitter が自動で乗ります。同じ時刻に複数の Workflow を動かしているチームでも、起動の山ができにくく、運用が安定するように、という配慮です。
Step 1 — 既存のクエリをそのまま使う
Workflow の Run Query Step は、Codatum で書いた SQL をそのまま使える ように作られています。配信のためにクエリを別ツールにコピーして二重管理する、という作業がそもそも要らない。
ダイアログから保存済みクエリを 1 本選ぶだけで設定完了です。Recently used / Connection 別のタブで絞り込めるので、よく使うクエリなら 2 クリックで指定できます。
実行結果は次の Step から {{ query.rows }} や {{ query.rowCount }} といった変数で参照できる。「分析で使っているクエリがそのまま配信のソースになる」 という前提が、運用に効いてきます。普段の分析でクエリを直すと配信内容も自動で追従するから、「配信用の SQL がいつのまにか古くなっていた」という事故が起きません。
Step 2 — 数字を、読める文章に変える
ここが今回の Workflow の 要 だと思っています。
数字をそのまま Slack に流すだけでも push 配信としては機能します。ただ、月曜の朝にチャンネルをスクロールしている人の目に「読みたい」と思わせる強度は、数字の羅列では出にくい。「先週比 +18% で過去最高」「特定セグメントで急減」のように 人が読んで理解できる文章 になって、ようやく数字が情報として通り抜けていきます。
LLM Step は、それを Workflow の中で完結させる仕組みです。
プロンプト欄には Step 1 の結果を埋め込めます。
{{ query.rows | json }} の部分が、実行時に Step 1 の結果に置き換わります。LLM が要約を生成し、その結果は次の Step から {{ llm.text }} で参照できる、という流れです。
AI Profile で利用する LLM (Anthropic / OpenAI / Vertex AI など) を選べるので、組織の AI ポリシーに合わせて切り替えられます。Workflow 経由の LLM 呼び出しは Agent 機能の利用量と 別管理 で集計されるので、配信のためにいくら使っているかを Workflow 単位で見られるのも、運用面では地味に効いてきます。
Step 3 — メッセージを、業務の流れに載せる
最後の配信 Step (Slack または Email) は、メッセージ本体を Liquid テンプレートで自由に組める のが特徴です。下のスクリーンショットは Email Step の設定画面ですが、Slack Step も同じ「Subject + Body (または Channel + Message) + Liquid」の組み合わせで作れます。
たとえば Slack なら、こんなテンプレが書けます。
{{ llm.text }} の位置に、Step 2 の AI 要約がそのまま入ります。実行時にはこんな形になります。
:bar_chart: 今週の KPI レポート (2026-04-27)
先週比でセッション数は +18%、コンバージョン率は 3.2% で前週並み。新規ユーザーが 1,200 件と過去 4 週で最大値を記録しました。
詳細はダッシュボードで:
...
実機の Slack 上では、このメッセージがチームの普段のやりとりの中に並びます。
ダッシュボードに数字を集めるだけのときとの違いは、スクロール中の目への入り方 に出ます。数字の一覧は「確認しに行くもの」、文章は「目に入って読んでしまうもの」。月曜の朝、Slack を眺めている誰かが「お、+18% か」と一言反応してくれたら、push 配信は仕事をしてくれている、と思っていいと思います。
Slack 連携は事前に OAuth で接続しておく必要がありますが、Email Step は workspace のメンバーをそのまま宛先に指定できるので、Slack 接続をまだ整えていないチームはまず Email から試してみる、という入り方もあります。HTTP Request Step を組み合わせれば、Slack / Email 以外の社内ツールに飛ばす構成も同じ仕組みで作れます。
応用 1 — Notebook を PDF で届ける
「Slack の文章だけでは伝わらない、見た目で理解させたい」という場面もあります。経営会議の議題ごとのダッシュボード、四半期レビュー資料、対外配信レポート — このあたりは、文字より絵で届ける方が早い。
そういうときは Run Report Step + Screenshot Step の組み合わせで、Notebook ページの PDF 配信が組めます。Codatum の Notebook は Rich Text の Doc ページとダッシュボード型の Grid ページを混ぜて作れて、どちらも Run Report で実行 → Screenshot で PDF/PNG に書き出せる。Email にそのまま添付して配信 できる、という流れです。
経営会議の前日 22 時に「明日の議題ごとのダッシュボード」が議論役にメールで届いている、というあの景色は、ちょうどこのパターンで組まれているケースが多いと思います。
応用 2 — 「異常時だけ通知」も同じテンプレで
定期配信の運用が立ち上がってくると、次に欲しくなるのが 条件付きの通知 です。「目標を割ったときだけ」「指標が急変したときだけ」アラートが飛ぶ、というあれ。
各 Step には Execute if (optional) という条件式が書けて、これで分岐させられます。式は Liquid + SQL の WHERE 句 形式で、数字によって Step を実行するかどうかを決められる、という仕組みです。
これを Slack Step に書いておけば、売上が 1,000 万円を超えた週だけ通知が飛ぶアラート Workflow になります。「定期配信」と「異常検知」を 1 つの仕組みで扱えるので、Workflow 自体を増やしすぎずに、配信の網を少しずつ広げていけます。
まとめ — 「作る」から「届く」へ
ダッシュボードを作るところで止まっていたチームの次にあるのが、それをチームに届けるフェーズ です。「見にきてね」運用のままだと、数字はある資産なのに使われていない、という状態が静かに続いてしまう。Workflow が肩代わりしてくれるのは、ちょうどここの一歩です。
Run Query / LLM / 配信 の 3 ステップを Liquid テンプレートで繋いでしまえば、月曜朝の Slack に「読める数字」が並ぶ景色が、思っているよりずっと近くにある。集める朝から、読み解く朝へ。Workflow 1 本で、チームのリズムがそっと設計し直されていきます。
「うちのデータ運用、次の半歩を何に置こうかな」を Codatum を含めて壁打ちしたいときは、選定相談の窓口があります。
